* [PATCH v8 09/11] usb: common: create Kconfig file
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Create Kconfig file for USB common core, and move USB_LED_TRIG
and USB_ULPI_BUS configs into the new file from the parent Kconfig,
it will help to add new configs later.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8:
new patch
---
drivers/usb/Kconfig | 35 +----------------------------------
drivers/usb/common/Kconfig | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 34 deletions(-)
create mode 100644 drivers/usb/common/Kconfig
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 6e59d370ef81..7bf94e65ed2f 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -36,8 +36,7 @@ menuconfig USB_SUPPORT
if USB_SUPPORT
-config USB_COMMON
- tristate
+source "drivers/usb/common/Kconfig"
config USB_ARCH_HAS_HCD
def_bool y
@@ -175,36 +174,4 @@ source "drivers/usb/typec/Kconfig"
source "drivers/usb/roles/Kconfig"
-config USB_LED_TRIG
- bool "USB LED Triggers"
- depends on LEDS_CLASS && LEDS_TRIGGERS
- select USB_COMMON
- help
- This option adds LED triggers for USB host and/or gadget activity.
-
- Say Y here if you are working on a system with led-class supported
- LEDs and you want to use them as activity indicators for USB host or
- gadget.
-
-config USB_ULPI_BUS
- tristate "USB ULPI PHY interface support"
- select USB_COMMON
- help
- UTMI+ Low Pin Interface (ULPI) is specification for a commonly used
- USB 2.0 PHY interface. The ULPI specification defines a standard set
- of registers that can be used to detect the vendor and product which
- allows ULPI to be handled as a bus. This module is the driver for that
- bus.
-
- The ULPI interfaces (the buses) are registered by the drivers for USB
- controllers which support ULPI register access and have ULPI PHY
- attached to them. The ULPI PHY drivers themselves are normal PHY
- drivers.
-
- ULPI PHYs provide often functions such as ADP sensing/probing (OTG
- protocol) and USB charger detection.
-
- To compile this driver as a module, choose M here: the module will
- be called ulpi.
-
endif # USB_SUPPORT
diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig
new file mode 100644
index 000000000000..848545b099cf
--- /dev/null
+++ b/drivers/usb/common/Kconfig
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config USB_COMMON
+ tristate
+
+
+config USB_LED_TRIG
+ bool "USB LED Triggers"
+ depends on LEDS_CLASS && LEDS_TRIGGERS
+ select USB_COMMON
+ help
+ This option adds LED triggers for USB host and/or gadget activity.
+
+ Say Y here if you are working on a system with led-class supported
+ LEDs and you want to use them as activity indicators for USB host or
+ gadget.
+
+config USB_ULPI_BUS
+ tristate "USB ULPI PHY interface support"
+ select USB_COMMON
+ help
+ UTMI+ Low Pin Interface (ULPI) is specification for a commonly used
+ USB 2.0 PHY interface. The ULPI specification defines a standard set
+ of registers that can be used to detect the vendor and product which
+ allows ULPI to be handled as a bus. This module is the driver for that
+ bus.
+
+ The ULPI interfaces (the buses) are registered by the drivers for USB
+ controllers which support ULPI register access and have ULPI PHY
+ attached to them. The ULPI PHY drivers themselves are normal PHY
+ drivers.
+
+ ULPI PHYs provide often functions such as ADP sensing/probing (OTG
+ protocol) and USB charger detection.
+
+ To compile this driver as a module, choose M here: the module will
+ be called ulpi.
+
--
2.21.0
^ permalink raw reply related
* [PATCH v8 08/11] usb: roles: get usb-role-switch from parent
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
when the USB host controller is the parent of the connector,
usually type-B, sometimes don't need the graph, so we should
check whether it's parent registers usb-role-switch or not
firstly, and get it if exists.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8: no changes
v7:
add signed-off-by Chunfeng
v6:
new patch
---
drivers/usb/roles/class.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index 5b637aaf311f..87439a84c983 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -114,6 +114,19 @@ static void *usb_role_switch_match(struct device_connection *con, int ep,
return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
}
+static struct usb_role_switch *
+usb_role_switch_is_parent(struct fwnode_handle *fwnode)
+{
+ struct fwnode_handle *parent = fwnode_get_parent(fwnode);
+ struct device *dev;
+
+ if (!parent || !fwnode_property_present(parent, "usb-role-switch"))
+ return NULL;
+
+ dev = class_find_device(role_class, NULL, parent, switch_fwnode_match);
+ return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
+}
+
/**
* usb_role_switch_get - Find USB role switch linked with the caller
* @dev: The caller device
@@ -125,8 +138,10 @@ struct usb_role_switch *usb_role_switch_get(struct device *dev)
{
struct usb_role_switch *sw;
- sw = device_connection_find_match(dev, "usb-role-switch", NULL,
- usb_role_switch_match);
+ sw = usb_role_switch_is_parent(dev_fwnode(dev));
+ if (!sw)
+ sw = device_connection_find_match(dev, "usb-role-switch", NULL,
+ usb_role_switch_match);
if (!IS_ERR_OR_NULL(sw))
WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
@@ -146,8 +161,10 @@ struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *fwnode)
{
struct usb_role_switch *sw;
- sw = fwnode_connection_find_match(fwnode, "usb-role-switch", NULL,
- usb_role_switch_match);
+ sw = usb_role_switch_is_parent(fwnode);
+ if (!sw)
+ sw = fwnode_connection_find_match(fwnode, "usb-role-switch",
+ NULL, usb_role_switch_match);
if (!IS_ERR_OR_NULL(sw))
WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
--
2.21.0
^ permalink raw reply related
* [PATCH v8 07/11] usb: roles: Add fwnode_usb_role_switch_get() function
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
The fwnode_usb_role_switch_get() function is exactly the
same as usb_role_switch_get(), except that it takes struct
fwnode_handle as parameter instead of struct device.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Tested-by: Biju Das <biju.das@bp.renesas.com>
---
v8: no changes
v7:
add signed-off-by Chunfeng and tested-by Biju
v6:
new patch
---
drivers/usb/roles/class.c | 20 ++++++++++++++++++++
include/linux/usb/role.h | 7 +++++++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
index 86defca6623e..5b637aaf311f 100644
--- a/drivers/usb/roles/class.c
+++ b/drivers/usb/roles/class.c
@@ -135,6 +135,26 @@ struct usb_role_switch *usb_role_switch_get(struct device *dev)
}
EXPORT_SYMBOL_GPL(usb_role_switch_get);
+/**
+ * fwnode_usb_role_switch_get - Find USB role switch linked with the caller
+ * @fwnode: The caller device node
+ *
+ * This is similar to the usb_role_switch_get() function above, but it searches
+ * the switch using fwnode instead of device entry.
+ */
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *fwnode)
+{
+ struct usb_role_switch *sw;
+
+ sw = fwnode_connection_find_match(fwnode, "usb-role-switch", NULL,
+ usb_role_switch_match);
+ if (!IS_ERR_OR_NULL(sw))
+ WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
+
+ return sw;
+}
+EXPORT_SYMBOL_GPL(fwnode_usb_role_switch_get);
+
/**
* usb_role_switch_put - Release handle to a switch
* @sw: USB Role Switch
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index da2b9641b877..2d77f97df72d 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -47,6 +47,7 @@ struct usb_role_switch_desc {
int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
struct usb_role_switch *usb_role_switch_get(struct device *dev);
+struct usb_role_switch *fwnode_usb_role_switch_get(struct fwnode_handle *node);
void usb_role_switch_put(struct usb_role_switch *sw);
struct usb_role_switch *
@@ -70,6 +71,12 @@ static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
return ERR_PTR(-ENODEV);
}
+static inline struct usb_role_switch *
+fwnode_usb_role_switch_get(struct fwnode_handle *node)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
static inline struct usb_role_switch *
--
2.21.0
^ permalink raw reply related
* [PATCH v8 06/11] device connection: Add fwnode_connection_find_match()
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
The fwnode_connection_find_match() function is exactly the
same as device_connection_find_match(), except it takes
struct fwnode_handle as parameter instead of struct device.
That allows locating device connections before the device
entries have been created.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8: no changes
v7:
rebased on Rafael's tree [1] (after rc4), provided by Heikki
[1] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next
v6:
new patch
---
drivers/base/devcon.c | 43 ++++++++++++++++++++++++++++++------------
include/linux/device.h | 10 +++++++---
2 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index 09f28479b243..986ad89de2f9 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -12,9 +12,6 @@
static DEFINE_MUTEX(devcon_lock);
static LIST_HEAD(devcon_list);
-typedef void *(*devcon_match_fn_t)(struct device_connection *con, int ep,
- void *data);
-
static void *
fwnode_graph_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
void *data, devcon_match_fn_t match)
@@ -60,6 +57,34 @@ fwnode_devcon_match(struct fwnode_handle *fwnode, const char *con_id,
return NULL;
}
+/**
+ * fwnode_connection_find_match - Find connection from a device node
+ * @fwnode: Device node with the connection
+ * @con_id: Identifier for the connection
+ * @data: Data for the match function
+ * @match: Function to check and convert the connection description
+ *
+ * Find a connection with unique identifier @con_id between @fwnode and another
+ * device node. @match will be used to convert the connection description to
+ * data the caller is expecting to be returned.
+ */
+void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
+ const char *con_id, void *data,
+ devcon_match_fn_t match)
+{
+ void *ret;
+
+ if (!fwnode || !match)
+ return NULL;
+
+ ret = fwnode_graph_devcon_match(fwnode, con_id, data, match);
+ if (ret)
+ return ret;
+
+ return fwnode_devcon_match(fwnode, con_id, data, match);
+}
+EXPORT_SYMBOL_GPL(fwnode_connection_find_match);
+
/**
* device_connection_find_match - Find physical connection to a device
* @dev: Device with the connection
@@ -83,15 +108,9 @@ void *device_connection_find_match(struct device *dev, const char *con_id,
if (!match)
return NULL;
- if (fwnode) {
- ret = fwnode_graph_devcon_match(fwnode, con_id, data, match);
- if (ret)
- return ret;
-
- ret = fwnode_devcon_match(fwnode, con_id, data, match);
- if (ret)
- return ret;
- }
+ ret = fwnode_connection_find_match(fwnode, con_id, data, match);
+ if (ret)
+ return ret;
mutex_lock(&devcon_lock);
diff --git a/include/linux/device.h b/include/linux/device.h
index c330b75c6c57..ba73878f8e93 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -778,10 +778,14 @@ struct device_connection {
struct list_head list;
};
+typedef void *(*devcon_match_fn_t)(struct device_connection *con, int ep,
+ void *data);
+
+void *fwnode_connection_find_match(struct fwnode_handle *fwnode,
+ const char *con_id, void *data,
+ devcon_match_fn_t match);
void *device_connection_find_match(struct device *dev, const char *con_id,
- void *data,
- void *(*match)(struct device_connection *con,
- int ep, void *data));
+ void *data, devcon_match_fn_t match);
struct device *device_connection_find(struct device *dev, const char *con_id);
--
2.21.0
^ permalink raw reply related
* [PATCH v8 05/11] usb: roles: Introduce stubs for the exiting functions in role.h.
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij, Yu Chen,
John Stultz
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
From: Yu Chen <chenyu56@huawei.com>
This patch adds stubs for the exiting functions while
CONFIG_USB_ROLE_SWITCH does not enabled.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: John Stultz <john.stultz@linaro.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8:
no changes
v7:
add Signed-off-by Chunfeng
v6:
merge this patch [1] into this series to add new API
[1] https://patchwork.kernel.org/patch/10909971/
---
include/linux/usb/role.h | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index c05ffa6abda9..da2b9641b877 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -42,6 +42,8 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
};
+
+#if IS_ENABLED(CONFIG_USB_ROLE_SWITCH)
int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
struct usb_role_switch *usb_role_switch_get(struct device *dev);
@@ -51,5 +53,33 @@ struct usb_role_switch *
usb_role_switch_register(struct device *parent,
const struct usb_role_switch_desc *desc);
void usb_role_switch_unregister(struct usb_role_switch *sw);
+#else
+static inline int usb_role_switch_set_role(struct usb_role_switch *sw,
+ enum usb_role role)
+{
+ return 0;
+}
+
+static inline enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw)
+{
+ return USB_ROLE_NONE;
+}
+
+static inline struct usb_role_switch *usb_role_switch_get(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_put(struct usb_role_switch *sw) { }
+
+static inline struct usb_role_switch *
+usb_role_switch_register(struct device *parent,
+ const struct usb_role_switch_desc *desc)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline void usb_role_switch_unregister(struct usb_role_switch *sw) { }
+#endif
#endif /* __LINUX_USB_ROLE_H */
--
2.21.0
^ permalink raw reply related
* [PATCH v8 04/11] dt-bindings: usb: mtu3: add properties about USB Role Switch
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, devicetree, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, Linus Walleij, linux-usb, linux-kernel,
Matthias Brugger, Andy Shevchenko, linux-mediatek, Min Guo,
Chunfeng Yun, Adam Thomson, linux-arm-kernel, Li Jun
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Now the USB Role Switch is supported, so add properties about it,
and modify some description related.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v8 no changes
v7 no changes
v6 no changes
v5 changes:
1. modify decription about extcon and vbus-supply properties
2. make this patch depend on [1]
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
v4 no changes
v3 no changes
v2 changes:
1. fix typo
2. refer new binding about connector property
---
.../devicetree/bindings/usb/mediatek,mtu3.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index 3382b5cb471d..3a8300205cdb 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -28,8 +28,13 @@ Optional properties:
parent's address space
- extcon : external connector for vbus and idpin changes detection, needed
when supports dual-role mode.
+ it's considered valid for compatibility reasons, not allowed for
+ new bindings, and use "usb-role-switch" property instead.
- vbus-supply : reference to the VBUS regulator, needed when supports
dual-role mode.
+ it's considered valid for compatibility reasons, not allowed for
+ new bindings, and put into a usb-connector node.
+ see connector/usb-connector.txt.
- pinctrl-names : a pinctrl state named "default" is optional, and need be
defined if auto drd switch is enabled, that means the property dr_mode
is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
@@ -39,6 +44,8 @@ Optional properties:
- maximum-speed : valid arguments are "super-speed", "high-speed" and
"full-speed"; refer to usb/generic.txt
+ - usb-role-switch : use USB Role Switch to support dual-role switch, but
+ not extcon; see usb/generic.txt.
- enable-manual-drd : supports manual dual-role switch via debugfs; usually
used when receptacle is TYPE-A and also wants to support dual-role
mode.
@@ -61,6 +68,9 @@ The xhci should be added as subnode to mtu3 as shown in the following example
if host mode is enabled. The DT binding details of xhci can be found in:
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+The port would be added as subnode if use "usb-role-switch" property.
+ see graph.txt
+
Example:
ssusb: usb@11271000 {
compatible = "mediatek,mt8173-mtu3";
--
2.21.0
^ permalink raw reply related
* [PATCH v8 03/11] dt-bindings: usb: add binding for USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
It's used to support dual role switch via GPIO when use Type-B
receptacle, typically the USB ID pin is connected to an input
GPIO, and also used to enable/disable device when the USB Vbus
pin is connected to an input GPIO.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v8 changes:
1. rename the title
2. change the compatible as "linux,usb-conn-gpio" instead of
"linux,typeb-conn-gpio"
v7 changes:
1. add description for device only mode
v6 changes:
1. remove status and port nodes in example
2. make vbus-supply as optional property
v5 changes:
1. treat type-B connector as child device of USB controller's, but not
as a separate virtual device, suggested by Rob
2. put connector's port node under connector node, suggested by Rob
v4 no changes
v3 changes:
1. treat type-B connector as a virtual device, but not child device of
USB controller's
v2 changes:
1. new patch to make binding clear suggested by Hans
---
.../devicetree/bindings/usb/usb-conn-gpio.txt | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
new file mode 100644
index 000000000000..d4d107fedc22
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
@@ -0,0 +1,31 @@
+USB GPIO Based Connection Detection
+
+This is typically used to switch dual role mode from the USB ID pin connected
+to an input GPIO, and also used to enable/disable device mode from the USB
+Vbus pin connected to an input GPIO.
+
+Required properties:
+- compatible : should include "linux,usb-conn-gpio" and "usb-b-connector".
+- id-gpios, vbus-gpios : input gpios, either one of them must be present,
+ and both can be present as well.
+ see connector/usb-connector.txt
+
+Optional properties:
+- vbus-supply : can be present if needed when supports dual role mode.
+ see connector/usb-connector.txt
+
+- Sub-nodes:
+ - port : can be present.
+ see graph.txt
+
+Example:
+
+&mtu3 {
+ connector {
+ compatible = "linux,usb-conn-gpio", "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
+ vbus-supply = <&usb_p0_vbus>;
+ };
+};
--
2.21.0
^ permalink raw reply related
* [PATCH v8 02/11] dt-bindings: connector: add optional properties for Type-B
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for
usb-b-connector
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v8 no changes
v7 no changes
v6 no changes
v5 changes:
1. add reviewed by Rob
v4 no changes
v3 changes:
1. add GPIO direction, and use fixed-regulator for GPIO controlled
VBUS regulator suggested by Rob;
v2 changes:
1. describe more clear for vbus-gpios and vbus-supply suggested by Hans
---
.../bindings/connector/usb-connector.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
index cef556d4e5ee..d357987181ee 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -17,6 +17,20 @@ Optional properties:
- self-powered: Set this property if the usb device that has its own power
source.
+Optional properties for usb-b-connector:
+- id-gpios: an input gpio for USB ID pin.
+- vbus-gpios: an input gpio for USB VBUS pin, used to detect presence of
+ VBUS 5V.
+ see gpio/gpio.txt.
+- vbus-supply: a phandle to the regulator for USB VBUS if needed when host
+ mode or dual role mode is supported.
+ Particularly, if use an output GPIO to control a VBUS regulator, should
+ model it as a regulator.
+ see regulator/fixed-regulator.yaml
+- pinctrl-names : a pinctrl state named "default" is optional
+- pinctrl-0 : pin control group
+ see pinctrl/pinctrl-bindings.txt
+
Optional properties for usb-c-connector:
- power-role: should be one of "source", "sink" or "dual"(DRP) if typec
connector has power support.
--
2.21.0
^ permalink raw reply related
* [PATCH v8 01/11] dt-binding: usb: add usb-role-switch property
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij, Yu Chen
In-Reply-To: <1563958245-6321-1-git-send-email-chunfeng.yun@mediatek.com>
Add a property usb-role-switch to tell the driver that use
USB Role Switch framework to handle the role switch,
it's useful when the driver has already supported other ways,
such as extcon framework etc.
Cc: Biju Das <biju.das@bp.renesas.com>
Cc: Yu Chen <chenyu56@huawei.com>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
v8: no changes
v7: no changes
v6:
1. merge into this series patch
2. add Reviewed-by
(no v4, v5)
v3:
add property type, modify description suggested by Heikki
v2:
describe it in terms of h/w functionality suggested by Rob
v1:
the property is discussed in:
[v2,2/7] dt-bindings: usb: renesas_usb3: add usb-role-switch property
https://patchwork.kernel.org/patch/10852497/
Mediatek and Hisilicon also try to use it:
[v4,3/6] dt-bindings: usb: mtu3: add properties about USB Role Switch
https://patchwork.kernel.org/patch/10918385/
[v4,6/6] usb: mtu3: register a USB Role Switch for dual role mode
https://patchwork.kernel.org/patch/10918367/
[v6,10/13] usb: dwc3: Registering a role switch in the DRD code
https://patchwork.kernel.org/patch/10909981/
---
Documentation/devicetree/bindings/usb/generic.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
index 0a74ab8dfdc2..cf5a1ad456e6 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -30,6 +30,10 @@ Optional properties:
optional for OTG device.
- adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
optional for OTG device.
+ - usb-role-switch: boolean, indicates that the device is capable of assigning
+ the USB data role (USB host or USB device) for a given
+ USB connector, such as Type-C, Type-B(micro).
+ see connector/usb-connector.txt.
This is an attribute to a USB controller such as:
--
2.21.0
^ permalink raw reply related
* [PATCH v8 00/11] add USB GPIO based connection detection driver
From: Chunfeng Yun @ 2019-07-24 8:50 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Biju Das
Cc: Mark Rutland, Chunfeng Yun, Matthias Brugger, Adam Thomson,
Li Jun, Badhri Jagan Sridharan, Heikki Krogerus, Hans de Goede,
Andy Shevchenko, Min Guo, devicetree, linux-kernel, linux-usb,
linux-arm-kernel, linux-mediatek, Linus Walleij
Because the USB Connector is introduced and the requirement of
usb-connector.txt binding, the old way using extcon to support
USB Dual-Role switch is now deprecated, meanwhile there is no
available common driver when use Type-B connector, typically
using an input GPIO to detect USB ID pin.
This patch series introduce a USB GPIO based connection detecton
driver and try to replace the function provided by extcon-usb-gpio
driver.
v8 changes:
1. rename the driver's name suggested by Heikki
2. move the driver from usb/roles/ into usb/common/ suggested by Heikki
3. introduce Kconfig for usb common core to add the new driver
4. modify binding of the driver
5. rename the subject title
v7 changes:
1. [5/10]: add signed-off-by Chunfeng
2. [6/10]: add signed-off-by Chunfeng
3. [6/10]: depends on linux-next of Rafael's tree [1]
4. [7/10]: add signed-off-by Chunfeng and tested-by Biju
5. [9/10]: add tested-by Nagarjuna, and remove DEV_PMS_OPS suggested by Andy
[1] https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=linux-next
v6 changes:
1. merge [1] and [2] into this series
2. don't use graph anymore to find usb-role-switch
3. abandon [3] and introduce three patches (6, 7, 8 in this series)
to rebuild APIs getting usb-role-switch
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
[2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
[3]: [PATCH v5 4/6] usb: roles: add API to get usb_role_switch by node
v5 changes:
1. remove linux/of.h and put usb_role_switch when error happens,
suggested by Biju
2. treat Type-B connector as USB controller's child, but not as
a virtual device, suggested by Rob
3. provide and use generic property "usb-role-switch", see [1],
suggested by Rob
Note: this series still depends on [2]
[1]: [v3] dt-binding: usb: add usb-role-switch property
https://patchwork.kernel.org/patch/10934835/
[2]: [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
v4 changes:
1. use switch_fwnode_match() to find fwnode suggested by Heikki
2. assign fwnode member of usb_role_switch struct suggested by Heikki
3. make [4/6] depend on [2]
3. remove linux/gpio.h suggested by Linus
4. put node when error happens
[4/6] usb: roles: add API to get usb_role_switch by node
[2] [v6,08/13] usb: roles: Introduce stubs for the exiting functions in role.h
https://patchwork.kernel.org/patch/10909971/
v3 changes:
1. add GPIO direction, and use fixed-regulator for GPIO controlled
VBUS regulator suggested by Rob;
2. rebuild fwnode_usb_role_switch_get() suggested by Andy and Heikki
3. treat the type-B connector as a virtual device;
4. change file name of driver again
5. select USB_ROLE_SWITCH in mtu3/Kconfig suggested by Heikki
6. rename ssusb_mode_manual_switch() to ssusb_mode_switch()
v2 changes:
1. make binding clear, and add a extra compatible suggested by Hans
Chunfeng Yun (8):
dt-binding: usb: add usb-role-switch property
dt-bindings: connector: add optional properties for Type-B
dt-bindings: usb: add binding for USB GPIO based connection detection
driver
dt-bindings: usb: mtu3: add properties about USB Role Switch
usb: roles: get usb-role-switch from parent
usb: common: create Kconfig file
usb: common: add USB GPIO based connection detection driver
usb: mtu3: register a USB Role Switch for dual role mode
Heikki Krogerus (2):
device connection: Add fwnode_connection_find_match()
usb: roles: Add fwnode_usb_role_switch_get() function
Yu Chen (1):
usb: roles: Introduce stubs for the exiting functions in role.h.
.../bindings/connector/usb-connector.txt | 14 +
.../devicetree/bindings/usb/generic.txt | 4 +
.../devicetree/bindings/usb/mediatek,mtu3.txt | 10 +
.../devicetree/bindings/usb/usb-conn-gpio.txt | 31 ++
drivers/base/devcon.c | 43 ++-
drivers/usb/Kconfig | 35 +--
drivers/usb/common/Kconfig | 51 ++++
drivers/usb/common/Makefile | 1 +
drivers/usb/common/usb-conn-gpio.c | 284 ++++++++++++++++++
drivers/usb/mtu3/Kconfig | 1 +
drivers/usb/mtu3/mtu3.h | 5 +
drivers/usb/mtu3/mtu3_debugfs.c | 4 +-
drivers/usb/mtu3/mtu3_dr.c | 48 ++-
drivers/usb/mtu3/mtu3_dr.h | 6 +-
drivers/usb/mtu3/mtu3_plat.c | 3 +-
drivers/usb/roles/class.c | 41 ++-
include/linux/device.h | 10 +-
include/linux/usb/role.h | 37 +++
18 files changed, 570 insertions(+), 58 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
create mode 100644 drivers/usb/common/Kconfig
create mode 100644 drivers/usb/common/usb-conn-gpio.c
--
2.21.0
^ permalink raw reply
* Re: [Sound-open-firmware] [PATCH v2 1/5] ASoC: SOF: imx: Add i.MX8 HW support
From: Lucas Stach @ 2019-07-24 8:32 UTC (permalink / raw)
To: Daniel Baluta, Pierre-Louis Bossart
Cc: Mark Rutland, Aisheng Dong, Peng Fan, Fabio Estevam, Anson Huang,
Devicetree List, Daniel Baluta, S.j. Wang, Marco Felsch,
Linux Kernel Mailing List, Paul Olaru, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, Leonard Crestez, Shawn Guo,
linux-arm-kernel, sound-open-firmware
In-Reply-To: <CAEnQRZCuB2QKzz-08K0z+x+p0qCpqR_wDc=q2GChvJiw4E9hBA@mail.gmail.com>
Hi Daniel,
Am Mittwoch, den 24.07.2019, 09:54 +0300 schrieb Daniel Baluta:
> On Tue, Jul 23, 2019 at 6:18 PM Pierre-Louis Bossart
[...]
>
> > Also are all the resources device-managed, I don't see a remove()?
>
> Good catch for pm stuff. We mostly didn't care about remove because
> drivers are always Y in our distribution.
Linux drivers need to be hotplug aware, even if they are not built as a
module. You can test things by manually unbinding the driver from the
device via sysfs.
Regards,
Lucas
^ permalink raw reply
* [PATCH v1 1/1] i2c: iproc: Fix i2c master read more than 63 bytes
From: Rayagonda Kokatanur @ 2019-07-24 8:28 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list, Ray Jui, Rayagonda Kokatanur,
Florian Fainelli
Use SMBUS_MASTER_DATA_READ.MASTER_RD_STATUS bit to check for RX
FIFO empty condition because SMBUS_MASTER_FIFO_CONTROL.MASTER_RX_PKT_COUNT
is not updated for read >= 64 bytes. This fixes the issue when trying to
read from the I2C slave more than 63 bytes.
Fixes: c24b8d574b7c ("i2c: iproc: Extend I2C read up to 255 bytes")
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index 2c7f145..d7fd76b 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -392,16 +392,18 @@ static bool bcm_iproc_i2c_slave_isr(struct bcm_iproc_i2c_dev *iproc_i2c,
static void bcm_iproc_i2c_read_valid_bytes(struct bcm_iproc_i2c_dev *iproc_i2c)
{
struct i2c_msg *msg = iproc_i2c->msg;
+ uint32_t val;
/* Read valid data from RX FIFO */
while (iproc_i2c->rx_bytes < msg->len) {
- if (!((iproc_i2c_rd_reg(iproc_i2c, M_FIFO_CTRL_OFFSET) >> M_FIFO_RX_CNT_SHIFT)
- & M_FIFO_RX_CNT_MASK))
+ val = iproc_i2c_rd_reg(iproc_i2c, M_RX_OFFSET);
+
+ /* rx fifo empty */
+ if (!((val >> M_RX_STATUS_SHIFT) & M_RX_STATUS_MASK))
break;
msg->buf[iproc_i2c->rx_bytes] =
- (iproc_i2c_rd_reg(iproc_i2c, M_RX_OFFSET) >>
- M_RX_DATA_SHIFT) & M_RX_DATA_MASK;
+ (val >> M_RX_DATA_SHIFT) & M_RX_DATA_MASK;
iproc_i2c->rx_bytes++;
}
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: clk: allwinner,sun4i-a10-ccu: Correct path in $id
From: Maxime Ripard @ 2019-07-24 8:26 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Stephen Boyd, Michael Turquette, Chen-Yu Tsai,
linux-clk, linux-arm-kernel
In-Reply-To: <20190723230843.19922-1-robh@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 563 bytes --]
On Tue, Jul 23, 2019 at 05:08:43PM -0600, Rob Herring wrote:
> The path in the schema '$id' value is wrong. Fix it.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Maxime Ripard <maxime.ripard@bootlin.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> I can take this via the DT tree.
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition
From: Maxime Ripard @ 2019-07-24 8:24 UTC (permalink / raw)
To: Sean Young
Cc: Clément Péron, Mauro Carvalho Chehab, Rob Herring,
Mark Rutland, Chen-Yu Tsai, devicetree, linux-kernel, linux-sunxi,
linux-arm-kernel, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20190724053937.4ic5n35xtw2chjdy-3XSxi2G4b3iXFJAUJl40Xg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On Wed, Jul 24, 2019 at 06:39:37AM +0100, Sean Young wrote:
> On Tue, Jul 23, 2019 at 09:04:40AM +0200, Maxime Ripard wrote:
> > Hi Sean,
> >
> > On Tue, Jul 23, 2019 at 07:25:57AM +0100, Sean Young wrote:
> > > On Mon, Jul 15, 2019 at 01:12:45PM +0100, Sean Young wrote:
> > > > On Sun, Jul 14, 2019 at 04:32:22PM +0200, Clément Péron wrote:
> > > > > Hi Sean,
> > > > >
> > > > > You acked the whole v3 series but this patch has been introduced in v5
> > > > > could you ack this one too?
> > > >
> > > > Acked-by: Sean Young <sean-hENCXIMQXOg@public.gmane.org>
> > >
> > > So who's tree should this series go through? It seems mostly device tree.
> > > Alternatively I'm happy to try it get merged via the media tree.
> >
> > Ideally the media bits should go through the media tree, the DT bits
> > will go through arm-soc
> >
> > So you can apply the patches 1-4, 7 and 10, I'll apply the rest.
> >
> > Does that work for you?
>
> Works for me, I'll add them to my next pull request to Mauro.
Applied 5, 6, 8, 9 and 11 to 13.
Thanks!
Maxmie
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190724082459.xsstansjxtyvu4st%40flea.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles
From: Andrew Jeffery @ 2019-07-24 8:13 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, lee.jones, robh+dt, mark.rutland, joel,
linus.walleij, devicetree, linux-arm-kernel, linux-kernel,
linux-gpio
In-Reply-To: <20190724081313.12934-1-andrew@aj.id.au>
Guide readers away from using the aspeed,g[45].* compatible patterns.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 2 --
Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt | 2 --
.../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 5 +----
.../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 4 +---
4 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
index ce8cf0ec6279..4d92c0bb6687 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
+++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
@@ -4,9 +4,7 @@ configuring elements such as clocks, pinmux, and reset.
Required properties:
- compatible: One of:
"aspeed,ast2400-scu", "syscon", "simple-mfd"
- "aspeed,g4-scu", "syscon", "simple-mfd"
"aspeed,ast2500-scu", "syscon", "simple-mfd"
- "aspeed,g5-scu", "syscon", "simple-mfd"
- reg: contains the offset and length of the SCU memory region
- #clock-cells: should be set to <1> - the system controller is also a
diff --git a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
index 854bd67ffec6..0e1fa5bc6a30 100644
--- a/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
+++ b/Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt
@@ -26,9 +26,7 @@ property:
- compatible : Should be one of the following:
"aspeed,ast2400-scu", "syscon", "simple-mfd"
- "aspeed,g4-scu", "syscon", "simple-mfd"
"aspeed,ast2500-scu", "syscon", "simple-mfd"
- "aspeed,g5-scu", "syscon", "simple-mfd"
Example
===================
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
index 125599a2dc5e..9368e4b6d4d0 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
@@ -15,16 +15,13 @@ description: |+
- compatible: Should be one of the following:
"aspeed,ast2400-scu", "syscon", "simple-mfd"
- "aspeed,g4-scu", "syscon", "simple-mfd"
Refer to the the bindings described in
Documentation/devicetree/bindings/mfd/syscon.txt
properties:
compatible:
- enum:
- - aspeed,ast2400-pinctrl
- - aspeed,g4-pinctrl
+ const: aspeed,ast2400-pinctrl
patternProperties:
'^.*$':
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
index 3e6d85318577..939fb755a6db 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
@@ -22,9 +22,7 @@ description: |+
properties:
compatible:
- enum:
- - aspeed,ast2500-pinctrl
- - aspeed,g5-pinctrl
+ const: aspeed,ast2500-pinctrl
aspeed,external-nodes:
minItems: 2
maxItems: 2
--
2.20.1
^ permalink raw reply related
* [PATCH 2/3] pinctrl: aspeed: Document existence of deprecated compatibles
From: Andrew Jeffery @ 2019-07-24 8:13 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, lee.jones, robh+dt, mark.rutland, joel,
linus.walleij, devicetree, linux-arm-kernel, linux-kernel,
linux-gpio
In-Reply-To: <20190724081313.12934-1-andrew@aj.id.au>
Otherwise they look odd in the face of not being listed in the bindings
documents.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 4 ++++
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 384396cbb22d..0e087fe759d2 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -2531,6 +2531,10 @@ static int aspeed_g4_pinctrl_probe(struct platform_device *pdev)
static const struct of_device_id aspeed_g4_pinctrl_of_match[] = {
{ .compatible = "aspeed,ast2400-pinctrl", },
+ /*
+ * The aspeed,g4-pinctrl compatible has been removed the from the
+ * bindings, but keep the match in case of old devicetrees.
+ */
{ .compatible = "aspeed,g4-pinctrl", },
{ },
};
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 053101f795a2..49255802735b 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -2676,6 +2676,10 @@ static int aspeed_g5_pinctrl_probe(struct platform_device *pdev)
static const struct of_device_id aspeed_g5_pinctrl_of_match[] = {
{ .compatible = "aspeed,ast2500-pinctrl", },
+ /*
+ * The aspeed,g5-pinctrl compatible has been removed the from the
+ * bindings, but keep the match in case of old devicetrees.
+ */
{ .compatible = "aspeed,g5-pinctrl", },
{ },
};
--
2.20.1
^ permalink raw reply related
* [PATCH 1/3] dts: ARM: aspeed: Migrate away from aspeed,g[45].* compatibles
From: Andrew Jeffery @ 2019-07-24 8:13 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, lee.jones, robh+dt, mark.rutland, joel,
linus.walleij, devicetree, linux-arm-kernel, linux-kernel,
linux-gpio
In-Reply-To: <20190724081313.12934-1-andrew@aj.id.au>
Use the SoC-specific compatible strings instead.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index dd4b0b15afcf..7f06dc21dc19 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -162,7 +162,7 @@
#reset-cells = <1>;
pinctrl: pinctrl {
- compatible = "aspeed,g4-pinctrl";
+ compatible = "aspeed,ast2400-pinctrl";
};
p2a: p2a-control {
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 5b1ca265c2ce..04c97138e18b 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -215,7 +215,7 @@
#reset-cells = <1>;
pinctrl: pinctrl {
- compatible = "aspeed,g5-pinctrl";
+ compatible = "aspeed,ast2500-pinctrl";
aspeed,external-nodes = <&gfx &lhc>;
};
--
2.20.1
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
From: Andrew Jeffery @ 2019-07-24 8:13 UTC (permalink / raw)
To: linux-aspeed
Cc: Andrew Jeffery, lee.jones, robh+dt, mark.rutland, joel,
linus.walleij, devicetree, linux-arm-kernel, linux-kernel,
linux-gpio
Hello,
Joel and I decided that going forward we're not going to name compatibles along
the lines of SoC generations, so discourage any further attempts by removing
the remaining instances.
It's probably best if we push the three patches all through one tree rather
than fragmenting. Is everyone happy if Joel applies them to the aspeed tree?
Cheers,
Andrew
Andrew Jeffery (3):
dts: ARM: aspeed: Migrate away from aspeed,g[45].* compatibles
pinctrl: aspeed: Document existence of deprecated compatibles
dt-bindings: aspeed: Remove mention of deprecated compatibles
Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 2 --
Documentation/devicetree/bindings/misc/aspeed-p2a-ctrl.txt | 2 --
.../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 5 +----
.../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 4 +---
arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 4 ++++
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 4 ++++
8 files changed, 12 insertions(+), 13 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 2/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 devicetree bindings
From: Stefan Riedmueller @ 2019-07-24 7:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, linux-kernel,
devicetree, Fabio Estevam, Andrew Smirnov, Manivannan Sadhasivam,
linux-imx, Stefan Riedmueller
In-Reply-To: <1563954573-370205-1-git-send-email-s.riedmueller@phytec.de>
Add devicetree bindings for i.MX6 based phyCORE-i.MX6, phyBOARD-Mira and
phyFLEX-i.MX6.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 40f007859092..00a037cf5c86 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -112,6 +112,13 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
+ - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - phytec,imx6q-pbab01 # PHYTEC phyFLEX carrier board
+ - phytec,imx6q-pbab01-nand # PHYTEC phyFLEX eval Kit
+ - phytec,imx6q-pbac06 # PHYTEC phyBOARD-Mira with i.MX6 Quad
+ - phytec,imx6q-pbac06-emmc # PHYTEC phyBOARD-Mira eMMC RDK
+ - phytec,imx6q-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
+ - phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- const: fsl,imx6q
@@ -121,6 +128,9 @@ properties:
- enum:
- fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board
- fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board
+ - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - phytec,imx6qp-pbac06 # PHYTEC phyBOARD-Mira with i.MX6 QuadPlus
+ - phytec,imx6qp-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
- const: fsl,imx6qp
- description: i.MX6DL based Boards
@@ -131,6 +141,13 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
+ - phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6
+ - phytec,imx6dl-pbab01 # PHYTEC phyFLEX carrier board
+ - phytec,imx6dl-pbab01-nand # PHYTEC phyFLEX eval Kit
+ - phytec,imx6dl-pbac06 # PHYTEC phyBOARD-Mira with i.MX6 DL
+ - phytec,imx6dl-pbac06-emmc # PHYTEC phyBOARD-Mira eMMC RDK
+ - phytec,imx6dl-pbac06-nand # PHYTEC phyBOARD-Mira NAND RDK
+ - phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 DL
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: arm: fsl: Add PHYTEC i.MX6 UL/ULL devicetree bindings
From: Stefan Riedmueller @ 2019-07-24 7:49 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, linux-kernel,
devicetree, Fabio Estevam, Andrew Smirnov, Manivannan Sadhasivam,
linux-imx, Stefan Riedmueller
Add devicetree bindings for i.MX6 UL/ULL based phyCORE-i.MX6 UL/ULL and
phyBOARD-Segin.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..40f007859092 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,12 +161,20 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
+ - phytec,imx6ul-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 UL
+ - phytec,imx6ul-pbacd10-emmc # PHYTEC phyBOARD-Segin eMMC Kit
+ - phytec,imx6ul-pbacd10-nand # PHYTEC phyBOARD-Segin NAND Kit
+ - phytec,imx6ul-pcl063 # PHYTEC phyCORE-i.MX 6UL
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
items:
- enum:
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
+ - phytec,imx6ull-pbacd10 # PHYTEC phyBOARD-Segin with i.MX6 ULL
+ - phytec,imx6ull-pbacd10-emmc # PHYTEC phyBOARD-Segin eMMC Kit
+ - phytec,imx6ull-pbacd10-nand # PHYTEC phyBOARD-Segin NAND Kit
+ - phytec,imx6ull-pcl063 # PHYTEC phyCORE-i.MX 6ULL
- const: fsl,imx6ull
- description: i.MX6ULZ based Boards
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/3] soc: fsl: add RCPM driver
From: Ran Wang @ 2019-07-24 7:47 UTC (permalink / raw)
To: Li Yang, Rob Herring, Mark Rutland, Pavel Machek
Cc: Rafael J . Wysocki, Li Biwen, Len Brown, Greg Kroah-Hartman,
linuxppc-dev, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, Ran Wang
In-Reply-To: <20190724074722.12270-1-ran.wang_1@nxp.com>
The NXP's QorIQ Processors based on ARM Core have RCPM module
(Run Control and Power Management), which performs all device-level
tasks associated with power management such as wakeup source control.
This driver depends on PM wakeup source framework which help to
collect wake information.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
Change in v5:
- Fix v4 regression of the return value of wakeup_source_get_next()
didn't pass to ws in while loop.
- Rename wakeup_source member 'attached_dev' to 'dev'.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/
Change in v4:
- Remove extra ',' in author line of rcpm.c
- Update usage of wakeup_source_get_next() to be less confusing to the
reader, code logic remain the same.
Change in v3:
- Some whitespace ajdustment.
Change in v2:
- Rebase Kconfig and Makefile update to latest mainline.
drivers/soc/fsl/Kconfig | 8 +++
drivers/soc/fsl/Makefile | 1 +
drivers/soc/fsl/rcpm.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 135 insertions(+)
create mode 100644 drivers/soc/fsl/rcpm.c
diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
index f9ad8ad..4918856 100644
--- a/drivers/soc/fsl/Kconfig
+++ b/drivers/soc/fsl/Kconfig
@@ -40,4 +40,12 @@ config DPAA2_CONSOLE
/dev/dpaa2_mc_console and /dev/dpaa2_aiop_console,
which can be used to dump the Management Complex and AIOP
firmware logs.
+
+config FSL_RCPM
+ bool "Freescale RCPM support"
+ depends on PM_SLEEP
+ help
+ The NXP QorIQ Processors based on ARM Core have RCPM module
+ (Run Control and Power Management), which performs all device-level
+ tasks associated with power management, such as wakeup source control.
endmenu
diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
index 71dee8d..906f1cd 100644
--- a/drivers/soc/fsl/Makefile
+++ b/drivers/soc/fsl/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FSL_DPAA) += qbman/
obj-$(CONFIG_QUICC_ENGINE) += qe/
obj-$(CONFIG_CPM) += qe/
+obj-$(CONFIG_FSL_RCPM) += rcpm.o
obj-$(CONFIG_FSL_GUTS) += guts.o
obj-$(CONFIG_FSL_MC_DPIO) += dpio/
obj-$(CONFIG_DPAA2_CONSOLE) += dpaa2-console.o
diff --git a/drivers/soc/fsl/rcpm.c b/drivers/soc/fsl/rcpm.c
new file mode 100644
index 0000000..02244a1
--- /dev/null
+++ b/drivers/soc/fsl/rcpm.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// rcpm.c - Freescale QorIQ RCPM driver
+//
+// Copyright 2019 NXP
+//
+// Author: Ran Wang <ran.wang_1@nxp.com>
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_address.h>
+#include <linux/slab.h>
+#include <linux/suspend.h>
+#include <linux/kernel.h>
+
+#define RCPM_WAKEUP_CELL_MAX_SIZE 7
+
+struct rcpm {
+ unsigned int wakeup_cells;
+ void __iomem *ippdexpcr_base;
+ bool little_endian;
+};
+
+static int rcpm_pm_prepare(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct wakeup_source *ws;
+ struct rcpm *rcpm;
+ u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
+ int i, ret;
+
+ rcpm = dev_get_drvdata(dev);
+ if (!rcpm)
+ return -EINVAL;
+
+ /* Begin with first registered wakeup source */
+ ws = NULL;
+ while (ws = wakeup_source_get_next(ws)) {
+ /* skip object which is not attached to device */
+ if (!ws->dev)
+ continue;
+
+ ret = device_property_read_u32_array(ws->dev,
+ "fsl,rcpm-wakeup", value, rcpm->wakeup_cells + 1);
+
+ /* Wakeup source should refer to current rcpm device */
+ if (ret || (np->phandle != value[0])) {
+ dev_info(dev, "%s doesn't refer to this rcpm\n",
+ ws->name);
+ continue;
+ }
+
+ for (i = 0; i < rcpm->wakeup_cells; i++) {
+ /* We can only OR related bits */
+ if (value[i + 1]) {
+ if (rcpm->little_endian) {
+ tmp = ioread32(rcpm->ippdexpcr_base + i * 4);
+ tmp |= value[i + 1];
+ iowrite32(tmp, rcpm->ippdexpcr_base + i * 4);
+ } else {
+ tmp = ioread32be(rcpm->ippdexpcr_base + i * 4);
+ tmp |= value[i + 1];
+ iowrite32be(tmp, rcpm->ippdexpcr_base + i * 4);
+ }
+ }
+ }
+ }
+
+ return 0;
+}
+
+static const struct dev_pm_ops rcpm_pm_ops = {
+ .prepare = rcpm_pm_prepare,
+};
+
+static int rcpm_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct resource *r;
+ struct rcpm *rcpm;
+ int ret;
+
+ rcpm = devm_kzalloc(dev, sizeof(*rcpm), GFP_KERNEL);
+ if (!rcpm)
+ return -ENOMEM;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r)
+ return -ENODEV;
+
+ rcpm->ippdexpcr_base = devm_ioremap_resource(&pdev->dev, r);
+ if (IS_ERR(rcpm->ippdexpcr_base)) {
+ ret = PTR_ERR(rcpm->ippdexpcr_base);
+ return ret;
+ }
+
+ rcpm->little_endian = device_property_read_bool(
+ &pdev->dev, "little-endian");
+
+ ret = device_property_read_u32(&pdev->dev,
+ "#fsl,rcpm-wakeup-cells", &rcpm->wakeup_cells);
+ if (ret)
+ return ret;
+
+ dev_set_drvdata(&pdev->dev, rcpm);
+
+ return 0;
+}
+
+static const struct of_device_id rcpm_of_match[] = {
+ { .compatible = "fsl,qoriq-rcpm-2.1+", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, rcpm_of_match);
+
+static struct platform_driver rcpm_driver = {
+ .driver = {
+ .name = "rcpm",
+ .of_match_table = rcpm_of_match,
+ .pm = &rcpm_pm_ops,
+ },
+ .probe = rcpm_probe,
+};
+
+module_platform_driver(rcpm_driver);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/3] Documentation: dt: binding: fsl: Add 'little-endian' and update Chassis define
From: Ran Wang @ 2019-07-24 7:47 UTC (permalink / raw)
To: Li Yang, Rob Herring, Mark Rutland, Pavel Machek
Cc: Rafael J . Wysocki, Li Biwen, Len Brown, Greg Kroah-Hartman,
linuxppc-dev, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, Ran Wang
In-Reply-To: <20190724074722.12270-1-ran.wang_1@nxp.com>
By default, QorIQ SoC's RCPM register block is Big Endian. But
there are some exceptions, such as LS1088A and LS2088A, are Little
Endian. So add this optional property to help identify them.
Actually LS2021A and other Layerscapes won't totally follow Chassis
2.1, so separate them from powerpc SoC.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Change in v5:
- Add 'Reviewed-by: Rob Herring <robh@kernel.org>' to commit message.
- Rename property 'fsl,#rcpm-wakeup-cells' to '#fsl,rcpm-wakeup-cells'.
please see https://lore.kernel.org/patchwork/patch/1101022/
Change in v4:
- Adjust indectation of 'ls1021a, ls1012a, ls1043a, ls1046a'.
Change in v3:
- None.
Change in v2:
- None.
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
index e284e4e..5a33619 100644
--- a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -5,7 +5,7 @@ and power management.
Required properites:
- reg : Offset and length of the register set of the RCPM block.
- - fsl,#rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
+ - #fsl,rcpm-wakeup-cells : The number of IPPDEXPCR register cells in the
fsl,rcpm-wakeup property.
- compatible : Must contain a chip-specific RCPM block compatible string
and (if applicable) may contain a chassis-version RCPM compatible
@@ -20,6 +20,7 @@ Required properites:
* "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
* "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
* "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
+ * "fsl,qoriq-rcpm-2.1+": for chassis 2.1+ rcpm
All references to "1.0" and "2.0" refer to the QorIQ chassis version to
which the chip complies.
@@ -27,14 +28,19 @@ Chassis Version Example Chips
--------------- -------------------------------
1.0 p4080, p5020, p5040, p2041, p3041
2.0 t4240, b4860, b4420
-2.1 t1040, ls1021
+2.1 t1040,
+2.1+ ls1021a, ls1012a, ls1043a, ls1046a
+
+Optional properties:
+ - little-endian : RCPM register block is Little Endian. Without it RCPM
+ will be Big Endian (default case).
Example:
The RCPM node for T4240:
rcpm: global-utilities@e2000 {
compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
reg = <0xe2000 0x1000>;
- fsl,#rcpm-wakeup-cells = <2>;
+ #fsl,rcpm-wakeup-cells = <2>;
};
* Freescale RCPM Wakeup Source Device Tree Bindings
@@ -44,7 +50,7 @@ can be used as a wakeup source.
- fsl,rcpm-wakeup: Consists of a phandle to the rcpm node and the IPPDEXPCR
register cells. The number of IPPDEXPCR register cells is defined in
- "fsl,#rcpm-wakeup-cells" in the rcpm node. The first register cell is
+ "#fsl,rcpm-wakeup-cells" in the rcpm node. The first register cell is
the bit mask that should be set in IPPDEXPCR0, and the second register
cell is for IPPDEXPCR1, and so on.
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-07-24 7:47 UTC (permalink / raw)
To: Li Yang, Rob Herring, Mark Rutland, Pavel Machek
Cc: Rafael J . Wysocki, Li Biwen, Len Brown, Greg Kroah-Hartman,
linuxppc-dev, linux-arm-kernel, devicetree, linux-kernel,
linux-pm, Ran Wang
Some user might want to go through all registered wakeup sources
and doing things accordingly. For example, SoC PM driver might need to
do HW programming to prevent powering down specific IP which wakeup
source depending on. So add this API to help walk through all registered
wakeup source objects on that list and return them one by one.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v5:
- Update commit message, add decription of walk through all wakeup
source objects.
- Add SCU protection in function wakeup_source_get_next().
- Rename wakeup_source member 'attached_dev' to 'dev' and move it up
(before wakeirq).
Change in v4:
- None.
Change in v3:
- Adjust indentation of *attached_dev;.
Change in v2:
- None.
drivers/base/power/wakeup.c | 24 ++++++++++++++++++++++++
include/linux/pm_wakeup.h | 3 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index ee31d4f..2fba891 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -14,6 +14,7 @@
#include <linux/suspend.h>
#include <linux/seq_file.h>
#include <linux/debugfs.h>
+#include <linux/of_device.h>
#include <linux/pm_wakeirq.h>
#include <trace/events/power.h>
@@ -226,6 +227,28 @@ void wakeup_source_unregister(struct wakeup_source *ws)
}
}
EXPORT_SYMBOL_GPL(wakeup_source_unregister);
+/**
+ * wakeup_source_get_next - Get next wakeup source from the list
+ * @ws: Previous wakeup source object, null means caller want first one.
+ */
+struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws)
+{
+ struct list_head *ws_head = &wakeup_sources;
+ struct wakeup_source *next_ws = NULL;
+ int idx;
+
+ idx = srcu_read_lock(&wakeup_srcu);
+ if (ws)
+ next_ws = list_next_or_null_rcu(ws_head, &ws->entry,
+ struct wakeup_source, entry);
+ else
+ next_ws = list_entry_rcu(ws_head->next,
+ struct wakeup_source, entry);
+ srcu_read_unlock(&wakeup_srcu, idx);
+
+ return next_ws;
+}
+EXPORT_SYMBOL_GPL(wakeup_source_get_next);
/**
* device_wakeup_attach - Attach a wakeup source object to a device object.
@@ -242,6 +265,7 @@ static int device_wakeup_attach(struct device *dev, struct wakeup_source *ws)
return -EEXIST;
}
dev->power.wakeup = ws;
+ ws->dev = dev;
if (dev->power.wakeirq)
device_wakeup_attach_irq(dev, dev->power.wakeirq);
spin_unlock_irq(&dev->power.lock);
diff --git a/include/linux/pm_wakeup.h b/include/linux/pm_wakeup.h
index 9102760..fc23c1a 100644
--- a/include/linux/pm_wakeup.h
+++ b/include/linux/pm_wakeup.h
@@ -23,6 +23,7 @@ struct wake_irq;
* @name: Name of the wakeup source
* @entry: Wakeup source list entry
* @lock: Wakeup source lock
+ * @dev: The device it attached to
* @wakeirq: Optional device specific wakeirq
* @timer: Wakeup timer list
* @timer_expires: Wakeup timer expiration
@@ -42,6 +43,7 @@ struct wakeup_source {
const char *name;
struct list_head entry;
spinlock_t lock;
+ struct device *dev;
struct wake_irq *wakeirq;
struct timer_list timer;
unsigned long timer_expires;
@@ -88,6 +90,7 @@ extern void wakeup_source_add(struct wakeup_source *ws);
extern void wakeup_source_remove(struct wakeup_source *ws);
extern struct wakeup_source *wakeup_source_register(const char *name);
extern void wakeup_source_unregister(struct wakeup_source *ws);
+extern struct wakeup_source *wakeup_source_get_next(struct wakeup_source *ws);
extern int device_wakeup_enable(struct device *dev);
extern int device_wakeup_disable(struct device *dev);
extern void device_set_wakeup_capable(struct device *dev, bool capable);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Petr Mladek @ 2019-07-24 7:31 UTC (permalink / raw)
To: Stephen Boyd
Cc: Brendan Higgins, Jeff Dike, Kevin Hilman, Logan Gunthorpe,
Michael Ellerman, Daniel Vetter, Amir Goldstein, Frank Rowand,
Steven Rostedt, Kees Cook, David Rientjes, kunit-dev,
Kieran Bingham, Peter Zijlstra, Randy Dunlap, Joel Stanley,
Luis Chamberlain, Rob Herring, shuah, wfg, Greg KH
In-Reply-To: <20190722235411.06C1320840@mail.kernel.org>
On Mon 2019-07-22 16:54:10, Stephen Boyd wrote:
> Quoting Brendan Higgins (2019-07-22 15:30:49)
> > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > >
> > >
> > > What's the calling context of the assertions and expectations? I still
> > > don't like the fact that string stream needs to allocate buffers and
> > > throw them into a list somewhere because the calling context matters
> > > there.
> >
> > The calling context is the same as before, which is anywhere.
>
> Ok. That's concerning then.
>
> >
> > > I'd prefer we just wrote directly to the console/log via printk
> > > instead. That way things are simple because we use the existing
> > > buffering path of printk, but maybe there's some benefit to the string
> > > stream that I don't see? Right now it looks like it builds a string and
> > > then dumps it to printk so I'm sort of lost what the benefit is over
> > > just writing directly with printk.
> >
> > It's just buffering it so the whole string gets printed uninterrupted.
> > If we were to print out piecemeal to printk, couldn't we have another
> > call to printk come in causing it to garble the KUnit message we are
> > in the middle of printing?
>
> Yes, printing piecemeal by calling printk many times could lead to
> interleaving of messages if something else comes in such as an interrupt
> printing something. Printk has some support to hold "records" but I'm
> not sure how that would work here because KERN_CONT talks about only
> being used early on in boot code. I haven't looked at printk in detail
> though so maybe I'm all wrong and KERN_CONT just works?
KERN_CONT does not guarantee that the message will get printed
together. The pieces get interleaved with messages printed in
parallel.
Note that KERN_CONT was originally really meant to be used only during
boot. It was later used more widely and ended in the best effort category.
There were several attempts to make it more reliable. But it was
always either too complicated or error prone or both.
You need to use your own buffering if you rely want perfect output.
The question is if it is really worth the complexity. Also note that
any buffering reduces the chance that the messages will reach
the console.
BTW: There is a work in progress on a lockless printk ring buffer.
It will make printk() more secure regarding deadlocks. But it might
make transparent handling of continuous lines even more tricky.
I guess that local buffering, before calling printk(), will be
even more important then. Well, it might really force us to create
an API for it.
> Can printk be called once with whatever is in the struct? Otherwise if
> this is about making printk into a structured log then maybe printk
> isn't the proper solution anyway. Maybe a dev interface should be used
> instead that can handle starting and stopping tests (via ioctl) in
> addition to reading test results, records, etc. with read() and a
> clearing of the records. Then the seqfile API works naturally. All of
> this is a bit premature, but it looks like you're going down the path of
> making something akin to ftrace that stores binary formatted
> assertion/expectation records in a lockless ring buffer that then
> formats those records when the user asks for them.
IMHO, ftrace postpones the text formatting primary because it does not
not want to slow down the traced code more than necessary. It is yet
another layer and there should be some strong reason for it.
> I can imagine someone wanting to write unit tests that check conditions
> from a simulated hardirq context via irq works (a driver mock
> framework?), so this doesn't seem far off.
Note that stroring the messages into the printk log is basically safe in any
context. It uses temporary per-CPU buffers for recursive messages and
in NMI. The only problem is panic() when some CPU gets stuck with the
lock taken. This will get solved by the lockless ringbuffer. Also
the temporary buffers will not be necessary any longer.
Much bigger problems are with consoles. There are many of them. It
means a lot of code and more locks involved, including scheduler
locks. Note that console lock is a semaphore.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v3 6/6] interconnect: Add OPP table support for interconnects
From: Vincent Guittot @ 2019-07-24 7:16 UTC (permalink / raw)
To: Saravana Kannan
Cc: Georgi Djakov, Rob Herring, Mark Rutland, Viresh Kumar,
Nishanth Menon, Stephen Boyd, Rafael J. Wysocki, Sweeney, Sean,
daidavid1, Rajendra Nayak, sibis, Bjorn Andersson, Evan Green,
Android Kernel Team, open list:THERMAL,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel
In-Reply-To: <CAGETcx_w=yVDiwVWT1+mmoj54FuLC37Eh2E-s0BfrtEa0AqEjw@mail.gmail.com>
On Tue, 16 Jul 2019 at 02:56, Saravana Kannan <saravanak@google.com> wrote:
>
> On Mon, Jul 15, 2019 at 1:16 AM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
> >
> > On Tue, 9 Jul 2019 at 21:03, Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Tue, Jul 9, 2019 at 12:25 AM Vincent Guittot
> > > <vincent.guittot@linaro.org> wrote:
> > > >
> > > > On Sun, 7 Jul 2019 at 23:48, Saravana Kannan <saravanak@google.com> wrote:
> > > > >
> > > > > On Thu, Jul 4, 2019 at 12:12 AM Vincent Guittot
> > > > > <vincent.guittot@linaro.org> wrote:
> > > > > >
> > > > > > On Wed, 3 Jul 2019 at 23:33, Saravana Kannan <saravanak@google.com> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 2, 2019 at 11:45 PM Vincent Guittot
> > > > > > > <vincent.guittot@linaro.org> wrote:
> > > > > > > >
> > > > > > > > On Wed, 3 Jul 2019 at 03:10, Saravana Kannan <saravanak@google.com> wrote:
> > > > > > > > >
> > > > > > > > > Interconnect paths can have different performance points. Now that OPP
> > > > > > > > > framework supports bandwidth OPP tables, add OPP table support for
> > > > > > > > > interconnects.
> > > > > > > > >
> > > > > > > > > Devices can use the interconnect-opp-table DT property to specify OPP
> > > > > > > > > tables for interconnect paths. And the driver can obtain the OPP table for
> > > > > > > > > an interconnect path by calling icc_get_opp_table().
> > > > > > > >
> > > > > > > > The opp table of a path must come from the aggregation of OPP tables
> > > > > > > > of the interconnect providers.
> > > > > > >
> > > > > > > The aggregation of OPP tables of the providers is certainly the
> > > > > > > superset of what a path can achieve, but to say that OPPs for
> > > > > > > interconnect path should match that superset is an oversimplification
> > > > > > > of the reality in hardware.
> > > > > > >
> > > > > > > There are lots of reasons an interconnect path might not want to use
> > > > > > > all the available bandwidth options across all the interconnects in
> > > > > > > the route.
> > > > > > >
> > > > > > > 1. That particular path might not have been validated or verified
> > > > > > > during the HW design process for some of the frequencies/bandwidth
> > > > > > > combinations of the providers.
> > > > > >
> > > > > > All these constraint are provider's constraints and not consumer's one
> > > > > >
> > > > > > The consumer asks for a bandwidth according to its needs and then the
> > > > > > providers select the optimal bandwidth of each interconnect after
> > > > > > aggregating all the request and according to what OPP have been
> > > > > > validated
> > > > >
> > > > > Not really. The screening can be a consumer specific issue. The
> > > > > consumer IP itself might have some issue with using too low of a
> > > > > bandwidth or bandwidth that's not within some range. It should not be
> > > >
> > > > How can an IP ask for not enough bandwidth ?
> > > > It asks the needed bandwidth based on its requirements
> > >
> > > The "enough bandwidth" is not always obvious. It's only for very
> > > simple cases that you can calculate the required bandwidth. Even for
> > > cases that you think might be "obvious/easy" aren't always easy.
> > >
> > > For example, you'd think a display IP would have a fixed bandwidth
> > > requirement for a fixed resolution screen. But that's far from the
> > > truth. It can also change as the number of layers change per frame.
> > > For video decoder/encoder, it depends on how well the frames compress
> > > with a specific compression scheme.
> > > So the "required" bandwidth is often a heuristic based on the IP
> > > frequency or traffic measurement.
> > >
> > > But that's not even the point I was making in this specific "bullet".
> > >
> > > A hardware IP might be screen/verified with only certain bandwidth
> > > levels. Or it might have hardware bugs that prevent it from using
> > > lower bandwidths even though it's technically sufficient. We need a
> > > way to capture that per path. This is not even a fictional case. This
> > > has been true multiple times over widely used IPs.
> >
> > here you are mixing HW constraint on the soc and OPP screening with
> > bandwidth request from consumer
> > ICC framework is about getting bandwidth request not trying to fix
> > some HW/voltage dependency of the SoC
> >
> > >
> > > > > the provider's job to take into account all the IP that might be
> > > > > connected to the interconnects. If the interconnect HW itself didn't
> > > >
> > > > That's not what I'm saying. The provider knows which bandwidth the
> > > > interconnect can provide as it is the ones which configures it. So if
> > > > the interconnect has a finite number of bandwidth point based probably
> > > > on the possible clock frequency and others config of the interconnect,
> > > > it selects the best final config after aggregating the request of the
> > > > consumer.
> > >
> > > I completely agree with this. What you are stating above is how it
> > > should work and that's the whole point of the interconnect framework.
> > >
> > > But this is orthogonal to the point I'm making.
> >
> > It's not orthogonal because you want to add a OPP table pointer in the
> > ICC path structure to fix your platform HW constraint whereas it's not
> > the purpose of the framework IMO
> >
> > >
> > > > > change, the provider driver shouldn't need to change. By your
> > > > > definition, a provider driver will have to account for all the
> > > > > possible bus masters that might be connected to it across all SoCs.
> > > >
> > > > you didn't catch my point
> > >
> > > Same. I think we are talking over each other. Let me try again.
> > >
> > > You are trying to describe how and interconnect provider and framework
> > > should work. There's no disagreement there.
> > >
> > > My point is that consumers might not want to or can not always use all
> > > the available bandwidth levels offered by the providers. There can be
> > > many reasons for that (which is what I listed in my earlier emails)
> > > and we need a good and generic way to capture that so that everyone
> > > isn't trying to invent their own property.
> >
> > And my point is that you want to describe some platform or even UCs
> > specific constraint in the ICC framework which is not the place to do.
> >
> > If the consumers might not want to use all available bandwidth because
> > this is not power efficient as an example, this should be describe
> > somewhere else to express that there is a shared power domain
> > between some devices and we shoudl ensure that all devices in this
> > power domain should use the Optimal Operating Point (optimal freq for
> > a voltage)
>
> My patch series has nothing to do with shared power domains. I think
> the examples have made it amply clear.
It's far from being clear why a consumer doesn't want to use some
bandwidth level TBH
Do you have a real example ?
>
> > ICC framework describes the bandwidth request that are expressed by
> > the consumers for the current running state of their IP but it doesn't
> > reflect the fact that on platform A, the consumer should use bandwidth
> > X because it will select a voltage level of a shared power domain that
> > is optimized for the other devices B, C ... . It's up to the provider
> > to know HW details of the bus that it drives and to make such
> > decision; the consumer should always request the same
>
> The change to ICC framework is practically just this. I don't have any
> future changes planned for the ICC framework. This is the entirety of
> it.
>
> + opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
> + if (opp_node) {
> + path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
> + of_node_put(opp_node);
> + }
>
> It's quite a stretch and bit hyperbolic to say this one change is
> getting ICC framework to do all the things you claim above.
>
So I clearly don't see the benefit of adding this opp_table field in
icc_path struct because I'm still convinced that the consumer doesn't
have to get a bandwidth table like that.
If the consumer already get a bandwidth value and it should in order
to call icc_set or even in order to select one element in your table,
then it should directly set it with icc_set and let the provider
aggregate and choose the real one
> It's literally a simple helper function so that the consumer doesn't
> have to make assumptions about indices and it's a bit more explicit
> about which OPP table of the device (a device can have multiple OPP
> tables) corresponds to which ICC path.
>
> Going by your extreme argument, one can also claim that it's not the
> ICC framework's job to make it easy for consumers to figure out the
> source/destination endpoints or give them names and delete the
> interconnect and interconnect-names properties. That's clearly just as
> absurd a claim.
>
>
> -Saravana
>
> > > > > That's not good design nor is it scalable.
> > > > >
> > > > > > >
> > > > > > > 2. Similarly during parts screening in the factory, some of the
> > > > > > > combinations might not have been screened and can't be guaranteed
> > > > > > > to work.
> > > > > >
> > > > > > As above, it's the provider's job to select the final bandwidth
> > > > > > according to its constraint
> > > > >
> > > > > Same reply as above.
> > > > >
> > > > > > >
> > > > > > > 3. Only a certain set of bandwidth levels might make sense to use from
> > > > > > > a power/performance balance given the device using it. For example:
> > > > > > > - The big CPU might not want to use some of the lower bandwidths
> > > > > > > but the little CPU might want to.
> > > > > > > - The big CPU might not want to use some intermediate bandwidth
> > > > > > > points if they don't save a lot of power compared to a higher
> > > > > > > bandwidth levels, but the little CPU might want to.
> > > > > > > - The little CPU might never want to use the higher set of
> > > > > > > bandwidth levels since they won't be power efficient for the use
> > > > > > > cases that might run on it.
> > > > > >
> > > > > > These example are quite vague about the reasons why little might never
> > > > > > want to use higher bandwidth.
> > > > >
> > > > > How is it vague? I just said because of power/performance balance.
> > > > >
> > > > > > But then, if little doesn't ask high bandwidth it will not use them.
> > > > >
> > > > > If you are running a heuristics based algorithm to pick bandwidth,
> > > > > this is how it'll know NOT to use some of the bandwidth levels.
> > > >
> > > > so you want to set a bandwidth according to the cpu frequency which is
> > > > what has been proposed in other thread
> > >
> > > Nope, that's just one heuristic. Often times it's based on hardware
> > > monitors measuring interconnect activity. If you go look at the SDM845
> > > in a Pixel 3, almost nothing is directly tied to the CPU frequency.
> > >
> > > Even if you are scaling bandwidth based on other hardware
> > > measurements, you might want to avoid some bandwidth level provided by
> > > the interconnect providers because it's suboptimal.
> > >
> > > For example, when making bandwidth votes to accommodate the big CPUs,
> > > you might never want to use some of the lower bandwidth levels because
> > > they are not power efficient for any CPU frequency or any bandwidth
> > > level. Because at those levels the memory/interconnect is so slow that
> > > it has a non-trivial utilization increase (because the CPU is
> > > stalling) of the big CPUs.
> > >
> > > Again, this is completely different from what the providers/icc
> > > framework does. Which is, once the request is made, they aggregate and
> > > set the actual interconnect frequencies correctly.
> > >
> > > > >
> > > > > > >
> > > > > > > 4. It might not make sense from a system level power perspective.
> > > > > > > Let's take an example of a path S (source) -> A -> B -> C -> D
> > > > > > > (destination).
> > > > > > > - A supports only 2, 5, 7 and 10 GB/s. B supports 1, 2 ... 10 GB/s.
> > > > > > > C supports 5 and 10 GB/s
> > > > > > > - If you combine and list the superset of bandwidth levels
> > > > > > > supported in that path, that'd be 1, 2, 3, ... 10 GB/s.
> > > > > > > - Which set of bandwidth levels make sense will depend on the
> > > > > > > hardware characteristics of the interconnects.
> > > > > > > - If B is the biggest power sink, then you might want to use all 10
> > > > > > > levels.
> > > > > > > - If A is the biggest power sink, then you might want to use all 2,
> > > > > > > 5 and 10 GB/s of the levels.
> > > > > > > - If C is the biggest power sink then you might only want to use 5
> > > > > > > and 10 GB/s
> > > > > > > - The more hops and paths you get the more convoluted this gets.
> > > > > > >
> > > > > > > 5. The design of the interconnects themselves might have an impact on
> > > > > > > which bandwidth levels are used.
> > > > > > > - For example, the FIFO depth between two specific interconnects
> > > > > > > might affect the valid bandwidth levels for a specific path.
> > > > > > > - Say S1 -> A -> B -> D1, S2 -> C -> B -> D1 and S2 -> C -> D2 are
> > > > > > > three paths.
> > > > > > > - If C <-> B FIFO depth is small, then there might be a requirement
> > > > > > > that C and B be closely performance matched to avoid system level
> > > > > > > congestion due to back pressure.
> > > > > > > - So S2 -> D1 path can't use all the bandwidth levels supported by
> > > > > > > C-B combination.
> > > > > > > - But S2 -> D2 can use all the bandwidth levels supported by C.
> > > > > > > - And S1 -> D1 can use all the levels supported by A-B combination.
> > > > > > >
> > > > > >
> > > > > > All the examples above makes sense but have to be handle by the
> > > > > > provider not the consumer. The consumer asks for a bandwidth according
> > > > > > to its constraints. Then the provider which is the driver that manages
> > > > > > the interconnect IP, should manage all this hardware and platform
> > > > > > specific stuff related to the interconnect IP in order to set the
> > > > > > optimal bandwidth that fit both consumer constraint and platform
> > > > > > specific configuration.
> > > > >
> > > > > Sure, but the provider itself can have interconnect properties to
> > > > > indicate which other interconnects it's tied to. And the provider will
> > > > > still need the interconnect-opp-table to denote which bandwidth levels
> > > > > are sensible to use with each of its connections.
> > >
> > > You seem to have missed this comment.
> > >
> > > Thanks,
> > > Saravana
> > >
> > > > > So in some instances the interconnect-opp-table covers the needs of
> > > > > purely consumers and in some instances purely providers. But in either
> > > > > case, it's still needed to describe the hardware properly.
> > > > >
> > > > > -Saravana
> > > > >
> > > > > > > These are just some of the reasons I could recollect in a few minutes.
> > > > > > > These are all real world cases I had to deal with in the past several
> > > > > > > years of dealing with scaling interconnects. I'm sure vendors and SoCs
> > > > > > > I'm not familiar with have other good reasons I'm not aware of.
> > > > > > >
> > > > > > > Trying to figure this all out by aggregating OPP tables of
> > > > > > > interconnect providers just isn't feasible nor is it efficient. The
> > > > > > > OPP tables for an interconnect path is describing the valid BW levels
> > > > > > > supported by that path and verified in hardware and makes a lot of
> > > > > > > sense to capture it clearly in DT.
> > > > > > >
> > > > > > > > So such kind of OPP table should be at
> > > > > > > > provider level but not at path level.
> > > > > > >
> > > > > > > They can also use it if they want to, but they'll probably want to use
> > > > > > > a frequency OPP table.
> > > > > > >
> > > > > > >
> > > > > > > -Saravana
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Signed-off-by: Saravana Kannan <saravanak@google.com>
> > > > > > > > > ---
> > > > > > > > > drivers/interconnect/core.c | 27 ++++++++++++++++++++++++++-
> > > > > > > > > include/linux/interconnect.h | 7 +++++++
> > > > > > > > > 2 files changed, 33 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> > > > > > > > > index 871eb4bc4efc..881bac80bc1e 100644
> > > > > > > > > --- a/drivers/interconnect/core.c
> > > > > > > > > +++ b/drivers/interconnect/core.c
> > > > > > > > > @@ -47,6 +47,7 @@ struct icc_req {
> > > > > > > > > */
> > > > > > > > > struct icc_path {
> > > > > > > > > size_t num_nodes;
> > > > > > > > > + struct opp_table *opp_table;
> > > > > > > > > struct icc_req reqs[];
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > @@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > > > > > {
> > > > > > > > > struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> > > > > > > > > struct icc_node *src_node, *dst_node;
> > > > > > > > > - struct device_node *np = NULL;
> > > > > > > > > + struct device_node *np = NULL, *opp_node;
> > > > > > > > > struct of_phandle_args src_args, dst_args;
> > > > > > > > > int idx = 0;
> > > > > > > > > int ret;
> > > > > > > > > @@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
> > > > > > > > > dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
> > > > > > > > > mutex_unlock(&icc_lock);
> > > > > > > > >
> > > > > > > > > + opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
> > > > > > > > > + if (opp_node) {
> > > > > > > > > + path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
> > > > > > > > > + of_node_put(opp_node);
> > > > > > > > > + }
> > > > > > > > > +
> > > > > > > > > +
> > > > > > > > > return path;
> > > > > > > > > }
> > > > > > > > > EXPORT_SYMBOL_GPL(of_icc_get);
> > > > > > > > >
> > > > > > > > > +/**
> > > > > > > > > + * icc_get_opp_table() - Get the OPP table that corresponds to a path
> > > > > > > > > + * @path: reference to the path returned by icc_get()
> > > > > > > > > + *
> > > > > > > > > + * This function will return the OPP table that corresponds to a path handle.
> > > > > > > > > + * If the interconnect API is disabled, NULL is returned and the consumer
> > > > > > > > > + * drivers will still build. Drivers are free to handle this specifically, but
> > > > > > > > > + * they don't have to.
> > > > > > > > > + *
> > > > > > > > > + * Return: opp_table pointer on success. NULL is returned when the API is
> > > > > > > > > + * disabled or the OPP table is missing.
> > > > > > > > > + */
> > > > > > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > > > > > +{
> > > > > > > > > + return path->opp_table;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > /**
> > > > > > > > > * icc_set_bw() - set bandwidth constraints on an interconnect path
> > > > > > > > > * @path: reference to the path returned by icc_get()
> > > > > > > > > diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> > > > > > > > > index dc25864755ba..0c0bc55f0e89 100644
> > > > > > > > > --- a/include/linux/interconnect.h
> > > > > > > > > +++ b/include/linux/interconnect.h
> > > > > > > > > @@ -9,6 +9,7 @@
> > > > > > > > >
> > > > > > > > > #include <linux/mutex.h>
> > > > > > > > > #include <linux/types.h>
> > > > > > > > > +#include <linux/pm_opp.h>
> > > > > > > > >
> > > > > > > > > /* macros for converting to icc units */
> > > > > > > > > #define Bps_to_icc(x) ((x) / 1000)
> > > > > > > > > @@ -28,6 +29,7 @@ struct device;
> > > > > > > > > struct icc_path *icc_get(struct device *dev, const int src_id,
> > > > > > > > > const int dst_id);
> > > > > > > > > struct icc_path *of_icc_get(struct device *dev, const char *name);
> > > > > > > > > +struct opp_table *icc_get_opp_table(struct icc_path *path);
> > > > > > > > > void icc_put(struct icc_path *path);
> > > > > > > > > int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> > > > > > > > >
> > > > > > > > > @@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
> > > > > > > > > {
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > +static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
> > > > > > > > > +{
> > > > > > > > > + return NULL;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> > > > > > > > > {
> > > > > > > > > return 0;
> > > > > > > > > --
> > > > > > > > > 2.22.0.410.gd8fdbe21b5-goog
> > > > > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> > > > > >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox