Hello,
DRM natively supports pipelines whose display can be removed, but all the
components preceding it (all the display controller and any bridges) are
assumed to be fixed and cannot be plugged, removed or modified at runtime.
This series adds support for DRM pipelines having a removable part after
the encoder, thus also allowing bridges to be removed and reconnected at
runtime, possibly with different components.
In the overall ongoing work, this is going to be handled via device tree
overlay insertion and removal. For many kernel driver frameworks, adding
and removing devices via device tree overlays works already (albeit with
some issues related to overlays in general), but this does not happen for
DRM, so this serias aims at filling this gap.
This series only covers the DRM aspects and not the overlay ones. See
"Development roadmap" below for more details.
Use case
--------
The use case we are working on is to support professional products that
have a portable "main" part running on battery, with the main SoC and able
to work autonomously with limited features, and that can be connected to an
"add-on" part that is not portable and adds more features.
The add-on can be connected and disconnected at runtime at any moment by
the end user, and add-on features need to be enabled and disabled
automatically at runtime. The features provided by the add-on include a
display and a battery charger to recharge the battery of the main part. The
display on the add-on has an LVDS input but the connector between the base
and the add-on has a MIPI DSI bus, so a DSI-to-LVDS bridge is present on
the add-on.
Targeted abstraction level
--------------------------
This series aims at supporting both the use case described above and any
similar use cases, e.g. using different video busses, up to a given level
of generalization.
This picture summarizes the DRM aspects of such devices:
.------------------------.
| DISPLAY CONTROLLER |
| .---------. .------. |
| | ENCODER |<--| CRTC | |
| '---------' '------' |
'------|-----------------'
|
|DSI HOTPLUG
V CONNECTOR
.---------. .--. .-. .---------. .-------.
| 0 to N | | _| _| | | 1 to N | | |
| BRIDGES |--DSI-->||_ |_ |--DSI-->| BRIDGES |--LVDS-->| PANEL |
| | | | | | | | | |
'---------' '--' '-' '---------' '-------'
[--- fixed components --] [----------- removable add-on -----------]
Fixed components include:
* all components up to the DRM encoder, usually part of the SoC
* optionally some bridges, in the SoC and/or as external chips
Components on the removable add-on include:
* one or more bridges
* a fixed connector (not one natively supporting hotplug such as HDMI)
* the panel
Overall this looks like a fairly standard embedded device, except for the
hot-pluggable connector allowing to remove a bridge and all the following
components at runtime and without prior notice for the kernel.
The video bus is MIPI DSI in the example and in the implementation provided
by this series, but the implementation is meant to allow can be
generalizedwgeneralization to other video busses without native hotplug
support, such as parallel video and LVDS.
The "hotplug connector" in picture is the mechanical connector that can be
physically removed at runtime. All the video bus signals (DSI in the
example) get connected or disconnected via that connector.
Note that the term "connector" in this context has nothing to do with the
"DRM connector" abstraction already present in the DRM subsystem (struct
drm_connector). The existing "DRM connector" has been designed to support
hotplug on a bus that physically supports both hotplug _and_ monitor
identification (e.g. HDMI), and later also used to model the connection to
a non-removable panel that is commonly found on embedded systems and
supports neither hotplug nor panel identification. For this reason, the
"DRM connector" is always physically located after all the bridges.
The "hotplug connector" here described is physically hot-pluggable but does
not support model identification, being meant for buses that do not support
identification because they do not support hot-plugging natively.
This is why at least 1 bridge is assumed to be present in the removable
add-on: if there were no such bridge, the "hotplug connector" would be
immediately followed by the "DRM connector" and the panel. In such a
situation, hot-plugging could be implemented by the "DRM connector" in a
much more straightforward way. So this work is mostly useful when there is
at least one bridge on the removable add-on.
The removable components form a unique assembly whose components can not be
separated individually: at any given moment the add-on is either connected
or disconencted -- it is never considered partially connected.
After an add-on has been removed, an add-on of a different model can be
connected, e.g. providing a different panel needing different timings. The
technique to identify the model that gets connected is outside of the scope
of this patch series, as described in "Development roadmap" below.
Implementation
--------------
In order to support the above use case while being reasonably generic and
avoid unnecessary changes to the common DRM code, the implementation is
based on the introduction of the "hotplug-bridge", a new bridge driver that
represents the "hotplug connector" and should be positioned in the DRM
pipeline exactly where the "hotplug connector" is.
In this position the hotplug-bridge decouples the preceding and the
following components so that each of them can be implemented normally,
without having to even be aware of hot-plugging. The implementation is as
transparent as possible in order to minimize the need of any changes to the
design of other components: it is based on a few self-contained additions
to drm_bridge and drm_encoder, and does not require any modification to
other bridges. However the implementation has some tricky aspects that make
it more complex than in an ideal design. See the last patch in the series
for the details.
Patch overview:
* patch 1 adds device tree bindings for the "hotplug video connector"
* patches 2 and 3 add some prerequisite new features to the DRM code
* patch 4 adds the hotplug-bridge itself
Development roadmap
-------------------
This series is a part of a larger work to support embedded devices having a
hot-pluggable add-on. The overall work includes:
1. a mechanism to detect add-on insertion/removal, read the model ID and
load a corresponding device tree overlay
2. fixes to existing bugs that get exposed when loading/unloading device
tree overlays at runtime
3. allowing the tail of a DRM pipeline to be hot-pluggable [this series]
All of the above are under development at Bootlin, and patches for item 2
are already under discussion on the relevant mailing-lists.
Item 1 is a prerequisite for production usage of the hotplug-bridge, but
even though it is working well enough in internal testing, it is not yet
ready for sending patches for review. This patch series covering item 3 is
being sent anyway in order to start discussion with the kernel community as
early as possible, expecially the DRM community as this work is changing
some of the assumptions behind the DRM architecture.
Testing
-------
This series cannot be tested in public until the mechanism for add-on
insertion and removal will be sent. It can however be tested by other
means, even with a hardware that has no removable parts, "pretending" that
one or more bridges can be removed:
* remove and re-insert the driver module for the DRM bridge after the
hotplug-bridge
* unbind/bind the DRM bridge after the hotplug-bridge from its driver
Thanks for you patience in reading this!
Luca
Co-developed-by: Paul Kocialkowski <[email protected]>
Signed-off-by: Luca Ceresoli <[email protected]>
---
Luca Ceresoli (3):
dt-bindings: display: bridge: add the Hot-plug MIPI DSI connector
drm/encoder: add drm_encoder_cleanup_from()
drm/bridge: hotplug-bridge: add driver to support hot-pluggable DSI bridges
Paul Kocialkowski (1):
drm/bridge: add bridge notifier to be notified of bridge addition and removal
.../bridge/hotplug-video-connector-dsi.yaml | 87 ++++
MAINTAINERS | 6 +
drivers/gpu/drm/bridge/Kconfig | 15 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/hotplug-bridge.c | 561 +++++++++++++++++++++
drivers/gpu/drm/drm_bridge.c | 35 ++
drivers/gpu/drm/drm_encoder.c | 21 +
include/drm/drm_bridge.h | 19 +
include/drm/drm_encoder.h | 1 +
9 files changed, 746 insertions(+)
---
base-commit: 30b26f75c864d1da39fe5e8628f1cbc3702a9add
change-id: 20240319-hotplug-drm-bridge-16b86e67fe92
Best regards,
--
Luca Ceresoli <[email protected]>
Add bindings for a physical, hot-pluggable connector allowing the far end
of a MIPI DSI bus to be connected and disconnected at runtime.
Signed-off-by: Luca Ceresoli <[email protected]>
---
.../bridge/hotplug-video-connector-dsi.yaml | 87 ++++++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 92 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
new file mode 100644
index 000000000000..05beb8aa9ab4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Hot-pluggable connector on a MIPI DSI bus
+
+maintainers:
+ - Luca Ceresoli <[email protected]>
+
+description:
+ A bridge representing a physical, hot-pluggable connector on a MIPI DSI
+ video bus. The connector splits the video pipeline in a fixed part and a
+ removable part.
+
+ The fixed part of the video pipeline includes all components up to the
+ display controller and 0 or more bridges. The removable part includes one
+ or more bridges and any other components up to the panel.
+
+ The removable part of the pipeline can be physically disconnected at any
+ moment, making all of its components not usable anymore. The same or a
+ different removable part of the pipeline can be reconnected later on.
+
+ Note that the hotplug-video-connector does not describe video busses
+ having native hotplug capabilities in the hardware, such as HDMI.
+
+properties:
+ compatible:
+ const: hotplug-video-connector-dsi
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ The end of the fixed part of the MIPI DSI bus (terminating at the
+ hotplug connector). The remote-endpoint sub-node must point to
+ the previous component of the video pipeline.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ The start of the removable part of the MIPI DSI bus (starting
+ from the hotplug connector). The remote-endpoint sub-node must
+ point to the next component of the video pipeline.
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ hotplug-video-connector {
+ compatible = "hotplug-video-connector-dsi";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hotplug_connector_in: endpoint {
+ remote-endpoint = <&previous_bridge_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hotplug_connector_out: endpoint {
+ remote-endpoint = <&next_bridge_in>;
+ };
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index aa3b947fb080..e1affd13e30b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6716,6 +6716,11 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
F: drivers/gpu/drm/panel/panel-himax-hx8394.c
+DRM DRIVER FOR HOTPLUG VIDEO CONNECTOR BRIDGE
+M: Luca Ceresoli <[email protected]>
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
+
DRM DRIVER FOR HX8357D PANELS
S: Orphan
T: git git://anongit.freedesktop.org/drm/drm-misc
--
2.34.1
Supporting hardware whose final part of the DRM pipeline can be physically
removed requires the ability to detach all bridges from a given point to
the end of the pipeline.
Introduce a variant of drm_encoder_cleanup() for this.
Signed-off-by: Luca Ceresoli <[email protected]>
---
drivers/gpu/drm/drm_encoder.c | 21 +++++++++++++++++++++
include/drm/drm_encoder.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 8f2bc6a28482..13149447bec8 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -207,6 +207,27 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+/**
+ * drm_encoder_cleanup_from - remove a given bridge and all the following
+ * @encoder: encoder whole list of bridges shall be pruned
+ * @bridge: first bridge to remove
+ *
+ * Removes from an encoder all the bridges starting with a given bridges
+ * and until the end of the chain.
+ *
+ * This should not be used in "normal" DRM pipelines. It is only useful for
+ * devices whose final part of the DRM chain can be physically removed and
+ * later reconnected (possibly with different hardware).
+ */
+void drm_encoder_cleanup_from(struct drm_encoder *encoder, struct drm_bridge *bridge)
+{
+ struct drm_bridge *next;
+
+ list_for_each_entry_safe_from(bridge, next, &encoder->bridge_chain, chain_node)
+ drm_bridge_detach(bridge);
+}
+EXPORT_SYMBOL(drm_encoder_cleanup_from);
+
static void drmm_encoder_alloc_release(struct drm_device *dev, void *ptr)
{
struct drm_encoder *encoder = ptr;
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 977a9381c8ba..bafcabb24267 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -320,6 +320,7 @@ static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev,
}
void drm_encoder_cleanup(struct drm_encoder *encoder);
+void drm_encoder_cleanup_from(struct drm_encoder *encoder, struct drm_bridge *bridge);
/**
* drm_for_each_encoder_mask - iterate over encoders specified by bitmask
--
2.34.1
From: Paul Kocialkowski <[email protected]>
In preparation for allowing bridges to be added to and removed from a DRM
card without destroying the whole card, add a DRM bridge notifier. Notified
events are addition and removal to/from the global bridge list.
Co-developed-by: Luca Ceresoli <[email protected]>
Signed-off-by: Luca Ceresoli <[email protected]>
Signed-off-by: Paul Kocialkowski <[email protected]>
---
drivers/gpu/drm/drm_bridge.c | 35 +++++++++++++++++++++++++++++++++++
include/drm/drm_bridge.h | 19 +++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 521a71c61b16..245f7fa4ea22 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -25,6 +25,7 @@
#include <linux/media-bus-format.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/notifier.h>
#include <drm/drm_atomic_state_helper.h>
#include <drm/drm_bridge.h>
@@ -197,6 +198,36 @@
static DEFINE_MUTEX(bridge_lock);
static LIST_HEAD(bridge_list);
+static BLOCKING_NOTIFIER_HEAD(bridge_notifier);
+
+/**
+ * drm_bridge_notifier_register - add a DRM bridge notifier
+ * @nb: the notifier block to be registered
+ *
+ * The notifier block will be notified of events defined in
+ * &drm_bridge_notifier_event
+ */
+int drm_bridge_notifier_register(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&bridge_notifier, nb);
+}
+EXPORT_SYMBOL(drm_bridge_notifier_register);
+
+/**
+ * drm_bridge_notifier_unregister - remove a DRM bridge notifier
+ * @nb: the notifier block to be unregistered
+ */
+int drm_bridge_notifier_unregister(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&bridge_notifier, nb);
+}
+EXPORT_SYMBOL(drm_bridge_notifier_unregister);
+
+static void drm_bridge_notifier_notify(unsigned long event,
+ struct drm_bridge *bridge)
+{
+ blocking_notifier_call_chain(&bridge_notifier, event, bridge);
+}
/**
* drm_bridge_add - add the given bridge to the global bridge list
@@ -210,6 +241,8 @@ void drm_bridge_add(struct drm_bridge *bridge)
mutex_lock(&bridge_lock);
list_add_tail(&bridge->list, &bridge_list);
mutex_unlock(&bridge_lock);
+
+ drm_bridge_notifier_notify(DRM_BRIDGE_NOTIFY_ADD, bridge);
}
EXPORT_SYMBOL(drm_bridge_add);
@@ -243,6 +276,8 @@ EXPORT_SYMBOL(devm_drm_bridge_add);
*/
void drm_bridge_remove(struct drm_bridge *bridge)
{
+ drm_bridge_notifier_notify(DRM_BRIDGE_NOTIFY_REMOVE, bridge);
+
mutex_lock(&bridge_lock);
list_del_init(&bridge->list);
mutex_unlock(&bridge_lock);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 4baca0d9107b..ee48c1eb76ae 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -43,6 +43,22 @@ struct drm_panel;
struct edid;
struct i2c_adapter;
+/**
+ * enum drm_bridge_notifier_event - DRM bridge events
+ */
+enum drm_bridge_notifier_event {
+ /**
+ * @DRM_BRIDGE_NOTIFY_ADD: A bridge has just been added to the
+ * global bridge list. See drm_bridge_add().
+ */
+ DRM_BRIDGE_NOTIFY_ADD,
+ /**
+ * @DRM_BRIDGE_NOTIFY_REMOVE: A bridge is about to be removed from
+ * the global bridge list. See drm_bridge_remove().
+ */
+ DRM_BRIDGE_NOTIFY_REMOVE,
+};
+
/**
* enum drm_bridge_attach_flags - Flags for &drm_bridge_funcs.attach
*/
@@ -781,6 +797,9 @@ drm_priv_to_bridge(struct drm_private_obj *priv)
return container_of(priv, struct drm_bridge, base);
}
+int drm_bridge_notifier_register(struct notifier_block *nb);
+int drm_bridge_notifier_unregister(struct notifier_block *nb);
+
void drm_bridge_add(struct drm_bridge *bridge);
int devm_drm_bridge_add(struct device *dev, struct drm_bridge *bridge);
void drm_bridge_remove(struct drm_bridge *bridge);
--
2.34.1
On Tue, Mar 26, 2024 at 05:28:11PM +0100, Luca Ceresoli wrote:
> Add bindings for a physical, hot-pluggable connector allowing the far end
> of a MIPI DSI bus to be connected and disconnected at runtime.
>
> Signed-off-by: Luca Ceresoli <[email protected]>
> ---
> .../bridge/hotplug-video-connector-dsi.yaml | 87 ++++++++++++++++++++++
> MAINTAINERS | 5 ++
> 2 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> new file mode 100644
> index 000000000000..05beb8aa9ab4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Hot-pluggable connector on a MIPI DSI bus
> +
> +maintainers:
> + - Luca Ceresoli <[email protected]>
> +
> +description:
> + A bridge representing a physical, hot-pluggable connector on a MIPI DSI
> + video bus. The connector splits the video pipeline in a fixed part and a
> + removable part.
> +
> + The fixed part of the video pipeline includes all components up to the
> + display controller and 0 or more bridges. The removable part includes one
> + or more bridges and any other components up to the panel.
> +
> + The removable part of the pipeline can be physically disconnected at any
> + moment, making all of its components not usable anymore. The same or a
> + different removable part of the pipeline can be reconnected later on.
> +
> + Note that the hotplug-video-connector does not describe video busses
> + having native hotplug capabilities in the hardware, such as HDMI.
> +
> +properties:
> + compatible:
> + const: hotplug-video-connector-dsi
Got a spec for this connector? How do I know if I have one or not?
The problem here is what else is on this connector? GPIO controls,
power rails, etc.?
If this is some kind of standard connector, then we need to be able to
remap everything on the connector not just DSI signals. And for that,
it's not just DSI signals, so I'd say we would need some sort of generic
graph remapping that the core graph code handles transparently.
If it is not standard, then you don't need any remapping and can just
use an overlay that connects the ports directly.
Rob
Hello Rob,
[+Cc Wolfram for the I2C discussion below]
thanks for your feedback.
On Wed, 27 Mar 2024 11:09:08 -0500
Rob Herring <[email protected]> wrote:
> On Tue, Mar 26, 2024 at 05:28:11PM +0100, Luca Ceresoli wrote:
> > Add bindings for a physical, hot-pluggable connector allowing the far end
> > of a MIPI DSI bus to be connected and disconnected at runtime.
> >
> > Signed-off-by: Luca Ceresoli <[email protected]>
> > ---
> > .../bridge/hotplug-video-connector-dsi.yaml | 87 ++++++++++++++++++++++
> > MAINTAINERS | 5 ++
> > 2 files changed, 92 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> > new file mode 100644
> > index 000000000000..05beb8aa9ab4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/hotplug-video-connector-dsi.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/hotplug-video-connector-dsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Hot-pluggable connector on a MIPI DSI bus
> > +
> > +maintainers:
> > + - Luca Ceresoli <[email protected]>
> > +
> > +description:
> > + A bridge representing a physical, hot-pluggable connector on a MIPI DSI
> > + video bus. The connector splits the video pipeline in a fixed part and a
> > + removable part.
> > +
> > + The fixed part of the video pipeline includes all components up to the
> > + display controller and 0 or more bridges. The removable part includes one
> > + or more bridges and any other components up to the panel.
> > +
> > + The removable part of the pipeline can be physically disconnected at any
> > + moment, making all of its components not usable anymore. The same or a
> > + different removable part of the pipeline can be reconnected later on.
> > +
> > + Note that the hotplug-video-connector does not describe video busses
> > + having native hotplug capabilities in the hardware, such as HDMI.
> > +
> > +properties:
> > + compatible:
> > + const: hotplug-video-connector-dsi
>
> Got a spec for this connector? How do I know if I have one or not?
>
> The problem here is what else is on this connector? GPIO controls,
> power rails, etc.?
>
> If this is some kind of standard connector, then we need to be able to
> remap everything on the connector not just DSI signals. And for that,
> it's not just DSI signals, so I'd say we would need some sort of generic
> graph remapping that the core graph code handles transparently.
>
> If it is not standard, then you don't need any remapping and can just
> use an overlay that connects the ports directly.
This is not a standardized connector. And it couldn't be: to the best of
my knowledge no standard removable MIPI DSI connector exists at all.
This whole work is unavoidably breaking some long-standing assumptions
and opening some new challenges: giving a proper DT description to
runtime-pluggable hardware and breaking the dogma that a DRM pipeline
is not removable, to name some. So I think it's better to take a step
back and describe the big picture.
As mentioned in the cover letter ("Development roadmap" section),
together with Hervé we are working on a set of patches to allow this
sort of removable hardware to be handled properly by the Linux kernel.
From the cover letter:
> The use case we are working on is to support professional products that
> have a portable "main" part running on battery, with the main SoC and able
> to work autonomously with limited features, and that can be connected to an
> "add-on" part that is not portable and adds more features.
The add-on gets connected via a connector that is not standardized.
There is a well-defined part number for the mechanical connector, but
the pin usage is custom for the product. Connector pins include:
* I2C lines to access various chips on the add-on
- one of these chips is an EEPROM with the add-on product ID
* Some pins to report to the CPU whether the add-on is connected and
add-on power rails are stable (these are wired to SoC GPIOs)
* An interrupt line collecting IRQs from the add-on chips
* MIPI DSI to drive a panel on the add-on
* Gigabit Ethernet (4 pairs)
* USB lines
* A few more accessory pins
Some of these are not problematic: USB is hot-pluggable and
auto-discoverable by nature, Ethernet pins are just connected directly
to the RJ-45 connector so the add-on acts as an Ethernet or USB cable.
For everything else there is going to be a separate patch series
with code to detect add-on connection, read the ID, identify the
appropriate DT overlay and load it, and unload it on disconnection.
Before that, it's good to discuss how the device tree should describe
the whole hardware described above, in these terms:
1. Should device tree describe the connector?
2. If it does, how should the various busses on the connector
(especially I2C and MIPI DSI) be described and associated to the
connector?
To address question 1, I think we _do_ need to describe the connector
itself, because it is a part of the non-discoverable hardware that the
software needs to manage. Among others we need software to know which
GPIOs report the connection and power good statuses, and to know how to
locate the ID EEPROM.
Regarding question 2 I think there are a few open possibilities, and
I must admit the example provided in this series is just too simplistic
to be adequate. Apologies, this series is mostly aiming at discussing
the DRM implementation aspects.
Let me try a more realistic DT description that allows to:
1. associate the various busses to the connector they go through
2. map components of different base board models to the connector pins
3. map components of different add-on models to the connector pins
The 2nd and 3rd items allow decoupling the base and add-on hardware so
that different base board models and different add-on models can be
mixed in all combinations if they use the same connector pinout. This
obviously resembles the Beaglebone capes and RPi hats use case.
My draft proposal is as follows:
---------------------- [my-product.dts] ----------------------
/ {
// [0]
my_hotplug_connector: my-hotplug-connector {
compatible = "vendor-abc,product-xyz-connector";
// [1]
plugged-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
powergood-gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
// [5]
hotplug_dsi_bus: hotplug-dsi-video-bus@0 {
port@0 {
reg = <0>;
hotplug_dsi_in: endpoint {
remote-endpoint = <&bridge1>;
};
};
port@1 {
reg = <1>;
hotplug_dsi_out: endpoint {
// remote-endpoint to be added by overlay
};
};
};
// [3]
// Map "placeholder" i2cA to "physical" i2c3
i2cA: hotplug-i2c-bus@A {
hotplug-connector,base-bus = <&i2c3>;
};
i2cB: hotplug-i2c-bus@B {
hotplug-connector,base-bus = <&i2c5>;
};
};
};
// Video bridge or display controller on the base board
&bridge1 {
ports {
port@1 {
bridge1_out: endpoint {
remote-endpoint = <&hotplug_dsi_in>;
};
};
};
};
--------------------------------------------------------------
------------------- [my-add-on-common.dtso] ------------------
// [2]
&my_hotplug_connector {
nvmem-cells = <addon_id>;
nvmem-cell-names = "id";
};
// [4]
// i2cA is a "placeholder" name, mapped by the connector
// definition on the base dts to a physical bus on the base board
&i2cA {
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
addon_id: addon-id@10 {
reg = <0x10 0x4>;
};
};
};
};
--------------------------------------------------------------
----------------- [my-add-on-model-xyz.dtso] -----------------
// [6]
&hotplug_dsi_out {
remote-endpoint = <&bridge2_in>; // Fill in the missing piece
};
&{/}
{
panel {
compatible = ...;
ports {
port@0 {
reg = <0>;
panel_in: endpoint {
remote-endpoint = <&bridge2_out>;
};
};
};
};
};
&i2cB {
// Video bridge chip on the add-on
bridge@22 {
// ... compatible, other props/nodes ...
ports {
port@0 {
bridge2_in: endpoint {
remote-endpoint = <&hotplug_dsi_out>;
};
};
port@1 {
bridge2_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
};
--------------------------------------------------------------
The connector itself [0] is described under the root node because it is
not on any addressable bus, similarly to "sound" and "panel" nodes. I
don't think connectors addressable over I2C or other addressable busses
are going to appear in the forseeable future, but if they did they
could be represented as such in the device tree as well.
The connector GPIOs [1] allow the CPU to know the connection and "power
good" status of the connector. On the implementation side, those are the
inputs triggering overlay loading and unloading.
There is a "common" overlay which describes the common components of
all add-ons at least up to the NVMEM cell [2] holding the add-on ID
that is needed to load the model-specific overlay. This overlay adds
nvmem properties to the hotplug connector node to point to the specific
NVMEM cell. The nvmem-cells and nvmem-cell-names = "id" properties need
to be part of the hotplug-connector bindings.
The "placeholder" hotplug-i2c-bus nodes in the connector node [3] allow
decoupling the I2C bus segment on the base board from the segment on
the add-on. They point to the base bus controller phandle via
hotplug-connector,base-bus, and allow the overlay to use the
"placeholder" [4] instead of naming the "base" I2C bus name. This
allows using the same add-on and overlay on a different base board,
which could even have a totally different SoC, and where the same
connector pins are not wired to the SoC i2c3 but to e.g. i2c4.
In other words:
* [3] means connector pins X and Y are wired to i2c3 on this base board
* [4] means connector pins X and Y are wired to i2cA on this add-on
The specific pins X and Y are not described. Only the bus going through
the connector is.
This can be implemented in the I2C code similarly to a 1-port i2c-mux,
even though it might have an even better ad-hoc implementation that
avoids any unneeded overhead from the mux code, as we are not muxing
anything here, just "connecting wires". Whatever the implementation,
what it needs to do is ensure that i2cA and i2cB appear as regular I2C
busses to their subnodes (e.g. eeprom@50), and when drivers for those
subnodes try to probe they attach to the correct bus (i2c3, i2c5) in
some way -- anything else is an implementation detail. Let's call this
the "I2C decoupler driver".
Once the "common" overlay is loaded, software can read the add-on ID
from NVMEM and find out the overlay that describes the specific add-on
model, see my-add-on-model-xyz.dtso above. This other overlay needs to
be loaded and will populate all the remaining add-on hardware, possibly
using nodes from the first overlay (e.g. a regulator that is used both
by the eeprom@50 and by nodes in the 2nd overlay).
Now to the video bus. Back to the main dts, the hotplug-dsi-video-bus@0
node [5] describes the video pipeline up to the "main" board side of
the connector, represented by port@0. port@1 represents the beginning
of the add-on side of the pipeline, and as such it has no
remote-endpoint because no hardware is present before hotplug and anyway
which hardware will be connected is unknown.
Note DSI is used in the example, but it could as well be LVDS or
parallel video.
The model-specific overlay describes the continuation of the pipeline
up to the panel _and_ fills in the remote-endpoint of &hotplug_dsi_out
to connect the two segments. Just like the i2c example, the overlays
never refer to base board components: it only refers to what appears in
the hotplug connector definition node [0].
An alternative design is that the entire port@1 node is missing from the
hotplug-dsi-video-bus@0 node and is entirely added by the overlay. No
strong opinion on this, the example shows what is tested, but I think
either will be fine.
On the implementation side, the hotplug-dsi-video-bus@0 node does
materialize as the hotplug-bridge driver (patch 4 of this series). The
hotplug-bridge sits in the middle of a previous bridge and the first
bridge in the add-on to let each of them probe normally, and then
passes calls through as transparently as possible.
Still about the implementation, in this example there are 3 main
components that need an implementation:
1. the hotplug-connector driver for /my-hotplug-connector [0]
2. the I2C decoupler driver (possibly based on i2c-mux)
3. the hotplug-bridge driver (this series)
The hotplug-connector driver is responsible for monitoring the
status GPIOs, load the 1st overlay, read the NVMEM ID, load the 2nd
overlay. But it is also in charge of instantiating the "decoupling"
driver for hotplug-i2c-bus nodes [1] and hotplug-dsi-video-bus nodes
[3].
Generalizing the idea to other busses such as SPI should be quite
trivial.
This device tree representation is possibly complicated and verbose.
However I cannot think of a simpler one that can describe a connector
to a removable hardware without losing the ability of decoupling the
base hardware from the add-on hardware.
Your opinion on this will be very appreciated.
Best regards,
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com