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 its
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.
Im 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. Id say that, from a
representation PoV its 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 dont see a better solution if we want something
that is not invasive.
- the whole API is exposed through a single header file (i3c.h), but Im
seriously considering the option of splitting the I3C driver/user API
and the I3C master one, mainly to hide I3C core internals and restrict
what I3C users can do to a limited set of functionalities (send
I3C/I2C frames to a specific device and thats all).
Missing features in this preliminary version:
- no support for IBI (In Band Interrupts). This is something Im working
on, and Im still unsure how to represent it: an irqchip or a
completely independent representation that would be I3C specific.
Right now, Im more inclined to go for the irqchip approach, since
this is something people are used to deal with already.
- no Hot Join support, which is similar to hotplug
- no support for multi-master and the associated concepts (mastership
handover, support for secondary masters, ...)
- I2C devices can only be described using DT because this is the only
use case I have. However, the framework can easily be extended with
ACPI and board info support
- I3C slave framework. This has been completely omitted, but shouldnt
have a huge impact on the I3C framework because I3C slaves dont see
the whole bus, its 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
MTK-Commit-Id: f48b091ac9cd273278b3980263dd5a229bec0173
Change-Id: I42b39f7bc54e2cedfc03a9d43068175b91256d3b
Signed-off-by: qiangming.xia <qiangming.xia@mediatek.com>
CR-Id: ALPS04938819
Feature: Sensor Hub
07b8620899