* [PATCH v3 2/2] leds: Add PWM multicolor driver
From: sven @ 2022-01-26 10:48 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones, post
In-Reply-To: <20220126104844.246068-1-sven@svenschwermer.de>
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
By allowing to group multiple monochrome PWM LEDs into multicolor LEDs,
all involved LEDs can be controlled in-sync. This enables using effects
using triggers, etc.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
---
Notes:
Changes in v3:
* Release fwnode handles
* Sort header includes
* Remove deprecated device tree properties
* Remove deprecated LED_OFF
* Remove subled channel assignment
* s/pwmstate/state/
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-pwm-multicolor.c | 184 +++++++++++++++++++++++++++++
3 files changed, 193 insertions(+)
create mode 100644 drivers/leds/leds-pwm-multicolor.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6090e647daee..bae1f63f6195 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -552,6 +552,14 @@ config LEDS_PWM
help
This option enables support for pwm driven LEDs
+config LEDS_PWM_MULTICOLOR
+ tristate "PWM driven multi-color LED Support"
+ depends on LEDS_CLASS_MULTICOLOR
+ depends on PWM
+ help
+ This option enables support for PWM driven monochrome LEDs that are
+ grouped into multicolor LEDs.
+
config LEDS_REGULATOR
tristate "REGULATOR driven LED support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e58ecb36360f..ba2c2c1edf12 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_LEDS_PCA963X) += leds-pca963x.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_PWM_MULTICOLOR) += leds-pwm-multicolor.o
obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
diff --git a/drivers/leds/leds-pwm-multicolor.c b/drivers/leds/leds-pwm-multicolor.c
new file mode 100644
index 000000000000..bc4d21ddd74a
--- /dev/null
+++ b/drivers/leds/leds-pwm-multicolor.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PWM-based multi-color LED control
+ *
+ * Copyright 2022 Sven Schwermer <sven.schwermer@disruptive-technologies.com>
+ */
+
+#include <linux/err.h>
+#include <linux/kernel.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+
+struct pwm_led {
+ struct pwm_device *pwm;
+ struct pwm_state state;
+};
+
+struct pwm_mc_led {
+ struct led_classdev_mc mc_cdev;
+ struct mutex lock;
+ struct pwm_led leds[];
+};
+
+static int led_pwm_mc_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ int i;
+ unsigned long long duty;
+ int ret = 0;
+ struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(cdev);
+ struct pwm_mc_led *priv = container_of(mc_cdev, struct pwm_mc_led, mc_cdev);
+
+ led_mc_calc_color_components(mc_cdev, brightness);
+
+ mutex_lock(&priv->lock);
+
+ for (i = 0; i < mc_cdev->num_colors; ++i) {
+ duty = priv->leds[i].state.period;
+ duty *= mc_cdev->subled_info[i].brightness;
+ do_div(duty, cdev->max_brightness);
+
+ priv->leds[i].state.duty_cycle = duty;
+ priv->leds[i].state.enabled = duty > 0;
+ ret = pwm_apply_state(priv->leds[i].pwm,
+ &priv->leds[i].state);
+ if (ret)
+ break;
+ }
+
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int led_pwm_mc_probe(struct platform_device *pdev)
+{
+ struct fwnode_handle *mcnode, *fwnode;
+ int count = 0;
+ struct pwm_mc_led *priv;
+ struct mc_subled *subled;
+ struct led_classdev *cdev;
+ struct pwm_led *pwmled;
+ u32 color;
+ int ret = 0;
+ struct led_init_data init_data = {};
+
+ mcnode = device_get_named_child_node(&pdev->dev, "multi-led");
+ if (!mcnode) {
+ dev_err(&pdev->dev, "expected multi-led node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ /* count the nodes inside the multi-led node */
+ fwnode_for_each_child_node(mcnode, fwnode)
+ ++count;
+
+ priv = devm_kzalloc(&pdev->dev, struct_size(priv, leds, count),
+ GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto release_mcnode;
+ }
+ mutex_init(&priv->lock);
+
+ subled = devm_kcalloc(&pdev->dev, count, sizeof(*subled), GFP_KERNEL);
+ if (!subled) {
+ ret = -ENOMEM;
+ goto destroy_mutex;
+ }
+ priv->mc_cdev.subled_info = subled;
+
+ /* init the multicolor's LED class device */
+ cdev = &priv->mc_cdev.led_cdev;
+ fwnode_property_read_u32(mcnode, "max-brightness",
+ &cdev->max_brightness);
+ cdev->flags = LED_CORE_SUSPENDRESUME;
+ cdev->brightness_set_blocking = led_pwm_mc_set;
+
+ /* iterate over the nodes inside the multi-led node */
+ fwnode_for_each_child_node(mcnode, fwnode) {
+ pwmled = &priv->leds[priv->mc_cdev.num_colors];
+ pwmled->pwm = devm_fwnode_pwm_get(&pdev->dev, fwnode, NULL);
+ if (IS_ERR(pwmled->pwm)) {
+ ret = PTR_ERR(pwmled->pwm);
+ dev_err(&pdev->dev, "unable to request PWM: %d\n", ret);
+ fwnode_handle_put(fwnode);
+ goto destroy_mutex;
+ }
+ pwm_init_state(pwmled->pwm, &pwmled->state);
+
+ ret = fwnode_property_read_u32(fwnode, "color", &color);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot read color: %d\n", ret);
+ fwnode_handle_put(fwnode);
+ goto destroy_mutex;
+ }
+
+ subled[priv->mc_cdev.num_colors].color_index = color;
+ ++priv->mc_cdev.num_colors;
+ }
+
+ init_data.fwnode = mcnode;
+ ret = devm_led_classdev_multicolor_register_ext(&pdev->dev,
+ &priv->mc_cdev,
+ &init_data);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to register multicolor PWM led for %s: %d\n",
+ cdev->name, ret);
+ goto destroy_mutex;
+ }
+
+ ret = led_pwm_mc_set(cdev, cdev->brightness);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to set led PWM value for %s: %d",
+ cdev->name, ret);
+ goto destroy_mutex;
+ }
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+
+destroy_mutex:
+ mutex_destroy(&priv->lock);
+release_mcnode:
+ fwnode_handle_put(mcnode);
+out:
+ return ret;
+}
+
+static int led_pwm_mc_remove(struct platform_device *pdev)
+{
+ struct pwm_mc_led *priv = platform_get_drvdata(pdev);
+
+ mutex_destroy(&priv->lock);
+ return 0;
+}
+
+static const struct of_device_id of_pwm_leds_mc_match[] = {
+ { .compatible = "pwm-leds-multicolor", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_leds_mc_match);
+
+static struct platform_driver led_pwm_mc_driver = {
+ .probe = led_pwm_mc_probe,
+ .remove = led_pwm_mc_remove,
+ .driver = {
+ .name = "leds_pwm_multicolor",
+ .of_match_table = of_pwm_leds_mc_match,
+ },
+};
+
+module_platform_driver(led_pwm_mc_driver);
+
+MODULE_AUTHOR("Sven Schwermer <sven.schwermer@disruptive-technologies.com>");
+MODULE_DESCRIPTION("multi-color PWM LED driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:leds-pwm-multicolor");
--
2.35.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: sven @ 2022-01-26 10:48 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones, post
In-Reply-To: <20220126104844.246068-1-sven@svenschwermer.de>
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
This allows to group multiple PWM-connected monochrome LEDs into
multicolor LEDs, e.g. RGB LEDs.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
---
Notes:
Changes in v3:
* Remove multi-led unit name
.../bindings/leds/leds-pwm-multicolor.yaml | 75 +++++++++++++++++++
1 file changed, 75 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
new file mode 100644
index 000000000000..5a7ed5e1bb9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-pwm-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multi-color LEDs connected to PWM
+
+maintainers:
+ - Sven Schwermer <sven.schwermer@disruptive-technologies.com>
+
+description: |
+ This driver combines several monochrome PWM LEDs into one multi-color
+ LED using the multicolor LED class.
+
+properties:
+ compatible:
+ const: pwm-leds-multicolor
+
+ multi-led:
+ type: object
+ allOf:
+ - $ref: leds-class-multicolor.yaml#
+
+ patternProperties:
+ "^led-[0-9a-z]+$":
+ type: object
+ properties:
+ pwms:
+ maxItems: 1
+
+ pwm-names: true
+
+ color:
+ $ref: common.yaml#/properties/color
+
+ required:
+ - pwms
+ - color
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ rgb-led {
+ compatible = "pwm-leds-multicolor";
+
+ multi-led {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ max-brightness = <65535>;
+
+ led-red {
+ pwms = <&pwm1 0 1000000>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-green {
+ pwms = <&pwm2 0 1000000>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-blue {
+ pwms = <&pwm3 0 1000000>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+
+...
--
2.35.0
^ permalink raw reply related
* [PATCH v3 0/2] Multicolor PWM LED support
From: sven @ 2022-01-26 10:48 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones, post
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Hi,
This patch series is getting mature. I have removed the RFC tag for this
version. The initial discussion happened here [1].
I would appreciate if anyone would test this code. It runs on my
i.MX6ULL-based hardware.
Best regards,
Sven
[1]:https://lore.kernel.org/linux-leds/37540afd-f2f1-52dd-f4f1-6e7b436e9595@svenschwermer.de/
Sven Schwermer (2):
dt-bindings: leds: Add multicolor PWM LED bindings
leds: Add PWM multicolor driver
.../bindings/leds/leds-pwm-multicolor.yaml | 75 +++++++
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pwm-multicolor.c | 184 ++++++++++++++++++
4 files changed, 268 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
create mode 100644 drivers/leds/leds-pwm-multicolor.c
Interdiff against v2:
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
index b82b26f2e140..5a7ed5e1bb9f 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -17,8 +17,7 @@ properties:
compatible:
const: pwm-leds-multicolor
-patternProperties:
- '^multi-led@[0-9a-f]$':
+ multi-led:
type: object
allOf:
- $ref: leds-class-multicolor.yaml#
@@ -51,7 +50,7 @@ examples:
rgb-led {
compatible = "pwm-leds-multicolor";
- multi-led@0 {
+ multi-led {
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_INDICATOR;
max-brightness = <65535>;
diff --git a/drivers/leds/leds-pwm-multicolor.c b/drivers/leds/leds-pwm-multicolor.c
index c54bed4536d3..bc4d21ddd74a 100644
--- a/drivers/leds/leds-pwm-multicolor.c
+++ b/drivers/leds/leds-pwm-multicolor.c
@@ -5,18 +5,18 @@
* Copyright 2022 Sven Schwermer <sven.schwermer@disruptive-technologies.com>
*/
-#include <linux/module.h>
+#include <linux/err.h>
#include <linux/kernel.h>
-#include <linux/platform_device.h>
#include <linux/led-class-multicolor.h>
#include <linux/leds.h>
-#include <linux/err.h>
-#include <linux/pwm.h>
+#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
struct pwm_led {
struct pwm_device *pwm;
- struct pwm_state pwmstate;
+ struct pwm_state state;
};
struct pwm_mc_led {
@@ -39,14 +39,14 @@ static int led_pwm_mc_set(struct led_classdev *cdev,
mutex_lock(&priv->lock);
for (i = 0; i < mc_cdev->num_colors; ++i) {
- duty = priv->leds[i].pwmstate.period;
+ duty = priv->leds[i].state.period;
duty *= mc_cdev->subled_info[i].brightness;
do_div(duty, cdev->max_brightness);
- priv->leds[i].pwmstate.duty_cycle = duty;
- priv->leds[i].pwmstate.enabled = duty > 0;
+ priv->leds[i].state.duty_cycle = duty;
+ priv->leds[i].state.enabled = duty > 0;
ret = pwm_apply_state(priv->leds[i].pwm,
- &priv->leds[i].pwmstate);
+ &priv->leds[i].state);
if (ret)
break;
}
@@ -83,7 +83,7 @@ static int led_pwm_mc_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
- goto out;
+ goto release_mcnode;
}
mutex_init(&priv->lock);
@@ -96,8 +96,6 @@ static int led_pwm_mc_probe(struct platform_device *pdev)
/* init the multicolor's LED class device */
cdev = &priv->mc_cdev.led_cdev;
- fwnode_property_read_string(mcnode, "label", &cdev->name);
- cdev->brightness = LED_OFF;
fwnode_property_read_u32(mcnode, "max-brightness",
&cdev->max_brightness);
cdev->flags = LED_CORE_SUSPENDRESUME;
@@ -110,19 +108,19 @@ static int led_pwm_mc_probe(struct platform_device *pdev)
if (IS_ERR(pwmled->pwm)) {
ret = PTR_ERR(pwmled->pwm);
dev_err(&pdev->dev, "unable to request PWM: %d\n", ret);
+ fwnode_handle_put(fwnode);
goto destroy_mutex;
}
- pwm_init_state(pwmled->pwm, &pwmled->pwmstate);
+ pwm_init_state(pwmled->pwm, &pwmled->state);
ret = fwnode_property_read_u32(fwnode, "color", &color);
if (ret) {
dev_err(&pdev->dev, "cannot read color: %d\n", ret);
+ fwnode_handle_put(fwnode);
goto destroy_mutex;
}
subled[priv->mc_cdev.num_colors].color_index = color;
- subled[priv->mc_cdev.num_colors].channel =
- priv->mc_cdev.num_colors;
++priv->mc_cdev.num_colors;
}
@@ -149,6 +147,8 @@ static int led_pwm_mc_probe(struct platform_device *pdev)
destroy_mutex:
mutex_destroy(&priv->lock);
+release_mcnode:
+ fwnode_handle_put(mcnode);
out:
return ret;
}
--
2.35.0
^ permalink raw reply related
* Re: [PATCH v6 0/2] Driver for Open Profile for DICE
From: David Brazdil @ 2022-01-26 10:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Rob Herring, Arnd Bergmann, Frank Rowand, Will Deacon,
Andrew Scull, devicetree, linux-kernel
In-Reply-To: <YfEOlN8Wshoa/aaB@kroah.com>
Hi Greg,
On Wed, Jan 26, 2022 at 10:04:20AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 04, 2022 at 10:06:43AM +0000, David Brazdil wrote:
> > Open Profile for DICE is an open protocol for measured boot compatible
> > with the Trusted Computing Group's Device Identifier Composition
> > Engine (DICE) specification. The generated Compound Device Identifier
> > (CDI) certificates represent the measured hardware/software combination
> > and can be used by userspace for remote attestation and sealing.
> >
> > This patchset adds DeviceTree bindings for the DICE device referencing
> > a reserved memory region containing the CDIs, and a driver that exposes
> > the memory region to userspace via a misc device.
> >
> > See https://pigweed.googlesource.com/open-dice for more details.
> >
> > The patches are based on top of v5.16-rc8 and can also be found here:
> > https://android-kvm.googlesource.com/linux topic/dice_v6
> >
> > Changes since v5:
> > * replaced 'additionalProperties' with 'unevaluatedProperties' in DT YAML
>
> I am going to drop this version from my review queue as I think you have
> a new one instead, right?
Sorry for the radio silence and yes, please drop from your queue. I need
to post a new one and get back to Wedson. Hopefully today.
David
^ permalink raw reply
* Re: [RFC PATCH v2 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Sven Schwermer @ 2022-01-26 10:17 UTC (permalink / raw)
To: Marek Behún
Cc: linux-leds, devicetree, linux-pwm, Sven Schwermer, pavel, robh+dt,
thierry.reding, u.kleine-koenig, lee.jones, post
In-Reply-To: <20220125212736.5ffafe2b@thinkpad>
On 1/25/22 21:27, Marek Behún wrote:
> what about
>
> multi-led@0 {
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> pwms = <&pwm1 0 1000000>,
> <&pwm2 0 1000000>,
> <&pwm3 0 1000000>;
> channels = <LED_COLOR_ID_RED>,
> <LED_COLOR_ID_GREEN>,
> <LED_COLOR_ID_BLUE>;
> };
>
> I am not saying that it is necessarily better, just comenting that
> maybe it is, since it saves some space. `pwms` is phandle-array, so it
> can contain references to multiple pwms, and we have functions which
> make getting these pwms in driver code easy...
I have had another look at this. It seems like if you specify more than
one PWM instance in the `pwms` property, the device tree must specify
`pwm-names` in order for the driver to be able to request the correct
instance (see `of_pwm_get`). In this case, the device tree would need to
contain some strings in `pwm-names` that allow the driver to match them
against the color IDs. Alternatively, I could re-implement the PWM
instance request logic. Both options seem not ideal.
For the next version of this patch series, I'll go with my original
approach. I'm open for alternatives :)
Best regards,
Sven
^ permalink raw reply
* [PATCH net-next 5/5] dt-bindings: net: xgmac_mdio: Add "clock-frequency" and "suppress-preamble"
From: Tobias Waldekranz @ 2022-01-26 10:14 UTC (permalink / raw)
To: davem, kuba; +Cc: netdev, Madalin Bucur, Rob Herring, devicetree, linux-kernel
In-Reply-To: <20220126101432.822818-1-tobias@waldekranz.com>
The driver now supports the standard "clock-frequency" and
"suppress-preamble" properties, do document them in the binding
description.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
.../devicetree/bindings/net/fsl-fman.txt | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
index cd5288fb4318..801efc7d6818 100644
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
@@ -388,6 +388,25 @@ PROPERTIES
Value type: <prop-encoded-array>
Definition: A standard property.
+- clocks
+ Usage: optional
+ Value type: <phandle>
+ Definition: A reference to the input clock of the controller
+ from which the MDC frequency is derived.
+
+- clock-frequency
+ Usage: optional
+ Value type: <u32>
+ Definition: Specifies the external MDC frequency, in Hertz, to
+ be used. Requires that the input clock is specified in the
+ "clocks" property. See also: mdio.yaml.
+
+- suppress-preamble
+ Usage: optional
+ Value type: <boolean>
+ Definition: Disable generation of preamble bits. See also:
+ mdio.yaml.
+
- interrupts
Usage: required for external MDIO
Value type: <prop-encoded-array>
--
2.25.1
^ permalink raw reply related
* [PATCH net-next 1/5] dt-bindings: net: xgmac_mdio: Remove unsupported "bus-frequency"
From: Tobias Waldekranz @ 2022-01-26 10:14 UTC (permalink / raw)
To: davem, kuba
Cc: netdev, Madalin Bucur, Rob Herring, Shaohui Xie, Scott Wood,
devicetree, linux-kernel
In-Reply-To: <20220126101432.822818-1-tobias@waldekranz.com>
This property has never been supported by the driver. The kernel has
settled on "clock-frequency" as the standard name for this binding, so
once that is supported we will document that instead.
Fixes: 7f93c9d90f4d ("power/fsl: add MDIO dt binding for FMan")
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
---
Documentation/devicetree/bindings/net/fsl-fman.txt | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt
index 020337f3c05f..cd5288fb4318 100644
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
@@ -388,15 +388,6 @@ PROPERTIES
Value type: <prop-encoded-array>
Definition: A standard property.
-- bus-frequency
- Usage: optional
- Value type: <u32>
- Definition: Specifies the external MDIO bus clock speed to
- be used, if different from the standard 2.5 MHz.
- This may be due to the standard speed being unsupported (e.g.
- due to a hardware problem), or to advertise that all relevant
- components in the system support a faster speed.
-
- interrupts
Usage: required for external MDIO
Value type: <prop-encoded-array>
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v5 03/16] dt-bindings: clock: Document FSD CMU bindings
From: Krzysztof Kozlowski @ 2022-01-26 10:07 UTC (permalink / raw)
To: Sylwester Nawrocki, Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, linux-samsung-soc, pankaj.dubey, sboyd,
linux-fsd
In-Reply-To: <a611a070-4932-1691-1f20-7cfa8bb96cc1@samsung.com>
On 26/01/2022 10:13, Sylwester Nawrocki wrote:
> On 24.01.2022 15:16, Alim Akhtar wrote:
>> Add dt-schema documentation for Tesla FSD SoC clock controller.
>>
>> Cc: linux-fsd@tesla.com
>> Acked-by: Stephen Boyd <sboyd@kernel.org>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Thanks, applied with all other clock driver changes.
Sylwester,
They are on separate branch, so I could send you pull if needed for
conflict resolution. Just let me know.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC (clock parts)
From: Krzysztof Kozlowski @ 2022-01-26 10:05 UTC (permalink / raw)
To: linux-arm-kernel, Alim Akhtar, linux-kernel
Cc: Krzysztof Kozlowski, soc, devicetree, linux-samsung-soc, robh+dt,
catalin.marinas, s.nawrocki, arnd, pankaj.dubey, linux-clk,
linus.walleij, olof, sboyd
In-Reply-To: <20220124141644.71052-1-alim.akhtar@samsung.com>
On Mon, 24 Jan 2022 19:46:28 +0530, Alim Akhtar wrote:
> Adds basic support for the Tesla Full Self-Driving (FSD)
> SoC. This SoC contains three clusters of four Cortex-A72 CPUs,
> as well as several IPs.
>
> Patches 1 to 9 provide support for the clock controller
> (which is designed similarly to Exynos SoCs).
>
> [...]
Applied also clock parts, thanks!
[01/16] dt-bindings: add vendor prefix for Tesla
commit: a5a93e9b9ab9b4f367a773b32bbe1687006d75b7
[02/16] dt-bindings: clock: Add bindings definitions for FSD CMU blocks
commit: d6dc675377261472adda696da456b4ebcc5bb9d9
[03/16] dt-bindings: clock: Document FSD CMU bindings
commit: ed68db7b7f2fd01e930fa3e6fbb75954dc25e41c
[04/16] clk: samsung: fsd: Add initial clock support
commit: 4f346005aaed641042ca18171c4383a6a85f6a8b
[05/16] clk: samsung: fsd: Add cmu_peric block clock information
commit: e3f3dc3810d3765128d28b241f4afb761d81678a
[06/16] clk: samsung: fsd: Add cmu_fsys0 clock information
commit: a15e367b02543f96ae845baf7be4526080437305
[07/16] clk: samsung: fsd: Add cmu_fsys1 clock information
commit: bfbce52e4649b9a2c7296a6296ffbdfc3b07de2e
[08/16] clk: samsung: fsd: Add cmu_imem block clock information
commit: ca0fdfd131c7d33984d8feeda23a99e883ffb0cb
[09/16] clk: samsung: fsd: Add cmu_mfc block clock information
commit: 75c50afaa0d9a3e8f96940451bed6d0ccc6a0a03
[10/16] clk: samsung: fsd: Add cam_csi block clock information
commit: b826c3e4de1a44ad8e5536d86d5ef062a54ed2b2
[13/16] dt-bindings: arm: add Tesla FSD ARM SoC
commit: d25c5eb511df3439cd91517bcbce4b274f8972b9
[14/16] arm64: dts: fsd: Add initial device tree support
commit: 18b1db6a162c29695920fdf212ccb8d7d5c07e9a
[15/16] arm64: dts: fsd: Add initial pinctrl support
commit: 684dac402f212d8ededbe7d97bc42a5e49533f40
[16/16] arm64: defconfig: Enable Tesla FSD SoC
commit: 0d525a653b03a25190650f783026c8e655268b48
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mn-venice-gw7902: disable gpu
From: Lucas Stach @ 2022-01-26 9:58 UTC (permalink / raw)
To: Shawn Guo, Tim Harvey
Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel,
Adam Ford
In-Reply-To: <20220126093558.GL4686@dragon>
Am Mittwoch, dem 26.01.2022 um 17:35 +0800 schrieb Shawn Guo:
> On Thu, Dec 16, 2021 at 08:12:27AM -0800, Tim Harvey wrote:
> > Since commit 99aa29932271 ("arm64: dts: imx8mn: Enable GPU")
> > imx8mn-venice-gw7902 will hang during kernel init because it uses
> > a MIMX8MN5CVTI which does not have a GPU.
>
> I do not quite follow on this. i.MX8MN integrates a GPU, and
> MIMX8MN5CVTI is built on i.MX8MN, correct? If so, how comes
> MIMX8MN5CVTI doesn't have a GPU?
>
It's a fused-down variant of the i.MX8MN that has the GPU disabled by
fuses.
> >
> > Disable pgc_gpumix to work around this. We also disable the GPU devices
> > that depend on the gpumix power domain and pgc_gpu to avoid them staying
> > in a probe deferred state forever.
>
> Is this an indication that GPU should be disabled in imx8mn.dtsi and
> enabled board by board?
>
There's a trade-off here: most boards will probably use the full
variants that include the GPU, so probably less boards will need to
disable the GPU, as done here, than boards that need to enable it when
the base DT disables the GPU.
Same story as with the i.MX6 where there are some SKUs that disable the
VPU by fuses: we enable it in the base DT and if you happen to build a
very low-cost board that uses the fused-down version you need to
disable it in the board DT.
Regards,
Lucas
> Shawn
>
> >
> > Cc: Adam Ford <aford173@gmail.com>
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> > ---
> > .../boot/dts/freescale/imx8mn-venice-gw7902.dts | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts b/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> > index 236f425e1570..2d58005d20e4 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> > @@ -220,6 +220,10 @@
> > };
> > };
> >
> > +&disp_blk_ctrl {
> > + status = "disabled";
> > +};
> > +
> > /* off-board header */
> > &ecspi2 {
> > pinctrl-names = "default";
> > @@ -251,6 +255,10 @@
> > };
> > };
> >
> > +&gpu {
> > + status = "disabled";
> > +};
> > +
> > &i2c1 {
> > clock-frequency = <100000>;
> > pinctrl-names = "default";
> > @@ -546,6 +554,10 @@
> > status = "okay";
> > };
> >
> > +&pgc_gpumix {
> > + status = "disabled";
> > +};
> > +
> > /* off-board header */
> > &sai3 {
> > pinctrl-names = "default";
> > --
> > 2.17.1
> >
^ permalink raw reply
* Re: [PATCH v10 0/4] clk: meson: add a sub EMMC clock controller support
From: Liang Yang @ 2022-01-26 9:42 UTC (permalink / raw)
To: Jerome Brunet, Neil Armstrong, Kevin Hilman, Michael Turquette,
Stephen Boyd, Rob Herring, linux-clk
Cc: Martin Blumenstingl, Jianxin Pan, Victor Wan, XianWei Zhao,
Kelvin Zhang, BiChao Zheng, YongHui Yu, linux-arm-kernel,
linux-amlogic, linux-kernel, devicetree
In-Reply-To: <1jy23226sa.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
On 2022/1/26 17:14, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
>
> On Wed 26 Jan 2022 at 17:08, Liang Yang <liang.yang@amlogic.com> wrote:
>
>> Hi Neil,
>>
>> On 2022/1/25 22:54, Neil Armstrong wrote:
>>> [ EXTERNAL EMAIL ]
>>> Hi Liang,
>>> On 21/01/2022 08:45, Liang Yang wrote:
>>>> This driver will add a MMC clock controller driver support.
>>>> The original idea about adding a clock controller is during the
>>>> discussion in the NAND driver mainline effort[1].
>>>>
>>>> This driver is tested in the S400 board (AXG platform) with NAND driver.
>>> Thanks a lot for providing a fixed and updated version of this serie.
>>> After some chat with Jerome and Kevin, it seems the way the eMMC clock
>>> reuse
>>> for NAND was designed nearly 4 years doesn't look accurate anymore.
>>> Having a separate clk driver designed to replace the eMMC node when NAND
>>> is
>>> used on the board seems over engineered.
>>> Actually having the clock code you add in this serie _but_ directly in
>>> the NAND looks far better, and more coherent since having Linux runtime
>>> detection of eMMC vs NAND will never happen and even this serie required
>>> some DT modification from the bootloader.
>>> I'll let Jerome or Kevin add more details if they want, but I think you
>>> should resurrect
>>> the work you pushed in [1] & [2] but:
>>> - passing the eMMC clk registers as a third "reg" cell
>> Does it just need to define a 'reg' resource in NFC node and not 'syscon'
>> here?
>
> Yes
>
>>> - passing the same "clocks" phandle as the eMMC node
>>> - adding the eMMC clock code in the NAND driver directly
>>> I'm open to discussions if you consider the current approach is still
>>> superior.
>>
>> I don't have persuasive ideas, but really it shares the common clock
>> implementation for both NFC and EMMC. and we don't need to paste the
>> same code in NFC and EMMC.
>
> You don't need to copy everything. If I understood correctly, all the
> Rx/Tx should not be needed. Yes, there is some duplication as it stands but
> it allows to avoid coupling the MMC and NAND driver. We can still think
> about optimizing things later on. Let's get something simply working
> first.
ok. i will do it. thank you.
>
>>
>>> Thanks,
>>> Neil
>>> [1]
>>> https://lore.kernel.org/r/20220106033130.37623-1-liang.yang@amlogic.com
>>> [2] https://lore.kernel.org/r/20220106032504.23310-1-liang.yang@amlogic.com
>>>
>>>>
>>>> Changes since v9 [10]
>>>> - use clk_parent_data instead of parent_names
>>>>
>>>> Changes since v8 [9]
>>>> - use MESON_SCLK_ONE_BASED instead of CLK_DIVIDER_ONE_BASED
>>>> - use struct_size to caculate onecell_data
>>>> - add clk-phase-delay.h
>>>> - define CLK_DELAY_STEP_PS_GX and CLK_DELAY_STEP_PS_AXG
>>>>
>>>> Changes since v7 [8]
>>>> - move meson_clk_get_phase_delay_data() from header to driver
>>>> - CONFIG sclk-div with COMMON_CLK_AMLOGIC instead of COMMON_CLK_AMLOGIC_AUDIO
>>>> - remove onecell date and ID for internal MUX clk
>>>> - use helper for functions for ONE_BASED in sclk-div
>>>> - add ONE_BASED support for duty cycle
>>>>
>>>> Changes since v6 [7]:
>>>> - add one based support for sclk divier
>>>> - alloc sclk in probe for multiple instance
>>>> - fix coding styles
>>>>
>>>> Changes since v5 [6]:
>>>> - remove divider ops with .init and use sclk_div instead
>>>> - drop CLK_DIVIDER_ROUND_CLOSEST in mux and div
>>>> - drop the useless type cast
>>>>
>>>> Changes since v4 [5]:
>>>> - use struct parm in phase delay driver
>>>> - remove 0 delay releted part in phase delay driver
>>>> - don't rebuild the parent name once again
>>>> - add divider ops with .init
>>>>
>>>> Changes since v3 [4]:
>>>> - separate clk-phase-delay driver
>>>> - replace clk_get_rate() with clk_hw_get_rate()
>>>> - collect Rob's R-Y
>>>> - drop 'meson-' prefix from compatible string
>>>>
>>>> Changes since v2 [3]:
>>>> - squash dt-binding clock-id patch
>>>> - update license
>>>> - fix alignment
>>>> - construct a clk register helper() function
>>>>
>>>> Changes since v1 [2]:
>>>> - implement phase clock
>>>> - update compatible name
>>>> - adjust file name
>>>> - divider probe() into small functions, and re-use them
>>>>
>>>> [1] https://lkml.kernel.org/r/20180628090034.0637a062@xps13
>>>> [2] https://lkml.kernel.org/r/20180703145716.31860-1-yixun.lan@amlogic.com
>>>> [3] https://lkml.kernel.org/r/20180710163658.6175-1-yixun.lan@amlogic.com
>>>> [4] https://lkml.kernel.org/r/20180712211244.11428-1-yixun.lan@amlogic.com
>>>> [5] https://lkml.kernel.org/r/20180809070724.11935-4-yixun.lan@amlogic.com
>>>> [6] https://lkml.kernel.org/r/1539839245-13793-1-git-send-email-jianxin.pan@amlogic.com
>>>> [7] https://lkml.kernel.org/r/1541089855-19356-1-git-send-email-jianxin.pan@amlogic.com
>>>> [8] https://lkml.kernel.org/r/1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com
>>>> [9] https://lkml.kernel.org/r/1545063850-21504-1-git-send-email-jianxin.pan@amlogic.com
>>>> [10] https://lore.kernel.org/all/20220113115745.45826-1-liang.yang@amlogic.com/
>>>> Liang Yang (4):
>>>> clk: meson: add one based divider support for sclk
>>>> clk: meson: add emmc sub clock phase delay driver
>>>> clk: meson: add DT documentation for emmc clock controller
>>>> clk: meson: add sub MMC clock controller driver
>>>>
>>>> .../bindings/clock/amlogic,mmc-clkc.yaml | 64 ++++
>>>> drivers/clk/meson/Kconfig | 18 ++
>>>> drivers/clk/meson/Makefile | 2 +
>>>> drivers/clk/meson/clk-phase-delay.c | 69 ++++
>>>> drivers/clk/meson/clk-phase-delay.h | 20 ++
>>>> drivers/clk/meson/mmc-clkc.c | 302 ++++++++++++++++++
>>>> drivers/clk/meson/sclk-div.c | 59 ++--
>>>> drivers/clk/meson/sclk-div.h | 3 +
>>>> include/dt-bindings/clock/amlogic,mmc-clkc.h | 14 +
>>>> 9 files changed, 529 insertions(+), 22 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.yaml
>>>> create mode 100644 drivers/clk/meson/clk-phase-delay.c
>>>> create mode 100644 drivers/clk/meson/clk-phase-delay.h
>>>> create mode 100644 drivers/clk/meson/mmc-clkc.c
>>>> create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
>>>>
>>> .
>
> .
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mn-venice-gw7902: disable gpu
From: Shawn Guo @ 2022-01-26 9:35 UTC (permalink / raw)
To: Tim Harvey
Cc: Rob Herring, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel,
Adam Ford, Lucas Stach
In-Reply-To: <20211216161227.31960-1-tharvey@gateworks.com>
On Thu, Dec 16, 2021 at 08:12:27AM -0800, Tim Harvey wrote:
> Since commit 99aa29932271 ("arm64: dts: imx8mn: Enable GPU")
> imx8mn-venice-gw7902 will hang during kernel init because it uses
> a MIMX8MN5CVTI which does not have a GPU.
I do not quite follow on this. i.MX8MN integrates a GPU, and
MIMX8MN5CVTI is built on i.MX8MN, correct? If so, how comes
MIMX8MN5CVTI doesn't have a GPU?
>
> Disable pgc_gpumix to work around this. We also disable the GPU devices
> that depend on the gpumix power domain and pgc_gpu to avoid them staying
> in a probe deferred state forever.
Is this an indication that GPU should be disabled in imx8mn.dtsi and
enabled board by board?
Shawn
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
> .../boot/dts/freescale/imx8mn-venice-gw7902.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts b/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> index 236f425e1570..2d58005d20e4 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mn-venice-gw7902.dts
> @@ -220,6 +220,10 @@
> };
> };
>
> +&disp_blk_ctrl {
> + status = "disabled";
> +};
> +
> /* off-board header */
> &ecspi2 {
> pinctrl-names = "default";
> @@ -251,6 +255,10 @@
> };
> };
>
> +&gpu {
> + status = "disabled";
> +};
> +
> &i2c1 {
> clock-frequency = <100000>;
> pinctrl-names = "default";
> @@ -546,6 +554,10 @@
> status = "okay";
> };
>
> +&pgc_gpumix {
> + status = "disabled";
> +};
> +
> /* off-board header */
> &sai3 {
> pinctrl-names = "default";
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
From: Krzysztof Kozlowski @ 2022-01-26 9:32 UTC (permalink / raw)
To: Sylwester Nawrocki, Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, linux-samsung-soc, pankaj.dubey, sboyd
In-Reply-To: <bccd3ad0-7862-ef3b-246c-71463baaca52@samsung.com>
On 26/01/2022 10:21, Sylwester Nawrocki wrote:
> Hi,
>
> On 26.01.2022 07:52, Alim Akhtar wrote:
>>>
>>> Thanks, applied DTS/soc and pinctrl patches.
>>>
>> Thanks Krzysztof
>>
>>> I expect Sylwester will pick up the clock ones. Otherwise please let me know
>>> to pick it up as well.
>>>
>> Hi Sylwester, hope you will be taking clock changes, or let Krzysztof know otherwise.
>> Thanks
>
> Krzysztof, can you also take the clk patches through your tree?
> If you prefer to avoid it I will create a topic branch with the
> clk headers and DT bindings documentation.
No problem, I'll consume everything I encounter :)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH V4 3/6] soc: qcom: eud: Add driver support for Embedded USB Debugger(EUD)
From: Greg KH @ 2022-01-26 9:30 UTC (permalink / raw)
To: Souradeep Chowdhury
Cc: linux-arm-msm, linux-usb, devicetree, pure.logic, bjorn.andersson,
robh, linux-kernel, quic_tsoni, quic_psodagud, quic_satyap,
quic_pheragu, quic_rjendra, quic_sibis, quic_saipraka
In-Reply-To: <7ccee5ae484e6917f5838c8abde368680ec63d05.1642768837.git.quic_schowdhu@quicinc.com>
On Fri, Jan 21, 2022 at 07:23:48PM +0530, Souradeep Chowdhury wrote:
> Add support for control peripheral of EUD (Embedded USB Debugger) to
> listen to events such as USB attach/detach, pet EUD to indicate software
> is functional.Reusing the platform device kobj, sysfs entry 'enable' is
> created to enable or disable EUD.
>
> To enable the eud the following needs to be done
> echo 1 > /sys/bus/platform/.../enable
>
> To disable eud, following is the command
> echo 0 > /sys/bus/platform/.../enable
>
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
> Documentation/ABI/testing/sysfs-driver-eud | 9 ++
> drivers/soc/qcom/Kconfig | 10 ++
> drivers/soc/qcom/Makefile | 1 +
> drivers/soc/qcom/qcom_eud.c | 250 +++++++++++++++++++++++++++++
This should go under drivers/usb/ as it's creating a USB generic
user/kernel api that all future devices of this type must follow.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RESEND 2/2] ARM: dts: imx6qdl: Handle unneeded MFD-subdevices correctly
From: Shawn Guo @ 2022-01-26 9:27 UTC (permalink / raw)
To: Andrej Picej
Cc: robh+dt, s.hauer, devicetree, festevam, kernel, linux-kernel,
y.bas
In-Reply-To: <20211216115529.2331475-2-andrej.picej@norik.com>
On Thu, Dec 16, 2021 at 12:55:29PM +0100, Andrej Picej wrote:
> From: Yunus Bas <y.bas@phytec.de>
>
> The proper way to handle partly used MFD devices are to describe all MFD
> subdevices in the devicetree and disable the not used ones. This
> suppresses any warnings that may arise as a result.
>
> Signed-off-by: Yunus Bas <y.bas@phytec.de>
> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
Use subject prefix like
ARM: dts: imx6qdl-phytec: ...
Shawn
> ---
> arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 5 +++++
> arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 10 ++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> index 2ec154756bbc..3590f439adf5 100644
> --- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> @@ -213,6 +213,11 @@ pmic_rtc: rtc {
> da9063_wdog: wdt {
> compatible = "dlg,da9063-watchdog";
> };
> +
> + onkey {
> + compatible = "dlg,da9063-onkey";
> + status = "disabled";
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
> index 94b254bfd054..28a805384668 100644
> --- a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
> @@ -116,6 +116,16 @@ watchdog {
> dlg,use-sw-pm;
> };
>
> + thermal {
> + compatible = "dlg,da9062-thermal";
> + status = "disabled";
> + };
> +
> + gpio {
> + compatible = "dlg,da9062-gpio";
> + status = "disabled";
> + };
> +
> regulators {
> vdd_arm: buck1 {
> regulator-name = "vdd_arm";
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH RESEND 1/2] ARM: dts: imx6: phyFLEX: add missing pmic mfd subdevices
From: Shawn Guo @ 2022-01-26 9:24 UTC (permalink / raw)
To: Andrej Picej
Cc: robh+dt, s.hauer, devicetree, festevam, kernel, linux-kernel,
y.bas
In-Reply-To: <20211216115529.2331475-1-andrej.picej@norik.com>
On Thu, Dec 16, 2021 at 12:55:28PM +0100, Andrej Picej wrote:
> phyFLEX PMIC DA9063 has also RTC and watchdog support. Add both
> mfd subdevices so they can be used.
>
> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
> ---
> arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> index f3236204cb5a..2ec154756bbc 100644
> --- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> @@ -205,6 +205,14 @@ vdd_mx6_high_reg: ldo11 {
> regulator-always-on;
> };
> };
> +
> + pmic_rtc: rtc {
Maybe a more specific label like the following?
da9063_rtc: rtc
And it's more aligned with da9063_wdog below.
> + compatible = "dlg,da9063-rtc";
> + };
> +
> + da9063_wdog: wdt {
watchdog for the node name.
Shawn
> + compatible = "dlg,da9063-watchdog";
> + };
> };
> };
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
From: Sylwester Nawrocki @ 2022-01-26 9:21 UTC (permalink / raw)
To: Alim Akhtar, 'Krzysztof Kozlowski', linux-arm-kernel,
linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, linux-samsung-soc, pankaj.dubey, sboyd
In-Reply-To: <063601d81281$5492d620$fdb88260$@samsung.com>
Hi,
On 26.01.2022 07:52, Alim Akhtar wrote:
>>
>> Thanks, applied DTS/soc and pinctrl patches.
>>
> Thanks Krzysztof
>
>> I expect Sylwester will pick up the clock ones. Otherwise please let me know
>> to pick it up as well.
>>
> Hi Sylwester, hope you will be taking clock changes, or let Krzysztof know otherwise.
> Thanks
Krzysztof, can you also take the clk patches through your tree?
If you prefer to avoid it I will create a topic branch with the
clk headers and DT bindings documentation.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
From: Krzysztof Kozlowski @ 2022-01-26 9:19 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, s.nawrocki, linux-samsung-soc,
pankaj.dubey, sboyd
In-Reply-To: <063501d81281$10e5b3c0$32b11b40$@samsung.com>
On 26/01/2022 07:50, Alim Akhtar wrote:
> Hi Krzysztof
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>> Sent: Tuesday, January 25, 2022 10:56 PM
>> To: Alim Akhtar <alim.akhtar@samsung.com>; linux-arm-
>> kernel@lists.infradead.org; linux-kernel@vger.kernel.org
>> Cc: soc@kernel.org; linux-clk@vger.kernel.org; devicetree@vger.kernel.org;
>> olof@lixom.net; arnd@arndb.de; linus.walleij@linaro.org;
>> catalin.marinas@arm.com; robh+dt@kernel.org; s.nawrocki@samsung.com;
>> linux-samsung-soc@vger.kernel.org; pankaj.dubey@samsung.com;
>> sboyd@kernel.org
>> Subject: Re: [PATCH v5 00/16] Add support for Tesla Full Self-Driving (FSD) SoC
>>
>> On 25/01/2022 18:12, Krzysztof Kozlowski wrote:
>>> On 24/01/2022 15:16, Alim Akhtar wrote:
>>>> Adds basic support for the Tesla Full Self-Driving (FSD) SoC. This
>>>> SoC contains three clusters of four Cortex-A72 CPUs, as well as
>>>> several IPs.
>>>>
>>>> Patches 1 to 9 provide support for the clock controller (which is
>>>> designed similarly to Exynos SoCs).
>>>>
>>>> The remaining changes provide pinmux support, initial device tree support.
>>>>
>>>> - Changes since v4
>>>> * fixed 'make dtbs_check' warnings on patch 14/16
>>>>
>>>> - Changes since v3
>>>> * Addressed Stefen's review comments on patch 14/16
>>>> * Fixed kernel test robot warning on patch 04/16
>>>> * rebsaed this series on Krzysztof's pinmux new binding schema work
>>>> [1]
>>>>
>>>> - Changes since v2
>>>> * Addressed Krzysztof's and Stephen's review comments
>>>> * Added Reviewed-by and Acked-by tags
>>>> * Rebased on next-20220120
>>>>
>>>> - Changes since v1
>>>> * fixed make dt_binding_check error as pointed by Rob
>>>> * Addressed Krzysztof's and Rob's review comments
>>>> * Added Reviewed-by and Acked-by tags
>>>> * Dropped SPI, MCT and ADC from this series (to be posted in small
>>>> sets)
>>>>
>>>> NOTE: These patches are based on Krzysztof's pinmux for-next branch
>>>> commit 832ae134ccc1 ("pinctrl: samsung: add support for Exynos850 and
>>>> ExynosAutov9 wake-ups") [1]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/samsung.git/l
>>>> og/?h=for-next
>>>>
>>>>
>>>
>>> Thanks, applied DTS/soc and pinctrl patches.
>>>
>>> I expect Sylwester will pick up the clock ones. Otherwise please let
>>> me know to pick it up as well.
>>
>> I forgot that clock macros are used in DTS. This does not compile and I cannot
>> take drivers into DTS branch.
>>
>> Alim,
>> DTS changes dropped. Please resend with the same trick we did for
>> Exynos850 board - hard-coded clock IDs as defines. See:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/diff/arch/arm6
>> 4/boot/dts/exynos/exynos850.dtsi?h=samsung-dt64-5.17-
>> 2&id=e3493220fd3e474abcdcefbe14fb60485097ce06
>>
> Ok, I will resend patch 14 and 15 (DTS changes) only as suggested above.
I see Sylwester acked clock patches, so I will take them. No need to
resend, I'll organize the patches so they will compile.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v10 0/4] clk: meson: add a sub EMMC clock controller support
From: Jerome Brunet @ 2022-01-26 9:14 UTC (permalink / raw)
To: Liang Yang, Neil Armstrong, Kevin Hilman, Michael Turquette,
Stephen Boyd, Rob Herring, linux-clk
Cc: Martin Blumenstingl, Jianxin Pan, Victor Wan, XianWei Zhao,
Kelvin Zhang, BiChao Zheng, YongHui Yu, linux-arm-kernel,
linux-amlogic, linux-kernel, devicetree
In-Reply-To: <6eb4f247-367b-d460-6314-fc94ccd00b89@amlogic.com>
On Wed 26 Jan 2022 at 17:08, Liang Yang <liang.yang@amlogic.com> wrote:
> Hi Neil,
>
> On 2022/1/25 22:54, Neil Armstrong wrote:
>> [ EXTERNAL EMAIL ]
>> Hi Liang,
>> On 21/01/2022 08:45, Liang Yang wrote:
>>> This driver will add a MMC clock controller driver support.
>>> The original idea about adding a clock controller is during the
>>> discussion in the NAND driver mainline effort[1].
>>>
>>> This driver is tested in the S400 board (AXG platform) with NAND driver.
>> Thanks a lot for providing a fixed and updated version of this serie.
>> After some chat with Jerome and Kevin, it seems the way the eMMC clock
>> reuse
>> for NAND was designed nearly 4 years doesn't look accurate anymore.
>> Having a separate clk driver designed to replace the eMMC node when NAND
>> is
>> used on the board seems over engineered.
>> Actually having the clock code you add in this serie _but_ directly in
>> the NAND looks far better, and more coherent since having Linux runtime
>> detection of eMMC vs NAND will never happen and even this serie required
>> some DT modification from the bootloader.
>> I'll let Jerome or Kevin add more details if they want, but I think you
>> should resurrect
>> the work you pushed in [1] & [2] but:
>> - passing the eMMC clk registers as a third "reg" cell
> Does it just need to define a 'reg' resource in NFC node and not 'syscon'
> here?
Yes
>> - passing the same "clocks" phandle as the eMMC node
>> - adding the eMMC clock code in the NAND driver directly
>> I'm open to discussions if you consider the current approach is still
>> superior.
>
> I don't have persuasive ideas, but really it shares the common clock
> implementation for both NFC and EMMC. and we don't need to paste the
> same code in NFC and EMMC.
You don't need to copy everything. If I understood correctly, all the
Rx/Tx should not be needed. Yes, there is some duplication as it stands but
it allows to avoid coupling the MMC and NAND driver. We can still think
about optimizing things later on. Let's get something simply working
first.
>
>> Thanks,
>> Neil
>> [1]
>> https://lore.kernel.org/r/20220106033130.37623-1-liang.yang@amlogic.com
>> [2] https://lore.kernel.org/r/20220106032504.23310-1-liang.yang@amlogic.com
>>
>>>
>>> Changes since v9 [10]
>>> - use clk_parent_data instead of parent_names
>>>
>>> Changes since v8 [9]
>>> - use MESON_SCLK_ONE_BASED instead of CLK_DIVIDER_ONE_BASED
>>> - use struct_size to caculate onecell_data
>>> - add clk-phase-delay.h
>>> - define CLK_DELAY_STEP_PS_GX and CLK_DELAY_STEP_PS_AXG
>>>
>>> Changes since v7 [8]
>>> - move meson_clk_get_phase_delay_data() from header to driver
>>> - CONFIG sclk-div with COMMON_CLK_AMLOGIC instead of COMMON_CLK_AMLOGIC_AUDIO
>>> - remove onecell date and ID for internal MUX clk
>>> - use helper for functions for ONE_BASED in sclk-div
>>> - add ONE_BASED support for duty cycle
>>>
>>> Changes since v6 [7]:
>>> - add one based support for sclk divier
>>> - alloc sclk in probe for multiple instance
>>> - fix coding styles
>>>
>>> Changes since v5 [6]:
>>> - remove divider ops with .init and use sclk_div instead
>>> - drop CLK_DIVIDER_ROUND_CLOSEST in mux and div
>>> - drop the useless type cast
>>>
>>> Changes since v4 [5]:
>>> - use struct parm in phase delay driver
>>> - remove 0 delay releted part in phase delay driver
>>> - don't rebuild the parent name once again
>>> - add divider ops with .init
>>>
>>> Changes since v3 [4]:
>>> - separate clk-phase-delay driver
>>> - replace clk_get_rate() with clk_hw_get_rate()
>>> - collect Rob's R-Y
>>> - drop 'meson-' prefix from compatible string
>>>
>>> Changes since v2 [3]:
>>> - squash dt-binding clock-id patch
>>> - update license
>>> - fix alignment
>>> - construct a clk register helper() function
>>>
>>> Changes since v1 [2]:
>>> - implement phase clock
>>> - update compatible name
>>> - adjust file name
>>> - divider probe() into small functions, and re-use them
>>>
>>> [1] https://lkml.kernel.org/r/20180628090034.0637a062@xps13
>>> [2] https://lkml.kernel.org/r/20180703145716.31860-1-yixun.lan@amlogic.com
>>> [3] https://lkml.kernel.org/r/20180710163658.6175-1-yixun.lan@amlogic.com
>>> [4] https://lkml.kernel.org/r/20180712211244.11428-1-yixun.lan@amlogic.com
>>> [5] https://lkml.kernel.org/r/20180809070724.11935-4-yixun.lan@amlogic.com
>>> [6] https://lkml.kernel.org/r/1539839245-13793-1-git-send-email-jianxin.pan@amlogic.com
>>> [7] https://lkml.kernel.org/r/1541089855-19356-1-git-send-email-jianxin.pan@amlogic.com
>>> [8] https://lkml.kernel.org/r/1544457877-51301-1-git-send-email-jianxin.pan@amlogic.com
>>> [9] https://lkml.kernel.org/r/1545063850-21504-1-git-send-email-jianxin.pan@amlogic.com
>>> [10] https://lore.kernel.org/all/20220113115745.45826-1-liang.yang@amlogic.com/
>>> Liang Yang (4):
>>> clk: meson: add one based divider support for sclk
>>> clk: meson: add emmc sub clock phase delay driver
>>> clk: meson: add DT documentation for emmc clock controller
>>> clk: meson: add sub MMC clock controller driver
>>>
>>> .../bindings/clock/amlogic,mmc-clkc.yaml | 64 ++++
>>> drivers/clk/meson/Kconfig | 18 ++
>>> drivers/clk/meson/Makefile | 2 +
>>> drivers/clk/meson/clk-phase-delay.c | 69 ++++
>>> drivers/clk/meson/clk-phase-delay.h | 20 ++
>>> drivers/clk/meson/mmc-clkc.c | 302 ++++++++++++++++++
>>> drivers/clk/meson/sclk-div.c | 59 ++--
>>> drivers/clk/meson/sclk-div.h | 3 +
>>> include/dt-bindings/clock/amlogic,mmc-clkc.h | 14 +
>>> 9 files changed, 529 insertions(+), 22 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/clock/amlogic,mmc-clkc.yaml
>>> create mode 100644 drivers/clk/meson/clk-phase-delay.c
>>> create mode 100644 drivers/clk/meson/clk-phase-delay.h
>>> create mode 100644 drivers/clk/meson/mmc-clkc.c
>>> create mode 100644 include/dt-bindings/clock/amlogic,mmc-clkc.h
>>>
>> .
^ permalink raw reply
* Re: [PATCH v5 10/16] clk: samsung: fsd: Add cam_csi block clock information
From: Sylwester Nawrocki @ 2022-01-26 9:18 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Sathyakam M
In-Reply-To: <20220124141644.71052-11-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Adds clocks for BLK_CAM_CSI block, this is needed for CSI to work.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Sathyakam M <sathya@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 09/16] clk: samsung: fsd: Add cmu_mfc block clock information
From: Sylwester Nawrocki @ 2022-01-26 9:18 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Smitha T Murthy
In-Reply-To: <20220124141644.71052-10-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Adds cmu_mfc clock related code, these clocks are
> required for MFC IP.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 08/16] clk: samsung: fsd: Add cmu_imem block clock information
From: Sylwester Nawrocki @ 2022-01-26 9:17 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Arjun K V, Tauseef Nomani
In-Reply-To: <20220124141644.71052-9-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Adds cmu_imem clock related code, imem block contains IPs
> like WDT, DMA, TMU etc, these clocks are required for such
> IP function.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Arjun K V <arjun.kv@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Tauseef Nomani <tauseef.n@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 07/16] clk: samsung: fsd: Add cmu_fsys1 clock information
From: Sylwester Nawrocki @ 2022-01-26 9:17 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Ajay Kumar
In-Reply-To: <20220124141644.71052-8-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Adds cmu_fsys1 block clock information which are needed
> for PCIe IPs in block FSYS1.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 06/16] clk: samsung: fsd: Add cmu_fsys0 clock information
From: Sylwester Nawrocki @ 2022-01-26 9:15 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Shradha Todi, Jayati Sahu,
Ajay Kumar
In-Reply-To: <20220124141644.71052-7-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> CMU_FSYS0 block has IPs like UFS, EQOS, PCIe etc, lets add
> the related clock information for the same.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> Signed-off-by: Jayati Sahu <jayati.sahu@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
^ permalink raw reply
* Re: [PATCH v5 05/16] clk: samsung: fsd: Add cmu_peric block clock information
From: Sylwester Nawrocki @ 2022-01-26 9:15 UTC (permalink / raw)
To: Alim Akhtar, linux-arm-kernel, linux-kernel
Cc: soc, linux-clk, devicetree, olof, arnd, linus.walleij,
catalin.marinas, robh+dt, krzysztof.kozlowski, linux-samsung-soc,
pankaj.dubey, sboyd, linux-fsd, Aswani Reddy, Niyas Ahmed S T,
Chandrasekar R, Jayati Sahu, Sriranjani P, Ajay Kumar
In-Reply-To: <20220124141644.71052-6-alim.akhtar@samsung.com>
On 24.01.2022 15:16, Alim Akhtar wrote:
> Add CMU_PERIC block clock information needed for various IPs
> functions found in this block.
>
> Cc: linux-fsd@tesla.com
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
> Signed-off-by: Aswani Reddy <aswani.reddy@samsung.com>
> Signed-off-by: Niyas Ahmed S T <niyas.ahmed@samsung.com>
> Signed-off-by: Chandrasekar R <rcsekar@samsung.com>
> Signed-off-by: Jayati Sahu <jayati.sahu@samsung.com>
> Signed-off-by: Sriranjani P <sriranjani.p@samsung.com>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.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