* [PATCH v6 00/10] Add the I3C subsystem
@ 2018-07-19 15:29 Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
` (10 more replies)
0 siblings, 11 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
This patch series is a proposal for a new I3C subsystem.
This infrastructure is not complete yet and will be extended over
time.
There are a few design choices that are worth mentioning because they
impact the way I3C device drivers can interact with their devices:
- all functions used to send I3C/I2C frames must be called in
non-atomic context. Mainly done this way to ease implementation, but
this is still open to discussion. Please let me know if you think it's
worth considering an asynchronous model here
- the bus element is a separate object and is not implicitly described
by the master (as done in I2C). The reason is that I want to be able
to handle multiple master connected to the same bus and visible to
Linux.
In this situation, we should only have one instance of the device and
not one per master, and sharing the bus object would be part of the
solution to gracefully handle this case.
I'm not sure if we will ever need to deal with multiple masters
controlling the same bus and exposed under Linux, but separating the
bus and master concept is pretty easy, hence the decision to do it
now, just in case we need it some day.
The other benefit of separating the bus and master concepts is that
master devices appear under the bus directory in sysfs.
Discussion around the bus/master/dev representation is still ongoing,
with Arnd opting for a simple approach where
* the bus is implicitly represented by the master device
* the master is not represented as a device under the I3C bus
* only remote I3C devices are exposed and possibly duplicated if
several masters controlling the same bus are exposed to the same
Linux instance
and Peter preferring the representation where the bus is a separate
object. IIRC, Wolfram was in favor of the "bus is a separate object"
too.
If possible, I'd like to close this discussion soon, no matter which
solution is chosen.
- I2C backward compatibility has been designed to be transparent to I2C
drivers and the I2C subsystem. The I3C master just registers an I2C
adapter which creates a new I2C bus. I'd say that, from a
representation PoV it's not ideal because what should appear as a
single I3C bus exposing I3C and I2C devices here appears as 2
different busses connected to each other through the parenting (the
I3C master is the parent of the I2C and I3C busses).
On the other hand, I don't see a better solution if we want something
that is not invasive.
Missing features in this preliminary version:
- support for HDR modes (has been removed because of lack of real users)
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldn't
have a huge impact on the I3C framework because I3C slaves don't see
the whole bus, it's only about handling master requests and generating
IBIs. Some of the struct, constant and enum definitions could be
shared, but most of the I3C slave framework logic will be different
Main changes between v5 and v6:
- Introduce {i3c,i2c}_dev_desc structures to better match how I3C
master controllers (reservation of one HW slot for each device
attached to the bus). With this solution, the resource migration
that happens when a device lose its dynamic address and is
re-assigned a different address is simplified on the driver side,
because most of it is now handled in the core (reserve a new dev
slot, reserve IBI resources and free all resources attached to the
old slot)
- Add I3C error codes (M0 to M2) so that the core and device drivers
can have fine grained information on what caused an EIO error.
Only minor things happened between v3 and v5 (you can go check the
changelog in each patch for more details).
Main changes between v2 and v3 are:
- Reworked the DT bindings as suggested by Rob
- Reworked the bus initialization step as suggested by Vitor
- Added a driver for an I3C GPIO expander
Main changes between the initial RFC and this v2 are:
- Add a generic infrastructure to support IBIs. It's worth mentioning
that I tried exposing IBIs as a regular IRQs, but after several
attempts and a discussion with Mark Zyngier, it appeared that it was
not really fitting in the Linux IRQ model (the fact that you have
payload attached to IBIs, the fact that most of the time an IBI will
generate a transfer on the bus which has to be done in an atomic
context, ...)
The counterpart of this decision is the latency induced by the
workqueue approach, but since I don't have real use cases, I don't
know if this can be a problem or not.
- Add helpers to support Hot Join
- Add support for IBIs and Hot Join in Cadence I3C master driver
- Address several issues in how I was using the device model
Thanks,
Boris
Boris Brezillon (10):
i3c: Add core I3C infrastructure
docs: driver-api: Add I3C documentation
i3c: Add sysfs ABI spec
dt-bindings: i3c: Document core bindings
dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg
property
MAINTAINERS: Add myself as the I3C subsystem maintainer
i3c: master: Add driver for Cadence IP
dt-bindings: i3c: Document Cadence I3C master bindings
gpio: Add a driver for Cadence I3C GPIO expander
dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
Documentation/ABI/testing/sysfs-bus-i3c | 95 +
.../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 39 +
.../devicetree/bindings/i3c/cdns,i3c-master.txt | 44 +
Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++
Documentation/driver-api/i3c/device-driver-api.rst | 9 +
Documentation/driver-api/i3c/index.rst | 11 +
Documentation/driver-api/i3c/master-driver-api.rst | 10 +
Documentation/driver-api/i3c/protocol.rst | 203 ++
Documentation/driver-api/index.rst | 1 +
MAINTAINERS | 10 +
drivers/Kconfig | 2 +
drivers/Makefile | 2 +-
drivers/gpio/Kconfig | 11 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-cdns-i3c.c | 411 ++++
drivers/i3c/Kconfig | 24 +
drivers/i3c/Makefile | 4 +
drivers/i3c/core.c | 606 ++++++
drivers/i3c/device.c | 233 +++
drivers/i3c/internals.h | 36 +
drivers/i3c/master.c | 2058 ++++++++++++++++++++
drivers/i3c/master/Kconfig | 5 +
drivers/i3c/master/Makefile | 1 +
drivers/i3c/master/i3c-master-cdns.c | 1668 ++++++++++++++++
include/dt-bindings/i3c/i3c.h | 28 +
include/linux/i3c/ccc.h | 385 ++++
include/linux/i3c/device.h | 331 ++++
include/linux/i3c/master.h | 652 +++++++
include/linux/mod_devicetable.h | 17 +
29 files changed, 7036 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/index.rst
create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/protocol.rst
create mode 100644 drivers/gpio/gpio-cdns-i3c.c
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/dt-bindings/i3c/i3c.h
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.14.1
^ permalink raw reply [flat|nested] 71+ messages in thread
* [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-08-03 21:38 ` mshettel
2018-08-22 16:43 ` vitor
2018-07-19 15:29 ` [PATCH v6 02/10] docs: driver-api: Add I3C documentation Boris Brezillon
` (9 subsequent siblings)
10 siblings, 2 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, 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.
Missing features in this preliminary version:
- I3C HDR modes are not supported
- 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@bootlin.com>
---
Changes in v6:
- Add I3C/I2C dev descriptors to simplify I3C driver controllers when
migrating resources from on I3C device slot to anoter
- Add I3C error codes and return them when doing SDR/priv and CCC
transfers. This allows us to properly detect when no devices acked
a CCC command, which in some cases is a valid situation (no I3C
devices on the bus)
- Remove __packed specifiers where unneeded
- Allocate all IBI slots in one call using kcalloc()
Changes in v5:
- Rename the address sysfs entry into dynamic_address to clarify things
- Document that we expect buffers passed to i3c_device_do_priv_xfers()
to be DMA-able
- Fix DEFSLVS CCC command
- s/2017/2018/ in copyright headers
- Fix SPDX header in internals.h
- Fix coding style issues
Changes in v4:
- none
Changes in v3:
- Fix locking issues
- Explicitly include a bunch of headers (reported by Randy Dunlap)
- Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
- Do not use BIT() macro in mod_devicetable.h
- Fix typos
- Fix/enhance some kernel doc headers
- Rework the bus initialization code to simplify master drivers
- Assign dynamic address with SETDASA if the device has a static
address and the DT has a valid assigned-address property
- Rework the LVR extraction in DT parsing code
- Add code to detect when a device is re-attached to the bus after
losing its dynamic address. In this case we know try to re-assign the
old address, and most importantly, the I3C device driver sees the same
device instance, not a new one
- Add an ->i2c_funcs() hook to let the master declare which I2C features
it supports
- Unexport a few functions
- Remove support for HDR mode since we have no real user yet
Changes in v2:
- Fix a bunch of mistake I made with the device model (pointed by GKH)
- Move the documentation out of this commit (pointed by GKH)
- only source drivers/i3c/master/Kconfig when CONFIG_I3C is enabled
(pointed by GKH)
- Add IBI infrastructure
- Add helpers to ease support for Hot Join (most of the logic is
delegated to I3C controller drivers)
- move the doc out of this commit to improve readability
- Fix a few bugs in device probing/remove (detected after trying to
load/unload modules in various orders)
- Add a module_i3c_i2c_driver() macro to ease integration of drivers
for devices that support both I3C and I2C mode
---
drivers/Kconfig | 2 +
drivers/Makefile | 2 +-
drivers/i3c/Kconfig | 24 +
drivers/i3c/Makefile | 4 +
drivers/i3c/core.c | 606 ++++++++++++
drivers/i3c/device.c | 233 +++++
drivers/i3c/internals.h | 36 +
drivers/i3c/master.c | 2058 +++++++++++++++++++++++++++++++++++++++
drivers/i3c/master/Kconfig | 0
drivers/i3c/master/Makefile | 0
include/linux/i3c/ccc.h | 385 ++++++++
include/linux/i3c/device.h | 331 +++++++
include/linux/i3c/master.h | 652 +++++++++++++
include/linux/mod_devicetable.h | 17 +
14 files changed, 4349 insertions(+), 1 deletion(-)
create mode 100644 drivers/i3c/Kconfig
create mode 100644 drivers/i3c/Makefile
create mode 100644 drivers/i3c/core.c
create mode 100644 drivers/i3c/device.c
create mode 100644 drivers/i3c/internals.h
create mode 100644 drivers/i3c/master.c
create mode 100644 drivers/i3c/master/Kconfig
create mode 100644 drivers/i3c/master/Makefile
create mode 100644 include/linux/i3c/ccc.h
create mode 100644 include/linux/i3c/device.h
create mode 100644 include/linux/i3c/master.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 95b9ccc08165..80f6aebc896f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -55,6 +55,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 24cd47014657..999239dc29d4 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..30a441506f61
--- /dev/null
+++ b/drivers/i3c/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menuconfig I3C
+ tristate "I3C support"
+ select I2C
+ help
+ I3C is a serial protocol standardized by the MIPI alliance.
+
+ It's supposed to be backward compatible with I2C while providing
+ support for high speed transfers and native interrupt support
+ without the need for extra pins.
+
+ The I3C protocol also standardizes the slave device types and is
+ mainly designed to communicate with sensors.
+
+ If you want I3C support, you should say Y here and also to the
+ specific driver for your bus adapter(s) below.
+
+ This I3C support can also be built as a module. If so, the module
+ will be called i3c.
+
+if I3C
+source "drivers/i3c/master/Kconfig"
+endif # I3C
diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
new file mode 100644
index 000000000000..3b6d1502d6e6
--- /dev/null
+++ b/drivers/i3c/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+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..5c62192ff876
--- /dev/null
+++ b/drivers/i3c/core.c
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#include <linux/device.h>
+#include <linux/idr.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_device.h>
+#include <linux/rwsem.h>
+#include <linux/slab.h>
+
+#include "internals.h"
+
+static DEFINE_IDR(i3c_bus_idr);
+static DEFINE_MUTEX(i3c_core_lock);
+
+/**
+ * i3c_bus_maintenance_lock - Lock the bus for a maintenance operation
+ * @bus: I3C bus to take the lock on
+ *
+ * This function takes the bus lock so that no other operations can occur on
+ * the bus. This is needed for all kind of bus maintenance operation, like
+ * - enabling/disabling slave events
+ * - re-triggering DAA
+ * - changing the dynamic address of a device
+ * - relinquishing mastership
+ * - ...
+ *
+ * The reason for this kind of locking is that we don't want drivers and core
+ * logic to rely on I3C device information that could be changed behind their
+ * back.
+ */
+void i3c_bus_maintenance_lock(struct i3c_bus *bus)
+{
+ down_write(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_maintenance_lock);
+
+/**
+ * i3c_bus_maintenance_unlock - Release the bus lock after a maintenance
+ * operation
+ * @bus: I3C bus to release the lock on
+ *
+ * Should be called when the bus maintenance operation is done. See
+ * i3c_bus_maintenance_lock() for more details on what these maintenance
+ * operations are.
+ */
+void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
+{
+ up_write(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
+
+/**
+ * i3c_bus_normaluse_lock - Lock the bus for a normal operation
+ * @bus: I3C bus to take the lock on
+ *
+ * This function takes the bus lock for any operation that is not a maintenance
+ * operation (see i3c_bus_maintenance_lock() for a non-exhaustive list of
+ * maintenance operations). Basically all communications with I3C devices are
+ * normal operations (HDR, SDR transfers or CCC commands that do not change bus
+ * state or I3C dynamic address).
+ *
+ * Note that this lock is not guaranteeing serialization of normal operations.
+ * In other words, transfer requests passed to the I3C master can be submitted
+ * in parallel and I3C master drivers have to use their own locking to make
+ * sure two different communications are not inter-mixed, or access to the
+ * output/input queue is not done while the engine is busy.
+ */
+void i3c_bus_normaluse_lock(struct i3c_bus *bus)
+{
+ down_read(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_normaluse_lock);
+
+/**
+ * i3c_bus_normaluse_unlock - Release the bus lock after a normal operation
+ * @bus: I3C bus to release the lock on
+ *
+ * Should be called when a normal operation is done. See
+ * i3c_bus_normaluse_lock() for more details on what these normal operations
+ * are.
+ */
+void i3c_bus_normaluse_unlock(struct i3c_bus *bus)
+{
+ up_read(&bus->lock);
+}
+EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock);
+
+static ssize_t bcr_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ ssize_t ret;
+
+ i3c_bus_normaluse_lock(i3cdev->bus);
+ ret = sprintf(buf, "%x\n", i3cdev->desc->info.bcr);
+ i3c_bus_normaluse_unlock(i3cdev->bus);
+
+ 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);
+ ssize_t ret;
+
+ i3c_bus_normaluse_lock(i3cdev->bus);
+ ret = sprintf(buf, "%x\n", i3cdev->desc->info.dcr);
+ i3c_bus_normaluse_unlock(i3cdev->bus);
+
+ 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);
+ ssize_t ret;
+
+ i3c_bus_normaluse_lock(i3cdev->bus);
+ ret = sprintf(buf, "%llx\n", i3cdev->desc->info.pid);
+ i3c_bus_normaluse_unlock(i3cdev->bus);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(pid);
+
+static ssize_t dynamic_address_show(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ ssize_t ret;
+
+ i3c_bus_normaluse_lock(i3cdev->bus);
+ ret = sprintf(buf, "%02x\n", i3cdev->desc->info.dyn_addr);
+ i3c_bus_normaluse_unlock(i3cdev->bus);
+
+ return ret;
+}
+static DEVICE_ATTR_RO(dynamic_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);
+ ssize_t offset = 0, ret;
+ unsigned long caps;
+ int mode;
+
+ i3c_bus_normaluse_lock(i3cdev->bus);
+ caps = i3cdev->desc->info.hdr_cap;
+ for_each_set_bit(mode, &caps, 8) {
+ if (mode >= ARRAY_SIZE(hdrcap_strings))
+ break;
+
+ if (!hdrcap_strings[mode])
+ continue;
+
+ ret = sprintf(buf + offset, offset ? " %s" : "%s",
+ hdrcap_strings[mode]);
+ if (ret < 0)
+ goto out;
+
+ offset += ret;
+ }
+
+ ret = sprintf(buf + offset, "\n");
+ if (ret < 0)
+ goto out;
+
+ ret = offset + ret;
+
+out:
+ i3c_bus_normaluse_unlock(i3cdev->bus);
+
+ 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_dynamic_address.attr,
+ &dev_attr_hdrcap.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(i3c_device);
+
+static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+ struct i3c_device_info devinfo;
+ u16 manuf, part, ext;
+
+ i3c_device_get_info(i3cdev, &devinfo);
+ manuf = I3C_PID_MANUF_ID(devinfo.pid);
+ part = I3C_PID_PART_ID(devinfo.pid);
+ ext = I3C_PID_EXTRA_INFO(devinfo.pid);
+
+ if (I3C_PID_RND_LOWER_32BITS(devinfo.pid))
+ return add_uevent_var(env, "MODALIAS=i3c:dcr%02Xmanuf%04X",
+ devinfo.dcr, manuf);
+
+ return add_uevent_var(env,
+ "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
+ devinfo.dcr, manuf, part, ext);
+}
+
+const struct device_type i3c_device_type = {
+ .groups = i3c_device_groups,
+ .uevent = i3c_device_uevent,
+};
+
+const struct device_type i3c_master_type = {
+ .groups = i3c_device_groups,
+};
+
+static const struct i3c_device_id *
+i3c_device_match_id(struct i3c_device *i3cdev,
+ const struct i3c_device_id *id_table)
+{
+ struct i3c_device_info devinfo;
+ const struct i3c_device_id *id;
+
+ i3c_device_get_info(i3cdev, &devinfo);
+
+ /*
+ * 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(devinfo.pid)) {
+ u16 manuf = I3C_PID_MANUF_ID(devinfo.pid);
+ u16 part = I3C_PID_PART_ID(devinfo.pid);
+ u16 ext_info = I3C_PID_EXTRA_INFO(devinfo.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 == devinfo.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);
+ int ret;
+
+ ret = driver->remove(i3cdev);
+ if (ret)
+ return ret;
+
+ i3c_device_free_ibi(i3cdev);
+
+ return ret;
+}
+
+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);
+}
+
+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_normaluse_lock(i3cbus);
+ 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_normaluse_unlock(i3cbus);
+
+ 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_normaluse_lock(i3cbus);
+ ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
+ i3cbus->cur_master->info.pid);
+ i3c_bus_normaluse_unlock(i3cbus);
+
+ 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_normaluse_lock(i3cbus);
+ ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
+ i3c_bus_normaluse_unlock(i3cbus);
+
+ 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_normaluse_lock(i3cbus);
+ ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
+ i3c_bus_normaluse_unlock(i3cbus);
+
+ 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 void i3c_busdev_release(struct device *dev)
+{
+ struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev);
+
+ WARN_ON(!list_empty(&bus->devs.i2c) || !list_empty(&bus->devs.i3c));
+
+ mutex_lock(&i3c_core_lock);
+ idr_remove(&i3c_bus_idr, bus->id);
+ mutex_unlock(&i3c_core_lock);
+
+ of_node_put(bus->dev.of_node);
+ kfree(bus);
+}
+
+static const struct device_type i3c_busdev_type = {
+ .groups = i3c_busdev_groups,
+};
+
+void i3c_bus_unref(struct i3c_bus *bus)
+{
+ put_device(&bus->dev);
+}
+
+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 = of_node_get(parent->of_node);
+ i3cbus->dev.bus = &i3c_bus_type;
+ i3cbus->dev.type = &i3c_busdev_type;
+ i3cbus->dev.release = i3c_busdev_release;
+
+ 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;
+ device_initialize(&i3cbus->dev);
+
+ 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_dev_desc *desc;
+
+ i3c_bus_for_each_i2cdev(i3cbus, desc) {
+ switch (desc->boardinfo->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_add(&i3cbus->dev);
+}
+
+static int __init i3c_init(void)
+{
+ return bus_register(&i3c_bus_type);
+}
+subsys_initcall(i3c_init);
+
+static void __exit i3c_exit(void)
+{
+ idr_destroy(&i3c_bus_idr);
+ bus_unregister(&i3c_bus_type);
+}
+module_exit(i3c_exit);
+
+MODULE_AUTHOR("Boris Brezillon <boris.brezillon@bootlin.com>");
+MODULE_DESCRIPTION("I3C core");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
new file mode 100644
index 000000000000..69cc040c3a1c
--- /dev/null
+++ b/drivers/i3c/device.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#include <linux/atomic.h>
+#include <linux/bug.h>
+#include <linux/completion.h>
+#include <linux/device.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+
+#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)
+{
+ int ret, i;
+
+ if (nxfers < 1)
+ return 0;
+
+ for (i = 0; i < nxfers; i++) {
+ if (!xfers[i].len || !xfers[i].data.in)
+ return -EINVAL;
+ }
+
+ i3c_bus_normaluse_lock(dev->bus);
+ ret = i3c_dev_do_priv_xfers_locked(dev->desc, xfers, nxfers);
+ i3c_bus_normaluse_unlock(dev->bus);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
+
+/**
+ * i3c_device_get_info() - get I3C device information
+ *
+ * @dev: device we want information on
+ * @info: the information object to fill in
+ *
+ * Retrieve I3C dev info.
+ */
+void i3c_device_get_info(struct i3c_device *dev,
+ struct i3c_device_info *info)
+{
+ if (!info)
+ return;
+
+ i3c_bus_normaluse_lock(dev->bus);
+ if (dev->desc)
+ *info = dev->desc->info;
+ i3c_bus_normaluse_unlock(dev->bus);
+}
+EXPORT_SYMBOL_GPL(i3c_device_get_info);
+
+/**
+ * i3c_device_disable_ibi() - Disable IBIs coming from a specific device
+ * @dev: device on which IBIs should be disabled
+ *
+ * This function disable IBIs coming from a specific device and wait for
+ * all pending IBIs to be processed.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_disable_ibi(struct i3c_device *dev)
+{
+ int ret = -ENOENT;
+
+ i3c_bus_normaluse_lock(dev->bus);
+ if (dev->desc) {
+ mutex_lock(&dev->desc->ibi_lock);
+ ret = i3c_dev_disable_ibi_locked(dev->desc);
+ mutex_unlock(&dev->desc->ibi_lock);
+ }
+ i3c_bus_normaluse_unlock(dev->bus);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_disable_ibi);
+
+/**
+ * i3c_device_enable_ibi() - Enable IBIs coming from a specific device
+ * @dev: device on which IBIs should be enabled
+ *
+ * This function enable IBIs coming from a specific device and wait for
+ * all pending IBIs to be processed. This should be called on a device
+ * where i3c_device_request_ibi() has succeeded.
+ *
+ * Note that IBIs from this device might be received before this function
+ * returns to its caller.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_enable_ibi(struct i3c_device *dev)
+{
+ int ret = -ENOENT;
+
+ i3c_bus_normaluse_lock(dev->bus);
+ if (dev->desc) {
+ mutex_lock(&dev->desc->ibi_lock);
+ ret = i3c_dev_enable_ibi_locked(dev->desc);
+ mutex_unlock(&dev->desc->ibi_lock);
+ }
+ i3c_bus_normaluse_unlock(dev->bus);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_enable_ibi);
+
+/**
+ * i3c_device_request_ibi() - Request an IBI
+ * @dev: device for which we should enable IBIs
+ * @req: setup requested for this IBI
+ *
+ * This function is responsible for pre-allocating all resources needed to
+ * process IBIs coming from @dev. When this function returns, the IBI is not
+ * enabled until i3c_device_enable_ibi() is called.
+ *
+ * Return: 0 in case of success, a negative error core otherwise.
+ */
+int i3c_device_request_ibi(struct i3c_device *dev,
+ const struct i3c_ibi_setup *req)
+{
+ int ret = -ENOENT;
+
+ if (!req->handler || !req->num_slots)
+ return -EINVAL;
+
+ i3c_bus_normaluse_lock(dev->bus);
+ if (dev->desc) {
+ mutex_lock(&dev->desc->ibi_lock);
+ ret = i3c_dev_request_ibi_locked(dev->desc, req);
+ mutex_unlock(&dev->desc->ibi_lock);
+ }
+ i3c_bus_normaluse_unlock(dev->bus);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_device_request_ibi);
+
+/**
+ * i3c_device_free_ibi() - Free all resources needed for IBI handling
+ * @dev: device on which you want to release IBI resources
+ *
+ * This function is responsible for de-allocating resources previously
+ * allocated by i3c_device_request_ibi(). It should be called after disabling
+ * IBIs with i3c_device_disable_ibi().
+ */
+void i3c_device_free_ibi(struct i3c_device *dev)
+{
+ i3c_bus_normaluse_lock(dev->bus);
+ if (dev->desc) {
+ mutex_lock(&dev->desc->ibi_lock);
+ i3c_dev_free_ibi_locked(dev->desc);
+ mutex_unlock(&dev->desc->ibi_lock);
+ }
+ i3c_bus_normaluse_unlock(dev->bus);
+}
+EXPORT_SYMBOL_GPL(i3c_device_free_ibi);
+
+/**
+ * i3cdev_to_dev() - Returns the device embedded in @i3cdev
+ * @i3cdev: I3C device
+ *
+ * Return: a pointer to a device object.
+ */
+struct device *i3cdev_to_dev(struct i3c_device *i3cdev)
+{
+ return &i3cdev->dev;
+}
+EXPORT_SYMBOL_GPL(i3cdev_to_dev);
+
+/**
+ * dev_to_i3cdev() - Returns the I3C device containing @dev
+ * @dev: device object
+ *
+ * Return: a pointer to an I3C device object.
+ */
+struct i3c_device *dev_to_i3cdev(struct device *dev)
+{
+ return container_of(dev, struct i3c_device, dev);
+}
+EXPORT_SYMBOL_GPL(dev_to_i3cdev);
+
+/**
+ * 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..ced88435466f
--- /dev/null
+++ b/drivers/i3c/internals.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#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_unref(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);
+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_dev_do_priv_xfers_locked(struct i3c_dev_desc *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers);
+int i3c_dev_disable_ibi_locked(struct i3c_dev_desc *dev);
+int i3c_dev_enable_ibi_locked(struct i3c_dev_desc *dev);
+int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req);
+void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev);
+#endif /* I3C_INTERNAL_H */
diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
new file mode 100644
index 000000000000..d04e9ff9c850
--- /dev/null
+++ b/drivers/i3c/master.c
@@ -0,0 +1,2058 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#include <linux/atomic.h>
+#include <linux/bug.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/workqueue.h>
+
+#include "internals.h"
+
+static struct i3c_master_controller *
+i2c_adapter_to_i3c_master(struct i2c_adapter *adap)
+{
+ return container_of(adap, struct i3c_master_controller, i2c);
+}
+
+static struct i2c_adapter *
+i3c_master_to_i2c_adapter(struct i3c_master_controller *master)
+{
+ return &master->i2c;
+}
+
+static void i3c_master_free_i2c_dev(struct i2c_dev_desc *dev)
+{
+ kfree(dev);
+}
+
+static struct i2c_dev_desc *
+i3c_master_alloc_i2c_dev(struct i3c_master_controller *master,
+ const struct i2c_dev_boardinfo *boardinfo)
+{
+ struct i2c_dev_desc *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return ERR_PTR(-ENOMEM);
+
+ dev->common.master = master;
+ dev->boardinfo = boardinfo;
+
+ return dev;
+}
+
+static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller *master,
+ struct i3c_ccc_cmd *cmd)
+{
+ int ret;
+
+ if (!cmd || !master)
+ return -EINVAL;
+
+ if (WARN_ON(master->init_done &&
+ !rwsem_is_locked(&master->bus->lock)))
+ return -EINVAL;
+
+ if (!master->ops->send_ccc_cmd)
+ return -ENOTSUPP;
+
+ if ((cmd->id & I3C_CCC_DIRECT) && (!cmd->dests || !cmd->ndests))
+ return -EINVAL;
+
+ if (master->ops->supports_ccc_cmd &&
+ !master->ops->supports_ccc_cmd(master, cmd))
+ return -ENOTSUPP;
+
+ ret = master->ops->send_ccc_cmd(master, cmd);
+ if (ret) {
+ if (cmd->err != I3C_ERROR_UNKNOWN)
+ return cmd->err;
+
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct i2c_dev_desc *
+i3c_master_find_i2c_dev_by_addr(const struct i3c_master_controller *master,
+ u16 addr)
+{
+ struct i2c_dev_desc *dev;
+
+ i3c_bus_for_each_i2cdev(master->bus, dev) {
+ if (dev->boardinfo->base.addr == addr)
+ return dev;
+ }
+
+ return NULL;
+}
+
+/**
+ * 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);
+
+static void i3c_device_release(struct device *dev)
+{
+ struct i3c_device *i3cdev = dev_to_i3cdev(dev);
+
+ WARN_ON(i3cdev->desc);
+
+ of_node_put(i3cdev->dev.of_node);
+ kfree(i3cdev);
+}
+
+static void i3c_master_free_i3c_dev(struct i3c_dev_desc *dev)
+{
+ kfree(dev);
+}
+
+static struct i3c_dev_desc *
+i3c_master_alloc_i3c_dev(struct i3c_master_controller *master,
+ const struct i3c_device_info *info)
+{
+ struct i3c_dev_desc *dev;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return ERR_PTR(-ENOMEM);
+
+ dev->common.master = master;
+ dev->info = *info;
+ mutex_init(&dev->ibi_lock);
+
+ return dev;
+}
+
+static 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;
+
+ 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);
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+
+/**
+ * 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 positive I3C error code if the error is
+ * one of the official Mx error codes, and 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 = { };
+
+ dest.addr = I3C_BROADCAST_ADDR;
+ cmd.dests = &dest;
+ cmd.ndests = 1;
+ cmd.rnw = false;
+ cmd.id = I3C_CCC_ENTDAA;
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+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 positive I3C error code if the error is
+ * one of the official Mx error codes, and a negative error code otherwise.
+ */
+int i3c_master_disec_locked(struct i3c_master_controller *master, u8 addr,
+ u8 evts)
+{
+ struct i3c_ccc_events 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_enec_locked() - send an ENEC 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
+ *
+ * Sends an ENEC CCC command to enable 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 positive I3C error code if the error is
+ * one of the official Mx error codes, and a negative error code otherwise.
+ */
+int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
+ u8 evts)
+{
+ struct i3c_ccc_events 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_ENEC(addr == I3C_BROADCAST_ADDR),
+ .dests = &dest,
+ .ndests = 1,
+ };
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+EXPORT_SYMBOL_GPL(i3c_master_enec_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 positive I3C error code if the error is
+ * one of the official Mx error codes, and 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_dev_desc *i3cdev;
+ struct i2c_dev_desc *i2cdev;
+ struct i3c_bus *bus;
+ bool send = false;
+ int ndevs = 0, ret;
+
+ if (!master)
+ return -EINVAL;
+
+ bus = i3c_master_get_bus(master);
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ ndevs++;
+
+ if (i3cdev == master->this)
+ continue;
+
+ 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 - 1) * sizeof(struct i3c_ccc_dev_desc));
+ defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
+ if (!defslvs)
+ return -ENOMEM;
+
+ dest.payload.data = defslvs;
+
+ defslvs->count = ndevs;
+ defslvs->master.bcr = master->this->info.bcr;
+ defslvs->master.dcr = master->this->info.dcr;
+ defslvs->master.dyn_addr = master->this->info.dyn_addr << 1;
+ defslvs->master.static_addr = I3C_BROADCAST_ADDR << 1;
+
+ desc = defslvs->slaves;
+ i3c_bus_for_each_i2cdev(bus, i2cdev) {
+ desc->lvr = i2cdev->boardinfo->lvr;
+ desc->static_addr = i2cdev->boardinfo->base.addr << 1;
+ desc++;
+ }
+
+ i3c_bus_for_each_i3cdev(bus, i3cdev) {
+ /* Skip the I3C dev representing this master. */
+ if (i3cdev == master->this)
+ continue;
+
+ desc->bcr = i3cdev->info.bcr;
+ desc->dcr = i3cdev->info.dcr;
+ desc->dyn_addr = i3cdev->info.dyn_addr << 1;
+ desc->static_addr = i3cdev->info.static_addr << 1;
+ 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_setdasa_locked(struct i3c_master_controller *master,
+ u8 static_addr, u8 dyn_addr)
+{
+ struct i3c_ccc_setda setda = {
+ .addr = dyn_addr << 1,
+ };
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = static_addr,
+ .payload.len = sizeof(setda),
+ .payload.data = &setda,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = false,
+ .id = I3C_CCC_SETDASA,
+ .dests = &dest,
+ .ndests = 1,
+ };
+
+ if (!dyn_addr || !static_addr)
+ return -EINVAL;
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+
+static int i3c_master_setnewda_locked(struct i3c_master_controller *master,
+ u8 oldaddr, u8 newaddr)
+{
+ struct i3c_ccc_setda setda = {
+ .addr = newaddr << 1,
+ };
+ struct i3c_ccc_cmd_dest dest = {
+ .addr = oldaddr,
+ .payload.len = sizeof(setda),
+ .payload.data = &setda,
+ };
+ struct i3c_ccc_cmd cmd = {
+ .rnw = false,
+ .id = I3C_CCC_SETNEWDA,
+ .dests = &dest,
+ .ndests = 1,
+ };
+
+ if (!oldaddr || !newaddr)
+ return -EINVAL;
+
+ return i3c_master_send_ccc_cmd_locked(master, &cmd);
+}
+
+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;
+
+ /*
+ * When the device does not have IBI payload GETMRL only returns 2
+ * bytes of data.
+ */
+ if (!(info->bcr & I3C_BCR_IBI_PAYLOAD))
+ dest.payload.len -= 1;
+
+ 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_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ enum i3c_addr_slot_status slot_status;
+ int ret;
+
+ if (!dev->info.dyn_addr)
+ return -EINVAL;
+
+ slot_status = i3c_bus_get_addr_slot_status(master->bus,
+ dev->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, &dev->info);
+ if (ret)
+ return ret;
+
+ ret = i3c_master_getbcr_locked(master, &dev->info);
+ if (ret)
+ return ret;
+
+ ret = i3c_master_getdcr_locked(master, &dev->info);
+ if (ret)
+ return ret;
+
+ if (dev->info.bcr & I3C_BCR_MAX_DATA_SPEED_LIM) {
+ ret = i3c_master_getmxds_locked(master, &dev->info);
+ if (ret)
+ return ret;
+ }
+
+ if (dev->info.bcr & I3C_BCR_IBI_PAYLOAD)
+ dev->info.max_ibi_len = 1;
+
+ i3c_master_getmrl_locked(master, &dev->info);
+ i3c_master_getmwl_locked(master, &dev->info);
+
+ if (dev->info.bcr & I3C_BCR_HDR_CAP) {
+ ret = i3c_master_gethdrcap_locked(master, &dev->info);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+static void i3c_master_put_i3c_addrs(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+
+ if (dev->info.static_addr)
+ i3c_bus_set_addr_slot_status(master->bus,
+ dev->info.static_addr,
+ I3C_ADDR_SLOT_FREE);
+
+ if (dev->info.dyn_addr)
+ i3c_bus_set_addr_slot_status(master->bus, dev->info.dyn_addr,
+ I3C_ADDR_SLOT_FREE);
+
+ if (dev->boardinfo && dev->boardinfo->init_dyn_addr)
+ i3c_bus_set_addr_slot_status(master->bus, dev->info.dyn_addr,
+ I3C_ADDR_SLOT_FREE);
+}
+
+static int i3c_master_get_i3c_addrs(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ enum i3c_addr_slot_status status;
+
+ if (!dev->info.static_addr && !dev->info.dyn_addr)
+ return 0;
+
+ if (dev->info.static_addr) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ dev->info.static_addr);
+ if (status != I3C_ADDR_SLOT_FREE)
+ return -EBUSY;
+
+ i3c_bus_set_addr_slot_status(master->bus,
+ dev->info.static_addr,
+ I3C_ADDR_SLOT_I3C_DEV);
+ }
+
+ /*
+ * ->init_dyn_addr should have been reserved before that, so, if we're
+ * trying to apply a pre-reserved dynamic address, we should not try
+ * to reserve the address slot a second time.
+ */
+ if (dev->info.dyn_addr &&
+ (!dev->boardinfo ||
+ dev->boardinfo->init_dyn_addr != dev->info.dyn_addr)) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ dev->info.dyn_addr);
+ if (status != I3C_ADDR_SLOT_FREE)
+ goto err_release_static_addr;
+
+ i3c_bus_set_addr_slot_status(master->bus, dev->info.dyn_addr,
+ I3C_ADDR_SLOT_I3C_DEV);
+ }
+
+ return 0;
+
+err_release_static_addr:
+ if (dev->info.static_addr)
+ i3c_bus_set_addr_slot_status(master->bus,
+ dev->info.static_addr,
+ I3C_ADDR_SLOT_FREE);
+
+ return -EBUSY;
+}
+
+static int i3c_master_attach_i3c_dev(struct i3c_master_controller *master,
+ struct i3c_dev_desc *dev)
+{
+ int ret;
+
+ /*
+ * We don't attach devices to the controller until they are
+ * addressable on the bus.
+ */
+ if (!dev->info.static_addr && !dev->info.dyn_addr)
+ return 0;
+
+ ret = i3c_master_get_i3c_addrs(dev);
+ if (ret)
+ return ret;
+
+ /* Do not attach the master device itself. */
+ if (master->this != dev && master->ops->attach_i3c_dev) {
+ ret = master->ops->attach_i3c_dev(dev);
+ if (ret) {
+ i3c_master_put_i3c_addrs(dev);
+ return ret;
+ }
+ }
+
+ list_add_tail(&dev->common.node, &master->bus->devs.i3c);
+
+ return 0;
+}
+
+static int i3c_master_reattach_i3c_dev(struct i3c_dev_desc *dev,
+ u8 old_dyn_addr)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ enum i3c_addr_slot_status status;
+ int ret;
+
+ if (dev->info.dyn_addr != old_dyn_addr) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ dev->info.dyn_addr);
+ if (status != I3C_ADDR_SLOT_FREE)
+ return -EBUSY;
+ i3c_bus_set_addr_slot_status(master->bus,
+ dev->info.dyn_addr,
+ I3C_ADDR_SLOT_I3C_DEV);
+ }
+
+ if (master->ops->reattach_i3c_dev) {
+ ret = master->ops->reattach_i3c_dev(dev, old_dyn_addr);
+ if (ret) {
+ i3c_master_put_i3c_addrs(dev);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static void i3c_master_detach_i3c_dev(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+
+ /* Do not detach the master device itself. */
+ if (master->this != dev && master->ops->detach_i3c_dev)
+ master->ops->detach_i3c_dev(dev);
+
+ i3c_master_put_i3c_addrs(dev);
+ list_del(&dev->common.node);
+}
+
+static int i3c_master_attach_i2c_dev(struct i3c_master_controller *master,
+ struct i2c_dev_desc *dev)
+{
+ int ret;
+
+ if (master->ops->attach_i2c_dev) {
+ ret = master->ops->attach_i2c_dev(dev);
+ if (ret)
+ return ret;
+ }
+
+ list_add_tail(&dev->common.node, &master->bus->devs.i2c);
+
+ return 0;
+}
+
+static void i3c_master_detach_i2c_dev(struct i2c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i2c_dev_get_master(dev);
+
+ list_del(&dev->common.node);
+
+ if (master->ops->detach_i2c_dev)
+ master->ops->detach_i2c_dev(dev);
+}
+
+static void i3c_master_pre_assign_dyn_addr(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ struct i3c_device_info info;
+ int ret;
+
+ if (!dev->boardinfo || !dev->boardinfo->init_dyn_addr ||
+ !dev->boardinfo->static_addr)
+ return;
+
+ ret = i3c_master_setdasa_locked(master, dev->info.static_addr,
+ dev->boardinfo->init_dyn_addr);
+ if (ret)
+ return;
+
+ dev->info.dyn_addr = dev->boardinfo->init_dyn_addr;
+ ret = i3c_master_reattach_i3c_dev(dev, 0);
+ if (ret)
+ return;
+
+ ret = i3c_master_retrieve_dev_info(dev);
+ if (ret)
+ goto err_rstdaa;
+
+ dev->info = info;
+
+ return;
+
+err_rstdaa:
+ i3c_master_rstdaa_locked(master, dev->boardinfo->init_dyn_addr);
+}
+
+static void
+i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
+{
+ struct i3c_dev_desc *desc;
+ int ret;
+
+ if (!master->init_done)
+ return;
+
+ i3c_bus_for_each_i3cdev(master->bus, desc) {
+ if (desc->dev || !desc->info.dyn_addr)
+ continue;
+
+ desc->dev = kzalloc(sizeof(*desc->dev), GFP_KERNEL);
+ if (!desc->dev)
+ continue;
+
+ desc->dev->bus = master->bus;
+ desc->dev->desc = desc;
+ desc->dev->dev.parent = &master->bus->dev;
+ if (desc == master->this)
+ desc->dev->dev.type = &i3c_master_type;
+ else
+ desc->dev->dev.type = &i3c_device_type;
+ desc->dev->dev.bus = &i3c_bus_type;
+ desc->dev->dev.release = i3c_device_release;
+ dev_set_name(&desc->dev->dev, "%d-%llx", master->bus->id,
+ desc->info.pid);
+
+ if (desc->boardinfo)
+ desc->dev->dev.of_node = desc->boardinfo->of_node;
+
+ pr_info("%s:%i\n", __func__, __LINE__);
+ if (ret)
+ dev_err(master->parent,
+ "Failed to add I3C device (err = %d)\n", ret);
+ }
+}
+
+/**
+ * i3c_master_do_daa() - do a DAA (Dynamic Address Assignment)
+ * @master: master doing the DAA
+ *
+ * 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_dev_set_master_data().
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: a 0 in case of success, an negative error code otherwise.
+ */
+int i3c_master_do_daa(struct i3c_master_controller *master)
+{
+ int ret;
+
+ i3c_bus_maintenance_lock(master->bus);
+ ret = master->ops->do_daa(master);
+ i3c_bus_maintenance_unlock(master->bus);
+
+ if (ret)
+ return ret;
+
+ i3c_bus_normaluse_lock(master->bus);
+ i3c_master_register_new_i3c_devs(master);
+ i3c_bus_normaluse_unlock(master->bus);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_do_daa);
+
+/**
+ * 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 called from
+ * &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 maintenance 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)
+{
+ struct i3c_dev_desc *i3cdev;
+ int ret;
+
+ 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;
+
+ if (master->this)
+ return -EINVAL;
+
+ i3cdev = i3c_master_alloc_i3c_dev(master, info);
+ if (IS_ERR(i3cdev))
+ return PTR_ERR(i3cdev);
+
+ master->this = i3cdev;
+ master->bus->cur_master = master->this;
+
+ ret = i3c_master_attach_i3c_dev(master, i3cdev);
+ if (ret)
+ goto err_free_dev;
+
+ return 0;
+
+err_free_dev:
+ i3c_master_free_i3c_dev(i3cdev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_set_info);
+
+static void i3c_master_detach_free_devs(struct i3c_master_controller *master)
+{
+ struct i3c_dev_desc *i3cdev, *i3ctmp;
+ struct i2c_dev_desc *i2cdev, *i2ctmp;
+
+ list_for_each_entry_safe(i3cdev, i3ctmp, &master->bus->devs.i3c,
+ common.node) {
+ i3c_master_detach_i3c_dev(i3cdev);
+
+ if (i3cdev->boardinfo && i3cdev->boardinfo->init_dyn_addr)
+ i3c_bus_set_addr_slot_status(master->bus,
+ i3cdev->boardinfo->init_dyn_addr,
+ I3C_ADDR_SLOT_FREE);
+
+ i3c_master_free_i3c_dev(i3cdev);
+ }
+
+ list_for_each_entry_safe(i2cdev, i2ctmp, &master->bus->devs.i2c,
+ common.node) {
+ i3c_master_detach_i2c_dev(i2cdev);
+ i3c_bus_set_addr_slot_status(master->bus,
+ i2cdev->boardinfo->base.addr,
+ I3C_ADDR_SLOT_FREE);
+ i3c_master_free_i2c_dev(i2cdev);
+ }
+}
+
+/**
+ * i3c_master_bus_init() - initialize an I3C bus
+ * @master: main master initializing the bus
+ *
+ * This function is following all initialisation steps described in the I3C
+ * specification:
+ *
+ * 1. Attach I2C and statically defined I3C devs to the master so that the
+ * master can fill its internal device table appropriately
+ *
+ * 2. Call &i3c_master_controller_ops->bus_init() method to initialize
+ * the master controller. That's usually where the bus mode is selected
+ * (pure bus or mixed fast/slow bus)
+ *
+ * 3. Instruct all devices on the bus to drop their dynamic address. This is
+ * particularly important when the bus was previously configured by someone
+ * else (for example the bootloader)
+ *
+ * 4. Disable all slave events.
+ *
+ * 5. Pre-assign dynamic addresses requested by the FW with SETDASA for I3C
+ * devices that have a static address
+ *
+ * 6. Do a DAA (Dynamic Address Assignment) to assign dynamic addresses to all
+ * remaining I3C devices
+ *
+ * Once this is done, all I3C and I2C devices should be usable.
+ *
+ * Return: a 0 in case of success, an negative error code otherwise.
+ */
+static int i3c_master_bus_init(struct i3c_master_controller *master)
+{
+ enum i3c_addr_slot_status status;
+ struct i2c_dev_boardinfo *i2cboardinfo;
+ struct i3c_dev_boardinfo *i3cboardinfo;
+ struct i3c_dev_desc *i3cdev;
+ struct i2c_dev_desc *i2cdev;
+ int ret;
+
+ /*
+ * First attach all devices with static definitions provided by the
+ * FW.
+ */
+ list_for_each_entry(i2cboardinfo, &master->boardinfo.i2c, node) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ i2cboardinfo->base.addr);
+ if (status != I3C_ADDR_SLOT_FREE) {
+ ret = -EBUSY;
+ goto err_detach_devs;
+ }
+
+ i3c_bus_set_addr_slot_status(master->bus,
+ i2cboardinfo->base.addr,
+ I3C_ADDR_SLOT_I2C_DEV);
+
+ i2cdev = i3c_master_alloc_i2c_dev(master, i2cboardinfo);
+ if (IS_ERR(i2cdev)) {
+ ret = PTR_ERR(i2cdev);
+ goto err_detach_devs;
+ }
+
+ ret = i3c_master_attach_i2c_dev(master, i2cdev);
+ if (ret) {
+ i3c_master_free_i2c_dev(i2cdev);
+ goto err_detach_devs;
+ }
+ }
+ list_for_each_entry(i3cboardinfo, &master->boardinfo.i3c, node) {
+ struct i3c_device_info info = {
+ .static_addr = i3cboardinfo->static_addr,
+ };
+
+ if (i3cboardinfo->init_dyn_addr) {
+ status = i3c_bus_get_addr_slot_status(master->bus,
+ i3cboardinfo->init_dyn_addr);
+ if (status != I3C_ADDR_SLOT_FREE) {
+ ret = -EBUSY;
+ goto err_detach_devs;
+ }
+ }
+
+ i3cdev = i3c_master_alloc_i3c_dev(master, &info);
+ if (IS_ERR(i3cdev)) {
+ ret = PTR_ERR(i3cdev);
+ goto err_detach_devs;
+ }
+
+ i3cdev->boardinfo = i3cboardinfo;
+
+ ret = i3c_master_attach_i3c_dev(master, i3cdev);
+ if (ret) {
+ i3c_master_free_i3c_dev(i3cdev);
+ goto err_detach_devs;
+ }
+ }
+
+ /*
+ * Now execute the controller specific ->bus_init() routine, which
+ * might configure its internal logic to match the bus limitations.
+ */
+ ret = master->ops->bus_init(master);
+ if (ret)
+ goto err_detach_devs;
+
+ /*
+ * The master device should have been instantiated in ->bus_init(),
+ * complain if this was not the case.
+ */
+ if (!master->this) {
+ dev_err(master->parent,
+ "master_set_info() was not called in ->bus_init()\n");
+ ret = -EINVAL;
+ goto err_bus_cleanup;
+ }
+
+ /*
+ * Reset all dynamic address that may have been assigned before
+ * (assigned by the bootloader for example).
+ */
+ ret = i3c_master_rstdaa_locked(master, I3C_BROADCAST_ADDR);
+ if (ret && ret != I3C_ERROR_M2)
+ goto err_bus_cleanup;
+
+ /* Disable all slave events before starting DAA. */
+ ret = i3c_master_disec_locked(master, I3C_BROADCAST_ADDR,
+ I3C_CCC_EVENT_SIR | I3C_CCC_EVENT_MR |
+ I3C_CCC_EVENT_HJ);
+ if (ret && ret != I3C_ERROR_M2)
+ goto err_bus_cleanup;
+
+ /*
+ * Pre-assign dynamic address and retrieve device information if
+ * needed.
+ */
+ i3c_bus_for_each_i3cdev(master->bus, i3cdev)
+ i3c_master_pre_assign_dyn_addr(i3cdev);
+
+ ret = i3c_master_do_daa(master);
+ if (ret)
+ goto err_rstdaa;
+
+ return 0;
+
+err_rstdaa:
+ i3c_master_rstdaa_locked(master, I3C_BROADCAST_ADDR);
+
+err_bus_cleanup:
+ if (master->ops->bus_cleanup)
+ master->ops->bus_cleanup(master);
+
+err_detach_devs:
+ i3c_master_detach_free_devs(master);
+
+ return ret;
+}
+
+static void i3c_master_bus_cleanup(struct i3c_master_controller *master)
+{
+ if (master->ops->bus_cleanup)
+ master->ops->bus_cleanup(master);
+
+ i3c_master_detach_free_devs(master);
+}
+
+static struct i3c_dev_desc *
+i3c_master_search_i3c_dev_duplicate(struct i3c_dev_desc *refdev)
+{
+ struct i3c_master_controller *master = refdev->common.master;
+ struct i3c_dev_desc *i3cdev;
+
+ i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+ if (i3cdev != refdev && i3cdev->info.pid == refdev->info.pid)
+ return i3cdev;
+ }
+
+ return NULL;
+}
+
+/**
+ * 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_dev_set_master_data().
+ *
+ * This function must be called with the bus lock held in write mode.
+ *
+ * Return: a 0 in case of success, an negative error code otherwise.
+ */
+int i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master,
+ u8 addr)
+{
+ struct i3c_device_info info = { .dyn_addr = addr };
+ struct i3c_dev_desc *newdev, *olddev;
+ u8 old_dyn_addr = addr, expected_dyn_addr;
+ struct i3c_ibi_setup ibireq = { };
+ bool enable_ibi = false;
+ int ret;
+
+ if (!master)
+ return -EINVAL;
+
+ newdev = i3c_master_alloc_i3c_dev(master, &info);
+ if (IS_ERR(newdev))
+ return PTR_ERR(newdev);
+
+ ret = i3c_master_attach_i3c_dev(master, newdev);
+ if (ret) {
+ ret = PTR_ERR(newdev);
+ goto err_free_dev;
+ }
+
+ ret = i3c_master_retrieve_dev_info(newdev);
+ if (ret)
+ goto err_free_dev;
+
+ olddev = i3c_master_search_i3c_dev_duplicate(newdev);
+ if (olddev) {
+ newdev->boardinfo = olddev->boardinfo;
+ newdev->info.static_addr = olddev->info.static_addr;
+ newdev->dev = olddev->dev;
+ if (newdev->dev)
+ newdev->dev->desc = newdev;
+
+ /*
+ * We need to restore the IBI state too, so let's save the
+ * IBI information and try to restore them after olddev has
+ * been detached+released and its IBI has been stopped and
+ * the associated resources have been freed.
+ */
+ mutex_lock(&olddev->ibi_lock);
+ if (olddev->ibi) {
+ ibireq.handler = olddev->ibi->handler;
+ ibireq.max_payload_len = olddev->ibi->max_payload_len;
+ ibireq.num_slots = olddev->ibi->num_slots;
+
+ if (olddev->ibi->enabled) {
+ enable_ibi = true;
+ i3c_dev_disable_ibi_locked(olddev);
+ }
+
+ i3c_dev_free_ibi_locked(olddev);
+ }
+ mutex_unlock(&olddev->ibi_lock);
+
+ old_dyn_addr = olddev->info.dyn_addr;
+
+ i3c_master_detach_i3c_dev(olddev);
+ i3c_master_free_i3c_dev(olddev);
+ }
+
+ ret = i3c_master_reattach_i3c_dev(newdev, old_dyn_addr);
+ if (ret)
+ goto err_detach_dev;
+
+ /*
+ * Depending on our previous state, the expected dynamic address might
+ * differ:
+ * - if the device already had a dynamic address assigned, let's try to
+ * re-apply this one
+ * - if the device did not have a dynamic address and the firmware
+ * requested a specific address, pick this one
+ * - in any other case, keep the address automatically assigned by the
+ * master
+ */
+ if (old_dyn_addr && old_dyn_addr != newdev->info.dyn_addr)
+ expected_dyn_addr = old_dyn_addr;
+ else if (newdev->boardinfo && newdev->boardinfo->init_dyn_addr)
+ expected_dyn_addr = newdev->boardinfo->init_dyn_addr;
+ else
+ expected_dyn_addr = newdev->info.dyn_addr;
+
+ if (newdev->info.dyn_addr != expected_dyn_addr) {
+ /*
+ * Try to apply the expected dynamic address. If it fails, keep
+ * the address assigned by the master.
+ */
+ ret = i3c_master_setnewda_locked(master,
+ newdev->info.dyn_addr,
+ expected_dyn_addr);
+ if (!ret) {
+ old_dyn_addr = newdev->info.dyn_addr;
+ newdev->info.dyn_addr = expected_dyn_addr;
+ i3c_master_reattach_i3c_dev(newdev, old_dyn_addr);
+ } else {
+ dev_err(master->parent,
+ "Failed to assign reserved/old address to device %d%llx",
+ master->bus->id, newdev->info.pid);
+ }
+ }
+
+ /*
+ * Now is time to try to restore the IBI setup. If we're lucky,
+ * everything works as before, otherwise, all we can do is complain.
+ * FIXME: maybe we should add callback to inform the driver that it
+ * should request the IBI again instead of trying to hide that from
+ * him.
+ */
+ if (ibireq.handler) {
+ mutex_lock(&newdev->ibi_lock);
+ ret = i3c_dev_request_ibi_locked(newdev, &ibireq);
+ if (ret) {
+ dev_err(master->parent,
+ "Failed to request IBI on device %d-%llx",
+ master->bus->id, newdev->info.pid);
+ } else if (enable_ibi) {
+ ret = i3c_dev_enable_ibi_locked(newdev);
+ if (ret)
+ dev_err(master->parent,
+ "Failed to re-enable IBI on device %d-%llx",
+ master->bus->id, newdev->info.pid);
+ }
+ mutex_lock(&newdev->ibi_lock);
+ }
+
+ return 0;
+
+err_detach_dev:
+ if (newdev->dev && newdev->dev->desc)
+ newdev->dev->desc = NULL;
+
+ i3c_master_detach_i3c_dev(newdev);
+
+err_free_dev:
+ i3c_master_free_i3c_dev(newdev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
+
+#define OF_I3C_REG1_IS_I2C_DEV BIT(31)
+
+static int
+of_i3c_master_add_i2c_boardinfo(struct i3c_master_controller *master,
+ struct device_node *node, u32 *reg)
+{
+ struct i2c_dev_boardinfo *boardinfo;
+ struct device *dev = master->parent;
+ /* LVR is encoded in the lowest byte of reg[1]. */
+ int ret;
+
+ boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
+ if (!boardinfo)
+ return -ENOMEM;
+
+ ret = of_i2c_get_board_info(dev, node, &boardinfo->base);
+ if (ret)
+ return ret;
+
+ boardinfo->lvr = reg[1];
+
+ if (boardinfo->lvr & I3C_LVR_I2C_FM_MODE)
+ master->bus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
+
+ list_add_tail(&boardinfo->node, &master->boardinfo.i2c);
+ of_node_get(node);
+
+ return 0;
+}
+
+static int
+of_i3c_master_add_i3c_boardinfo(struct i3c_master_controller *master,
+ struct device_node *node, u32 *reg)
+{
+ struct i3c_dev_boardinfo *boardinfo;
+ struct device *dev = master->parent;
+ struct i3c_device_info info = { };
+ enum i3c_addr_slot_status addrstatus;
+ u32 init_dyn_addr = 0;
+
+ boardinfo = devm_kzalloc(dev, sizeof(*boardinfo), GFP_KERNEL);
+ if (!boardinfo)
+ return -ENOMEM;
+
+ if (reg[0]) {
+ if (reg[0] > I3C_MAX_ADDR)
+ return -EINVAL;
+
+ addrstatus = i3c_bus_get_addr_slot_status(master->bus, reg[0]);
+ if (addrstatus != I3C_ADDR_SLOT_FREE)
+ return -EINVAL;
+ }
+
+ boardinfo->static_addr = reg[0];
+
+ if (!of_property_read_u32(node, "assigned-address", &init_dyn_addr)) {
+ if (init_dyn_addr > I3C_MAX_ADDR)
+ return -EINVAL;
+
+ addrstatus = i3c_bus_get_addr_slot_status(master->bus,
+ init_dyn_addr);
+ if (addrstatus != I3C_ADDR_SLOT_FREE)
+ return -EINVAL;
+ }
+
+ boardinfo->pid = ((u64)reg[1] << 32) | reg[2];
+
+ if ((info.pid & GENMASK_ULL(63, 48)) ||
+ I3C_PID_RND_LOWER_32BITS(info.pid))
+ return -EINVAL;
+
+ boardinfo->init_dyn_addr = init_dyn_addr;
+ boardinfo->of_node = of_node_get(node);
+ list_add_tail(&boardinfo->node, &master->boardinfo.i3c);
+
+ return 0;
+}
+
+static int of_i3c_master_add_dev(struct i3c_master_controller *master,
+ struct device_node *node)
+{
+ u32 reg[3];
+ int ret;
+
+ if (!master || !node)
+ return -EINVAL;
+
+ ret = of_property_read_u32_array(node, "reg", reg, ARRAY_SIZE(reg));
+ if (ret)
+ return ret;
+
+ if (reg[1] & OF_I3C_REG1_IS_I2C_DEV)
+ ret = of_i3c_master_add_i2c_boardinfo(master, node, reg);
+ else
+ ret = of_i3c_master_add_i3c_boardinfo(master, node, reg);
+
+ return ret;
+}
+
+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)
+ return ret;
+ }
+
+ /*
+ * 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-hz", &val))
+ master->bus->scl_rate.i2c = val;
+
+ if (!of_property_read_u32(i3cbus_np, "i3c-scl-hz", &val))
+ master->bus->scl_rate.i3c = val;
+
+ return 0;
+}
+
+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);
+ struct i2c_dev_desc *dev;
+ int i, ret;
+ u16 addr;
+
+ if (!xfers || !master || nxfers <= 0)
+ return -EINVAL;
+
+ if (!master->ops->i2c_xfers)
+ return -ENOTSUPP;
+
+ /* Doing transfers to different devices is not supported. */
+ addr = xfers[0].addr;
+ for (i = 1; i < nxfers; i++) {
+ if (addr != xfers[i].addr)
+ return -ENOTSUPP;
+ }
+
+ i3c_bus_normaluse_lock(master->bus);
+ dev = i3c_master_find_i2c_dev_by_addr(master, addr);
+ if (!dev)
+ ret = -ENOENT;
+ else
+ ret = master->ops->i2c_xfers(dev, xfers, nxfers);
+ i3c_bus_normaluse_unlock(master->bus);
+
+ return ret ? ret : nxfers;
+}
+
+static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
+{
+ struct i3c_master_controller *master = i2c_adapter_to_i3c_master(adap);
+
+ return master->ops->i2c_funcs(master);
+}
+
+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_dev_desc *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->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->dev = i2c_new_device(adap, &i2cdev->boardinfo->base);
+
+ return 0;
+}
+
+static void i3c_master_i2c_adapter_cleanup(struct i3c_master_controller *master)
+{
+ struct i2c_dev_desc *i2cdev;
+
+ i2c_del_adapter(&master->i2c);
+
+ i3c_bus_for_each_i2cdev(master->bus, i2cdev)
+ i2cdev->dev = NULL;
+}
+
+static void i3c_master_unregister_i3c_devs(struct i3c_master_controller *master)
+{
+ struct i3c_dev_desc *i3cdev;
+
+ i3c_bus_for_each_i3cdev(master->bus, i3cdev) {
+ if (!i3cdev->dev)
+ continue;
+
+ i3cdev->dev->desc = NULL;
+ if (device_is_registered(&i3cdev->dev->dev))
+ device_unregister(&i3cdev->dev->dev);
+ else
+ put_device(&i3cdev->dev->dev);
+ i3cdev->dev = NULL;
+ }
+}
+
+/**
+ * i3c_master_queue_ibi() - Queue an IBI
+ * @dev: the device this IBI is coming from
+ * @slot: the IBI slot used to store the payload
+ *
+ * Queue an IBI to the controller workqueue. The IBI handler attached to
+ * the dev will be called from a workqueue context.
+ */
+void i3c_master_queue_ibi(struct i3c_dev_desc *dev, struct i3c_ibi_slot *slot)
+{
+ atomic_inc(&dev->ibi->pending_ibis);
+ queue_work(dev->common.master->wq, &slot->work);
+}
+EXPORT_SYMBOL_GPL(i3c_master_queue_ibi);
+
+static void i3c_master_handle_ibi(struct work_struct *work)
+{
+ struct i3c_ibi_slot *slot = container_of(work, struct i3c_ibi_slot,
+ work);
+ struct i3c_dev_desc *dev = slot->dev;
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ struct i3c_ibi_payload payload;
+
+ payload.data = slot->data;
+ payload.len = slot->len;
+
+ if (dev->dev)
+ dev->ibi->handler(dev->dev, &payload);
+
+ master->ops->recycle_ibi_slot(dev, slot);
+ if (atomic_dec_and_test(&dev->ibi->pending_ibis))
+ complete(&dev->ibi->all_ibis_handled);
+}
+
+static void i3c_master_init_ibi_slot(struct i3c_dev_desc *dev,
+ struct i3c_ibi_slot *slot)
+{
+ slot->dev = dev;
+ INIT_WORK(&slot->work, i3c_master_handle_ibi);
+}
+
+struct i3c_generic_ibi_slot {
+ struct list_head node;
+ struct i3c_ibi_slot base;
+};
+
+struct i3c_generic_ibi_pool {
+ spinlock_t lock;
+ unsigned int num_slots;
+ struct i3c_generic_ibi_slot *slots;
+ void *payload_buf;
+ struct list_head free_slots;
+ struct list_head pending;
+};
+
+/**
+ * i3c_generic_ibi_free_pool() - Free a generic IBI pool
+ * @pool: the IBI pool to free
+ *
+ * Free all IBI slots allated by a generic IBI pool.
+ */
+void i3c_generic_ibi_free_pool(struct i3c_generic_ibi_pool *pool)
+{
+ struct i3c_generic_ibi_slot *slot;
+ unsigned int nslots = 0;
+
+ while (!list_empty(&pool->free_slots)) {
+ slot = list_first_entry(&pool->free_slots,
+ struct i3c_generic_ibi_slot, node);
+ list_del(&slot->node);
+ nslots++;
+ }
+
+ /*
+ * If the number of freed slots is not equal to the number of allocated
+ * slots we have a leak somewhere.
+ */
+ WARN_ON(nslots != pool->num_slots);
+
+ kfree(pool->payload_buf);
+ kfree(pool->slots);
+ kfree(pool);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_free_pool);
+
+/**
+ * i3c_generic_ibi_alloc_pool() - Create a generic IBI pool
+ * @dev: the device this pool will be used for
+ * @req: IBI setup request describing what the device driver expects
+ *
+ * Create a generic IBI pool based on the information provided in @req.
+ *
+ * Return: a valid IBI pool in case of success, an ERR_PTR() otherwise.
+ */
+struct i3c_generic_ibi_pool *
+i3c_generic_ibi_alloc_pool(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req)
+{
+ struct i3c_generic_ibi_pool *pool;
+ struct i3c_generic_ibi_slot *slot;
+ unsigned int i;
+ int ret;
+
+ pool = kzalloc(sizeof(*pool), GFP_KERNEL);
+ if (!pool)
+ return ERR_PTR(-ENOMEM);
+
+ spin_lock_init(&pool->lock);
+ INIT_LIST_HEAD(&pool->free_slots);
+ INIT_LIST_HEAD(&pool->pending);
+
+ pool->slots = kcalloc(req->num_slots, sizeof(*slot), GFP_KERNEL);
+ if (!pool->slots) {
+ ret = -ENOMEM;
+ goto err_free_pool;
+ }
+
+ if (req->max_payload_len) {
+ pool->payload_buf = kcalloc(req->num_slots,
+ req->max_payload_len, GFP_KERNEL);
+ if (!pool->payload_buf) {
+ ret = -ENOMEM;
+ goto err_free_pool;
+ }
+ }
+
+ for (i = 0; i < req->num_slots; i++) {
+ slot = &pool->slots[i];
+ i3c_master_init_ibi_slot(dev, &slot->base);
+
+ if (req->max_payload_len)
+ slot->base.data = pool->payload_buf +
+ (i * req->max_payload_len);
+
+ list_add_tail(&slot->node, &pool->free_slots);
+ pool->num_slots++;
+ }
+
+ return pool;
+
+err_free_pool:
+ i3c_generic_ibi_free_pool(pool);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_alloc_pool);
+
+/**
+ * i3c_generic_ibi_get_free_slot() - Get a free slot from a generic IBI pool
+ * @pool: the pool to query an IBI slot on
+ *
+ * Search for a free slot in a generic IBI pool.
+ * The slot should be returned to the pool using i3c_generic_ibi_recycle_slot()
+ * when it's no longer needed.
+ *
+ * Return: a pointer to a free slot, or NULL if there's no free slot available.
+ */
+struct i3c_ibi_slot *
+i3c_generic_ibi_get_free_slot(struct i3c_generic_ibi_pool *pool)
+{
+ struct i3c_generic_ibi_slot *slot;
+ unsigned long flags;
+
+ spin_lock_irqsave(&pool->lock, flags);
+ slot = list_first_entry_or_null(&pool->free_slots,
+ struct i3c_generic_ibi_slot, node);
+ if (slot)
+ list_del(&slot->node);
+ spin_unlock_irqrestore(&pool->lock, flags);
+
+ return slot ? &slot->base : NULL;
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_get_free_slot);
+
+/**
+ * i3c_generic_ibi_recycle_slot() - Return a slot to a generic IBI pool
+ * @pool: the pool to return the IBI slot to
+ * @s: IBI slot to recycle
+ *
+ * Add an IBI slot back to its generic IBI pool. Should be called from the
+ * master driver struct_master_controller_ops->recycle_ibi() method.
+ */
+void i3c_generic_ibi_recycle_slot(struct i3c_generic_ibi_pool *pool,
+ struct i3c_ibi_slot *s)
+{
+ struct i3c_generic_ibi_slot *slot;
+ unsigned long flags;
+
+ if (!s)
+ return;
+
+ slot = container_of(s, struct i3c_generic_ibi_slot, base);
+ spin_lock_irqsave(&pool->lock, flags);
+ list_add_tail(&slot->node, &pool->free_slots);
+ spin_unlock_irqrestore(&pool->lock, flags);
+}
+EXPORT_SYMBOL_GPL(i3c_generic_ibi_recycle_slot);
+
+static void i3c_master_destroy_bus(struct i3c_master_controller *master)
+{
+ i3c_bus_unregister(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);
+
+ 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_unref(i3cbus);
+
+ return ret;
+}
+
+static int i3c_master_check_ops(const struct i3c_master_controller_ops *ops)
+{
+ if (!ops || !ops->bus_init || !ops->priv_xfers ||
+ !ops->send_ccc_cmd || !ops->do_daa || !ops->i2c_xfers ||
+ !ops->i2c_funcs)
+ return -EINVAL;
+
+ if (ops->request_ibi &&
+ (!ops->enable_ibi || !ops->disable_ibi || !ops->free_ibi ||
+ !ops->recycle_ibi_slot))
+ return -EINVAL;
+
+ return 0;
+}
+
+/**
+ * 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;
+
+ ret = i3c_master_check_ops(ops);
+ if (ret)
+ return ret;
+
+ master->parent = parent;
+ master->ops = ops;
+ master->secondary = secondary;
+ INIT_LIST_HEAD(&master->boardinfo.i2c);
+ INIT_LIST_HEAD(&master->boardinfo.i3c);
+
+ ret = i3c_master_create_bus(master);
+ if (ret)
+ return ret;
+
+ master->wq = alloc_workqueue("%s", 0, 0, dev_name(parent));
+ if (!master->wq) {
+ ret = -ENOMEM;
+ goto err_destroy_bus;
+ }
+
+ ret = i3c_master_bus_init(master);
+ if (ret)
+ goto err_destroy_wq;
+
+ /*
+ * 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_cleanup_bus;
+
+ /*
+ * We're done initializing the bus and the controller, we can now
+ * register I3C devices dicovered during the initial DAA.
+ */
+ master->init_done = true;
+ i3c_bus_normaluse_lock(master->bus);
+ i3c_master_register_new_i3c_devs(master);
+ i3c_bus_normaluse_unlock(master->bus);
+
+ return 0;
+
+err_cleanup_bus:
+ i3c_master_bus_cleanup(master);
+
+err_destroy_wq:
+ destroy_workqueue(master->wq);
+
+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_bus_cleanup(master);
+ destroy_workqueue(master->wq);
+ i3c_master_destroy_bus(master);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(i3c_master_unregister);
+
+int i3c_dev_do_priv_xfers_locked(struct i3c_dev_desc *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ struct i3c_master_controller *master;
+
+ if (!dev)
+ return -ENOENT;
+
+ master = i3c_dev_get_master(dev);
+ if (!master || !xfers)
+ return -EINVAL;
+
+ if (!master->ops->priv_xfers)
+ return -ENOTSUPP;
+
+ return master->ops->priv_xfers(dev, xfers, nxfers);
+}
+
+int i3c_dev_disable_ibi_locked(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master;
+ int ret;
+
+ if (!dev->ibi)
+ return -EINVAL;
+
+ master = i3c_dev_get_master(dev);
+ ret = master->ops->disable_ibi(dev);
+ if (ret)
+ return ret;
+
+ reinit_completion(&dev->ibi->all_ibis_handled);
+ if (atomic_read(&dev->ibi->pending_ibis))
+ wait_for_completion(&dev->ibi->all_ibis_handled);
+
+ dev->ibi->enabled = false;
+
+ return 0;
+}
+
+int i3c_dev_enable_ibi_locked(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ int ret;
+
+ if (!dev->ibi)
+ return -EINVAL;
+
+ ret = master->ops->enable_ibi(dev);
+ if (!ret)
+ dev->ibi->enabled = true;
+
+ return ret;
+}
+
+int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+ struct i3c_device_ibi_info *ibi;
+ int ret;
+
+ if (!master->ops->request_ibi)
+ return -ENOTSUPP;
+
+ if (dev->ibi)
+ return -EBUSY;
+
+ ibi = kzalloc(sizeof(*ibi), GFP_KERNEL);
+ if (!ibi)
+ return -ENOMEM;
+
+ atomic_set(&ibi->pending_ibis, 0);
+ init_completion(&ibi->all_ibis_handled);
+ ibi->handler = req->handler;
+ ibi->max_payload_len = req->max_payload_len;
+ ibi->num_slots = req->num_slots;
+
+ dev->ibi = ibi;
+ ret = master->ops->request_ibi(dev, req);
+ if (ret) {
+ kfree(ibi);
+ dev->ibi = NULL;
+ }
+
+ return ret;
+}
+
+void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *master = i3c_dev_get_master(dev);
+
+ if (!dev->ibi)
+ return;
+
+ if (WARN_ON(dev->ibi->enabled))
+ BUG_ON(i3c_dev_disable_ibi_locked(dev));
+
+ master->ops->free_ibi(dev);
+ kfree(dev->ibi);
+ dev->ibi = NULL;
+}
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..4331ca648efe
--- /dev/null
+++ b/include/linux/i3c/ccc.h
@@ -0,0 +1,385 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#ifndef I3C_CCC_H
+#define I3C_CCC_H
+
+#include <linux/bitops.h>
+#include <linux/i3c/device.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;
+};
+
+/**
+ * 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;
+};
+
+/**
+ * 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/I2C 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;
+};
+
+/**
+ * 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;
+};
+
+/**
+ * struct i3c_ccc_setda - payload passed to SETNEWDA and SETDASA CCCs
+ *
+ * @addr: dynamic address to assign to an I3C device
+ *
+ * Information passed to the SETNEWDA and SETDASA CCCs to assign/change the
+ * dynamic address of an I3C device.
+ */
+struct i3c_ccc_setda {
+ u8 addr;
+};
+
+/**
+ * struct i3c_ccc_getpid - payload passed to GETPID CCC
+ *
+ * @pid: 48 bits PID in big endian
+ */
+struct i3c_ccc_getpid {
+ u8 pid[6];
+};
+
+/**
+ * struct i3c_ccc_getbcr - payload passed to GETBCR CCC
+ *
+ * @bcr: BCR (Bus Characteristic Register) value
+ */
+struct i3c_ccc_getbcr {
+ u8 bcr;
+};
+
+/**
+ * struct i3c_ccc_getdcr - payload passed to GETDCR CCC
+ *
+ * @dcr: DCR (Device Characteristic Register) value
+ */
+struct i3c_ccc_getdcr {
+ u8 dcr;
+};
+
+#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;
+};
+
+/**
+ * struct i3c_ccc_getaccmst - payload passed to GETACCMST CCC
+ *
+ * @newmaster: address of the master taking bus ownership
+ */
+struct i3c_ccc_getaccmst {
+ u8 newmaster;
+};
+
+/**
+ * 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_SDR0_FSCL_MAX,
+ I3C_SDR1_FSCL_8MHZ,
+ I3C_SDR2_FSCL_6MHZ,
+ I3C_SDR3_FSCL_4MHZ,
+ I3C_SDR4_FSCL_2MHZ,
+};
+
+/**
+ * enum i3c_tsco - clock to data turn-around
+ */
+enum i3c_tsco {
+ I3C_TSCO_8NS,
+ I3C_TSCO_9NS,
+ I3C_TSCO_10NS,
+ I3C_TSCO_11NS,
+ I3C_TSCO_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
+ * @ndests: number of destinations. Should always be one for broadcast commands
+ * @dests: array of destinations and associated payload for this CCC. Most of
+ * the time, only one destination is provided
+ * @err: I3C error code
+ */
+struct i3c_ccc_cmd {
+ bool rnw;
+ u8 id;
+ int ndests;
+ struct i3c_ccc_cmd_dest *dests;
+ enum i3c_error_code err;
+};
+
+#endif /* I3C_CCC_H */
diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
new file mode 100644
index 000000000000..ef0a25706f18
--- /dev/null
+++ b/include/linux/i3c/device.h
@@ -0,0 +1,331 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#ifndef I3C_DEV_H
+#define I3C_DEV_H
+
+#include <linux/bitops.h>
+#include <linux/device.h>
+#include <linux/i2c.h>
+#include <linux/kconfig.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+
+/**
+ * enum i3c_error_code - I3C error codes
+ *
+ * These are the standard error codes as defined by the I3C specification.
+ * When -EIO is returned by the i3c_device_do_priv_xfers() or
+ * i3c_device_send_hdr_cmds() one can check the error code in
+ * &struct_i3c_priv_xfer.err or &struct i3c_hdr_cmd.err to get a better idea of
+ * what went wrong.
+ *
+ * @I3C_ERROR_UNKNOWN: unknown error, usually means the error is not I3C
+ * related
+ * @I3C_ERROR_M0: M0 error
+ * @I3C_ERROR_M1: M1 error
+ * @I3C_ERROR_M2: M2 error
+ */
+enum i3c_error_code {
+ I3C_ERROR_UNKNOWN = 0,
+ I3C_ERROR_M0 = 1,
+ I3C_ERROR_M1,
+ I3C_ERROR_M2,
+};
+
+/**
+ * enum i3c_hdr_mode - HDR mode ids
+ * @I3C_HDR_DDR: DDR mode
+ * @I3C_HDR_TSP: TSP mode
+ * @I3C_HDR_TSL: TSL mode
+ */
+enum i3c_hdr_mode {
+ I3C_HDR_DDR,
+ I3C_HDR_TSP,
+ I3C_HDR_TSL,
+};
+
+/**
+ * struct i3c_priv_xfer - I3C SDR private transfer
+ * @rnw: encodes the transfer direction. true for a read, false for a write
+ * @len: transfer length in bytes of the transfer
+ * @data: input/output buffer
+ * @data.in: input buffer. Must point to a DMA-able buffer
+ * @data.out: output buffer. Must point to a DMA-able buffer
+ * @err: I3C error code
+ */
+struct i3c_priv_xfer {
+ bool rnw;
+ u16 len;
+ union {
+ void *in;
+ const void *out;
+ } data;
+ enum i3c_error_code err;
+};
+
+/**
+ * enum i3c_dcr - I3C DCR values
+ * @I3C_DCR_GENERIC_DEVICE: generic I3C device
+ */
+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(_manufid, _partid, _drvdata) \
+ { \
+ .match_flags = I3C_MATCH_MANUF_AND_PART, \
+ .manuf_id = _manufid, \
+ .part_id = _partid, \
+ .data = _drvdata, \
+ }
+
+#define I3C_DEVICE_EXTRA_INFO(_manufid, _partid, _info, _drvdata) \
+ { \
+ .match_flags = I3C_MATCH_MANUF_AND_PART | \
+ I3C_MATCH_EXTRA_INFO, \
+ .manuf_id = _manufid, \
+ .part_id = _partid, \
+ .extra_info = _info, \
+ .data = _drvdata, \
+ }
+
+#define I3C_CLASS(_dcr, _drvdata) \
+ { \
+ .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);
+}
+
+struct device *i3cdev_to_dev(struct i3c_device *i3cdev);
+struct i3c_device *dev_to_i3cdev(struct device *dev);
+
+static inline void i3cdev_set_drvdata(struct i3c_device *i3cdev,
+ void *data)
+{
+ struct device *dev = i3cdev_to_dev(i3cdev);
+
+ dev_set_drvdata(dev, data);
+}
+
+static inline void *i3cdev_get_drvdata(struct i3c_device *i3cdev)
+{
+ struct device *dev = i3cdev_to_dev(i3cdev);
+
+ return dev_get_drvdata(dev);
+}
+
+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)
+
+/**
+ * module_i3c_driver() - Register a module providing an I3C driver
+ * @__drv: the I3C driver to register
+ *
+ * Provide generic init/exit functions that simply register/unregister an I3C
+ * driver.
+ * Should be used by any driver that does not require extra init/cleanup steps.
+ */
+#define module_i3c_driver(__drv) \
+ module_driver(__drv, i3c_driver_register, i3c_driver_unregister)
+
+/**
+ * i3c_i2c_driver_register() - Register an i2c and an i3c driver
+ * @i3cdrv: the I3C driver to register
+ * @i2cdrv: the I2C driver to register
+ *
+ * This function registers both @i2cdev and @i3cdev, and fails if one of these
+ * registrations fails. This is mainly useful for devices that support both I2C
+ * and I3C modes.
+ * Note that when CONFIG_I3C is not enabled, this function only registers the
+ * I2C driver.
+ *
+ * Return: 0 if both registrations succeeds, a negative error code otherwise.
+ */
+static inline int i3c_i2c_driver_register(struct i3c_driver *i3cdrv,
+ struct i2c_driver *i2cdrv)
+{
+ int ret;
+
+ ret = i2c_add_driver(i2cdrv);
+ if (ret || !IS_ENABLED(CONFIG_I3C))
+ return ret;
+
+ ret = i3c_driver_register(i3cdrv);
+ if (ret)
+ i2c_del_driver(i2cdrv);
+
+ return ret;
+}
+
+/**
+ * i3c_i2c_driver_unregister() - Unregister an i2c and an i3c driver
+ * @i3cdrv: the I3C driver to register
+ * @i2cdrv: the I2C driver to register
+ *
+ * This function unregisters both @i3cdrv and @i2cdrv.
+ * Note that when CONFIG_I3C is not enabled, this function only unregisters the
+ * @i2cdrv.
+ */
+static inline void i3c_i2c_driver_unregister(struct i3c_driver *i3cdrv,
+ struct i2c_driver *i2cdrv)
+{
+ if (IS_ENABLED(CONFIG_I3C))
+ i3c_driver_unregister(i3cdrv);
+
+ i2c_del_driver(i2cdrv);
+}
+
+/**
+ * module_i3c_i2c_driver() - Register a module providing an I3C and an I2C
+ * driver
+ * @__i3cdrv: the I3C driver to register
+ * @__i2cdrv: the I3C driver to register
+ *
+ * Provide generic init/exit functions that simply register/unregister an I3C
+ * and an I2C driver.
+ * This macro can be used even if CONFIG_I3C is disabled, in this case, only
+ * the I2C driver will be registered.
+ * Should be used by any driver that does not require extra init/cleanup steps.
+ */
+#define module_i3c_i2c_driver(__i3cdrv, __i2cdrv) \
+ module_driver(__i3cdrv, \
+ i3c_i2c_driver_register, \
+ i3c_i2c_driver_unregister)
+
+int i3c_device_do_priv_xfers(struct i3c_device *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers);
+
+void i3c_device_get_info(struct i3c_device *dev, struct i3c_device_info *info);
+
+struct i3c_ibi_payload {
+ unsigned int len;
+ const void *data;
+};
+
+/**
+ * struct i3c_ibi_setup - IBI setup object
+ * @max_payload_len: maximum length of the payload associated to an IBI. If one
+ * IBI appears to have a payload that is bigger than this
+ * number, the IBI will be rejected.
+ * @num_slots: number of pre-allocated IBI slots. This should be chosen so that
+ * the system never runs out of IBI slots, otherwise you'll lose
+ * IBIs.
+ * @handler: IBI handler, every time an IBI is received. This handler is called
+ * in a workqueue context. It is allowed to sleep and send new
+ * messages on the bus, though it's recommended to keep the
+ * processing done there as fast as possible to avoid delaying
+ * processing of other queued on the same workqueue.
+ *
+ * Temporary structure used to pass information to i3c_device_request_ibi().
+ * This object can be allocated on the stack since i3c_device_request_ibi()
+ * copies every bit of information and do not use it after
+ * i3c_device_request_ibi() has returned.
+ */
+struct i3c_ibi_setup {
+ unsigned int max_payload_len;
+ unsigned int num_slots;
+ void (*handler)(struct i3c_device *dev,
+ const struct i3c_ibi_payload *payload);
+};
+
+int i3c_device_request_ibi(struct i3c_device *dev,
+ const struct i3c_ibi_setup *setup);
+void i3c_device_free_ibi(struct i3c_device *dev);
+int i3c_device_enable_ibi(struct i3c_device *dev);
+int i3c_device_disable_ibi(struct i3c_device *dev);
+
+#endif /* I3C_DEV_H */
diff --git a/include/linux/i3c/master.h b/include/linux/i3c/master.h
new file mode 100644
index 000000000000..f512b713daf4
--- /dev/null
+++ b/include/linux/i3c/master.h
@@ -0,0 +1,652 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#ifndef I3C_MASTER_H
+#define I3C_MASTER_H
+
+#include <asm/bitsperlong.h>
+
+#include <linux/bitops.h>
+#include <linux/i2c.h>
+#include <linux/i3c/ccc.h>
+#include <linux/i3c/device.h>
+#include <linux/rwsem.h>
+#include <linux/spinlock.h>
+#include <linux/workqueue.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 i2c_device;
+struct i3c_device;
+
+/**
+ * struct i3c_i2c_dev_desc - Common part of the I3C/I2C device descriptor
+ * @node: node element used to insert the slot into the I2C or I3C device
+ * list
+ * @master: I3C master that instantiated this device. Will be used to do
+ * I2C/I3C transfers
+ * @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_desc {
+ struct list_head node;
+ 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_dev_boardinfo - I2C device board information
+ * @node: used to insert the boardinfo object in the I2C boardinfo list
+ * @base: regular I2C board information
+ * @lvr: LVR (Legacy Virtual Register) needed by the I3C core to know about
+ * the I2C device limitations
+ *
+ * This structure is used to attach board-level information to an I2C device.
+ * Each I2C device connected on the I3C bus should have one.
+ */
+struct i2c_dev_boardinfo {
+ struct list_head node;
+ struct i2c_board_info base;
+ u8 lvr;
+};
+
+/**
+ * struct i2c_dev_desc - I2C device descriptor
+ * @common: common part of the I2C device descriptor
+ * @boardinfo: pointer to the boardinfo attached to this I2C device
+ * @dev: I2C device object registered to the I2C framework
+ *
+ * Each I2C device connected on the bus will have an i2c_dev_desc.
+ * This object is created by the core and later attached to the controller
+ * using &struct_i3c_master_controller->ops->attach_i2c_dev().
+ *
+ * &struct_i2c_dev_desc is the internal representation of an I2C device
+ * connected on an I3C bus. This object is also passed to all
+ * &struct_i3c_master_controller_ops hooks.
+ */
+struct i2c_dev_desc {
+ struct i3c_i2c_dev_desc common;
+ const struct i2c_dev_boardinfo *boardinfo;
+ struct i2c_client *dev;
+};
+
+/**
+ * struct i3c_ibi_slot - I3C IBI (In-Band Interrupt) slot
+ * @work: work associated to this slot. The IBI handler will be called from
+ * there
+ * @dev: the I3C device that has generated this IBI
+ * @len: length of the payload associated to this IBI
+ * @data: payload buffer
+ *
+ * An IBI slot is an object pre-allocated by the controller and used when an
+ * IBI comes in.
+ * Every time an IBI comes in, the I3C master driver should find a free IBI
+ * slot in its IBI slot pool, retrieve the IBI payload and queue the IBI using
+ * i3c_master_queue_ibi().
+ *
+ * How IBI slots are allocated is left to the I3C master driver, though, for
+ * simple kmalloc-based allocation, the generic IBI slot pool can be used.
+ */
+struct i3c_ibi_slot {
+ struct work_struct work;
+ struct i3c_dev_desc *dev;
+ unsigned int len;
+ void *data;
+};
+
+/**
+ * struct i3c_device_ibi_info - IBI information attached to a specific device
+ * @all_ibis_handled: used to be informed when no more IBIs are waiting to be
+ * processed. Used by i3c_device_disable_ibi() to wait for
+ * all IBIs to be dequeued
+ * @pending_ibis: count the number of pending IBIs. Each pending IBI has its
+ * work element queued to the controller workqueue
+ * @max_payload_len: maximum payload length for an IBI coming from this device.
+ * this value is specified when calling
+ * i3c_device_request_ibi() and should not change at run
+ * time. All messages IBIs exceeding this limit should be
+ * rejected by the master
+ * @num_slots: number of IBI slots reserved for this device
+ * @enabled: reflect the IBI status
+ * @handler: IBI handler specified at i3c_device_request_ibi() call time. This
+ * handler will be called from the controller workqueue, and as such
+ * is allowed to sleep (though it is recommended to process the IBI
+ * as fast as possible to not stall processing of other IBIs queued
+ * on the same workqueue).
+ * New I3C messages can be sent from the IBI handler
+ *
+ * The &struct_i3c_device_ibi_info object is allocated when
+ * i3c_device_request_ibi() is called and attached to a specific device. This
+ * object is here to manage IBIs coming from a specific I3C device.
+ *
+ * Note that this structure is the generic view of the IBI management
+ * infrastructure. I3C master drivers may have their own internal
+ * representation which they can associate to the device using
+ * controller-private data.
+ */
+struct i3c_device_ibi_info {
+ struct completion all_ibis_handled;
+ atomic_t pending_ibis;
+ unsigned int max_payload_len;
+ unsigned int num_slots;
+ bool enabled;
+ void (*handler)(struct i3c_device *dev,
+ const struct i3c_ibi_payload *payload);
+};
+
+/**
+ * struct i3c_dev_boardinfo - I3C device board information
+ * @node: used to insert the boardinfo object in the I3C boardinfo list
+ * @init_dyn_addr: initial dynamic address requested by the FW. We provide no
+ * guarantee that the device will end up using this address,
+ * but try our best to assign this specific address to the
+ * device
+ * @static_addr: static address the I3C device listen on before it's been
+ * assigned a dynamic address by the master. Will be used during
+ * bus initialization to assign it a specific dynamic address
+ * before starting DAA (Dynamic Address Assignment)
+ * @pid: I3C Provisional ID exposed by the device. This is a unique identifier
+ * that may be used to attach boardinfo to i3c_dev_desc when the device
+ * does not have a static address
+ * @of_node: optional DT node in case the device has been described in the DT
+ *
+ * This structure is used to attach board-level information to an I3C device.
+ * Not all I3C devices connected on the bus will have a boardinfo. It's only
+ * needed if you want to attach extra resources to a device or assign it a
+ * specific dynamic address.
+ */
+struct i3c_dev_boardinfo {
+ struct list_head node;
+ u8 init_dyn_addr;
+ u8 static_addr;
+ u64 pid;
+ struct device_node *of_node;
+};
+
+/**
+ * struct i3c_dev_desc - I3C device descriptor
+ * @common: common part of the I3C device descriptor
+ * @info: I3C device information. Will be automatically filled when you create
+ * your device with i3c_master_add_i3c_dev_locked()
+ * @ibi_lock: lock used to protect the &struct_i3c_device->ibi
+ * @ibi: IBI info attached to a device. Should be NULL until
+ * i3c_device_request_ibi() is called
+ * @dev: pointer to the I3C device object exposed to I3C device drivers. This
+ * should never be accessed from I3C master controller drivers. Only core
+ * code should manipulate it in when updating the dev <-> desc link or
+ * when propagating IBI events to the driver
+ * @boardinfo: pointer to the boardinfo attached to this I3C device
+ *
+ * Internal representation of an I3C device. This object is only used by the
+ * core and passed to I3C master controller drivers when they're requested to
+ * do some operations on the device.
+ * The core maintains the link between the internal I3C dev descriptor and the
+ * object exposed to the I3C device drivers (&struct_i3c_device).
+ */
+struct i3c_dev_desc {
+ struct i3c_i2c_dev_desc common;
+ struct i3c_device_info info;
+ struct mutex ibi_lock;
+ struct i3c_device_ibi_info *ibi;
+ struct i3c_device *dev;
+ const struct i3c_dev_boardinfo *boardinfo;
+};
+
+/**
+ * struct i3c_device - I3C device object
+ * @dev: device object to register the I3C dev to the device model
+ * @desc: pointer to an i3c device descriptor object. This link is updated
+ * every time the I3C device is rediscovered with a different dynamic
+ * address assigned
+ * @bus: I3C bus this device is attached to
+ *
+ * I3C device object exposed to I3C device drivers. The takes care of linking
+ * this object to the relevant &struct_i3c_dev_desc one.
+ * All 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 device dev;
+ struct i3c_dev_desc *desc;
+ struct i3c_bus *bus;
+};
+
+/*
+ * 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
+ * @id: bus ID. Assigned by the framework when register the bus
+ * @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.i3c: maximum rate for the clock signal when doing I3C SDR/priv
+ * transfers
+ * @scl_rate.i2c: maximum rate for the clock signal when doing I2C transfers
+ * @scl_rate: SCL signal rate for I3C and I2C mode
+ * @devs.i3c: contains a list of I3C device descriptors representing I3C
+ * devices connected on the bus and successfully attached to the
+ * I3C master
+ * @devs.i2c: contains a list of I2C device descriptors representing I2C
+ * devices connected on the bus and successfully attached to the
+ * I3C master
+ * @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_dev_desc *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;
+};
+
+struct i3c_master_controller;
+
+/**
+ * struct i3c_master_controller_ops - I3C master methods
+ * @bus_init: hook responsible for the I3C bus initialization. You should at
+ * least call master_set_info() from there and set the bus mode.
+ * You can also put controller specific initialization in there.
+ * This method is mandatory.
+ * @bus_cleanup: cleanup everything done in
+ * &i3c_master_controller_ops->bus_init().
+ * This method is optional.
+ * @attach_i3c_dev: called every time an I3C device is attached to the bus. It
+ * can be after a DAA or when a device is statically declared
+ * by the FW, in which case it will only have a static address
+ * and the dynamic address will be 0.
+ * When this function is called, device information have not
+ * been retrieved yet.
+ * This is a good place to attach master controller specific
+ * data to I3C devices.
+ * This method is optional.
+ * @reattach_i3c_dev: called every time an I3C device has its addressed
+ * changed. It can be because the device has been powered
+ * down and has lost its address, or it can happen when a
+ * device had a static address and has been assigned a
+ * dynamic address with SETDASA.
+ * This method is optional.
+ * @detach_i3c_dev: called when an I3C device is detached from the bus. Usually
+ * happens when the master device is unregistered.
+ * This method is optional.
+ * @do_daa: do a DAA (Dynamic Address Assignment) procedure. This is procedure
+ * should send an ENTDAA CCC command and then add all devices
+ * discovered sure the DAA using i3c_master_add_i3c_dev_locked().
+ * Add devices added with i3c_master_add_i3c_dev_locked() will then be
+ * attached or re-attached to the controller.
+ * This method is mandatory.
+ * @supports_ccc_cmd: should return true if the CCC command is supported, false
+ * otherwise.
+ * This method is optional, if not provided the core assumes
+ * all CCC commands are supported.
+ * @send_ccc_cmd: send a CCC command
+ * This method is mandatory.
+ * @priv_xfers: do one or several private I3C SDR transfers
+ * This method is mandatory.
+ * @attach_i2c_dev: called every time an I2C device is attached to the bus.
+ * This is a good place to attach master controller specific
+ * data to I2C devices.
+ * This method is optional.
+ * @detach_i2c_dev: called when an I2C device is detached from the bus. Usually
+ * happens when the master device is unregistered.
+ * This method is optional.
+ * @i2c_xfers: do one or several I2C transfers.
+ * This method is mandatory.
+ * @i2c_funcs: expose the supported I2C functionalities.
+ * This method is mandatory.
+ * @request_ibi: attach an IBI handler to an I3C device. This implies defining
+ * an IBI handler and the constraints of the IBI (maximum payload
+ * length and number of pre-allocated slots).
+ * Some controllers support less IBI-capable devices than regular
+ * devices, so this method might return -%EBUSY if there's no
+ * more space for an extra IBI registration
+ * This method is optional.
+ * @free_ibi: free an IBI previously requested with ->request_ibi(). The IBI
+ * should have been disabled with ->disable_irq() prior to that
+ * This method is mandatory only if ->request_ibi is not NULL.
+ * @enable_ibi: enable the IBI. Only valid if ->request_ibi() has been called
+ * prior to ->enable_ibi(). The controller should first enable
+ * the IBI on the controller end (for example, unmask the hardware
+ * IRQ) and then send the ENEC CCC command (with the IBI flag set)
+ * to the I3C device.
+ * This method is mandatory only if ->request_ibi is not NULL.
+ * @disable_ibi: disable an IBI. First send the DISEC CCC command with the IBI
+ * flag set and then deactivate the hardware IRQ on the
+ * controller end.
+ * This method is mandatory only if ->request_ibi is not NULL.
+ * @recycle_ibi_slot: recycle an IBI slot. Called every time an IBI has been
+ * processed by its handler. The IBI slot should be put back
+ * in the IBI slot pool so that the controller can re-use it
+ * for a future IBI
+ * This method is mandatory only if ->request_ibi is not
+ * NULL.
+ */
+struct i3c_master_controller_ops {
+ int (*bus_init)(struct i3c_master_controller *master);
+ void (*bus_cleanup)(struct i3c_master_controller *master);
+ int (*attach_i3c_dev)(struct i3c_dev_desc *dev);
+ int (*reattach_i3c_dev)(struct i3c_dev_desc *dev, u8 old_dyn_addr);
+ void (*detach_i3c_dev)(struct i3c_dev_desc *dev);
+ int (*do_daa)(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 (*priv_xfers)(struct i3c_dev_desc *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers);
+ int (*attach_i2c_dev)(struct i2c_dev_desc *dev);
+ void (*detach_i2c_dev)(struct i2c_dev_desc *dev);
+ int (*i2c_xfers)(struct i2c_dev_desc *dev,
+ const struct i2c_msg *xfers, int nxfers);
+ u32 (*i2c_funcs)(struct i3c_master_controller *master);
+ int (*request_ibi)(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req);
+ void (*free_ibi)(struct i3c_dev_desc *dev);
+ int (*enable_ibi)(struct i3c_dev_desc *dev);
+ int (*disable_ibi)(struct i3c_dev_desc *dev);
+ void (*recycle_ibi_slot)(struct i3c_dev_desc *dev,
+ struct i3c_ibi_slot *slot);
+};
+
+/**
+ * struct i3c_master_controller - I3C master controller object
+ * @parent: parent device that instantiated this master
+ * @this: an I3C device object representing this master. This device will be
+ * added to the list of I3C devs available 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
+ * @init_done: true when the bus initialization is done
+ * @boardinfo.i3c: list of I3C boardinfo objects
+ * @boardinfo.i2c: list of I2C boardinfo objects
+ * @boardinfo: board-level information attached to devices connected on the bus
+ * @bus: I3C bus object created by this master
+ * @wq: workqueue used to execute IBI handlers. Can also be used by master
+ * drivers if they need to postpone operations that need to take place
+ * in a thread context. Typical examples are Hot Join processing which
+ * requires taking the bus lock in maintenance, which in turn, can only
+ * be done from a sleep-able context
+ *
+ * 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_dev_desc *this;
+ struct i2c_adapter i2c;
+ const struct i3c_master_controller_ops *ops;
+ bool secondary;
+ bool init_done;
+ struct {
+ struct list_head i3c;
+ struct list_head i2c;
+ } boardinfo;
+ struct i3c_bus *bus;
+ struct workqueue_struct *wq;
+};
+
+/**
+ * i3c_bus_for_each_i2cdev() - iterate over all I2C devices present on the bus
+ * @bus: the I3C bus
+ * @dev: an I2C device descriptor pointer updated to point to the current slot
+ * at each iteration of the loop
+ *
+ * Iterate over all I2C devs present on the bus.
+ */
+#define i3c_bus_for_each_i2cdev(bus, dev) \
+ list_for_each_entry(dev, &(bus)->devs.i2c, common.node)
+
+/**
+ * i3c_bus_for_each_i3cdev() - iterate over all I3C devices present on the bus
+ * @bus: the I3C bus
+ * @dev: and I3C device descriptor pointer updated to point to the current slot
+ * at each iteration of the loop
+ *
+ * Iterate over all I3C devs present on the bus.
+ */
+#define i3c_bus_for_each_i3cdev(bus, dev) \
+ list_for_each_entry(dev, &(bus)->devs.i3c, common.node)
+
+void i3c_bus_maintenance_lock(struct i3c_bus *bus);
+void i3c_bus_maintenance_unlock(struct i3c_bus *bus);
+void i3c_bus_normaluse_lock(struct i3c_bus *bus);
+void i3c_bus_normaluse_unlock(struct i3c_bus *bus);
+
+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,
+ u8 evts);
+int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
+ u8 evts);
+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);
+
+int i3c_master_add_i3c_dev_locked(struct i3c_master_controller *master,
+ u8 addr);
+int i3c_master_do_daa(struct i3c_master_controller *master);
+
+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_dev_get_master_data() - get master private data attached to an I3C
+ * device descriptor
+ * @dev: the I3C device descriptor to get private data from
+ *
+ * Return: the private data previously attached with i3c_dev_set_master_data()
+ * or NULL if no data has been attached to the device.
+ */
+static inline void *i3c_dev_get_master_data(const struct i3c_dev_desc *dev)
+{
+ return dev->common.master_priv;
+}
+
+/**
+ * i3c_dev_set_master_data() - attach master private data to an I3C device
+ * descriptor
+ * @dev: the I3C device descriptor 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_dev_get_master_data().
+ */
+static inline void i3c_dev_set_master_data(struct i3c_dev_desc *dev,
+ void *data)
+{
+ dev->common.master_priv = data;
+}
+
+/**
+ * i2c_dev_get_master_data() - get master private data attached to an I2C
+ * device descriptor
+ * @dev: the I2C device descriptor to get private data from
+ *
+ * Return: the private data previously attached with i2c_dev_set_master_data()
+ * or NULL if no data has been attached to the device.
+ */
+static inline void *i2c_dev_get_master_data(const struct i2c_dev_desc *dev)
+{
+ return dev->common.master_priv;
+}
+
+/**
+ * i2c_dev_set_master_data() - attach master private data to an I2C device
+ * descriptor
+ * @dev: the I2C device descriptor 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().
+ */
+static inline void i2c_dev_set_master_data(struct i2c_dev_desc *dev,
+ void *data)
+{
+ dev->common.master_priv = data;
+}
+
+/**
+ * i3c_dev_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_dev_get_master(struct i3c_dev_desc *dev)
+{
+ return dev->common.master;
+}
+
+/**
+ * i2c_dev_get_master() - get master used to communicate with a device
+ * @dev: I2C dev
+ *
+ * Return: the master controller driving @dev
+ */
+static inline struct i3c_master_controller *
+i2c_dev_get_master(struct i2c_dev_desc *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;
+}
+
+struct i3c_generic_ibi_pool;
+
+struct i3c_generic_ibi_pool *
+i3c_generic_ibi_alloc_pool(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req);
+void i3c_generic_ibi_free_pool(struct i3c_generic_ibi_pool *pool);
+
+struct i3c_ibi_slot *
+i3c_generic_ibi_get_free_slot(struct i3c_generic_ibi_pool *pool);
+void i3c_generic_ibi_recycle_slot(struct i3c_generic_ibi_pool *pool,
+ struct i3c_ibi_slot *slot);
+
+void i3c_master_queue_ibi(struct i3c_dev_desc *dev, struct i3c_ibi_slot *slot);
+
+struct i3c_ibi_slot *i3c_master_get_free_ibi_slot(struct i3c_dev_desc *dev);
+
+#endif /* I3C_MASTER_H */
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 96a71a648eed..870392478d66 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -448,6 +448,23 @@ struct pci_epf_device_id {
kernel_ulong_t driver_data;
};
+/* i3c */
+
+#define I3C_MATCH_DCR 0x1
+#define I3C_MATCH_MANUF 0x2
+#define I3C_MATCH_PART 0x4
+#define I3C_MATCH_EXTRA_INFO 0x8
+
+struct i3c_device_id {
+ __u8 match_flags;
+ __u8 dcr;
+ __u16 manuf_id;
+ __u16 part_id;
+ __u16 extra_info;
+
+ const void *data;
+};
+
/* spi */
#define SPI_NAME_SIZE 32
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 02/10] docs: driver-api: Add I3C documentation
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 03/10] i3c: Add sysfs ABI spec Boris Brezillon
` (8 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Add the I3C documentation describing the protocol, the master driver API
and the device driver API.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
---
Changes in v6:
- Fix typos reported by Randy
- Add Randy's R-b
Changes in v5:
- Remove useless conf.py file
- Add SPDX headers
Changes in v2:
- Moved out of patch "i3c: Add core I3C infrastructure"
- Add link to the I3C spec
- Move rst files in Documentation/driver-api/i3c/
---
Documentation/driver-api/i3c/device-driver-api.rst | 9 +
Documentation/driver-api/i3c/index.rst | 11 ++
Documentation/driver-api/i3c/master-driver-api.rst | 10 +
Documentation/driver-api/i3c/protocol.rst | 203 +++++++++++++++++++++
Documentation/driver-api/index.rst | 1 +
5 files changed, 234 insertions(+)
create mode 100644 Documentation/driver-api/i3c/device-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/index.rst
create mode 100644 Documentation/driver-api/i3c/master-driver-api.rst
create mode 100644 Documentation/driver-api/i3c/protocol.rst
diff --git a/Documentation/driver-api/i3c/device-driver-api.rst b/Documentation/driver-api/i3c/device-driver-api.rst
new file mode 100644
index 000000000000..85bc3381cd3e
--- /dev/null
+++ b/Documentation/driver-api/i3c/device-driver-api.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================
+I3C device driver API
+=====================
+
+.. kernel-doc:: include/linux/i3c/device.h
+
+.. kernel-doc:: drivers/i3c/device.c
diff --git a/Documentation/driver-api/i3c/index.rst b/Documentation/driver-api/i3c/index.rst
new file mode 100644
index 000000000000..783d6dad054b
--- /dev/null
+++ b/Documentation/driver-api/i3c/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============
+I3C subsystem
+=============
+
+.. toctree::
+
+ protocol
+ device-driver-api
+ master-driver-api
diff --git a/Documentation/driver-api/i3c/master-driver-api.rst b/Documentation/driver-api/i3c/master-driver-api.rst
new file mode 100644
index 000000000000..bb19264aa239
--- /dev/null
+++ b/Documentation/driver-api/i3c/master-driver-api.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+================================
+I3C master controller driver API
+================================
+
+.. kernel-doc:: drivers/i3c/master.c
+
+.. kernel-doc:: include/linux/i3c/master.h
+
diff --git a/Documentation/driver-api/i3c/protocol.rst b/Documentation/driver-api/i3c/protocol.rst
new file mode 100644
index 000000000000..dae3b6d32c6b
--- /dev/null
+++ b/Documentation/driver-api/i3c/protocol.rst
@@ -0,0 +1,203 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+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 to the table. If you need more information, please refer to the MIPI
+I3C specification (can be downloaded here
+http://resources.mipi.org/mipi-i3c-v1-download).
+
+Introduction
+============
+
+The I3C (pronounced 'eye-three-see') is a MIPI standardized protocol designed
+to overcome I2C limitations (limited speed, external signals needed for
+interrupts, no automatic detection of the devices connected to the bus, ...)
+while remaining power-efficient.
+
+I3C Bus
+=======
+
+An I3C bus is made of several I3C devices and possibly some I2C devices as
+well, but let's focus on I3C devices for now.
+
+An I3C device on the I3C bus can have one of the following roles:
+
+* Master: the device is driving the bus. It's the one in charge of initiating
+ transactions or deciding who is allowed to talk on the bus (slave generated
+ events are possible in I3C, see below).
+* Slave: the device acts as a slave, and is not able to send frames to another
+ slave on the bus. The device can still send events to the master on
+ its own initiative if the master allowed it.
+
+I3C is a multi-master protocol, so there might be several masters on a bus,
+though only one device can act as a master at a given time. In order to gain
+bus ownership, a master has to follow a specific procedure.
+
+Each device on the I3C bus has to be assigned a dynamic address to be able to
+communicate. Until this is done, the device should only respond to a limited
+set of commands. If it has a static address (also called legacy I2C address),
+the device can reply to I2C transfers.
+
+In addition to these per-device addresses, the protocol defines a broadcast
+address in order to address all 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 broadcast (applies to all devices) or sent to a specific
+device.
+
+I3C Hot-Join
+============
+
+The Hot-Join mechanism is similar 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 clock
+frequency is 12.5MHz).
+
+I3C 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 in big endian
+* N 16-bits data words in big endian
+
+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/driver-api/index.rst b/Documentation/driver-api/index.rst
index 6d9f2f9fe20e..cc6a33f232ea 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -32,6 +32,7 @@ available subsections can be seen below.
pci
spi
i2c
+ i3c/index
hsi
edac
scsi
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 03/10] i3c: Add sysfs ABI spec
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 02/10] docs: driver-api: Add I3C documentation Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 04/10] dt-bindings: i3c: Document core bindings Boris Brezillon
` (7 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Document sysfs files/directories/symlinks exposed by the I3C subsystem.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
Changes in v5:
- Fix the kernel version
- Rename address into dynamic_address to match changes done in the code
Changes in v4:
- none
Changes in v3:
- none
Changes in v2:
- new patch
---
Documentation/ABI/testing/sysfs-bus-i3c | 95 +++++++++++++++++++++++++++++++++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i3c
diff --git a/Documentation/ABI/testing/sysfs-bus-i3c b/Documentation/ABI/testing/sysfs-bus-i3c
new file mode 100644
index 000000000000..068fd1e97c01
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i3c
@@ -0,0 +1,95 @@
+What: /sys/bus/i3c/devices/i3c-<bus-id>
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ An I3C bus. This directory will contain one sub-directory per
+ I3C device present on the bus.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/current_master
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ Expose the master that owns the bus (<bus-id>-<master-pid>) at
+ the time this file is read. Note that bus ownership can change
+ overtime, so there's no guarantee that when the read() call
+ returns, the value returned is still valid.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/mode
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ I3C bus mode. Can be "pure", "mixed-fast" or "mixed-slow". See
+ the I3C specification for a detailed description of what each
+ of these modes implies.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/i3c_scl_frequency
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ The frequency (expressed in Hz) of the SCL signal when
+ operating in I3C SDR mode.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/i2c_scl_frequency
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ The frequency (expressed in Hz) of the SCL signal when
+ operating in I2C mode.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ An I3C device present on I3C bus identified by <bus-id>. Note
+ that all devices are represented including the master driving
+ the bus.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/dynamic_address
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ Dynamic address assigned to device <bus-id>-<device-pid>. This
+ address may change if the bus is re-initialized.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/bcr
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ BCR stands for Bus Characteristics Register and express the
+ device capabilities in term of speed, maximum read/write
+ length, etc. See the I3C specification for more details.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/dcr
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ DCR stands for Device Characteristics Register and express the
+ device capabilities in term of exposed features. See the I3C
+ specification for more details.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ PID stands for Provisional ID and is used to uniquely identify
+ a device on a bus. This PID contains information about the
+ vendor, the part and an instance ID so that several devices of
+ the same type can be connected on the same bus.
+ See the I3C specification for more details.
+
+What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/hdrcap
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ Expose the HDR (High Data Rate) capabilities of a device.
+ Returns a list of supported HDR mode, each element is separated
+ by space. Modes can be "hdr-ddr", "hdr-tsp" and "hdr-tsl".
+ See the I3C specification for more details about these HDR
+ modes.
+
+What: /sys/bus/i3c/devices/<bus-id>-<device-pid>
+KernelVersion: 4.19
+Contact: linux-i3c@vger.kernel.org
+Description:
+ These directories are just symbolic links to
+ /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>.
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 04/10] dt-bindings: i3c: Document core bindings
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (2 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 03/10] i3c: Add sysfs ABI spec Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property Boris Brezillon
` (6 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, 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@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Add Rob's R-b
Changes in v4:
- Clarify the fact that static address == I3C address and dynamic
address == I3C address
- Use i2c-scl-hz in the example
Changes in v3:
- Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
- Rework the way we expose the provisional ID and LVR information
- Rename dynamic-address into assigned-address
- Enforce the I3C master node name
Changes in v2:
- Define how to describe I3C devices in the DT and when it should be
used. Note that the parsing of I3C devices is not yet implemented in
the framework. Will be added when someone really needs it.
---
Documentation/devicetree/bindings/i3c/i3c.txt | 140 ++++++++++++++++++++++++++
1 file changed, 140 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
new file mode 100644
index 000000000000..13b719f1ef15
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/i3c.txt
@@ -0,0 +1,140 @@
+Generic device tree bindings for I3C busses
+===========================================
+
+This document describes generic bindings that should be used to describe I3C
+busses in a device tree.
+
+Required properties
+-------------------
+
+- #address-cells - should be <3>. Read more about addresses below.
+- #size-cells - should be <0>.
+- compatible - name of the I3C master controller driving the I3C bus
+
+For other required properties e.g. to describe register sets,
+clocks, etc. check the binding documentation of the specific driver.
+The node describing an I3C bus should be named i3c-master.
+
+Optional properties
+-------------------
+
+These properties may not be supported by all I3C master drivers. Each I3C
+master bindings should specify which of them are supported.
+
+- i3c-scl-hz: frequency of the SCL signal used for I3C transfers.
+ When undefined the core sets it to 12.5MHz.
+
+- i2c-scl-hz: frequency of the SCL signal used for I2C transfers.
+ When undefined, the core looks at LVR (Legacy Virtual Register)
+ values of I2C devices described in the device tree to determine
+ the maximum I2C frequency.
+
+I2C devices
+===========
+
+Each I2C device connected to the bus should be described in a subnode. All
+properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
+valid here, but several new properties have been added.
+
+New constraint on existing properties:
+--------------------------------------
+- reg: contains 3 cells
+ + first cell : still encoding the I2C address
+
+ + second cell: should have bit 31 set to 1 to signify that this is an I2C
+ device. Bits 0 to 7 encode the I3C LVR (Legacy Virtual
+ Register):
+
+ bit[7:5]: I2C device index. Possible values
+ * 0: I2C device has a 50 ns spike filter
+ * 1: I2C device does not have a 50 ns spike filter but supports high
+ frequency on SCL
+ * 2: I2C device does not have a 50 ns spike filter and is not tolerant
+ to high frequencies
+ * 3-7: reserved
+
+ bit[4]: tell whether the device operates in FM (Fast Mode) or FM+ mode
+ * 0: FM+ mode
+ * 1: FM mode
+
+ bit[3:0]: device type
+ * 0-15: reserved
+
+ + third cell: should be 0
+
+I3C devices
+===========
+
+All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
+are thus discoverable. So, by default, I3C devices do not have to be described
+in the device tree.
+This being said, one might want to attach extra resources to these devices,
+and those resources may have to be described in the device tree, which in turn
+means we have to describe I3C devices.
+
+Another use case for describing an I3C device in the device tree is when this
+I3C device has a static I2C address and we want to assign it a specific I3C
+dynamic address before the DAA takes place (so that other devices on the bus
+can't take this dynamic address).
+
+The I3C device should be names <device-type>@<static-i2c-address>,<i3c-pid>,
+where device-type is describing the type of device connected on the bus
+(gpio-controller, sensor, ...).
+
+Required properties
+-------------------
+- reg: contains 3 cells
+ + first cell : encodes the static I2C address. Should be 0 if the device does
+ not have one (0 is not a valid I2C address).
+
+ + second and third cells: should encode the ProvisionalID. The second cell
+ contains the manufacturer ID left-shifted by 1.
+ The third cell contains ORing of the part ID
+ left-shifted by 16, the instance ID left-shifted
+ by 12 and the extra information. This encoding is
+ following the PID definition provided by the I3C
+ specification.
+
+Optional properties
+-------------------
+- assigned-address: dynamic address to be assigned to this device. This
+ property is only valid if the I3C device has a static
+ address (first cell of the reg property != 0).
+
+
+Example:
+
+ i3c-master@d040000 {
+ compatible = "cdns,i3c-master";
+ clocks = <&coreclock>, <&i3csysclock>;
+ clock-names = "pclk", "sysclk";
+ interrupts = <3 0>;
+ reg = <0x0d040000 0x1000>;
+ #address-cells = <3>;
+ #size-cells = <0>;
+
+ status = "okay";
+ i2c-scl-hz = <100000>;
+
+ /* I2C device. */
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52 0x80000010 0x0>;
+ };
+
+ /* I3C device with a static I2C address. */
+ thermal_sensor: sensor@68,39200144004 {
+ reg = <0x68 0x392 0x144004>;
+ assigned-address = <0xa>;
+ };
+
+ /*
+ * I3C device without a static I2C address but requiring
+ * resources described in the DT.
+ */
+ sensor@0,39200154004 {
+ reg = <0x0 0x392 0x154004>;
+ clocks = <&clock_provider 0>;
+ };
+ };
+
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (3 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 04/10] dt-bindings: i3c: Document core bindings Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
` (5 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
The reg property of devices connected to an I3C bus have 3 cells, and
filling them manually is not trivial. Provides macros to help doing
that.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- none
---
include/dt-bindings/i3c/i3c.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 include/dt-bindings/i3c/i3c.h
diff --git a/include/dt-bindings/i3c/i3c.h b/include/dt-bindings/i3c/i3c.h
new file mode 100644
index 000000000000..97448c546649
--- /dev/null
+++ b/include/dt-bindings/i3c/i3c.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#ifndef _DT_BINDINGS_I3C_I3C_H
+#define _DT_BINDINGS_I3C_I3C_H
+
+#define IS_I2C_DEV 0x80000000
+
+#define I2C_DEV(addr, lvr) \
+ (addr) (IS_I2C_DEV | (lvr)) 0x0
+
+#define I3C_PID(manufid, partid, instid, extrainfo) \
+ ((manufid) << 1) \
+ (((partid) << 16) | ((instid) << 12) | (extrainfo))
+
+#define I3C_DEV_WITH_STATIC_ADDR(addr, manufid, partid, \
+ instid, extrainfo) \
+ (addr) I3C_PID(manufid, partid, instid, extrainfo)
+
+#define I3C_DEV(manufid, partid, instid, extrainfo) \
+ I3C_DEV_WITH_STATIC_ADDR(0x0, manufid, partid, \
+ instid, extrainfo)
+
+#endif
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (4 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 07/10] i3c: master: Add driver for Cadence IP Boris Brezillon
` (4 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Create an entry for the I3C subsystem and mark it as maintained by me.
There's no official git repository, patchwork instance, mailing list or
website yet, but this will be added after the subsystem has been
accepted.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
Changes in v5:
- Add the sysfs ABI file
---
MAINTAINERS | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 192d7f73fd01..62ef9618b2ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6764,6 +6764,16 @@ L: linux-i2c@vger.kernel.org
S: Maintained
F: drivers/i2c/i2c-stub.c
+I3C SUBSYSTEM
+M: Boris Brezillon <boris.brezillon@bootlin.com>
+S: Maintained
+F: Documentation/ABI/testing/sysfs-bus-i3c
+F: Documentation/devicetree/bindings/i3c/
+F: Documentation/driver-api/i3c
+F: drivers/i3c/
+F: include/linux/i3c/
+F: include/dt-bindings/i3c/
+
IA64 (Itanium) PLATFORM
M: Tony Luck <tony.luck@intel.com>
M: Fenghua Yu <fenghua.yu@intel.com>
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 07/10] i3c: master: Add driver for Cadence IP
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (5 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 08/10] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
` (3 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Add a driver for Cadence I3C master IP.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
---
Changes in v6:
- Rework the attach/detach logic to match the new way of doing things.
- Use kcalloc() where appropriate
- Simplfy access to the RX/TX/IBI_DATA FIFOs
Changes in v5:
- Drop unused len var in cdns_i3c_master_handle_ibi()
- Get IBIR and CMDR depth from CONF_STATUS0
- s/2017/2018/ in copyright header
- Fix coding style issues
Changes in v4:
- Fix potential unsigned integer underflow
- Add missing static specific on IBI related functions
Changes in v3:
- Adjust to match I3C framework changes
- Implement support the CMD RESPONSE QUEUE and IBI QUEUE added in the
latest revision of Cadence master IP
- Remove support for HDR modes
Changes in v2:
- Add basic IBI support. Note that the IP is not really reliable with
regards to IBI because you can't extract IBI payloads as soon as you
have more than one IBI waiting in the HW queue. This is something
that will hopefully be addressed in future revisions of this IP
- Add a simple xfer queueing mechanism to optimize message queuing.
- Fix a few bugs
- Add support for Hot Join
---
drivers/i3c/master/Kconfig | 5 +
drivers/i3c/master/Makefile | 1 +
drivers/i3c/master/i3c-master-cdns.c | 1668 ++++++++++++++++++++++++++++++++++
3 files changed, 1674 insertions(+)
create mode 100644 drivers/i3c/master/i3c-master-cdns.c
diff --git a/drivers/i3c/master/Kconfig b/drivers/i3c/master/Kconfig
index e69de29bb2d1..56b9a18543b2 100644
--- a/drivers/i3c/master/Kconfig
+++ b/drivers/i3c/master/Kconfig
@@ -0,0 +1,5 @@
+config CDNS_I3C_MASTER
+ tristate "Cadence I3C master driver"
+ depends on I3C
+ help
+ Enable this driver if you want to support Cadence I3C master block.
diff --git a/drivers/i3c/master/Makefile b/drivers/i3c/master/Makefile
index e69de29bb2d1..4c4304aa9534 100644
--- a/drivers/i3c/master/Makefile
+++ b/drivers/i3c/master/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CDNS_I3C_MASTER) += i3c-master-cdns.o
diff --git a/drivers/i3c/master/i3c-master-cdns.c b/drivers/i3c/master/i3c-master-cdns.c
new file mode 100644
index 000000000000..1874486a41e9
--- /dev/null
+++ b/drivers/i3c/master/i3c-master-cdns.c
@@ -0,0 +1,1668 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#include <linux/bitops.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/i3c/master.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/ioport.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/workqueue.h>
+
+#define DEV_ID 0x0
+#define DEV_ID_I3C_MASTER 0x5034
+
+#define CONF_STATUS0 0x4
+#define CONF_STATUS0_CMDR_DEPTH(x) (4 << (((x) & GENMASK(31, 29)) >> 29))
+#define CONF_STATUS0_ECC_CHK BIT(28)
+#define CONF_STATUS0_INTEG_CHK BIT(27)
+#define CONF_STATUS0_CSR_DAP_CHK BIT(26)
+#define CONF_STATUS0_TRANS_TOUT_CHK BIT(25)
+#define CONF_STATUS0_PROT_FAULTS_CHK BIT(24)
+#define CONF_STATUS0_GPO_NUM(x) (((x) & GENMASK(23, 16)) >> 16)
+#define CONF_STATUS0_GPI_NUM(x) (((x) & GENMASK(15, 8)) >> 8)
+#define CONF_STATUS0_IBIR_DEPTH(x) (4 << (((x) & GENMASK(7, 6)) >> 7))
+#define CONF_STATUS0_SUPPORTS_DDR BIT(5)
+#define CONF_STATUS0_SEC_MASTER BIT(4)
+#define CONF_STATUS0_DEVS_NUM(x) ((x) & GENMASK(3, 0))
+
+#define CONF_STATUS1 0x8
+#define CONF_STATUS1_IBI_HW_RES(x) ((((x) & GENMASK(31, 28)) >> 28) + 1)
+#define CONF_STATUS1_CMD_DEPTH(x) (4 << (((x) & GENMASK(27, 26)) >> 26))
+#define CONF_STATUS1_SLVDDR_RX_DEPTH(x) (8 << (((x) & GENMASK(25, 21)) >> 21))
+#define CONF_STATUS1_SLVDDR_TX_DEPTH(x) (8 << (((x) & GENMASK(20, 16)) >> 16))
+#define CONF_STATUS1_IBI_DEPTH(x) (2 << (((x) & GENMASK(12, 10)) >> 10))
+#define CONF_STATUS1_RX_DEPTH(x) (8 << (((x) & GENMASK(9, 5)) >> 5))
+#define CONF_STATUS1_TX_DEPTH(x) (8 << ((x) & GENMASK(4, 0)))
+
+#define REV_ID 0xc
+#define REV_ID_VID(id) (((id) & GENMASK(31, 20)) >> 20)
+#define REV_ID_PID(id) (((id) & GENMASK(19, 8)) >> 8)
+#define REV_ID_REV_MAJOR(id) (((id) & GENMASK(7, 4)) >> 4)
+#define REV_ID_REV_MINOR(id) ((id) & GENMASK(3, 0))
+
+#define CTRL 0x10
+#define CTRL_DEV_EN BIT(31)
+#define CTRL_HALT_EN BIT(30)
+#define CTRL_MCS BIT(29)
+#define CTRL_MCS_EN BIT(28)
+#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(9, 0)
+
+#define PRESCL_CTRL1 0x18
+#define PRESCL_CTRL1_PP_LOW_MASK GENMASK(15, 8)
+#define PRESCL_CTRL1_PP_LOW(x) ((x) << 8)
+#define PRESCL_CTRL1_OD_LOW_MASK GENMASK(7, 0)
+#define PRESCL_CTRL1_OD_LOW(x) (x)
+
+#define MST_IER 0x20
+#define MST_IDR 0x24
+#define MST_IMR 0x28
+#define MST_ICR 0x2c
+#define MST_ISR 0x30
+#define MST_INT_HALTED BIT(18)
+#define MST_INT_MR_DONE BIT(17)
+#define MST_INT_IMM_COMP BIT(16)
+#define MST_INT_TX_THR BIT(15)
+#define MST_INT_TX_OVF BIT(14)
+#define MST_INT_IBID_THR BIT(12)
+#define MST_INT_IBID_UNF BIT(11)
+#define MST_INT_IBIR_THR BIT(10)
+#define MST_INT_IBIR_UNF BIT(9)
+#define MST_INT_IBIR_OVF BIT(8)
+#define MST_INT_RX_THR BIT(7)
+#define MST_INT_RX_UNF BIT(6)
+#define MST_INT_CMDD_EMP BIT(5)
+#define MST_INT_CMDD_THR BIT(4)
+#define MST_INT_CMDD_OVF BIT(3)
+#define MST_INT_CMDR_THR BIT(2)
+#define MST_INT_CMDR_UNF BIT(1)
+#define MST_INT_CMDR_OVF BIT(0)
+
+#define MST_STATUS0 0x34
+#define MST_STATUS0_IDLE BIT(18)
+#define MST_STATUS0_HALTED BIT(17)
+#define MST_STATUS0_MASTER_MODE BIT(16)
+#define MST_STATUS0_TX_FULL BIT(13)
+#define MST_STATUS0_IBID_FULL BIT(12)
+#define MST_STATUS0_IBIR_FULL BIT(11)
+#define MST_STATUS0_RX_FULL BIT(10)
+#define MST_STATUS0_CMDD_FULL BIT(9)
+#define MST_STATUS0_CMDR_FULL BIT(8)
+#define MST_STATUS0_TX_EMP BIT(5)
+#define MST_STATUS0_IBID_EMP BIT(4)
+#define MST_STATUS0_IBIR_EMP BIT(3)
+#define MST_STATUS0_RX_EMP BIT(2)
+#define MST_STATUS0_CMDD_EMP BIT(1)
+#define MST_STATUS0_CMDR_EMP BIT(0)
+
+#define CMDR 0x38
+#define CMDR_NO_ERROR 0
+#define CMDR_DDR_PREAMBLE_ERROR 1
+#define CMDR_DDR_PARITY_ERROR 2
+#define CMDR_DDR_RX_FIFO_OVF 3
+#define CMDR_DDR_TX_FIFO_UNF 4
+#define CMDR_M0_ERROR 5
+#define CMDR_M1_ERROR 6
+#define CMDR_M2_ERROR 7
+#define CMDR_MST_ABORT 8
+#define CMDR_NACK_RESP 9
+#define CMDR_INVALID_DA 10
+#define CMDR_DDR_DROPPED 11
+#define CMDR_ERROR(x) (((x) & GENMASK(27, 24)) >> 24)
+#define CMDR_XFER_BYTES(x) (((x) & GENMASK(19, 8)) >> 8)
+#define CMDR_CMDID_HJACK_DISEC 0xfe
+#define CMDR_CMDID_HJACK_ENTDAA 0xff
+#define CMDR_CMDID(x) ((x) & GENMASK(7, 0))
+
+#define IBIR 0x3c
+#define IBIR_ACKED BIT(12)
+#define IBIR_SLVID(x) (((x) & GENMASK(11, 8)) >> 8)
+#define IBIR_ERROR BIT(7)
+#define IBIR_XFER_BYTES(x) (((x) & GENMASK(6, 2)) >> 2)
+#define IBIR_TYPE_IBI 0
+#define IBIR_TYPE_HJ 1
+#define IBIR_TYPE_MR 2
+#define IBIR_TYPE(x) ((x) & GENMASK(1, 0))
+
+#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_DA_UPD BIT(15)
+#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_DA(x) (((s) & GENMASK(15, 9)) >> 9)
+#define SLV_STATUS1_HAS_DA BIT(8)
+#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_CMDID(id) ((id) << 24)
+#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 IBIR_THR(t) ((t) << 24)
+#define CMDR_THR(t) ((t) << 16)
+#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_IBI_RESP BIT(23)
+#define FLUSH_CMD_RESP BIT(22)
+#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 TTO_PRESCL_CTRL0 0xb0
+#define TTO_PRESCL_CTRL0_DIVB(x) ((x) << 16)
+#define TTO_PRESCL_CTRL0_DIVA(x) (x)
+
+#define TTO_PRESCL_CTRL1 0xb4
+#define TTO_PRESCL_CTRL1_DIVB(x) ((x) << 16)
+#define TTO_PRESCL_CTRL1_DIVA(x) (x)
+
+#define DEVS_CTRL 0xb8
+#define DEVS_CTRL_DEV_CLR_SHIFT 16
+#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 DEVS_CTRL_DEVS_ACTIVE_MASK GENMASK(15, 0)
+#define MAX_DEVS 16
+
+#define DEV_ID_RR0(d) (0xc0 + ((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_DEV_ADDR_MASK (GENMASK(6, 0) | GENMASK(15, 13))
+#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) (0xc4 + ((d) * 0x10))
+#define DEV_ID_RR1_PID_MSB(pid) (pid)
+
+#define DEV_ID_RR2(d) (0xc8 + ((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) (0x180 + ((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_CONF_MASK(d) (GENMASK(15, 0) << (((d) % 2) ? 16 : 0))
+#define SIR_MAP_DEV_CONF(d, c) ((c) << (((d) % 2) ? 16 : 0))
+#define DEV_ROLE_SLAVE 0
+#define DEV_ROLE_MASTER 1
+#define SIR_MAP_DEV_ROLE(role) ((role) << 14)
+#define SIR_MAP_DEV_SLOW BIT(13)
+#define SIR_MAP_DEV_PL(l) ((l) << 8)
+#define SIR_MAP_PL_MAX GENMASK(4, 0)
+#define SIR_MAP_DEV_DA(a) ((a) << 1)
+#define SIR_MAP_DEV_ACK BIT(0)
+
+#define GPIR_WORD(x) (0x200 + ((x) * 4))
+#define GPI_REG(val, id) \
+ (((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+#define GPOR_WORD(x) (0x220 + ((x) * 4))
+#define GPO_REG(val, id) \
+ (((val) >> (((id) % 4) * 8)) & GENMASK(7, 0))
+
+#define ASF_INT_STATUS 0x300
+#define ASF_INT_RAW_STATUS 0x304
+#define ASF_INT_MASK 0x308
+#define ASF_INT_TEST 0x30c
+#define ASF_INT_FATAL_SELECT 0x310
+#define ASF_INTEGRITY_ERR BIT(6)
+#define ASF_PROTOCOL_ERR BIT(5)
+#define ASF_TRANS_TIMEOUT_ERR BIT(4)
+#define ASF_CSR_ERR BIT(3)
+#define ASF_DAP_ERR BIT(2)
+#define ASF_SRAM_UNCORR_ERR BIT(1)
+#define ASF_SRAM_CORR_ERR BIT(0)
+
+#define ASF_SRAM_CORR_FAULT_STATUS 0x320
+#define ASF_SRAM_UNCORR_FAULT_STATUS 0x324
+#define ASF_SRAM_CORR_FAULT_INSTANCE(x) ((x) >> 24)
+#define ASF_SRAM_CORR_FAULT_ADDR(x) ((x) & GENMASK(23, 0))
+
+#define ASF_SRAM_FAULT_STATS 0x328
+#define ASF_SRAM_FAULT_UNCORR_STATS(x) ((x) >> 16)
+#define ASF_SRAM_FAULT_CORR_STATS(x) ((x) & GENMASK(15, 0))
+
+#define ASF_TRANS_TOUT_CTRL 0x330
+#define ASF_TRANS_TOUT_EN BIT(31)
+#define ASF_TRANS_TOUT_VAL(x) (x)
+
+#define ASF_TRANS_TOUT_FAULT_MASK 0x334
+#define ASF_TRANS_TOUT_FAULT_STATUS 0x338
+#define ASF_TRANS_TOUT_FAULT_APB BIT(3)
+#define ASF_TRANS_TOUT_FAULT_SCL_LOW BIT(2)
+#define ASF_TRANS_TOUT_FAULT_SCL_HIGH BIT(1)
+#define ASF_TRANS_TOUT_FAULT_FSCL_HIGH BIT(0)
+
+#define ASF_PROTO_FAULT_MASK 0x340
+#define ASF_PROTO_FAULT_STATUS 0x344
+#define ASF_PROTO_FAULT_SLVSDR_RD_ABORT BIT(31)
+#define ASF_PROTO_FAULT_SLVDDR_FAIL BIT(30)
+#define ASF_PROTO_FAULT_S(x) BIT(16 + (x))
+#define ASF_PROTO_FAULT_MSTSDR_RD_ABORT BIT(15)
+#define ASF_PROTO_FAULT_MSTDDR_FAIL BIT(14)
+#define ASF_PROTO_FAULT_M(x) BIT(x)
+
+struct cdns_i3c_master_caps {
+ u32 cmdfifodepth;
+ u32 cmdrfifodepth;
+ u32 txfifodepth;
+ u32 rxfifodepth;
+ u32 ibirfifodepth;
+};
+
+struct cdns_i3c_cmd {
+ u32 cmd0;
+ u32 cmd1;
+ u32 tx_len;
+ const void *tx_buf;
+ u32 rx_len;
+ void *rx_buf;
+ u32 error;
+};
+
+struct cdns_i3c_xfer {
+ struct list_head node;
+ struct completion comp;
+ int ret;
+ unsigned int ncmds;
+ struct cdns_i3c_cmd cmds[0];
+};
+
+struct cdns_i3c_master {
+ struct work_struct hj_work;
+ struct i3c_master_controller base;
+ u32 free_rr_slots;
+ unsigned int maxdevs;
+ struct {
+ unsigned int num_slots;
+ struct i3c_dev_desc **slots;
+ spinlock_t lock;
+ } ibi;
+ struct {
+ struct list_head list;
+ struct cdns_i3c_xfer *cur;
+ spinlock_t lock;
+ } xferqueue;
+ void __iomem *regs;
+ struct clk *sysclk;
+ struct clk *pclk;
+ struct cdns_i3c_master_caps caps;
+ unsigned long i3c_scl_lim;
+};
+
+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)
+{
+ writesl(master->regs + TX_FIFO, bytes, nbytes & ~3);
+ if (nbytes & 3) {
+ u32 tmp = 0;
+
+ memcpy(&tmp, bytes + (nbytes & ~3), nbytes & 3);
+ __raw_writel(tmp, master->regs + TX_FIFO);
+ }
+}
+
+static void cdns_i3c_master_rd_from_rx_fifo(struct cdns_i3c_master *master,
+ u8 *bytes, int nbytes)
+{
+ readsl(master->regs + RX_FIFO, bytes, nbytes & ~3);
+ if (nbytes & 3) {
+ u32 tmp = __raw_readl(master->regs + RX_FIFO);
+
+ memcpy(bytes + (nbytes & ~3), &tmp, nbytes & 3);
+ }
+}
+
+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 int cdns_i3c_master_disable(struct cdns_i3c_master *master)
+{
+ u32 status;
+
+ writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN, master->regs + CTRL);
+
+ return readl_poll_timeout(master->regs + MST_STATUS0, status,
+ status & MST_STATUS0_IDLE, 10, 1000000);
+}
+
+static void cdns_i3c_master_enable(struct cdns_i3c_master *master)
+{
+ writel(readl(master->regs + CTRL) | CTRL_DEV_EN, master->regs + CTRL);
+}
+
+static struct cdns_i3c_xfer *
+cdns_i3c_master_alloc_xfer(struct cdns_i3c_master *master, unsigned int ncmds)
+{
+ struct cdns_i3c_xfer *xfer;
+
+ xfer = kzalloc(sizeof(*xfer) + (ncmds * sizeof(*xfer->cmds)),
+ GFP_KERNEL);
+ if (!xfer)
+ return NULL;
+
+ INIT_LIST_HEAD(&xfer->node);
+ xfer->ncmds = ncmds;
+ xfer->ret = -ETIMEDOUT;
+
+ return xfer;
+}
+
+static void cdns_i3c_master_free_xfer(struct cdns_i3c_xfer *xfer)
+{
+ kfree(xfer);
+}
+
+static void cdns_i3c_master_start_xfer_locked(struct cdns_i3c_master *master)
+{
+ struct cdns_i3c_xfer *xfer = master->xferqueue.cur;
+ unsigned int i;
+
+ if (!xfer)
+ return;
+
+ writel(MST_INT_CMDD_EMP, master->regs + MST_ICR);
+ for (i = 0; i < xfer->ncmds; i++) {
+ struct cdns_i3c_cmd *cmd = &xfer->cmds[i];
+
+ cdns_i3c_master_wr_to_tx_fifo(master, cmd->tx_buf,
+ cmd->tx_len);
+ }
+
+ for (i = 0; i < xfer->ncmds; i++) {
+ struct cdns_i3c_cmd *cmd = &xfer->cmds[i];
+
+ writel(cmd->cmd1 | CMD1_FIFO_CMDID(i),
+ master->regs + CMD1_FIFO);
+ writel(cmd->cmd0, master->regs + CMD0_FIFO);
+ }
+
+ writel(readl(master->regs + CTRL) | CTRL_MCS,
+ master->regs + CTRL);
+ writel(MST_INT_CMDD_EMP, master->regs + MST_IER);
+}
+
+static void cdns_i3c_master_end_xfer_locked(struct cdns_i3c_master *master,
+ u32 isr)
+{
+ struct cdns_i3c_xfer *xfer = master->xferqueue.cur;
+ int i, ret = 0;
+ u32 status0;
+
+ if (!xfer)
+ return;
+
+ if (!(isr & MST_INT_CMDD_EMP))
+ return;
+
+ writel(MST_INT_CMDD_EMP, master->regs + MST_IDR);
+
+ for (status0 = readl(master->regs + MST_STATUS0);
+ !(status0 & MST_STATUS0_CMDR_EMP);
+ status0 = readl(master->regs + MST_STATUS0)) {
+ struct cdns_i3c_cmd *cmd;
+ u32 cmdr, rx_len, id;
+
+ cmdr = readl(master->regs + CMDR);
+ id = CMDR_CMDID(cmdr);
+ if (id == CMDR_CMDID_HJACK_DISEC ||
+ id == CMDR_CMDID_HJACK_ENTDAA ||
+ WARN_ON(id >= xfer->ncmds))
+ continue;
+
+ cmd = &xfer->cmds[CMDR_CMDID(cmdr)];
+ rx_len = min_t(u32, CMDR_XFER_BYTES(cmdr), cmd->rx_len);
+ cdns_i3c_master_rd_from_rx_fifo(master, cmd->rx_buf, rx_len);
+ cmd->error = CMDR_ERROR(cmdr);
+ }
+
+ for (i = 0; i < xfer->ncmds; i++) {
+ switch (xfer->cmds[i].error) {
+ case CMDR_NO_ERROR:
+ break;
+
+ case CMDR_DDR_PREAMBLE_ERROR:
+ case CMDR_DDR_PARITY_ERROR:
+ case CMDR_M0_ERROR:
+ case CMDR_M1_ERROR:
+ case CMDR_M2_ERROR:
+ case CMDR_MST_ABORT:
+ case CMDR_NACK_RESP:
+ case CMDR_DDR_DROPPED:
+ ret = -EIO;
+ break;
+
+ case CMDR_DDR_RX_FIFO_OVF:
+ case CMDR_DDR_TX_FIFO_UNF:
+ ret = -ENOSPC;
+ break;
+
+ case CMDR_INVALID_DA:
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ }
+
+ xfer->ret = ret;
+ complete(&xfer->comp);
+
+ xfer = list_first_entry_or_null(&master->xferqueue.list,
+ struct cdns_i3c_xfer, node);
+ if (xfer)
+ list_del_init(&xfer->node);
+
+ master->xferqueue.cur = xfer;
+ cdns_i3c_master_start_xfer_locked(master);
+}
+
+static void cdns_i3c_master_queue_xfer(struct cdns_i3c_master *master,
+ struct cdns_i3c_xfer *xfer)
+{
+ unsigned long flags;
+
+ init_completion(&xfer->comp);
+ spin_lock_irqsave(&master->xferqueue.lock, flags);
+ if (master->xferqueue.cur) {
+ list_add_tail(&xfer->node, &master->xferqueue.list);
+ } else {
+ master->xferqueue.cur = xfer;
+ cdns_i3c_master_start_xfer_locked(master);
+ }
+ spin_unlock_irqrestore(&master->xferqueue.lock, flags);
+}
+
+static void cdns_i3c_master_unqueue_xfer(struct cdns_i3c_master *master,
+ struct cdns_i3c_xfer *xfer)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&master->xferqueue.lock, flags);
+ if (master->xferqueue.cur == xfer) {
+ u32 status;
+
+ writel(readl(master->regs + CTRL) & ~CTRL_DEV_EN,
+ master->regs + CTRL);
+ readl_poll_timeout_atomic(master->regs + MST_STATUS0, status,
+ status & MST_STATUS0_IDLE, 10,
+ 1000000);
+ master->xferqueue.cur = NULL;
+ writel(FLUSH_RX_FIFO | FLUSH_TX_FIFO | FLUSH_CMD_FIFO |
+ FLUSH_CMD_RESP,
+ master->regs + FLUSH_CTRL);
+ writel(MST_INT_CMDD_EMP, master->regs + MST_IDR);
+ writel(readl(master->regs + CTRL) | CTRL_DEV_EN,
+ master->regs + CTRL);
+ } else {
+ list_del_init(&xfer->node);
+ }
+ spin_unlock_irqrestore(&master->xferqueue.lock, flags);
+}
+
+static enum i3c_error_code cdns_i3c_cmd_get_err(struct cdns_i3c_cmd *cmd)
+{
+ switch (cmd->error) {
+ case CMDR_M0_ERROR:
+ return I3C_ERROR_M0;
+
+ case CMDR_M1_ERROR:
+ return I3C_ERROR_M1;
+
+ case CMDR_M2_ERROR:
+ case CMDR_NACK_RESP:
+ return I3C_ERROR_M2;
+
+ default:
+ break;
+ }
+
+ return I3C_ERROR_UNKNOWN;
+}
+
+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);
+ struct cdns_i3c_xfer *xfer;
+ struct cdns_i3c_cmd *ccmd;
+ int ret;
+
+ xfer = cdns_i3c_master_alloc_xfer(master, 1);
+ if (!xfer)
+ return -ENOMEM;
+
+ ccmd = xfer->cmds;
+ ccmd->cmd1 = CMD1_FIFO_CCC(cmd->id);
+ ccmd->cmd0 = CMD0_FIFO_IS_CCC |
+ CMD0_FIFO_PL_LEN(cmd->dests[0].payload.len);
+
+ if (cmd->id & I3C_CCC_DIRECT)
+ ccmd->cmd0 |= CMD0_FIFO_DEV_ADDR(cmd->dests[0].addr);
+
+ if (cmd->rnw) {
+ ccmd->cmd0 |= CMD0_FIFO_RNW;
+ ccmd->rx_buf = cmd->dests[0].payload.data;
+ ccmd->rx_len = cmd->dests[0].payload.len;
+ } else {
+ ccmd->tx_buf = cmd->dests[0].payload.data;
+ ccmd->tx_len = cmd->dests[0].payload.len;
+ }
+
+ cdns_i3c_master_queue_xfer(master, xfer);
+ if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+ cdns_i3c_master_unqueue_xfer(master, xfer);
+
+ ret = xfer->ret;
+ cmd->err = cdns_i3c_cmd_get_err(&xfer->cmds[0]);
+ cdns_i3c_master_free_xfer(xfer);
+
+ return ret;
+}
+
+static int cdns_i3c_master_priv_xfers(struct i3c_dev_desc *dev,
+ struct i3c_priv_xfer *xfers,
+ int nxfers)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ int txslots = 0, rxslots = 0, i, ret;
+ struct cdns_i3c_xfer *cdns_xfer;
+
+ for (i = 0; i < nxfers; i++) {
+ if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+ return -ENOTSUPP;
+ }
+
+ if (!nxfers)
+ return 0;
+
+ if (nxfers > master->caps.cmdfifodepth ||
+ nxfers > master->caps.cmdrfifodepth)
+ return -ENOTSUPP;
+
+ /*
+ * First make sure that all transactions (block of transfers separated
+ * by a STOP marker) fit in the FIFOs.
+ */
+ for (i = 0; i < nxfers; i++) {
+ if (xfers[i].rnw)
+ rxslots += DIV_ROUND_UP(xfers[i].len, 4);
+ else
+ txslots += DIV_ROUND_UP(xfers[i].len, 4);
+ }
+
+ if (rxslots > master->caps.rxfifodepth ||
+ txslots > master->caps.txfifodepth)
+ return -ENOTSUPP;
+
+ cdns_xfer = cdns_i3c_master_alloc_xfer(master, nxfers);
+ if (!cdns_xfer)
+ return -ENOMEM;
+
+ for (i = 0; i < nxfers; i++) {
+ struct cdns_i3c_cmd *ccmd = &cdns_xfer->cmds[i];
+ u32 pl_len = xfers[i].len;
+
+ ccmd->cmd0 = CMD0_FIFO_DEV_ADDR(dev->info.dyn_addr) |
+ CMD0_FIFO_PRIV_XMIT_MODE(XMIT_BURST_WITHOUT_SUBADDR);
+
+ if (xfers[i].rnw) {
+ ccmd->cmd0 |= CMD0_FIFO_RNW;
+ ccmd->rx_buf = xfers[i].data.in;
+ ccmd->rx_len = xfers[i].len;
+ pl_len++;
+ } else {
+ ccmd->tx_buf = xfers[i].data.out;
+ ccmd->tx_len = xfers[i].len;
+ }
+
+ ccmd->cmd0 |= CMD0_FIFO_PL_LEN(pl_len);
+
+ if (i < nxfers - 1)
+ ccmd->cmd0 |= CMD0_FIFO_RSBC;
+
+ if (!i)
+ ccmd->cmd0 |= CMD0_FIFO_BCH;
+ }
+
+ cdns_i3c_master_queue_xfer(master, cdns_xfer);
+ if (!wait_for_completion_timeout(&cdns_xfer->comp,
+ msecs_to_jiffies(1000)))
+ cdns_i3c_master_unqueue_xfer(master, cdns_xfer);
+
+ ret = cdns_xfer->ret;
+
+ for (i = 0; i < nxfers; i++)
+ xfers[i].err = cdns_i3c_cmd_get_err(&cdns_xfer->cmds[i]);
+
+ cdns_i3c_master_free_xfer(cdns_xfer);
+
+ return ret;
+}
+
+static int cdns_i3c_master_i2c_xfers(struct i2c_dev_desc *dev,
+ const struct i2c_msg *xfers, int nxfers)
+{
+ struct i3c_master_controller *m = i2c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ unsigned int nrxwords = 0, ntxwords = 0;
+ struct cdns_i3c_xfer *xfer;
+ int i, ret = 0;
+
+ if (nxfers > master->caps.cmdfifodepth)
+ return -ENOTSUPP;
+
+ for (i = 0; i < nxfers; i++) {
+ if (xfers[i].len > CMD0_FIFO_PL_LEN_MAX)
+ return -ENOTSUPP;
+
+ if (xfers[i].flags & I2C_M_RD)
+ nrxwords += DIV_ROUND_UP(xfers[i].len, 4);
+ else
+ ntxwords += DIV_ROUND_UP(xfers[i].len, 4);
+ }
+
+ if (ntxwords > master->caps.txfifodepth ||
+ nrxwords > master->caps.rxfifodepth)
+ return -ENOTSUPP;
+
+ xfer = cdns_i3c_master_alloc_xfer(master, nxfers);
+ if (!xfer)
+ return -ENOMEM;
+
+ for (i = 0; i < nxfers; i++) {
+ struct cdns_i3c_cmd *ccmd = &xfer->cmds[0];
+
+ ccmd->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)
+ ccmd->cmd0 |= CMD0_FIFO_IS_10B;
+
+ if (xfers[i].flags & I2C_M_RD) {
+ ccmd->cmd0 |= CMD0_FIFO_RNW;
+ ccmd->rx_buf = xfers[i].buf;
+ ccmd->rx_len = xfers[i].len;
+ } else {
+ ccmd->tx_buf = xfers[i].buf;
+ ccmd->tx_len = xfers[i].len;
+ }
+ }
+
+ cdns_i3c_master_queue_xfer(master, xfer);
+ if (!wait_for_completion_timeout(&xfer->comp, msecs_to_jiffies(1000)))
+ cdns_i3c_master_unqueue_xfer(master, xfer);
+
+ ret = xfer->ret;
+ cdns_i3c_master_free_xfer(xfer);
+
+ return ret;
+}
+
+static u32 cdns_i3c_master_i2c_funcs(struct i3c_master_controller *m)
+{
+ return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
+}
+
+struct cdns_i3c_i2c_dev_data {
+ u16 id;
+ s16 ibi;
+ struct i3c_generic_ibi_pool *ibi_pool;
+};
+
+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 void cdns_i3c_master_upd_i3c_addr(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+ u32 rr;
+
+ rr = prepare_rr0_dev_address(dev->info.dyn_addr ?
+ dev->info.dyn_addr :
+ dev->info.static_addr);
+ writel(DEV_ID_RR0_IS_I3C | rr, master->regs + DEV_ID_RR0(data->id));
+}
+
+static int cdns_i3c_master_get_rr_slot(struct cdns_i3c_master *master,
+ u8 dyn_addr)
+{
+ u32 activedevs, rr;
+ int i;
+
+ if (!dyn_addr) {
+ if (!master->free_rr_slots)
+ return -ENOSPC;
+
+ return ffs(master->free_rr_slots) - 1;
+ }
+
+ activedevs = readl(master->regs + DEVS_CTRL) &
+ DEVS_CTRL_DEVS_ACTIVE_MASK;
+
+ for (i = 1; i <= master->maxdevs; i++) {
+ if (!(BIT(i) & activedevs))
+ continue;
+
+ rr = readl(master->regs + DEV_ID_RR0(i));
+ if (!(rr & DEV_ID_RR0_IS_I3C) ||
+ DEV_ID_RR0_GET_DEV_ADDR(rr) != dyn_addr)
+ continue;
+
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int cdns_i3c_master_reattach_i3c_dev(struct i3c_dev_desc *dev,
+ u8 old_dyn_addr)
+{
+ cdns_i3c_master_upd_i3c_addr(dev);
+
+ return 0;
+}
+
+static int cdns_i3c_master_attach_i3c_dev(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data;
+ int slot;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ slot = cdns_i3c_master_get_rr_slot(master, dev->info.dyn_addr);
+ if (slot < 0) {
+ kfree(data);
+ return slot;
+ }
+
+ data->ibi = -1;
+ data->id = slot;
+ i3c_dev_set_master_data(dev, data);
+ master->free_rr_slots &= ~BIT(slot);
+
+ if (!dev->info.dyn_addr) {
+ cdns_i3c_master_upd_i3c_addr(dev);
+ 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 i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_CLR(data->id),
+ master->regs + DEVS_CTRL);
+
+ i3c_dev_set_master_data(dev, NULL);
+ master->free_rr_slots |= BIT(data->id);
+ kfree(data);
+}
+
+static int cdns_i3c_master_attach_i2c_dev(struct i2c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i2c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data;
+ int slot;
+
+ slot = cdns_i3c_master_get_rr_slot(master, 0);
+ if (slot < 0)
+ return slot;
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->id = slot;
+ master->free_rr_slots &= ~BIT(slot);
+ i2c_dev_set_master_data(dev, data);
+
+ writel(prepare_rr0_dev_address(dev->boardinfo->base.addr) |
+ (dev->boardinfo->base.flags & I2C_CLIENT_TEN ?
+ DEV_ID_RR0_LVR_EXT_ADDR : 0),
+ master->regs + DEV_ID_RR0(data->id));
+ writel(dev->boardinfo->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 i2c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i2c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i2c_dev_get_master_data(dev);
+
+ writel(readl(master->regs + DEVS_CTRL) |
+ DEVS_CTRL_DEV_CLR(data->id),
+ master->regs + DEVS_CTRL);
+ master->free_rr_slots |= BIT(data->id);
+
+ i2c_dev_set_master_data(dev, NULL);
+ kfree(data);
+}
+
+static void cdns_i3c_master_bus_cleanup(struct i3c_master_controller *m)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+
+ cdns_i3c_master_disable(master);
+}
+
+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 void cdns_i3c_master_upd_i3c_scl_lim(struct cdns_i3c_master *master)
+{
+ struct i3c_master_controller *m = &master->base;
+ unsigned long i3c_lim_period, pres_step, ncycles;
+ unsigned long new_i3c_scl_lim = 0;
+ struct i3c_dev_desc *dev;
+ u32 prescl1, ctrl;
+
+ i3c_bus_for_each_i3cdev(m->bus, dev) {
+ unsigned long max_fscl;
+
+ max_fscl = max(I3C_CCC_MAX_SDR_FSCL(dev->info.max_read_ds),
+ I3C_CCC_MAX_SDR_FSCL(dev->info.max_write_ds));
+ switch (max_fscl) {
+ case I3C_SDR1_FSCL_8MHZ:
+ max_fscl = 8000000;
+ break;
+ case I3C_SDR2_FSCL_6MHZ:
+ max_fscl = 6000000;
+ break;
+ case I3C_SDR3_FSCL_4MHZ:
+ max_fscl = 4000000;
+ break;
+ case I3C_SDR4_FSCL_2MHZ:
+ max_fscl = 2000000;
+ break;
+ case I3C_SDR0_FSCL_MAX:
+ default:
+ max_fscl = 0;
+ break;
+ }
+
+ if (max_fscl &&
+ (new_i3c_scl_lim > max_fscl || !new_i3c_scl_lim))
+ new_i3c_scl_lim = max_fscl;
+ }
+
+ /* Only update PRESCL_CTRL1 if the I3C SCL limitation has changed. */
+ if (new_i3c_scl_lim == master->i3c_scl_lim)
+ return;
+ master->i3c_scl_lim = new_i3c_scl_lim;
+ if (!new_i3c_scl_lim)
+ return;
+ pres_step = 1000000000UL / (master->base.bus->scl_rate.i3c * 4);
+
+ /* Configure PP_LOW to meet I3C slave limitations. */
+ prescl1 = readl(master->regs + PRESCL_CTRL1) &
+ ~PRESCL_CTRL1_PP_LOW_MASK;
+ ctrl = readl(master->regs + CTRL);
+
+ i3c_lim_period = DIV_ROUND_UP(1000000000, master->i3c_scl_lim);
+ ncycles = DIV_ROUND_UP(i3c_lim_period, pres_step);
+ if (ncycles < 4)
+ ncycles = 0;
+ else
+ ncycles -= 4;
+
+ prescl1 |= PRESCL_CTRL1_PP_LOW(ncycles);
+
+ /* Disable I3C master before updating PRESCL_CTRL1. */
+ if (ctrl & CTRL_DEV_EN)
+ cdns_i3c_master_disable(master);
+
+ writel(prescl1, master->regs + PRESCL_CTRL1);
+
+ if (ctrl & CTRL_DEV_EN)
+ cdns_i3c_master_enable(master);
+}
+
+static int cdns_i3c_master_do_daa(struct i3c_master_controller *m)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ unsigned long old_i3c_scl_lim;
+ u32 olddevs, newdevs;
+ int ret, slot;
+ u8 addrs[MAX_DEVS] = { };
+ u8 last_addr = 0;
+
+ olddevs = readl(master->regs + DEVS_CTRL) & DEVS_CTRL_DEVS_ACTIVE_MASK;
+
+ /* Prepare RR slots before launching DAA. */
+ for (slot = 1; slot <= master->maxdevs; slot++) {
+ if (olddevs & BIT(slot))
+ continue;
+
+ ret = i3c_master_get_free_addr(m, last_addr + 1);
+ if (ret < 0)
+ return -ENOSPC;
+
+ last_addr = ret;
+ addrs[slot] = last_addr;
+ 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));
+ }
+
+ ret = i3c_master_entdaa_locked(&master->base);
+ if (ret && ret != I3C_ERROR_M2)
+ return ret;
+
+ newdevs = readl(master->regs + DEVS_CTRL) & DEVS_CTRL_DEVS_ACTIVE_MASK;
+ newdevs &= ~olddevs;
+
+ /* Save the old limitation before add devices. */
+ old_i3c_scl_lim = master->i3c_scl_lim;
+
+ /*
+ * Clear all retaining registers filled during DAA. We already
+ * have the addressed assigned to them in the addrs array.
+ */
+ for (slot = 1; slot <= master->maxdevs; slot++) {
+ if (newdevs & BIT(slot))
+ i3c_master_add_i3c_dev_locked(m, addrs[slot]);
+ }
+
+ /*
+ * Clear slots that ended up not being used. Can be caused by I3C
+ * device creation failure or when the I3C device was already known
+ * by the system but with a different address (in this case the device
+ * already has a slot and does not need a new one).
+ */
+ writel(readl(master->regs + DEVS_CTRL) |
+ master->free_rr_slots << DEVS_CTRL_DEV_CLR_SHIFT,
+ master->regs + DEVS_CTRL);
+
+ i3c_master_defslvs_locked(&master->base);
+
+ cdns_i3c_master_upd_i3c_scl_lim(master);
+
+ /* Unmask Hot-Join and Mastership request interrupts. */
+ i3c_master_enec_locked(m, I3C_BROADCAST_ADDR,
+ I3C_CCC_EVENT_HJ | I3C_CCC_EVENT_MR);
+
+ return 0;
+}
+
+static int cdns_i3c_master_bus_init(struct i3c_master_controller *m)
+{
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ unsigned long pres_step, sysclk_rate, max_i2cfreq;
+ u32 ctrl, prescl0, prescl1, pres, low;
+ struct i3c_device_info info = { };
+ int ret, ncycles;
+
+ 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(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);
+
+ /* Get an address for the master. */
+ ret = i3c_master_get_free_addr(m, 0);
+ if (ret < 0)
+ return ret;
+
+ 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)
+ return ret;
+
+ /*
+ * Enable Hot-Join, and, when a Hot-Join request happens, disable all
+ * events coming from this device.
+ *
+ * We will issue ENTDAA afterwards from the threaded IRQ handler.
+ */
+ ctrl |= CTRL_HJ_ACK | CTRL_HJ_DISEC | CTRL_HALT_EN | CTRL_MCS_EN;
+ writel(ctrl, master->regs + CTRL);
+
+ cdns_i3c_master_enable(master);
+
+ return 0;
+}
+
+static void cdns_i3c_master_handle_ibi(struct cdns_i3c_master *master,
+ u32 ibir)
+{
+ struct cdns_i3c_i2c_dev_data *data;
+ bool data_consumed = false;
+ struct i3c_ibi_slot *slot;
+ u32 id = IBIR_SLVID(ibir);
+ struct i3c_dev_desc *dev;
+ size_t nbytes;
+ u8 *buf;
+
+ /*
+ * FIXME: maybe we should report the FIFO OVF errors to the upper
+ * layer.
+ */
+ if (id >= master->ibi.num_slots || (ibir & IBIR_ERROR))
+ goto out;
+
+ dev = master->ibi.slots[id];
+ spin_lock(&master->ibi.lock);
+
+ data = i3c_dev_get_master_data(dev);
+ slot = i3c_generic_ibi_get_free_slot(data->ibi_pool);
+ if (!slot)
+ goto out_unlock;
+
+ buf = slot->data;
+
+ nbytes = IBIR_XFER_BYTES(ibir);
+ readsl(master->regs + IBI_DATA_FIFO, buf, nbytes & ~3);
+ if (nbytes % 3) {
+ u32 tmp = __raw_readl(master->regs + IBI_DATA_FIFO);
+
+ memcpy(buf + (nbytes & ~3), &tmp, nbytes & 3);
+ }
+
+ slot->len = min_t(unsigned int, IBIR_XFER_BYTES(ibir),
+ dev->ibi->max_payload_len);
+ i3c_master_queue_ibi(dev, slot);
+ data_consumed = true;
+
+out_unlock:
+ spin_unlock(&master->ibi.lock);
+
+out:
+ /* Consume data from the FIFO if it's not been done already. */
+ if (!data_consumed) {
+ int i;
+
+ for (i = 0; i < IBIR_XFER_BYTES(ibir); i += 4)
+ readl(master->regs + IBI_DATA_FIFO);
+ }
+}
+
+static void cnds_i3c_master_demux_ibis(struct cdns_i3c_master *master)
+{
+ u32 status0;
+
+ writel(MST_INT_IBIR_THR, master->regs + MST_ICR);
+
+ for (status0 = readl(master->regs + MST_STATUS0);
+ !(status0 & MST_STATUS0_IBIR_EMP);
+ status0 = readl(master->regs + MST_STATUS0)) {
+ u32 ibir = readl(master->regs + IBIR);
+
+ switch (IBIR_TYPE(ibir)) {
+ case IBIR_TYPE_IBI:
+ cdns_i3c_master_handle_ibi(master, ibir);
+ break;
+
+ case IBIR_TYPE_HJ:
+ WARN_ON(IBIR_XFER_BYTES(ibir) || (ibir & IBIR_ERROR));
+ queue_work(master->base.wq, &master->hj_work);
+ break;
+
+ case IBIR_TYPE_MR:
+ WARN_ON(IBIR_XFER_BYTES(ibir) || (ibir & IBIR_ERROR));
+ default:
+ break;
+ }
+ }
+}
+
+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);
+ if (!(status & readl(master->regs + MST_IMR)))
+ return IRQ_NONE;
+
+ spin_lock(&master->xferqueue.lock);
+ cdns_i3c_master_end_xfer_locked(master, status);
+ spin_unlock(&master->xferqueue.lock);
+
+ if (status & MST_INT_IBIR_THR)
+ cnds_i3c_master_demux_ibis(master);
+
+ return IRQ_HANDLED;
+}
+
+static int cdns_i3c_master_disable_ibi(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+ unsigned long flags;
+ u32 sirmap;
+ int ret;
+
+ ret = i3c_master_disec_locked(m, dev->info.dyn_addr,
+ I3C_CCC_EVENT_SIR);
+ if (ret)
+ return ret;
+
+ spin_lock_irqsave(&master->ibi.lock, flags);
+ sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+ sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+ sirmap |= SIR_MAP_DEV_CONF(data->ibi,
+ SIR_MAP_DEV_DA(I3C_BROADCAST_ADDR));
+ writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+ spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+ return ret;
+}
+
+static int cdns_i3c_master_enable_ibi(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+ unsigned long flags;
+ u32 sircfg, sirmap;
+ int ret;
+
+ spin_lock_irqsave(&master->ibi.lock, flags);
+ sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+ sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+ sircfg = SIR_MAP_DEV_ROLE(dev->info.bcr >> 6) |
+ SIR_MAP_DEV_DA(dev->info.dyn_addr) |
+ SIR_MAP_DEV_PL(dev->info.max_ibi_len) |
+ SIR_MAP_DEV_ACK;
+
+ if (dev->info.bcr & I3C_BCR_MAX_DATA_SPEED_LIM)
+ sircfg |= SIR_MAP_DEV_SLOW;
+
+ sirmap |= SIR_MAP_DEV_CONF(data->ibi, sircfg);
+ writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+ spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+ ret = i3c_master_enec_locked(m, dev->info.dyn_addr,
+ I3C_CCC_EVENT_SIR);
+ if (ret) {
+ spin_lock_irqsave(&master->ibi.lock, flags);
+ sirmap = readl(master->regs + SIR_MAP_DEV_REG(data->ibi));
+ sirmap &= ~SIR_MAP_DEV_CONF_MASK(data->ibi);
+ sirmap |= SIR_MAP_DEV_CONF(data->ibi,
+ SIR_MAP_DEV_DA(I3C_BROADCAST_ADDR));
+ writel(sirmap, master->regs + SIR_MAP_DEV_REG(data->ibi));
+ spin_unlock_irqrestore(&master->ibi.lock, flags);
+ }
+
+ return ret;
+}
+
+static int cdns_i3c_master_request_ibi(struct i3c_dev_desc *dev,
+ const struct i3c_ibi_setup *req)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+ unsigned long flags;
+ unsigned int i;
+
+ data->ibi_pool = i3c_generic_ibi_alloc_pool(dev, req);
+ if (IS_ERR(data->ibi_pool))
+ return PTR_ERR(data->ibi_pool);
+
+ spin_lock_irqsave(&master->ibi.lock, flags);
+ for (i = 0; i < master->ibi.num_slots; i++) {
+ if (!master->ibi.slots[i]) {
+ data->ibi = i;
+ master->ibi.slots[i] = dev;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+ if (i < master->ibi.num_slots)
+ return 0;
+
+ i3c_generic_ibi_free_pool(data->ibi_pool);
+ data->ibi_pool = NULL;
+
+ return -ENOSPC;
+}
+
+static void cdns_i3c_master_free_ibi(struct i3c_dev_desc *dev)
+{
+ struct i3c_master_controller *m = i3c_dev_get_master(dev);
+ struct cdns_i3c_master *master = to_cdns_i3c_master(m);
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&master->ibi.lock, flags);
+ master->ibi.slots[data->ibi] = NULL;
+ data->ibi = -1;
+ spin_unlock_irqrestore(&master->ibi.lock, flags);
+
+ i3c_generic_ibi_free_pool(data->ibi_pool);
+}
+
+static void cdns_i3c_master_recycle_ibi_slot(struct i3c_dev_desc *dev,
+ struct i3c_ibi_slot *slot)
+{
+ struct cdns_i3c_i2c_dev_data *data = i3c_dev_get_master_data(dev);
+
+ i3c_generic_ibi_recycle_slot(data->ibi_pool, slot);
+}
+
+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,
+ .do_daa = cdns_i3c_master_do_daa,
+ .attach_i3c_dev = cdns_i3c_master_attach_i3c_dev,
+ .reattach_i3c_dev = cdns_i3c_master_reattach_i3c_dev,
+ .detach_i3c_dev = cdns_i3c_master_detach_i3c_dev,
+ .attach_i2c_dev = cdns_i3c_master_attach_i2c_dev,
+ .detach_i2c_dev = cdns_i3c_master_detach_i2c_dev,
+ .supports_ccc_cmd = cdns_i3c_master_supports_ccc_cmd,
+ .send_ccc_cmd = cdns_i3c_master_send_ccc_cmd,
+ .priv_xfers = cdns_i3c_master_priv_xfers,
+ .i2c_xfers = cdns_i3c_master_i2c_xfers,
+ .i2c_funcs = cdns_i3c_master_i2c_funcs,
+ .enable_ibi = cdns_i3c_master_enable_ibi,
+ .disable_ibi = cdns_i3c_master_disable_ibi,
+ .request_ibi = cdns_i3c_master_request_ibi,
+ .free_ibi = cdns_i3c_master_free_ibi,
+ .recycle_ibi_slot = cdns_i3c_master_recycle_ibi_slot,
+};
+
+static void cdns_i3c_master_hj(struct work_struct *work)
+{
+ struct cdns_i3c_master *master = container_of(work,
+ struct cdns_i3c_master,
+ hj_work);
+
+ i3c_master_do_daa(&master->base);
+}
+
+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;
+
+ 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;
+
+ if (readl(master->regs + DEV_ID) != DEV_ID_I3C_MASTER) {
+ ret = -EINVAL;
+ goto err_disable_sysclk;
+ }
+
+ spin_lock_init(&master->xferqueue.lock);
+ INIT_LIST_HEAD(&master->xferqueue.list);
+
+ INIT_WORK(&master->hj_work, cdns_i3c_master_hj);
+ 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_STATUS0);
+
+ /* Device ID0 is reserved to describe this master. */
+ master->maxdevs = CONF_STATUS0_DEVS_NUM(val);
+ master->free_rr_slots = GENMASK(master->maxdevs, 1);
+
+ val = readl(master->regs + CONF_STATUS1);
+ master->caps.cmdfifodepth = CONF_STATUS1_CMD_DEPTH(val);
+ master->caps.rxfifodepth = CONF_STATUS1_RX_DEPTH(val);
+ master->caps.txfifodepth = CONF_STATUS1_TX_DEPTH(val);
+ master->caps.ibirfifodepth = CONF_STATUS0_IBIR_DEPTH(val);
+ master->caps.cmdrfifodepth = CONF_STATUS0_CMDR_DEPTH(val);
+
+ spin_lock_init(&master->ibi.lock);
+ master->ibi.num_slots = CONF_STATUS1_IBI_HW_RES(val);
+ master->ibi.slots = devm_kcalloc(&pdev->dev, master->ibi.num_slots,
+ sizeof(*master->ibi.slots),
+ GFP_KERNEL);
+ if (!master->ibi.slots)
+ goto err_disable_sysclk;
+
+ writel(IBIR_THR(1), master->regs + CMD_IBI_THR_CTRL);
+ writel(MST_INT_IBIR_THR, master->regs + MST_IER);
+ writel(DEVS_CTRL_DEV_CLR_ALL, master->regs + DEVS_CTRL);
+
+ ret = i3c_master_register(&master->base, &pdev->dev,
+ &cdns_i3c_master_ops, false);
+ if (ret)
+ goto err_disable_sysclk;
+
+ return 0;
+
+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" },
+ { /* sentinel */ },
+};
+
+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);
+
+MODULE_AUTHOR("Boris Brezillon <boris.brezillon@bootlin.com>");
+MODULE_DESCRIPTION("Cadence I3C master driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:cdns-i3c-master");
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 08/10] dt-bindings: i3c: Document Cadence I3C master bindings
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (6 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 07/10] i3c: master: Add driver for Cadence IP Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 09/10] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
` (2 subsequent siblings)
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Add Rob's R-b
Changes in v4:
- Fix example to match the new representation
---
.../devicetree/bindings/i3c/cdns,i3c-master.txt | 44 ++++++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
new file mode 100644
index 000000000000..0e2b8b8770bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt
@@ -0,0 +1,44 @@
+Bindings for cadence I3C master block
+=====================================
+
+Required properties:
+--------------------
+- compatible: shall be "cdns,i3c-master"
+- clocks: shall reference the pclk and sysclk
+- clock-names: shall contain "pclk" and "sysclk"
+- interrupts: the interrupt line connected to this I3C master
+- reg: I3C master registers
+
+Mandatory properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- #address-cells: shall be set to 1
+- #size-cells: shall be set to 0
+
+Optional properties defined by the generic binding (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details):
+
+- i2c-scl-hz
+- i3c-scl-hz
+
+I3C device connected on the bus follow the generic description (see
+Documentation/devicetree/bindings/i3c/i3c.txt for more details).
+
+Example:
+
+ i3c-master@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-hz = <100000>;
+
+ nunchuk: nunchuk@52 {
+ compatible = "nintendo,nunchuk";
+ reg = <0x52 0x80000010 0>;
+ };
+ };
+
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 09/10] gpio: Add a driver for Cadence I3C GPIO expander
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (7 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 08/10] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
2018-07-20 8:52 ` [PATCH v6 00/10] Add the I3C subsystem Arnd Bergmann
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes in v6:
- Use kmalloc_array() instead of kmalloc(N * sizeof(X))
- Add Linus' ack
Changes in v5:
- Use the !! operator to return 0 or 1 in cdns_i3c_gpio_get_direction()
- Use a scratch buffer to make sure the buffers passed to
i3c_device_do_priv_xfers() are DMA-able
- Fix errors reported by checkpatch
Changes in v4:
- none
Changes in v3:
- new
---
drivers/gpio/Kconfig | 11 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-cdns-i3c.c | 411 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 423 insertions(+)
create mode 100644 drivers/gpio/gpio-cdns-i3c.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 71c0ab46f216..19ed6006aea1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -898,6 +898,17 @@ config GPIO_TS4900
endmenu
+menu "I3C GPIO expanders"
+ depends on I3C
+
+config GPIO_CDNS_I3C
+ tristate "Cadence I3C GPIO expander"
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to enabled the driver for Cadence I3C GPIO expander.
+
+endmenu
+
menu "MFD GPIO expanders"
config GPIO_ADP5520
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1324c8f966a7..020b9171223b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
+obj-$(CONFIG_GPIO_CDNS_I3C) += gpio-cdns-i3c.o
obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
diff --git a/drivers/gpio/gpio-cdns-i3c.c b/drivers/gpio/gpio-cdns-i3c.c
new file mode 100644
index 000000000000..37c9d57a2fbb
--- /dev/null
+++ b/drivers/gpio/gpio-cdns-i3c.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Cadence Design Systems Inc.
+ *
+ * Author: Boris Brezillon <boris.brezillon@bootlin.com>
+ */
+
+#include <linux/gpio/driver.h>
+#include <linux/i3c/device.h>
+#include <linux/module.h>
+
+#define OVR 0x0
+#define IVR 0x1
+#define DIR_MODE 0x2
+#define IMR 0x3
+#define ISR 0x4
+#define ITR(x) (0x5 + (x))
+
+struct cdns_i3c_gpio {
+ struct gpio_chip gpioc;
+ struct irq_chip irqc;
+ struct i3c_device *i3cdev;
+ struct mutex irq_lock;
+ u8 dir;
+ u8 ovr;
+ u8 imr;
+ u8 itr[3];
+};
+
+static struct cdns_i3c_gpio *gpioc_to_cdns_gpioc(struct gpio_chip *gpioc)
+{
+ return container_of(gpioc, struct cdns_i3c_gpio, gpioc);
+}
+
+static int cdns_i3c_gpio_read_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 *val)
+{
+ struct i3c_priv_xfer xfers[2] = { };
+ u8 *scratchbuf;
+ int ret;
+
+ /*
+ * i3c_device_do_priv_xfers() mandates that buffers passed in xfers be
+ * DMA-able. This prevents us from using reg and val directly since
+ * reg is on the stack, and val might be too.
+ * Allocate a temporary buffer with kmalloc() to solve the problem.
+ */
+ scratchbuf = kmalloc(sizeof(*scratchbuf), GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ scratchbuf[0] = reg;
+ xfers[0].data.out = scratchbuf;
+ xfers[0].len = 1;
+ xfers[1].data.in = scratchbuf;
+ xfers[1].len = 1;
+ xfers[1].rnw = true;
+
+ ret = i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+ if (!ret)
+ *val = *scratchbuf;
+
+ kfree(scratchbuf);
+
+ return ret;
+}
+
+static int cdns_i3c_gpio_write_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
+ u8 val)
+{
+ struct i3c_priv_xfer xfers[2] = { };
+ u8 *scratchbuf;
+ int ret;
+
+ /*
+ * i3c_device_do_priv_xfers() mandates that buffers passed in xfers be
+ * DMA-able. This prevents us from using reg and val directly since
+ * reg is on the stack, and val might be too.
+ * Allocate a temporary buffer with kmalloc() to solve the problem.
+ */
+ scratchbuf = kmalloc_array(2, sizeof(*scratchbuf), GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ scratchbuf[0] = reg;
+ scratchbuf[1] = val;
+ xfers[0].data.out = scratchbuf;
+ xfers[0].len = 1;
+ xfers[1].data.out = scratchbuf + 1;
+ xfers[1].len = 1;
+
+ ret = i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
+ ARRAY_SIZE(xfers));
+
+ kfree(scratchbuf);
+
+ return ret;
+}
+
+static int cdns_i3c_gpio_get_direction(struct gpio_chip *g,
+ unsigned int offset)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+
+ return !!(gpioc->dir & BIT(offset));
+}
+
+static void cdns_i3c_gpio_set_multiple(struct gpio_chip *g,
+ unsigned long *mask,
+ unsigned long *bits)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+ u8 newovr;
+ int ret;
+
+ newovr = (gpioc->ovr & ~(*mask)) | (*bits & *mask);
+ if (newovr == gpioc->ovr)
+ return;
+
+ ret = cdns_i3c_gpio_write_reg(gpioc, OVR, newovr);
+ if (!ret)
+ gpioc->ovr = newovr;
+}
+
+static void cdns_i3c_gpio_set(struct gpio_chip *g, unsigned int offset,
+ int value)
+{
+ unsigned long mask = BIT(offset), bits = value ? BIT(offset) : 0;
+
+ cdns_i3c_gpio_set_multiple(g, &mask, &bits);
+}
+
+static int cdns_i3c_gpio_set_dir(struct cdns_i3c_gpio *gpioc, unsigned int pin,
+ bool in)
+{
+ u8 newdir;
+ int ret;
+
+ newdir = gpioc->dir;
+ if (in)
+ newdir |= BIT(pin);
+ else
+ newdir &= ~BIT(pin);
+
+ if (newdir == gpioc->dir)
+ return 0;
+
+ gpioc->dir = newdir;
+ ret = cdns_i3c_gpio_write_reg(gpioc, DIR_MODE, newdir);
+ if (!ret)
+ gpioc->dir = newdir;
+
+ return ret;
+}
+
+static int cdns_i3c_gpio_dir_input(struct gpio_chip *g, unsigned int offset)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+
+ return cdns_i3c_gpio_set_dir(gpioc, offset, true);
+}
+
+static int cdns_i3c_gpio_dir_output(struct gpio_chip *g, unsigned int offset,
+ int val)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+
+ cdns_i3c_gpio_set(g, offset, val);
+
+ return cdns_i3c_gpio_set_dir(gpioc, offset, true);
+}
+
+static int cdns_i3c_gpio_get_multiple(struct gpio_chip *g,
+ unsigned long *mask,
+ unsigned long *bits)
+{
+ struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
+ int ret;
+ u8 ivr;
+
+ ret = cdns_i3c_gpio_read_reg(gpioc, IVR, &ivr);
+ if (ret)
+ return ret;
+
+ *bits = ivr & *mask & gpioc->dir;
+ *bits |= gpioc->ovr & *mask & ~gpioc->dir;
+
+ return 0;
+}
+
+static int cdns_i3c_gpio_get(struct gpio_chip *g, unsigned int offset)
+{
+ unsigned long mask = BIT(offset), bits = 0;
+ int ret;
+
+ ret = cdns_i3c_gpio_get_multiple(g, &mask, &bits);
+ if (ret)
+ return ret;
+
+ return mask & bits;
+}
+
+static void cdns_i3c_gpio_ibi_handler(struct i3c_device *i3cdev,
+ const struct i3c_ibi_payload *payload)
+{
+ struct cdns_i3c_gpio *gpioc = i3cdev_get_drvdata(i3cdev);
+ u8 isr = 0;
+ int i;
+
+ cdns_i3c_gpio_read_reg(gpioc, ISR, &isr);
+ for (i = 0; i < 8; i++) {
+ unsigned int irq;
+
+ if (!(BIT(i) & isr & gpioc->imr))
+ continue;
+
+ irq = irq_find_mapping(gpioc->gpioc.irq.domain, i);
+ handle_nested_irq(irq);
+ }
+}
+
+static void cdns_i3c_gpio_irq_lock(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct cdns_i3c_gpio *gpioc = gpiochip_get_data(gc);
+
+ mutex_lock(&gpioc->irq_lock);
+}
+
+static void cdns_i3c_gpio_irq_sync_unlock(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct cdns_i3c_gpio *gpioc = gpiochip_get_data(gc);
+ int i;
+
+ cdns_i3c_gpio_write_reg(gpioc, IMR, gpioc->imr);
+ for (i = 0; i < 3; i++)
+ cdns_i3c_gpio_write_reg(gpioc, ITR(i), gpioc->itr[i]);
+
+ mutex_unlock(&gpioc->irq_lock);
+}
+
+static void cdns_i3c_gpio_irq_unmask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct cdns_i3c_gpio *gpioc = gpiochip_get_data(gc);
+
+ gpioc->imr |= BIT(data->hwirq);
+}
+
+static void cdns_i3c_gpio_irq_mask(struct irq_data *data)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct cdns_i3c_gpio *gpioc = gpiochip_get_data(gc);
+
+ gpioc->imr &= ~BIT(data->hwirq);
+}
+
+static int cdns_i3c_gpio_irq_set_type(struct irq_data *data, unsigned int type)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct cdns_i3c_gpio *gpioc = gpiochip_get_data(gc);
+
+ switch (type) {
+ case IRQ_TYPE_LEVEL_HIGH:
+ gpioc->itr[0] |= BIT(data->hwirq);
+ gpioc->itr[1] |= BIT(data->hwirq);
+ break;
+
+ case IRQ_TYPE_LEVEL_LOW:
+ gpioc->itr[0] |= BIT(data->hwirq);
+ gpioc->itr[1] &= ~BIT(data->hwirq);
+ break;
+
+ case IRQ_TYPE_EDGE_BOTH:
+ gpioc->itr[0] &= ~BIT(data->hwirq);
+ gpioc->itr[2] |= BIT(data->hwirq);
+ break;
+
+ case IRQ_TYPE_EDGE_RISING:
+ gpioc->itr[0] &= ~BIT(data->hwirq);
+ gpioc->itr[1] |= BIT(data->hwirq);
+ gpioc->itr[2] &= ~BIT(data->hwirq);
+ break;
+
+ case IRQ_TYPE_EDGE_FALLING:
+ gpioc->itr[0] &= ~BIT(data->hwirq);
+ gpioc->itr[1] &= ~BIT(data->hwirq);
+ gpioc->itr[2] &= ~BIT(data->hwirq);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int cdns_i3c_gpio_probe(struct i3c_device *i3cdev)
+{
+ struct cdns_i3c_gpio *gpioc;
+ struct device *parent = i3cdev_to_dev(i3cdev);
+ struct i3c_ibi_setup ibisetup = {
+ .max_payload_len = 2,
+ .num_slots = 1,
+ .handler = cdns_i3c_gpio_ibi_handler,
+ };
+ int ret;
+
+ gpioc = devm_kzalloc(parent, sizeof(*gpioc), GFP_KERNEL);
+ if (!gpioc)
+ return -ENOMEM;
+
+ gpioc->i3cdev = i3cdev;
+ i3cdev_set_drvdata(i3cdev, gpioc);
+
+ /* Mask all interrupts. */
+ ret = cdns_i3c_gpio_write_reg(gpioc, IMR, 0);
+ if (ret)
+ return ret;
+
+ /*
+ * Clear the ISR after reading it, not when the IBI is is Acked by the
+ * I3C master. This way we make sure we don't lose events.
+ */
+ ret = cdns_i3c_gpio_write_reg(gpioc, ITR(3), 0xff);
+ if (ret)
+ return ret;
+
+ ret = cdns_i3c_gpio_read_reg(gpioc, DIR_MODE, &gpioc->dir);
+ if (ret)
+ return ret;
+
+ ret = cdns_i3c_gpio_read_reg(gpioc, OVR, &gpioc->ovr);
+ if (ret)
+ return ret;
+
+ ret = i3c_device_request_ibi(i3cdev, &ibisetup);
+ if (ret)
+ return ret;
+
+ gpioc->gpioc.label = dev_name(parent);
+ gpioc->gpioc.owner = THIS_MODULE;
+ gpioc->gpioc.parent = parent;
+ gpioc->gpioc.base = -1;
+ gpioc->gpioc.ngpio = 8;
+ gpioc->gpioc.can_sleep = true;
+ gpioc->gpioc.get_direction = cdns_i3c_gpio_get_direction;
+ gpioc->gpioc.direction_input = cdns_i3c_gpio_dir_input;
+ gpioc->gpioc.direction_output = cdns_i3c_gpio_dir_output;
+ gpioc->gpioc.get = cdns_i3c_gpio_get;
+ gpioc->gpioc.get_multiple = cdns_i3c_gpio_get_multiple;
+ gpioc->gpioc.set = cdns_i3c_gpio_set;
+ gpioc->gpioc.set_multiple = cdns_i3c_gpio_set_multiple;
+
+ ret = devm_gpiochip_add_data(parent, &gpioc->gpioc, gpioc);
+ if (ret)
+ return ret;
+
+ gpioc->irqc.name = dev_name(parent);
+ gpioc->irqc.parent_device = parent;
+ gpioc->irqc.irq_unmask = cdns_i3c_gpio_irq_unmask;
+ gpioc->irqc.irq_mask = cdns_i3c_gpio_irq_mask;
+ gpioc->irqc.irq_bus_lock = cdns_i3c_gpio_irq_lock;
+ gpioc->irqc.irq_bus_sync_unlock = cdns_i3c_gpio_irq_sync_unlock;
+ gpioc->irqc.irq_set_type = cdns_i3c_gpio_irq_set_type;
+ gpioc->irqc.flags = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_MASK_ON_SUSPEND;
+
+ ret = gpiochip_irqchip_add_nested(&gpioc->gpioc, &gpioc->irqc, 0,
+ handle_simple_irq, IRQ_TYPE_NONE);
+ if (ret)
+ goto err_free_ibi;
+
+ ret = i3c_device_enable_ibi(i3cdev);
+ if (ret)
+ goto err_free_ibi;
+
+ return 0;
+
+err_free_ibi:
+ i3c_device_free_ibi(i3cdev);
+
+ return ret;
+}
+
+static int cdns_i3c_gpio_remove(struct i3c_device *i3cdev)
+{
+ i3c_device_disable_ibi(i3cdev);
+ i3c_device_free_ibi(i3cdev);
+
+ return 0;
+}
+
+static const struct i3c_device_id cdns_i3c_gpio_ids[] = {
+ I3C_DEVICE(0x1c9, 0x0, NULL),
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(i3c, cdns_i3c_gpio_ids);
+
+static struct i3c_driver cdns_i3c_gpio = {
+ .driver.name = "cdns-i3c-gpio",
+ .id_table = cdns_i3c_gpio_ids,
+ .probe = cdns_i3c_gpio_probe,
+ .remove = cdns_i3c_gpio_remove,
+};
+module_i3c_driver(cdns_i3c_gpio);
+
+MODULE_AUTHOR("Boris Brezillon <boris.brezillon@bootlin.com>");
+MODULE_DESCRIPTION("Driver for Cadence I3C GPIO expander");
+MODULE_LICENSE("GPL v2");
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* [PATCH v6 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (8 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 09/10] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
@ 2018-07-19 15:29 ` Boris Brezillon
2018-07-20 8:52 ` [PATCH v6 00/10] Add the I3C subsystem Arnd Bergmann
10 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-19 15:29 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin, Boris Brezillon
Document the Cadence I3C gpio expander bindings.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Add Rob's R-b
Changes in v4:
- Use GPIO_ and IRQ_TYPE_ macros instead of raw numbers
- Fix the unit-address in the example
---
.../devicetree/bindings/gpio/gpio-cdns-i3c.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
new file mode 100644
index 000000000000..d0155a9cea79
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-cdns-i3c.txt
@@ -0,0 +1,39 @@
+* Cadence I3C GPIO expander
+
+The Cadence I3C GPIO expander provides 8 GPIOs controllable over I3C.
+This GPIOs can be configured in output or input mode and if they are in input
+mode they can generate IBIs (In Band Interrupts).
+
+Required properties for GPIO node:
+- reg : 3 cells encoding the I3C static address (none in our case) and the I3C
+ Provisional ID. See Documentation/devicetree/bindings/i3c/i3c.txt for
+ more details.
+ Should be <0x0 0x392 0x0>.
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity (GPIO_ACTIVE_HIGH or
+ GPIO_ACTIVE_LOW)
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be 2. The first cell is the GPIO number.
+ The second cell is used to specify trigger type and level flags.
+ The following trigger types are accepted (see
+ <dt-bindings/interrupt-controller/irq.h> for their definition):
+ IRQ_TYPE_EDGE_RISING
+ IRQ_TYPE_EDGE_FALLING
+ IRQ_TYPE_EDGE_BOTH
+ IRQ_TYPE_LEVEL_HIGH
+ IRQ_TYPE_LEVEL_LOW
+
+Example:
+
+ i3c-master@xxx {
+ ...
+ i3c_gpio_expander: gpio@0,39200000000 {
+ reg = <0 0x392 0x0>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ ...
+ };
--
2.14.1
^ permalink raw reply related [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
` (9 preceding siblings ...)
2018-07-19 15:29 ` [PATCH v6 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
@ 2018-07-20 8:52 ` Arnd Bergmann
2018-07-20 9:57 ` Peter Rosin
10 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-20 8:52 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj, Peter Rosin
On Thu, Jul 19, 2018 at 5:29 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> - 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.
>
> Discussion around the bus/master/dev representation is still ongoing,
> with Arnd opting for a simple approach where
> * the bus is implicitly represented by the master device
> * the master is not represented as a device under the I3C bus
> * only remote I3C devices are exposed and possibly duplicated if
> several masters controlling the same bus are exposed to the same
> Linux instance
> and Peter preferring the representation where the bus is a separate
> object. IIRC, Wolfram was in favor of the "bus is a separate object"
> too.
>
> If possible, I'd like to close this discussion soon, no matter which
> solution is chosen.
...
> Missing features in this preliminary version:
...
> - no support for multi-master and the associated concepts (mastership
> handover, support for secondary masters, ...)
Let's try to come to a conclusion to this discussion, this is the main
show-stopper for inclusion that I see, as changing the fundamental
design would be hard to do once we do it one way or the other,
and the structure is exposed to user space.
Peter and Wolfram, could you explain what scenario you can see that
would require handing over ownership of a device from one i3c master
to another i3c master when both are controlled by the same Linux
instance?
To me this seems like a rather odd scenario, and supporting it
properly requires significant complexity once we try to support the
dynamic handover of the bus between two of our own masters.
It seems more likely to me that we could deal with this case by
requiring either that each bus is controlled by at most one master
device in Linux, or at least that when we have two masters on
the same bus that they each control a non-overlapping set of
slave devices. Either way we'd be able to represent the structure
as a normal tree in the firmware (DT or ACPI) as well as in
sysfs.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 8:52 ` [PATCH v6 00/10] Add the I3C subsystem Arnd Bergmann
@ 2018-07-20 9:57 ` Peter Rosin
2018-07-20 10:05 ` Boris Brezillon
2018-07-20 10:12 ` Wolfram Sang
0 siblings, 2 replies; 71+ messages in thread
From: Peter Rosin @ 2018-07-20 9:57 UTC (permalink / raw)
To: Arnd Bergmann, Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On 2018-07-20 10:52, Arnd Bergmann wrote:
> On Thu, Jul 19, 2018 at 5:29 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
>
>> - 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.
>>
>> Discussion around the bus/master/dev representation is still ongoing,
>> with Arnd opting for a simple approach where
>> * the bus is implicitly represented by the master device
>> * the master is not represented as a device under the I3C bus
>> * only remote I3C devices are exposed and possibly duplicated if
>> several masters controlling the same bus are exposed to the same
>> Linux instance
>> and Peter preferring the representation where the bus is a separate
>> object. IIRC, Wolfram was in favor of the "bus is a separate object"
>> too.
>>
>> If possible, I'd like to close this discussion soon, no matter which
>> solution is chosen.
> ...
>> Missing features in this preliminary version:
> ...
>> - no support for multi-master and the associated concepts (mastership
>> handover, support for secondary masters, ...)
>
> Let's try to come to a conclusion to this discussion, this is the main
> show-stopper for inclusion that I see, as changing the fundamental
> design would be hard to do once we do it one way or the other,
> and the structure is exposed to user space.
>
> Peter and Wolfram, could you explain what scenario you can see that
> would require handing over ownership of a device from one i3c master
> to another i3c master when both are controlled by the same Linux
> instance?
>
> To me this seems like a rather odd scenario, and supporting it
> properly requires significant complexity once we try to support the
> dynamic handover of the bus between two of our own masters.
>
> It seems more likely to me that we could deal with this case by
> requiring either that each bus is controlled by at most one master
> device in Linux, or at least that when we have two masters on
> the same bus that they each control a non-overlapping set of
> slave devices. Either way we'd be able to represent the structure
> as a normal tree in the firmware (DT or ACPI) as well as in
> sysfs.
I have not read much of the I3C spec. I'm just coming from the
current situation with I2C and the i2c-demux-pinctrl driver which
tries to retrofit this into the I2C world and is not doing a grand
job. And how could it?
If you can acknowledge that i2c-demux-pinctrl is needed for I2C
but for some reason is not needed for I3C because of something
that differs between I2C and I3C, then fine, by all means ditch
the explicit bus object.
But in my mind splitting up the devices on the same bus between
several of our own masters and then not have a single object for
the bus is going to cause headaches down the line. Be it address
clashes or trouble with master ping-pong or whatever.
I think the reason for i2c-demux-pinctrl is that some (most?) I2C
hardware suffers from quirks and one way to work around it is to
make selected accesses from a different master. I expect I3C HW
to also suffer from quirks...
Maybe a bit-bang I3C master isn't feasible for some fundamental
reason? But if it is, then I'd say that it's just a matter of time
until someone finds a situation where such a thing could be used to
work around some I3C quirk. And then it might be too expensive to
always use the bit-bang master for the affected device.
But what do I know? Don't let me hold this series back...
Cheers,
Peter
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 9:57 ` Peter Rosin
@ 2018-07-20 10:05 ` Boris Brezillon
2018-07-20 10:39 ` Peter Rosin
2018-07-20 10:12 ` Wolfram Sang
1 sibling, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-07-20 10:05 UTC (permalink / raw)
To: Peter Rosin
Cc: Arnd Bergmann, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, 20 Jul 2018 11:57:56 +0200
Peter Rosin <peda@axentia.se> wrote:
>
> Maybe a bit-bang I3C master isn't feasible for some fundamental
> reason?
No, it's clearly not. The way an I3C master is supposed to switch from
open-drain to push-pull during a transaction or the concept of IBIs
are the first things that come to mind, but I guess you have plenty of
other reasons preventing you from implementing a i3c-bit-bang master.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 9:57 ` Peter Rosin
2018-07-20 10:05 ` Boris Brezillon
@ 2018-07-20 10:12 ` Wolfram Sang
2018-07-20 10:57 ` Arnd Bergmann
1 sibling, 1 reply; 71+ messages in thread
From: Wolfram Sang @ 2018-07-20 10:12 UTC (permalink / raw)
To: Peter Rosin
Cc: Arnd Bergmann, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
> I have not read much of the I3C spec. I'm just coming from the
> current situation with I2C and the i2c-demux-pinctrl driver which
> tries to retrofit this into the I2C world and is not doing a grand
> job. And how could it?
>
> If you can acknowledge that i2c-demux-pinctrl is needed for I2C
> but for some reason is not needed for I3C because of something
> that differs between I2C and I3C, then fine, by all means ditch
> the explicit bus object.
>
> But in my mind splitting up the devices on the same bus between
> several of our own masters and then not have a single object for
> the bus is going to cause headaches down the line. Be it address
> clashes or trouble with master ping-pong or whatever.
>
> I think the reason for i2c-demux-pinctrl is that some (most?) I2C
> hardware suffers from quirks and one way to work around it is to
> make selected accesses from a different master. I expect I3C HW
> to also suffer from quirks...
>
> Maybe a bit-bang I3C master isn't feasible for some fundamental
> reason? But if it is, then I'd say that it's just a matter of time
> until someone finds a situation where such a thing could be used to
> work around some I3C quirk. And then it might be too expensive to
> always use the bit-bang master for the affected device.
>
> But what do I know? Don't let me hold this series back...
Thanks, Peter. You nailed it, the I2C use case (and its limits). From
what I know about I3C, bit-banging doesn't sound very feasible to me, so
the situation might be a bit different. Still, no one knows about future
I3C use cases and HW quirks. This is why I encouraged the seperate bus
object because back then it was said it was easy to do and implement. If
this now becomes a show-stopper, we can surely re-decide. I am not
strong on this point, it was just something which would have helped I2C.
(And for that matter, we (= the Renesas Upstream Kernel Team) was
discussing something similar to the i2c demuxer for SPI, too. We have
multiple IP cores which can do SPI on R-Car, all with their pros and
cons)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 10:05 ` Boris Brezillon
@ 2018-07-20 10:39 ` Peter Rosin
0 siblings, 0 replies; 71+ messages in thread
From: Peter Rosin @ 2018-07-20 10:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On 2018-07-20 12:05, Boris Brezillon wrote:
> On Fri, 20 Jul 2018 11:57:56 +0200 Peter Rosin <peda@axentia.se> wrote:
>> Maybe a bit-bang I3C master isn't feasible for some fundamental
>> reason?
>
> No, it's clearly not. The way an I3C master is supposed to switch from
> open-drain to push-pull during a transaction or the concept of IBIs
> are the first things that come to mind, but I guess you have plenty of
> other reasons preventing you from implementing a i3c-bit-bang master.
Why can't a bit-banger switch from open-drain to push-pull? That's just
a matter of disconnecting some pull-ups, no? And maybe you know that no
device on your bus uses IBIs? Maybe none of reasons for why bit-banging
isn't feasible are applicable?
I.e. maybe there can be a I3C bit-banger that perhaps isn't generic and
isn't full-featured, but does work just fine in some specific setup?
Cheers,
Peter
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 10:12 ` Wolfram Sang
@ 2018-07-20 10:57 ` Arnd Bergmann
2018-07-20 11:05 ` Wolfram Sang
2018-07-20 11:13 ` Peter Rosin
0 siblings, 2 replies; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-20 10:57 UTC (permalink / raw)
To: Wolfram Sang
Cc: Peter Rosin, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, Jul 20, 2018 at 12:12 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> I have not read much of the I3C spec. I'm just coming from the
>> current situation with I2C and the i2c-demux-pinctrl driver which
>> tries to retrofit this into the I2C world and is not doing a grand
>> job. And how could it?
>>
>> If you can acknowledge that i2c-demux-pinctrl is needed for I2C
>> but for some reason is not needed for I3C because of something
>> that differs between I2C and I3C, then fine, by all means ditch
>> the explicit bus object.
>>
>> But in my mind splitting up the devices on the same bus between
>> several of our own masters and then not have a single object for
>> the bus is going to cause headaches down the line. Be it address
>> clashes or trouble with master ping-pong or whatever.
>>
>> I think the reason for i2c-demux-pinctrl is that some (most?) I2C
>> hardware suffers from quirks and one way to work around it is to
>> make selected accesses from a different master. I expect I3C HW
>> to also suffer from quirks...
>>
>> Maybe a bit-bang I3C master isn't feasible for some fundamental
>> reason? But if it is, then I'd say that it's just a matter of time
>> until someone finds a situation where such a thing could be used to
>> work around some I3C quirk. And then it might be too expensive to
>> always use the bit-bang master for the affected device.
>>
>> But what do I know? Don't let me hold this series back...
>
> Thanks, Peter. You nailed it, the I2C use case (and its limits). From
> what I know about I3C, bit-banging doesn't sound very feasible to me, so
> the situation might be a bit different. Still, no one knows about future
> I3C use cases and HW quirks. This is why I encouraged the seperate bus
> object because back then it was said it was easy to do and implement. If
> this now becomes a show-stopper, we can surely re-decide. I am not
> strong on this point, it was just something which would have helped I2C.
> (And for that matter, we (= the Renesas Upstream Kernel Team) was
> discussing something similar to the i2c demuxer for SPI, too. We have
> multiple IP cores which can do SPI on R-Car, all with their pros and
> cons)
I think we need to distinguish between demuxing and i3c master
handover here, they are two separate issues that both need to be solved
and that are not too hard to do, but we get into trouble if we combine
them in arbitrary ways, which is what I'm concerned about:
* What I understand from reading i2c-demux-pinctrl.c, a slave device
will only ever be observable from one master at a time, when you
switch over, all children get removed on one master and added to
the other one, to be probed again by their respective drivers.
I can see this as a useful feature on i3c as well, in particular to
deal with the situation where we have i2c slaves connected to a
pinmux that can switch them between an i3c master and an
i2c-only master (possibly a gpio based one). That particular use
case however doesn't seem to fix well in the current code, which
is structure around i3c buses.
* The other thing we definitely have to support for i3c is to deal with
handing over control of the bus between the i3c master owned
by Linux, and other masters that are /not/ owned by the same
Linux instance. This is the part that the spec discusses in much
detail, with the intention of temporarily giving up control of the
bus to let another master do its thing on a shared slave without
user interaction.
Combining the two quickly gets nasty I think. The current design
seems to imply that a device driver could keep talking to a slave
while it is being reparented from one master to another. I can't
think of a good reason why we would possibly want that, but
it definitely opens up questions in what happens to e.g. the sysfs
representation, lock order, and power management that I'd rather
not have to think about.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 10:57 ` Arnd Bergmann
@ 2018-07-20 11:05 ` Wolfram Sang
2018-07-20 11:13 ` Peter Rosin
1 sibling, 0 replies; 71+ messages in thread
From: Wolfram Sang @ 2018-07-20 11:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Rosin, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
> * What I understand from reading i2c-demux-pinctrl.c, a slave device
> will only ever be observable from one master at a time, when you
> switch over, all children get removed on one master and added to
> the other one, to be probed again by their respective drivers.
Yes. The very first versions of the demuxer tried to do it in a
hot-swapping like fashion but then I switched over because of...
> it definitely opens up questions in what happens to e.g. the sysfs
> representation, lock order, and power management that I'd rather
> not have to think about.
... this! There are dragons, I can tell you :)
> * The other thing we definitely have to support for i3c is to deal with
> handing over control of the bus between the i3c master owned
> by Linux, and other masters that are /not/ owned by the same
> Linux instance. This is the part that the spec discusses in much
> detail, with the intention of temporarily giving up control of the
> bus to let another master do its thing on a shared slave without
> user interaction.
I can't comment about this one.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 10:57 ` Arnd Bergmann
2018-07-20 11:05 ` Wolfram Sang
@ 2018-07-20 11:13 ` Peter Rosin
2018-07-20 11:28 ` Arnd Bergmann
1 sibling, 1 reply; 71+ messages in thread
From: Peter Rosin @ 2018-07-20 11:13 UTC (permalink / raw)
To: Arnd Bergmann, Wolfram Sang
Cc: Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On 2018-07-20 12:57, Arnd Bergmann wrote:
> * What I understand from reading i2c-demux-pinctrl.c, a slave device
> will only ever be observable from one master at a time, when you
> switch over, all children get removed on one master and added to
> the other one, to be probed again by their respective drivers.
> I can see this as a useful feature on i3c as well, in particular to
> deal with the situation where we have i2c slaves connected to a
> pinmux that can switch them between an i3c master and an
> i2c-only master (possibly a gpio based one). That particular use
> case however doesn't seem to fix well in the current code, which
> is structure around i3c buses.
It's pretty easy to come up with examples where this reprobing is
not desirable at all. E.g. if one of the involved I2C devices is
a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
graphics pipeline. Blink-blink on the screen because some *other*
unrelated device needed to be accessed by an alternative master. Not
pretty.
(No, I don't suffer from this since I don't need the demuxer. Which is
fortunate. This was just an example, I'm sure there are others.)
Cheers,
Peter
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 11:13 ` Peter Rosin
@ 2018-07-20 11:28 ` Arnd Bergmann
2018-07-20 13:16 ` Peter Rosin
2018-07-20 13:17 ` Boris Brezillon
0 siblings, 2 replies; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-20 11:28 UTC (permalink / raw)
To: Peter Rosin
Cc: Wolfram Sang, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
> On 2018-07-20 12:57, Arnd Bergmann wrote:
>> * What I understand from reading i2c-demux-pinctrl.c, a slave device
>> will only ever be observable from one master at a time, when you
>> switch over, all children get removed on one master and added to
>> the other one, to be probed again by their respective drivers.
>> I can see this as a useful feature on i3c as well, in particular to
>> deal with the situation where we have i2c slaves connected to a
>> pinmux that can switch them between an i3c master and an
>> i2c-only master (possibly a gpio based one). That particular use
>> case however doesn't seem to fix well in the current code, which
>> is structure around i3c buses.
>
> It's pretty easy to come up with examples where this reprobing is
> not desirable at all. E.g. if one of the involved I2C devices is
> a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
> graphics pipeline. Blink-blink on the screen because some *other*
> unrelated device needed to be accessed by an alternative master. Not
> pretty.
Agreed, we definitely don't want to reprobe all devices during normal
operation for i3c master handover.
What is the least contrived use case that you can think of where we
would want to use one master to talk to one device on the bus,
but another master to talk to another device on the same bus?
I still hope that we can decide that this is not a useful scenario
at all.
If we find a case in which it is needed, we could still deal with it
like this:
- enumerate all slaves connected to the bus for each of the
two masters
- mark each slave as status="enabled" in at most one of the
buses, and as disabled everywhere else
- Use dynamic handover according to the bus protocol to
switch masters without having Linux even know that the
two buses are shared.
That scenario would then fall completely into the "secondary
master handover" category but require no special handling
in the i3c layer beyond what we need for secondary masters
that are managed by something outside of the kernel's
score (a microcontroller, firmware, ...).
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 11:28 ` Arnd Bergmann
@ 2018-07-20 13:16 ` Peter Rosin
2018-07-20 15:41 ` Wolfram Sang
2018-07-20 13:17 ` Boris Brezillon
1 sibling, 1 reply; 71+ messages in thread
From: Peter Rosin @ 2018-07-20 13:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Wolfram Sang, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On 2018-07-20 13:28, Arnd Bergmann wrote:
> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
>> On 2018-07-20 12:57, Arnd Bergmann wrote:
>>> * What I understand from reading i2c-demux-pinctrl.c, a slave device
>>> will only ever be observable from one master at a time, when you
>>> switch over, all children get removed on one master and added to
>>> the other one, to be probed again by their respective drivers.
>>> I can see this as a useful feature on i3c as well, in particular to
>>> deal with the situation where we have i2c slaves connected to a
>>> pinmux that can switch them between an i3c master and an
>>> i2c-only master (possibly a gpio based one). That particular use
>>> case however doesn't seem to fix well in the current code, which
>>> is structure around i3c buses.
>>
>> It's pretty easy to come up with examples where this reprobing is
>> not desirable at all. E.g. if one of the involved I2C devices is
>> a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
>> graphics pipeline. Blink-blink on the screen because some *other*
>> unrelated device needed to be accessed by an alternative master. Not
>> pretty.
>
> Agreed, we definitely don't want to reprobe all devices during normal
> operation for i3c master handover.
>
> What is the least contrived use case that you can think of where we
> would want to use one master to talk to one device on the bus,
> but another master to talk to another device on the same bus?
> I still hope that we can decide that this is not a useful scenario
> at all.
>
> If we find a case in which it is needed, we could still deal with it
> like this:
> - enumerate all slaves connected to the bus for each of the
> two masters
> - mark each slave as status="enabled" in at most one of the
> buses, and as disabled everywhere else
> - Use dynamic handover according to the bus protocol to
> switch masters without having Linux even know that the
> two buses are shared.
>
> That scenario would then fall completely into the "secondary
> master handover" category but require no special handling
> in the i3c layer beyond what we need for secondary masters
> that are managed by something outside of the kernel's
> score (a microcontroller, firmware, ...).
The worst case is not mentioned above, where a single device benefits
from being accessed by two different masters.
That happens e.g. if one master is speedy but triggers a quirk and
one master is slow and reliable, and the device must use the speedy
master for some things (high bandwidth data?) but can't use it for
other things (configuration?) and must fall back to the slow and
reliable master for that.
I don't have an actual example for I2C, maybe Wolfram does? But I can
invent a case. E.g. the speedy DMA-enabled master cannot generate
RESTART, which is a must for (re-)configuration, but not for passing
data to the device.
Also consider some future HW that has several I3C blocks, but they
are not identical. There's one beefy kind and one slim kind (I'm sure
you can find HW with different flavors of I2C blocks). Even if the
HW designers intended for one type of block to be superior in every
aspect, they might have made a mistake? This HW also has a pinmux, so
the SW is free to route different I3C blocks to the actual I3C bus.
Maybe the involved I3C blocks don't see the bus when the pinmux is
in the "wrong" state? Then you can't do a normal handover...
But if you *want* to end up with "that's just too contrived", then
of course that's where you'll end up.
Cheers,
Peter
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 11:28 ` Arnd Bergmann
2018-07-20 13:16 ` Peter Rosin
@ 2018-07-20 13:17 ` Boris Brezillon
2018-07-24 14:03 ` Arnd Bergmann
1 sibling, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-07-20 13:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Rosin, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, 20 Jul 2018 13:28:10 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
> > On 2018-07-20 12:57, Arnd Bergmann wrote:
> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device
> >> will only ever be observable from one master at a time, when you
> >> switch over, all children get removed on one master and added to
> >> the other one, to be probed again by their respective drivers.
> >> I can see this as a useful feature on i3c as well, in particular to
> >> deal with the situation where we have i2c slaves connected to a
> >> pinmux that can switch them between an i3c master and an
> >> i2c-only master (possibly a gpio based one). That particular use
> >> case however doesn't seem to fix well in the current code, which
> >> is structure around i3c buses.
> >
> > It's pretty easy to come up with examples where this reprobing is
> > not desirable at all. E.g. if one of the involved I2C devices is
> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
> > graphics pipeline. Blink-blink on the screen because some *other*
> > unrelated device needed to be accessed by an alternative master. Not
> > pretty.
>
> Agreed, we definitely don't want to reprobe all devices during normal
> operation for i3c master handover.
>
Re-probing would not happen, no matter the solution we choose. It's
that, in one case, you would have X virtual/linux devices representing
the same physical device and in the other case, you would just have
one, and everytime a transfer is requested by the driver, the core
would pick the appropriate master to do it (most likely the one in
control of the bus at that time)
> What is the least contrived use case that you can think of where we
> would want to use one master to talk to one device on the bus,
> but another master to talk to another device on the same bus?
The only reason I see for this use case is when you have 2 masters,
each of them having different capabilities:
device A needs cap X
device B need cap Y
master N provides cap X but not cap Y
master M provides cap Y but not cap X
In this case you'd want device A to use master M and device B to use
master N.
> I still hope that we can decide that this is not a useful scenario
> at all.
I'm not saying this scenario is about to happen IRL, just describing
one potential reason for having 2 different masters connected to the
same bus and both exposed to Linux.
>
> If we find a case in which it is needed, we could still deal with it
> like this:
> - enumerate all slaves connected to the bus for each of the
> two masters
That's what will happen if you don't share the same bus representation.
> - mark each slave as status="enabled" in at most one of the
> buses, and as disabled everywhere else
We shouldn't need to do that. We can just let the driver check whether
the master provides the necessary capabilities to efficiently
communicate with the device, and if it does not just return -ENOTSUPP
in the ->probe() function. This way you'll have a device, but not
driver controlling it on one bus, and on the other bus, you'll have
another device (which points to the same physical device) this time
with a driver attached to it.
> - Use dynamic handover according to the bus protocol to
> switch masters without having Linux even know that the
> two buses are shared.
Yep.
>
> That scenario would then fall completely into the "secondary
> master handover" category but require no special handling
> in the i3c layer beyond what we need for secondary masters
> that are managed by something outside of the kernel's
> score (a microcontroller, firmware, ...).
I definitely agree that both options should work. It's just that having
X times the same physical device represented in Linux seemed like a bad
thing to me, but it's also not something I'm strongly opposed to.
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 13:16 ` Peter Rosin
@ 2018-07-20 15:41 ` Wolfram Sang
2018-07-24 14:14 ` Arnd Bergmann
0 siblings, 1 reply; 71+ messages in thread
From: Wolfram Sang @ 2018-07-20 15:41 UTC (permalink / raw)
To: Peter Rosin
Cc: Arnd Bergmann, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]
> I don't have an actual example for I2C, maybe Wolfram does? But I can
> invent a case. E.g. the speedy DMA-enabled master cannot generate
> RESTART, which is a must for (re-)configuration, but not for passing
> data to the device.
DMA capable controllers may also not react adequate to the slave doing
clock stretching (which is forbidden in I3C).
Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
transfers to the PMIC, the other has I2C slave functionality. One cannot
do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
Sometimes you can mux the pins to GPIO, so you have a third option.
This setup is the reason the demux driver exists.
> Also consider some future HW that has several I3C blocks, but they
> are not identical. There's one beefy kind and one slim kind (I'm sure
> you can find HW with different flavors of I2C blocks). Even if the
> HW designers intended for one type of block to be superior in every
> aspect, they might have made a mistake? This HW also has a pinmux, so
> the SW is free to route different I3C blocks to the actual I3C bus.
So, basically this is what happened with R-Car. Now, I tend to think
that I3C is much more complex and noone would put two I3C IP cores into
on SoC. But it was not too long ago that I wouldn't believe someone put
two different I2C IP cores into a SoC. Then again, it happened when I2C
was around for 35 years...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 13:17 ` Boris Brezillon
@ 2018-07-24 14:03 ` Arnd Bergmann
2018-07-24 14:28 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 14:03 UTC (permalink / raw)
To: Boris Brezillon
Cc: Peter Rosin, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, Jul 20, 2018 at 3:17 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Fri, 20 Jul 2018 13:28:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
>> > On 2018-07-20 12:57, Arnd Bergmann wrote:
>> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device
>> >> will only ever be observable from one master at a time, when you
>> >> switch over, all children get removed on one master and added to
>> >> the other one, to be probed again by their respective drivers.
>> >> I can see this as a useful feature on i3c as well, in particular to
>> >> deal with the situation where we have i2c slaves connected to a
>> >> pinmux that can switch them between an i3c master and an
>> >> i2c-only master (possibly a gpio based one). That particular use
>> >> case however doesn't seem to fix well in the current code, which
>> >> is structure around i3c buses.
>> >
>> > It's pretty easy to come up with examples where this reprobing is
>> > not desirable at all. E.g. if one of the involved I2C devices is
>> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
>> > graphics pipeline. Blink-blink on the screen because some *other*
>> > unrelated device needed to be accessed by an alternative master. Not
>> > pretty.
>>
>> Agreed, we definitely don't want to reprobe all devices during normal
>> operation for i3c master handover.
>>
>
> Re-probing would not happen, no matter the solution we choose. It's
> that, in one case, you would have X virtual/linux devices representing
> the same physical device and in the other case, you would just have
> one, and everytime a transfer is requested by the driver, the core
> would pick the appropriate master to do it (most likely the one in
> control of the bus at that time)
I think this is one of the cases I'd want to avoid: controlling multiple
masters that are active at the same time without going through
the handover.
If we have an actual pinmux between two masters and only one
of them can even see the bus, I think we should go through a
complete remove/probe cycle the way that the i2c-demux-pinctrl
does today. If OTOH we a primary/secondary master pair with
handover capability, I would prefer to not see one slave on
both devices at the same time, or (ideally) only use one of the
two masters and disable the other one completely.
>> If we find a case in which it is needed, we could still deal with it
>> like this:
>> - enumerate all slaves connected to the bus for each of the
>> two masters
>
> That's what will happen if you don't share the same bus representation.
To clarify: I meant list them in the DT representation, not enumerate
them in Linux during boot. Sorry for using a misleading description here.
>> - mark each slave as status="enabled" in at most one of the
>> buses, and as disabled everywhere else
>
> We shouldn't need to do that. We can just let the driver check whether
> the master provides the necessary capabilities to efficiently
> communicate with the device, and if it does not just return -ENOTSUPP
> in the ->probe() function. This way you'll have a device, but not
> driver controlling it on one bus, and on the other bus, you'll have
> another device (which points to the same physical device) this time
> with a driver attached to it.
I'd still hope that we can completely avoid that case and never
have the case where one physical device has two live
representations in the kernel. It /could/ still be done of course,
but would not always do the right thing, depending on the
type of device (a temperature sensor could just be probed
twice without problems, a network device probably cannot)
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-20 15:41 ` Wolfram Sang
@ 2018-07-24 14:14 ` Arnd Bergmann
2018-07-24 15:57 ` Wolfram Sang
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 14:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: Peter Rosin, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Fri, Jul 20, 2018 at 5:41 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> I don't have an actual example for I2C, maybe Wolfram does? But I can
>> invent a case. E.g. the speedy DMA-enabled master cannot generate
>> RESTART, which is a must for (re-)configuration, but not for passing
>> data to the device.
>
> DMA capable controllers may also not react adequate to the slave doing
> clock stretching (which is forbidden in I3C).
>
> Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
> transfers to the PMIC, the other has I2C slave functionality. One cannot
> do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
> Sometimes you can mux the pins to GPIO, so you have a third option.
>
> This setup is the reason the demux driver exists.
Have you run into scenarios where you dynamically switch between
the two masters in order to do different things (on one slave, or
on multiple slaves), or could you always decide on one of them
at boot time with that particular chip?
>> Also consider some future HW that has several I3C blocks, but they
>> are not identical. There's one beefy kind and one slim kind (I'm sure
>> you can find HW with different flavors of I2C blocks). Even if the
>> HW designers intended for one type of block to be superior in every
>> aspect, they might have made a mistake? This HW also has a pinmux, so
>> the SW is free to route different I3C blocks to the actual I3C bus.
>
> So, basically this is what happened with R-Car. Now, I tend to think
> that I3C is much more complex and noone would put two I3C IP cores into
> on SoC. But it was not too long ago that I wouldn't believe someone put
> two different I2C IP cores into a SoC. Then again, it happened when I2C
> was around for 35 years...
I think an SoC design we will likely see is an i3c master multiplexed with
an i2c master to access one bus. The i2c master can then use clock
stretching and other things that may not work in the i3c master, and it
may be used in the absence of proper i3c drivers in the OS.
However, that case cannot be handled with the abstraction in the
proposed i3c framework, which can only deal with multiple i3c
standard compliant masters. I'm also not sure if it can be added
to the i2c-demux-pinctrl driver.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 14:03 ` Arnd Bergmann
@ 2018-07-24 14:28 ` Boris Brezillon
2018-07-24 15:05 ` Arnd Bergmann
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-07-24 14:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Rosin, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
Hi Arnd,
On Tue, 24 Jul 2018 16:03:38 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Jul 20, 2018 at 3:17 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Fri, 20 Jul 2018 13:28:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
> >> > On 2018-07-20 12:57, Arnd Bergmann wrote:
> >> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device
> >> >> will only ever be observable from one master at a time, when you
> >> >> switch over, all children get removed on one master and added to
> >> >> the other one, to be probed again by their respective drivers.
> >> >> I can see this as a useful feature on i3c as well, in particular to
> >> >> deal with the situation where we have i2c slaves connected to a
> >> >> pinmux that can switch them between an i3c master and an
> >> >> i2c-only master (possibly a gpio based one). That particular use
> >> >> case however doesn't seem to fix well in the current code, which
> >> >> is structure around i3c buses.
> >> >
> >> > It's pretty easy to come up with examples where this reprobing is
> >> > not desirable at all. E.g. if one of the involved I2C devices is
> >> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
> >> > graphics pipeline. Blink-blink on the screen because some *other*
> >> > unrelated device needed to be accessed by an alternative master. Not
> >> > pretty.
> >>
> >> Agreed, we definitely don't want to reprobe all devices during normal
> >> operation for i3c master handover.
> >>
> >
> > Re-probing would not happen, no matter the solution we choose. It's
> > that, in one case, you would have X virtual/linux devices representing
> > the same physical device and in the other case, you would just have
> > one, and everytime a transfer is requested by the driver, the core
> > would pick the appropriate master to do it (most likely the one in
> > control of the bus at that time)
>
> I think this is one of the cases I'd want to avoid: controlling multiple
> masters that are active at the same time without going through
> the handover.
That's simply not possible, the I3C protocol forbids it. There can only
be one active master on the bus at any point in time.
>
> If we have an actual pinmux between two masters and only one
> of them can even see the bus, I think we should go through a
> complete remove/probe cycle the way that the i2c-demux-pinctrl
> does today. If OTOH we a primary/secondary master pair with
> handover capability, I would prefer to not see one slave on
> both devices at the same time, or (ideally) only use one of the
> two masters and disable the other one completely.
Again, you don't have a choice because it's part of the protocol. At
any time, you only have one active master on the bus, and other masters
are acting as slaves until they gain bus ownership (if they ever do).
Say that device A wants to do an HDR transfer on the bus, and HDR is
only supported by master X, but master Y is currently owning the bus.
Master X will first have to request bus ownership before doing the
transfer requested by device A.
Now, imagine that device A wants to do an SDR transfer which is
supported by both master X and master Y, and master Y is in control.
Instead of requesting a bus handover, the framework would just
automatically decide to do the transfer through master Y. That's the
sort of things this separate bus/master representation allows.
>
> >> If we find a case in which it is needed, we could still deal with it
> >> like this:
> >> - enumerate all slaves connected to the bus for each of the
> >> two masters
> >
> > That's what will happen if you don't share the same bus representation.
>
> To clarify: I meant list them in the DT representation, not enumerate
> them in Linux during boot. Sorry for using a misleading description here.
Okay.
>
> >> - mark each slave as status="enabled" in at most one of the
> >> buses, and as disabled everywhere else
> >
> > We shouldn't need to do that. We can just let the driver check whether
> > the master provides the necessary capabilities to efficiently
> > communicate with the device, and if it does not just return -ENOTSUPP
> > in the ->probe() function. This way you'll have a device, but not
> > driver controlling it on one bus, and on the other bus, you'll have
> > another device (which points to the same physical device) this time
> > with a driver attached to it.
>
> I'd still hope that we can completely avoid that case and never
> have the case where one physical device has two live
> representations in the kernel. It /could/ still be done of course,
> but would not always do the right thing, depending on the
> type of device (a temperature sensor could just be probed
> twice without problems, a network device probably cannot)
Not really feasible if we don't share the same bus representation. So,
that means you hope we'll never have a real case where 2 masters are
connected to the same physical bus and both exposed to the same Linux
instance.
I'm still unsure what you think adds complexity in the current
approach. When I implemented it, it looked like is was almost the same
(in term of complexity) to have a bus object separated from the master,
but I'm probably missing something.
Anyway, here's what I propose. I'll work on a v7 where the bus object
is tied to the master (and not exposed in sysfs or the DT
representation) and the master itself is not represented as a device on
the bus. This way you'll have both solutions to compare them and take a
decision.
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 14:28 ` Boris Brezillon
@ 2018-07-24 15:05 ` Arnd Bergmann
2018-07-24 15:15 ` Geert Uytterhoeven
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 15:05 UTC (permalink / raw)
To: Boris Brezillon
Cc: Peter Rosin, Wolfram Sang, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Tue, Jul 24, 2018 at 4:28 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Hi Arnd,
>
> On Tue, 24 Jul 2018 16:03:38 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Fri, Jul 20, 2018 at 3:17 PM, Boris Brezillon
>> <boris.brezillon@bootlin.com> wrote:
>> > On Fri, 20 Jul 2018 13:28:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>> >
>> >> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
>> >> > On 2018-07-20 12:57, Arnd Bergmann wrote:
>> >> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device
>> >> >> will only ever be observable from one master at a time, when you
>> >> >> switch over, all children get removed on one master and added to
>> >> >> the other one, to be probed again by their respective drivers.
>> >> >> I can see this as a useful feature on i3c as well, in particular to
>> >> >> deal with the situation where we have i2c slaves connected to a
>> >> >> pinmux that can switch them between an i3c master and an
>> >> >> i2c-only master (possibly a gpio based one). That particular use
>> >> >> case however doesn't seem to fix well in the current code, which
>> >> >> is structure around i3c buses.
>> >> >
>> >> > It's pretty easy to come up with examples where this reprobing is
>> >> > not desirable at all. E.g. if one of the involved I2C devices is
>> >> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
>> >> > graphics pipeline. Blink-blink on the screen because some *other*
>> >> > unrelated device needed to be accessed by an alternative master. Not
>> >> > pretty.
>> >>
>> >> Agreed, we definitely don't want to reprobe all devices during normal
>> >> operation for i3c master handover.
>> >>
>> >
>> > Re-probing would not happen, no matter the solution we choose. It's
>> > that, in one case, you would have X virtual/linux devices representing
>> > the same physical device and in the other case, you would just have
>> > one, and everytime a transfer is requested by the driver, the core
>> > would pick the appropriate master to do it (most likely the one in
>> > control of the bus at that time)
>>
>> I think this is one of the cases I'd want to avoid: controlling multiple
>> masters that are active at the same time without going through
>> the handover.
>
> That's simply not possible, the I3C protocol forbids it. There can only
> be one active master on the bus at any point in time.
Ok, it sounded like that's what you wanted to do here.
>> If we have an actual pinmux between two masters and only one
>> of them can even see the bus, I think we should go through a
>> complete remove/probe cycle the way that the i2c-demux-pinctrl
>> does today. If OTOH we a primary/secondary master pair with
>> handover capability, I would prefer to not see one slave on
>> both devices at the same time, or (ideally) only use one of the
>> two masters and disable the other one completely.
>
> Again, you don't have a choice because it's part of the protocol. At
> any time, you only have one active master on the bus, and other masters
> are acting as slaves until they gain bus ownership (if they ever do).
> Say that device A wants to do an HDR transfer on the bus, and HDR is
> only supported by master X, but master Y is currently owning the bus.
> Master X will first have to request bus ownership before doing the
> transfer requested by device A.
>
> Now, imagine that device A wants to do an SDR transfer which is
> supported by both master X and master Y, and master Y is in control.
> Instead of requesting a bus handover, the framework would just
> automatically decide to do the transfer through master Y. That's the
> sort of things this separate bus/master representation allows.
That's not the case I was describing here, I was thinking of what
Wolfram described with the Renesas SoC that has two i2c masters
multiplexed through the pinmux layer. I would assume that we
can still do the same thing in i3c by shutting down the current
master without a handover, and reprobing everything from scratch.
If only one of the two masters is physically connected to the
bus at any time, the handover protocol certainly wouldn't
apply.
>> >> - mark each slave as status="enabled" in at most one of the
>> >> buses, and as disabled everywhere else
>> >
>> > We shouldn't need to do that. We can just let the driver check whether
>> > the master provides the necessary capabilities to efficiently
>> > communicate with the device, and if it does not just return -ENOTSUPP
>> > in the ->probe() function. This way you'll have a device, but not
>> > driver controlling it on one bus, and on the other bus, you'll have
>> > another device (which points to the same physical device) this time
>> > with a driver attached to it.
>>
>> I'd still hope that we can completely avoid that case and never
>> have the case where one physical device has two live
>> representations in the kernel. It /could/ still be done of course,
>> but would not always do the right thing, depending on the
>> type of device (a temperature sensor could just be probed
>> twice without problems, a network device probably cannot)
>
> Not really feasible if we don't share the same bus representation. So,
> that means you hope we'll never have a real case where 2 masters are
> connected to the same physical bus and both exposed to the same Linux
> instance.
Why not? As I described in my earlier mail, we just need to make
sure that either one of the two masters gets all the devices and
the other master is completely disabled, or each master gets
a subset of the devices and all other devices are marked as
status="disabled" in DT to prevent them from being bound to
a driver more than once.
> I'm still unsure what you think adds complexity in the current
> approach. When I implemented it, it looked like is was almost the same
> (in term of complexity) to have a bus object separated from the master,
> but I'm probably missing something.
>
> Anyway, here's what I propose. I'll work on a v7 where the bus object
> is tied to the master (and not exposed in sysfs or the DT
> representation) and the master itself is not represented as a device on
> the bus. This way you'll have both solutions to compare them and take a
> decision.
That sounds helpful, thanks a lot!
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:05 ` Arnd Bergmann
@ 2018-07-24 15:15 ` Geert Uytterhoeven
2018-07-24 15:40 ` Arnd Bergmann
2018-07-24 16:04 ` Wolfram Sang
0 siblings, 2 replies; 71+ messages in thread
From: Geert Uytterhoeven @ 2018-07-24 15:15 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Boris Brezillon, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, pgaj
Hi Arnd,
On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jul 24, 2018 at 4:28 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Tue, 24 Jul 2018 16:03:38 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Fri, Jul 20, 2018 at 3:17 PM, Boris Brezillon
> >> <boris.brezillon@bootlin.com> wrote:
> >> > On Fri, 20 Jul 2018 13:28:10 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin <peda@axentia.se> wrote:
> >> >> > On 2018-07-20 12:57, Arnd Bergmann wrote:
> >> >> >> * What I understand from reading i2c-demux-pinctrl.c, a slave device
> >> >> >> will only ever be observable from one master at a time, when you
> >> >> >> switch over, all children get removed on one master and added to
> >> >> >> the other one, to be probed again by their respective drivers.
> >> >> >> I can see this as a useful feature on i3c as well, in particular to
> >> >> >> deal with the situation where we have i2c slaves connected to a
> >> >> >> pinmux that can switch them between an i3c master and an
> >> >> >> i2c-only master (possibly a gpio based one). That particular use
> >> >> >> case however doesn't seem to fix well in the current code, which
> >> >> >> is structure around i3c buses.
> >> >> >
> >> >> > It's pretty easy to come up with examples where this reprobing is
> >> >> > not desirable at all. E.g. if one of the involved I2C devices is
> >> >> > a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
> >> >> > graphics pipeline. Blink-blink on the screen because some *other*
> >> >> > unrelated device needed to be accessed by an alternative master. Not
> >> >> > pretty.
> >> >>
> >> >> Agreed, we definitely don't want to reprobe all devices during normal
> >> >> operation for i3c master handover.
> >> >>
> >> >
> >> > Re-probing would not happen, no matter the solution we choose. It's
> >> > that, in one case, you would have X virtual/linux devices representing
> >> > the same physical device and in the other case, you would just have
> >> > one, and everytime a transfer is requested by the driver, the core
> >> > would pick the appropriate master to do it (most likely the one in
> >> > control of the bus at that time)
> >>
> >> I think this is one of the cases I'd want to avoid: controlling multiple
> >> masters that are active at the same time without going through
> >> the handover.
> >
> > That's simply not possible, the I3C protocol forbids it. There can only
> > be one active master on the bus at any point in time.
>
> Ok, it sounded like that's what you wanted to do here.
>
> >> If we have an actual pinmux between two masters and only one
> >> of them can even see the bus, I think we should go through a
> >> complete remove/probe cycle the way that the i2c-demux-pinctrl
> >> does today. If OTOH we a primary/secondary master pair with
> >> handover capability, I would prefer to not see one slave on
> >> both devices at the same time, or (ideally) only use one of the
> >> two masters and disable the other one completely.
> >
> > Again, you don't have a choice because it's part of the protocol. At
> > any time, you only have one active master on the bus, and other masters
> > are acting as slaves until they gain bus ownership (if they ever do).
> > Say that device A wants to do an HDR transfer on the bus, and HDR is
> > only supported by master X, but master Y is currently owning the bus.
> > Master X will first have to request bus ownership before doing the
> > transfer requested by device A.
> >
> > Now, imagine that device A wants to do an SDR transfer which is
> > supported by both master X and master Y, and master Y is in control.
> > Instead of requesting a bus handover, the framework would just
> > automatically decide to do the transfer through master Y. That's the
> > sort of things this separate bus/master representation allows.
>
> That's not the case I was describing here, I was thinking of what
> Wolfram described with the Renesas SoC that has two i2c masters
> multiplexed through the pinmux layer. I would assume that we
> can still do the same thing in i3c by shutting down the current
> master without a handover, and reprobing everything from scratch.
The major disadvantage of reprobing is that it may cause visual disturbances
when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
etc.).
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] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:15 ` Geert Uytterhoeven
@ 2018-07-24 15:40 ` Arnd Bergmann
2018-07-24 15:46 ` Geert Uytterhoeven
2018-07-24 16:04 ` Wolfram Sang
1 sibling, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 15:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Boris Brezillon, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> That's not the case I was describing here, I was thinking of what
>> Wolfram described with the Renesas SoC that has two i2c masters
>> multiplexed through the pinmux layer. I would assume that we
>> can still do the same thing in i3c by shutting down the current
>> master without a handover, and reprobing everything from scratch.
>
> The major disadvantage of reprobing is that it may cause visual disturbances
> when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
> etc.).
Do you mean we should reuse the device pointer and association with
the driver even when we switch out the i3c master using the pinmux?
Or do you mean we need to be prepared for driving a single
slave through multiple masters over the lifetime of that device,
but using the i3c master handover protocol?
In the second case, how do we decide which master to use
for accessing a device for a given request?
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:40 ` Arnd Bergmann
@ 2018-07-24 15:46 ` Geert Uytterhoeven
2018-07-24 15:58 ` Arnd Bergmann
0 siblings, 1 reply; 71+ messages in thread
From: Geert Uytterhoeven @ 2018-07-24 15:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Boris Brezillon, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, pgaj
Hi Arnd,
On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> >> That's not the case I was describing here, I was thinking of what
> >> Wolfram described with the Renesas SoC that has two i2c masters
> >> multiplexed through the pinmux layer. I would assume that we
> >> can still do the same thing in i3c by shutting down the current
> >> master without a handover, and reprobing everything from scratch.
> >
> > The major disadvantage of reprobing is that it may cause visual disturbances
> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
> > etc.).
>
> Do you mean we should reuse the device pointer and association with
> the driver even when we switch out the i3c master using the pinmux?
>
> Or do you mean we need to be prepared for driving a single
> slave through multiple masters over the lifetime of that device,
> but using the i3c master handover protocol?
> In the second case, how do we decide which master to use
> for accessing a device for a given request?
I'll have to defer to Wolfram. He's the i2c and muxing expert.
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] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 14:14 ` Arnd Bergmann
@ 2018-07-24 15:57 ` Wolfram Sang
2018-07-24 16:04 ` Arnd Bergmann
2018-07-24 16:07 ` Boris Brezillon
0 siblings, 2 replies; 71+ messages in thread
From: Wolfram Sang @ 2018-07-24 15:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Rosin, Boris Brezillon, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
> > Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
> > transfers to the PMIC, the other has I2C slave functionality. One cannot
> > do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
> > Sometimes you can mux the pins to GPIO, so you have a third option.
> >
> > This setup is the reason the demux driver exists.
>
> Have you run into scenarios where you dynamically switch between
> the two masters in order to do different things (on one slave, or
> on multiple slaves), or could you always decide on one of them
> at boot time with that particular chip?
My personal use case is debugging. R-Car H2 is great because I can
always pinmux this or that I2C IP core to the same set of pins, and in 2
out of 4 cases even GPIO bitbang on top of that. So, it is great to
compare behaviour, do scopes with the same type of setup, etc...
For that, I do runtime switches, but the slaves are not really under
real usage.
I have absolutely no idea how $customers use it, sadly.
> I think an SoC design we will likely see is an i3c master multiplexed with
> an i2c master to access one bus. The i2c master can then use clock
> stretching and other things that may not work in the i3c master, and it
> may be used in the absence of proper i3c drivers in the OS.
Multiplexed? Well, as soon you want to use I3C features like IBI, this
is not going to work, right? It will not even work with Linux being an
I2C slave itself. Or do you mean running the I3C and I2C controller
simultaneously using the same wires?
> However, that case cannot be handled with the abstraction in the
> proposed i3c framework, which can only deal with multiple i3c
> standard compliant masters. I'm also not sure if it can be added
> to the i2c-demux-pinctrl driver.
The I2C demuxer maps the whole bus to an i2c_adapter. You cannot select
a master per client.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:46 ` Geert Uytterhoeven
@ 2018-07-24 15:58 ` Arnd Bergmann
2018-07-24 16:14 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 15:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Boris Brezillon, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Arnd,
>
> On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> >> That's not the case I was describing here, I was thinking of what
>> >> Wolfram described with the Renesas SoC that has two i2c masters
>> >> multiplexed through the pinmux layer. I would assume that we
>> >> can still do the same thing in i3c by shutting down the current
>> >> master without a handover, and reprobing everything from scratch.
>> >
>> > The major disadvantage of reprobing is that it may cause visual disturbances
>> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
>> > etc.).
>>
>> Do you mean we should reuse the device pointer and association with
>> the driver even when we switch out the i3c master using the pinmux?
>>
>> Or do you mean we need to be prepared for driving a single
>> slave through multiple masters over the lifetime of that device,
>> but using the i3c master handover protocol?
>> In the second case, how do we decide which master to use
>> for accessing a device for a given request?
>
> I'll have to defer to Wolfram. He's the i2c and muxing expert.
On i2c, we only have the first case, and Wolfram said that it
intentionally does the reprobe to avoid the problems we discussed.
The question is what to do about this if it happens again on i3c.
Peter seemed to think that it was possibly something we might
have to handle, while Boris said that it wouldn't be because it's
not coverered by the i3c spec.
The second case is the one that started the discussion, and
this is where I said I'd prefer to associate each slave with at
most one master at boot time, while the current v6 patch
is prepared for having one slave be accessed alternatingly
by multiple masters using the master handover, though so
far nobody has been able to describe exactly how we'd pick
which master is active at what point, or what specific scenario
would require it.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:15 ` Geert Uytterhoeven
2018-07-24 15:40 ` Arnd Bergmann
@ 2018-07-24 16:04 ` Wolfram Sang
1 sibling, 0 replies; 71+ messages in thread
From: Wolfram Sang @ 2018-07-24 16:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Boris Brezillon, Peter Rosin, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, pgaj
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
> The major disadvantage of reprobing is that it may cause visual disturbances
> when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
> etc.).
Another one is that you might find bugs related to re-binding which can
be surprisingly hard to solve... IIRC we had a case with the regulator
subsystem where rebinding the PMIC which regulated the CPU is still
unresolved. I think. I'd need to recheck to be sure.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:57 ` Wolfram Sang
@ 2018-07-24 16:04 ` Arnd Bergmann
2018-07-24 20:22 ` Wolfram Sang
2018-07-24 16:07 ` Boris Brezillon
1 sibling, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 16:04 UTC (permalink / raw)
To: Wolfram Sang
Cc: Peter Rosin, Boris Brezillon, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori,
Przemyslaw Gaj
On Tue, Jul 24, 2018 at 5:57 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > Renesas R-Car Gen2 has two I2C IP cores. One can do DMA and automatic
>> > transfers to the PMIC, the other has I2C slave functionality. One cannot
>> > do I2C_SMBUS_QUICK, the other can. And some more kind of quirks.
>> > Sometimes you can mux the pins to GPIO, so you have a third option.
>> >
>> > This setup is the reason the demux driver exists.
>>
>> Have you run into scenarios where you dynamically switch between
>> the two masters in order to do different things (on one slave, or
>> on multiple slaves), or could you always decide on one of them
>> at boot time with that particular chip?
>
> My personal use case is debugging. R-Car H2 is great because I can
> always pinmux this or that I2C IP core to the same set of pins, and in 2
> out of 4 cases even GPIO bitbang on top of that. So, it is great to
> compare behaviour, do scopes with the same type of setup, etc...
> For that, I do runtime switches, but the slaves are not really under
> real usage.
Ok, so runtime here still means it's chosen by an operator (i.e. you),
not part of regular operation.
> I have absolutely no idea how $customers use it, sadly.
Right.
>> I think an SoC design we will likely see is an i3c master multiplexed with
>> an i2c master to access one bus. The i2c master can then use clock
>> stretching and other things that may not work in the i3c master, and it
>> may be used in the absence of proper i3c drivers in the OS.
>
> Multiplexed? Well, as soon you want to use I3C features like IBI, this
> is not going to work, right? It will not even work with Linux being an
> I2C slave itself. Or do you mean running the I3C and I2C controller
> simultaneously using the same wires?
I meant multiplexing it through the pinmux framework, with one of the
two being active at any time. Obviously this makes no sense for
i3c slaves, but it can be useful if the bus only contains i2c slaves.
>> However, that case cannot be handled with the abstraction in the
>> proposed i3c framework, which can only deal with multiple i3c
>> standard compliant masters. I'm also not sure if it can be added
>> to the i2c-demux-pinctrl driver.
>
> The I2C demuxer maps the whole bus to an i2c_adapter. You cannot select
> a master per client.
What I meant here was switching the bus between an i2c master and an
i3c master like you do with the i2c demuxer. Right now, this wouldn't
work because i2c and i3c use different representations in DT and in
Linux for the same devices.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:57 ` Wolfram Sang
2018-07-24 16:04 ` Arnd Bergmann
@ 2018-07-24 16:07 ` Boris Brezillon
1 sibling, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-07-24 16:07 UTC (permalink / raw)
To: Wolfram Sang
Cc: Arnd Bergmann, Peter Rosin, linux-i2c, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, linux-gpio, Sekhar Nori,
Przemyslaw Gaj
On Tue, 24 Jul 2018 17:57:17 +0200
Wolfram Sang <wsa@the-dreams.de> wrote:
> > I think an SoC design we will likely see is an i3c master multiplexed with
> > an i2c master to access one bus. The i2c master can then use clock
> > stretching and other things that may not work in the i3c master, and it
> > may be used in the absence of proper i3c drivers in the OS.
>
> Multiplexed? Well, as soon you want to use I3C features like IBI, this
> is not going to work, right? It will not even work with Linux being an
> I2C slave itself. Or do you mean running the I3C and I2C controller
> simultaneously using the same wires?
I think we should switch to an I3C mindset. It seems the use cases
we're discussing so far are I2C use cases. Keep in mind that I3C bus
management is completely different from I2C one (event if I3C is
backward compatible with I2C, it's just a feature, not the foundation
of the I3C protocol).
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 15:58 ` Arnd Bergmann
@ 2018-07-24 16:14 ` Boris Brezillon
2018-07-24 16:25 ` Arnd Bergmann
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-07-24 16:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, 24 Jul 2018 17:58:29 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > Hi Arnd,
> >
> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >> >> That's not the case I was describing here, I was thinking of what
> >> >> Wolfram described with the Renesas SoC that has two i2c masters
> >> >> multiplexed through the pinmux layer. I would assume that we
> >> >> can still do the same thing in i3c by shutting down the current
> >> >> master without a handover, and reprobing everything from scratch.
> >> >
> >> > The major disadvantage of reprobing is that it may cause visual disturbances
> >> > when i2c slaves are involved with e.g. the display pipeline (think HDMI encoders
> >> > etc.).
> >>
> >> Do you mean we should reuse the device pointer and association with
> >> the driver even when we switch out the i3c master using the pinmux?
> >>
> >> Or do you mean we need to be prepared for driving a single
> >> slave through multiple masters over the lifetime of that device,
> >> but using the i3c master handover protocol?
> >> In the second case, how do we decide which master to use
> >> for accessing a device for a given request?
> >
> > I'll have to defer to Wolfram. He's the i2c and muxing expert.
>
> On i2c, we only have the first case, and Wolfram said that it
> intentionally does the reprobe to avoid the problems we discussed.
> The question is what to do about this if it happens again on i3c.
> Peter seemed to think that it was possibly something we might
> have to handle, while Boris said that it wouldn't be because it's
> not coverered by the i3c spec.
>
> The second case is the one that started the discussion, and
> this is where I said I'd prefer to associate each slave with at
> most one master at boot time, while the current v6 patch
> is prepared for having one slave be accessed alternatingly
> by multiple masters using the master handover, though so
> far nobody has been able to describe exactly how we'd pick
> which master is active at what point,
Even if it's not yet implemented, I have everything in place to figure
this out (see the ->cur_master field in the i3c_bus object). Now,
what's missing is a list of possible masters attached to an i3c device
so that the framework can pick the most appropriate one at runtime and
initiate mastership handover if required (if the selected master is not
the currently active one).
The selection logic should look like this:
if (active_master supports requested feature)
use active master
else
pick an inactive one that has relevant caps and initiate
mastership handover (+ update bus->cur_master)
> or what specific scenario
> would require it.
I think I described a scenario (masters having different
capabilities all connected to the same bus), though I don't know how
likely this use case is :-/.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 16:14 ` Boris Brezillon
@ 2018-07-24 16:25 ` Arnd Bergmann
2018-07-24 16:54 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 16:25 UTC (permalink / raw)
To: Boris Brezillon
Cc: Geert Uytterhoeven, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Tue, 24 Jul 2018 17:58:29 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
>> >> <geert@linux-m68k.org> wrote:
>> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> The second case is the one that started the discussion, and
>> this is where I said I'd prefer to associate each slave with at
>> most one master at boot time, while the current v6 patch
>> is prepared for having one slave be accessed alternatingly
>> by multiple masters using the master handover, though so
>> far nobody has been able to describe exactly how we'd pick
>> which master is active at what point,
>
> Even if it's not yet implemented, I have everything in place to figure
> this out (see the ->cur_master field in the i3c_bus object). Now,
> what's missing is a list of possible masters attached to an i3c device
> so that the framework can pick the most appropriate one at runtime and
> initiate mastership handover if required (if the selected master is not
> the currently active one).
>
> The selection logic should look like this:
>
> if (active_master supports requested feature)
> use active master
> else
> pick an inactive one that has relevant caps and initiate
> mastership handover (+ update bus->cur_master)
How would you deal with soft requirements like performance?
E.g. if you have one master that can do large transfers faster
through a special DMA engine, and other master that can
be faster for small transfers, but both support all capabilities
for that device, won't you need some complex logic to avoid
being stuck with a slow master indefinitely?
>> or what specific scenario
>> would require it.
>
> I think I described a scenario (masters having different
> capabilities all connected to the same bus), though I don't know how
> likely this use case is :-/.
I was looking for something more specific here. What (lack of)
capabilities could two i3c controllers have that require you to
use both of them for the same device, rather than picking
a master for each slave with the right feature set?
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 16:25 ` Arnd Bergmann
@ 2018-07-24 16:54 ` Boris Brezillon
2018-07-24 20:21 ` Arnd Bergmann
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-07-24 16:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, 24 Jul 2018 18:25:22 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > On Tue, 24 Jul 2018 17:58:29 +0200
> > Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> On Tue, Jul 24, 2018 at 5:46 PM, Geert Uytterhoeven
> >> <geert@linux-m68k.org> wrote:
> >> > On Tue, Jul 24, 2018 at 5:40 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> >> On Tue, Jul 24, 2018 at 5:15 PM, Geert Uytterhoeven
> >> >> <geert@linux-m68k.org> wrote:
> >> >> > On Tue, Jul 24, 2018 at 5:05 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >> The second case is the one that started the discussion, and
> >> this is where I said I'd prefer to associate each slave with at
> >> most one master at boot time, while the current v6 patch
> >> is prepared for having one slave be accessed alternatingly
> >> by multiple masters using the master handover, though so
> >> far nobody has been able to describe exactly how we'd pick
> >> which master is active at what point,
> >
> > Even if it's not yet implemented, I have everything in place to figure
> > this out (see the ->cur_master field in the i3c_bus object). Now,
> > what's missing is a list of possible masters attached to an i3c device
> > so that the framework can pick the most appropriate one at runtime and
> > initiate mastership handover if required (if the selected master is not
> > the currently active one).
> >
> > The selection logic should look like this:
> >
> > if (active_master supports requested feature)
> > use active master
> > else
> > pick an inactive one that has relevant caps and initiate
> > mastership handover (+ update bus->cur_master)
>
> How would you deal with soft requirements like performance?
> E.g. if you have one master that can do large transfers faster
> through a special DMA engine, and other master that can
> be faster for small transfers, but both support all capabilities
> for that device, won't you need some complex logic to avoid
> being stuck with a slow master indefinitely?
True.
>
> >> or what specific scenario
> >> would require it.
> >
> > I think I described a scenario (masters having different
> > capabilities all connected to the same bus), though I don't know how
> > likely this use case is :-/.
>
> I was looking for something more specific here. What (lack of)
> capabilities could two i3c controllers have that require you to
> use both of them for the same device, rather than picking
> a master for each slave with the right feature set?
Hehe, if I had a clear answer to this question we wouldn't have this
discussion :-). I gave you an example:
- master A supporting IBIs but not HDR transactions
- master B supporting HDR modes but not IBIs
but as I said, I'm not sure how likely this example is...
The question is more, should we design things so that we can at some
point implement a solution to support those funky setups, or should we
just ignore it and risk breaking sysfs/DT ABI when/if we have to support
that?
This is really an open question. I initially went for the former, but
have no objection switching to the latter.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 16:54 ` Boris Brezillon
@ 2018-07-24 20:21 ` Arnd Bergmann
0 siblings, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2018-07-24 20:21 UTC (permalink / raw)
To: Boris Brezillon
Cc: Geert Uytterhoeven, Peter Rosin, Wolfram Sang, Linux I2C,
Jonathan Corbet, open list:DOCUMENTATION, Greg KH,
Przemyslaw Sroka, Arkadiusz Golec, Alan Douglas, Bartosz Folta,
Damian Kos, Alicja Jurasik-Urbaniak, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Vitor Soares, Linus Walleij,
Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori, Przemyslaw Gaj
On Tue, Jul 24, 2018 at 6:54 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> On Tue, 24 Jul 2018 18:25:22 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Tue, Jul 24, 2018 at 6:14 PM, Boris Brezillon
>> <boris.brezillon@bootlin.com> wrote:
>> > On Tue, 24 Jul 2018 17:58:29 +0200
>> > Arnd Bergmann <arnd@arndb.de> wrote:
>> >> or what specific scenario would require it.
>> >
>> > I think I described a scenario (masters having different
>> > capabilities all connected to the same bus), though I don't know how
>> > likely this use case is :-/.
>>
>> I was looking for something more specific here. What (lack of)
>> capabilities could two i3c controllers have that require you to
>> use both of them for the same device, rather than picking
>> a master for each slave with the right feature set?
>
> Hehe, if I had a clear answer to this question we wouldn't have this
> discussion :-). I gave you an example:
>
> - master A supporting IBIs but not HDR transactions
> - master B supporting HDR modes but not IBIs
>
> but as I said, I'm not sure how likely this example is...
I'd say for a specific example like that, the person that did the
SoC integration should find a new job outside of hardware
design ;-)
I suppose the point is really that this is only preparation for something
completely unexpected, and any specific example one could come
up with is very unlikely to occur in real hardware.
> The question is more, should we design things so that we can at some
> point implement a solution to support those funky setups, or should we
> just ignore it and risk breaking sysfs/DT ABI when/if we have to support
> that?
>
> This is really an open question. I initially went for the former, but
> have no objection switching to the latter.
For me it's mainly a feeling that the risk of something going wrong
with the current design is bigger than it actually solving problems
we will encounter later. I hope that when you do a v7 version for
comparison, I'll be able to pinpoint specific aspects that are better
rather than being that unspecific. (note: I'll be on vacation next
week and won't be able to review it until I'm back).
Let me try to summarize the points made so far:
1. If we need a way for dynamic handover between two of our
own masters and are not prepared for it now, some hardware
designs may end up being unusable junk. Hopefully those
cases are rare and found early during design when the hardware
can still be changed to something that works.
2. If we design a system that does allow that handover and we don't
need it, the biggest risk is introducing complexity in the system
that makes it harder to use and debug for everyone.
3. The case where we have two masters on a bus, but each
slave is only ever driven by one master can easily be added
later, by adding some DT description for that machine as I
described, but no extra code or DT bindings, or reprobing
of devices during handover.
4. Handing over between an i2c master and an i3c master cannot
be done with the current design either way, and could only ever
work in very limited scenarios. The same is true for i3c masters
that can be connected to the same bus, but not at the same
time (like the case with multiplexed i2c masters today).
5. The debug scenario that Wolfram described might be handled
with a separate bus structure and handing over behind the
curtains, but does not require it to be done without a reprobe.
I can imagine several other (simpler) designs that would allow
doing this.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 00/10] Add the I3C subsystem
2018-07-24 16:04 ` Arnd Bergmann
@ 2018-07-24 20:22 ` Wolfram Sang
0 siblings, 0 replies; 71+ messages in thread
From: Wolfram Sang @ 2018-07-24 20:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Peter Rosin, Boris Brezillon, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, Greg Kroah-Hartman, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Vitor Soares, Geert Uytterhoeven,
Linus Walleij, Xiang Lin, open list:GPIO SUBSYSTEM, Sekhar Nori,
Przemyslaw Gaj
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
> > My personal use case is debugging. R-Car H2 is great because I can
> > always pinmux this or that I2C IP core to the same set of pins, and in 2
> > out of 4 cases even GPIO bitbang on top of that. So, it is great to
> > compare behaviour, do scopes with the same type of setup, etc...
> > For that, I do runtime switches, but the slaves are not really under
> > real usage.
>
> Ok, so runtime here still means it's chosen by an operator (i.e. you),
> not part of regular operation.
Yes.
> I meant multiplexing it through the pinmux framework, with one of the
> two being active at any time. Obviously this makes no sense for
> i3c slaves, but it can be useful if the bus only contains i2c slaves.
Unless Linux is not an I2C slave itself.
> What I meant here was switching the bus between an i2c master and an
> i3c master like you do with the i2c demuxer. Right now, this wouldn't
> work because i2c and i3c use different representations in DT and in
> Linux for the same devices.
I see. Thanks for the clarification.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 71+ messages in thread
* RE: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
@ 2018-08-03 21:38 ` mshettel
2018-08-04 5:33 ` Boris Brezillon
2018-08-22 16:43 ` vitor
1 sibling, 1 reply; 71+ messages in thread
From: mshettel @ 2018-08-03 21:38 UTC (permalink / raw)
To: 'Boris Brezillon', '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',
'Cyprian Wronka', 'Suresh Punnoose',
'Rafal Ciepiela', 'Thomas Petazzoni',
'Nishanth Menon', 'Rob Herring',
'Pawel Moll', 'Mark Rutland',
'Ian Campbell', 'Kumar Gala',
devicetree, linux-kernel, 'Vitor Soares',
'Geert Uytterhoeven', 'Linus Walleij',
'Xiang Lin', linux-gpio, 'Sekhar Nori',
'Przemyslaw Gaj', 'Peter Rosin'
On 7/19/2018 9:29 AM, 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.
>
> Missing features in this preliminary version:
> - I3C HDR modes are not supported
> - 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@bootlin.com>
> ---
> Changes in v6:
> - Add I3C/I2C dev descriptors to simplify I3C driver controllers when
> migrating resources from on I3C device slot to anoter
> - Add I3C error codes and return them when doing SDR/priv and CCC
> transfers. This allows us to properly detect when no devices acked
> a CCC command, which in some cases is a valid situation (no I3C
> devices on the bus)
> - Remove __packed specifiers where unneeded
> - Allocate all IBI slots in one call using kcalloc()
>
> Changes in v5:
> - Rename the address sysfs entry into dynamic_address to clarify things
> - Document that we expect buffers passed to i3c_device_do_priv_xfers()
> to be DMA-able
> - Fix DEFSLVS CCC command
> - s/2017/2018/ in copyright headers
> - Fix SPDX header in internals.h
> - Fix coding style issues
>
> Changes in v4:
> - none
>
> Changes in v3:
> - Fix locking issues
> - Explicitly include a bunch of headers (reported by Randy Dunlap)
> - Rename {i2c,i3c}-scl-frequency DT prop into {i2c,i3c}-scl-hz
> - Do not use BIT() macro in mod_devicetable.h
> - Fix typos
> - Fix/enhance some kernel doc headers
> - Rework the bus initialization code to simplify master drivers
> - Assign dynamic address with SETDASA if the device has a static
> address and the DT has a valid assigned-address property
> - Rework the LVR extraction in DT parsing code
> - Add code to detect when a device is re-attached to the bus after
> losing its dynamic address. In this case we know try to re-assign the
> old address, and most importantly, the I3C device driver sees the same
> device instance, not a new one
> - Add an ->i2c_funcs() hook to let the master declare which I2C features
> it supports
> - Unexport a few functions
> - Remove support for HDR mode since we have no real user yet
>
> Changes in v2:
> - Fix a bunch of mistake I made with the device model (pointed by GKH)
> - Move the documentation out of this commit (pointed by GKH)
> - only source drivers/i3c/master/Kconfig when CONFIG_I3C is enabled
> (pointed by GKH)
> - Add IBI infrastructure
> - Add helpers to ease support for Hot Join (most of the logic is
> delegated to I3C controller drivers)
> - move the doc out of this commit to improve readability
> - Fix a few bugs in device probing/remove (detected after trying to
> load/unload modules in various orders)
> - Add a module_i3c_i2c_driver() macro to ease integration of drivers
> for devices that support both I3C and I2C mode
> ---
> drivers/Kconfig | 2 +
> drivers/Makefile | 2 +-
> drivers/i3c/Kconfig | 24 +
> drivers/i3c/Makefile | 4 +
> drivers/i3c/core.c | 606 ++++++++++++
> drivers/i3c/device.c | 233 +++++
> drivers/i3c/internals.h | 36 +
> drivers/i3c/master.c | 2058
> +++++++++++++++++++++++++++++++++++++++
> drivers/i3c/master/Kconfig | 0
> drivers/i3c/master/Makefile | 0
> include/linux/i3c/ccc.h | 385 ++++++++
> include/linux/i3c/device.h | 331 +++++++
> include/linux/i3c/master.h | 652 +++++++++++++
> include/linux/mod_devicetable.h | 17 +
> 14 files changed, 4349 insertions(+), 1 deletion(-)
> create mode 100644 drivers/i3c/Kconfig
> create mode 100644 drivers/i3c/Makefile
> create mode 100644 drivers/i3c/core.c
> create mode 100644 drivers/i3c/device.c
> create mode 100644 drivers/i3c/internals.h
> create mode 100644 drivers/i3c/master.c
> create mode 100644 drivers/i3c/master/Kconfig
> create mode 100644 drivers/i3c/master/Makefile
> create mode 100644 include/linux/i3c/ccc.h
> create mode 100644 include/linux/i3c/device.h
> create mode 100644 include/linux/i3c/master.h
>
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index 95b9ccc08165..80f6aebc896f 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -55,6 +55,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 24cd47014657..999239dc29d4 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..30a441506f61
> --- /dev/null
> +++ b/drivers/i3c/Kconfig
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +menuconfig I3C
> + tristate "I3C support"
> + select I2C
> + help
> + I3C is a serial protocol standardized by the MIPI alliance.
> +
> + It's supposed to be backward compatible with I2C while providing
> + support for high speed transfers and native interrupt support
> + without the need for extra pins.
> +
> + The I3C protocol also standardizes the slave device types and is
> + mainly designed to communicate with sensors.
> +
> + If you want I3C support, you should say Y here and also to the
> + specific driver for your bus adapter(s) below.
> +
> + This I3C support can also be built as a module. If so, the module
> + will be called i3c.
> +
> +if I3C
> +source "drivers/i3c/master/Kconfig"
> +endif # I3C
> diff --git a/drivers/i3c/Makefile b/drivers/i3c/Makefile
> new file mode 100644
> index 000000000000..3b6d1502d6e6
> --- /dev/null
> +++ b/drivers/i3c/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +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..5c62192ff876
> --- /dev/null
> +++ b/drivers/i3c/core.c
> @@ -0,0 +1,606 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/idr.h>
> +#include <linux/init.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of_device.h>
> +#include <linux/rwsem.h>
> +#include <linux/slab.h>
> +
> +#include "internals.h"
> +
> +static DEFINE_IDR(i3c_bus_idr);
> +static DEFINE_MUTEX(i3c_core_lock);
> +
> +/**
> + * i3c_bus_maintenance_lock - Lock the bus for a maintenance operation
> + * @bus: I3C bus to take the lock on
> + *
> + * This function takes the bus lock so that no other operations can occur
on
> + * the bus. This is needed for all kind of bus maintenance operation,
like
> + * - enabling/disabling slave events
> + * - re-triggering DAA
> + * - changing the dynamic address of a device
> + * - relinquishing mastership
> + * - ...
> + *
> + * The reason for this kind of locking is that we don't want drivers and
core
> + * logic to rely on I3C device information that could be changed behind
their
> + * back.
> + */
> +void i3c_bus_maintenance_lock(struct i3c_bus *bus)
> +{
> + down_write(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_lock);
> +
> +/**
> + * i3c_bus_maintenance_unlock - Release the bus lock after a maintenance
> + * operation
> + * @bus: I3C bus to release the lock on
> + *
> + * Should be called when the bus maintenance operation is done. See
> + * i3c_bus_maintenance_lock() for more details on what these
> maintenance
> + * operations are.
> + */
> +void i3c_bus_maintenance_unlock(struct i3c_bus *bus)
> +{
> + up_write(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_maintenance_unlock);
> +
> +/**
> + * i3c_bus_normaluse_lock - Lock the bus for a normal operation
> + * @bus: I3C bus to take the lock on
> + *
> + * This function takes the bus lock for any operation that is not a
> maintenance
> + * operation (see i3c_bus_maintenance_lock() for a non-exhaustive list of
> + * maintenance operations). Basically all communications with I3C devices
> are
> + * normal operations (HDR, SDR transfers or CCC commands that do not
> change bus
> + * state or I3C dynamic address).
> + *
> + * Note that this lock is not guaranteeing serialization of normal
operations.
> + * In other words, transfer requests passed to the I3C master can be
> submitted
> + * in parallel and I3C master drivers have to use their own locking to
make
> + * sure two different communications are not inter-mixed, or access to
the
> + * output/input queue is not done while the engine is busy.
> + */
> +void i3c_bus_normaluse_lock(struct i3c_bus *bus)
> +{
> + down_read(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_lock);
> +
> +/**
> + * i3c_bus_normaluse_unlock - Release the bus lock after a normal
> operation
> + * @bus: I3C bus to release the lock on
> + *
> + * Should be called when a normal operation is done. See
> + * i3c_bus_normaluse_lock() for more details on what these normal
> operations
> + * are.
> + */
> +void i3c_bus_normaluse_unlock(struct i3c_bus *bus)
> +{
> + up_read(&bus->lock);
> +}
> +EXPORT_SYMBOL_GPL(i3c_bus_normaluse_unlock);
> +
> +static ssize_t bcr_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cdev->bus);
> + ret = sprintf(buf, "%x\n", i3cdev->desc->info.bcr);
> + i3c_bus_normaluse_unlock(i3cdev->bus);
> +
> + 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);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cdev->bus);
> + ret = sprintf(buf, "%x\n", i3cdev->desc->info.dcr);
> + i3c_bus_normaluse_unlock(i3cdev->bus);
> +
> + 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);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cdev->bus);
> + ret = sprintf(buf, "%llx\n", i3cdev->desc->info.pid);
> + i3c_bus_normaluse_unlock(i3cdev->bus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(pid);
> +
> +static ssize_t dynamic_address_show(struct device *dev,
> + struct device_attribute *da,
> + char *buf)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + ssize_t ret;
> +
> + i3c_bus_normaluse_lock(i3cdev->bus);
> + ret = sprintf(buf, "%02x\n", i3cdev->desc->info.dyn_addr);
> + i3c_bus_normaluse_unlock(i3cdev->bus);
> +
> + return ret;
> +}
> +static DEVICE_ATTR_RO(dynamic_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);
> + ssize_t offset = 0, ret;
> + unsigned long caps;
> + int mode;
> +
> + i3c_bus_normaluse_lock(i3cdev->bus);
> + caps = i3cdev->desc->info.hdr_cap;
> + for_each_set_bit(mode, &caps, 8) {
> + if (mode >= ARRAY_SIZE(hdrcap_strings))
> + break;
> +
> + if (!hdrcap_strings[mode])
> + continue;
> +
> + ret = sprintf(buf + offset, offset ? " %s" : "%s",
> + hdrcap_strings[mode]);
> + if (ret < 0)
> + goto out;
> +
> + offset += ret;
> + }
> +
> + ret = sprintf(buf + offset, "\n");
> + if (ret < 0)
> + goto out;
> +
> + ret = offset + ret;
> +
> +out:
> + i3c_bus_normaluse_unlock(i3cdev->bus);
> +
> + 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_dynamic_address.attr,
> + &dev_attr_hdrcap.attr,
> + NULL,
> +};
> +ATTRIBUTE_GROUPS(i3c_device);
> +
> +static int i3c_device_uevent(struct device *dev, struct kobj_uevent_env
> *env)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> + struct i3c_device_info devinfo;
> + u16 manuf, part, ext;
> +
> + i3c_device_get_info(i3cdev, &devinfo);
> + manuf = I3C_PID_MANUF_ID(devinfo.pid);
> + part = I3C_PID_PART_ID(devinfo.pid);
> + ext = I3C_PID_EXTRA_INFO(devinfo.pid);
> +
> + if (I3C_PID_RND_LOWER_32BITS(devinfo.pid))
> + return add_uevent_var(env,
> "MODALIAS=i3c:dcr%02Xmanuf%04X",
> + devinfo.dcr, manuf);
> +
> + return add_uevent_var(env,
> +
> "MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04xext%04x",
> + devinfo.dcr, manuf, part, ext);
> +}
> +
> +const struct device_type i3c_device_type = {
> + .groups = i3c_device_groups,
> + .uevent = i3c_device_uevent,
> +};
> +
> +const struct device_type i3c_master_type = {
> + .groups = i3c_device_groups,
> +};
> +
> +static const struct i3c_device_id *
> +i3c_device_match_id(struct i3c_device *i3cdev,
> + const struct i3c_device_id *id_table)
> +{
> + struct i3c_device_info devinfo;
> + const struct i3c_device_id *id;
> +
> + i3c_device_get_info(i3cdev, &devinfo);
> +
> + /*
> + * 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(devinfo.pid)) {
> + u16 manuf = I3C_PID_MANUF_ID(devinfo.pid);
> + u16 part = I3C_PID_PART_ID(devinfo.pid);
> + u16 ext_info = I3C_PID_EXTRA_INFO(devinfo.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 == devinfo.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);
> + int ret;
> +
> + ret = driver->remove(i3cdev);
> + if (ret)
> + return ret;
> +
> + i3c_device_free_ibi(i3cdev);
> +
> + return ret;
> +}
> +
> +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);
> +}
> +
> +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_normaluse_lock(i3cbus);
> + 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_normaluse_unlock(i3cbus);
> +
> + 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_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%d-%llx\n", i3cbus->id,
> + i3cbus->cur_master->info.pid);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + 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_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i3c);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + 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_normaluse_lock(i3cbus);
> + ret = sprintf(buf, "%ld\n", i3cbus->scl_rate.i2c);
> + i3c_bus_normaluse_unlock(i3cbus);
> +
> + 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 void i3c_busdev_release(struct device *dev)
> +{
> + struct i3c_bus *bus = container_of(dev, struct i3c_bus, dev);
> +
> + WARN_ON(!list_empty(&bus->devs.i2c) || !list_empty(&bus-
> >devs.i3c));
> +
> + mutex_lock(&i3c_core_lock);
> + idr_remove(&i3c_bus_idr, bus->id);
> + mutex_unlock(&i3c_core_lock);
> +
> + of_node_put(bus->dev.of_node);
> + kfree(bus);
> +}
> +
> +static const struct device_type i3c_busdev_type = {
> + .groups = i3c_busdev_groups,
> +};
> +
> +void i3c_bus_unref(struct i3c_bus *bus)
> +{
> + put_device(&bus->dev);
> +}
> +
> +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 = of_node_get(parent->of_node);
> + i3cbus->dev.bus = &i3c_bus_type;
> + i3cbus->dev.type = &i3c_busdev_type;
> + i3cbus->dev.release = i3c_busdev_release;
> +
> + 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;
> + device_initialize(&i3cbus->dev);
> +
> + 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_dev_desc *desc;
> +
> + i3c_bus_for_each_i2cdev(i3cbus, desc) {
> + switch (desc->boardinfo->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_add(&i3cbus->dev);
> +}
> +
> +static int __init i3c_init(void)
> +{
> + return bus_register(&i3c_bus_type);
> +}
> +subsys_initcall(i3c_init);
> +
> +static void __exit i3c_exit(void)
> +{
> + idr_destroy(&i3c_bus_idr);
> + bus_unregister(&i3c_bus_type);
> +}
> +module_exit(i3c_exit);
> +
> +MODULE_AUTHOR("Boris Brezillon <boris.brezillon@bootlin.com>");
> +MODULE_DESCRIPTION("I3C core");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/i3c/device.c b/drivers/i3c/device.c
> new file mode 100644
> index 000000000000..69cc040c3a1c
> --- /dev/null
> +++ b/drivers/i3c/device.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> + */
> +
> +#include <linux/atomic.h>
> +#include <linux/bug.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/slab.h>
> +
> +#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)
> +{
> + int ret, i;
> +
> + if (nxfers < 1)
> + return 0;
> +
> + for (i = 0; i < nxfers; i++) {
> + if (!xfers[i].len || !xfers[i].data.in)
> + return -EINVAL;
> + }
> +
> + i3c_bus_normaluse_lock(dev->bus);
> + ret = i3c_dev_do_priv_xfers_locked(dev->desc, xfers, nxfers);
> + i3c_bus_normaluse_unlock(dev->bus);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
> +
> +/**
> + * i3c_device_get_info() - get I3C device information
> + *
> + * @dev: device we want information on
> + * @info: the information object to fill in
> + *
> + * Retrieve I3C dev info.
> + */
> +void i3c_device_get_info(struct i3c_device *dev,
> + struct i3c_device_info *info)
> +{
> + if (!info)
> + return;
> +
> + i3c_bus_normaluse_lock(dev->bus);
> + if (dev->desc)
> + *info = dev->desc->info;
> + i3c_bus_normaluse_unlock(dev->bus);
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_get_info);
> +
> +/**
> + * i3c_device_disable_ibi() - Disable IBIs coming from a specific device
> + * @dev: device on which IBIs should be disabled
> + *
> + * This function disable IBIs coming from a specific device and wait for
> + * all pending IBIs to be processed.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_disable_ibi(struct i3c_device *dev)
> +{
> + int ret = -ENOENT;
> +
> + i3c_bus_normaluse_lock(dev->bus);
> + if (dev->desc) {
> + mutex_lock(&dev->desc->ibi_lock);
> + ret = i3c_dev_disable_ibi_locked(dev->desc);
> + mutex_unlock(&dev->desc->ibi_lock);
> + }
> + i3c_bus_normaluse_unlock(dev->bus);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_disable_ibi);
> +
> +/**
> + * i3c_device_enable_ibi() - Enable IBIs coming from a specific device
> + * @dev: device on which IBIs should be enabled
> + *
> + * This function enable IBIs coming from a specific device and wait for
> + * all pending IBIs to be processed. This should be called on a device
> + * where i3c_device_request_ibi() has succeeded.
> + *
> + * Note that IBIs from this device might be received before this function
> + * returns to its caller.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_enable_ibi(struct i3c_device *dev)
> +{
> + int ret = -ENOENT;
> +
> + i3c_bus_normaluse_lock(dev->bus);
> + if (dev->desc) {
> + mutex_lock(&dev->desc->ibi_lock);
> + ret = i3c_dev_enable_ibi_locked(dev->desc);
> + mutex_unlock(&dev->desc->ibi_lock);
> + }
> + i3c_bus_normaluse_unlock(dev->bus);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_enable_ibi);
> +
> +/**
> + * i3c_device_request_ibi() - Request an IBI
> + * @dev: device for which we should enable IBIs
> + * @req: setup requested for this IBI
> + *
> + * This function is responsible for pre-allocating all resources needed
to
> + * process IBIs coming from @dev. When this function returns, the IBI is
not
> + * enabled until i3c_device_enable_ibi() is called.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_request_ibi(struct i3c_device *dev,
> + const struct i3c_ibi_setup *req)
> +{
> + int ret = -ENOENT;
> +
> + if (!req->handler || !req->num_slots)
> + return -EINVAL;
> +
> + i3c_bus_normaluse_lock(dev->bus);
> + if (dev->desc) {
> + mutex_lock(&dev->desc->ibi_lock);
> + ret = i3c_dev_request_ibi_locked(dev->desc, req);
> + mutex_unlock(&dev->desc->ibi_lock);
> + }
> + i3c_bus_normaluse_unlock(dev->bus);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_request_ibi);
> +
> +/**
> + * i3c_device_free_ibi() - Free all resources needed for IBI handling
> + * @dev: device on which you want to release IBI resources
> + *
> + * This function is responsible for de-allocating resources previously
> + * allocated by i3c_device_request_ibi(). It should be called after
disabling
> + * IBIs with i3c_device_disable_ibi().
> + */
> +void i3c_device_free_ibi(struct i3c_device *dev)
> +{
> + i3c_bus_normaluse_lock(dev->bus);
> + if (dev->desc) {
> + mutex_lock(&dev->desc->ibi_lock);
> + i3c_dev_free_ibi_locked(dev->desc);
> + mutex_unlock(&dev->desc->ibi_lock);
> + }
> + i3c_bus_normaluse_unlock(dev->bus);
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_free_ibi);
> +
> +/**
> + * i3cdev_to_dev() - Returns the device embedded in @i3cdev
> + * @i3cdev: I3C device
> + *
> + * Return: a pointer to a device object.
> + */
> +struct device *i3cdev_to_dev(struct i3c_device *i3cdev)
> +{
> + return &i3cdev->dev;
> +}
> +EXPORT_SYMBOL_GPL(i3cdev_to_dev);
> +
> +/**
> + * dev_to_i3cdev() - Returns the I3C device containing @dev
> + * @dev: device object
> + *
> + * Return: a pointer to an I3C device object.
> + */
> +struct i3c_device *dev_to_i3cdev(struct device *dev)
> +{
> + return container_of(dev, struct i3c_device, dev);
> +}
> +EXPORT_SYMBOL_GPL(dev_to_i3cdev);
> +
> +/**
> + * 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..ced88435466f
> --- /dev/null
> +++ b/drivers/i3c/internals.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2018 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> + */
> +
> +#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_unref(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);
> +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_dev_do_priv_xfers_locked(struct i3c_dev_desc *dev,
> + struct i3c_priv_xfer *xfers,
> + int nxfers);
> +int i3c_dev_disable_ibi_locked(struct i3c_dev_desc *dev);
> +int i3c_dev_enable_ibi_locked(struct i3c_dev_desc *dev);
> +int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev,
> + const struct i3c_ibi_setup *req);
> +void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev);
> +#endif /* I3C_INTERNAL_H */
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> new file mode 100644
> index 000000000000..d04e9ff9c850
> --- /dev/null
> +++ b/drivers/i3c/master.c
> @@ -0,0 +1,2058 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon <boris.brezillon@bootlin.com>
> + */
> +
> +#include <linux/atomic.h>
> +#include <linux/bug.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/export.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
> +#include <linux/spinlock.h>
> +#include <linux/workqueue.h>
> +
> +#include "internals.h"
> +
> +static struct i3c_master_controller *
> +i2c_adapter_to_i3c_master(struct i2c_adapter *adap)
> +{
> + return container_of(adap, struct i3c_master_controller, i2c);
> +}
> +
> +static struct i2c_adapter *
> +i3c_master_to_i2c_adapter(struct i3c_master_controller *master)
> +{
> + return &master->i2c;
> +}
> +
> +static void i3c_master_free_i2c_dev(struct i2c_dev_desc *dev)
> +{
> + kfree(dev);
> +}
> +
> +static struct i2c_dev_desc *
> +i3c_master_alloc_i2c_dev(struct i3c_master_controller *master,
> + const struct i2c_dev_boardinfo *boardinfo)
> +{
> + struct i2c_dev_desc *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return ERR_PTR(-ENOMEM);
> +
> + dev->common.master = master;
> + dev->boardinfo = boardinfo;
> +
> + return dev;
> +}
> +
> +static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller
> *master,
> + struct i3c_ccc_cmd *cmd)
> +{
> + int ret;
> +
> + if (!cmd || !master)
> + return -EINVAL;
> +
> + if (WARN_ON(master->init_done &&
> + !rwsem_is_locked(&master->bus->lock)))
> + return -EINVAL;
> +
> + if (!master->ops->send_ccc_cmd)
> + return -ENOTSUPP;
> +
> + if ((cmd->id & I3C_CCC_DIRECT) && (!cmd->dests || !cmd->ndests))
> + return -EINVAL;
> +
> + if (master->ops->supports_ccc_cmd &&
> + !master->ops->supports_ccc_cmd(master, cmd))
> + return -ENOTSUPP;
> +
> + ret = master->ops->send_ccc_cmd(master, cmd);
> + if (ret) {
> + if (cmd->err != I3C_ERROR_UNKNOWN)
> + return cmd->err;
> +
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static struct i2c_dev_desc *
> +i3c_master_find_i2c_dev_by_addr(const struct i3c_master_controller
> *master,
> + u16 addr)
> +{
> + struct i2c_dev_desc *dev;
> +
> + i3c_bus_for_each_i2cdev(master->bus, dev) {
> + if (dev->boardinfo->base.addr == addr)
> + return dev;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * 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);
> +
> +static void i3c_device_release(struct device *dev)
> +{
> + struct i3c_device *i3cdev = dev_to_i3cdev(dev);
> +
> + WARN_ON(i3cdev->desc);
> +
> + of_node_put(i3cdev->dev.of_node);
> + kfree(i3cdev);
> +}
> +
> +static void i3c_master_free_i3c_dev(struct i3c_dev_desc *dev)
> +{
> + kfree(dev);
> +}
> +
> +static struct i3c_dev_desc *
> +i3c_master_alloc_i3c_dev(struct i3c_master_controller *master,
> + const struct i3c_device_info *info)
> +{
> + struct i3c_dev_desc *dev;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return ERR_PTR(-ENOMEM);
> +
> + dev->common.master = master;
> + dev->info = *info;
> + mutex_init(&dev->ibi_lock);
> +
> + return dev;
> +}
> +
> +static 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;
> +
> + 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);
> +
> + return i3c_master_send_ccc_cmd_locked(master, &cmd);
> +}
> +
> +/**
> + * 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 positive I3C error code if the error
is
> + * one of the official Mx error codes, and 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 = { };
> +
> + dest.addr = I3C_BROADCAST_ADDR;
> + cmd.dests = &dest;
> + cmd.ndests = 1;
> + cmd.rnw = false;
> + cmd.id = I3C_CCC_ENTDAA;
> +
> + return i3c_master_send_ccc_cmd_locked(master, &cmd);
> +}
> +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 positive I3C error code if the error
is
> + * one of the official Mx error codes, and a negative error code
otherwise.
> + */
> +int i3c_master_disec_locked(struct i3c_master_controller *master, u8
addr,
> + u8 evts)
> +{
> + struct i3c_ccc_events 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_enec_locked() - send an ENEC 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
> + *
> + * Sends an ENEC CCC command to enable 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 positive I3C error code if the error
is
> + * one of the official Mx error codes, and a negative error code
otherwise.
> + */
> +int i3c_master_enec_locked(struct i3c_master_controller *master, u8 addr,
> + u8 evts)
> +{
> + struct i3c_ccc_events 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_ENEC(addr == I3C_BROADCAST_ADDR),
> + .dests = &dest,
> + .ndests = 1,
> + };
> +
> + return i3c_master_send_ccc_cmd_locked(master, &cmd);
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_enec_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 positive I3C error code if the error
is
> + * one of the official Mx error codes, and 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_dev_desc *i3cdev;
> + struct i2c_dev_desc *i2cdev;
> + struct i3c_bus *bus;
> + bool send = false;
> + int ndevs = 0, ret;
> +
> + if (!master)
> + return -EINVAL;
> +
> + bus = i3c_master_get_bus(master);
> + i3c_bus_for_each_i3cdev(bus, i3cdev) {
> + ndevs++;
> +
> + if (i3cdev == master->this)
> + continue;
> +
> + 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 - 1) * sizeof(struct i3c_ccc_dev_desc));
> + defslvs = kzalloc(dest.payload.len, GFP_KERNEL);
> + if (!defslvs)
> + return -ENOMEM;
> +
> + dest.payload.data = defslvs;
> +
> + defslvs->count = ndevs;
> + defslvs->master.bcr = master->this->info.bcr;
> + defslvs->master.dcr = master->this->info.dcr;
> + defslvs->master.dyn_addr = master->this->info.dyn_addr << 1;
> + defslvs->master.static_addr = I3C_BROADCAST_ADDR << 1;
> +
> + desc = defslvs->slaves;
> + i3c_bus_for_each_i2cdev(bus, i2cdev) {
> + desc->lvr = i2cdev->boardinfo->lvr;
> + desc->static_addr = i2cdev->boardinfo->base.addr << 1;
> + desc++;
> + }
> +
> + i3c_bus_for_each_i3cdev(bus, i3cdev) {
> + /* Skip the I3C dev representing this master. */
> + if (i3cdev == master->this)
> + continue;
> +
> + desc->bcr = i3cdev->info.bcr;
> + desc->dcr = i3cdev->info.dcr;
> + desc->dyn_addr = i3cdev->info.dyn_addr << 1;
> + desc->static_addr = i3cdev->info.static_addr << 1;
> + 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_setdasa_locked(struct i3c_master_controller
*master,
> + u8 static_addr, u8 dyn_addr)
> +{
> + struct i3c_ccc_setda setda = {
> + .addr = dyn_addr << 1,
> + };
> + struct i3c_ccc_cmd_dest dest = {
> + .addr = static_addr,
> + .payload.len = sizeof(setda),
> + .payload.data = &setda,
> + };
> + struct i3c_ccc_cmd cmd = {
> + .rnw = false,
> + .id = I3C_CCC_SETDASA,
> + .dests = &dest,
> + .ndests = 1,
> + };
> +
> + if (!dyn_addr || !static_addr)
> + return -EINVAL;
> +
> + return i3c_master_send_ccc_cmd_locked(master, &cmd);
> +}
> +
> +static int i3c_master_setnewda_locked(struct i3c_master_controller
> *master,
> + u8 oldaddr, u8 newaddr)
> +{
> + struct i3c_ccc_setda setda = {
> + .addr = newaddr << 1,
> + };
> + struct i3c_ccc_cmd_dest dest = {
> + .addr = oldaddr,
> + .payload.len = sizeof(setda),
> + .payload.data = &setda,
> + };
> + struct i3c_ccc_cmd cmd = {
> + .rnw = false,
> + .id = I3C_CCC_SETNEWDA,
> + .dests = &dest,
> + .ndests = 1,
> + };
> +
> + if (!oldaddr || !newaddr)
> + return -EINVAL;
> +
> + return i3c_master_send_ccc_cmd_locked(master, &cmd);
> +}
> +
> +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;
> +
> + /*
> + * When the device does not have IBI payload GETMRL only returns 2
> + * bytes of data.
> + */
> + if (!(info->bcr & I3C_BCR_IBI_PAYLOAD))
> + dest.payload.len -= 1;
> +
> + 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_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> + enum i3c_addr_slot_status slot_status;
> + int ret;
> +
> + if (!dev->info.dyn_addr)
> + return -EINVAL;
> +
> + slot_status = i3c_bus_get_addr_slot_status(master->bus,
> + dev->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, &dev->info);
> + if (ret)
> + return ret;
> +
> + ret = i3c_master_getbcr_locked(master, &dev->info);
> + if (ret)
> + return ret;
> +
> + ret = i3c_master_getdcr_locked(master, &dev->info);
> + if (ret)
> + return ret;
> +
> + if (dev->info.bcr & I3C_BCR_MAX_DATA_SPEED_LIM) {
> + ret = i3c_master_getmxds_locked(master, &dev->info);
> + if (ret)
> + return ret;
> + }
> +
> + if (dev->info.bcr & I3C_BCR_IBI_PAYLOAD)
> + dev->info.max_ibi_len = 1;
> +
> + i3c_master_getmrl_locked(master, &dev->info);
> + i3c_master_getmwl_locked(master, &dev->info);
> +
> + if (dev->info.bcr & I3C_BCR_HDR_CAP) {
> + ret = i3c_master_gethdrcap_locked(master, &dev->info);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void i3c_master_put_i3c_addrs(struct i3c_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> +
> + if (dev->info.static_addr)
> + i3c_bus_set_addr_slot_status(master->bus,
> + dev->info.static_addr,
> + I3C_ADDR_SLOT_FREE);
> +
> + if (dev->info.dyn_addr)
> + i3c_bus_set_addr_slot_status(master->bus, dev-
> >info.dyn_addr,
> + I3C_ADDR_SLOT_FREE);
> +
> + if (dev->boardinfo && dev->boardinfo->init_dyn_addr)
> + i3c_bus_set_addr_slot_status(master->bus, dev-
> >info.dyn_addr,
> + I3C_ADDR_SLOT_FREE);
> +}
> +
> +static int i3c_master_get_i3c_addrs(struct i3c_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> + enum i3c_addr_slot_status status;
> +
> + if (!dev->info.static_addr && !dev->info.dyn_addr)
> + return 0;
> +
> + if (dev->info.static_addr) {
> + status = i3c_bus_get_addr_slot_status(master->bus,
> +
dev->info.static_addr);
> + if (status != I3C_ADDR_SLOT_FREE)
> + return -EBUSY;
> +
> + i3c_bus_set_addr_slot_status(master->bus,
> + dev->info.static_addr,
> + I3C_ADDR_SLOT_I3C_DEV);
> + }
> +
> + /*
> + * ->init_dyn_addr should have been reserved before that, so, if
> we're
> + * trying to apply a pre-reserved dynamic address, we should not try
> + * to reserve the address slot a second time.
> + */
> + if (dev->info.dyn_addr &&
> + (!dev->boardinfo ||
> + dev->boardinfo->init_dyn_addr != dev->info.dyn_addr)) {
> + status = i3c_bus_get_addr_slot_status(master->bus,
> + dev->info.dyn_addr);
> + if (status != I3C_ADDR_SLOT_FREE)
> + goto err_release_static_addr;
> +
> + i3c_bus_set_addr_slot_status(master->bus, dev-
> >info.dyn_addr,
> + I3C_ADDR_SLOT_I3C_DEV);
> + }
> +
> + return 0;
> +
> +err_release_static_addr:
> + if (dev->info.static_addr)
> + i3c_bus_set_addr_slot_status(master->bus,
> + dev->info.static_addr,
> + I3C_ADDR_SLOT_FREE);
> +
> + return -EBUSY;
> +}
> +
> +static int i3c_master_attach_i3c_dev(struct i3c_master_controller
*master,
> + struct i3c_dev_desc *dev)
> +{
> + int ret;
> +
> + /*
> + * We don't attach devices to the controller until they are
> + * addressable on the bus.
> + */
> + if (!dev->info.static_addr && !dev->info.dyn_addr)
> + return 0;
> +
> + ret = i3c_master_get_i3c_addrs(dev);
> + if (ret)
> + return ret;
> +
> + /* Do not attach the master device itself. */
> + if (master->this != dev && master->ops->attach_i3c_dev) {
> + ret = master->ops->attach_i3c_dev(dev);
> + if (ret) {
> + i3c_master_put_i3c_addrs(dev);
> + return ret;
> + }
> + }
> +
> + list_add_tail(&dev->common.node, &master->bus->devs.i3c);
> +
> + return 0;
> +}
> +
> +static int i3c_master_reattach_i3c_dev(struct i3c_dev_desc *dev,
> + u8 old_dyn_addr)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> + enum i3c_addr_slot_status status;
> + int ret;
> +
> + if (dev->info.dyn_addr != old_dyn_addr) {
> + status = i3c_bus_get_addr_slot_status(master->bus,
> + dev->info.dyn_addr);
> + if (status != I3C_ADDR_SLOT_FREE)
> + return -EBUSY;
> + i3c_bus_set_addr_slot_status(master->bus,
> + dev->info.dyn_addr,
> + I3C_ADDR_SLOT_I3C_DEV);
> + }
> +
> + if (master->ops->reattach_i3c_dev) {
> + ret = master->ops->reattach_i3c_dev(dev, old_dyn_addr);
> + if (ret) {
> + i3c_master_put_i3c_addrs(dev);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void i3c_master_detach_i3c_dev(struct i3c_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> +
> + /* Do not detach the master device itself. */
> + if (master->this != dev && master->ops->detach_i3c_dev)
> + master->ops->detach_i3c_dev(dev);
> +
> + i3c_master_put_i3c_addrs(dev);
> + list_del(&dev->common.node);
> +}
> +
> +static int i3c_master_attach_i2c_dev(struct i3c_master_controller
*master,
> + struct i2c_dev_desc *dev)
> +{
> + int ret;
> +
> + if (master->ops->attach_i2c_dev) {
> + ret = master->ops->attach_i2c_dev(dev);
> + if (ret)
> + return ret;
> + }
> +
> + list_add_tail(&dev->common.node, &master->bus->devs.i2c);
> +
> + return 0;
> +}
> +
> +static void i3c_master_detach_i2c_dev(struct i2c_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i2c_dev_get_master(dev);
> +
> + list_del(&dev->common.node);
> +
> + if (master->ops->detach_i2c_dev)
> + master->ops->detach_i2c_dev(dev);
> +}
> +
> +static void i3c_master_pre_assign_dyn_addr(struct i3c_dev_desc *dev)
> +{
> + struct i3c_master_controller *master = i3c_dev_get_master(dev);
> + struct i3c_device_info info;
> + int ret;
> +
> + if (!dev->boardinfo || !dev->boardinfo->init_dyn_addr ||
> + !dev->boardinfo->static_addr)
> + return;
> +
> + ret = i3c_master_setdasa_locked(master, dev->info.static_addr,
> + dev->boardinfo->init_dyn_addr);
> + if (ret)
> + return;
> +
> + dev->info.dyn_addr = dev->boardinfo->init_dyn_addr;
> + ret = i3c_master_reattach_i3c_dev(dev, 0);
> + if (ret)
> + return;
> +
> + ret = i3c_master_retrieve_dev_info(dev);
> + if (ret)
> + goto err_rstdaa;
> +
> + dev->info = info;
> +
> + return;
> +
> +err_rstdaa:
> + i3c_master_rstdaa_locked(master, dev->boardinfo->init_dyn_addr);
> +}
> +
> +static void
> +i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
> +{
> + struct i3c_dev_desc *desc;
> + int ret;
> +
> + if (!master->init_done)
> + return;
> +
> + i3c_bus_for_each_i3cdev(master->bus, desc) {
> + if (desc->dev || !desc->info.dyn_addr)
> + continue;
> +
> + desc->dev = kzalloc(sizeof(*desc->dev), GFP_KERNEL);
> + if (!desc->dev)
> + continue;
> +
> + desc->dev->bus = master->bus;
> + desc->dev->desc = desc;
> + desc->dev->dev.parent = &master->bus->dev;
> + if (desc == master->this)
> + desc->dev->dev.type = &i3c_master_type;
> + else
> + desc->dev->dev.type = &i3c_device_type;
> + desc->dev->dev.bus = &i3c_bus_type;
> + desc->dev->dev.release = i3c_device_release;
> + dev_set_name(&desc->dev->dev, "%d-%llx", master->bus-
> >id,
> + desc->info.pid);
> +
> + if (desc->boardinfo)
> + desc->dev->dev.of_node = desc->boardinfo-
> >of_node;
> +
> + pr_info("%s:%i\n", __func__, __LINE__);
> + if (ret)
> + dev_err(master->parent,
> + "Failed to add I3C device (err = %d)\n",
ret);
> + }
> +}
The compiler gives a warning that "ret" may be used uninitialized in the
above function, which is true since "ret" is never assigned a value. Also,
I wonder about the "pr_info" call here, should there be a more detailed
message here about the device being registered, other than the file name and
line number?
Otherwise, I have gone through the code in the process of writing the first
iteration of the Qualcomm I3C master driver, and overall the framework looks
good. Will update with any additional feedback I have.
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-03 21:38 ` mshettel
@ 2018-08-04 5:33 ` Boris Brezillon
0 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-08-04 5:33 UTC (permalink / raw)
To: mshettel
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',
'Cyprian Wronka', 'Suresh Punnoose',
'Rafal Ciepiela', 'Thomas Petazzoni',
'Nishanth Menon', 'Rob Herring',
'Pawel Moll', 'Mark Rutland',
'Ian Campbell', 'Kumar Gala',
devicetree, linux-kernel, 'Vitor Soares',
'Geert Uytterhoeven', 'Linus Walleij',
'Xiang Lin', linux-gpio, 'Sekhar Nori',
'Przemyslaw Gaj', 'Peter Rosin'
Hi Mike,
On Fri, 3 Aug 2018 15:38:43 -0600
<mshettel@codeaurora.org> wrote:
> > +static void
> > +i3c_master_register_new_i3c_devs(struct i3c_master_controller *master)
> > +{
> > + struct i3c_dev_desc *desc;
> > + int ret;
> > +
> > + if (!master->init_done)
> > + return;
> > +
> > + i3c_bus_for_each_i3cdev(master->bus, desc) {
> > + if (desc->dev || !desc->info.dyn_addr)
> > + continue;
> > +
> > + desc->dev = kzalloc(sizeof(*desc->dev), GFP_KERNEL);
> > + if (!desc->dev)
> > + continue;
> > +
> > + desc->dev->bus = master->bus;
> > + desc->dev->desc = desc;
> > + desc->dev->dev.parent = &master->bus->dev;
> > + if (desc == master->this)
> > + desc->dev->dev.type = &i3c_master_type;
> > + else
> > + desc->dev->dev.type = &i3c_device_type;
> > + desc->dev->dev.bus = &i3c_bus_type;
> > + desc->dev->dev.release = i3c_device_release;
> > + dev_set_name(&desc->dev->dev, "%d-%llx", master->bus-
> > >id,
> > + desc->info.pid);
> > +
> > + if (desc->boardinfo)
> > + desc->dev->dev.of_node = desc->boardinfo-
> > >of_node;
> > +
> > + pr_info("%s:%i\n", __func__, __LINE__);
> > + if (ret)
> > + dev_err(master->parent,
> > + "Failed to add I3C device (err = %d)\n",
> ret);
> > + }
> > +}
>
> The compiler gives a warning that "ret" may be used uninitialized in the
> above function, which is true since "ret" is never assigned a value. Also,
> I wonder about the "pr_info" call here, should there be a more detailed
> message here about the device being registered, other than the file name and
> line number?
Yes, kbuild already reported that problem. I messed up when selecting
the lines to add to my commit and added this trace instead of
ret = device_register(&desc->dev->dev);
Will be fixed in v7.
>
> Otherwise, I have gone through the code in the process of writing the first
> iteration of the Qualcomm I3C master driver, and overall the framework looks
> good. Will update with any additional feedback I have.
Thanks for looking at the framework code. Your driver is in my TODO
list.
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
2018-08-03 21:38 ` mshettel
@ 2018-08-22 16:43 ` vitor
2018-08-24 12:39 ` Boris Brezillon
1 sibling, 1 reply; 71+ messages in thread
From: vitor @ 2018-08-22 16:43 UTC (permalink / raw)
To: Boris Brezillon, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel, Vitor Soares,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, linux-gpio,
Sekhar Nori, Przemyslaw Gaj, Peter Rosin
Hi Boris,
On 19-07-2018 16:29, Boris Brezillon wrote:
> +int i3c_bus_register(struct i3c_bus *i3cbus)
> +{
> + struct i2c_dev_desc *desc;
> +
> + i3c_bus_for_each_i2cdev(i3cbus, desc) {
> + switch (desc->boardinfo->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_add(&i3cbus->dev);
> +}
During the tests of the bus with i2c devices I found the i2c_dev_desc
objects aren't allocated before this function. This cause i3cbus->mode =
I3C_BUS_MODE_PURE.
I want to do something for the slave and secondary master, do you
already have infrastructure that you can share?
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-22 16:43 ` vitor
@ 2018-08-24 12:39 ` Boris Brezillon
2018-08-24 17:52 ` vitor
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-08-24 12:39 UTC (permalink / raw)
To: vitor, linux-gpio, Sekhar Nori
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, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Geert Uytterhoeven, Linus Walleij, Xiang Lin,
Przemyslaw Gaj, Peter Rosin
Hi Vitor,
On Wed, 22 Aug 2018 17:43:34 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
>
> On 19-07-2018 16:29, Boris Brezillon wrote:
> > +int i3c_bus_register(struct i3c_bus *i3cbus)
> > +{
> > + struct i2c_dev_desc *desc;
> > +
> > + i3c_bus_for_each_i2cdev(i3cbus, desc) {
> > + switch (desc->boardinfo->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_add(&i3cbus->dev);
> > +}
> During the tests of the bus with i2c devices I found the i2c_dev_desc
> objects aren't allocated before this function. This cause i3cbus->mode =
> I3C_BUS_MODE_PURE.
I just checked and DT parsing (+ I2C descs creation) is done before
i3c_bus_register() is called, so we should be good. How did you declare
your I2C devices (right now, only DT declaration is supported).
>
> I want to do something for the slave and secondary master, do you
> already have infrastructure that you can share?
What do you mean?
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-24 12:39 ` Boris Brezillon
@ 2018-08-24 17:52 ` vitor
2018-08-24 18:16 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: vitor @ 2018-08-24 17:52 UTC (permalink / raw)
To: Boris Brezillon, vitor, linux-gpio, Sekhar Nori
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, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree,
linux-kernel, Geert Uytterhoeven, Linus Walleij, Xiang Lin,
Przemyslaw Gaj, Peter Rosin
Hi Boris,
On 24-08-2018 13:39, Boris Brezillon wrote:
> Hi Vitor,
>
> On Wed, 22 Aug 2018 17:43:34 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
>> Hi Boris,
>>
>>
>> On 19-07-2018 16:29, Boris Brezillon wrote:
>>> +int i3c_bus_register(struct i3c_bus *i3cbus)
>>> +{
>>> + struct i2c_dev_desc *desc;
>>> +
>>> + i3c_bus_for_each_i2cdev(i3cbus, desc) {
>>> + switch (desc->boardinfo->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_add(&i3cbus->dev);
>>> +}
>> During the tests of the bus with i2c devices I found the i2c_dev_desc
>> objects aren't allocated before this function. This cause i3cbus->mode =
>> I3C_BUS_MODE_PURE.
> I just checked and DT parsing (+ I2C descs creation) is done before
> i3c_bus_register() is called, so we should be good. How did you declare
> your I2C devices (right now, only DT declaration is supported).
During the DT parsing, you create the i2c_dev_boardinfo. the
i2c_dev_desc is created in i3c_master_bus_init() which is after the
i3c_mater_create_bus(). One possible way to fix this is to pass master
also to i3c_bus_register and iterate over i2c_dev_board_info list.
>> I want to do something for the slave and secondary master, do you
>> already have infrastructure that you can share?
> What do you mean?
>
> Regards,
>
> Boris
I want start to add the secondary master functionality but it is also
necessary to add the infrastructure to the subsystem.
So, to avoid duplicated work can you share your plans for the secondary
master?
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-24 17:52 ` vitor
@ 2018-08-24 18:16 ` Boris Brezillon
2018-08-28 11:50 ` vitor
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-08-24 18:16 UTC (permalink / raw)
To: vitor
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Przemyslaw Gaj,
Peter Rosin
Hi Vitor,
On Fri, 24 Aug 2018 18:52:52 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
>
> On 24-08-2018 13:39, Boris Brezillon wrote:
> > Hi Vitor,
> >
> > On Wed, 22 Aug 2018 17:43:34 +0100
> > vitor <Vitor.Soares@synopsys.com> wrote:
> >
> >> Hi Boris,
> >>
> >>
> >> On 19-07-2018 16:29, Boris Brezillon wrote:
> >>> +int i3c_bus_register(struct i3c_bus *i3cbus)
> >>> +{
> >>> + struct i2c_dev_desc *desc;
> >>> +
> >>> + i3c_bus_for_each_i2cdev(i3cbus, desc) {
> >>> + switch (desc->boardinfo->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_add(&i3cbus->dev);
> >>> +}
> >> During the tests of the bus with i2c devices I found the i2c_dev_desc
> >> objects aren't allocated before this function. This cause i3cbus->mode =
> >> I3C_BUS_MODE_PURE.
> > I just checked and DT parsing (+ I2C descs creation) is done before
> > i3c_bus_register() is called, so we should be good. How did you declare
> > your I2C devices (right now, only DT declaration is supported).
> During the DT parsing, you create the i2c_dev_boardinfo. the
> i2c_dev_desc is created in i3c_master_bus_init() which is after the
> i3c_mater_create_bus().
Oops, you're right.
> One possible way to fix this is to pass master
> also to i3c_bus_register and iterate over i2c_dev_board_info list.
Yes, that's the proper fix. I'll do that in v7.
>
> >> I want to do something for the slave and secondary master, do you
> >> already have infrastructure that you can share?
> > What do you mean?
> >
> > Regards,
> >
> > Boris
>
> I want start to add the secondary master functionality but it is also
> necessary to add the infrastructure to the subsystem.
> So, to avoid duplicated work can you share your plans for the secondary
> master?
Well, before even considering supporting secondary master registration,
we need to handle mastership handover. As for the DAA operation, it's
likely to be host specific, so we'll have to add a new hook to the
i3c_master_controller_ops struct.
Once you've done that, we'll have trigger a mastership handover
everytime an I3C driver tries to send a frame on the bus, and the
master this frame should do through is not in control of the bus. That
should be pretty easy for the nominal case, but error cases are likely
to be hard to deal with.
Note that I have a ->cur_master field in the i3c_bus object which
stores allows us to track whose the currently active master. If
master->this != master->bus->cur_master that means you need to start a
mastership handover procedure.
That's all I thought about for now, and we'll probably face other
problems when implementing it. Let me know if you have other questions,
and don't hesitate to share your code early during the development
phase.
Also note that the bus representation is likely to change based on
Arnd's feedback, so you might have to rework your implementation a bit
at some point.
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-24 18:16 ` Boris Brezillon
@ 2018-08-28 11:50 ` vitor
2018-08-28 12:02 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: vitor @ 2018-08-28 11:50 UTC (permalink / raw)
To: Boris Brezillon, vitor
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Przemyslaw Gaj,
Peter Rosin
Hi Boris,
The DT Bindings say "The node describing an I3C bus should be named
i3c-master.". Do you have a field for secondary master?
On 24-08-2018 19:16, Boris Brezillon wrote:
> Well, before even considering supporting secondary master registration,
> we need to handle mastership handover. As for the DAA operation, it's
> likely to be host specific, so we'll have to add a new hook to the
> i3c_master_controller_ops struct.
Do you mean when master try to delegate the bus ownership through
GETACCMST? or to get the bus ownership with IBI-MR?
I think that could be useful to pass the ibi type on request_ibi(),
there is some case where the master doesn't support IBI-MR.
> Once you've done that, we'll have trigger a mastership handover
> everytime an I3C driver tries to send a frame on the bus, and the
> master this frame should do through is not in control of the bus. That
> should be pretty easy for the nominal case, but error cases are likely
> to be hard to deal with.
> Note that I have a ->cur_master field in the i3c_bus object which
> stores allows us to track whose the currently active master. If
> master->this != master->bus->cur_master that means you need to start a
> mastership handover procedure.
>
> That's all I thought about for now, and we'll probably face other
> problems when implementing it. Let me know if you have other questions,
> and don't hesitate to share your code early during the development
> phase.
>
> Also note that the bus representation is likely to change based on
> Arnd's feedback, so you might have to rework your implementation a bit
> at some point.
>
> Regards,
>
> Boris
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 11:50 ` vitor
@ 2018-08-28 12:02 ` Boris Brezillon
2018-08-28 12:55 ` Przemyslaw Gaj
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-08-28 12:02 UTC (permalink / raw)
To: vitor
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Przemyslaw Gaj,
Peter Rosin
Hi Vitor,
On Tue, 28 Aug 2018 12:50:12 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
> The DT Bindings say "The node describing an I3C bus should be named
> i3c-master.". Do you have a field for secondary master?
>
> On 24-08-2018 19:16, Boris Brezillon wrote:
> > Well, before even considering supporting secondary master registration,
> > we need to handle mastership handover. As for the DAA operation, it's
> > likely to be host specific, so we'll have to add a new hook to the
> > i3c_master_controller_ops struct.
> Do you mean when master try to delegate the bus ownership through
> GETACCMST? or to get the bus ownership with IBI-MR?
I think we need to support both.
>
> I think that could be useful to pass the ibi type on request_ibi(),
> there is some case where the master doesn't support IBI-MR.
Actually, I was planning on making it completely separate from
regular slave IBIs. That is, the master controller driver would demux
the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
mastership handover work to the workqueue (pretty much what we do for
Hot-Join already). Mastership handover is anyway likely to be IP
specific, so I don't think there's a need to make it look like a
regular IBI.
Regarding whether IBI-MR support should be exposed to the I3C framework
or not depends on how much will be automated on the framework side. I
don't the answer yet, but that's probably something will figure out
along the road.
Regards,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 12:02 ` Boris Brezillon
@ 2018-08-28 12:55 ` Przemyslaw Gaj
2018-08-28 13:01 ` Boris Brezillon
` (2 more replies)
0 siblings, 3 replies; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-08-28 12:55 UTC (permalink / raw)
To: Boris Brezillon, vitor
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Vitor,
I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
Hi Vitor,
On Tue, 28 Aug 2018 12:50:12 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
> The DT Bindings say "The node describing an I3C bus should be named
> i3c-master.". Do you have a field for secondary master?
I think we don’t need separate field for secondary master. Main and secondary masters
support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
>
> On 24-08-2018 19:16, Boris Brezillon wrote:
> > Well, before even considering supporting secondary master registration,
> > we need to handle mastership handover. As for the DAA operation, it's
> > likely to be host specific, so we'll have to add a new hook to the
> > i3c_master_controller_ops struct.
> Do you mean when master try to delegate the bus ownership through
> GETACCMST? or to get the bus ownership with IBI-MR?
I think we need to support both.
I agree.
>
> I think that could be useful to pass the ibi type on request_ibi(),
> there is some case where the master doesn't support IBI-MR.
Actually, I was planning on making it completely separate from
regular slave IBIs. That is, the master controller driver would demux
the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
mastership handover work to the workqueue (pretty much what we do for
Hot-Join already). Mastership handover is anyway likely to be IP
specific, so I don't think there's a need to make it look like a
regular IBI.
I think it's better to have separate function to do mastership request.
Regarding whether IBI-MR support should be exposed to the I3C framework
or not depends on how much will be automated on the framework side. I
don't the answer yet, but that's probably something will figure out
along the road.
My current implementation is: when request_mastership field
of i3c_master_controller_ops structure is set, master driver supports mastership requests.
That's how I check if this is supported or not.
Regards,
Boris
Regards,
Przemek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 12:55 ` Przemyslaw Gaj
@ 2018-08-28 13:01 ` Boris Brezillon
2018-08-29 7:41 ` Przemyslaw Gaj
2018-08-28 13:03 ` Boris Brezillon
2018-08-30 13:57 ` vitor
2 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-08-28 13:01 UTC (permalink / raw)
To: Przemyslaw Gaj
Cc: vitor, linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Przemek,
On Tue, 28 Aug 2018 12:55:20 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
> Hi Vitor,
>
> I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
>
> On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> Hi Vitor,
>
> On Tue, 28 Aug 2018 12:50:12 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
> > Hi Boris,
> >
> > The DT Bindings say "The node describing an I3C bus should be named
> > i3c-master.". Do you have a field for secondary master?
>
> I think we don’t need separate field for secondary master. Main and secondary masters
> support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
>
> >
> > On 24-08-2018 19:16, Boris Brezillon wrote:
> > > Well, before even considering supporting secondary master registration,
> > > we need to handle mastership handover. As for the DAA operation, it's
> > > likely to be host specific, so we'll have to add a new hook to the
> > > i3c_master_controller_ops struct.
> > Do you mean when master try to delegate the bus ownership through
> > GETACCMST? or to get the bus ownership with IBI-MR?
>
> I think we need to support both.
>
> I agree.
>
> >
> > I think that could be useful to pass the ibi type on request_ibi(),
> > there is some case where the master doesn't support IBI-MR.
>
> Actually, I was planning on making it completely separate from
> regular slave IBIs. That is, the master controller driver would demux
> the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
> mastership handover work to the workqueue (pretty much what we do for
> Hot-Join already). Mastership handover is anyway likely to be IP
> specific, so I don't think there's a need to make it look like a
> regular IBI.
>
> I think it's better to have separate function to do mastership request.
>
> Regarding whether IBI-MR support should be exposed to the I3C framework
> or not depends on how much will be automated on the framework side. I
> don't the answer yet, but that's probably something will figure out
> along the road.
>
> My current implementation is: when request_mastership field
> of i3c_master_controller_ops structure is set, master driver supports mastership requests.
> That's how I check if this is supported or not.
Can you maybe host your code on a public repo (I can push it for you if
needed) so that you and Vitor can start discussing implementation
details.
Thanks,
Boris
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 12:55 ` Przemyslaw Gaj
2018-08-28 13:01 ` Boris Brezillon
@ 2018-08-28 13:03 ` Boris Brezillon
2018-08-30 13:57 ` vitor
2 siblings, 0 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-08-28 13:03 UTC (permalink / raw)
To: Przemyslaw Gaj
Cc: vitor, linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
On Tue, 28 Aug 2018 12:55:20 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
> Hi Vitor,
>
> I have already implemented Mastership request/handover but we are
> waiting for Boris’s patch to be accepted and merged.
My bad. I didn't have time to work on the bus/master rework suggested
by Arnd before going on vacation. I hope I'll be able to work on that
soon.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 13:01 ` Boris Brezillon
@ 2018-08-29 7:41 ` Przemyslaw Gaj
0 siblings, 0 replies; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-08-29 7:41 UTC (permalink / raw)
To: Boris Brezillon
Cc: vitor, linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Boris,
On 8/28/18, 3:01 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
Hi Przemek,
On Tue, 28 Aug 2018 12:55:20 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
> Hi Vitor,
>
> I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
>
> On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> Hi Vitor,
>
> On Tue, 28 Aug 2018 12:50:12 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
> > Hi Boris,
> >
> > The DT Bindings say "The node describing an I3C bus should be named
> > i3c-master.". Do you have a field for secondary master?
>
> I think we don’t need separate field for secondary master. Main and secondary masters
> support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
>
> >
> > On 24-08-2018 19:16, Boris Brezillon wrote:
> > > Well, before even considering supporting secondary master registration,
> > > we need to handle mastership handover. As for the DAA operation, it's
> > > likely to be host specific, so we'll have to add a new hook to the
> > > i3c_master_controller_ops struct.
> > Do you mean when master try to delegate the bus ownership through
> > GETACCMST? or to get the bus ownership with IBI-MR?
>
> I think we need to support both.
>
> I agree.
>
> >
> > I think that could be useful to pass the ibi type on request_ibi(),
> > there is some case where the master doesn't support IBI-MR.
>
> Actually, I was planning on making it completely separate from
> regular slave IBIs. That is, the master controller driver would demux
> the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
> mastership handover work to the workqueue (pretty much what we do for
> Hot-Join already). Mastership handover is anyway likely to be IP
> specific, so I don't think there's a need to make it look like a
> regular IBI.
>
> I think it's better to have separate function to do mastership request.
>
> Regarding whether IBI-MR support should be exposed to the I3C framework
> or not depends on how much will be automated on the framework side. I
> don't the answer yet, but that's probably something will figure out
> along the road.
>
> My current implementation is: when request_mastership field
> of i3c_master_controller_ops structure is set, master driver supports mastership requests.
> That's how I check if this is supported or not.
Can you maybe host your code on a public repo (I can push it for you if
needed) so that you and Vitor can start discussing implementation
details.
Sure! Please give me some time. I'll try to do it this week or early next week.
Thanks,
Boris
Thanks,
Przemek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-28 12:55 ` Przemyslaw Gaj
2018-08-28 13:01 ` Boris Brezillon
2018-08-28 13:03 ` Boris Brezillon
@ 2018-08-30 13:57 ` vitor
2018-08-30 19:00 ` Przemyslaw Gaj
2 siblings, 1 reply; 71+ messages in thread
From: vitor @ 2018-08-30 13:57 UTC (permalink / raw)
To: Przemyslaw Gaj, Boris Brezillon, vitor
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Przemyslaw
On 28-08-2018 13:55, Przemyslaw Gaj wrote:
> Hi Vitor,
>
> I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
>
> On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> Hi Vitor,
>
> On Tue, 28 Aug 2018 12:50:12 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
> > Hi Boris,
> >
> > The DT Bindings say "The node describing an I3C bus should be named
> > i3c-master.". Do you have a field for secondary master?
>
> I think we don’t need separate field for secondary master. Main and secondary masters
> support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
Yes, you are right.
>
> >
> > On 24-08-2018 19:16, Boris Brezillon wrote:
> > > Well, before even considering supporting secondary master registration,
> > > we need to handle mastership handover. As for the DAA operation, it's
> > > likely to be host specific, so we'll have to add a new hook to the
> > > i3c_master_controller_ops struct.
> > Do you mean when master try to delegate the bus ownership through
> > GETACCMST? or to get the bus ownership with IBI-MR?
>
> I think we need to support both.
>
> I agree.
That's ok to me.
>
> >
> > I think that could be useful to pass the ibi type on request_ibi(),
> > there is some case where the master doesn't support IBI-MR.
>
> Actually, I was planning on making it completely separate from
> regular slave IBIs. That is, the master controller driver would demux
> the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
> mastership handover work to the workqueue (pretty much what we do for
> Hot-Join already). Mastership handover is anyway likely to be IP
> specific, so I don't think there's a need to make it look like a
> regular IBI.
>
> I think it's better to have separate function to do mastership request.
>
> Regarding whether IBI-MR support should be exposed to the I3C framework
> or not depends on how much will be automated on the framework side. I
> don't the answer yet, but that's probably something will figure out
> along the road.
>
> My current implementation is: when request_mastership field
> of i3c_master_controller_ops structure is set, master driver supports mastership requests.
> That's how I check if this is supported or not.
>
> Regards,
>
> Boris
>
> Regards,
> Przemek
>
when you say request_mastership, do you mean the current master do the
mastership hand-off or the secondary master request to be current master?
So, per my understanding since the Main master support the hand-off of
the bus you accept all incoming MR, right? Or do you check all devices BCR?
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-30 13:57 ` vitor
@ 2018-08-30 19:00 ` Przemyslaw Gaj
2018-09-03 9:33 ` vitor
0 siblings, 1 reply; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-08-30 19:00 UTC (permalink / raw)
To: vitor, Boris Brezillon
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Vitor,
On 8/30/18, 3:57 PM, "vitor" <Vitor.Soares@synopsys.com> wrote:
EXTERNAL MAIL
Hi Przemyslaw
Just Przemek :)
On 28-08-2018 13:55, Przemyslaw Gaj wrote:
> Hi Vitor,
>
> I have already implemented Mastership request/handover but we are waiting for Boris’s patch to be accepted and merged. Anyway, my comments below.
>
> On 8/28/18, 2:02 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> Hi Vitor,
>
> On Tue, 28 Aug 2018 12:50:12 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
> > Hi Boris,
> >
> > The DT Bindings say "The node describing an I3C bus should be named
> > i3c-master.". Do you have a field for secondary master?
>
> I think we don’t need separate field for secondary master. Main and secondary masters
> support similar functionalities. It’s enough to have this state internally and do mastership it it's needed.
Yes, you are right.
>
> >
> > On 24-08-2018 19:16, Boris Brezillon wrote:
> > > Well, before even considering supporting secondary master registration,
> > > we need to handle mastership handover. As for the DAA operation, it's
> > > likely to be host specific, so we'll have to add a new hook to the
> > > i3c_master_controller_ops struct.
> > Do you mean when master try to delegate the bus ownership through
> > GETACCMST? or to get the bus ownership with IBI-MR?
>
> I think we need to support both.
>
> I agree.
That's ok to me.
>
> >
> > I think that could be useful to pass the ibi type on request_ibi(),
> > there is some case where the master doesn't support IBI-MR.
>
> Actually, I was planning on making it completely separate from
> regular slave IBIs. That is, the master controller driver would demux
> the slave, MR and Hot Join IBIs, and if there's an MR request, queue a
> mastership handover work to the workqueue (pretty much what we do for
> Hot-Join already). Mastership handover is anyway likely to be IP
> specific, so I don't think there's a need to make it look like a
> regular IBI.
>
> I think it's better to have separate function to do mastership request.
>
> Regarding whether IBI-MR support should be exposed to the I3C framework
> or not depends on how much will be automated on the framework side. I
> don't the answer yet, but that's probably something will figure out
> along the road.
>
> My current implementation is: when request_mastership field
> of i3c_master_controller_ops structure is set, master driver supports mastership requests.
> That's how I check if this is supported or not.
>
> Regards,
>
> Boris
>
> Regards,
> Przemek
>
when you say request_mastership, do you mean the current master do the
mastership hand-off or the secondary master request to be current master?
I mean secondary master requests to be current master. Current master do the mastership
hand-off using GETACCMST command.
So, per my understanding since the Main master support the hand-off of
the bus you accept all incoming MR, right? Or do you check all devices BCR?
I'm not sure what do you mean here. Mastership request(MR) is from secondary master
to current master. Current master can NACK this request if for example it comes from
wrong device. If it's ok, current master sends GETACCMST command and secondary master
may ACK or NACK this command. It it's acked, secondary master becomes current master.
Best regards,
Vitor Soares
Please let me know if something is unclear.
Regards,
Przemek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-08-30 19:00 ` Przemyslaw Gaj
@ 2018-09-03 9:33 ` vitor
2018-09-04 11:03 ` Przemyslaw Gaj
2018-09-06 12:43 ` Przemyslaw Gaj
0 siblings, 2 replies; 71+ messages in thread
From: vitor @ 2018-09-03 9:33 UTC (permalink / raw)
To: Przemyslaw Gaj, vitor, Boris Brezillon
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Przemek,
On 30-08-2018 20:00, Przemyslaw Gaj wrote:
> So, per my understanding since the Main master support the hand-off of
> the bus you accept all incoming MR, right? Or do you check all devices BCR?
>
> I'm not sure what do you mean here. Mastership request(MR) is from secondary master
> to current master. Current master can NACK this request if for example it comes from
> wrong device. If it's ok, current master sends GETACCMST command and secondary master
> may ACK or NACK this command. It it's acked, secondary master becomes current master.
>
> Best regards,
> Vitor Soares
>
> Please let me know if something is unclear.
>
> Regards,
> Przemek
>
Sorry, it s not clear yet.
For instances there is a bus with several secondary master. If each of
them request the bus mastership (one at a time), will you accept all by
default? Because you can only accept only some of them.
Regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-03 9:33 ` vitor
@ 2018-09-04 11:03 ` Przemyslaw Gaj
2018-09-06 12:43 ` Przemyslaw Gaj
1 sibling, 0 replies; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-04 11:03 UTC (permalink / raw)
To: vitor, Boris Brezillon
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Vitor,
On 9/3/18, 11:33 AM, "vitor" <Vitor.Soares@synopsys.com> wrote:
EXTERNAL MAIL
Hi Przemek,
On 30-08-2018 20:00, Przemyslaw Gaj wrote:
> So, per my understanding since the Main master support the hand-off of
> the bus you accept all incoming MR, right? Or do you check all devices BCR?
>
> I'm not sure what do you mean here. Mastership request(MR) is from secondary master
> to current master. Current master can NACK this request if for example it comes from
> wrong device. If it's ok, current master sends GETACCMST command and secondary master
> may ACK or NACK this command. It it's acked, secondary master becomes current master.
>
> Best regards,
> Vitor Soares
>
> Please let me know if something is unclear.
>
> Regards,
> Przemek
>
Sorry, it s not clear yet.
For instances there is a bus with several secondary master. If each of
them request the bus mastership (one at a time), will you accept all by
default? Because you can only accept only some of them.
First of all, only devices which have Mastership request event enabled (ENMR slave event)
can request mastership. Second thing is that this device needs to have IBI enabled in
current master. I accept all such devices. There is no additional logic for now, we can add it
in the future.
I was very busy recently. I'm almost ready to publish my changes related to mastership request.
I'm sorry for the delay.
Regards,
Vitor Soares
Regards,
Przemek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-03 9:33 ` vitor
2018-09-04 11:03 ` Przemyslaw Gaj
@ 2018-09-06 12:43 ` Przemyslaw Gaj
2018-09-06 12:59 ` Arnd Bergmann
1 sibling, 1 reply; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-06 12:43 UTC (permalink / raw)
To: vitor, Boris Brezillon
Cc: linux-gpio, Sekhar Nori, 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, Cyprian Wronka,
Suresh Punnoose, Rafal Ciepiela, Thomas Petazzoni,
Nishanth Menon, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree, linux-kernel,
Geert Uytterhoeven, Linus Walleij, Xiang Lin, Peter Rosin
Hi Boris, Vitor,
This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
https://github.com/przemekgaj/i3c-linux/commit/d54fe68a9d3e573c0c454a2c6f1afafc20142ec5
Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
Thanks,
Przemek
On 9/3/18, 11:33 AM, "vitor" <Vitor.Soares@synopsys.com> wrote:
EXTERNAL MAIL
Hi Przemek,
On 30-08-2018 20:00, Przemyslaw Gaj wrote:
> So, per my understanding since the Main master support the hand-off of
> the bus you accept all incoming MR, right? Or do you check all devices BCR?
>
> I'm not sure what do you mean here. Mastership request(MR) is from secondary master
> to current master. Current master can NACK this request if for example it comes from
> wrong device. If it's ok, current master sends GETACCMST command and secondary master
> may ACK or NACK this command. It it's acked, secondary master becomes current master.
>
> Best regards,
> Vitor Soares
>
> Please let me know if something is unclear.
>
> Regards,
> Przemek
>
Sorry, it s not clear yet.
For instances there is a bus with several secondary master. If each of
them request the bus mastership (one at a time), will you accept all by
default? Because you can only accept only some of them.
Regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 12:43 ` Przemyslaw Gaj
@ 2018-09-06 12:59 ` Arnd Bergmann
2018-09-06 13:14 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: Arnd Bergmann @ 2018-09-06 12:59 UTC (permalink / raw)
To: Przemyslaw Gaj
Cc: Vitor Soares, Boris Brezillon, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
>
> Hi Boris, Vitor,
>
> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> https://github.com/przemekgaj/i3c-linux/commit/d54fe68a9d3e573c0c454a2c6f1afafc20142ec5
>
> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
>
> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
Can you explain the reason for having a user space interface and DT property?
I thought we had concluded earlier that we wouldn't need that, but it's possible
that I missed something in the discussion since then.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 12:59 ` Arnd Bergmann
@ 2018-09-06 13:14 ` Boris Brezillon
2018-09-06 13:20 ` Boris Brezillon
2018-09-06 13:47 ` Przemyslaw Gaj
0 siblings, 2 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-09-06 13:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Przemyslaw Gaj, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, 6 Sep 2018 14:59:46 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >
> > Hi Boris, Vitor,
> >
> > This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > https://github.com/przemekgaj/i3c-linux/commit/d54fe68a9d3e573c0c454a2c6f1afafc20142ec5
> >
> > Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >
> > I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
>
>
> Can you explain the reason for having a user space interface and DT property?
> I thought we had concluded earlier that we wouldn't need that, but it's possible
> that I missed something in the discussion since then.
I don't think the sysfs knob is needed, this being said, after thinking
a bit more about mastership handover and the secondary master case, I
think we have something important to solve.
When a master is not in control of the bus, it gets informed of devices
present on the bus by monitoring DAA or DEFSLVS broadcast events. That
means the secondary master should populate the bus with I3C/I2C devices
on such events, but that's not enough, because DEFSLVS/DAA do not
provide all device info. Some of them (like read/write/ibi limitations)
require extra CCC commands, and, to send those CCC commands, the
secondary master must claim the bus. We could add a case where we
declare devices as partially discovered until the master acquires
ownership of the bus, but that means part of the data returned by
i3c_device_get_info() will be inaccurate, which might have an impact on
some i3c driver ->probe() functions.
We could also say that partially discovered devices should not be
registered to the device model, but we then hit the problem of "who can
force the secondary master to claim the bus if there's no users?".
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:14 ` Boris Brezillon
@ 2018-09-06 13:20 ` Boris Brezillon
2018-09-06 13:45 ` Arnd Bergmann
2018-09-06 13:50 ` vitor
2018-09-06 13:47 ` Przemyslaw Gaj
1 sibling, 2 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-09-06 13:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Przemyslaw Gaj, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, 6 Sep 2018 15:14:37 +0200
Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> On Thu, 6 Sep 2018 14:59:46 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> > >
> > > Hi Boris, Vitor,
> > >
> > > This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > > https://github.com/przemekgaj/i3c-linux/commit/d54fe68a9d3e573c0c454a2c6f1afafc20142ec5
> > >
> > > Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > > It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> > >
> > > I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >
> >
> > Can you explain the reason for having a user space interface and DT property?
> > I thought we had concluded earlier that we wouldn't need that, but it's possible
> > that I missed something in the discussion since then.
>
> I don't think the sysfs knob is needed, this being said, after thinking
> a bit more about mastership handover and the secondary master case, I
> think we have something important to solve.
>
> When a master is not in control of the bus, it gets informed of devices
> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> means the secondary master should populate the bus with I3C/I2C devices
> on such events, but that's not enough, because DEFSLVS/DAA do not
> provide all device info. Some of them (like read/write/ibi limitations)
> require extra CCC commands, and, to send those CCC commands, the
> secondary master must claim the bus. We could add a case where we
> declare devices as partially discovered until the master acquires
> ownership of the bus, but that means part of the data returned by
> i3c_device_get_info() will be inaccurate, which might have an impact on
> some i3c driver ->probe() functions.
Hm, one possible solution would be to register partially discovered
devices to the device model and let i3c_device_get_info() claim the bus
and request missing data when needed. This way, if the driver needs to
call i3c_device_get_info() in its probe path, it should work just fine.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:20 ` Boris Brezillon
@ 2018-09-06 13:45 ` Arnd Bergmann
2018-09-06 13:50 ` vitor
1 sibling, 0 replies; 71+ messages in thread
From: Arnd Bergmann @ 2018-09-06 13:45 UTC (permalink / raw)
To: Boris Brezillon
Cc: Przemyslaw Gaj, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, Sep 6, 2018 at 3:21 PM Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
>
> On Thu, 6 Sep 2018 15:14:37 +0200
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> > When a master is not in control of the bus, it gets informed of devices
> > present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> > means the secondary master should populate the bus with I3C/I2C devices
> > on such events, but that's not enough, because DEFSLVS/DAA do not
> > provide all device info. Some of them (like read/write/ibi limitations)
> > require extra CCC commands, and, to send those CCC commands, the
> > secondary master must claim the bus. We could add a case where we
> > declare devices as partially discovered until the master acquires
> > ownership of the bus, but that means part of the data returned by
> > i3c_device_get_info() will be inaccurate, which might have an impact on
> > some i3c driver ->probe() functions.
>
> Hm, one possible solution would be to register partially discovered
> devices to the device model and let i3c_device_get_info() claim the bus
> and request missing data when needed. This way, if the driver needs to
> call i3c_device_get_info() in its probe path, it should work just fine.
I guess you could also call i3c_device_get_info() in the common i3c_probe()
function before calling into the driver.
However, either way, we may still have a problem here: if the current master
decides not to hand over master access to us at all, the probe() function
will be blocked indefinitely, and that may stop us from probing other devices
later on, or hang the module loader (depending on what context that
probe() is called from).
Using a timeout here could avoid the hang, but leads to other potential
issues, e.g. how to decide whether to retry the probe later.
Arnd
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:14 ` Boris Brezillon
2018-09-06 13:20 ` Boris Brezillon
@ 2018-09-06 13:47 ` Przemyslaw Gaj
2018-09-06 14:09 ` Boris Brezillon
1 sibling, 1 reply; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-06 13:47 UTC (permalink / raw)
To: Boris Brezillon, Arnd Bergmann
Cc: Vitor Soares, open list:GPIO SUBSYSTEM, Sekhar Nori,
Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On 9/6/18, 3:14 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
On Thu, 6 Sep 2018 14:59:46 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >
> > Hi Boris, Vitor,
> >
> > This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=CMnAfM_OfpqcWZRfiqcRWw&m=OPSa25ENnrF0Qv70DG49ZngfdygJZubjo3TOgBA3pJ4&s=_C6i1KPplQGcWvQYPkrGx7V3TjKDJvqt3KG-vcdU2K4&e=
> >
> > Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >
> > I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
>
>
> Can you explain the reason for having a user space interface and DT property?
> I thought we had concluded earlier that we wouldn't need that, but it's possible
> that I missed something in the discussion since then.
I don't think the sysfs knob is needed, this being said, after thinking
a bit more about mastership handover and the secondary master case, I
think we have something important to solve.
When a master is not in control of the bus, it gets informed of devices
present on the bus by monitoring DAA or DEFSLVS broadcast events. That
means the secondary master should populate the bus with I3C/I2C devices
on such events, but that's not enough, because DEFSLVS/DAA do not
provide all device info. Some of them (like read/write/ibi limitations)
require extra CCC commands, and, to send those CCC commands, the
secondary master must claim the bus. We could add a case where we
declare devices as partially discovered until the master acquires
ownership of the bus, but that means part of the data returned by
i3c_device_get_info() will be inaccurate, which might have an impact on
some i3c driver ->probe() functions.
How do you want to handle cases when secondary master joins the bus after
DEFSLVS? Of course we can send DEFSLVS after secondary master joins the bus.
We could also say that partially discovered devices should not be
registered to the device model, but we then hit the problem of "who can
force the secondary master to claim the bus if there's no users?".
Now I feel like I missed something. Do you want to populate second instance
of the same physical bus? If yes, then we don't need to have reference
between masters in DT.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:20 ` Boris Brezillon
2018-09-06 13:45 ` Arnd Bergmann
@ 2018-09-06 13:50 ` vitor
2018-09-06 14:14 ` Boris Brezillon
1 sibling, 1 reply; 71+ messages in thread
From: vitor @ 2018-09-06 13:50 UTC (permalink / raw)
To: Boris Brezillon, Arnd Bergmann
Cc: Przemyslaw Gaj, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
Hi,
On 06-09-2018 14:20, Boris Brezillon wrote:
> On Thu, 6 Sep 2018 15:14:37 +0200
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>
>> On Thu, 6 Sep 2018 14:59:46 +0200
>> Arnd Bergmann <arnd@arndb.de> wrote:
>>
>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
>>>> Hi Boris, Vitor,
>>>>
>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
>>>>
>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
>>>>
>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
>>>
>>> Can you explain the reason for having a user space interface and DT property?
>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
>>> that I missed something in the discussion since then.
>> I don't think the sysfs knob is needed, this being said, after thinking
>> a bit more about mastership handover and the secondary master case, I
>> think we have something important to solve.
>>
>> When a master is not in control of the bus, it gets informed of devices
>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
>> means the secondary master should populate the bus with I3C/I2C devices
>> on such events, but that's not enough, because DEFSLVS/DAA do not
>> provide all device info.Some of them (like read/write/ibi limitations)
>> require extra CCC commands, and, to send those CCC commands, the
>> secondary master must claim the bus. We could add a case where we
>> declare devices as partially discovered until the master acquires
>> ownership of the bus, but that means part of the data returned by
>> i3c_device_get_info() will be inaccurate, which might have an impact on
>> some i3c driver ->probe() functions.
> Hm, one possible solution would be to register partially discovered
> devices to the device model and let i3c_device_get_info() claim the bus
> and request missing data when needed. This way, if the driver needs to
> call i3c_device_get_info() in its probe path, it should work just fine.
Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
attach and retrieve the device info.
This can be triggered after the secondary master receive ENEC MR until
them is keep in the driver memory.
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:47 ` Przemyslaw Gaj
@ 2018-09-06 14:09 ` Boris Brezillon
2018-09-06 14:20 ` Przemyslaw Gaj
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-09-06 14:09 UTC (permalink / raw)
To: Przemyslaw Gaj
Cc: Arnd Bergmann, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, 6 Sep 2018 13:47:29 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
> On 9/6/18, 3:14 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> On Thu, 6 Sep 2018 14:59:46 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> > >
> > > Hi Boris, Vitor,
> > >
> > > This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=CMnAfM_OfpqcWZRfiqcRWw&m=OPSa25ENnrF0Qv70DG49ZngfdygJZubjo3TOgBA3pJ4&s=_C6i1KPplQGcWvQYPkrGx7V3TjKDJvqt3KG-vcdU2K4&e=
> > >
> > > Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > > It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> > >
> > > I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >
> >
> > Can you explain the reason for having a user space interface and DT property?
> > I thought we had concluded earlier that we wouldn't need that, but it's possible
> > that I missed something in the discussion since then.
>
> I don't think the sysfs knob is needed, this being said, after thinking
> a bit more about mastership handover and the secondary master case, I
> think we have something important to solve.
>
> When a master is not in control of the bus, it gets informed of devices
> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> means the secondary master should populate the bus with I3C/I2C devices
> on such events, but that's not enough, because DEFSLVS/DAA do not
> provide all device info. Some of them (like read/write/ibi limitations)
> require extra CCC commands, and, to send those CCC commands, the
> secondary master must claim the bus. We could add a case where we
> declare devices as partially discovered until the master acquires
> ownership of the bus, but that means part of the data returned by
> i3c_device_get_info() will be inaccurate, which might have an impact on
> some i3c driver ->probe() functions.
>
> How do you want to handle cases when secondary master joins the bus after
> DEFSLVS? Of course we can send DEFSLVS after secondary master joins the bus.
That's already the case ;-). Every time the current master discovers
another master, it's sends a DEFSLVS at the end of the DAA procedure.
>
> We could also say that partially discovered devices should not be
> registered to the device model, but we then hit the problem of "who can
> force the secondary master to claim the bus if there's no users?".
>
> Now I feel like I missed something. Do you want to populate second instance
> of the same physical bus? If yes, then we don't need to have reference
> between masters in DT.
This is the discussion we've had about 1 month ago with Arnd, Wolfram
and Peter, and the conclusion was that 2 different masters connected to
the same physical bus should expose 2 different buses (which means
having the same physical devices exposed 2 times in Linux).
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 13:50 ` vitor
@ 2018-09-06 14:14 ` Boris Brezillon
2018-09-06 15:17 ` vitor
0 siblings, 1 reply; 71+ messages in thread
From: Boris Brezillon @ 2018-09-06 14:14 UTC (permalink / raw)
To: vitor
Cc: Arnd Bergmann, Przemyslaw Gaj, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, 6 Sep 2018 14:50:03 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi,
>
>
> On 06-09-2018 14:20, Boris Brezillon wrote:
> > On Thu, 6 Sep 2018 15:14:37 +0200
> > Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >
> >> On Thu, 6 Sep 2018 14:59:46 +0200
> >> Arnd Bergmann <arnd@arndb.de> wrote:
> >>
> >>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >>>> Hi Boris, Vitor,
> >>>>
> >>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
> >>>>
> >>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> >>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >>>>
> >>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >>>
> >>> Can you explain the reason for having a user space interface and DT property?
> >>> I thought we had concluded earlier that we wouldn't need that, but it's possible
> >>> that I missed something in the discussion since then.
> >> I don't think the sysfs knob is needed, this being said, after thinking
> >> a bit more about mastership handover and the secondary master case, I
> >> think we have something important to solve.
> >>
> >> When a master is not in control of the bus, it gets informed of devices
> >> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> >> means the secondary master should populate the bus with I3C/I2C devices
> >> on such events, but that's not enough, because DEFSLVS/DAA do not
> >> provide all device info.Some of them (like read/write/ibi limitations)
> >> require extra CCC commands, and, to send those CCC commands, the
> >> secondary master must claim the bus. We could add a case where we
> >> declare devices as partially discovered until the master acquires
> >> ownership of the bus, but that means part of the data returned by
> >> i3c_device_get_info() will be inaccurate, which might have an impact on
> >> some i3c driver ->probe() functions.
> > Hm, one possible solution would be to register partially discovered
> > devices to the device model and let i3c_device_get_info() claim the bus
> > and request missing data when needed. This way, if the driver needs to
> > call i3c_device_get_info() in its probe path, it should work just fine.
>
> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
> attach and retrieve the device info.
When will you call i3c_master_add_i3c_dev_locked()? After receiving a
DEFSLVS interrupt/event? When that happens you're not in control of the
bus, which means you'll have to force bus ownership handover. Is this
really what we want?
These are not rhetorical questions, I'm really asking for your opinion
here.
> This can be triggered after the secondary master receive ENEC MR until
> them is keep in the driver memory.
But that means no-one will actually trigger a mastership request,
because devices won't be registered until all info are available. If we
take this path, we should have a way to explicitly trigger a mastership
request (sysfs knob or any other means).
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 14:09 ` Boris Brezillon
@ 2018-09-06 14:20 ` Przemyslaw Gaj
0 siblings, 0 replies; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-06 14:20 UTC (permalink / raw)
To: Boris Brezillon
Cc: Arnd Bergmann, Vitor Soares, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On 9/6/18, 4:10 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
On Thu, 6 Sep 2018 13:47:29 +0000
Przemyslaw Gaj <pgaj@cadence.com> wrote:
> On 9/6/18, 3:14 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> On Thu, 6 Sep 2018 14:59:46 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
> > On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> > >
> > > Hi Boris, Vitor,
> > >
> > > This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-_haXqY&r=CMnAfM_OfpqcWZRfiqcRWw&m=OPSa25ENnrF0Qv70DG49ZngfdygJZubjo3TOgBA3pJ4&s=_C6i1KPplQGcWvQYPkrGx7V3TjKDJvqt3KG-vcdU2K4&e=
> > >
> > > Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > > It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> > >
> > > I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >
> >
> > Can you explain the reason for having a user space interface and DT property?
> > I thought we had concluded earlier that we wouldn't need that, but it's possible
> > that I missed something in the discussion since then.
>
> I don't think the sysfs knob is needed, this being said, after thinking
> a bit more about mastership handover and the secondary master case, I
> think we have something important to solve.
>
> When a master is not in control of the bus, it gets informed of devices
> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> means the secondary master should populate the bus with I3C/I2C devices
> on such events, but that's not enough, because DEFSLVS/DAA do not
> provide all device info. Some of them (like read/write/ibi limitations)
> require extra CCC commands, and, to send those CCC commands, the
> secondary master must claim the bus. We could add a case where we
> declare devices as partially discovered until the master acquires
> ownership of the bus, but that means part of the data returned by
> i3c_device_get_info() will be inaccurate, which might have an impact on
> some i3c driver ->probe() functions.
>
> How do you want to handle cases when secondary master joins the bus after
> DEFSLVS? Of course we can send DEFSLVS after secondary master joins the bus.
That's already the case ;-). Every time the current master discovers
another master, it's sends a DEFSLVS at the end of the DAA procedure.
>
> We could also say that partially discovered devices should not be
> registered to the device model, but we then hit the problem of "who can
> force the secondary master to claim the bus if there's no users?".
>
> Now I feel like I missed something. Do you want to populate second instance
> of the same physical bus? If yes, then we don't need to have reference
> between masters in DT.
This is the discussion we've had about 1 month ago with Arnd, Wolfram
and Peter, and the conclusion was that 2 different masters connected to
the same physical bus should expose 2 different buses (which means
having the same physical devices exposed 2 times in Linux).
Ok, I implemented it after our discussion, I think it was in May. I even had
version where every master had own bus.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 14:14 ` Boris Brezillon
@ 2018-09-06 15:17 ` vitor
2018-09-06 16:06 ` Boris Brezillon
0 siblings, 1 reply; 71+ messages in thread
From: vitor @ 2018-09-06 15:17 UTC (permalink / raw)
To: Boris Brezillon, vitor
Cc: Arnd Bergmann, Przemyslaw Gaj, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
Hi Boris,
On 06-09-2018 15:14, Boris Brezillon wrote:
> On Thu, 6 Sep 2018 14:50:03 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
>> Hi,
>>
>>
>> On 06-09-2018 14:20, Boris Brezillon wrote:
>>> On Thu, 6 Sep 2018 15:14:37 +0200
>>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
>>>
>>>> On Thu, 6 Sep 2018 14:59:46 +0200
>>>> Arnd Bergmann <arnd@arndb.de> wrote:
>>>>
>>>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
>>>>>> Hi Boris, Vitor,
>>>>>>
>>>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
>>>>>>
>>>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
>>>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
>>>>>>
>>>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
>>>>> Can you explain the reason for having a user space interface and DT property?
>>>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
>>>>> that I missed something in the discussion since then.
>>>> I don't think the sysfs knob is needed, this being said, after thinking
>>>> a bit more about mastership handover and the secondary master case, I
>>>> think we have something important to solve.
>>>>
>>>> When a master is not in control of the bus, it gets informed of devices
>>>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
>>>> means the secondary master should populate the bus with I3C/I2C devices
>>>> on such events, but that's not enough, because DEFSLVS/DAA do not
>>>> provide all device info.Some of them (like read/write/ibi limitations)
>>>> require extra CCC commands, and, to send those CCC commands, the
>>>> secondary master must claim the bus. We could add a case where we
>>>> declare devices as partially discovered until the master acquires
>>>> ownership of the bus, but that means part of the data returned by
>>>> i3c_device_get_info() will be inaccurate, which might have an impact on
>>>> some i3c driver ->probe() functions.
>>> Hm, one possible solution would be to register partially discovered
>>> devices to the device model and let i3c_device_get_info() claim the bus
>>> and request missing data when needed. This way, if the driver needs to
>>> call i3c_device_get_info() in its probe path, it should work just fine.
>> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
>> attach and retrieve the device info.
> When will you call i3c_master_add_i3c_dev_locked()? After receiving a
> DEFSLVS interrupt/event? When that happens you're not in control of the
> bus, which means you'll have to force bus ownership handover. Is this
> really what we want?
>
> These are not rhetorical questions, I'm really asking for your opinion
> here.
What I understand from last discussion was that every time that device
need to do something (private messages) on the bus and don't have the
bus control it should force ownership handover.
If my understanding is correct this can be also applied to CCC commands.
>
>> This can be triggered after the secondary master receive ENEC MR until
>> them is keep in the driver memory.
> But that means no-one will actually trigger a mastership request,
> because devices won't be registered until all info are available. If we
> take this path, we should have a way to explicitly trigger a mastership
> request (sysfs knob or any other means).
By the current flow that we have now, we enable the IBI events at the
end of .do_daa. At this time the main master bus is initialized with all
devices.
From the point of view of secondary master, it first participate on DAA
process, next it send its info (Main master do
i3c_master_retrieve_dev_info()) and them receive DEFSLVS. In the stage
it cannot request the bus mastership it need the MR enable.
So, what I would suggest is to keep DEFSLVS data in secondary master
driver memory . When secondary master receive the MR enable, it can get
the bus ownership and do i3c_master_add_i3c_dev_locked() and each device
in DEFSLVS command. After this step delegate the bus ownership to the
main master.
What do you think about this?
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 15:17 ` vitor
@ 2018-09-06 16:06 ` Boris Brezillon
2018-09-06 16:17 ` Przemyslaw Gaj
2018-09-07 7:51 ` Przemyslaw Gaj
0 siblings, 2 replies; 71+ messages in thread
From: Boris Brezillon @ 2018-09-06 16:06 UTC (permalink / raw)
To: vitor
Cc: Arnd Bergmann, Przemyslaw Gaj, open list:GPIO SUBSYSTEM,
Sekhar Nori, Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On Thu, 6 Sep 2018 16:17:58 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
>
> On 06-09-2018 15:14, Boris Brezillon wrote:
> > On Thu, 6 Sep 2018 14:50:03 +0100
> > vitor <Vitor.Soares@synopsys.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On 06-09-2018 14:20, Boris Brezillon wrote:
> >>> On Thu, 6 Sep 2018 15:14:37 +0200
> >>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >>>
> >>>> On Thu, 6 Sep 2018 14:59:46 +0200
> >>>> Arnd Bergmann <arnd@arndb.de> wrote:
> >>>>
> >>>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >>>>>> Hi Boris, Vitor,
> >>>>>>
> >>>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
> >>>>>>
> >>>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> >>>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >>>>>>
> >>>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >>>>> Can you explain the reason for having a user space interface and DT property?
> >>>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
> >>>>> that I missed something in the discussion since then.
> >>>> I don't think the sysfs knob is needed, this being said, after thinking
> >>>> a bit more about mastership handover and the secondary master case, I
> >>>> think we have something important to solve.
> >>>>
> >>>> When a master is not in control of the bus, it gets informed of devices
> >>>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> >>>> means the secondary master should populate the bus with I3C/I2C devices
> >>>> on such events, but that's not enough, because DEFSLVS/DAA do not
> >>>> provide all device info.Some of them (like read/write/ibi limitations)
> >>>> require extra CCC commands, and, to send those CCC commands, the
> >>>> secondary master must claim the bus. We could add a case where we
> >>>> declare devices as partially discovered until the master acquires
> >>>> ownership of the bus, but that means part of the data returned by
> >>>> i3c_device_get_info() will be inaccurate, which might have an impact on
> >>>> some i3c driver ->probe() functions.
> >>> Hm, one possible solution would be to register partially discovered
> >>> devices to the device model and let i3c_device_get_info() claim the bus
> >>> and request missing data when needed. This way, if the driver needs to
> >>> call i3c_device_get_info() in its probe path, it should work just fine.
> >> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
> >> attach and retrieve the device info.
> > When will you call i3c_master_add_i3c_dev_locked()? After receiving a
> > DEFSLVS interrupt/event? When that happens you're not in control of the
> > bus, which means you'll have to force bus ownership handover. Is this
> > really what we want?
> >
> > These are not rhetorical questions, I'm really asking for your opinion
> > here.
> What I understand from last discussion was that every time that device
> need to do something (private messages) on the bus and don't have the
> bus control it should force ownership handover.
> If my understanding is correct this can be also applied to CCC commands.
Sure, but the question is more, when do we want to do that?
>
> >
> >> This can be triggered after the secondary master receive ENEC MR until
> >> them is keep in the driver memory.
> > But that means no-one will actually trigger a mastership request,
> > because devices won't be registered until all info are available. If we
> > take this path, we should have a way to explicitly trigger a mastership
> > request (sysfs knob or any other means).
> By the current flow that we have now, we enable the IBI events at the
> end of .do_daa. At this time the main master bus is initialized with all
> devices.
>
> From the point of view of secondary master, it first participate on DAA
> process, next it send its info (Main master do
> i3c_master_retrieve_dev_info()) and them receive DEFSLVS. In the stage
> it cannot request the bus mastership it need the MR enable.
You mean the broadcast ENEC(MR) event, right? Then yes, this one is
probably missing (or maybe I added it in the master controller driver,
I don't remember).
>
> So, what I would suggest is to keep DEFSLVS data in secondary master
> driver memory . When secondary master receive the MR enable, it can get
> the bus ownership and do i3c_master_add_i3c_dev_locked() and each device
> in DEFSLVS command. After this step delegate the bus ownership to the
> main master.
That's an option, indeed.
>
> What do you think about this?
Sounds like a good start. If MR is rejected by the master, we will just
keep all devices in an unregistered state. We can also add a sysfs
entry to manually re-trigger this operation in case the initial one
failed.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 16:06 ` Boris Brezillon
@ 2018-09-06 16:17 ` Przemyslaw Gaj
2018-09-10 16:16 ` vitor
2018-09-07 7:51 ` Przemyslaw Gaj
1 sibling, 1 reply; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-06 16:17 UTC (permalink / raw)
To: Boris Brezillon, vitor
Cc: Arnd Bergmann, open list:GPIO SUBSYSTEM, Sekhar Nori,
Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
On 9/6/18, 6:07 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
On Thu, 6 Sep 2018 16:17:58 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
>
> On 06-09-2018 15:14, Boris Brezillon wrote:
> > On Thu, 6 Sep 2018 14:50:03 +0100
> > vitor <Vitor.Soares@synopsys.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On 06-09-2018 14:20, Boris Brezillon wrote:
> >>> On Thu, 6 Sep 2018 15:14:37 +0200
> >>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >>>
> >>>> On Thu, 6 Sep 2018 14:59:46 +0200
> >>>> Arnd Bergmann <arnd@arndb.de> wrote:
> >>>>
> >>>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >>>>>> Hi Boris, Vitor,
> >>>>>>
> >>>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
> >>>>>>
> >>>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> >>>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >>>>>>
> >>>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >>>>> Can you explain the reason for having a user space interface and DT property?
> >>>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
> >>>>> that I missed something in the discussion since then.
> >>>> I don't think the sysfs knob is needed, this being said, after thinking
> >>>> a bit more about mastership handover and the secondary master case, I
> >>>> think we have something important to solve.
> >>>>
> >>>> When a master is not in control of the bus, it gets informed of devices
> >>>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> >>>> means the secondary master should populate the bus with I3C/I2C devices
> >>>> on such events, but that's not enough, because DEFSLVS/DAA do not
> >>>> provide all device info.Some of them (like read/write/ibi limitations)
> >>>> require extra CCC commands, and, to send those CCC commands, the
> >>>> secondary master must claim the bus. We could add a case where we
> >>>> declare devices as partially discovered until the master acquires
> >>>> ownership of the bus, but that means part of the data returned by
> >>>> i3c_device_get_info() will be inaccurate, which might have an impact on
> >>>> some i3c driver ->probe() functions.
> >>> Hm, one possible solution would be to register partially discovered
> >>> devices to the device model and let i3c_device_get_info() claim the bus
> >>> and request missing data when needed. This way, if the driver needs to
> >>> call i3c_device_get_info() in its probe path, it should work just fine.
> >> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
> >> attach and retrieve the device info.
> > When will you call i3c_master_add_i3c_dev_locked()? After receiving a
> > DEFSLVS interrupt/event? When that happens you're not in control of the
> > bus, which means you'll have to force bus ownership handover. Is this
> > really what we want?
> >
> > These are not rhetorical questions, I'm really asking for your opinion
> > here.
> What I understand from last discussion was that every time that device
> need to do something (private messages) on the bus and don't have the
> bus control it should force ownership handover.
> If my understanding is correct this can be also applied to CCC commands.
Sure, but the question is more, when do we want to do that?
>
> >
> >> This can be triggered after the secondary master receive ENEC MR until
> >> them is keep in the driver memory.
> > But that means no-one will actually trigger a mastership request,
> > because devices won't be registered until all info are available. If we
> > take this path, we should have a way to explicitly trigger a mastership
> > request (sysfs knob or any other means).
> By the current flow that we have now, we enable the IBI events at the
> end of .do_daa. At this time the main master bus is initialized with all
> devices.
>
> From the point of view of secondary master, it first participate on DAA
> process, next it send its info (Main master do
> i3c_master_retrieve_dev_info()) and them receive DEFSLVS. In the stage
> it cannot request the bus mastership it need the MR enable.
You mean the broadcast ENEC(MR) event, right? Then yes, this one is
probably missing (or maybe I added it in the master controller driver,
I don't remember).
>
> So, what I would suggest is to keep DEFSLVS data in secondary master
> driver memory . When secondary master receive the MR enable, it can get
> the bus ownership and do i3c_master_add_i3c_dev_locked() and each device
> in DEFSLVS command. After this step delegate the bus ownership to the
> main master.
That's an option, indeed.
>
> What do you think about this?
Sounds like a good start. If MR is rejected by the master, we will just
keep all devices in an unregistered state. We can also add a sysfs
entry to manually re-trigger this operation in case the initial one
failed.
This everything sounds like my previous version. Enec event was missing,
everything was triggered manually from sysfs.
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 16:06 ` Boris Brezillon
2018-09-06 16:17 ` Przemyslaw Gaj
@ 2018-09-07 7:51 ` Przemyslaw Gaj
1 sibling, 0 replies; 71+ messages in thread
From: Przemyslaw Gaj @ 2018-09-07 7:51 UTC (permalink / raw)
To: Boris Brezillon, vitor
Cc: Arnd Bergmann, open list:GPIO SUBSYSTEM, Sekhar Nori,
Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
Hi Boris, Vitor,
On 9/6/18, 6:07 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
EXTERNAL MAIL
On Thu, 6 Sep 2018 16:17:58 +0100
vitor <Vitor.Soares@synopsys.com> wrote:
> Hi Boris,
>
>
> On 06-09-2018 15:14, Boris Brezillon wrote:
> > On Thu, 6 Sep 2018 14:50:03 +0100
> > vitor <Vitor.Soares@synopsys.com> wrote:
> >
> >> Hi,
> >>
> >>
> >> On 06-09-2018 14:20, Boris Brezillon wrote:
> >>> On Thu, 6 Sep 2018 15:14:37 +0200
> >>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >>>
> >>>> On Thu, 6 Sep 2018 14:59:46 +0200
> >>>> Arnd Bergmann <arnd@arndb.de> wrote:
> >>>>
> >>>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> >>>>>> Hi Boris, Vitor,
> >>>>>>
> >>>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
> >>>>>>
> >>>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> >>>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> >>>>>>
> >>>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> >>>>> Can you explain the reason for having a user space interface and DT property?
> >>>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
> >>>>> that I missed something in the discussion since then.
> >>>> I don't think the sysfs knob is needed, this being said, after thinking
> >>>> a bit more about mastership handover and the secondary master case, I
> >>>> think we have something important to solve.
> >>>>
> >>>> When a master is not in control of the bus, it gets informed of devices
> >>>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> >>>> means the secondary master should populate the bus with I3C/I2C devices
> >>>> on such events, but that's not enough, because DEFSLVS/DAA do not
> >>>> provide all device info.Some of them (like read/write/ibi limitations)
> >>>> require extra CCC commands, and, to send those CCC commands, the
> >>>> secondary master must claim the bus. We could add a case where we
> >>>> declare devices as partially discovered until the master acquires
> >>>> ownership of the bus, but that means part of the data returned by
> >>>> i3c_device_get_info() will be inaccurate, which might have an impact on
> >>>> some i3c driver ->probe() functions.
> >>> Hm, one possible solution would be to register partially discovered
> >>> devices to the device model and let i3c_device_get_info() claim the bus
> >>> and request missing data when needed. This way, if the driver needs to
> >>> call i3c_device_get_info() in its probe path, it should work just fine.
> >> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
> >> attach and retrieve the device info.
> > When will you call i3c_master_add_i3c_dev_locked()? After receiving a
> > DEFSLVS interrupt/event? When that happens you're not in control of the
> > bus, which means you'll have to force bus ownership handover. Is this
> > really what we want?
> >
> > These are not rhetorical questions, I'm really asking for your opinion
> > here.
> What I understand from last discussion was that every time that device
> need to do something (private messages) on the bus and don't have the
> bus control it should force ownership handover.
> If my understanding is correct this can be also applied to CCC commands.
Sure, but the question is more, when do we want to do that?
>
> >
> >> This can be triggered after the secondary master receive ENEC MR until
> >> them is keep in the driver memory.
> > But that means no-one will actually trigger a mastership request,
> > because devices won't be registered until all info are available. If we
> > take this path, we should have a way to explicitly trigger a mastership
> > request (sysfs knob or any other means).
> By the current flow that we have now, we enable the IBI events at the
> end of .do_daa. At this time the main master bus is initialized with all
> devices.
>
> From the point of view of secondary master, it first participate on DAA
> process, next it send its info (Main master do
> i3c_master_retrieve_dev_info()) and them receive DEFSLVS. In the stage
> it cannot request the bus mastership it need the MR enable.
You mean the broadcast ENEC(MR) event, right? Then yes, this one is
probably missing (or maybe I added it in the master controller driver,
I don't remember).
>
> So, what I would suggest is to keep DEFSLVS data in secondary master
> driver memory . When secondary master receive the MR enable, it can get
> the bus ownership and do i3c_master_add_i3c_dev_locked() and each device
> in DEFSLVS command. After this step delegate the bus ownership to the
> main master.
That's an option, indeed.
>
> What do you think about this?
Sounds like a good start. If MR is rejected by the master, we will just
keep all devices in an unregistered state. We can also add a sysfs
entry to manually re-trigger this operation in case the initial one
failed.
I found that version. I added also mastership request after ENEC(MR) event to run
tests and verify if everything works correctly. It looked quite simple. Secondary master
does not give control back automatically after bus initialization and master doesn't
yet request mastership when device driver wants to use the bus / transfer data.
This can be the base for further works.
https://github.com/przemekgaj/i3c-linux/tree/mastership_takeover
Regards,
Przemek
^ permalink raw reply [flat|nested] 71+ messages in thread
* Re: [PATCH v6 01/10] i3c: Add core I3C infrastructure
2018-09-06 16:17 ` Przemyslaw Gaj
@ 2018-09-10 16:16 ` vitor
0 siblings, 0 replies; 71+ messages in thread
From: vitor @ 2018-09-10 16:16 UTC (permalink / raw)
To: Przemyslaw Gaj, Boris Brezillon, vitor
Cc: Arnd Bergmann, open list:GPIO SUBSYSTEM, Sekhar Nori,
Wolfram Sang, Linux I2C, Jonathan Corbet,
open list:DOCUMENTATION, gregkh, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Rafal Ciepiela, Thomas Petazzoni, Nishanth Menon, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, DTML,
Linux Kernel Mailing List, Geert Uytterhoeven, Linus Walleij,
Xiang Lin, Peter Rosin
Hi,
On 06-09-2018 17:17, Przemyslaw Gaj wrote:
>
> On 9/6/18, 6:07 PM, "Boris Brezillon" <boris.brezillon@bootlin.com> wrote:
>
> EXTERNAL MAIL
>
>
> On Thu, 6 Sep 2018 16:17:58 +0100
> vitor <Vitor.Soares@synopsys.com> wrote:
>
> > Hi Boris,
> >
> >
> > On 06-09-2018 15:14, Boris Brezillon wrote:
> > > On Thu, 6 Sep 2018 14:50:03 +0100
> > > vitor <Vitor.Soares@synopsys.com> wrote:
> > >
> > >> Hi,
> > >>
> > >>
> > >> On 06-09-2018 14:20, Boris Brezillon wrote:
> > >>> On Thu, 6 Sep 2018 15:14:37 +0200
> > >>> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> > >>>
> > >>>> On Thu, 6 Sep 2018 14:59:46 +0200
> > >>>> Arnd Bergmann <arnd@arndb.de> wrote:
> > >>>>
> > >>>>> On Thu, Sep 6, 2018 at 2:43 PM Przemyslaw Gaj <pgaj@cadence.com> wrote:
> > >>>>>> Hi Boris, Vitor,
> > >>>>>>
> > >>>>>> This repository does not contain full kernel sources, but it should be enough to discuss mastership request feature.
> > >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_przemekgaj_i3c-2Dlinux_commit_d54fe68a9d3e573c0c454a2c6f1afafc20142ec5&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=qVuU64u9x77Y0Kd0PhDK_lpxFgg6PK9PateHwjb_DY0&m=Q9DWw3KGmshGw0f5QTiffbpbESyUlPx6KmASuDBtX9Y&s=HHE_y1kyMszJvP_tSP9JkDlPYxDywBeHwkMGgCR11uI&e=
> > >>>>>>
> > >>>>>> Please keep in mind that this is initial version, but mastership works correctly. I added one property to DT to reflect relationship between masters.
> > >>>>>> It is possible to request mastership on demand (using sysfs. Useful in case when Linux machine is equipped only with secondary master controller) or automatically change operation mode when device driver wants to read/write something from/to device.
> > >>>>>>
> > >>>>>> I'm sure I will have to rework something because this was implemented on sources from PATCH v4. I saw that Boris released v7 yesterday :)
> > >>>>> Can you explain the reason for having a user space interface and DT property?
> > >>>>> I thought we had concluded earlier that we wouldn't need that, but it's possible
> > >>>>> that I missed something in the discussion since then.
> > >>>> I don't think the sysfs knob is needed, this being said, after thinking
> > >>>> a bit more about mastership handover and the secondary master case, I
> > >>>> think we have something important to solve.
> > >>>>
> > >>>> When a master is not in control of the bus, it gets informed of devices
> > >>>> present on the bus by monitoring DAA or DEFSLVS broadcast events. That
> > >>>> means the secondary master should populate the bus with I3C/I2C devices
> > >>>> on such events, but that's not enough, because DEFSLVS/DAA do not
> > >>>> provide all device info.Some of them (like read/write/ibi limitations)
> > >>>> require extra CCC commands, and, to send those CCC commands, the
> > >>>> secondary master must claim the bus. We could add a case where we
> > >>>> declare devices as partially discovered until the master acquires
> > >>>> ownership of the bus, but that means part of the data returned by
> > >>>> i3c_device_get_info() will be inaccurate, which might have an impact on
> > >>>> some i3c driver ->probe() functions.
> > >>> Hm, one possible solution would be to register partially discovered
> > >>> devices to the device model and let i3c_device_get_info() claim the bus
> > >>> and request missing data when needed. This way, if the driver needs to
> > >>> call i3c_device_get_info() in its probe path, it should work just fine.
> > >> Why don't use the i3c_master_add_i3c_dev_locked that job? It create,
> > >> attach and retrieve the device info.
> > > When will you call i3c_master_add_i3c_dev_locked()? After receiving a
> > > DEFSLVS interrupt/event? When that happens you're not in control of the
> > > bus, which means you'll have to force bus ownership handover. Is this
> > > really what we want?
> > >
> > > These are not rhetorical questions, I'm really asking for your opinion
> > > here.
> > What I understand from last discussion was that every time that device
> > need to do something (private messages) on the bus and don't have the
> > bus control it should force ownership handover.
> > If my understanding is correct this can be also applied to CCC commands.
>
> Sure, but the question is more, when do we want to do that?
>
> >
> > >
> > >> This can be triggered after the secondary master receive ENEC MR until
> > >> them is keep in the driver memory.
> > > But that means no-one will actually trigger a mastership request,
> > > because devices won't be registered until all info are available. If we
> > > take this path, we should have a way to explicitly trigger a mastership
> > > request (sysfs knob or any other means).
> > By the current flow that we have now, we enable the IBI events at the
> > end of .do_daa. At this time the main master bus is initialized with all
> > devices.
> >
> > From the point of view of secondary master, it first participate on DAA
> > process, next it send its info (Main master do
> > i3c_master_retrieve_dev_info()) and them receive DEFSLVS. In the stage
> > it cannot request the bus mastership it need the MR enable.
>
> You mean the broadcast ENEC(MR) event, right? Then yes, this one is
> probably missing (or maybe I added it in the master controller driver,
> I don't remember).
>
> >
> > So, what I would suggest is to keep DEFSLVS data in secondary master
> > driver memory . When secondary master receive the MR enable, it can get
> > the bus ownership and do i3c_master_add_i3c_dev_locked() and each device
> > in DEFSLVS command. After this step delegate the bus ownership to the
> > main master.
>
> That's an option, indeed.
>
> >
> > What do you think about this?
>
> Sounds like a good start. If MR is rejected by the master, we will just
> keep all devices in an unregistered state. We can also add a sysfs
> entry to manually re-trigger this operation in case the initial one
> failed.
>
> This everything sounds like my previous version. Enec event was missing,
> everything was triggered manually from sysfs.
>
Does make sense to do the ->bus_init() only after receive the first
ENEC-MR event? The bus initialization assume that we already know the
I2C devices present on the line (bus->mode) and i3c_master_set_info only
have meaning if the device will act as a master otherwise it can act as
"slave".
Best regards,
Vitor Soares
^ permalink raw reply [flat|nested] 71+ messages in thread
end of thread, other threads:[~2018-09-10 16:17 UTC | newest]
Thread overview: 71+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-19 15:29 [PATCH v6 00/10] Add the I3C subsystem Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 01/10] i3c: Add core I3C infrastructure Boris Brezillon
2018-08-03 21:38 ` mshettel
2018-08-04 5:33 ` Boris Brezillon
2018-08-22 16:43 ` vitor
2018-08-24 12:39 ` Boris Brezillon
2018-08-24 17:52 ` vitor
2018-08-24 18:16 ` Boris Brezillon
2018-08-28 11:50 ` vitor
2018-08-28 12:02 ` Boris Brezillon
2018-08-28 12:55 ` Przemyslaw Gaj
2018-08-28 13:01 ` Boris Brezillon
2018-08-29 7:41 ` Przemyslaw Gaj
2018-08-28 13:03 ` Boris Brezillon
2018-08-30 13:57 ` vitor
2018-08-30 19:00 ` Przemyslaw Gaj
2018-09-03 9:33 ` vitor
2018-09-04 11:03 ` Przemyslaw Gaj
2018-09-06 12:43 ` Przemyslaw Gaj
2018-09-06 12:59 ` Arnd Bergmann
2018-09-06 13:14 ` Boris Brezillon
2018-09-06 13:20 ` Boris Brezillon
2018-09-06 13:45 ` Arnd Bergmann
2018-09-06 13:50 ` vitor
2018-09-06 14:14 ` Boris Brezillon
2018-09-06 15:17 ` vitor
2018-09-06 16:06 ` Boris Brezillon
2018-09-06 16:17 ` Przemyslaw Gaj
2018-09-10 16:16 ` vitor
2018-09-07 7:51 ` Przemyslaw Gaj
2018-09-06 13:47 ` Przemyslaw Gaj
2018-09-06 14:09 ` Boris Brezillon
2018-09-06 14:20 ` Przemyslaw Gaj
2018-07-19 15:29 ` [PATCH v6 02/10] docs: driver-api: Add I3C documentation Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 03/10] i3c: Add sysfs ABI spec Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 04/10] dt-bindings: i3c: Document core bindings Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 05/10] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 06/10] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 07/10] i3c: master: Add driver for Cadence IP Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 08/10] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 09/10] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
2018-07-19 15:29 ` [PATCH v6 10/10] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
2018-07-20 8:52 ` [PATCH v6 00/10] Add the I3C subsystem Arnd Bergmann
2018-07-20 9:57 ` Peter Rosin
2018-07-20 10:05 ` Boris Brezillon
2018-07-20 10:39 ` Peter Rosin
2018-07-20 10:12 ` Wolfram Sang
2018-07-20 10:57 ` Arnd Bergmann
2018-07-20 11:05 ` Wolfram Sang
2018-07-20 11:13 ` Peter Rosin
2018-07-20 11:28 ` Arnd Bergmann
2018-07-20 13:16 ` Peter Rosin
2018-07-20 15:41 ` Wolfram Sang
2018-07-24 14:14 ` Arnd Bergmann
2018-07-24 15:57 ` Wolfram Sang
2018-07-24 16:04 ` Arnd Bergmann
2018-07-24 20:22 ` Wolfram Sang
2018-07-24 16:07 ` Boris Brezillon
2018-07-20 13:17 ` Boris Brezillon
2018-07-24 14:03 ` Arnd Bergmann
2018-07-24 14:28 ` Boris Brezillon
2018-07-24 15:05 ` Arnd Bergmann
2018-07-24 15:15 ` Geert Uytterhoeven
2018-07-24 15:40 ` Arnd Bergmann
2018-07-24 15:46 ` Geert Uytterhoeven
2018-07-24 15:58 ` Arnd Bergmann
2018-07-24 16:14 ` Boris Brezillon
2018-07-24 16:25 ` Arnd Bergmann
2018-07-24 16:54 ` Boris Brezillon
2018-07-24 20:21 ` Arnd Bergmann
2018-07-24 16:04 ` Wolfram Sang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).