clk: Samsung: audss: Add support for Exynos5420

From: Andrew Bresticker <[email protected]>

This allows the input clocks to the Exynos AudioSS block to be specified via device-tree bindings. Default names will be used when an input clock is not given. This will be useful when adding support for the Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of "sclk_audio0".

Signed-off-by Andrew Bresticker <[email protected]>

Reviewed-on: https://gerrit.chromium.org/gerrit/57833

Reviewed-by Simon Glass <[email protected]>

---
 .../devicetree/bindings/clock/clk-exynos-audss.txt |   31

++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c |
28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)

Hi Padmavathi, Andrew,

Quoted 8 lines · On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:

From: Andrew Bresticker <[email protected]>

This allows the input clocks to the Exynos AudioSS block to be specified via device-tree bindings. Default names will be used when an input clock is not given. This will be useful when adding support for the Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of "sclk_audio0".

Quoted 7 lines

Signed-off-by Andrew Bresticker <[email protected]>

Reviewed-on: https://gerrit.chromium.org/gerrit/57833

Reviewed-by Simon Glass <[email protected]>

---
 .../devicetree/bindings/clock/clk-exynos-audss.txt |   31

++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c |
28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)

Well, this is basically how it should be done, but in current state of clock core I can see a problem: can we really rely on the order of clock initialization? I mean, we can't defer initialization of particular clock controller until all external clocks it needs are available, because there is no probing involved here.

Best regards,
Tomasz

Quoting Tomasz Figa (2013-07-22 09:28:47)

Quoted 23 lines

Hi Padmavathi, Andrew,

Quoted 11 lines · On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:

From: Andrew Bresticker <[email protected]>

This allows the input clocks to the Exynos AudioSS block to be specified via device-tree bindings. Default names will be used when an input clock is not given. This will be useful when adding support for the Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of "sclk_audio0".

Signed-off-by Andrew Bresticker <[email protected]>

Reviewed-on: https://gerrit.chromium.org/gerrit/57833

Reviewed-by Simon Glass <[email protected]>

Quoted 8 lines

---

 .../devicetree/bindings/clock/clk-exynos-audss.txt |   31

++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c
|> >
28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)

Quoted 5 lines

Well, this is basically how it should be done, but in current state of clock core I can see a problem: can we really rely on the order of clock initialization? I mean, we can't defer initialization of particular clock controller until all external clocks it needs are available, because there is no probing involved here.

The clock core allows registering clocks even if their parents are not yet registered. I test this path with some dummy clocks every so often to make sure the re-parenting operation are completed successfully after the parents eventually are registered.

This feature was not used in practice until recently with the advent of multiple clock controllers getting registered and DT description of clocks / clock controllers that may be "out of order". If you find any bugs please let me know ;-)

Quoted 25 lines · On Monday 22 of July 2013 11:15:30 Mike Turquette wrote:

Quoting Tomasz Figa (2013-07-22 09:28:47)

Quoted 23 lines

Hi Padmavathi, Andrew,

Quoted 19 lines · On Wednesday 10 of July 2013 17:41:51 Padmavathi Venna wrote:

From: Andrew Bresticker <[email protected]>

This allows the input clocks to the Exynos AudioSS block to be specified via device-tree bindings. Default names will be used when an input clock is not given. This will be useful when adding support for the Exynos5420 where the audio bus clock is called "sclk_maudio0" instead of "sclk_audio0".

Signed-off-by Andrew Bresticker <[email protected]>

Reviewed-on: https://gerrit.chromium.org/gerrit/57833

Reviewed-by Simon Glass <[email protected]>

---

 .../devicetree/bindings/clock/clk-exynos-audss.txt |   31

++++++++++++++++++- drivers/clk/samsung/clk-exynos-audss.c
|> >
28 +++++++++++++++-- 2 files changed, 53 insertions(+), 6 deletions(-)

Quoted 5 lines

Quoted 5 lines

Well, this is basically how it should be done, but in current state of clock core I can see a problem: can we really rely on the order of clock initialization? I mean, we can't defer initialization of particular clock controller until all external clocks it needs are available, because there is no probing involved here.

Quoted 5 lines

The clock core allows registering clocks even if their parents are not yet registered. I test this path with some dummy clocks every so often to make sure the re-parenting operation are completed successfully after the parents eventually are registered.

Sure it does, but this patch is about something different. It adds device tree based lookup (of_clk_get_by_name()) of external clocks (as opposed to existing lookup by name), which will fail if provider pointed by phandle is not registered yet.

Quoted 4 lines

This feature was not used in practice until recently with the advent of multiple clock controllers getting registered and DT description of clocks / clock controllers that may be "out of order". If you find any bugs please let me know ;-)

I will send you a bunch of patches sorting out issues I found in clk_set_rate() path, but give me some time to prepare them :).

As for multiple clock controllers, this is going to be funny. I have discussed this a bit with Sylwester and we managed to find some design issues that I think must be solved:

a) What about multiple controllers with identical clock names? Imagine two PMICs that can also generate 32 KHz clocks, both having them named "clk32k". Am I right saying that this won't work with current code?

b) What are the rules of using clock-output-names property (and what should be used in non-DT case)? I can imagine using it to assign platform- specific names of clock outputs of extra clock controllers (this would help in the above case of "clk32k"), but currently it seems like it is optional to use it in clock drivers and the meaning is provider-specific.

Best regards,
Tomasz

Well, this is basically how it should be done, but in current state of clock core I can see a problem: can we really rely on the order of clock initialization? I mean, we can't defer initialization of particular clock controller until all external clocks it needs are available, because there is no probing involved here.

This patch corrects the /include to #include on exynos5420

Signed-off-by Padmavathi Venna<[email protected]>

---
  arch/arm/boot/dts/exynos5420.dtsi |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

arch/arm/boot/dts/exynos5420.dtsi +0 -0

index 8c54c4b..da55160 100644

From: Andrew Bresticker<[email protected]>

This adds device-tree bindings for the audio subsystem clock controller on Exynos 5420.

Signed-off-by Andrew Bresticker<[email protected]>

Reviewed-on: https://gerrit.chromium.org/gerrit/57712

Reviewed-by Simon Glass<[email protected]>

Signed-off-by Padmavathi Venna<[email protected]>

---
  arch/arm/boot/dts/exynos5420.dtsi |   11 +++++++++++
  1 files changed, 11 insertions(+), 0 deletions(-)

arch/arm/boot/dts/exynos5420.dtsi +4 -0

index da55160..a84f5f1 100644
@@ -15,6 +15,9 @@
 
  #include "exynos5.dtsi"
  #include "exynos5420-pinctrl.dtsi"
+
+#include<dt-bindings/clk/exynos-audss-clk.h>
+
  / {
  	compatible = "samsung,exynos5420";
 

@@ -65,6 +68,14 @@
  		#clock-cells =<1>;
  	};
 
+	clock_audss: audss-clock-controller@3810000 {

This patch set adds support for audio subsystem clks on Exynos5420. Exynos5420 audio subsystem has a gate bit for ADMA controller and the some of parent clks for mout_i2s are also different from Exynos5250. So this patch adds provision for supporting both the platforms by passing the parent clk names through device tree.

Andrew Bresticker (3):
clk: exynos-audss: add support for Exynos 5420
clk: exynos-audss: allow input clocks to be specified in device tree
ARM: dts: exynos5420: add audio clock controller

Padmavathi Venna (1):
ARM: dts: Correct the /include entry on exynos5420 dtsi file

 .../devicetree/bindings/clock/clk-exynos-audss.txt |   38 +++++++++++++++++--
 arch/arm/boot/dts/exynos5420.dtsi                  |   13 ++++++-
 drivers/clk/samsung/clk-exynos-audss.c             |   36 ++++++++++++++++--
 include/dt-bindings/clk/exynos-audss-clk.h         |    3 +-
 4 files changed, 80 insertions(+), 10 deletions(-)

--
1.7.4.4