All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 0/6] Add support for Rpi4b + Cirrus Lochnagar2 and CS47L15
@ 2021-01-08 16:04 ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

This set of patches provides support for using the Raspberry Pi 4b with
a Cirrus Logic Lochnagar 2 audio development platform plus Cirrus Logic
CS47L15 codec.

Patches are needed to audio-graph-card to enable support for setting the
component sysclks and plls. These are not specific to CS47L15 - several
Cirrus and non-Cirrus codecs also require component clock setup, typically
for larger codecs with multiple internal clocking options and clock domains.

The codec sysclks and plls cannot be placed under the clock framework because
they are typically I2C/SPI/Soundwire-connected peripherals and access to the
registers would cause a nested get of the bus clock. The clock framework does
not support this and it would result in a deadlock.

Richard Fitzgerald (6):
  of: base: Add of_count_phandle_with_fixed_args()
  dt-bindings: audio-graph-card: Add plls and sysclks properties
  ASoC: audio-graph-card: Support setting component plls and sysclks
  ASoC: madera: Allow codecs to be selected from kernel config
  ASoC: madera: Export clock config defines to dt-bindings
  ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15

 .../bindings/sound/audio-graph.yaml           |  46 ++++
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 +++++++++++++++
 drivers/of/base.c                             |  73 ++++--
 include/dt-bindings/sound/madera.h            |  60 +++++
 include/linux/of.h                            |   9 +
 include/sound/simple_card_utils.h             |  25 ++
 sound/soc/codecs/Kconfig                      |  10 +-
 sound/soc/codecs/madera.h                     |  56 +----
 sound/soc/generic/audio-graph-card.c          |  13 +
 sound/soc/generic/simple-card-utils.c         | 238 ++++++++++++++++++
 13 files changed, 836 insertions(+), 83 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

-- 
2.20.1


^ permalink raw reply	[flat|nested] 64+ messages in thread

* [PATCH v4 0/6] Add support for Rpi4b + Cirrus Lochnagar2 and CS47L15
@ 2021-01-08 16:04 ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

This set of patches provides support for using the Raspberry Pi 4b with
a Cirrus Logic Lochnagar 2 audio development platform plus Cirrus Logic
CS47L15 codec.

Patches are needed to audio-graph-card to enable support for setting the
component sysclks and plls. These are not specific to CS47L15 - several
Cirrus and non-Cirrus codecs also require component clock setup, typically
for larger codecs with multiple internal clocking options and clock domains.

The codec sysclks and plls cannot be placed under the clock framework because
they are typically I2C/SPI/Soundwire-connected peripherals and access to the
registers would cause a nested get of the bus clock. The clock framework does
not support this and it would result in a deadlock.

Richard Fitzgerald (6):
  of: base: Add of_count_phandle_with_fixed_args()
  dt-bindings: audio-graph-card: Add plls and sysclks properties
  ASoC: audio-graph-card: Support setting component plls and sysclks
  ASoC: madera: Allow codecs to be selected from kernel config
  ASoC: madera: Export clock config defines to dt-bindings
  ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15

 .../bindings/sound/audio-graph.yaml           |  46 ++++
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 +++++++++++++++
 drivers/of/base.c                             |  73 ++++--
 include/dt-bindings/sound/madera.h            |  60 +++++
 include/linux/of.h                            |   9 +
 include/sound/simple_card_utils.h             |  25 ++
 sound/soc/codecs/Kconfig                      |  10 +-
 sound/soc/codecs/madera.h                     |  56 +----
 sound/soc/generic/audio-graph-card.c          |  13 +
 sound/soc/generic/simple-card-utils.c         | 238 ++++++++++++++++++
 13 files changed, 836 insertions(+), 83 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

-- 
2.20.1


^ permalink raw reply	[flat|nested] 64+ messages in thread

* [PATCH v4 0/6] Add support for Rpi4b + Cirrus Lochnagar2 and CS47L15
@ 2021-01-08 16:04 ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

This set of patches provides support for using the Raspberry Pi 4b with
a Cirrus Logic Lochnagar 2 audio development platform plus Cirrus Logic
CS47L15 codec.

Patches are needed to audio-graph-card to enable support for setting the
component sysclks and plls. These are not specific to CS47L15 - several
Cirrus and non-Cirrus codecs also require component clock setup, typically
for larger codecs with multiple internal clocking options and clock domains.

The codec sysclks and plls cannot be placed under the clock framework because
they are typically I2C/SPI/Soundwire-connected peripherals and access to the
registers would cause a nested get of the bus clock. The clock framework does
not support this and it would result in a deadlock.

Richard Fitzgerald (6):
  of: base: Add of_count_phandle_with_fixed_args()
  dt-bindings: audio-graph-card: Add plls and sysclks properties
  ASoC: audio-graph-card: Support setting component plls and sysclks
  ASoC: madera: Allow codecs to be selected from kernel config
  ASoC: madera: Export clock config defines to dt-bindings
  ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15

 .../bindings/sound/audio-graph.yaml           |  46 ++++
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 +++++++++++++++
 drivers/of/base.c                             |  73 ++++--
 include/dt-bindings/sound/madera.h            |  60 +++++
 include/linux/of.h                            |   9 +
 include/sound/simple_card_utils.h             |  25 ++
 sound/soc/codecs/Kconfig                      |  10 +-
 sound/soc/codecs/madera.h                     |  56 +----
 sound/soc/generic/audio-graph-card.c          |  13 +
 sound/soc/generic/simple-card-utils.c         | 238 ++++++++++++++++++
 13 files changed, 836 insertions(+), 83 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* [PATCH v4 1/6] of: base: Add of_count_phandle_with_fixed_args()
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:04   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald, Rob Herring

Add an equivalent of of_count_phandle_with_args() for fixed argument
sets, to pair with of_parse_phandle_with_fixed_args().

The existing of_count_phandle_with_args() is modified to be a
private function that handles both cases and the public functions
are trivial wrappers round that.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 drivers/of/base.c  | 73 +++++++++++++++++++++++++++++++---------------
 include/linux/of.h |  9 ++++++
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..c5ff2524bf40 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1720,34 +1720,22 @@ int of_parse_phandle_with_fixed_args(const struct device_node *np,
 }
 EXPORT_SYMBOL(of_parse_phandle_with_fixed_args);
 
-/**
- * of_count_phandle_with_args() - Find the number of phandles references in a property
- * @np:		pointer to a device tree node containing a list
- * @list_name:	property name that contains a list
- * @cells_name:	property name that specifies phandles' arguments count
- *
- * Returns the number of phandle + argument tuples within a property. It
- * is a typical pattern to encode a list of phandle and variable
- * arguments into a single property. The number of arguments is encoded
- * by a property in the phandle-target node. For example, a gpios
- * property would contain a list of GPIO specifies consisting of a
- * phandle and 1 or more arguments. The number of arguments are
- * determined by the #gpio-cells property in the node pointed to by the
- * phandle.
- */
-int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
-				const char *cells_name)
+static int __of_count_phandle_with_args(const struct device_node *np,
+					const char *list_name,
+					const char *cells_name,
+					int cells_count)
 {
 	struct of_phandle_iterator it;
 	int rc, cur_index = 0;
 
 	/*
-	 * If cells_name is NULL we assume a cell count of 0. This makes
-	 * counting the phandles trivial as each 32bit word in the list is a
-	 * phandle and no arguments are to consider. So we don't iterate through
-	 * the list but just use the length to determine the phandle count.
+	 * If cells_count < 0 and cells_name is NULL we assume a cell count
+	 * of 0. A zero cell count makes counting the phandles trivial as each
+	 * 32bit word in the list is a phandle and no arguments are to consider.
+	 * So we don't iterate through the list but just use the length to
+	 * determine the phandle count.
 	 */
-	if (!cells_name) {
+	if ((cells_count < 0 && !cells_name) || cells_count == 0) {
 		const __be32 *list;
 		int size;
 
@@ -1758,7 +1746,7 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 		return size / sizeof(*list);
 	}
 
-	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, -1);
+	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, cells_count);
 	if (rc)
 		return rc;
 
@@ -1770,8 +1758,47 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 
 	return cur_index;
 }
+
+/**
+ * of_count_phandle_with_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cells_name:	property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
+				const char *cells_name)
+{
+	return __of_count_phandle_with_args(np, list_name, cells_name, -1);
+}
 EXPORT_SYMBOL(of_count_phandle_with_args);
 
+/**
+ * of_count_phandle_with_fixed_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cell_count: number of argument cells following the phandle
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property.
+ */
+int of_count_phandle_with_fixed_args(const struct device_node *np,
+				     const char *list_name,
+				     int cells_count)
+{
+	return __of_count_phandle_with_args(np, list_name, NULL, cells_count);
+}
+EXPORT_SYMBOL(of_count_phandle_with_fixed_args);
+
 /**
  * __of_add_property - Add a property to a node without lock operations
  */
diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..4f09d644a803 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -377,6 +377,8 @@ extern int of_parse_phandle_with_fixed_args(const struct device_node *np,
 	struct of_phandle_args *out_args);
 extern int of_count_phandle_with_args(const struct device_node *np,
 	const char *list_name, const char *cells_name);
+extern int of_count_phandle_with_fixed_args(const struct device_node *np,
+	const char *list_name, int cells_count);
 
 /* phandle iterator functions */
 extern int of_phandle_iterator_init(struct of_phandle_iterator *it,
@@ -888,6 +890,13 @@ static inline int of_count_phandle_with_args(struct device_node *np,
 	return -ENOSYS;
 }
 
+static inline int of_count_phandle_with_fixed_args(const struct device_node *np,
+						   const char *list_name,
+						   int cells_count)
+{
+	return -ENOSYS;
+}
+
 static inline int of_phandle_iterator_init(struct of_phandle_iterator *it,
 					   const struct device_node *np,
 					   const char *list_name,
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 1/6] of: base: Add of_count_phandle_with_fixed_args()
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, Rob Herring, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Add an equivalent of of_count_phandle_with_args() for fixed argument
sets, to pair with of_parse_phandle_with_fixed_args().

The existing of_count_phandle_with_args() is modified to be a
private function that handles both cases and the public functions
are trivial wrappers round that.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 drivers/of/base.c  | 73 +++++++++++++++++++++++++++++++---------------
 include/linux/of.h |  9 ++++++
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..c5ff2524bf40 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1720,34 +1720,22 @@ int of_parse_phandle_with_fixed_args(const struct device_node *np,
 }
 EXPORT_SYMBOL(of_parse_phandle_with_fixed_args);
 
-/**
- * of_count_phandle_with_args() - Find the number of phandles references in a property
- * @np:		pointer to a device tree node containing a list
- * @list_name:	property name that contains a list
- * @cells_name:	property name that specifies phandles' arguments count
- *
- * Returns the number of phandle + argument tuples within a property. It
- * is a typical pattern to encode a list of phandle and variable
- * arguments into a single property. The number of arguments is encoded
- * by a property in the phandle-target node. For example, a gpios
- * property would contain a list of GPIO specifies consisting of a
- * phandle and 1 or more arguments. The number of arguments are
- * determined by the #gpio-cells property in the node pointed to by the
- * phandle.
- */
-int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
-				const char *cells_name)
+static int __of_count_phandle_with_args(const struct device_node *np,
+					const char *list_name,
+					const char *cells_name,
+					int cells_count)
 {
 	struct of_phandle_iterator it;
 	int rc, cur_index = 0;
 
 	/*
-	 * If cells_name is NULL we assume a cell count of 0. This makes
-	 * counting the phandles trivial as each 32bit word in the list is a
-	 * phandle and no arguments are to consider. So we don't iterate through
-	 * the list but just use the length to determine the phandle count.
+	 * If cells_count < 0 and cells_name is NULL we assume a cell count
+	 * of 0. A zero cell count makes counting the phandles trivial as each
+	 * 32bit word in the list is a phandle and no arguments are to consider.
+	 * So we don't iterate through the list but just use the length to
+	 * determine the phandle count.
 	 */
-	if (!cells_name) {
+	if ((cells_count < 0 && !cells_name) || cells_count == 0) {
 		const __be32 *list;
 		int size;
 
@@ -1758,7 +1746,7 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 		return size / sizeof(*list);
 	}
 
-	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, -1);
+	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, cells_count);
 	if (rc)
 		return rc;
 
@@ -1770,8 +1758,47 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 
 	return cur_index;
 }
+
+/**
+ * of_count_phandle_with_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cells_name:	property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
+				const char *cells_name)
+{
+	return __of_count_phandle_with_args(np, list_name, cells_name, -1);
+}
 EXPORT_SYMBOL(of_count_phandle_with_args);
 
+/**
+ * of_count_phandle_with_fixed_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cell_count: number of argument cells following the phandle
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property.
+ */
+int of_count_phandle_with_fixed_args(const struct device_node *np,
+				     const char *list_name,
+				     int cells_count)
+{
+	return __of_count_phandle_with_args(np, list_name, NULL, cells_count);
+}
+EXPORT_SYMBOL(of_count_phandle_with_fixed_args);
+
 /**
  * __of_add_property - Add a property to a node without lock operations
  */
diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..4f09d644a803 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -377,6 +377,8 @@ extern int of_parse_phandle_with_fixed_args(const struct device_node *np,
 	struct of_phandle_args *out_args);
 extern int of_count_phandle_with_args(const struct device_node *np,
 	const char *list_name, const char *cells_name);
+extern int of_count_phandle_with_fixed_args(const struct device_node *np,
+	const char *list_name, int cells_count);
 
 /* phandle iterator functions */
 extern int of_phandle_iterator_init(struct of_phandle_iterator *it,
@@ -888,6 +890,13 @@ static inline int of_count_phandle_with_args(struct device_node *np,
 	return -ENOSYS;
 }
 
+static inline int of_count_phandle_with_fixed_args(const struct device_node *np,
+						   const char *list_name,
+						   int cells_count)
+{
+	return -ENOSYS;
+}
+
 static inline int of_phandle_iterator_init(struct of_phandle_iterator *it,
 					   const struct device_node *np,
 					   const char *list_name,
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 1/6] of: base: Add of_count_phandle_with_fixed_args()
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Add an equivalent of of_count_phandle_with_args() for fixed argument
sets, to pair with of_parse_phandle_with_fixed_args().

The existing of_count_phandle_with_args() is modified to be a
private function that handles both cases and the public functions
are trivial wrappers round that.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 drivers/of/base.c  | 73 +++++++++++++++++++++++++++++++---------------
 include/linux/of.h |  9 ++++++
 2 files changed, 59 insertions(+), 23 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 161a23631472..c5ff2524bf40 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1720,34 +1720,22 @@ int of_parse_phandle_with_fixed_args(const struct device_node *np,
 }
 EXPORT_SYMBOL(of_parse_phandle_with_fixed_args);
 
-/**
- * of_count_phandle_with_args() - Find the number of phandles references in a property
- * @np:		pointer to a device tree node containing a list
- * @list_name:	property name that contains a list
- * @cells_name:	property name that specifies phandles' arguments count
- *
- * Returns the number of phandle + argument tuples within a property. It
- * is a typical pattern to encode a list of phandle and variable
- * arguments into a single property. The number of arguments is encoded
- * by a property in the phandle-target node. For example, a gpios
- * property would contain a list of GPIO specifies consisting of a
- * phandle and 1 or more arguments. The number of arguments are
- * determined by the #gpio-cells property in the node pointed to by the
- * phandle.
- */
-int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
-				const char *cells_name)
+static int __of_count_phandle_with_args(const struct device_node *np,
+					const char *list_name,
+					const char *cells_name,
+					int cells_count)
 {
 	struct of_phandle_iterator it;
 	int rc, cur_index = 0;
 
 	/*
-	 * If cells_name is NULL we assume a cell count of 0. This makes
-	 * counting the phandles trivial as each 32bit word in the list is a
-	 * phandle and no arguments are to consider. So we don't iterate through
-	 * the list but just use the length to determine the phandle count.
+	 * If cells_count < 0 and cells_name is NULL we assume a cell count
+	 * of 0. A zero cell count makes counting the phandles trivial as each
+	 * 32bit word in the list is a phandle and no arguments are to consider.
+	 * So we don't iterate through the list but just use the length to
+	 * determine the phandle count.
 	 */
-	if (!cells_name) {
+	if ((cells_count < 0 && !cells_name) || cells_count == 0) {
 		const __be32 *list;
 		int size;
 
@@ -1758,7 +1746,7 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 		return size / sizeof(*list);
 	}
 
-	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, -1);
+	rc = of_phandle_iterator_init(&it, np, list_name, cells_name, cells_count);
 	if (rc)
 		return rc;
 
@@ -1770,8 +1758,47 @@ int of_count_phandle_with_args(const struct device_node *np, const char *list_na
 
 	return cur_index;
 }
+
+/**
+ * of_count_phandle_with_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cells_name:	property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int of_count_phandle_with_args(const struct device_node *np, const char *list_name,
+				const char *cells_name)
+{
+	return __of_count_phandle_with_args(np, list_name, cells_name, -1);
+}
 EXPORT_SYMBOL(of_count_phandle_with_args);
 
+/**
+ * of_count_phandle_with_fixed_args() - Find the number of phandles references in a property
+ * @np:		pointer to a device tree node containing a list
+ * @list_name:	property name that contains a list
+ * @cell_count: number of argument cells following the phandle
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property.
+ */
+int of_count_phandle_with_fixed_args(const struct device_node *np,
+				     const char *list_name,
+				     int cells_count)
+{
+	return __of_count_phandle_with_args(np, list_name, NULL, cells_count);
+}
+EXPORT_SYMBOL(of_count_phandle_with_fixed_args);
+
 /**
  * __of_add_property - Add a property to a node without lock operations
  */
diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..4f09d644a803 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -377,6 +377,8 @@ extern int of_parse_phandle_with_fixed_args(const struct device_node *np,
 	struct of_phandle_args *out_args);
 extern int of_count_phandle_with_args(const struct device_node *np,
 	const char *list_name, const char *cells_name);
+extern int of_count_phandle_with_fixed_args(const struct device_node *np,
+	const char *list_name, int cells_count);
 
 /* phandle iterator functions */
 extern int of_phandle_iterator_init(struct of_phandle_iterator *it,
@@ -888,6 +890,13 @@ static inline int of_count_phandle_with_args(struct device_node *np,
 	return -ENOSYS;
 }
 
+static inline int of_count_phandle_with_fixed_args(const struct device_node *np,
+						   const char *list_name,
+						   int cells_count)
+{
+	return -ENOSYS;
+}
+
 static inline int of_phandle_iterator_init(struct of_phandle_iterator *it,
 					   const struct device_node *np,
 					   const char *list_name,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:04   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

The audio-graph-card driver has properties for configuring the clocking
for DAIs within a component, but is missing properties for setting
up the PLLs and sysclks of the component.

This patch adds the two new properties 'plls' and 'sysclks' so that the
audio-graph-driver can fully configure the component clocking.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
index 4b46794e5153..9e0819205a17 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -39,6 +39,52 @@ properties:
   mic-det-gpio:
     maxItems: 1
 
+  plls:
+    description: |
+      A list of component pll settings. There are 4 cells per PLL setting:
+        - phandle to the node of the codec or cpu component,
+        - component PLL id,
+        - component clock source id,
+        - frequency (in Hz) of the PLL output clock.
+      The PLL id and clock source id are specific to the particular component
+      so see the relevant component driver for the ids. Typically the
+      clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several plls
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  plls-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the plls property.
+
+  sysclks:
+    description: |
+      A list of component sysclk settings. There are 4 cells per sysclk
+      setting:
+        - phandle to the node of the codec or cpu component,
+        - component sysclk id,
+        - component clock source id,
+        - direction of the clock: 0 if the clock is an input to the component,
+          1 if it is an output.
+      The sysclk id and clock source id are specific to the particular
+      component so see the relevant component driver for the ids. Typically
+      the clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several sysclks
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  sysclks-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the sysclks property.
+
+dependencies:
+  plls: [ plls-clocks ]
+  sysclks: [ sysclks-clocks ]
+
 required:
   - dais
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

The audio-graph-card driver has properties for configuring the clocking
for DAIs within a component, but is missing properties for setting
up the PLLs and sysclks of the component.

This patch adds the two new properties 'plls' and 'sysclks' so that the
audio-graph-driver can fully configure the component clocking.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
index 4b46794e5153..9e0819205a17 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -39,6 +39,52 @@ properties:
   mic-det-gpio:
     maxItems: 1
 
+  plls:
+    description: |
+      A list of component pll settings. There are 4 cells per PLL setting:
+        - phandle to the node of the codec or cpu component,
+        - component PLL id,
+        - component clock source id,
+        - frequency (in Hz) of the PLL output clock.
+      The PLL id and clock source id are specific to the particular component
+      so see the relevant component driver for the ids. Typically the
+      clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several plls
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  plls-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the plls property.
+
+  sysclks:
+    description: |
+      A list of component sysclk settings. There are 4 cells per sysclk
+      setting:
+        - phandle to the node of the codec or cpu component,
+        - component sysclk id,
+        - component clock source id,
+        - direction of the clock: 0 if the clock is an input to the component,
+          1 if it is an output.
+      The sysclk id and clock source id are specific to the particular
+      component so see the relevant component driver for the ids. Typically
+      the clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several sysclks
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  sysclks-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the sysclks property.
+
+dependencies:
+  plls: [ plls-clocks ]
+  sysclks: [ sysclks-clocks ]
+
 required:
   - dais
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

The audio-graph-card driver has properties for configuring the clocking
for DAIs within a component, but is missing properties for setting
up the PLLs and sysclks of the component.

This patch adds the two new properties 'plls' and 'sysclks' so that the
audio-graph-driver can fully configure the component clocking.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
index 4b46794e5153..9e0819205a17 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
@@ -39,6 +39,52 @@ properties:
   mic-det-gpio:
     maxItems: 1
 
+  plls:
+    description: |
+      A list of component pll settings. There are 4 cells per PLL setting:
+        - phandle to the node of the codec or cpu component,
+        - component PLL id,
+        - component clock source id,
+        - frequency (in Hz) of the PLL output clock.
+      The PLL id and clock source id are specific to the particular component
+      so see the relevant component driver for the ids. Typically the
+      clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several plls
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  plls-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the plls property.
+
+  sysclks:
+    description: |
+      A list of component sysclk settings. There are 4 cells per sysclk
+      setting:
+        - phandle to the node of the codec or cpu component,
+        - component sysclk id,
+        - component clock source id,
+        - direction of the clock: 0 if the clock is an input to the component,
+          1 if it is an output.
+      The sysclk id and clock source id are specific to the particular
+      component so see the relevant component driver for the ids. Typically
+      the clock source id indicates the pin the source clock is connected to.
+      The same phandle can appear in multiple entries so that several sysclks
+      can be set in the same component.
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+
+  sysclks-clocks:
+    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
+    description: |
+      A list of clock names giving the source clock for each setting
+      in the sysclks property.
+
+dependencies:
+  plls: [ plls-clocks ]
+  sysclks: [ sysclks-clocks ]
+
 required:
   - dais
 
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:04   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

Some codecs need plls and/or sysclks to be configured using the
snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
necessarily be converted to use the clock framework. If the codec is on
a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
But the clock framework does not support nested operations and this would
deadlock.

This patch adds new dt properties that list phandles of components with
the pll/sysclk settings to be applied. Multiple settings can be given for
the same phandle to allow for components with multiple clocks and plls.
The plls and sysclks are enabled when the card bias level moves to STANDBY
and disabled when it moves to OFF.

The implementation does not attempt to handle specifying complex clock
ordering interdependencies between components. The plls and sysclks are
applied to a component as it is passed to the card set_bias_level/
set_bias_level_post callbacks. It follows from this that the order
components are configured is the order that they are passed to those
callbacks.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/sound/simple_card_utils.h     |  25 +++
 sound/soc/generic/audio-graph-card.c  |  13 ++
 sound/soc/generic/simple-card-utils.c | 238 ++++++++++++++++++++++++++
 3 files changed, 276 insertions(+)

diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h
index ba4a3e1897b9..1f755250f9c7 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -38,6 +38,16 @@ struct asoc_simple_jack {
 	struct snd_soc_jack_gpio gpio;
 };
 
+struct asoc_simple_sysclk_pll {
+	struct device_node *node;
+	struct clk *clk;
+	int id;
+	int source;
+	unsigned int freq_out;
+	int dir;
+	bool enabled;
+};
+
 struct asoc_simple_priv {
 	struct snd_soc_card snd_card;
 	struct simple_dai_props {
@@ -59,6 +69,11 @@ struct asoc_simple_priv {
 	const struct snd_soc_ops *ops;
 	unsigned int dpcm_selectable:1;
 	unsigned int force_dpcm:1;
+
+	struct asoc_simple_sysclk_pll *sysclks;
+	int num_sysclks;
+	struct asoc_simple_sysclk_pll *plls;
+	int num_plls;
 };
 #define simple_priv_to_card(priv)	(&(priv)->snd_card)
 #define simple_priv_to_props(priv, i)	((priv)->dai_props + (i))
@@ -97,6 +112,14 @@ void asoc_simple_shutdown(struct snd_pcm_substream *substream);
 int asoc_simple_hw_params(struct snd_pcm_substream *substream,
 			  struct snd_pcm_hw_params *params);
 int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd);
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level);
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level);
+
 int asoc_simple_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
 				   struct snd_pcm_hw_params *params);
 
@@ -131,6 +154,8 @@ int asoc_simple_parse_widgets(struct snd_soc_card *card,
 				      char *prefix);
 int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 				   char *prefix);
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix);
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix);
 
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			       struct asoc_simple_jack *sjack,
diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c
index 16a04a678828..9aa15d5ecbd0 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -592,6 +592,19 @@ int graph_parse_of(struct asoc_simple_priv *priv, struct device *dev)
 
 	snd_soc_card_set_drvdata(card, priv);
 
+	ret = asoc_simple_parse_sysclks(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	ret = asoc_simple_parse_plls(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	if (priv->num_sysclks || priv->num_plls) {
+		card->set_bias_level = asoc_simple_set_bias_level;
+		card->set_bias_level_post = asoc_simple_set_bias_level_post;
+	}
+
 	asoc_simple_debug_info(priv);
 
 	ret = devm_snd_soc_register_card(dev, card);
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 6cada4c1e283..a9b1849e328b 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -399,6 +399,162 @@ int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd)
 }
 EXPORT_SYMBOL_GPL(asoc_simple_dai_init);
 
+static bool asoc_simple_node_is_component(struct snd_soc_component *component,
+					  struct device_node *node)
+{
+	struct device_node *comp_node;
+
+	comp_node = component->dev->of_node;
+	if (!comp_node && component->dev->parent)
+		comp_node = component->dev->parent->of_node;
+
+	return (comp_node == node);
+}
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		return 0;
+
+	switch (level) {
+	case SND_SOC_BIAS_STANDBY:
+		if (dapm->bias_level != SND_SOC_BIAS_OFF)
+			break;
+
+		/*
+		 * A component's PLLs normally supply its SYSCLKs so enable
+		 * the PLLs first.
+		 */
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->plls[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable pll %d parent clock: %d\n",
+					component->name, priv->plls[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_pll(component,
+							priv->plls[i].id,
+							priv->plls[i].source,
+							clk_get_rate(priv->plls[i].clk),
+							priv->plls[i].freq_out);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set pll %d: %d\n",
+					component->name, priv->plls[i].id, ret);
+
+				clk_disable_unprepare(priv->plls[i].clk);
+				return ret;
+			}
+
+			priv->plls[i].enabled = true;
+		}
+
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->sysclks[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable sysclk %d parent clock: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   priv->sysclks[i].source,
+							   clk_get_rate(priv->sysclks[i].clk),
+							   priv->sysclks[i].dir);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set sysclk %d: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+
+				clk_disable_unprepare(priv->sysclks[i].clk);
+				return ret;
+			}
+
+			priv->sysclks[i].enabled = true;
+		}
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level);
+
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		goto out;
+
+	switch (level) {
+	case SND_SOC_BIAS_OFF:
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			if (!priv->sysclks[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   0,
+							   0,
+							   priv->sysclks[i].dir);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable sysclk %d: %d\n",
+					 component->name, priv->sysclks[i].id, ret);
+
+			clk_disable_unprepare(priv->sysclks[i].clk);
+			priv->sysclks[i].enabled = false;
+		}
+
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			if (!priv->plls[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_pll(component, priv->plls[i].id, 0, 0, 0);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable pll %d: %d\n",
+					 component->name, priv->plls[i].id, ret);
+
+			clk_disable_unprepare(priv->plls[i].clk);
+			priv->plls[i].enabled = false;
+		}
+		break;
+	default:
+		break;
+	}
+
+out:
+	dapm->bias_level = level;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level_post);
+
 void asoc_simple_canonicalize_platform(struct snd_soc_dai_link *dai_link)
 {
 	/* Assumes platform == cpu */
@@ -433,6 +589,7 @@ EXPORT_SYMBOL_GPL(asoc_simple_canonicalize_cpu);
 
 int asoc_simple_clean_reference(struct snd_soc_card *card)
 {
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
 	struct snd_soc_dai_link *dai_link;
 	int i;
 
@@ -440,6 +597,15 @@ int asoc_simple_clean_reference(struct snd_soc_card *card)
 		of_node_put(dai_link->cpus->of_node);
 		of_node_put(dai_link->codecs->of_node);
 	}
+
+	if (priv) {
+		for (i = 0; i < priv->num_sysclks; ++i)
+			of_node_put(priv->sysclks[i].node);
+
+		for (i = 0; i < priv->num_plls; ++i)
+			of_node_put(priv->plls[i].node);
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(asoc_simple_clean_reference);
@@ -538,6 +704,78 @@ int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(asoc_simple_parse_pin_switches);
 
+static int asoc_simple_parse_sysclks_plls(struct asoc_simple_priv *priv,
+					  char *prefix,
+					  char *prop_root_name,
+					  struct asoc_simple_sysclk_pll **out,
+					  int *out_count)
+{
+	struct device *dev = priv->snd_card.dev;
+	struct device_node *node = dev->of_node;
+	struct of_phandle_args args;
+	int n_elem, i, ret;
+	char prop[128];
+	char clocks_prop[128];
+	const char *src_clk_name;
+	struct clk *in_clk;
+
+	if (!prefix)
+		prefix = "";
+
+	snprintf(prop, sizeof(prop), "%s%s", prefix, prop_root_name);
+	snprintf(clocks_prop, sizeof(clocks_prop), "%s-clocks", prop);
+	n_elem = of_count_phandle_with_fixed_args(node, prop, 3);
+	if (n_elem == -ENOENT || n_elem == 0) {
+		return 0;
+	} else if (n_elem < 0) {
+		dev_err(dev, "Failed to parse %s: %d\n", prop, n_elem);
+		return n_elem;
+	}
+
+	*out = devm_kcalloc(dev, n_elem, sizeof(**out), GFP_KERNEL);
+	if (!*out)
+		return -ENOMEM;
+	*out_count = 0;
+
+	for (i = 0; i < n_elem; ++i) {
+		ret = of_property_read_string_index(node, clocks_prop, i, &src_clk_name);
+		if (ret < 0)
+			return ret;
+
+		in_clk = devm_clk_get(dev, src_clk_name);
+		if (IS_ERR(in_clk))
+			return PTR_ERR(in_clk);
+
+		ret = of_parse_phandle_with_fixed_args(node, prop, 3, i, &args);
+		if (ret < 0)
+			return ret;
+
+		(*out)[i].node		= args.np;
+		(*out)[i].clk		= in_clk;
+		(*out)[i].id		= args.args[0];
+		(*out)[i].source	= args.args[1];
+		(*out)[i].dir		= args.args[2]; /* for sysclks */
+		(*out)[i].freq_out	= args.args[2]; /* for plls */
+		++*out_count;
+	}
+
+	return 0;
+}
+
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "sysclks",
+					      &priv->sysclks, &priv->num_sysclks);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_sysclks);
+
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "plls",
+					      &priv->plls, &priv->num_plls);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_plls);
+
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			  struct asoc_simple_jack *sjack,
 			  int is_hp, char *prefix,
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Some codecs need plls and/or sysclks to be configured using the
snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
necessarily be converted to use the clock framework. If the codec is on
a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
But the clock framework does not support nested operations and this would
deadlock.

This patch adds new dt properties that list phandles of components with
the pll/sysclk settings to be applied. Multiple settings can be given for
the same phandle to allow for components with multiple clocks and plls.
The plls and sysclks are enabled when the card bias level moves to STANDBY
and disabled when it moves to OFF.

The implementation does not attempt to handle specifying complex clock
ordering interdependencies between components. The plls and sysclks are
applied to a component as it is passed to the card set_bias_level/
set_bias_level_post callbacks. It follows from this that the order
components are configured is the order that they are passed to those
callbacks.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/sound/simple_card_utils.h     |  25 +++
 sound/soc/generic/audio-graph-card.c  |  13 ++
 sound/soc/generic/simple-card-utils.c | 238 ++++++++++++++++++++++++++
 3 files changed, 276 insertions(+)

diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h
index ba4a3e1897b9..1f755250f9c7 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -38,6 +38,16 @@ struct asoc_simple_jack {
 	struct snd_soc_jack_gpio gpio;
 };
 
+struct asoc_simple_sysclk_pll {
+	struct device_node *node;
+	struct clk *clk;
+	int id;
+	int source;
+	unsigned int freq_out;
+	int dir;
+	bool enabled;
+};
+
 struct asoc_simple_priv {
 	struct snd_soc_card snd_card;
 	struct simple_dai_props {
@@ -59,6 +69,11 @@ struct asoc_simple_priv {
 	const struct snd_soc_ops *ops;
 	unsigned int dpcm_selectable:1;
 	unsigned int force_dpcm:1;
+
+	struct asoc_simple_sysclk_pll *sysclks;
+	int num_sysclks;
+	struct asoc_simple_sysclk_pll *plls;
+	int num_plls;
 };
 #define simple_priv_to_card(priv)	(&(priv)->snd_card)
 #define simple_priv_to_props(priv, i)	((priv)->dai_props + (i))
@@ -97,6 +112,14 @@ void asoc_simple_shutdown(struct snd_pcm_substream *substream);
 int asoc_simple_hw_params(struct snd_pcm_substream *substream,
 			  struct snd_pcm_hw_params *params);
 int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd);
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level);
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level);
+
 int asoc_simple_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
 				   struct snd_pcm_hw_params *params);
 
@@ -131,6 +154,8 @@ int asoc_simple_parse_widgets(struct snd_soc_card *card,
 				      char *prefix);
 int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 				   char *prefix);
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix);
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix);
 
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			       struct asoc_simple_jack *sjack,
diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c
index 16a04a678828..9aa15d5ecbd0 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -592,6 +592,19 @@ int graph_parse_of(struct asoc_simple_priv *priv, struct device *dev)
 
 	snd_soc_card_set_drvdata(card, priv);
 
+	ret = asoc_simple_parse_sysclks(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	ret = asoc_simple_parse_plls(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	if (priv->num_sysclks || priv->num_plls) {
+		card->set_bias_level = asoc_simple_set_bias_level;
+		card->set_bias_level_post = asoc_simple_set_bias_level_post;
+	}
+
 	asoc_simple_debug_info(priv);
 
 	ret = devm_snd_soc_register_card(dev, card);
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 6cada4c1e283..a9b1849e328b 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -399,6 +399,162 @@ int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd)
 }
 EXPORT_SYMBOL_GPL(asoc_simple_dai_init);
 
+static bool asoc_simple_node_is_component(struct snd_soc_component *component,
+					  struct device_node *node)
+{
+	struct device_node *comp_node;
+
+	comp_node = component->dev->of_node;
+	if (!comp_node && component->dev->parent)
+		comp_node = component->dev->parent->of_node;
+
+	return (comp_node == node);
+}
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		return 0;
+
+	switch (level) {
+	case SND_SOC_BIAS_STANDBY:
+		if (dapm->bias_level != SND_SOC_BIAS_OFF)
+			break;
+
+		/*
+		 * A component's PLLs normally supply its SYSCLKs so enable
+		 * the PLLs first.
+		 */
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->plls[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable pll %d parent clock: %d\n",
+					component->name, priv->plls[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_pll(component,
+							priv->plls[i].id,
+							priv->plls[i].source,
+							clk_get_rate(priv->plls[i].clk),
+							priv->plls[i].freq_out);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set pll %d: %d\n",
+					component->name, priv->plls[i].id, ret);
+
+				clk_disable_unprepare(priv->plls[i].clk);
+				return ret;
+			}
+
+			priv->plls[i].enabled = true;
+		}
+
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->sysclks[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable sysclk %d parent clock: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   priv->sysclks[i].source,
+							   clk_get_rate(priv->sysclks[i].clk),
+							   priv->sysclks[i].dir);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set sysclk %d: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+
+				clk_disable_unprepare(priv->sysclks[i].clk);
+				return ret;
+			}
+
+			priv->sysclks[i].enabled = true;
+		}
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level);
+
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		goto out;
+
+	switch (level) {
+	case SND_SOC_BIAS_OFF:
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			if (!priv->sysclks[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   0,
+							   0,
+							   priv->sysclks[i].dir);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable sysclk %d: %d\n",
+					 component->name, priv->sysclks[i].id, ret);
+
+			clk_disable_unprepare(priv->sysclks[i].clk);
+			priv->sysclks[i].enabled = false;
+		}
+
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			if (!priv->plls[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_pll(component, priv->plls[i].id, 0, 0, 0);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable pll %d: %d\n",
+					 component->name, priv->plls[i].id, ret);
+
+			clk_disable_unprepare(priv->plls[i].clk);
+			priv->plls[i].enabled = false;
+		}
+		break;
+	default:
+		break;
+	}
+
+out:
+	dapm->bias_level = level;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level_post);
+
 void asoc_simple_canonicalize_platform(struct snd_soc_dai_link *dai_link)
 {
 	/* Assumes platform == cpu */
@@ -433,6 +589,7 @@ EXPORT_SYMBOL_GPL(asoc_simple_canonicalize_cpu);
 
 int asoc_simple_clean_reference(struct snd_soc_card *card)
 {
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
 	struct snd_soc_dai_link *dai_link;
 	int i;
 
@@ -440,6 +597,15 @@ int asoc_simple_clean_reference(struct snd_soc_card *card)
 		of_node_put(dai_link->cpus->of_node);
 		of_node_put(dai_link->codecs->of_node);
 	}
+
+	if (priv) {
+		for (i = 0; i < priv->num_sysclks; ++i)
+			of_node_put(priv->sysclks[i].node);
+
+		for (i = 0; i < priv->num_plls; ++i)
+			of_node_put(priv->plls[i].node);
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(asoc_simple_clean_reference);
@@ -538,6 +704,78 @@ int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(asoc_simple_parse_pin_switches);
 
+static int asoc_simple_parse_sysclks_plls(struct asoc_simple_priv *priv,
+					  char *prefix,
+					  char *prop_root_name,
+					  struct asoc_simple_sysclk_pll **out,
+					  int *out_count)
+{
+	struct device *dev = priv->snd_card.dev;
+	struct device_node *node = dev->of_node;
+	struct of_phandle_args args;
+	int n_elem, i, ret;
+	char prop[128];
+	char clocks_prop[128];
+	const char *src_clk_name;
+	struct clk *in_clk;
+
+	if (!prefix)
+		prefix = "";
+
+	snprintf(prop, sizeof(prop), "%s%s", prefix, prop_root_name);
+	snprintf(clocks_prop, sizeof(clocks_prop), "%s-clocks", prop);
+	n_elem = of_count_phandle_with_fixed_args(node, prop, 3);
+	if (n_elem == -ENOENT || n_elem == 0) {
+		return 0;
+	} else if (n_elem < 0) {
+		dev_err(dev, "Failed to parse %s: %d\n", prop, n_elem);
+		return n_elem;
+	}
+
+	*out = devm_kcalloc(dev, n_elem, sizeof(**out), GFP_KERNEL);
+	if (!*out)
+		return -ENOMEM;
+	*out_count = 0;
+
+	for (i = 0; i < n_elem; ++i) {
+		ret = of_property_read_string_index(node, clocks_prop, i, &src_clk_name);
+		if (ret < 0)
+			return ret;
+
+		in_clk = devm_clk_get(dev, src_clk_name);
+		if (IS_ERR(in_clk))
+			return PTR_ERR(in_clk);
+
+		ret = of_parse_phandle_with_fixed_args(node, prop, 3, i, &args);
+		if (ret < 0)
+			return ret;
+
+		(*out)[i].node		= args.np;
+		(*out)[i].clk		= in_clk;
+		(*out)[i].id		= args.args[0];
+		(*out)[i].source	= args.args[1];
+		(*out)[i].dir		= args.args[2]; /* for sysclks */
+		(*out)[i].freq_out	= args.args[2]; /* for plls */
+		++*out_count;
+	}
+
+	return 0;
+}
+
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "sysclks",
+					      &priv->sysclks, &priv->num_sysclks);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_sysclks);
+
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "plls",
+					      &priv->plls, &priv->num_plls);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_plls);
+
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			  struct asoc_simple_jack *sjack,
 			  int is_hp, char *prefix,
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Some codecs need plls and/or sysclks to be configured using the
snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
necessarily be converted to use the clock framework. If the codec is on
a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
But the clock framework does not support nested operations and this would
deadlock.

This patch adds new dt properties that list phandles of components with
the pll/sysclk settings to be applied. Multiple settings can be given for
the same phandle to allow for components with multiple clocks and plls.
The plls and sysclks are enabled when the card bias level moves to STANDBY
and disabled when it moves to OFF.

The implementation does not attempt to handle specifying complex clock
ordering interdependencies between components. The plls and sysclks are
applied to a component as it is passed to the card set_bias_level/
set_bias_level_post callbacks. It follows from this that the order
components are configured is the order that they are passed to those
callbacks.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/sound/simple_card_utils.h     |  25 +++
 sound/soc/generic/audio-graph-card.c  |  13 ++
 sound/soc/generic/simple-card-utils.c | 238 ++++++++++++++++++++++++++
 3 files changed, 276 insertions(+)

diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h
index ba4a3e1897b9..1f755250f9c7 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -38,6 +38,16 @@ struct asoc_simple_jack {
 	struct snd_soc_jack_gpio gpio;
 };
 
+struct asoc_simple_sysclk_pll {
+	struct device_node *node;
+	struct clk *clk;
+	int id;
+	int source;
+	unsigned int freq_out;
+	int dir;
+	bool enabled;
+};
+
 struct asoc_simple_priv {
 	struct snd_soc_card snd_card;
 	struct simple_dai_props {
@@ -59,6 +69,11 @@ struct asoc_simple_priv {
 	const struct snd_soc_ops *ops;
 	unsigned int dpcm_selectable:1;
 	unsigned int force_dpcm:1;
+
+	struct asoc_simple_sysclk_pll *sysclks;
+	int num_sysclks;
+	struct asoc_simple_sysclk_pll *plls;
+	int num_plls;
 };
 #define simple_priv_to_card(priv)	(&(priv)->snd_card)
 #define simple_priv_to_props(priv, i)	((priv)->dai_props + (i))
@@ -97,6 +112,14 @@ void asoc_simple_shutdown(struct snd_pcm_substream *substream);
 int asoc_simple_hw_params(struct snd_pcm_substream *substream,
 			  struct snd_pcm_hw_params *params);
 int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd);
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level);
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level);
+
 int asoc_simple_be_hw_params_fixup(struct snd_soc_pcm_runtime *rtd,
 				   struct snd_pcm_hw_params *params);
 
@@ -131,6 +154,8 @@ int asoc_simple_parse_widgets(struct snd_soc_card *card,
 				      char *prefix);
 int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 				   char *prefix);
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix);
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix);
 
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			       struct asoc_simple_jack *sjack,
diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c
index 16a04a678828..9aa15d5ecbd0 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -592,6 +592,19 @@ int graph_parse_of(struct asoc_simple_priv *priv, struct device *dev)
 
 	snd_soc_card_set_drvdata(card, priv);
 
+	ret = asoc_simple_parse_sysclks(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	ret = asoc_simple_parse_plls(priv, NULL);
+	if (ret < 0)
+		goto err;
+
+	if (priv->num_sysclks || priv->num_plls) {
+		card->set_bias_level = asoc_simple_set_bias_level;
+		card->set_bias_level_post = asoc_simple_set_bias_level_post;
+	}
+
 	asoc_simple_debug_info(priv);
 
 	ret = devm_snd_soc_register_card(dev, card);
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 6cada4c1e283..a9b1849e328b 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -399,6 +399,162 @@ int asoc_simple_dai_init(struct snd_soc_pcm_runtime *rtd)
 }
 EXPORT_SYMBOL_GPL(asoc_simple_dai_init);
 
+static bool asoc_simple_node_is_component(struct snd_soc_component *component,
+					  struct device_node *node)
+{
+	struct device_node *comp_node;
+
+	comp_node = component->dev->of_node;
+	if (!comp_node && component->dev->parent)
+		comp_node = component->dev->parent->of_node;
+
+	return (comp_node == node);
+}
+
+int asoc_simple_set_bias_level(struct snd_soc_card *card,
+			       struct snd_soc_dapm_context *dapm,
+			       enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		return 0;
+
+	switch (level) {
+	case SND_SOC_BIAS_STANDBY:
+		if (dapm->bias_level != SND_SOC_BIAS_OFF)
+			break;
+
+		/*
+		 * A component's PLLs normally supply its SYSCLKs so enable
+		 * the PLLs first.
+		 */
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->plls[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable pll %d parent clock: %d\n",
+					component->name, priv->plls[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_pll(component,
+							priv->plls[i].id,
+							priv->plls[i].source,
+							clk_get_rate(priv->plls[i].clk),
+							priv->plls[i].freq_out);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set pll %d: %d\n",
+					component->name, priv->plls[i].id, ret);
+
+				clk_disable_unprepare(priv->plls[i].clk);
+				return ret;
+			}
+
+			priv->plls[i].enabled = true;
+		}
+
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			ret = clk_prepare_enable(priv->sysclks[i].clk);
+			if (ret) {
+				dev_err(card->dev,
+					"(%s) failed to enable sysclk %d parent clock: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+				return ret;
+			}
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   priv->sysclks[i].source,
+							   clk_get_rate(priv->sysclks[i].clk),
+							   priv->sysclks[i].dir);
+			if (ret) {
+				dev_err(card->dev, "(%s) failed to set sysclk %d: %d\n",
+					component->name, priv->sysclks[i].id, ret);
+
+				clk_disable_unprepare(priv->sysclks[i].clk);
+				return ret;
+			}
+
+			priv->sysclks[i].enabled = true;
+		}
+		break;
+	default:
+		break;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level);
+
+int asoc_simple_set_bias_level_post(struct snd_soc_card *card,
+				    struct snd_soc_dapm_context *dapm,
+				    enum snd_soc_bias_level level)
+{
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
+	struct snd_soc_component *component = dapm->component;
+	int i, ret;
+
+	if (!component)
+		goto out;
+
+	switch (level) {
+	case SND_SOC_BIAS_OFF:
+		for (i = 0; i < priv->num_sysclks; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->sysclks[i].node))
+				continue;
+
+			if (!priv->sysclks[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_sysclk(component,
+							   priv->sysclks[i].id,
+							   0,
+							   0,
+							   priv->sysclks[i].dir);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable sysclk %d: %d\n",
+					 component->name, priv->sysclks[i].id, ret);
+
+			clk_disable_unprepare(priv->sysclks[i].clk);
+			priv->sysclks[i].enabled = false;
+		}
+
+		for (i = 0; i < priv->num_plls; ++i) {
+			if (!asoc_simple_node_is_component(component, priv->plls[i].node))
+				continue;
+
+			if (!priv->plls[i].enabled)
+				continue;
+
+			ret = snd_soc_component_set_pll(component, priv->plls[i].id, 0, 0, 0);
+			if (ret)
+				dev_warn(card->dev, "(%s) failed to disable pll %d: %d\n",
+					 component->name, priv->plls[i].id, ret);
+
+			clk_disable_unprepare(priv->plls[i].clk);
+			priv->plls[i].enabled = false;
+		}
+		break;
+	default:
+		break;
+	}
+
+out:
+	dapm->bias_level = level;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_set_bias_level_post);
+
 void asoc_simple_canonicalize_platform(struct snd_soc_dai_link *dai_link)
 {
 	/* Assumes platform == cpu */
@@ -433,6 +589,7 @@ EXPORT_SYMBOL_GPL(asoc_simple_canonicalize_cpu);
 
 int asoc_simple_clean_reference(struct snd_soc_card *card)
 {
+	struct asoc_simple_priv *priv = snd_soc_card_get_drvdata(card);
 	struct snd_soc_dai_link *dai_link;
 	int i;
 
@@ -440,6 +597,15 @@ int asoc_simple_clean_reference(struct snd_soc_card *card)
 		of_node_put(dai_link->cpus->of_node);
 		of_node_put(dai_link->codecs->of_node);
 	}
+
+	if (priv) {
+		for (i = 0; i < priv->num_sysclks; ++i)
+			of_node_put(priv->sysclks[i].node);
+
+		for (i = 0; i < priv->num_plls; ++i)
+			of_node_put(priv->plls[i].node);
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(asoc_simple_clean_reference);
@@ -538,6 +704,78 @@ int asoc_simple_parse_pin_switches(struct snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(asoc_simple_parse_pin_switches);
 
+static int asoc_simple_parse_sysclks_plls(struct asoc_simple_priv *priv,
+					  char *prefix,
+					  char *prop_root_name,
+					  struct asoc_simple_sysclk_pll **out,
+					  int *out_count)
+{
+	struct device *dev = priv->snd_card.dev;
+	struct device_node *node = dev->of_node;
+	struct of_phandle_args args;
+	int n_elem, i, ret;
+	char prop[128];
+	char clocks_prop[128];
+	const char *src_clk_name;
+	struct clk *in_clk;
+
+	if (!prefix)
+		prefix = "";
+
+	snprintf(prop, sizeof(prop), "%s%s", prefix, prop_root_name);
+	snprintf(clocks_prop, sizeof(clocks_prop), "%s-clocks", prop);
+	n_elem = of_count_phandle_with_fixed_args(node, prop, 3);
+	if (n_elem == -ENOENT || n_elem == 0) {
+		return 0;
+	} else if (n_elem < 0) {
+		dev_err(dev, "Failed to parse %s: %d\n", prop, n_elem);
+		return n_elem;
+	}
+
+	*out = devm_kcalloc(dev, n_elem, sizeof(**out), GFP_KERNEL);
+	if (!*out)
+		return -ENOMEM;
+	*out_count = 0;
+
+	for (i = 0; i < n_elem; ++i) {
+		ret = of_property_read_string_index(node, clocks_prop, i, &src_clk_name);
+		if (ret < 0)
+			return ret;
+
+		in_clk = devm_clk_get(dev, src_clk_name);
+		if (IS_ERR(in_clk))
+			return PTR_ERR(in_clk);
+
+		ret = of_parse_phandle_with_fixed_args(node, prop, 3, i, &args);
+		if (ret < 0)
+			return ret;
+
+		(*out)[i].node		= args.np;
+		(*out)[i].clk		= in_clk;
+		(*out)[i].id		= args.args[0];
+		(*out)[i].source	= args.args[1];
+		(*out)[i].dir		= args.args[2]; /* for sysclks */
+		(*out)[i].freq_out	= args.args[2]; /* for plls */
+		++*out_count;
+	}
+
+	return 0;
+}
+
+int asoc_simple_parse_sysclks(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "sysclks",
+					      &priv->sysclks, &priv->num_sysclks);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_sysclks);
+
+int asoc_simple_parse_plls(struct asoc_simple_priv *priv, char *prefix)
+{
+	return asoc_simple_parse_sysclks_plls(priv, prefix, "plls",
+					      &priv->plls, &priv->num_plls);
+}
+EXPORT_SYMBOL_GPL(asoc_simple_parse_plls);
+
 int asoc_simple_init_jack(struct snd_soc_card *card,
 			  struct asoc_simple_jack *sjack,
 			  int is_hp, char *prefix,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 4/6] ASoC: madera: Allow codecs to be selected from kernel config
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:04   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

The codec Kconfig options were hidden and intended to be selected by
the machine driver that requires them. But that means having either a
dedicated machine driver or building all codecs.

This patch makes the Kconfig options visible so that they can be
selected independently of the machine driver, allowing the codec to be
used with simple-card and other machine drivers that are not hardcoded
to use a fixed set of codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/codecs/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9bf6bfdaf11e..599dd8d2577f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -678,23 +678,23 @@ config SND_SOC_CS4349
 	depends on I2C
 
 config SND_SOC_CS47L15
-	tristate
+	tristate "Cirrus Logic CS47L15 CODEC"
 
 config SND_SOC_CS47L24
 	tristate
 	depends on MFD_CS47L24
 
 config SND_SOC_CS47L35
-	tristate
+	tristate "Cirrus Logic CS47L35 CODEC"
 
 config SND_SOC_CS47L85
-	tristate
+	tristate "Cirrus Logic CS47L85 CODEC"
 
 config SND_SOC_CS47L90
-	tristate
+	tristate "Cirrus Logic CS47L90 CODEC"
 
 config SND_SOC_CS47L92
-	tristate
+	tristate "Cirrus Logic CS47L92 CODEC"
 
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 4/6] ASoC: madera: Allow codecs to be selected from kernel config
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

The codec Kconfig options were hidden and intended to be selected by
the machine driver that requires them. But that means having either a
dedicated machine driver or building all codecs.

This patch makes the Kconfig options visible so that they can be
selected independently of the machine driver, allowing the codec to be
used with simple-card and other machine drivers that are not hardcoded
to use a fixed set of codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/codecs/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9bf6bfdaf11e..599dd8d2577f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -678,23 +678,23 @@ config SND_SOC_CS4349
 	depends on I2C
 
 config SND_SOC_CS47L15
-	tristate
+	tristate "Cirrus Logic CS47L15 CODEC"
 
 config SND_SOC_CS47L24
 	tristate
 	depends on MFD_CS47L24
 
 config SND_SOC_CS47L35
-	tristate
+	tristate "Cirrus Logic CS47L35 CODEC"
 
 config SND_SOC_CS47L85
-	tristate
+	tristate "Cirrus Logic CS47L85 CODEC"
 
 config SND_SOC_CS47L90
-	tristate
+	tristate "Cirrus Logic CS47L90 CODEC"
 
 config SND_SOC_CS47L92
-	tristate
+	tristate "Cirrus Logic CS47L92 CODEC"
 
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 4/6] ASoC: madera: Allow codecs to be selected from kernel config
@ 2021-01-08 16:04   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:04 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

The codec Kconfig options were hidden and intended to be selected by
the machine driver that requires them. But that means having either a
dedicated machine driver or building all codecs.

This patch makes the Kconfig options visible so that they can be
selected independently of the machine driver, allowing the codec to be
used with simple-card and other machine drivers that are not hardcoded
to use a fixed set of codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/codecs/Kconfig | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9bf6bfdaf11e..599dd8d2577f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -678,23 +678,23 @@ config SND_SOC_CS4349
 	depends on I2C
 
 config SND_SOC_CS47L15
-	tristate
+	tristate "Cirrus Logic CS47L15 CODEC"
 
 config SND_SOC_CS47L24
 	tristate
 	depends on MFD_CS47L24
 
 config SND_SOC_CS47L35
-	tristate
+	tristate "Cirrus Logic CS47L35 CODEC"
 
 config SND_SOC_CS47L85
-	tristate
+	tristate "Cirrus Logic CS47L85 CODEC"
 
 config SND_SOC_CS47L90
-	tristate
+	tristate "Cirrus Logic CS47L90 CODEC"
 
 config SND_SOC_CS47L92
-	tristate
+	tristate "Cirrus Logic CS47L92 CODEC"
 
 # Cirrus Logic Quad-Channel ADC
 config SND_SOC_CS53L30
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 5/6] ASoC: madera: Export clock config defines to dt-bindings
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:05   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

Move the defines for clock/fll IDs and sources into the dt-bindings
header so that they can be used by machine driver dts files.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/dt-bindings/sound/madera.h | 60 ++++++++++++++++++++++++++++++
 sound/soc/codecs/madera.h          | 56 +---------------------------
 2 files changed, 61 insertions(+), 55 deletions(-)

diff --git a/include/dt-bindings/sound/madera.h b/include/dt-bindings/sound/madera.h
index d0096d5eb0da..5c5fc1bfe6f9 100644
--- a/include/dt-bindings/sound/madera.h
+++ b/include/dt-bindings/sound/madera.h
@@ -22,4 +22,64 @@
 #define CS47L35_DMIC_REF_MICBIAS2A	2
 #define CS47L35_DMIC_REF_MICBIAS2B	3
 
+/* FLL IDs */
+#define MADERA_FLL1_REFCLK		1
+#define MADERA_FLL2_REFCLK		2
+#define MADERA_FLL3_REFCLK		3
+#define MADERA_FLLAO_REFCLK		4
+#define MADERA_FLL1_SYNCCLK		5
+#define MADERA_FLL2_SYNCCLK		6
+#define MADERA_FLL3_SYNCCLK		7
+#define MADERA_FLLAO_SYNCCLK		8
+
+/* FLL input source pin IDs */
+#define MADERA_FLL_SRC_NONE		-1
+#define MADERA_FLL_SRC_MCLK1		0
+#define MADERA_FLL_SRC_MCLK2		1
+#define MADERA_FLL_SRC_MCLK3		2
+#define MADERA_FLL_SRC_SLIMCLK		3
+#define MADERA_FLL_SRC_FLL1		4
+#define MADERA_FLL_SRC_FLL2		5
+#define MADERA_FLL_SRC_AIF1BCLK		8
+#define MADERA_FLL_SRC_AIF2BCLK		9
+#define MADERA_FLL_SRC_AIF3BCLK		10
+#define MADERA_FLL_SRC_AIF4BCLK		11
+#define MADERA_FLL_SRC_AIF1LRCLK	12
+#define MADERA_FLL_SRC_AIF2LRCLK	13
+#define MADERA_FLL_SRC_AIF3LRCLK	14
+#define MADERA_FLL_SRC_AIF4LRCLK	15
+
+/* SYSCLK IDs */
+#define MADERA_CLK_SYSCLK_1		1
+#define MADERA_CLK_ASYNCCLK_1		2
+#define MADERA_CLK_OPCLK		3
+#define MADERA_CLK_ASYNC_OPCLK		4
+#define MADERA_CLK_SYSCLK_2		5
+#define MADERA_CLK_SYSCLK_3		6
+#define MADERA_CLK_ASYNCCLK_2		7
+#define MADERA_CLK_DSPCLK		8
+#define MADERA_CLK_OUTCLK		9
+
+/* SYSCLK source IDs */
+#define MADERA_CLK_SRC_MCLK1		0x0
+#define MADERA_CLK_SRC_MCLK2		0x1
+#define MADERA_CLK_SRC_MCLK3		0x2
+#define MADERA_CLK_SRC_FLL1		0x4
+#define MADERA_CLK_SRC_FLL2		0x5
+#define MADERA_CLK_SRC_FLL3		0x6
+#define MADERA_CLK_SRC_FLLAO_HI		0x7
+#define MADERA_CLK_SRC_FLL1_DIV6	0x7
+#define MADERA_CLK_SRC_AIF1BCLK		0x8
+#define MADERA_CLK_SRC_AIF2BCLK		0x9
+#define MADERA_CLK_SRC_AIF3BCLK		0xA
+#define MADERA_CLK_SRC_AIF4BCLK		0xB
+#define MADERA_CLK_SRC_FLLAO		0xF
+
+/* OPCLK source IDs */
+#define MADERA_OUTCLK_SYSCLK		0
+#define MADERA_OUTCLK_ASYNCCLK		1
+#define MADERA_OUTCLK_MCLK1		4
+#define MADERA_OUTCLK_MCLK2		5
+#define MADERA_OUTCLK_MCLK3		6
+
 #endif
diff --git a/sound/soc/codecs/madera.h b/sound/soc/codecs/madera.h
index e0c0be59e2ef..1f4ea15648c5 100644
--- a/sound/soc/codecs/madera.h
+++ b/sound/soc/codecs/madera.h
@@ -9,67 +9,13 @@
 #ifndef ASOC_MADERA_H
 #define ASOC_MADERA_H
 
+#include <dt-bindings/sound/madera.h>
 #include <linux/completion.h>
 #include <sound/soc.h>
 #include <sound/madera-pdata.h>
 
 #include "wm_adsp.h"
 
-#define MADERA_FLL1_REFCLK		1
-#define MADERA_FLL2_REFCLK		2
-#define MADERA_FLL3_REFCLK		3
-#define MADERA_FLLAO_REFCLK		4
-#define MADERA_FLL1_SYNCCLK		5
-#define MADERA_FLL2_SYNCCLK		6
-#define MADERA_FLL3_SYNCCLK		7
-#define MADERA_FLLAO_SYNCCLK		8
-
-#define MADERA_FLL_SRC_NONE		-1
-#define MADERA_FLL_SRC_MCLK1		0
-#define MADERA_FLL_SRC_MCLK2		1
-#define MADERA_FLL_SRC_MCLK3		2
-#define MADERA_FLL_SRC_SLIMCLK		3
-#define MADERA_FLL_SRC_FLL1		4
-#define MADERA_FLL_SRC_FLL2		5
-#define MADERA_FLL_SRC_AIF1BCLK		8
-#define MADERA_FLL_SRC_AIF2BCLK		9
-#define MADERA_FLL_SRC_AIF3BCLK		10
-#define MADERA_FLL_SRC_AIF4BCLK		11
-#define MADERA_FLL_SRC_AIF1LRCLK	12
-#define MADERA_FLL_SRC_AIF2LRCLK	13
-#define MADERA_FLL_SRC_AIF3LRCLK	14
-#define MADERA_FLL_SRC_AIF4LRCLK	15
-
-#define MADERA_CLK_SYSCLK_1		1
-#define MADERA_CLK_ASYNCCLK_1		2
-#define MADERA_CLK_OPCLK		3
-#define MADERA_CLK_ASYNC_OPCLK		4
-#define MADERA_CLK_SYSCLK_2		5
-#define MADERA_CLK_SYSCLK_3		6
-#define MADERA_CLK_ASYNCCLK_2		7
-#define MADERA_CLK_DSPCLK		8
-#define MADERA_CLK_OUTCLK		9
-
-#define MADERA_CLK_SRC_MCLK1		0x0
-#define MADERA_CLK_SRC_MCLK2		0x1
-#define MADERA_CLK_SRC_MCLK3		0x2
-#define MADERA_CLK_SRC_FLL1		0x4
-#define MADERA_CLK_SRC_FLL2		0x5
-#define MADERA_CLK_SRC_FLL3		0x6
-#define MADERA_CLK_SRC_FLLAO_HI		0x7
-#define MADERA_CLK_SRC_FLL1_DIV6	0x7
-#define MADERA_CLK_SRC_AIF1BCLK		0x8
-#define MADERA_CLK_SRC_AIF2BCLK		0x9
-#define MADERA_CLK_SRC_AIF3BCLK		0xA
-#define MADERA_CLK_SRC_AIF4BCLK		0xB
-#define MADERA_CLK_SRC_FLLAO		0xF
-
-#define MADERA_OUTCLK_SYSCLK		0
-#define MADERA_OUTCLK_ASYNCCLK		1
-#define MADERA_OUTCLK_MCLK1		4
-#define MADERA_OUTCLK_MCLK2		5
-#define MADERA_OUTCLK_MCLK3		6
-
 #define MADERA_MIXER_VOL_MASK		0x00FE
 #define MADERA_MIXER_VOL_SHIFT		1
 #define MADERA_MIXER_VOL_WIDTH		7
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 5/6] ASoC: madera: Export clock config defines to dt-bindings
@ 2021-01-08 16:05   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Move the defines for clock/fll IDs and sources into the dt-bindings
header so that they can be used by machine driver dts files.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/dt-bindings/sound/madera.h | 60 ++++++++++++++++++++++++++++++
 sound/soc/codecs/madera.h          | 56 +---------------------------
 2 files changed, 61 insertions(+), 55 deletions(-)

diff --git a/include/dt-bindings/sound/madera.h b/include/dt-bindings/sound/madera.h
index d0096d5eb0da..5c5fc1bfe6f9 100644
--- a/include/dt-bindings/sound/madera.h
+++ b/include/dt-bindings/sound/madera.h
@@ -22,4 +22,64 @@
 #define CS47L35_DMIC_REF_MICBIAS2A	2
 #define CS47L35_DMIC_REF_MICBIAS2B	3
 
+/* FLL IDs */
+#define MADERA_FLL1_REFCLK		1
+#define MADERA_FLL2_REFCLK		2
+#define MADERA_FLL3_REFCLK		3
+#define MADERA_FLLAO_REFCLK		4
+#define MADERA_FLL1_SYNCCLK		5
+#define MADERA_FLL2_SYNCCLK		6
+#define MADERA_FLL3_SYNCCLK		7
+#define MADERA_FLLAO_SYNCCLK		8
+
+/* FLL input source pin IDs */
+#define MADERA_FLL_SRC_NONE		-1
+#define MADERA_FLL_SRC_MCLK1		0
+#define MADERA_FLL_SRC_MCLK2		1
+#define MADERA_FLL_SRC_MCLK3		2
+#define MADERA_FLL_SRC_SLIMCLK		3
+#define MADERA_FLL_SRC_FLL1		4
+#define MADERA_FLL_SRC_FLL2		5
+#define MADERA_FLL_SRC_AIF1BCLK		8
+#define MADERA_FLL_SRC_AIF2BCLK		9
+#define MADERA_FLL_SRC_AIF3BCLK		10
+#define MADERA_FLL_SRC_AIF4BCLK		11
+#define MADERA_FLL_SRC_AIF1LRCLK	12
+#define MADERA_FLL_SRC_AIF2LRCLK	13
+#define MADERA_FLL_SRC_AIF3LRCLK	14
+#define MADERA_FLL_SRC_AIF4LRCLK	15
+
+/* SYSCLK IDs */
+#define MADERA_CLK_SYSCLK_1		1
+#define MADERA_CLK_ASYNCCLK_1		2
+#define MADERA_CLK_OPCLK		3
+#define MADERA_CLK_ASYNC_OPCLK		4
+#define MADERA_CLK_SYSCLK_2		5
+#define MADERA_CLK_SYSCLK_3		6
+#define MADERA_CLK_ASYNCCLK_2		7
+#define MADERA_CLK_DSPCLK		8
+#define MADERA_CLK_OUTCLK		9
+
+/* SYSCLK source IDs */
+#define MADERA_CLK_SRC_MCLK1		0x0
+#define MADERA_CLK_SRC_MCLK2		0x1
+#define MADERA_CLK_SRC_MCLK3		0x2
+#define MADERA_CLK_SRC_FLL1		0x4
+#define MADERA_CLK_SRC_FLL2		0x5
+#define MADERA_CLK_SRC_FLL3		0x6
+#define MADERA_CLK_SRC_FLLAO_HI		0x7
+#define MADERA_CLK_SRC_FLL1_DIV6	0x7
+#define MADERA_CLK_SRC_AIF1BCLK		0x8
+#define MADERA_CLK_SRC_AIF2BCLK		0x9
+#define MADERA_CLK_SRC_AIF3BCLK		0xA
+#define MADERA_CLK_SRC_AIF4BCLK		0xB
+#define MADERA_CLK_SRC_FLLAO		0xF
+
+/* OPCLK source IDs */
+#define MADERA_OUTCLK_SYSCLK		0
+#define MADERA_OUTCLK_ASYNCCLK		1
+#define MADERA_OUTCLK_MCLK1		4
+#define MADERA_OUTCLK_MCLK2		5
+#define MADERA_OUTCLK_MCLK3		6
+
 #endif
diff --git a/sound/soc/codecs/madera.h b/sound/soc/codecs/madera.h
index e0c0be59e2ef..1f4ea15648c5 100644
--- a/sound/soc/codecs/madera.h
+++ b/sound/soc/codecs/madera.h
@@ -9,67 +9,13 @@
 #ifndef ASOC_MADERA_H
 #define ASOC_MADERA_H
 
+#include <dt-bindings/sound/madera.h>
 #include <linux/completion.h>
 #include <sound/soc.h>
 #include <sound/madera-pdata.h>
 
 #include "wm_adsp.h"
 
-#define MADERA_FLL1_REFCLK		1
-#define MADERA_FLL2_REFCLK		2
-#define MADERA_FLL3_REFCLK		3
-#define MADERA_FLLAO_REFCLK		4
-#define MADERA_FLL1_SYNCCLK		5
-#define MADERA_FLL2_SYNCCLK		6
-#define MADERA_FLL3_SYNCCLK		7
-#define MADERA_FLLAO_SYNCCLK		8
-
-#define MADERA_FLL_SRC_NONE		-1
-#define MADERA_FLL_SRC_MCLK1		0
-#define MADERA_FLL_SRC_MCLK2		1
-#define MADERA_FLL_SRC_MCLK3		2
-#define MADERA_FLL_SRC_SLIMCLK		3
-#define MADERA_FLL_SRC_FLL1		4
-#define MADERA_FLL_SRC_FLL2		5
-#define MADERA_FLL_SRC_AIF1BCLK		8
-#define MADERA_FLL_SRC_AIF2BCLK		9
-#define MADERA_FLL_SRC_AIF3BCLK		10
-#define MADERA_FLL_SRC_AIF4BCLK		11
-#define MADERA_FLL_SRC_AIF1LRCLK	12
-#define MADERA_FLL_SRC_AIF2LRCLK	13
-#define MADERA_FLL_SRC_AIF3LRCLK	14
-#define MADERA_FLL_SRC_AIF4LRCLK	15
-
-#define MADERA_CLK_SYSCLK_1		1
-#define MADERA_CLK_ASYNCCLK_1		2
-#define MADERA_CLK_OPCLK		3
-#define MADERA_CLK_ASYNC_OPCLK		4
-#define MADERA_CLK_SYSCLK_2		5
-#define MADERA_CLK_SYSCLK_3		6
-#define MADERA_CLK_ASYNCCLK_2		7
-#define MADERA_CLK_DSPCLK		8
-#define MADERA_CLK_OUTCLK		9
-
-#define MADERA_CLK_SRC_MCLK1		0x0
-#define MADERA_CLK_SRC_MCLK2		0x1
-#define MADERA_CLK_SRC_MCLK3		0x2
-#define MADERA_CLK_SRC_FLL1		0x4
-#define MADERA_CLK_SRC_FLL2		0x5
-#define MADERA_CLK_SRC_FLL3		0x6
-#define MADERA_CLK_SRC_FLLAO_HI		0x7
-#define MADERA_CLK_SRC_FLL1_DIV6	0x7
-#define MADERA_CLK_SRC_AIF1BCLK		0x8
-#define MADERA_CLK_SRC_AIF2BCLK		0x9
-#define MADERA_CLK_SRC_AIF3BCLK		0xA
-#define MADERA_CLK_SRC_AIF4BCLK		0xB
-#define MADERA_CLK_SRC_FLLAO		0xF
-
-#define MADERA_OUTCLK_SYSCLK		0
-#define MADERA_OUTCLK_ASYNCCLK		1
-#define MADERA_OUTCLK_MCLK1		4
-#define MADERA_OUTCLK_MCLK2		5
-#define MADERA_OUTCLK_MCLK3		6
-
 #define MADERA_MIXER_VOL_MASK		0x00FE
 #define MADERA_MIXER_VOL_SHIFT		1
 #define MADERA_MIXER_VOL_WIDTH		7
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 5/6] ASoC: madera: Export clock config defines to dt-bindings
@ 2021-01-08 16:05   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

Move the defines for clock/fll IDs and sources into the dt-bindings
header so that they can be used by machine driver dts files.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 include/dt-bindings/sound/madera.h | 60 ++++++++++++++++++++++++++++++
 sound/soc/codecs/madera.h          | 56 +---------------------------
 2 files changed, 61 insertions(+), 55 deletions(-)

diff --git a/include/dt-bindings/sound/madera.h b/include/dt-bindings/sound/madera.h
index d0096d5eb0da..5c5fc1bfe6f9 100644
--- a/include/dt-bindings/sound/madera.h
+++ b/include/dt-bindings/sound/madera.h
@@ -22,4 +22,64 @@
 #define CS47L35_DMIC_REF_MICBIAS2A	2
 #define CS47L35_DMIC_REF_MICBIAS2B	3
 
+/* FLL IDs */
+#define MADERA_FLL1_REFCLK		1
+#define MADERA_FLL2_REFCLK		2
+#define MADERA_FLL3_REFCLK		3
+#define MADERA_FLLAO_REFCLK		4
+#define MADERA_FLL1_SYNCCLK		5
+#define MADERA_FLL2_SYNCCLK		6
+#define MADERA_FLL3_SYNCCLK		7
+#define MADERA_FLLAO_SYNCCLK		8
+
+/* FLL input source pin IDs */
+#define MADERA_FLL_SRC_NONE		-1
+#define MADERA_FLL_SRC_MCLK1		0
+#define MADERA_FLL_SRC_MCLK2		1
+#define MADERA_FLL_SRC_MCLK3		2
+#define MADERA_FLL_SRC_SLIMCLK		3
+#define MADERA_FLL_SRC_FLL1		4
+#define MADERA_FLL_SRC_FLL2		5
+#define MADERA_FLL_SRC_AIF1BCLK		8
+#define MADERA_FLL_SRC_AIF2BCLK		9
+#define MADERA_FLL_SRC_AIF3BCLK		10
+#define MADERA_FLL_SRC_AIF4BCLK		11
+#define MADERA_FLL_SRC_AIF1LRCLK	12
+#define MADERA_FLL_SRC_AIF2LRCLK	13
+#define MADERA_FLL_SRC_AIF3LRCLK	14
+#define MADERA_FLL_SRC_AIF4LRCLK	15
+
+/* SYSCLK IDs */
+#define MADERA_CLK_SYSCLK_1		1
+#define MADERA_CLK_ASYNCCLK_1		2
+#define MADERA_CLK_OPCLK		3
+#define MADERA_CLK_ASYNC_OPCLK		4
+#define MADERA_CLK_SYSCLK_2		5
+#define MADERA_CLK_SYSCLK_3		6
+#define MADERA_CLK_ASYNCCLK_2		7
+#define MADERA_CLK_DSPCLK		8
+#define MADERA_CLK_OUTCLK		9
+
+/* SYSCLK source IDs */
+#define MADERA_CLK_SRC_MCLK1		0x0
+#define MADERA_CLK_SRC_MCLK2		0x1
+#define MADERA_CLK_SRC_MCLK3		0x2
+#define MADERA_CLK_SRC_FLL1		0x4
+#define MADERA_CLK_SRC_FLL2		0x5
+#define MADERA_CLK_SRC_FLL3		0x6
+#define MADERA_CLK_SRC_FLLAO_HI		0x7
+#define MADERA_CLK_SRC_FLL1_DIV6	0x7
+#define MADERA_CLK_SRC_AIF1BCLK		0x8
+#define MADERA_CLK_SRC_AIF2BCLK		0x9
+#define MADERA_CLK_SRC_AIF3BCLK		0xA
+#define MADERA_CLK_SRC_AIF4BCLK		0xB
+#define MADERA_CLK_SRC_FLLAO		0xF
+
+/* OPCLK source IDs */
+#define MADERA_OUTCLK_SYSCLK		0
+#define MADERA_OUTCLK_ASYNCCLK		1
+#define MADERA_OUTCLK_MCLK1		4
+#define MADERA_OUTCLK_MCLK2		5
+#define MADERA_OUTCLK_MCLK3		6
+
 #endif
diff --git a/sound/soc/codecs/madera.h b/sound/soc/codecs/madera.h
index e0c0be59e2ef..1f4ea15648c5 100644
--- a/sound/soc/codecs/madera.h
+++ b/sound/soc/codecs/madera.h
@@ -9,67 +9,13 @@
 #ifndef ASOC_MADERA_H
 #define ASOC_MADERA_H
 
+#include <dt-bindings/sound/madera.h>
 #include <linux/completion.h>
 #include <sound/soc.h>
 #include <sound/madera-pdata.h>
 
 #include "wm_adsp.h"
 
-#define MADERA_FLL1_REFCLK		1
-#define MADERA_FLL2_REFCLK		2
-#define MADERA_FLL3_REFCLK		3
-#define MADERA_FLLAO_REFCLK		4
-#define MADERA_FLL1_SYNCCLK		5
-#define MADERA_FLL2_SYNCCLK		6
-#define MADERA_FLL3_SYNCCLK		7
-#define MADERA_FLLAO_SYNCCLK		8
-
-#define MADERA_FLL_SRC_NONE		-1
-#define MADERA_FLL_SRC_MCLK1		0
-#define MADERA_FLL_SRC_MCLK2		1
-#define MADERA_FLL_SRC_MCLK3		2
-#define MADERA_FLL_SRC_SLIMCLK		3
-#define MADERA_FLL_SRC_FLL1		4
-#define MADERA_FLL_SRC_FLL2		5
-#define MADERA_FLL_SRC_AIF1BCLK		8
-#define MADERA_FLL_SRC_AIF2BCLK		9
-#define MADERA_FLL_SRC_AIF3BCLK		10
-#define MADERA_FLL_SRC_AIF4BCLK		11
-#define MADERA_FLL_SRC_AIF1LRCLK	12
-#define MADERA_FLL_SRC_AIF2LRCLK	13
-#define MADERA_FLL_SRC_AIF3LRCLK	14
-#define MADERA_FLL_SRC_AIF4LRCLK	15
-
-#define MADERA_CLK_SYSCLK_1		1
-#define MADERA_CLK_ASYNCCLK_1		2
-#define MADERA_CLK_OPCLK		3
-#define MADERA_CLK_ASYNC_OPCLK		4
-#define MADERA_CLK_SYSCLK_2		5
-#define MADERA_CLK_SYSCLK_3		6
-#define MADERA_CLK_ASYNCCLK_2		7
-#define MADERA_CLK_DSPCLK		8
-#define MADERA_CLK_OUTCLK		9
-
-#define MADERA_CLK_SRC_MCLK1		0x0
-#define MADERA_CLK_SRC_MCLK2		0x1
-#define MADERA_CLK_SRC_MCLK3		0x2
-#define MADERA_CLK_SRC_FLL1		0x4
-#define MADERA_CLK_SRC_FLL2		0x5
-#define MADERA_CLK_SRC_FLL3		0x6
-#define MADERA_CLK_SRC_FLLAO_HI		0x7
-#define MADERA_CLK_SRC_FLL1_DIV6	0x7
-#define MADERA_CLK_SRC_AIF1BCLK		0x8
-#define MADERA_CLK_SRC_AIF2BCLK		0x9
-#define MADERA_CLK_SRC_AIF3BCLK		0xA
-#define MADERA_CLK_SRC_AIF4BCLK		0xB
-#define MADERA_CLK_SRC_FLLAO		0xF
-
-#define MADERA_OUTCLK_SYSCLK		0
-#define MADERA_OUTCLK_ASYNCCLK		1
-#define MADERA_OUTCLK_MCLK1		4
-#define MADERA_OUTCLK_MCLK2		5
-#define MADERA_OUTCLK_MCLK3		6
-
 #define MADERA_MIXER_VOL_MASK		0x00FE
 #define MADERA_MIXER_VOL_SHIFT		1
 #define MADERA_MIXER_VOL_WIDTH		7
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15
  2021-01-08 16:04 ` Richard Fitzgerald
  (?)
@ 2021-01-08 16:05   ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
	Richard Fitzgerald

This adds a devicetree configuration for Raspberry Pi 4b connected to
Cirrus Logic Lochnagar 2 audio development board and CS47L15 codec.

The common (codec-independent) Lochnagar 2 configuration is separated
into a dtsi to simplify re-using it for other codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 ++++++++++++++++++
 4 files changed, 389 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 9407dd55673b..c61d522838ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4233,6 +4233,7 @@ M:	Charles Keepax <ckeepax@opensource.cirrus.com>
 M:	Richard Fitzgerald <rf@opensource.cirrus.com>
 L:	patches@opensource.cirrus.com
 S:	Supported
+F:	arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar*
 F:	Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b25168..87230f81aa7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2837-rpi-3-b-plus.dtb \
 	bcm2837-rpi-cm3-io3.dtb \
 	bcm2711-rpi-4-b.dtb \
+	bcm2711-rpi-4-b-lochnagar-cs47l15.dtb \
 	bcm2835-rpi-zero.dtb \
 	bcm2835-rpi-zero-w.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
new file mode 100644
index 000000000000..7b516b3d7af1
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b-lochnagar.dtsi"
+#include <dt-bindings/sound/madera.h>
+
+/ {
+	sound {
+		status = "okay";
+
+		compatible = "audio-graph-card";
+		label = "sound-card-cs47l15";
+
+		clocks = <&clk_24m>, <&fll1_out>, <&fll1_dsp>;
+		clock-names = "ln-clk-24m", "fll1-out", "fll1-dsp";
+
+		plls = <
+			&cs47l15 MADERA_FLL1_REFCLK MADERA_FLL_SRC_MCLK1 98304000
+		>;
+		plls-clocks = "ln-clk-24m";
+
+		sysclks = <
+			&cs47l15 MADERA_CLK_SYSCLK_1 MADERA_CLK_SRC_FLL1 0
+			&cs47l15 MADERA_CLK_DSPCLK   MADERA_CLK_SRC_FLL1 0
+		>;
+		sysclks-clocks = "fll1-out", "fll1-dsp";
+
+		widgets = "Microphone", "Microphone Jack",
+			  "Headphone", "Headphone Jack";
+
+		routing = "Microphone Jack", "MICBIAS1A",
+			  "IN1BRN", "Microphone Jack",
+			  "IN1BRP", "Microphone Jack",
+			  "Headphone Jack", "HPOUTL",
+			  "Headphone Jack", "HPOUTR";
+
+		dais = <&cpu_i2s_port &cs47l15_trace_port>;
+
+		/* Main output from FLL1 */
+		fll1_out: fll1_out {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <98304000>;
+		};
+
+		/* x1.5 DSP output from FLL1 */
+		fll1_dsp: fll1_dsp {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <147456000>;
+		};
+	};
+};
+
+&i2s {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu_i2s_port: port@0 {
+			reg = <0>;
+			cpu_i2s_ep: endpoint {
+				remote-endpoint = <&cs47l15_aif1>;
+				dai-format = "i2s";
+			};
+		};
+	};
+};
+
+&spi {
+	status = "okay";
+
+	cs47l15: cs47l15@1 {
+		status = "okay";
+
+		compatible = "cirrus,cs47l15";
+		reg = <0x1>;
+
+		spi-max-frequency = <11000000>;
+
+		interrupts = <27 8>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gpio>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		#sound-dai-cells = <1>;
+
+		AVDD-supply = <&lochnagar_vdd1v8>;
+		DCVDD-supply = <&lochnagar_vddcore>;
+		DBVDD1-supply = <&lochnagar_vdd1v8>;
+		CPVDD1-supply = <&lochnagar_vdd1v8>;
+		SPKVDD-supply = <&wallvdd>;
+		MICVDD-supply = <&lochnagar_micvdd>;
+
+		reset-gpios = <&lochnagar_pin 0 0>;
+
+		cirrus,dmic-ref = <
+			MADERA_DMIC_REF_MICBIAS1
+		>;
+		cirrus,inmode = <
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN1A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN1B */
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN2A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN2B */
+		>;
+
+		clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+			 <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>;
+		clock-names = "mclk1", "mclk2";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&cdc_irq &cs47l15_defaults>;
+
+		cs47l15_defaults: cs47l15-gpio-defaults {
+			aif1 {
+				groups = "aif1";
+				function = "aif1";
+				bias-bus-hold;
+			};
+			aif2 {
+				groups = "aif2";
+				function = "aif2";
+				bias-bus-hold;
+			};
+			aif3 {
+				groups = "aif3";
+				function = "aif3";
+				bias-bus-hold;
+			};
+			pdmspk1 {
+				groups = "pdmspk1";
+				function = "pdmspk1";
+			};
+		};
+
+		micvdd {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MICBIAS1 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+		};
+		MICBIAS1A {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1B {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1C {
+			regulator-active-discharge = <1>;
+		};
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			cs47l15_aif1_port: port@0 {
+				reg = <0>;
+				cs47l15_aif1: endpoint {
+					remote-endpoint = <&cpu_i2s_ep>;
+					bitclock-master;
+					frame-master;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			/* Debug trace compressed stream */
+			cs47l15_trace_port: port@3 {
+				reg = <3>;
+				cs47l15_trace_cpu: endpoint {
+					remote-endpoint = <&cs47l15_trace_codec>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			port@4 {
+				reg = <4>;
+				cs47l15_trace_codec: endpoint {
+					remote-endpoint = <&cs47l15_trace_cpu>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
new file mode 100644
index 000000000000..af498d7ad18a
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b.dts"
+#include <dt-bindings/clk/lochnagar.h>
+#include <dt-bindings/pinctrl/bcm2835.h>
+#include <dt-bindings/pinctrl/lochnagar.h>
+
+/ {
+	wallvdd: wallvdd@0 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "WALL_VDD_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+};
+
+&gpio {
+	lochnagar_present: lochnagar_present {
+		brcm,pins = <22>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	lochnagar_reset: lochnagar_reset {
+		brcm,pins = <24>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	cdc_irq: cdc_irq {
+		brcm,pins = <27>;
+		brcm,function = <BCM2835_FSEL_GPIO_IN>;
+	};
+
+	spi_pins: spi_pins {
+		brcm,pins = <9 10 11>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+
+	spi_cs: spi_cs {
+		brcm,pins = <7 8>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	i2s_pins: i2s_pins {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+};
+
+&i2s {
+	status = "okay";
+	#sound-dai-cells = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s_pins>;
+	dmas = <&dma 2>, <&dma 3>;
+	dma-names = "tx", "rx";
+};
+
+&i2c1 {
+	status = "okay";
+
+	lochnagar: lochnagar@22 {
+		status = "okay";
+
+		compatible = "cirrus,lochnagar2";
+		reg = <0x22>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&lochnagar_present &lochnagar_reset>;
+
+		reset-gpio = <&gpio 24 0>;
+		present-gpio = <&gpio 22 0>;
+
+		lochnagar_vdd1v8: VDD1V8 {
+			compatible = "regulator-fixed";
+
+			regulator-name = "VDD1V8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-boot-on;
+			regulator-always-on;
+
+			vin-supply = <&wallvdd>;
+		};
+
+		clk_pmic: clk_pmic {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+		clk_24m: clk_24m {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <24576000>;
+		};
+
+		lochnagar_clk: clk {
+			compatible = "cirrus,lochnagar2-clk";
+
+			#clock-cells = <1>;
+
+			clocks = <&clk_pmic>, <&clk_24m>;
+			clock-names = "ln-pmic-32k", "ln-clk-24m";
+
+			assigned-clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+					  <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>,
+					  <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			assigned-clock-parents = <&clk_24m>,
+						 <&clk_pmic>,
+						 <&clk_24m>;
+		};
+
+		lochnagar_pin: pin {
+			compatible = "cirrus,lochnagar-pinctrl";
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&lochnagar_pin 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>;
+
+			pinctrl-names = "default";
+			pinctrl-0 = <&pin_settings>;
+
+			pin_settings: pin_settings {
+				rpi_aif {
+					input-enable;
+					groups = "gf-aif1";
+					function = "codec-aif1";
+				};
+				codec_aif1 {
+					output-master;
+					groups = "codec-aif1";
+					function = "gf-aif1";
+				};
+				sc_codec_aif {
+					output-enable;
+					groups = "codec-aif2";
+					function = "soundcard-aif";
+				};
+				sc_lochnagar_aif {
+					input-enable;
+					groups = "soundcard-aif";
+					function = "codec-aif2";
+				};
+			};
+		};
+
+		lochnagar_hwmon: hwmon {
+			compatible = "cirrus,lochnagar2-hwmon";
+		};
+
+		lochnagar_micvdd: MICVDD {
+			compatible = "cirrus,lochnagar2-micvdd";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MIC1VDD {
+			compatible = "cirrus,lochnagar2-mic1vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <2>;
+		};
+
+		MIC2VDD {
+			compatible = "cirrus,lochnagar2-mic2vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <3>;
+		};
+
+		lochnagar_vddcore: VDDCORE {
+			compatible = "cirrus,lochnagar2-vddcore";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+		};
+
+		lochnagar_sc: soundcard {
+			compatible = "cirrus,lochnagar2-soundcard";
+
+			#sound-dai-cells = <1>;
+
+			clocks = <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			clock-names = "mclk";
+		};
+	};
+};
+
+&spi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi_pins &spi_cs>;
+	cs-gpios = <&gpio 8 1>, <&gpio 7 1>;
+};
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15
@ 2021-01-08 16:05   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

This adds a devicetree configuration for Raspberry Pi 4b connected to
Cirrus Logic Lochnagar 2 audio development board and CS47L15 codec.

The common (codec-independent) Lochnagar 2 configuration is separated
into a dtsi to simplify re-using it for other codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 ++++++++++++++++++
 4 files changed, 389 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 9407dd55673b..c61d522838ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4233,6 +4233,7 @@ M:	Charles Keepax <ckeepax@opensource.cirrus.com>
 M:	Richard Fitzgerald <rf@opensource.cirrus.com>
 L:	patches@opensource.cirrus.com
 S:	Supported
+F:	arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar*
 F:	Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b25168..87230f81aa7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2837-rpi-3-b-plus.dtb \
 	bcm2837-rpi-cm3-io3.dtb \
 	bcm2711-rpi-4-b.dtb \
+	bcm2711-rpi-4-b-lochnagar-cs47l15.dtb \
 	bcm2835-rpi-zero.dtb \
 	bcm2835-rpi-zero-w.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
new file mode 100644
index 000000000000..7b516b3d7af1
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b-lochnagar.dtsi"
+#include <dt-bindings/sound/madera.h>
+
+/ {
+	sound {
+		status = "okay";
+
+		compatible = "audio-graph-card";
+		label = "sound-card-cs47l15";
+
+		clocks = <&clk_24m>, <&fll1_out>, <&fll1_dsp>;
+		clock-names = "ln-clk-24m", "fll1-out", "fll1-dsp";
+
+		plls = <
+			&cs47l15 MADERA_FLL1_REFCLK MADERA_FLL_SRC_MCLK1 98304000
+		>;
+		plls-clocks = "ln-clk-24m";
+
+		sysclks = <
+			&cs47l15 MADERA_CLK_SYSCLK_1 MADERA_CLK_SRC_FLL1 0
+			&cs47l15 MADERA_CLK_DSPCLK   MADERA_CLK_SRC_FLL1 0
+		>;
+		sysclks-clocks = "fll1-out", "fll1-dsp";
+
+		widgets = "Microphone", "Microphone Jack",
+			  "Headphone", "Headphone Jack";
+
+		routing = "Microphone Jack", "MICBIAS1A",
+			  "IN1BRN", "Microphone Jack",
+			  "IN1BRP", "Microphone Jack",
+			  "Headphone Jack", "HPOUTL",
+			  "Headphone Jack", "HPOUTR";
+
+		dais = <&cpu_i2s_port &cs47l15_trace_port>;
+
+		/* Main output from FLL1 */
+		fll1_out: fll1_out {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <98304000>;
+		};
+
+		/* x1.5 DSP output from FLL1 */
+		fll1_dsp: fll1_dsp {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <147456000>;
+		};
+	};
+};
+
+&i2s {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu_i2s_port: port@0 {
+			reg = <0>;
+			cpu_i2s_ep: endpoint {
+				remote-endpoint = <&cs47l15_aif1>;
+				dai-format = "i2s";
+			};
+		};
+	};
+};
+
+&spi {
+	status = "okay";
+
+	cs47l15: cs47l15@1 {
+		status = "okay";
+
+		compatible = "cirrus,cs47l15";
+		reg = <0x1>;
+
+		spi-max-frequency = <11000000>;
+
+		interrupts = <27 8>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gpio>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		#sound-dai-cells = <1>;
+
+		AVDD-supply = <&lochnagar_vdd1v8>;
+		DCVDD-supply = <&lochnagar_vddcore>;
+		DBVDD1-supply = <&lochnagar_vdd1v8>;
+		CPVDD1-supply = <&lochnagar_vdd1v8>;
+		SPKVDD-supply = <&wallvdd>;
+		MICVDD-supply = <&lochnagar_micvdd>;
+
+		reset-gpios = <&lochnagar_pin 0 0>;
+
+		cirrus,dmic-ref = <
+			MADERA_DMIC_REF_MICBIAS1
+		>;
+		cirrus,inmode = <
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN1A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN1B */
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN2A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN2B */
+		>;
+
+		clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+			 <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>;
+		clock-names = "mclk1", "mclk2";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&cdc_irq &cs47l15_defaults>;
+
+		cs47l15_defaults: cs47l15-gpio-defaults {
+			aif1 {
+				groups = "aif1";
+				function = "aif1";
+				bias-bus-hold;
+			};
+			aif2 {
+				groups = "aif2";
+				function = "aif2";
+				bias-bus-hold;
+			};
+			aif3 {
+				groups = "aif3";
+				function = "aif3";
+				bias-bus-hold;
+			};
+			pdmspk1 {
+				groups = "pdmspk1";
+				function = "pdmspk1";
+			};
+		};
+
+		micvdd {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MICBIAS1 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+		};
+		MICBIAS1A {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1B {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1C {
+			regulator-active-discharge = <1>;
+		};
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			cs47l15_aif1_port: port@0 {
+				reg = <0>;
+				cs47l15_aif1: endpoint {
+					remote-endpoint = <&cpu_i2s_ep>;
+					bitclock-master;
+					frame-master;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			/* Debug trace compressed stream */
+			cs47l15_trace_port: port@3 {
+				reg = <3>;
+				cs47l15_trace_cpu: endpoint {
+					remote-endpoint = <&cs47l15_trace_codec>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			port@4 {
+				reg = <4>;
+				cs47l15_trace_codec: endpoint {
+					remote-endpoint = <&cs47l15_trace_cpu>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
new file mode 100644
index 000000000000..af498d7ad18a
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b.dts"
+#include <dt-bindings/clk/lochnagar.h>
+#include <dt-bindings/pinctrl/bcm2835.h>
+#include <dt-bindings/pinctrl/lochnagar.h>
+
+/ {
+	wallvdd: wallvdd@0 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "WALL_VDD_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+};
+
+&gpio {
+	lochnagar_present: lochnagar_present {
+		brcm,pins = <22>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	lochnagar_reset: lochnagar_reset {
+		brcm,pins = <24>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	cdc_irq: cdc_irq {
+		brcm,pins = <27>;
+		brcm,function = <BCM2835_FSEL_GPIO_IN>;
+	};
+
+	spi_pins: spi_pins {
+		brcm,pins = <9 10 11>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+
+	spi_cs: spi_cs {
+		brcm,pins = <7 8>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	i2s_pins: i2s_pins {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+};
+
+&i2s {
+	status = "okay";
+	#sound-dai-cells = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s_pins>;
+	dmas = <&dma 2>, <&dma 3>;
+	dma-names = "tx", "rx";
+};
+
+&i2c1 {
+	status = "okay";
+
+	lochnagar: lochnagar@22 {
+		status = "okay";
+
+		compatible = "cirrus,lochnagar2";
+		reg = <0x22>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&lochnagar_present &lochnagar_reset>;
+
+		reset-gpio = <&gpio 24 0>;
+		present-gpio = <&gpio 22 0>;
+
+		lochnagar_vdd1v8: VDD1V8 {
+			compatible = "regulator-fixed";
+
+			regulator-name = "VDD1V8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-boot-on;
+			regulator-always-on;
+
+			vin-supply = <&wallvdd>;
+		};
+
+		clk_pmic: clk_pmic {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+		clk_24m: clk_24m {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <24576000>;
+		};
+
+		lochnagar_clk: clk {
+			compatible = "cirrus,lochnagar2-clk";
+
+			#clock-cells = <1>;
+
+			clocks = <&clk_pmic>, <&clk_24m>;
+			clock-names = "ln-pmic-32k", "ln-clk-24m";
+
+			assigned-clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+					  <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>,
+					  <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			assigned-clock-parents = <&clk_24m>,
+						 <&clk_pmic>,
+						 <&clk_24m>;
+		};
+
+		lochnagar_pin: pin {
+			compatible = "cirrus,lochnagar-pinctrl";
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&lochnagar_pin 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>;
+
+			pinctrl-names = "default";
+			pinctrl-0 = <&pin_settings>;
+
+			pin_settings: pin_settings {
+				rpi_aif {
+					input-enable;
+					groups = "gf-aif1";
+					function = "codec-aif1";
+				};
+				codec_aif1 {
+					output-master;
+					groups = "codec-aif1";
+					function = "gf-aif1";
+				};
+				sc_codec_aif {
+					output-enable;
+					groups = "codec-aif2";
+					function = "soundcard-aif";
+				};
+				sc_lochnagar_aif {
+					input-enable;
+					groups = "soundcard-aif";
+					function = "codec-aif2";
+				};
+			};
+		};
+
+		lochnagar_hwmon: hwmon {
+			compatible = "cirrus,lochnagar2-hwmon";
+		};
+
+		lochnagar_micvdd: MICVDD {
+			compatible = "cirrus,lochnagar2-micvdd";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MIC1VDD {
+			compatible = "cirrus,lochnagar2-mic1vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <2>;
+		};
+
+		MIC2VDD {
+			compatible = "cirrus,lochnagar2-mic2vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <3>;
+		};
+
+		lochnagar_vddcore: VDDCORE {
+			compatible = "cirrus,lochnagar2-vddcore";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+		};
+
+		lochnagar_sc: soundcard {
+			compatible = "cirrus,lochnagar2-soundcard";
+
+			#sound-dai-cells = <1>;
+
+			clocks = <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			clock-names = "mclk";
+		};
+	};
+};
+
+&spi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi_pins &spi_cs>;
+	cs-gpios = <&gpio 8 1>, <&gpio 7 1>;
+};
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 64+ messages in thread

* [PATCH v4 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15
@ 2021-01-08 16:05   ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-08 16:05 UTC (permalink / raw)
  To: broonie, robh+dt, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli
  Cc: devicetree, alsa-devel, patches, linux-kernel,
	Richard Fitzgerald, bcm-kernel-feedback-list, linux-rpi-kernel,
	linux-arm-kernel

This adds a devicetree configuration for Raspberry Pi 4b connected to
Cirrus Logic Lochnagar 2 audio development board and CS47L15 codec.

The common (codec-independent) Lochnagar 2 configuration is separated
into a dtsi to simplify re-using it for other codecs.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 MAINTAINERS                                   |   1 +
 arch/arm/boot/dts/Makefile                    |   1 +
 .../dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts | 186 ++++++++++++++++
 .../boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi   | 201 ++++++++++++++++++
 4 files changed, 389 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index 9407dd55673b..c61d522838ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4233,6 +4233,7 @@ M:	Charles Keepax <ckeepax@opensource.cirrus.com>
 M:	Richard Fitzgerald <rf@opensource.cirrus.com>
 L:	patches@opensource.cirrus.com
 S:	Supported
+F:	arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar*
 F:	Documentation/devicetree/bindings/clock/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.yaml
 F:	Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3d1ea0b25168..87230f81aa7a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2837-rpi-3-b-plus.dtb \
 	bcm2837-rpi-cm3-io3.dtb \
 	bcm2711-rpi-4-b.dtb \
+	bcm2711-rpi-4-b-lochnagar-cs47l15.dtb \
 	bcm2835-rpi-zero.dtb \
 	bcm2835-rpi-zero-w.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
new file mode 100644
index 000000000000..7b516b3d7af1
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar-cs47l15.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b-lochnagar.dtsi"
+#include <dt-bindings/sound/madera.h>
+
+/ {
+	sound {
+		status = "okay";
+
+		compatible = "audio-graph-card";
+		label = "sound-card-cs47l15";
+
+		clocks = <&clk_24m>, <&fll1_out>, <&fll1_dsp>;
+		clock-names = "ln-clk-24m", "fll1-out", "fll1-dsp";
+
+		plls = <
+			&cs47l15 MADERA_FLL1_REFCLK MADERA_FLL_SRC_MCLK1 98304000
+		>;
+		plls-clocks = "ln-clk-24m";
+
+		sysclks = <
+			&cs47l15 MADERA_CLK_SYSCLK_1 MADERA_CLK_SRC_FLL1 0
+			&cs47l15 MADERA_CLK_DSPCLK   MADERA_CLK_SRC_FLL1 0
+		>;
+		sysclks-clocks = "fll1-out", "fll1-dsp";
+
+		widgets = "Microphone", "Microphone Jack",
+			  "Headphone", "Headphone Jack";
+
+		routing = "Microphone Jack", "MICBIAS1A",
+			  "IN1BRN", "Microphone Jack",
+			  "IN1BRP", "Microphone Jack",
+			  "Headphone Jack", "HPOUTL",
+			  "Headphone Jack", "HPOUTR";
+
+		dais = <&cpu_i2s_port &cs47l15_trace_port>;
+
+		/* Main output from FLL1 */
+		fll1_out: fll1_out {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <98304000>;
+		};
+
+		/* x1.5 DSP output from FLL1 */
+		fll1_dsp: fll1_dsp {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <147456000>;
+		};
+	};
+};
+
+&i2s {
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		cpu_i2s_port: port@0 {
+			reg = <0>;
+			cpu_i2s_ep: endpoint {
+				remote-endpoint = <&cs47l15_aif1>;
+				dai-format = "i2s";
+			};
+		};
+	};
+};
+
+&spi {
+	status = "okay";
+
+	cs47l15: cs47l15@1 {
+		status = "okay";
+
+		compatible = "cirrus,cs47l15";
+		reg = <0x1>;
+
+		spi-max-frequency = <11000000>;
+
+		interrupts = <27 8>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		interrupt-parent = <&gpio>;
+		gpio-controller;
+		#gpio-cells = <2>;
+		#sound-dai-cells = <1>;
+
+		AVDD-supply = <&lochnagar_vdd1v8>;
+		DCVDD-supply = <&lochnagar_vddcore>;
+		DBVDD1-supply = <&lochnagar_vdd1v8>;
+		CPVDD1-supply = <&lochnagar_vdd1v8>;
+		SPKVDD-supply = <&wallvdd>;
+		MICVDD-supply = <&lochnagar_micvdd>;
+
+		reset-gpios = <&lochnagar_pin 0 0>;
+
+		cirrus,dmic-ref = <
+			MADERA_DMIC_REF_MICBIAS1
+		>;
+		cirrus,inmode = <
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN1A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN1B */
+			MADERA_INMODE_SE   MADERA_INMODE_SE   /* IN2A */
+			MADERA_INMODE_DIFF MADERA_INMODE_DIFF /* IN2B */
+		>;
+
+		clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+			 <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>;
+		clock-names = "mclk1", "mclk2";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&cdc_irq &cs47l15_defaults>;
+
+		cs47l15_defaults: cs47l15-gpio-defaults {
+			aif1 {
+				groups = "aif1";
+				function = "aif1";
+				bias-bus-hold;
+			};
+			aif2 {
+				groups = "aif2";
+				function = "aif2";
+				bias-bus-hold;
+			};
+			aif3 {
+				groups = "aif3";
+				function = "aif3";
+				bias-bus-hold;
+			};
+			pdmspk1 {
+				groups = "pdmspk1";
+				function = "pdmspk1";
+			};
+		};
+
+		micvdd {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MICBIAS1 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+		};
+		MICBIAS1A {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1B {
+			regulator-active-discharge = <1>;
+		};
+		MICBIAS1C {
+			regulator-active-discharge = <1>;
+		};
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			cs47l15_aif1_port: port@0 {
+				reg = <0>;
+				cs47l15_aif1: endpoint {
+					remote-endpoint = <&cpu_i2s_ep>;
+					bitclock-master;
+					frame-master;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			/* Debug trace compressed stream */
+			cs47l15_trace_port: port@3 {
+				reg = <3>;
+				cs47l15_trace_cpu: endpoint {
+					remote-endpoint = <&cs47l15_trace_codec>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+			port@4 {
+				reg = <4>;
+				cs47l15_trace_codec: endpoint {
+					remote-endpoint = <&cs47l15_trace_cpu>;
+					system-clock-frequency = <0>;
+					mclk-fs = <0>;
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
new file mode 100644
index 000000000000..af498d7ad18a
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b-lochnagar.dtsi
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+#include "bcm2711-rpi-4-b.dts"
+#include <dt-bindings/clk/lochnagar.h>
+#include <dt-bindings/pinctrl/bcm2835.h>
+#include <dt-bindings/pinctrl/lochnagar.h>
+
+/ {
+	wallvdd: wallvdd@0 {
+		compatible = "regulator-fixed";
+
+		regulator-name = "WALL_VDD_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		regulator-always-on;
+	};
+
+};
+
+&gpio {
+	lochnagar_present: lochnagar_present {
+		brcm,pins = <22>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	lochnagar_reset: lochnagar_reset {
+		brcm,pins = <24>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	cdc_irq: cdc_irq {
+		brcm,pins = <27>;
+		brcm,function = <BCM2835_FSEL_GPIO_IN>;
+	};
+
+	spi_pins: spi_pins {
+		brcm,pins = <9 10 11>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+
+	spi_cs: spi_cs {
+		brcm,pins = <7 8>;
+		brcm,function = <BCM2835_FSEL_GPIO_OUT>;
+	};
+
+	i2s_pins: i2s_pins {
+		brcm,pins = <18 19 20 21>;
+		brcm,function = <BCM2835_FSEL_ALT0>;
+	};
+};
+
+&i2s {
+	status = "okay";
+	#sound-dai-cells = <1>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2s_pins>;
+	dmas = <&dma 2>, <&dma 3>;
+	dma-names = "tx", "rx";
+};
+
+&i2c1 {
+	status = "okay";
+
+	lochnagar: lochnagar@22 {
+		status = "okay";
+
+		compatible = "cirrus,lochnagar2";
+		reg = <0x22>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&lochnagar_present &lochnagar_reset>;
+
+		reset-gpio = <&gpio 24 0>;
+		present-gpio = <&gpio 22 0>;
+
+		lochnagar_vdd1v8: VDD1V8 {
+			compatible = "regulator-fixed";
+
+			regulator-name = "VDD1V8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-boot-on;
+			regulator-always-on;
+
+			vin-supply = <&wallvdd>;
+		};
+
+		clk_pmic: clk_pmic {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+		clk_24m: clk_24m {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <24576000>;
+		};
+
+		lochnagar_clk: clk {
+			compatible = "cirrus,lochnagar2-clk";
+
+			#clock-cells = <1>;
+
+			clocks = <&clk_pmic>, <&clk_24m>;
+			clock-names = "ln-pmic-32k", "ln-clk-24m";
+
+			assigned-clocks = <&lochnagar_clk LOCHNAGAR_CDC_MCLK1>,
+					  <&lochnagar_clk LOCHNAGAR_CDC_MCLK2>,
+					  <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			assigned-clock-parents = <&clk_24m>,
+						 <&clk_pmic>,
+						 <&clk_24m>;
+		};
+
+		lochnagar_pin: pin {
+			compatible = "cirrus,lochnagar-pinctrl";
+
+			gpio-controller;
+			#gpio-cells = <2>;
+			gpio-ranges = <&lochnagar_pin 0 0 LOCHNAGAR2_PIN_NUM_GPIOS>;
+
+			pinctrl-names = "default";
+			pinctrl-0 = <&pin_settings>;
+
+			pin_settings: pin_settings {
+				rpi_aif {
+					input-enable;
+					groups = "gf-aif1";
+					function = "codec-aif1";
+				};
+				codec_aif1 {
+					output-master;
+					groups = "codec-aif1";
+					function = "gf-aif1";
+				};
+				sc_codec_aif {
+					output-enable;
+					groups = "codec-aif2";
+					function = "soundcard-aif";
+				};
+				sc_lochnagar_aif {
+					input-enable;
+					groups = "soundcard-aif";
+					function = "codec-aif2";
+				};
+			};
+		};
+
+		lochnagar_hwmon: hwmon {
+			compatible = "cirrus,lochnagar2-hwmon";
+		};
+
+		lochnagar_micvdd: MICVDD {
+			compatible = "cirrus,lochnagar2-micvdd";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+		};
+
+		MIC1VDD {
+			compatible = "cirrus,lochnagar2-mic1vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <2>;
+		};
+
+		MIC2VDD {
+			compatible = "cirrus,lochnagar2-mic2vdd";
+
+			regulator-always-on;
+			cirrus,micbias-input = <3>;
+		};
+
+		lochnagar_vddcore: VDDCORE {
+			compatible = "cirrus,lochnagar2-vddcore";
+
+			SYSVDD-supply = <&wallvdd>;
+
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+		};
+
+		lochnagar_sc: soundcard {
+			compatible = "cirrus,lochnagar2-soundcard";
+
+			#sound-dai-cells = <1>;
+
+			clocks = <&lochnagar_clk LOCHNAGAR_SOUNDCARD_MCLK>;
+			clock-names = "mclk";
+		};
+	};
+};
+
+&spi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi_pins &spi_cs>;
+	cs-gpios = <&gpio 8 1>, <&gpio 7 1>;
+};
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
  2021-01-08 16:04   ` Richard Fitzgerald
  (?)
@ 2021-01-12  1:35     ` Kuninori Morimoto
  -1 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-12  1:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: broonie, robh+dt, nsaenzjulienne, f.fainelli, linux-kernel,
	devicetree, alsa-devel, patches, bcm-kernel-feedback-list,
	linux-rpi-kernel, linux-arm-kernel


Hi Richard

> Some codecs need plls and/or sysclks to be configured using the
> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
> necessarily be converted to use the clock framework. If the codec is on
> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
> But the clock framework does not support nested operations and this would
> deadlock.
> 
> This patch adds new dt properties that list phandles of components with
> the pll/sysclk settings to be applied. Multiple settings can be given for
> the same phandle to allow for components with multiple clocks and plls.
> The plls and sysclks are enabled when the card bias level moves to STANDBY
> and disabled when it moves to OFF.
> 
> The implementation does not attempt to handle specifying complex clock
> ordering interdependencies between components. The plls and sysclks are
> applied to a component as it is passed to the card set_bias_level/
> set_bias_level_post callbacks. It follows from this that the order
> components are configured is the order that they are passed to those
> callbacks.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---

As I mentioned in v3, adding *general* pll to common card driver is
maybe difficult.
Using your own customized audio-graph-card driver is better idea,
instead of adding code to common driver.

I think Sameer's Tegra driver (= [3/6]) is good sample for you ?

	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com

Thank you for your help !!

Best regards
---
Kuninori Morimoto

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-12  1:35     ` Kuninori Morimoto
  0 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-12  1:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


Hi Richard

> Some codecs need plls and/or sysclks to be configured using the
> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
> necessarily be converted to use the clock framework. If the codec is on
> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
> But the clock framework does not support nested operations and this would
> deadlock.
> 
> This patch adds new dt properties that list phandles of components with
> the pll/sysclk settings to be applied. Multiple settings can be given for
> the same phandle to allow for components with multiple clocks and plls.
> The plls and sysclks are enabled when the card bias level moves to STANDBY
> and disabled when it moves to OFF.
> 
> The implementation does not attempt to handle specifying complex clock
> ordering interdependencies between components. The plls and sysclks are
> applied to a component as it is passed to the card set_bias_level/
> set_bias_level_post callbacks. It follows from this that the order
> components are configured is the order that they are passed to those
> callbacks.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---

As I mentioned in v3, adding *general* pll to common card driver is
maybe difficult.
Using your own customized audio-graph-card driver is better idea,
instead of adding code to common driver.

I think Sameer's Tegra driver (= [3/6]) is good sample for you ?

	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com

Thank you for your help !!

Best regards
---
Kuninori Morimoto

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-12  1:35     ` Kuninori Morimoto
  0 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-12  1:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


Hi Richard

> Some codecs need plls and/or sysclks to be configured using the
> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
> necessarily be converted to use the clock framework. If the codec is on
> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
> But the clock framework does not support nested operations and this would
> deadlock.
> 
> This patch adds new dt properties that list phandles of components with
> the pll/sysclk settings to be applied. Multiple settings can be given for
> the same phandle to allow for components with multiple clocks and plls.
> The plls and sysclks are enabled when the card bias level moves to STANDBY
> and disabled when it moves to OFF.
> 
> The implementation does not attempt to handle specifying complex clock
> ordering interdependencies between components. The plls and sysclks are
> applied to a component as it is passed to the card set_bias_level/
> set_bias_level_post callbacks. It follows from this that the order
> components are configured is the order that they are passed to those
> callbacks.
> 
> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---

As I mentioned in v3, adding *general* pll to common card driver is
maybe difficult.
Using your own customized audio-graph-card driver is better idea,
instead of adding code to common driver.

I think Sameer's Tegra driver (= [3/6]) is good sample for you ?

	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com

Thank you for your help !!

Best regards
---
Kuninori Morimoto

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
  2021-01-12  1:35     ` Kuninori Morimoto
  (?)
@ 2021-01-12 10:22       ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-12 10:22 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: broonie, robh+dt, nsaenzjulienne, f.fainelli, linux-kernel,
	devicetree, alsa-devel, patches, bcm-kernel-feedback-list,
	linux-rpi-kernel, linux-arm-kernel

On 12/01/2021 01:35, Kuninori Morimoto wrote:
> 
> Hi Richard
> 
>> Some codecs need plls and/or sysclks to be configured using the
>> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
>> necessarily be converted to use the clock framework. If the codec is on
>> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
>> But the clock framework does not support nested operations and this would
>> deadlock.
>>
>> This patch adds new dt properties that list phandles of components with
>> the pll/sysclk settings to be applied. Multiple settings can be given for
>> the same phandle to allow for components with multiple clocks and plls.
>> The plls and sysclks are enabled when the card bias level moves to STANDBY
>> and disabled when it moves to OFF.
>>
>> The implementation does not attempt to handle specifying complex clock
>> ordering interdependencies between components. The plls and sysclks are
>> applied to a component as it is passed to the card set_bias_level/
>> set_bias_level_post callbacks. It follows from this that the order
>> components are configured is the order that they are passed to those
>> callbacks.
>>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
> 
> As I mentioned in v3, adding *general* pll to common card driver is
> maybe difficult.

You did say that. But you did not say why.
Can you be more specific about what problem you see with adding it
to the generic driver?

> Using your own customized audio-graph-card driver is better idea,
> instead of adding code to common driver.

I just don't want to duplicate code without good reason.

> 
> I think Sameer's Tegra driver (= [3/6]) is good sample for you ?
> 
> 	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com
> 
> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto
> 

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-12 10:22       ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-12 10:22 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne

On 12/01/2021 01:35, Kuninori Morimoto wrote:
> 
> Hi Richard
> 
>> Some codecs need plls and/or sysclks to be configured using the
>> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
>> necessarily be converted to use the clock framework. If the codec is on
>> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
>> But the clock framework does not support nested operations and this would
>> deadlock.
>>
>> This patch adds new dt properties that list phandles of components with
>> the pll/sysclk settings to be applied. Multiple settings can be given for
>> the same phandle to allow for components with multiple clocks and plls.
>> The plls and sysclks are enabled when the card bias level moves to STANDBY
>> and disabled when it moves to OFF.
>>
>> The implementation does not attempt to handle specifying complex clock
>> ordering interdependencies between components. The plls and sysclks are
>> applied to a component as it is passed to the card set_bias_level/
>> set_bias_level_post callbacks. It follows from this that the order
>> components are configured is the order that they are passed to those
>> callbacks.
>>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
> 
> As I mentioned in v3, adding *general* pll to common card driver is
> maybe difficult.

You did say that. But you did not say why.
Can you be more specific about what problem you see with adding it
to the generic driver?

> Using your own customized audio-graph-card driver is better idea,
> instead of adding code to common driver.

I just don't want to duplicate code without good reason.

> 
> I think Sameer's Tegra driver (= [3/6]) is good sample for you ?
> 
> 	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com
> 
> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto
> 

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-12 10:22       ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-12 10:22 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne

On 12/01/2021 01:35, Kuninori Morimoto wrote:
> 
> Hi Richard
> 
>> Some codecs need plls and/or sysclks to be configured using the
>> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot
>> necessarily be converted to use the clock framework. If the codec is on
>> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock.
>> But the clock framework does not support nested operations and this would
>> deadlock.
>>
>> This patch adds new dt properties that list phandles of components with
>> the pll/sysclk settings to be applied. Multiple settings can be given for
>> the same phandle to allow for components with multiple clocks and plls.
>> The plls and sysclks are enabled when the card bias level moves to STANDBY
>> and disabled when it moves to OFF.
>>
>> The implementation does not attempt to handle specifying complex clock
>> ordering interdependencies between components. The plls and sysclks are
>> applied to a component as it is passed to the card set_bias_level/
>> set_bias_level_post callbacks. It follows from this that the order
>> components are configured is the order that they are passed to those
>> callbacks.
>>
>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
> 
> As I mentioned in v3, adding *general* pll to common card driver is
> maybe difficult.

You did say that. But you did not say why.
Can you be more specific about what problem you see with adding it
to the generic driver?

> Using your own customized audio-graph-card driver is better idea,
> instead of adding code to common driver.

I just don't want to duplicate code without good reason.

> 
> I think Sameer's Tegra driver (= [3/6]) is good sample for you ?
> 
> 	https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com
> 
> Thank you for your help !!
> 
> Best regards
> ---
> Kuninori Morimoto
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
  2021-01-12 10:22       ` Richard Fitzgerald
  (?)
@ 2021-01-13  0:00         ` Kuninori Morimoto
  -1 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-13  0:00 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: broonie, robh+dt, nsaenzjulienne, f.fainelli, linux-kernel,
	devicetree, alsa-devel, patches, bcm-kernel-feedback-list,
	linux-rpi-kernel, linux-arm-kernel


Hi Richard

> > As I mentioned in v3, adding *general* pll to common card driver is
> > maybe difficult.
> 
> You did say that. But you did not say why.
> Can you be more specific about what problem you see with adding it
> to the generic driver?
> 
> > Using your own customized audio-graph-card driver is better idea,
> > instead of adding code to common driver.
> 
> I just don't want to duplicate code without good reason.

Ahh, sorry for my unclear comment.
I think "PLL settings" is very board/platform specific,
so, adding such code to common driver will be issue in the future.
This is the reason why I don't want add it to audio-graph-card.

But, as I mentioned above and Sameer is already doing,
you can reuse audio-graph-card and customize it.

	Reuse audio-graph-card + Use your own PLL code
	= your own customized audio-graph-card

You can reuse audio-graph-card code by calling graph_parse_of(),
and customize before/after that.
I think no duplicate code is needed.

I hope it can help you.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-13  0:00         ` Kuninori Morimoto
  0 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-13  0:00 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


Hi Richard

> > As I mentioned in v3, adding *general* pll to common card driver is
> > maybe difficult.
> 
> You did say that. But you did not say why.
> Can you be more specific about what problem you see with adding it
> to the generic driver?
> 
> > Using your own customized audio-graph-card driver is better idea,
> > instead of adding code to common driver.
> 
> I just don't want to duplicate code without good reason.

Ahh, sorry for my unclear comment.
I think "PLL settings" is very board/platform specific,
so, adding such code to common driver will be issue in the future.
This is the reason why I don't want add it to audio-graph-card.

But, as I mentioned above and Sameer is already doing,
you can reuse audio-graph-card and customize it.

	Reuse audio-graph-card + Use your own PLL code
	= your own customized audio-graph-card

You can reuse audio-graph-card code by calling graph_parse_of(),
and customize before/after that.
I think no duplicate code is needed.

I hope it can help you.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-13  0:00         ` Kuninori Morimoto
  0 siblings, 0 replies; 64+ messages in thread
From: Kuninori Morimoto @ 2021-01-13  0:00 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, robh+dt, broonie, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


Hi Richard

> > As I mentioned in v3, adding *general* pll to common card driver is
> > maybe difficult.
> 
> You did say that. But you did not say why.
> Can you be more specific about what problem you see with adding it
> to the generic driver?
> 
> > Using your own customized audio-graph-card driver is better idea,
> > instead of adding code to common driver.
> 
> I just don't want to duplicate code without good reason.

Ahh, sorry for my unclear comment.
I think "PLL settings" is very board/platform specific,
so, adding such code to common driver will be issue in the future.
This is the reason why I don't want add it to audio-graph-card.

But, as I mentioned above and Sameer is already doing,
you can reuse audio-graph-card and customize it.

	Reuse audio-graph-card + Use your own PLL code
	= your own customized audio-graph-card

You can reuse audio-graph-card code by calling graph_parse_of(),
and customize before/after that.
I think no duplicate code is needed.

I hope it can help you.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-08 16:04   ` Richard Fitzgerald
  (?)
@ 2021-01-13 15:22     ` Rob Herring
  -1 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2021-01-13 15:22 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: broonie, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
> The audio-graph-card driver has properties for configuring the clocking
> for DAIs within a component, but is missing properties for setting
> up the PLLs and sysclks of the component.
> 
> This patch adds the two new properties 'plls' and 'sysclks' so that the
> audio-graph-driver can fully configure the component clocking.

I'm not sure this makes sense to be generic, but if so, we already have 
the clock binding and should use (and possibly extend) that.

This appears to all be configuration of clocks within the codec, so 
these properties belong in the codec or cpu nodes.

> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---
>  .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> index 4b46794e5153..9e0819205a17 100644
> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> @@ -39,6 +39,52 @@ properties:
>    mic-det-gpio:
>      maxItems: 1
>  
> +  plls:
> +    description: |
> +      A list of component pll settings. There are 4 cells per PLL setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component PLL id,
> +        - component clock source id,
> +        - frequency (in Hz) of the PLL output clock.

assigned-clocks binding can set frequencies and parent clocks.

'pll' is too specific to the implementation. You may want to configure 
the freq and parent of something that's not a pll.

> +      The PLL id and clock source id are specific to the particular component
> +      so see the relevant component driver for the ids. Typically the
> +      clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several plls
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  plls-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the plls property.
> +
> +  sysclks:
> +    description: |
> +      A list of component sysclk settings. There are 4 cells per sysclk
> +      setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component sysclk id,
> +        - component clock source id,
> +        - direction of the clock: 0 if the clock is an input to the component,
> +          1 if it is an output.

A clock provider and consumer would provide the direction.

> +      The sysclk id and clock source id are specific to the particular
> +      component so see the relevant component driver for the ids. Typically
> +      the clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several sysclks
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  sysclks-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the sysclks property.
> +
> +dependencies:
> +  plls: [ plls-clocks ]
> +  sysclks: [ sysclks-clocks ]
> +
>  required:
>    - dais
>  
> -- 
> 2.20.1
> 

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-13 15:22     ` Rob Herring
  0 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2021-01-13 15:22 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, broonie,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
> The audio-graph-card driver has properties for configuring the clocking
> for DAIs within a component, but is missing properties for setting
> up the PLLs and sysclks of the component.
> 
> This patch adds the two new properties 'plls' and 'sysclks' so that the
> audio-graph-driver can fully configure the component clocking.

I'm not sure this makes sense to be generic, but if so, we already have 
the clock binding and should use (and possibly extend) that.

This appears to all be configuration of clocks within the codec, so 
these properties belong in the codec or cpu nodes.

> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---
>  .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> index 4b46794e5153..9e0819205a17 100644
> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> @@ -39,6 +39,52 @@ properties:
>    mic-det-gpio:
>      maxItems: 1
>  
> +  plls:
> +    description: |
> +      A list of component pll settings. There are 4 cells per PLL setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component PLL id,
> +        - component clock source id,
> +        - frequency (in Hz) of the PLL output clock.

assigned-clocks binding can set frequencies and parent clocks.

'pll' is too specific to the implementation. You may want to configure 
the freq and parent of something that's not a pll.

> +      The PLL id and clock source id are specific to the particular component
> +      so see the relevant component driver for the ids. Typically the
> +      clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several plls
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  plls-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the plls property.
> +
> +  sysclks:
> +    description: |
> +      A list of component sysclk settings. There are 4 cells per sysclk
> +      setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component sysclk id,
> +        - component clock source id,
> +        - direction of the clock: 0 if the clock is an input to the component,
> +          1 if it is an output.

A clock provider and consumer would provide the direction.

> +      The sysclk id and clock source id are specific to the particular
> +      component so see the relevant component driver for the ids. Typically
> +      the clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several sysclks
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  sysclks-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the sysclks property.
> +
> +dependencies:
> +  plls: [ plls-clocks ]
> +  sysclks: [ sysclks-clocks ]
> +
>  required:
>    - dais
>  
> -- 
> 2.20.1
> 

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-13 15:22     ` Rob Herring
  0 siblings, 0 replies; 64+ messages in thread
From: Rob Herring @ 2021-01-13 15:22 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, broonie,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
> The audio-graph-card driver has properties for configuring the clocking
> for DAIs within a component, but is missing properties for setting
> up the PLLs and sysclks of the component.
> 
> This patch adds the two new properties 'plls' and 'sysclks' so that the
> audio-graph-driver can fully configure the component clocking.

I'm not sure this makes sense to be generic, but if so, we already have 
the clock binding and should use (and possibly extend) that.

This appears to all be configuration of clocks within the codec, so 
these properties belong in the codec or cpu nodes.

> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
> ---
>  .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>  1 file changed, 46 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> index 4b46794e5153..9e0819205a17 100644
> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
> @@ -39,6 +39,52 @@ properties:
>    mic-det-gpio:
>      maxItems: 1
>  
> +  plls:
> +    description: |
> +      A list of component pll settings. There are 4 cells per PLL setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component PLL id,
> +        - component clock source id,
> +        - frequency (in Hz) of the PLL output clock.

assigned-clocks binding can set frequencies and parent clocks.

'pll' is too specific to the implementation. You may want to configure 
the freq and parent of something that's not a pll.

> +      The PLL id and clock source id are specific to the particular component
> +      so see the relevant component driver for the ids. Typically the
> +      clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several plls
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  plls-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the plls property.
> +
> +  sysclks:
> +    description: |
> +      A list of component sysclk settings. There are 4 cells per sysclk
> +      setting:
> +        - phandle to the node of the codec or cpu component,
> +        - component sysclk id,
> +        - component clock source id,
> +        - direction of the clock: 0 if the clock is an input to the component,
> +          1 if it is an output.

A clock provider and consumer would provide the direction.

> +      The sysclk id and clock source id are specific to the particular
> +      component so see the relevant component driver for the ids. Typically
> +      the clock source id indicates the pin the source clock is connected to.
> +      The same phandle can appear in multiple entries so that several sysclks
> +      can be set in the same component.
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +  sysclks-clocks:
> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> +    description: |
> +      A list of clock names giving the source clock for each setting
> +      in the sysclks property.
> +
> +dependencies:
> +  plls: [ plls-clocks ]
> +  sysclks: [ sysclks-clocks ]
> +
>  required:
>    - dais
>  
> -- 
> 2.20.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
  2021-01-13  0:00         ` Kuninori Morimoto
  (?)
@ 2021-01-13 15:51           ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 15:51 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: Richard Fitzgerald, robh+dt, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Wed, Jan 13, 2021 at 09:00:19AM +0900, Kuninori Morimoto wrote:

> Ahh, sorry for my unclear comment.
> I think "PLL settings" is very board/platform specific,
> so, adding such code to common driver will be issue in the future.
> This is the reason why I don't want add it to audio-graph-card.

I don't think it's *that* weird, they're a fairly common feature of
devices and in terms of integration aren't particularly different to
sysclks, though this is for more complex CODECs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-13 15:51           ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 15:51 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, Richard Fitzgerald, robh+dt,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 485 bytes --]

On Wed, Jan 13, 2021 at 09:00:19AM +0900, Kuninori Morimoto wrote:

> Ahh, sorry for my unclear comment.
> I think "PLL settings" is very board/platform specific,
> so, adding such code to common driver will be issue in the future.
> This is the reason why I don't want add it to audio-graph-card.

I don't think it's *that* weird, they're a fairly common feature of
devices and in terms of integration aren't particularly different to
sysclks, though this is for more complex CODECs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks
@ 2021-01-13 15:51           ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 15:51 UTC (permalink / raw)
  To: Kuninori Morimoto
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli, patches,
	linux-kernel, Richard Fitzgerald, robh+dt,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 485 bytes --]

On Wed, Jan 13, 2021 at 09:00:19AM +0900, Kuninori Morimoto wrote:

> Ahh, sorry for my unclear comment.
> I think "PLL settings" is very board/platform specific,
> so, adding such code to common driver will be issue in the future.
> This is the reason why I don't want add it to audio-graph-card.

I don't think it's *that* weird, they're a fairly common feature of
devices and in terms of integration aren't particularly different to
sysclks, though this is for more complex CODECs.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-13 15:22     ` Rob Herring
  (?)
@ 2021-01-13 16:09       ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 16:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: Richard Fitzgerald, kuninori.morimoto.gx, nsaenzjulienne,
	f.fainelli, linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> I'm not sure this makes sense to be generic, but if so, we already have 
> the clock binding and should use (and possibly extend) that.

> This appears to all be configuration of clocks within the codec, so 
> these properties belong in the codec or cpu nodes.

Right, I think this should just be the clock binding. 

> > +      The PLL id and clock source id are specific to the particular component
> > +      so see the relevant component driver for the ids. Typically the

This should refer to the bindings for components, not to their drivers.

> > +      clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several plls
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  plls-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the plls property.
> > +
> > +  sysclks:
> > +    description: |
> > +      A list of component sysclk settings. There are 4 cells per sysclk
> > +      setting:
> > +        - phandle to the node of the codec or cpu component,
> > +        - component sysclk id,
> > +        - component clock source id,
> > +        - direction of the clock: 0 if the clock is an input to the component,
> > +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
> > +      The sysclk id and clock source id are specific to the particular
> > +      component so see the relevant component driver for the ids. Typically
> > +      the clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several sysclks
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  sysclks-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the sysclks property.
> > +
> > +dependencies:
> > +  plls: [ plls-clocks ]
> > +  sysclks: [ sysclks-clocks ]
> > +
> >  required:
> >    - dais
> >  
> > -- 
> > 2.20.1
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-13 16:09       ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 16:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, Richard Fitzgerald,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> I'm not sure this makes sense to be generic, but if so, we already have 
> the clock binding and should use (and possibly extend) that.

> This appears to all be configuration of clocks within the codec, so 
> these properties belong in the codec or cpu nodes.

Right, I think this should just be the clock binding. 

> > +      The PLL id and clock source id are specific to the particular component
> > +      so see the relevant component driver for the ids. Typically the

This should refer to the bindings for components, not to their drivers.

> > +      clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several plls
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  plls-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the plls property.
> > +
> > +  sysclks:
> > +    description: |
> > +      A list of component sysclk settings. There are 4 cells per sysclk
> > +      setting:
> > +        - phandle to the node of the codec or cpu component,
> > +        - component sysclk id,
> > +        - component clock source id,
> > +        - direction of the clock: 0 if the clock is an input to the component,
> > +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
> > +      The sysclk id and clock source id are specific to the particular
> > +      component so see the relevant component driver for the ids. Typically
> > +      the clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several sysclks
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  sysclks-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the sysclks property.
> > +
> > +dependencies:
> > +  plls: [ plls-clocks ]
> > +  sysclks: [ sysclks-clocks ]
> > +
> >  required:
> >    - dais
> >  
> > -- 
> > 2.20.1
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-13 16:09       ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-13 16:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, Richard Fitzgerald,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 2464 bytes --]

On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> I'm not sure this makes sense to be generic, but if so, we already have 
> the clock binding and should use (and possibly extend) that.

> This appears to all be configuration of clocks within the codec, so 
> these properties belong in the codec or cpu nodes.

Right, I think this should just be the clock binding. 

> > +      The PLL id and clock source id are specific to the particular component
> > +      so see the relevant component driver for the ids. Typically the

This should refer to the bindings for components, not to their drivers.

> > +      clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several plls
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  plls-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the plls property.
> > +
> > +  sysclks:
> > +    description: |
> > +      A list of component sysclk settings. There are 4 cells per sysclk
> > +      setting:
> > +        - phandle to the node of the codec or cpu component,
> > +        - component sysclk id,
> > +        - component clock source id,
> > +        - direction of the clock: 0 if the clock is an input to the component,
> > +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
> > +      The sysclk id and clock source id are specific to the particular
> > +      component so see the relevant component driver for the ids. Typically
> > +      the clock source id indicates the pin the source clock is connected to.
> > +      The same phandle can appear in multiple entries so that several sysclks
> > +      can be set in the same component.
> > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +  sysclks-clocks:
> > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > +    description: |
> > +      A list of clock names giving the source clock for each setting
> > +      in the sysclks property.
> > +
> > +dependencies:
> > +  plls: [ plls-clocks ]
> > +  sysclks: [ sysclks-clocks ]
> > +
> >  required:
> >    - dais
> >  
> > -- 
> > 2.20.1
> > 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-13 15:22     ` Rob Herring
  (?)
@ 2021-01-14 10:31       ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-14 10:31 UTC (permalink / raw)
  To: Rob Herring
  Cc: broonie, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel



On 13/01/2021 15:22, Rob Herring wrote:
> On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
>> The audio-graph-card driver has properties for configuring the clocking
>> for DAIs within a component, but is missing properties for setting
>> up the PLLs and sysclks of the component.
>>
>> This patch adds the two new properties 'plls' and 'sysclks' so that the
>> audio-graph-driver can fully configure the component clocking.
> 
> I'm not sure this makes sense to be generic, but if so, we already have
> the clock binding and should use (and possibly extend) that.
> 
> This appears to all be configuration of clocks within the codec, so
> these properties belong in the codec or cpu nodes.
>

audio-graph-card doesn't have codec or cpu nodes. Those were in
simple-card but are replaced in audio-graph-card by a simple phandle
array forming a graph.

I could assume that all clock settings apply to the codec and that there
is only ever one codec in an audio-graph-card configuration.

>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
>>   .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>>   1 file changed, 46 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> index 4b46794e5153..9e0819205a17 100644
>> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> @@ -39,6 +39,52 @@ properties:
>>     mic-det-gpio:
>>       maxItems: 1
>>   
>> +  plls:
>> +    description: |
>> +      A list of component pll settings. There are 4 cells per PLL setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component PLL id,
>> +        - component clock source id,
>> +        - frequency (in Hz) of the PLL output clock.
> 
> assigned-clocks binding can set frequencies and parent clocks.
> 
> 'pll' is too specific to the implementation. You may want to configure
> the freq and parent of something that's not a pll.
> 
>> +      The PLL id and clock source id are specific to the particular component
>> +      so see the relevant component driver for the ids. Typically the
>> +      clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several plls
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  plls-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the plls property.
>> +
>> +  sysclks:
>> +    description: |
>> +      A list of component sysclk settings. There are 4 cells per sysclk
>> +      setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component sysclk id,
>> +        - component clock source id,
>> +        - direction of the clock: 0 if the clock is an input to the component,
>> +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
>> +      The sysclk id and clock source id are specific to the particular
>> +      component so see the relevant component driver for the ids. Typically
>> +      the clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several sysclks
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  sysclks-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the sysclks property.
>> +
>> +dependencies:
>> +  plls: [ plls-clocks ]
>> +  sysclks: [ sysclks-clocks ]
>> +
>>   required:
>>     - dais
>>   
>> -- 
>> 2.20.1
>>

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-14 10:31       ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-14 10:31 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, broonie,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne



On 13/01/2021 15:22, Rob Herring wrote:
> On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
>> The audio-graph-card driver has properties for configuring the clocking
>> for DAIs within a component, but is missing properties for setting
>> up the PLLs and sysclks of the component.
>>
>> This patch adds the two new properties 'plls' and 'sysclks' so that the
>> audio-graph-driver can fully configure the component clocking.
> 
> I'm not sure this makes sense to be generic, but if so, we already have
> the clock binding and should use (and possibly extend) that.
> 
> This appears to all be configuration of clocks within the codec, so
> these properties belong in the codec or cpu nodes.
>

audio-graph-card doesn't have codec or cpu nodes. Those were in
simple-card but are replaced in audio-graph-card by a simple phandle
array forming a graph.

I could assume that all clock settings apply to the codec and that there
is only ever one codec in an audio-graph-card configuration.

>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
>>   .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>>   1 file changed, 46 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> index 4b46794e5153..9e0819205a17 100644
>> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> @@ -39,6 +39,52 @@ properties:
>>     mic-det-gpio:
>>       maxItems: 1
>>   
>> +  plls:
>> +    description: |
>> +      A list of component pll settings. There are 4 cells per PLL setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component PLL id,
>> +        - component clock source id,
>> +        - frequency (in Hz) of the PLL output clock.
> 
> assigned-clocks binding can set frequencies and parent clocks.
> 
> 'pll' is too specific to the implementation. You may want to configure
> the freq and parent of something that's not a pll.
> 
>> +      The PLL id and clock source id are specific to the particular component
>> +      so see the relevant component driver for the ids. Typically the
>> +      clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several plls
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  plls-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the plls property.
>> +
>> +  sysclks:
>> +    description: |
>> +      A list of component sysclk settings. There are 4 cells per sysclk
>> +      setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component sysclk id,
>> +        - component clock source id,
>> +        - direction of the clock: 0 if the clock is an input to the component,
>> +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
>> +      The sysclk id and clock source id are specific to the particular
>> +      component so see the relevant component driver for the ids. Typically
>> +      the clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several sysclks
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  sysclks-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the sysclks property.
>> +
>> +dependencies:
>> +  plls: [ plls-clocks ]
>> +  sysclks: [ sysclks-clocks ]
>> +
>>   required:
>>     - dais
>>   
>> -- 
>> 2.20.1
>>

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-14 10:31       ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-14 10:31 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel, broonie,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne



On 13/01/2021 15:22, Rob Herring wrote:
> On Fri, Jan 08, 2021 at 04:04:57PM +0000, Richard Fitzgerald wrote:
>> The audio-graph-card driver has properties for configuring the clocking
>> for DAIs within a component, but is missing properties for setting
>> up the PLLs and sysclks of the component.
>>
>> This patch adds the two new properties 'plls' and 'sysclks' so that the
>> audio-graph-driver can fully configure the component clocking.
> 
> I'm not sure this makes sense to be generic, but if so, we already have
> the clock binding and should use (and possibly extend) that.
> 
> This appears to all be configuration of clocks within the codec, so
> these properties belong in the codec or cpu nodes.
>

audio-graph-card doesn't have codec or cpu nodes. Those were in
simple-card but are replaced in audio-graph-card by a simple phandle
array forming a graph.

I could assume that all clock settings apply to the codec and that there
is only ever one codec in an audio-graph-card configuration.

>> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
>> ---
>>   .../bindings/sound/audio-graph.yaml           | 46 +++++++++++++++++++
>>   1 file changed, 46 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/audio-graph.yaml b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> index 4b46794e5153..9e0819205a17 100644
>> --- a/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> +++ b/Documentation/devicetree/bindings/sound/audio-graph.yaml
>> @@ -39,6 +39,52 @@ properties:
>>     mic-det-gpio:
>>       maxItems: 1
>>   
>> +  plls:
>> +    description: |
>> +      A list of component pll settings. There are 4 cells per PLL setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component PLL id,
>> +        - component clock source id,
>> +        - frequency (in Hz) of the PLL output clock.
> 
> assigned-clocks binding can set frequencies and parent clocks.
> 
> 'pll' is too specific to the implementation. You may want to configure
> the freq and parent of something that's not a pll.
> 
>> +      The PLL id and clock source id are specific to the particular component
>> +      so see the relevant component driver for the ids. Typically the
>> +      clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several plls
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  plls-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the plls property.
>> +
>> +  sysclks:
>> +    description: |
>> +      A list of component sysclk settings. There are 4 cells per sysclk
>> +      setting:
>> +        - phandle to the node of the codec or cpu component,
>> +        - component sysclk id,
>> +        - component clock source id,
>> +        - direction of the clock: 0 if the clock is an input to the component,
>> +          1 if it is an output.
> 
> A clock provider and consumer would provide the direction.
> 
>> +      The sysclk id and clock source id are specific to the particular
>> +      component so see the relevant component driver for the ids. Typically
>> +      the clock source id indicates the pin the source clock is connected to.
>> +      The same phandle can appear in multiple entries so that several sysclks
>> +      can be set in the same component.
>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>> +
>> +  sysclks-clocks:
>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>> +    description: |
>> +      A list of clock names giving the source clock for each setting
>> +      in the sysclks property.
>> +
>> +dependencies:
>> +  plls: [ plls-clocks ]
>> +  sysclks: [ sysclks-clocks ]
>> +
>>   required:
>>     - dais
>>   
>> -- 
>> 2.20.1
>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-14 10:31       ` Richard Fitzgerald
  (?)
@ 2021-01-14 11:14         ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-14 11:14 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Thu, Jan 14, 2021 at 10:31:10AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 15:22, Rob Herring wrote:

> > This appears to all be configuration of clocks within the codec, so
> > these properties belong in the codec or cpu nodes.

> audio-graph-card doesn't have codec or cpu nodes. Those were in
> simple-card but are replaced in audio-graph-card by a simple phandle
> array forming a graph.

> I could assume that all clock settings apply to the codec and that there
> is only ever one codec in an audio-graph-card configuration.

The suggestion here is to put properties in the node for the relevant
device rather than the card.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-14 11:14         ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-14 11:14 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Thu, Jan 14, 2021 at 10:31:10AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 15:22, Rob Herring wrote:

> > This appears to all be configuration of clocks within the codec, so
> > these properties belong in the codec or cpu nodes.

> audio-graph-card doesn't have codec or cpu nodes. Those were in
> simple-card but are replaced in audio-graph-card by a simple phandle
> array forming a graph.

> I could assume that all clock settings apply to the codec and that there
> is only ever one codec in an audio-graph-card configuration.

The suggestion here is to put properties in the node for the relevant
device rather than the card.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-14 11:14         ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-14 11:14 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 640 bytes --]

On Thu, Jan 14, 2021 at 10:31:10AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 15:22, Rob Herring wrote:

> > This appears to all be configuration of clocks within the codec, so
> > these properties belong in the codec or cpu nodes.

> audio-graph-card doesn't have codec or cpu nodes. Those were in
> simple-card but are replaced in audio-graph-card by a simple phandle
> array forming a graph.

> I could assume that all clock settings apply to the codec and that there
> is only ever one codec in an audio-graph-card configuration.

The suggestion here is to put properties in the node for the relevant
device rather than the card.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-14 11:14         ` Mark Brown
  (?)
  (?)
@ 2021-01-14 12:31         ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-14 12:31 UTC (permalink / raw)
  To: alsa-devel

On 14/01/2021 11:14, Mark Brown wrote:
> On Thu, Jan 14, 2021 at 10:31:10AM +0000, Richard Fitzgerald wrote:
>> On 13/01/2021 15:22, Rob Herring wrote:
> 
>>> This appears to all be configuration of clocks within the codec, so
>>> these properties belong in the codec or cpu nodes.
> 
>> audio-graph-card doesn't have codec or cpu nodes. Those were in
>> simple-card but are replaced in audio-graph-card by a simple phandle
>> array forming a graph.
> 
>> I could assume that all clock settings apply to the codec and that there
>> is only ever one codec in an audio-graph-card configuration.
> 
> The suggestion here is to put properties in the node for the relevant
> device rather than the card.
> 

That's seems bad to me - putting the properties for one driver in the
node of another driver. It's also potentially misleading as an example.
As in something like:

   wm5102: wm5102 {
	compatible = "wlf,wm5102";

	sysclks = <&some_clock>;
	plls = <&some_other_clock>;

	...
   };

To me that seems to imply that these are properties of the wm5102 driver
and it is going to setup its own sysclk and pll settings from those
properties. But actually it's the machine driver that does it, and these
properties are specific to audio-graph-card.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-13 16:09       ` Mark Brown
  (?)
@ 2021-01-15 10:35         ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 10:35 UTC (permalink / raw)
  To: Mark Brown, Rob Herring
  Cc: kuninori.morimoto.gx, nsaenzjulienne, f.fainelli, linux-kernel,
	devicetree, alsa-devel, patches, bcm-kernel-feedback-list,
	linux-rpi-kernel, linux-arm-kernel

On 13/01/2021 16:09, Mark Brown wrote:
> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> I'm not sure this makes sense to be generic, but if so, we already have
>> the clock binding and should use (and possibly extend) that.
> 
>> This appears to all be configuration of clocks within the codec, so
>> these properties belong in the codec or cpu nodes.
> 
> Right, I think this should just be the clock binding.
> 

Ok, so if the idea is to do this:

sound {
	clocks = <&audio_mclk>, <&pll>;
	clock-names = "mclk", "pll";
}

some_codec {
	pll: pll {
		compatible = "fixed-clock";
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
	}
};

For this to work the clock binding must be a real clock object (so needs
a valid compatible=). But I need to somehow specify the PLL ID and
source pin for the PLL configuration. The schema for "fixed-clock" has
"additionalProperties: false" so I can't add extra custom properties to
the clock node.

Of course if we were able to use the clock framework to provide real
clock drivers for the plls and sysclks, the ID would be inherent in
the binding, and it can define a custom property for the source pin.

Some options:

1) Remove "additionalProperties: false" from the "fixed-clock" binding.

2) Add new core clock properties. Well, source-pin might legitimately be
meaningful, but for a real clock provider the clock ID is implicit.

3) Use 'reg' as fixed-clock doesn't use it. This works, but I suspect it
will be seen as an abuse of reg.

4) Put some extra properties in the sound node to define the <id,source>
pair for each clock. But that's clumsy to have some of the config in a
clock binding and a couple of extra elsewhere.

5) Use a bare clock binding that isn't a real clock provider, like:

sound {
	plls = <&pll>;
}

some_codec {
	pll: pll {
		reg = <1>; /* PLL ID */
	 	audio-graph-card,source-pin = <4>;
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
		
	}
};


>>> +      The PLL id and clock source id are specific to the particular component
>>> +      so see the relevant component driver for the ids. Typically the
> 
> This should refer to the bindings for components, not to their drivers.
> 
>>> +      clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several plls
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  plls-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the plls property.
>>> +
>>> +  sysclks:
>>> +    description: |
>>> +      A list of component sysclk settings. There are 4 cells per sysclk
>>> +      setting:
>>> +        - phandle to the node of the codec or cpu component,
>>> +        - component sysclk id,
>>> +        - component clock source id,
>>> +        - direction of the clock: 0 if the clock is an input to the component,
>>> +          1 if it is an output.
>>
>> A clock provider and consumer would provide the direction.
>>
>>> +      The sysclk id and clock source id are specific to the particular
>>> +      component so see the relevant component driver for the ids. Typically
>>> +      the clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several sysclks
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  sysclks-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the sysclks property.
>>> +
>>> +dependencies:
>>> +  plls: [ plls-clocks ]
>>> +  sysclks: [ sysclks-clocks ]
>>> +
>>>   required:
>>>     - dais
>>>   
>>> -- 
>>> 2.20.1
>>>

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 10:35         ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 10:35 UTC (permalink / raw)
  To: Mark Brown, Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On 13/01/2021 16:09, Mark Brown wrote:
> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> I'm not sure this makes sense to be generic, but if so, we already have
>> the clock binding and should use (and possibly extend) that.
> 
>> This appears to all be configuration of clocks within the codec, so
>> these properties belong in the codec or cpu nodes.
> 
> Right, I think this should just be the clock binding.
> 

Ok, so if the idea is to do this:

sound {
	clocks = <&audio_mclk>, <&pll>;
	clock-names = "mclk", "pll";
}

some_codec {
	pll: pll {
		compatible = "fixed-clock";
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
	}
};

For this to work the clock binding must be a real clock object (so needs
a valid compatible=). But I need to somehow specify the PLL ID and
source pin for the PLL configuration. The schema for "fixed-clock" has
"additionalProperties: false" so I can't add extra custom properties to
the clock node.

Of course if we were able to use the clock framework to provide real
clock drivers for the plls and sysclks, the ID would be inherent in
the binding, and it can define a custom property for the source pin.

Some options:

1) Remove "additionalProperties: false" from the "fixed-clock" binding.

2) Add new core clock properties. Well, source-pin might legitimately be
meaningful, but for a real clock provider the clock ID is implicit.

3) Use 'reg' as fixed-clock doesn't use it. This works, but I suspect it
will be seen as an abuse of reg.

4) Put some extra properties in the sound node to define the <id,source>
pair for each clock. But that's clumsy to have some of the config in a
clock binding and a couple of extra elsewhere.

5) Use a bare clock binding that isn't a real clock provider, like:

sound {
	plls = <&pll>;
}

some_codec {
	pll: pll {
		reg = <1>; /* PLL ID */
	 	audio-graph-card,source-pin = <4>;
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
		
	}
};


>>> +      The PLL id and clock source id are specific to the particular component
>>> +      so see the relevant component driver for the ids. Typically the
> 
> This should refer to the bindings for components, not to their drivers.
> 
>>> +      clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several plls
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  plls-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the plls property.
>>> +
>>> +  sysclks:
>>> +    description: |
>>> +      A list of component sysclk settings. There are 4 cells per sysclk
>>> +      setting:
>>> +        - phandle to the node of the codec or cpu component,
>>> +        - component sysclk id,
>>> +        - component clock source id,
>>> +        - direction of the clock: 0 if the clock is an input to the component,
>>> +          1 if it is an output.
>>
>> A clock provider and consumer would provide the direction.
>>
>>> +      The sysclk id and clock source id are specific to the particular
>>> +      component so see the relevant component driver for the ids. Typically
>>> +      the clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several sysclks
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  sysclks-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the sysclks property.
>>> +
>>> +dependencies:
>>> +  plls: [ plls-clocks ]
>>> +  sysclks: [ sysclks-clocks ]
>>> +
>>>   required:
>>>     - dais
>>>   
>>> -- 
>>> 2.20.1
>>>

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 10:35         ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 10:35 UTC (permalink / raw)
  To: Mark Brown, Rob Herring
  Cc: linux-arm-kernel, devicetree, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On 13/01/2021 16:09, Mark Brown wrote:
> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> I'm not sure this makes sense to be generic, but if so, we already have
>> the clock binding and should use (and possibly extend) that.
> 
>> This appears to all be configuration of clocks within the codec, so
>> these properties belong in the codec or cpu nodes.
> 
> Right, I think this should just be the clock binding.
> 

Ok, so if the idea is to do this:

sound {
	clocks = <&audio_mclk>, <&pll>;
	clock-names = "mclk", "pll";
}

some_codec {
	pll: pll {
		compatible = "fixed-clock";
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
	}
};

For this to work the clock binding must be a real clock object (so needs
a valid compatible=). But I need to somehow specify the PLL ID and
source pin for the PLL configuration. The schema for "fixed-clock" has
"additionalProperties: false" so I can't add extra custom properties to
the clock node.

Of course if we were able to use the clock framework to provide real
clock drivers for the plls and sysclks, the ID would be inherent in
the binding, and it can define a custom property for the source pin.

Some options:

1) Remove "additionalProperties: false" from the "fixed-clock" binding.

2) Add new core clock properties. Well, source-pin might legitimately be
meaningful, but for a real clock provider the clock ID is implicit.

3) Use 'reg' as fixed-clock doesn't use it. This works, but I suspect it
will be seen as an abuse of reg.

4) Put some extra properties in the sound node to define the <id,source>
pair for each clock. But that's clumsy to have some of the config in a
clock binding and a couple of extra elsewhere.

5) Use a bare clock binding that isn't a real clock provider, like:

sound {
	plls = <&pll>;
}

some_codec {
	pll: pll {
		reg = <1>; /* PLL ID */
	 	audio-graph-card,source-pin = <4>;
		clocks = <&audio_mclk>;
		clock-frequency = <98304000>;
		
	}
};


>>> +      The PLL id and clock source id are specific to the particular component
>>> +      so see the relevant component driver for the ids. Typically the
> 
> This should refer to the bindings for components, not to their drivers.
> 
>>> +      clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several plls
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  plls-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the plls property.
>>> +
>>> +  sysclks:
>>> +    description: |
>>> +      A list of component sysclk settings. There are 4 cells per sysclk
>>> +      setting:
>>> +        - phandle to the node of the codec or cpu component,
>>> +        - component sysclk id,
>>> +        - component clock source id,
>>> +        - direction of the clock: 0 if the clock is an input to the component,
>>> +          1 if it is an output.
>>
>> A clock provider and consumer would provide the direction.
>>
>>> +      The sysclk id and clock source id are specific to the particular
>>> +      component so see the relevant component driver for the ids. Typically
>>> +      the clock source id indicates the pin the source clock is connected to.
>>> +      The same phandle can appear in multiple entries so that several sysclks
>>> +      can be set in the same component.
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  sysclks-clocks:
>>> +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
>>> +    description: |
>>> +      A list of clock names giving the source clock for each setting
>>> +      in the sysclks property.
>>> +
>>> +dependencies:
>>> +  plls: [ plls-clocks ]
>>> +  sysclks: [ sysclks-clocks ]
>>> +
>>>   required:
>>>     - dais
>>>   
>>> -- 
>>> 2.20.1
>>>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-15 10:35         ` Richard Fitzgerald
  (?)
@ 2021-01-15 13:11           ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 13:11 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 16:09, Mark Brown wrote:
> > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> some_codec {
> 	pll: pll {
> 		compatible = "fixed-clock";
> 		clocks = <&audio_mclk>;
> 		clock-frequency = <98304000>;
> 	}

A PLL is not a fixed clock, why would you define a fixed clock here?
Are you confusing the selection of rates on existing clocks with the use
of the assigned-* properties that the clock binding provides?

> For this to work the clock binding must be a real clock object (so needs
> a valid compatible=). But I need to somehow specify the PLL ID and

That seems like a *very* surprising requirement - why would the clock
binding have that requirement?  It would seem to create issues for a
single device providing multiple clocks which should be a pretty common
coase.

> > > > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > > > +    description: |
> > > > +      A list of clock names giving the source clock for each setting
> > > > +      in the sysclks property.
> > > > +


Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 13:11           ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 13:11 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 16:09, Mark Brown wrote:
> > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> some_codec {
> 	pll: pll {
> 		compatible = "fixed-clock";
> 		clocks = <&audio_mclk>;
> 		clock-frequency = <98304000>;
> 	}

A PLL is not a fixed clock, why would you define a fixed clock here?
Are you confusing the selection of rates on existing clocks with the use
of the assigned-* properties that the clock binding provides?

> For this to work the clock binding must be a real clock object (so needs
> a valid compatible=). But I need to somehow specify the PLL ID and

That seems like a *very* surprising requirement - why would the clock
binding have that requirement?  It would seem to create issues for a
single device providing multiple clocks which should be a pretty common
coase.

> > > > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > > > +    description: |
> > > > +      A list of clock names giving the source clock for each setting
> > > > +      in the sysclks property.
> > > > +


Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 13:11           ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 13:11 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 1326 bytes --]

On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> On 13/01/2021 16:09, Mark Brown wrote:
> > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> some_codec {
> 	pll: pll {
> 		compatible = "fixed-clock";
> 		clocks = <&audio_mclk>;
> 		clock-frequency = <98304000>;
> 	}

A PLL is not a fixed clock, why would you define a fixed clock here?
Are you confusing the selection of rates on existing clocks with the use
of the assigned-* properties that the clock binding provides?

> For this to work the clock binding must be a real clock object (so needs
> a valid compatible=). But I need to somehow specify the PLL ID and

That seems like a *very* surprising requirement - why would the clock
binding have that requirement?  It would seem to create issues for a
single device providing multiple clocks which should be a pretty common
coase.

> > > > +    $ref: /schemas/types.yaml#/definitions/non-unique-string-array
> > > > +    description: |
> > > > +      A list of clock names giving the source clock for each setting
> > > > +      in the sysclks property.
> > > > +


Please delete unneeded context from mails when replying.  Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-15 13:11           ` Mark Brown
  (?)
@ 2021-01-15 14:42             ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 14:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

On 15/01/2021 13:11, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>> On 13/01/2021 16:09, Mark Brown wrote:
>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> some_codec {
>> 	pll: pll {
>> 		compatible = "fixed-clock";
>> 		clocks = <&audio_mclk>;
>> 		clock-frequency = <98304000>;
>> 	}
> 
> A PLL is not a fixed clock, why would you define a fixed clock here?

It's a fixed clock if you are only setting one configuration. Call it
compatible="any-other-dummy-clock-type" if you like, it doesn't matter
what it is for the purposes of what I was describing.

This isn't a clk driver for a pll, it's just a setting to be passed to
snd_soc_component_set_pll() using a clock binding to specify it.

> Are you confusing the selection of rates on existing clocks with the use
> of the assigned-* properties that the clock binding provides?
> 

I'm not at all sure what you and Rob have in mind here. Perhaps you
could give an example of what you are thinking the .dts would look like
to define some pll/sysclk settings for audio-graph-card to apply. An
example is worth a thousand emails.

>> For this to work the clock binding must be a real clock object (so needs
>> a valid compatible=). But I need to somehow specify the PLL ID and
> 
> That seems like a *very* surprising requirement - why would the clock
> binding have that requirement?  It would seem to create issues for a
> single device providing multiple clocks which should be a pretty common
> coase.
> 

You misunderstand me. What I'm saying is that to do this:

	sound {
		clocks = <&pll>;
	}

The node 'pll' must correspond to a clock provider driver. It can't be
just a bare node with some properties pick-n-mixed from the clock
binding, like this:

	pll1 : pll1 {
		clock-frequency = <98304000>;
	};

which doesn't define a compatible= to match it to a clk driver. An
attempt to bulk_get the machine driver clocks here will fail.

To use a bare node with pick-n-mixed useful clock binding properties,
that doesn't represent a real clk provider driver, it would have to be
pointed to by a custom property that is not treated as a clk framework
object, e.g.:

	sound {
		audio-graph-card,plls = <&pll>;
	}

In this case pll is a node parsed by audio-graph-card that just happens
to use properties from the clock binding.

So the question I'm trying to ask is: when you and Rob said use
the clock binding, did you mean pointing to that binding from
clocks=<...>, or from a custom property like my audio-graph-card,plls
example above.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 14:42             ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 14:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On 15/01/2021 13:11, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>> On 13/01/2021 16:09, Mark Brown wrote:
>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> some_codec {
>> 	pll: pll {
>> 		compatible = "fixed-clock";
>> 		clocks = <&audio_mclk>;
>> 		clock-frequency = <98304000>;
>> 	}
> 
> A PLL is not a fixed clock, why would you define a fixed clock here?

It's a fixed clock if you are only setting one configuration. Call it
compatible="any-other-dummy-clock-type" if you like, it doesn't matter
what it is for the purposes of what I was describing.

This isn't a clk driver for a pll, it's just a setting to be passed to
snd_soc_component_set_pll() using a clock binding to specify it.

> Are you confusing the selection of rates on existing clocks with the use
> of the assigned-* properties that the clock binding provides?
> 

I'm not at all sure what you and Rob have in mind here. Perhaps you
could give an example of what you are thinking the .dts would look like
to define some pll/sysclk settings for audio-graph-card to apply. An
example is worth a thousand emails.

>> For this to work the clock binding must be a real clock object (so needs
>> a valid compatible=). But I need to somehow specify the PLL ID and
> 
> That seems like a *very* surprising requirement - why would the clock
> binding have that requirement?  It would seem to create issues for a
> single device providing multiple clocks which should be a pretty common
> coase.
> 

You misunderstand me. What I'm saying is that to do this:

	sound {
		clocks = <&pll>;
	}

The node 'pll' must correspond to a clock provider driver. It can't be
just a bare node with some properties pick-n-mixed from the clock
binding, like this:

	pll1 : pll1 {
		clock-frequency = <98304000>;
	};

which doesn't define a compatible= to match it to a clk driver. An
attempt to bulk_get the machine driver clocks here will fail.

To use a bare node with pick-n-mixed useful clock binding properties,
that doesn't represent a real clk provider driver, it would have to be
pointed to by a custom property that is not treated as a clk framework
object, e.g.:

	sound {
		audio-graph-card,plls = <&pll>;
	}

In this case pll is a node parsed by audio-graph-card that just happens
to use properties from the clock binding.

So the question I'm trying to ask is: when you and Rob said use
the clock binding, did you mean pointing to that binding from
clocks=<...>, or from a custom property like my audio-graph-card,plls
example above.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 14:42             ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 14:42 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne

On 15/01/2021 13:11, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>> On 13/01/2021 16:09, Mark Brown wrote:
>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>> some_codec {
>> 	pll: pll {
>> 		compatible = "fixed-clock";
>> 		clocks = <&audio_mclk>;
>> 		clock-frequency = <98304000>;
>> 	}
> 
> A PLL is not a fixed clock, why would you define a fixed clock here?

It's a fixed clock if you are only setting one configuration. Call it
compatible="any-other-dummy-clock-type" if you like, it doesn't matter
what it is for the purposes of what I was describing.

This isn't a clk driver for a pll, it's just a setting to be passed to
snd_soc_component_set_pll() using a clock binding to specify it.

> Are you confusing the selection of rates on existing clocks with the use
> of the assigned-* properties that the clock binding provides?
> 

I'm not at all sure what you and Rob have in mind here. Perhaps you
could give an example of what you are thinking the .dts would look like
to define some pll/sysclk settings for audio-graph-card to apply. An
example is worth a thousand emails.

>> For this to work the clock binding must be a real clock object (so needs
>> a valid compatible=). But I need to somehow specify the PLL ID and
> 
> That seems like a *very* surprising requirement - why would the clock
> binding have that requirement?  It would seem to create issues for a
> single device providing multiple clocks which should be a pretty common
> coase.
> 

You misunderstand me. What I'm saying is that to do this:

	sound {
		clocks = <&pll>;
	}

The node 'pll' must correspond to a clock provider driver. It can't be
just a bare node with some properties pick-n-mixed from the clock
binding, like this:

	pll1 : pll1 {
		clock-frequency = <98304000>;
	};

which doesn't define a compatible= to match it to a clk driver. An
attempt to bulk_get the machine driver clocks here will fail.

To use a bare node with pick-n-mixed useful clock binding properties,
that doesn't represent a real clk provider driver, it would have to be
pointed to by a custom property that is not treated as a clk framework
object, e.g.:

	sound {
		audio-graph-card,plls = <&pll>;
	}

In this case pll is a node parsed by audio-graph-card that just happens
to use properties from the clock binding.

So the question I'm trying to ask is: when you and Rob said use
the clock binding, did you mean pointing to that binding from
clocks=<...>, or from a custom property like my audio-graph-card,plls
example above.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-15 14:42             ` Richard Fitzgerald
  (?)
@ 2021-01-15 15:20               ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 15:20 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
> On 15/01/2021 13:11, Mark Brown wrote:
> > On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> > > On 13/01/2021 16:09, Mark Brown wrote:
> > > > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> > > some_codec {
> > > 	pll: pll {
> > > 		compatible = "fixed-clock";
> > > 		clocks = <&audio_mclk>;
> > > 		clock-frequency = <98304000>;
> > > 	}

> > A PLL is not a fixed clock, why would you define a fixed clock here?

> It's a fixed clock if you are only setting one configuration. Call it
> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
> what it is for the purposes of what I was describing.

> This isn't a clk driver for a pll, it's just a setting to be passed to
> snd_soc_component_set_pll() using a clock binding to specify it.

So you're trying to describe a crystal on the board?  Why would this be
a subnode of the CODEC then?  Surely it's just a standard fixed clock
which provides some input to the CODEC in the same way you'd describe
any other input to the CODEC.  The above doesn't look anything like the
hardware.  But if that's what you're doing how is that related to
configuring the FLL except possibly as the input clock you'd reference?

> > Are you confusing the selection of rates on existing clocks with the use
> > of the assigned-* properties that the clock binding provides?

> I'm not at all sure what you and Rob have in mind here. Perhaps you
> could give an example of what you are thinking the .dts would look like
> to define some pll/sysclk settings for audio-graph-card to apply. An
> example is worth a thousand emails.

As far as I can tell you are trying to configure the FLL in the CODEC,
telling it to take an input clock and produce a fixed output clock rate
from that.  The FLL is a fairly basic clock, there are examples for both
that and choosing a configuration for a clock in the clock bindings.  

> > That seems like a *very* surprising requirement - why would the clock
> > binding have that requirement?  It would seem to create issues for a
> > single device providing multiple clocks which should be a pretty common
> > coase.

> You misunderstand me. What I'm saying is that to do this:

> 	sound {
> 		clocks = <&pll>;
> 	}

> The node 'pll' must correspond to a clock provider driver. It can't be
> just a bare node with some properties pick-n-mixed from the clock
> binding, like this:

I'm pretty sure I understand you perfectly; again, what makes you say
that a description of a clock in the device tree has any requirement
for a separate compatible string?

> So the question I'm trying to ask is: when you and Rob said use
> the clock binding, did you mean pointing to that binding from
> clocks=<...>, or from a custom property like my audio-graph-card,plls
> example above.

When we say to use the clock binding what we are saying is to use the
actual clock bindings to describe the clocks, not make a custom binding
that looks kind of like them - making a custom binding doesn't address
the problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 15:20               ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 15:20 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
> On 15/01/2021 13:11, Mark Brown wrote:
> > On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> > > On 13/01/2021 16:09, Mark Brown wrote:
> > > > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> > > some_codec {
> > > 	pll: pll {
> > > 		compatible = "fixed-clock";
> > > 		clocks = <&audio_mclk>;
> > > 		clock-frequency = <98304000>;
> > > 	}

> > A PLL is not a fixed clock, why would you define a fixed clock here?

> It's a fixed clock if you are only setting one configuration. Call it
> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
> what it is for the purposes of what I was describing.

> This isn't a clk driver for a pll, it's just a setting to be passed to
> snd_soc_component_set_pll() using a clock binding to specify it.

So you're trying to describe a crystal on the board?  Why would this be
a subnode of the CODEC then?  Surely it's just a standard fixed clock
which provides some input to the CODEC in the same way you'd describe
any other input to the CODEC.  The above doesn't look anything like the
hardware.  But if that's what you're doing how is that related to
configuring the FLL except possibly as the input clock you'd reference?

> > Are you confusing the selection of rates on existing clocks with the use
> > of the assigned-* properties that the clock binding provides?

> I'm not at all sure what you and Rob have in mind here. Perhaps you
> could give an example of what you are thinking the .dts would look like
> to define some pll/sysclk settings for audio-graph-card to apply. An
> example is worth a thousand emails.

As far as I can tell you are trying to configure the FLL in the CODEC,
telling it to take an input clock and produce a fixed output clock rate
from that.  The FLL is a fairly basic clock, there are examples for both
that and choosing a configuration for a clock in the clock bindings.  

> > That seems like a *very* surprising requirement - why would the clock
> > binding have that requirement?  It would seem to create issues for a
> > single device providing multiple clocks which should be a pretty common
> > coase.

> You misunderstand me. What I'm saying is that to do this:

> 	sound {
> 		clocks = <&pll>;
> 	}

> The node 'pll' must correspond to a clock provider driver. It can't be
> just a bare node with some properties pick-n-mixed from the clock
> binding, like this:

I'm pretty sure I understand you perfectly; again, what makes you say
that a description of a clock in the device tree has any requirement
for a separate compatible string?

> So the question I'm trying to ask is: when you and Rob said use
> the clock binding, did you mean pointing to that binding from
> clocks=<...>, or from a custom property like my audio-graph-card,plls
> example above.

When we say to use the clock binding what we are saying is to use the
actual clock bindings to describe the clocks, not make a custom binding
that looks kind of like them - making a custom binding doesn't address
the problem.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 15:20               ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 15:20 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 3163 bytes --]

On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
> On 15/01/2021 13:11, Mark Brown wrote:
> > On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
> > > On 13/01/2021 16:09, Mark Brown wrote:
> > > > On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:

> > > some_codec {
> > > 	pll: pll {
> > > 		compatible = "fixed-clock";
> > > 		clocks = <&audio_mclk>;
> > > 		clock-frequency = <98304000>;
> > > 	}

> > A PLL is not a fixed clock, why would you define a fixed clock here?

> It's a fixed clock if you are only setting one configuration. Call it
> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
> what it is for the purposes of what I was describing.

> This isn't a clk driver for a pll, it's just a setting to be passed to
> snd_soc_component_set_pll() using a clock binding to specify it.

So you're trying to describe a crystal on the board?  Why would this be
a subnode of the CODEC then?  Surely it's just a standard fixed clock
which provides some input to the CODEC in the same way you'd describe
any other input to the CODEC.  The above doesn't look anything like the
hardware.  But if that's what you're doing how is that related to
configuring the FLL except possibly as the input clock you'd reference?

> > Are you confusing the selection of rates on existing clocks with the use
> > of the assigned-* properties that the clock binding provides?

> I'm not at all sure what you and Rob have in mind here. Perhaps you
> could give an example of what you are thinking the .dts would look like
> to define some pll/sysclk settings for audio-graph-card to apply. An
> example is worth a thousand emails.

As far as I can tell you are trying to configure the FLL in the CODEC,
telling it to take an input clock and produce a fixed output clock rate
from that.  The FLL is a fairly basic clock, there are examples for both
that and choosing a configuration for a clock in the clock bindings.  

> > That seems like a *very* surprising requirement - why would the clock
> > binding have that requirement?  It would seem to create issues for a
> > single device providing multiple clocks which should be a pretty common
> > coase.

> You misunderstand me. What I'm saying is that to do this:

> 	sound {
> 		clocks = <&pll>;
> 	}

> The node 'pll' must correspond to a clock provider driver. It can't be
> just a bare node with some properties pick-n-mixed from the clock
> binding, like this:

I'm pretty sure I understand you perfectly; again, what makes you say
that a description of a clock in the device tree has any requirement
for a separate compatible string?

> So the question I'm trying to ask is: when you and Rob said use
> the clock binding, did you mean pointing to that binding from
> clocks=<...>, or from a custom property like my audio-graph-card,plls
> example above.

When we say to use the clock binding what we are saying is to use the
actual clock bindings to describe the clocks, not make a custom binding
that looks kind of like them - making a custom binding doesn't address
the problem.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-15 15:20               ` Mark Brown
  (?)
@ 2021-01-15 16:15                 ` Richard Fitzgerald
  -1 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 16:15 UTC (permalink / raw)
  To: Mark Brown
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

On 15/01/2021 15:20, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
>> On 15/01/2021 13:11, Mark Brown wrote:
>>> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>>>> On 13/01/2021 16:09, Mark Brown wrote:
>>>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>>>> some_codec {
>>>> 	pll: pll {
>>>> 		compatible = "fixed-clock";
>>>> 		clocks = <&audio_mclk>;
>>>> 		clock-frequency = <98304000>;
>>>> 	}
> 
>>> A PLL is not a fixed clock, why would you define a fixed clock here?
> 
>> It's a fixed clock if you are only setting one configuration. Call it
>> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
>> what it is for the purposes of what I was describing.
> 
>> This isn't a clk driver for a pll, it's just a setting to be passed to
>> snd_soc_component_set_pll() using a clock binding to specify it.
> 
> So you're trying to describe a crystal on the board?  Why would this be
> a subnode of the CODEC then?  Surely it's just a standard fixed clock
> which provides some input to the CODEC in the same way you'd describe
> any other input to the CODEC.  The above doesn't look anything like the
> hardware.  But if that's what you're doing how is that related to
> configuring the FLL except possibly as the input clock you'd reference?
> 
>>> Are you confusing the selection of rates on existing clocks with the use
>>> of the assigned-* properties that the clock binding provides?
> 
>> I'm not at all sure what you and Rob have in mind here. Perhaps you
>> could give an example of what you are thinking the .dts would look like
>> to define some pll/sysclk settings for audio-graph-card to apply. An
>> example is worth a thousand emails.
> 
> As far as I can tell you are trying to configure the FLL in the CODEC,
> telling it to take an input clock and produce a fixed output clock rate
> from that.  The FLL is a fairly basic clock, there are examples for both
> that and choosing a configuration for a clock in the clock bindings.
> 
>>> That seems like a *very* surprising requirement - why would the clock
>>> binding have that requirement?  It would seem to create issues for a
>>> single device providing multiple clocks which should be a pretty common
>>> coase.
> 
>> You misunderstand me. What I'm saying is that to do this:
> 
>> 	sound {
>> 		clocks = <&pll>;
>> 	}
> 
>> The node 'pll' must correspond to a clock provider driver. It can't be
>> just a bare node with some properties pick-n-mixed from the clock
>> binding, like this:
> 
> I'm pretty sure I understand you perfectly; again, what makes you say
> that a description of a clock in the device tree has any requirement
> for a separate compatible string?
> 

If I do:
  	sound {
  		clocks = <&clock>;
  	};

	clock: clock {
		compatible = "fixed-clock";
		clock-frequency = <98304000>;
	};

I can clk_bulk_get_all().
But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
will return -EPROBE_DEFER and log:

  /sound: Failed to get clk index: 0 ret: -517

from the error case in _clk_bulk_get() in clk/clk-bulk.c.

>> So the question I'm trying to ask is: when you and Rob said use
>> the clock binding, did you mean pointing to that binding from
>> clocks=<...>, or from a custom property like my audio-graph-card,plls
>> example above.
> 
> When we say to use the clock binding what we are saying is to use the
> actual clock bindings to describe the clocks, not make a custom binding
> that looks kind of like them - making a custom binding doesn't address
> the problem.
> 

But I don't know what you mean by "use the actual clock bindings to
describe the clocks".

What is not clear to me is how you want me to use a clock binding to
describe something that isn't a clk-framework clk. If you know what you
want, then please.. an example would help explain.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 16:15                 ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 16:15 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

On 15/01/2021 15:20, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
>> On 15/01/2021 13:11, Mark Brown wrote:
>>> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>>>> On 13/01/2021 16:09, Mark Brown wrote:
>>>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>>>> some_codec {
>>>> 	pll: pll {
>>>> 		compatible = "fixed-clock";
>>>> 		clocks = <&audio_mclk>;
>>>> 		clock-frequency = <98304000>;
>>>> 	}
> 
>>> A PLL is not a fixed clock, why would you define a fixed clock here?
> 
>> It's a fixed clock if you are only setting one configuration. Call it
>> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
>> what it is for the purposes of what I was describing.
> 
>> This isn't a clk driver for a pll, it's just a setting to be passed to
>> snd_soc_component_set_pll() using a clock binding to specify it.
> 
> So you're trying to describe a crystal on the board?  Why would this be
> a subnode of the CODEC then?  Surely it's just a standard fixed clock
> which provides some input to the CODEC in the same way you'd describe
> any other input to the CODEC.  The above doesn't look anything like the
> hardware.  But if that's what you're doing how is that related to
> configuring the FLL except possibly as the input clock you'd reference?
> 
>>> Are you confusing the selection of rates on existing clocks with the use
>>> of the assigned-* properties that the clock binding provides?
> 
>> I'm not at all sure what you and Rob have in mind here. Perhaps you
>> could give an example of what you are thinking the .dts would look like
>> to define some pll/sysclk settings for audio-graph-card to apply. An
>> example is worth a thousand emails.
> 
> As far as I can tell you are trying to configure the FLL in the CODEC,
> telling it to take an input clock and produce a fixed output clock rate
> from that.  The FLL is a fairly basic clock, there are examples for both
> that and choosing a configuration for a clock in the clock bindings.
> 
>>> That seems like a *very* surprising requirement - why would the clock
>>> binding have that requirement?  It would seem to create issues for a
>>> single device providing multiple clocks which should be a pretty common
>>> coase.
> 
>> You misunderstand me. What I'm saying is that to do this:
> 
>> 	sound {
>> 		clocks = <&pll>;
>> 	}
> 
>> The node 'pll' must correspond to a clock provider driver. It can't be
>> just a bare node with some properties pick-n-mixed from the clock
>> binding, like this:
> 
> I'm pretty sure I understand you perfectly; again, what makes you say
> that a description of a clock in the device tree has any requirement
> for a separate compatible string?
> 

If I do:
  	sound {
  		clocks = <&clock>;
  	};

	clock: clock {
		compatible = "fixed-clock";
		clock-frequency = <98304000>;
	};

I can clk_bulk_get_all().
But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
will return -EPROBE_DEFER and log:

  /sound: Failed to get clk index: 0 ret: -517

from the error case in _clk_bulk_get() in clk/clk-bulk.c.

>> So the question I'm trying to ask is: when you and Rob said use
>> the clock binding, did you mean pointing to that binding from
>> clocks=<...>, or from a custom property like my audio-graph-card,plls
>> example above.
> 
> When we say to use the clock binding what we are saying is to use the
> actual clock bindings to describe the clocks, not make a custom binding
> that looks kind of like them - making a custom binding doesn't address
> the problem.
> 

But I don't know what you mean by "use the actual clock bindings to
describe the clocks".

What is not clear to me is how you want me to use a clock binding to
describe something that isn't a clk-framework clk. If you know what you
want, then please.. an example would help explain.

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 16:15                 ` Richard Fitzgerald
  0 siblings, 0 replies; 64+ messages in thread
From: Richard Fitzgerald @ 2021-01-15 16:15 UTC (permalink / raw)
  To: Mark Brown
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne

On 15/01/2021 15:20, Mark Brown wrote:
> On Fri, Jan 15, 2021 at 02:42:12PM +0000, Richard Fitzgerald wrote:
>> On 15/01/2021 13:11, Mark Brown wrote:
>>> On Fri, Jan 15, 2021 at 10:35:23AM +0000, Richard Fitzgerald wrote:
>>>> On 13/01/2021 16:09, Mark Brown wrote:
>>>>> On Wed, Jan 13, 2021 at 09:22:25AM -0600, Rob Herring wrote:
> 
>>>> some_codec {
>>>> 	pll: pll {
>>>> 		compatible = "fixed-clock";
>>>> 		clocks = <&audio_mclk>;
>>>> 		clock-frequency = <98304000>;
>>>> 	}
> 
>>> A PLL is not a fixed clock, why would you define a fixed clock here?
> 
>> It's a fixed clock if you are only setting one configuration. Call it
>> compatible="any-other-dummy-clock-type" if you like, it doesn't matter
>> what it is for the purposes of what I was describing.
> 
>> This isn't a clk driver for a pll, it's just a setting to be passed to
>> snd_soc_component_set_pll() using a clock binding to specify it.
> 
> So you're trying to describe a crystal on the board?  Why would this be
> a subnode of the CODEC then?  Surely it's just a standard fixed clock
> which provides some input to the CODEC in the same way you'd describe
> any other input to the CODEC.  The above doesn't look anything like the
> hardware.  But if that's what you're doing how is that related to
> configuring the FLL except possibly as the input clock you'd reference?
> 
>>> Are you confusing the selection of rates on existing clocks with the use
>>> of the assigned-* properties that the clock binding provides?
> 
>> I'm not at all sure what you and Rob have in mind here. Perhaps you
>> could give an example of what you are thinking the .dts would look like
>> to define some pll/sysclk settings for audio-graph-card to apply. An
>> example is worth a thousand emails.
> 
> As far as I can tell you are trying to configure the FLL in the CODEC,
> telling it to take an input clock and produce a fixed output clock rate
> from that.  The FLL is a fairly basic clock, there are examples for both
> that and choosing a configuration for a clock in the clock bindings.
> 
>>> That seems like a *very* surprising requirement - why would the clock
>>> binding have that requirement?  It would seem to create issues for a
>>> single device providing multiple clocks which should be a pretty common
>>> coase.
> 
>> You misunderstand me. What I'm saying is that to do this:
> 
>> 	sound {
>> 		clocks = <&pll>;
>> 	}
> 
>> The node 'pll' must correspond to a clock provider driver. It can't be
>> just a bare node with some properties pick-n-mixed from the clock
>> binding, like this:
> 
> I'm pretty sure I understand you perfectly; again, what makes you say
> that a description of a clock in the device tree has any requirement
> for a separate compatible string?
> 

If I do:
  	sound {
  		clocks = <&clock>;
  	};

	clock: clock {
		compatible = "fixed-clock";
		clock-frequency = <98304000>;
	};

I can clk_bulk_get_all().
But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
will return -EPROBE_DEFER and log:

  /sound: Failed to get clk index: 0 ret: -517

from the error case in _clk_bulk_get() in clk/clk-bulk.c.

>> So the question I'm trying to ask is: when you and Rob said use
>> the clock binding, did you mean pointing to that binding from
>> clocks=<...>, or from a custom property like my audio-graph-card,plls
>> example above.
> 
> When we say to use the clock binding what we are saying is to use the
> actual clock bindings to describe the clocks, not make a custom binding
> that looks kind of like them - making a custom binding doesn't address
> the problem.
> 

But I don't know what you mean by "use the actual clock bindings to
describe the clocks".

What is not clear to me is how you want me to use a clock binding to
describe something that isn't a clk-framework clk. If you know what you
want, then please.. an example would help explain.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
  2021-01-15 16:15                 ` Richard Fitzgerald
  (?)
@ 2021-01-15 18:35                   ` Mark Brown
  -1 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 18:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: Rob Herring, kuninori.morimoto.gx, nsaenzjulienne, f.fainelli,
	linux-kernel, devicetree, alsa-devel, patches,
	bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

On Fri, Jan 15, 2021 at 04:15:21PM +0000, Richard Fitzgerald wrote:

> If I do:
>  	sound {
>  		clocks = <&clock>;
>  	};
> 
> 	clock: clock {
> 		compatible = "fixed-clock";
> 		clock-frequency = <98304000>;
> 	};
> 
> I can clk_bulk_get_all().
> But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
> will return -EPROBE_DEFER and log:

OK, so if this is only supposed to represent a fixed clock on the board
separate to the CODEC then yes, of course you do need to instantiate a
driver for it like you do for every device on the board.  However it
shouldn't be a subdevice of the CODEC as you had it originally, it
should be a distinct device as the above has it since that is what
physically exists.  This obviously won't configure the FLL at all though
(which was what the binding you were proposing was for, the above is
definitely not a direct substitute for the binding you originally
proposed).

> > When we say to use the clock binding what we are saying is to use the
> > actual clock bindings to describe the clocks, not make a custom binding
> > that looks kind of like them - making a custom binding doesn't address
> > the problem.

> But I don't know what you mean by "use the actual clock bindings to
> describe the clocks".

> What is not clear to me is how you want me to use a clock binding to
> describe something that isn't a clk-framework clk. If you know what you
> want, then please.. an example would help explain.

The concept of a clock framework is an implementation detail of Linux
which should not affect how the DT bindings for a device or system are
written, DT bindings should be clear and idiomatic as DT bindings.  The
goal is to represent the system in a clear and standardized fashion
which is useful to OSs in general, not just something convenient for
Linux as it happens to be implemented right now.  Current Linux
internals are not a constraint for DT bindings.

In this case if you can't figure out how to parse clock bindings without
moving the clocks over to standard Linux clock APIs (which seems likely)
then it follows that if you want to describe the clock configuration in
DT then the driver support for these clocks should use the standard
Linux clock framework.  This seems like a good idea in general anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 18:35                   ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 18:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, Rob Herring, alsa-devel, f.fainelli,
	kuninori.morimoto.gx, devicetree, patches, linux-kernel,
	bcm-kernel-feedback-list, linux-rpi-kernel, nsaenzjulienne

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

On Fri, Jan 15, 2021 at 04:15:21PM +0000, Richard Fitzgerald wrote:

> If I do:
>  	sound {
>  		clocks = <&clock>;
>  	};
> 
> 	clock: clock {
> 		compatible = "fixed-clock";
> 		clock-frequency = <98304000>;
> 	};
> 
> I can clk_bulk_get_all().
> But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
> will return -EPROBE_DEFER and log:

OK, so if this is only supposed to represent a fixed clock on the board
separate to the CODEC then yes, of course you do need to instantiate a
driver for it like you do for every device on the board.  However it
shouldn't be a subdevice of the CODEC as you had it originally, it
should be a distinct device as the above has it since that is what
physically exists.  This obviously won't configure the FLL at all though
(which was what the binding you were proposing was for, the above is
definitely not a direct substitute for the binding you originally
proposed).

> > When we say to use the clock binding what we are saying is to use the
> > actual clock bindings to describe the clocks, not make a custom binding
> > that looks kind of like them - making a custom binding doesn't address
> > the problem.

> But I don't know what you mean by "use the actual clock bindings to
> describe the clocks".

> What is not clear to me is how you want me to use a clock binding to
> describe something that isn't a clk-framework clk. If you know what you
> want, then please.. an example would help explain.

The concept of a clock framework is an implementation detail of Linux
which should not affect how the DT bindings for a device or system are
written, DT bindings should be clear and idiomatic as DT bindings.  The
goal is to represent the system in a clear and standardized fashion
which is useful to OSs in general, not just something convenient for
Linux as it happens to be implemented right now.  Current Linux
internals are not a constraint for DT bindings.

In this case if you can't figure out how to parse clock bindings without
moving the clocks over to standard Linux clock APIs (which seems likely)
then it follows that if you want to describe the clock configuration in
DT then the driver support for these clocks should use the standard
Linux clock framework.  This seems like a good idea in general anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 64+ messages in thread

* Re: [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties
@ 2021-01-15 18:35                   ` Mark Brown
  0 siblings, 0 replies; 64+ messages in thread
From: Mark Brown @ 2021-01-15 18:35 UTC (permalink / raw)
  To: Richard Fitzgerald
  Cc: linux-arm-kernel, alsa-devel, f.fainelli, kuninori.morimoto.gx,
	devicetree, patches, linux-kernel, bcm-kernel-feedback-list,
	linux-rpi-kernel, nsaenzjulienne


[-- Attachment #1.1: Type: text/plain, Size: 2334 bytes --]

On Fri, Jan 15, 2021 at 04:15:21PM +0000, Richard Fitzgerald wrote:

> If I do:
>  	sound {
>  		clocks = <&clock>;
>  	};
> 
> 	clock: clock {
> 		compatible = "fixed-clock";
> 		clock-frequency = <98304000>;
> 	};
> 
> I can clk_bulk_get_all().
> But if I remove the 'compatible' from the clock node, clk_bulk_get_all()
> will return -EPROBE_DEFER and log:

OK, so if this is only supposed to represent a fixed clock on the board
separate to the CODEC then yes, of course you do need to instantiate a
driver for it like you do for every device on the board.  However it
shouldn't be a subdevice of the CODEC as you had it originally, it
should be a distinct device as the above has it since that is what
physically exists.  This obviously won't configure the FLL at all though
(which was what the binding you were proposing was for, the above is
definitely not a direct substitute for the binding you originally
proposed).

> > When we say to use the clock binding what we are saying is to use the
> > actual clock bindings to describe the clocks, not make a custom binding
> > that looks kind of like them - making a custom binding doesn't address
> > the problem.

> But I don't know what you mean by "use the actual clock bindings to
> describe the clocks".

> What is not clear to me is how you want me to use a clock binding to
> describe something that isn't a clk-framework clk. If you know what you
> want, then please.. an example would help explain.

The concept of a clock framework is an implementation detail of Linux
which should not affect how the DT bindings for a device or system are
written, DT bindings should be clear and idiomatic as DT bindings.  The
goal is to represent the system in a clear and standardized fashion
which is useful to OSs in general, not just something convenient for
Linux as it happens to be implemented right now.  Current Linux
internals are not a constraint for DT bindings.

In this case if you can't figure out how to parse clock bindings without
moving the clocks over to standard Linux clock APIs (which seems likely)
then it follows that if you want to describe the clock configuration in
DT then the driver support for these clocks should use the standard
Linux clock framework.  This seems like a good idea in general anyway.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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	[flat|nested] 64+ messages in thread

end of thread, other threads:[~2021-01-15 18:37 UTC | newest]

Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-08 16:04 [PATCH v4 0/6] Add support for Rpi4b + Cirrus Lochnagar2 and CS47L15 Richard Fitzgerald
2021-01-08 16:04 ` Richard Fitzgerald
2021-01-08 16:04 ` Richard Fitzgerald
2021-01-08 16:04 ` [PATCH v4 1/6] of: base: Add of_count_phandle_with_fixed_args() Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:04 ` [PATCH v4 2/6] dt-bindings: audio-graph-card: Add plls and sysclks properties Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-13 15:22   ` Rob Herring
2021-01-13 15:22     ` Rob Herring
2021-01-13 15:22     ` Rob Herring
2021-01-13 16:09     ` Mark Brown
2021-01-13 16:09       ` Mark Brown
2021-01-13 16:09       ` Mark Brown
2021-01-15 10:35       ` Richard Fitzgerald
2021-01-15 10:35         ` Richard Fitzgerald
2021-01-15 10:35         ` Richard Fitzgerald
2021-01-15 13:11         ` Mark Brown
2021-01-15 13:11           ` Mark Brown
2021-01-15 13:11           ` Mark Brown
2021-01-15 14:42           ` Richard Fitzgerald
2021-01-15 14:42             ` Richard Fitzgerald
2021-01-15 14:42             ` Richard Fitzgerald
2021-01-15 15:20             ` Mark Brown
2021-01-15 15:20               ` Mark Brown
2021-01-15 15:20               ` Mark Brown
2021-01-15 16:15               ` Richard Fitzgerald
2021-01-15 16:15                 ` Richard Fitzgerald
2021-01-15 16:15                 ` Richard Fitzgerald
2021-01-15 18:35                 ` Mark Brown
2021-01-15 18:35                   ` Mark Brown
2021-01-15 18:35                   ` Mark Brown
2021-01-14 10:31     ` Richard Fitzgerald
2021-01-14 10:31       ` Richard Fitzgerald
2021-01-14 10:31       ` Richard Fitzgerald
2021-01-14 11:14       ` Mark Brown
2021-01-14 11:14         ` Mark Brown
2021-01-14 11:14         ` Mark Brown
2021-01-14 12:31         ` Richard Fitzgerald
2021-01-08 16:04 ` [PATCH v4 3/6] ASoC: audio-graph-card: Support setting component plls and sysclks Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-12  1:35   ` Kuninori Morimoto
2021-01-12  1:35     ` Kuninori Morimoto
2021-01-12  1:35     ` Kuninori Morimoto
2021-01-12 10:22     ` Richard Fitzgerald
2021-01-12 10:22       ` Richard Fitzgerald
2021-01-12 10:22       ` Richard Fitzgerald
2021-01-13  0:00       ` Kuninori Morimoto
2021-01-13  0:00         ` Kuninori Morimoto
2021-01-13  0:00         ` Kuninori Morimoto
2021-01-13 15:51         ` Mark Brown
2021-01-13 15:51           ` Mark Brown
2021-01-13 15:51           ` Mark Brown
2021-01-08 16:04 ` [PATCH v4 4/6] ASoC: madera: Allow codecs to be selected from kernel config Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:04   ` Richard Fitzgerald
2021-01-08 16:05 ` [PATCH v4 5/6] ASoC: madera: Export clock config defines to dt-bindings Richard Fitzgerald
2021-01-08 16:05   ` Richard Fitzgerald
2021-01-08 16:05   ` Richard Fitzgerald
2021-01-08 16:05 ` [PATCH v4 6/6] ARM: dts: Add dts for RPi4b + Cirrus Logic Lochnagar2 + CS47L15 Richard Fitzgerald
2021-01-08 16:05   ` Richard Fitzgerald
2021-01-08 16:05   ` Richard Fitzgerald

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.