ARM: sun9i: Enable MMC support on Allwinner A80

The only difference between module clocks on different platforms is the width of the mux register bits and the valid values, which are passed in through struct factors_data. The phase clocks parts are identical.

This patch generalizes the setup function, so most of the code can be reused when adding sun9i support, which has a wider mux register.

Signed-off-by Chen-Yu Tsai <[email protected]>

The module 0 style clocks, or storage module clocks as named in the official SDK, are almost the same as the module 0 clocks on earlier Allwinner SoCs. The only difference is wider mux register bits.

As with earlier Allwinner SoCs, mmc module clocks are a special case of mod0 clocks, with phase controls for 2 child clocks, output and sample.

This patch adds support for both.

Signed-off-by Chen-Yu Tsai <[email protected]>

---
 Documentation/devicetree/bindings/clock/sunxi.txt |  7 +++--
 drivers/clk/sunxi/clk-mod0.c                      | 32 +++++++++++++++++++++++
 2 files changed, 37 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/clock/sunxi.txt +5 -2

index e4c42276c577..0dfd018ba47b 100644
@@ -56,7 +56,9 @@ Required properties:
 	"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
 	"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
 	"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
+	"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
 	"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
+	"allwinner,sun9i-a80-mod0-clk" - for module 0 (storage) clocks on A80
 	"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
 	"allwinner,sun7i-a20-out-clk" - for the external output clocks
 	"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31

@@ -72,7 +74,8 @@ Required properties for all clocks:
 - #clock-cells : from common clock binding; shall be set to 0 except for
 	the following compatibles where it shall be set to 1:
 	"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
-	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk"
+	"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
+	"allwinner,*-usb-clk", "allwinner,*-mmc-clk"
 - clock-output-names : shall be the corresponding names of the outputs.
 	If the clock module only has one output, the name shall be the
 	module name.

@@ -94,7 +97,7 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
 is the normal PLL6 output, or "pll6". The second output is rate doubled
 PLL6, or "pll6x2".
 
-The "allwinner,sun4i-a10-mmc-clk" has three different outputs: the
+The "allwinner,*-mmc-clk" clocks have three different outputs: the
 main clock, with the ID 0, and the output and sample clocks, with the
 IDs 1 and 2, respectively.
 

drivers/clk/sunxi/clk-mod0.c +4 -0

index 4430d1398ce6..99ff2c7cccf7 100644
@@ -130,6 +130,30 @@ static struct platform_driver sun4i_a10_mod0_clk_driver = {
 };
 module_platform_driver(sun4i_a10_mod0_clk_driver);
 
+static const struct factors_data sun9i_a80_mod0_data __initconst = {
+	.enable = 31,
+	.mux = 24,
+	.muxmask = BIT(3) | BIT(2) | BIT(1) | BIT(0),

Quoted 57 lines · Chen-Yu Tsai

The module 0 style clocks, or storage module clocks as named in the official SDK, are almost the same as the module 0 clocks on earlier Allwinner SoCs. The only difference is wider mux register bits.

As with earlier Allwinner SoCs, mmc module clocks are a special case of mod0 clocks, with phase controls for 2 child clocks, output and sample.

This patch adds support for both.

Signed-off-by Chen-Yu Tsai <[email protected]>

---
 Documentation/devicetree/bindings/clock/sunxi.txt |  7 +++--
 drivers/clk/sunxi/clk-mod0.c                      | 32 +++++++++++++++++++++++
 2 files changed, 37 insertions(+), 2 deletions(-)

Documentation/devicetree/bindings/clock/sunxi.txt +5 -2

index e4c42276c577..0dfd018ba47b 100644
@@ -56,7 +56,9 @@ Required properties:
      "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
      "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
      "allwinner,sun4i-a10-mmc-clk" - for the MMC clock
+     "allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
      "allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
+     "allwinner,sun9i-a80-mod0-clk" - for module 0 (storage) clocks on A80
      "allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
      "allwinner,sun7i-a20-out-clk" - for the external output clocks
      "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31

@@ -72,7 +74,8 @@ Required properties for all clocks:
 - #clock-cells : from common clock binding; shall be set to 0 except for
      the following compatibles where it shall be set to 1:
      "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
-     "allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk"
+     "allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk",
+     "allwinner,*-usb-clk", "allwinner,*-mmc-clk"
 - clock-output-names : shall be the corresponding names of the outputs.
      If the clock module only has one output, the name shall be the
      module name.

@@ -94,7 +97,7 @@ For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
 is the normal PLL6 output, or "pll6". The second output is rate doubled
 PLL6, or "pll6x2".
 
-The "allwinner,sun4i-a10-mmc-clk" has three different outputs: the
+The "allwinner,*-mmc-clk" clocks have three different outputs: the
 main clock, with the ID 0, and the output and sample clocks, with the
 IDs 1 and 2, respectively.
 

drivers/clk/sunxi/clk-mod0.c +0 -0

index 4430d1398ce6..99ff2c7cccf7 100644
@@ -130,6 +130,30 @@ static struct platform_driver sun4i_a10_mod0_clk_driver = {
 };
 module_platform_driver(sun4i_a10_mod0_clk_driver);
 

Quoted 4 lines

drivers/clk/sunxi/clk-mod0.c +4 -0

+static const struct factors_data sun9i_a80_mod0_data __initconst = {
+     .enable = 31,
+     .mux = 24,
+     .muxmask = BIT(3) | BIT(2) | BIT(1) | BIT(0),

drivers/clk/sunxi/clk-mod0.c static struct platform_driver sun4i_a10_mod0_clk_driver = { · line 146

Quoted 10 lines

drivers/clk/sunxi/clk-mod0.c +10 -0

+     .table = &sun4i_a10_mod0_config,
+     .getter = sun4i_a10_get_mod0_factors,
+};
+
+static void __init sun9i_a80_mod0_setup(struct device_node *node)
+{
+     void __iomem *reg;
+
+     reg = of_io_request_and_map(node, 0, of_node_full_name(node));
+     if (!reg) {

of_io_request_and_map returns an error pointer.

Looks good otherwise.

Thanks!
Maxime

--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

The mmc module clocks are A80 specific module 0 (storage) type clocks.

Signed-off-by Chen-Yu Tsai <[email protected]>

Signed-off-by Andreas F?rber <[email protected]>

On the A80 SoC, the 4 mmc controllers each have a separate register controlling their register access clocks and reset controls. These registers in turn share a ahb clock gate and reset control.

This patch adds a platform device driver for these controls. It requires both clocks and reset controls to be available, so using CLK_OF_DECLARE might not be the best way.

Signed-off-by Chen-Yu Tsai <[email protected]>

---
 Documentation/devicetree/bindings/clock/sunxi.txt |  25 ++-
 drivers/clk/sunxi/Makefile                        |   1 +
 drivers/clk/sunxi/clk-sun9i-mmc.c                 | 222 ++++++++++++++++++++++
 3 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/sunxi/clk-sun9i-mmc.c

Documentation/devicetree/bindings/clock/sunxi.txt +0 -0

index 0dfd018ba47b..60b44285250d 100644

Quoted 16 lines · Chen-Yu Tsai

On the A80 SoC, the 4 mmc controllers each have a separate register controlling their register access clocks and reset controls. These registers in turn share a ahb clock gate and reset control.

This patch adds a platform device driver for these controls. It requires both clocks and reset controls to be available, so using CLK_OF_DECLARE might not be the best way.

Signed-off-by Chen-Yu Tsai <[email protected]>

---
 Documentation/devicetree/bindings/clock/sunxi.txt |  25 ++-
 drivers/clk/sunxi/Makefile                        |   1 +
 drivers/clk/sunxi/clk-sun9i-mmc.c                 | 222 ++++++++++++++++++++++
 3 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/sunxi/clk-sun9i-mmc.c

Documentation/devicetree/bindings/clock/sunxi.txt Required properties: · line 60

Quoted 9 lines

Documentation/devicetree/bindings/clock/sunxi.txt +1 -0

index 0dfd018ba47b..60b44285250d 100644
@@ -57,6 +57,7 @@ Required properties:
      "allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
      "allwinner,sun4i-a10-mmc-clk" - for the MMC clock
      "allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
+     "allwinner,sun9i-a80-mmc-config-clk" - for mmc gates + resets on A80

It looks like it's not just a clock. How about dropping the -clk suffix?

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Quoted 8 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Quoted 1 line

Signed-off-by Chen-Yu Tsai <[email protected]>

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Quoted 11 lines · Maxime Ripard

Quoted 9 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Quoted 3 lines

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Yes they are still passed through factors_data, for mux_clk_ops to know about the width of the mux, which is 3 bits on older SoCs vs 4 bits on sun9i.

Quoted 17 lines · Chen-Yu Tsai

Quoted 14 lines · Maxime Ripard

Quoted 9 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Quoted 3 lines

Yes they are still passed through factors_data, for mux_clk_ops to know about the width of the mux, which is 3 bits on older SoCs vs 4 bits on sun9i.

Erm.... These are gates. They are not muxable and are not handled through clk-factors, so I'm not sure how it is relevant :)

Quoted 18 lines · Maxime Ripard

Quoted 17 lines · Chen-Yu Tsai

Quoted 14 lines · Maxime Ripard

Quoted 9 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Quoted 6 lines

Quoted 3 lines

Yes they are still passed through factors_data, for mux_clk_ops to know about the width of the mux, which is 3 bits on older SoCs vs 4 bits on sun9i.

Erm.... These are gates. They are not muxable and are not handled through clk-factors, so I'm not sure how it is relevant :)

Sorry. I jumped to the mux mask stuff. Yes the gate masks are still used, and the gates are still referenced by the bit offset.

As described in the commit message, clock-indices is used by of_clk_get_parent_name() to match the index used in the phandle to the correct name in clock-names.

Take apb1 for example:

                       clock-indices = <0>, <1>, <2>, <3>, <4>,
                                       <16>, <17>, <18>, <19>, <20>, <21>;
                       clock-output-names = "apb1_i2c0", "apb1_i2c1",
                                       "apb1_i2c2", "apb1_i2c3", "apb1_i2c4",
                                       "apb1_uart0", "apb1_uart1", ...

If we have "clocks = <&apb1 16>;" in some device, and we call of_clk_get_parent_name() on said clock, it would try to get clock_output_names[16], which obviously is the wrong one.

With clock-indices, of_clk_get_parent_name first looks at that array, finds an entry matching 16, then uses the index of the matching entry to get the name from clock-output-names.

So, we are still using the gate bitmask to declare valid clock gates. The sunxi driver does not use clock-indices directly. Nor do I think it was intended to be used by clock drivers directly.

Quoted 42 lines · Chen-Yu Tsai

Quoted 18 lines · Maxime Ripard

Quoted 17 lines · Chen-Yu Tsai

Quoted 14 lines · Maxime Ripard

Quoted 9 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Quoted 6 lines

Quoted 3 lines

Yes they are still passed through factors_data, for mux_clk_ops to know about the width of the mux, which is 3 bits on older SoCs vs 4 bits on sun9i.

Erm.... These are gates. They are not muxable and are not handled through clk-factors, so I'm not sure how it is relevant :)

Sorry. I jumped to the mux mask stuff. Yes the gate masks are still used, and the gates are still referenced by the bit offset.

As described in the commit message, clock-indices is used by of_clk_get_parent_name() to match the index used in the phandle to the correct name in clock-names.

Take apb1 for example:

                       clock-indices = <0>, <1>, <2>, <3>, <4>,
                                       <16>, <17>, <18>, <19>, <20>, <21>;
                       clock-output-names = "apb1_i2c0", "apb1_i2c1",
                                       "apb1_i2c2", "apb1_i2c3", "apb1_i2c4",
                                       "apb1_uart0", "apb1_uart1", ...

Quoted 8 lines

If we have "clocks = <&apb1 16>;" in some device, and we call of_clk_get_parent_name() on said clock, it would try to get clock_output_names[16], which obviously is the wrong one.

With clock-indices, of_clk_get_parent_name first looks at that array, finds an entry matching 16, then uses the index of the matching entry to get the name from clock-output-names.

Yeah, I know what it does, and we do agree on the fact that it's needed.

Quoted 4 lines

So, we are still using the gate bitmask to declare valid clock gates. The sunxi driver does not use clock-indices directly. Nor do I think it was intended to be used by clock drivers directly.

However, the gate bitmask itself carries exactly the same information than clock-indices. It's the exact same list of numbers, just with two different ways of defining it.

If we go with clock-indices, which is the right solution, then we can just drop the other one.

I actually started to do just this last evening. A31 boots without any gates bit mask but the USB clocks one so far, I intend on converting the others as well.

Quoted 67 lines · Maxime Ripard

Quoted 42 lines · Chen-Yu Tsai

Quoted 18 lines · Maxime Ripard

Quoted 17 lines · Chen-Yu Tsai

Quoted 14 lines · Maxime Ripard

Quoted 9 lines · Chen-Yu Tsai

of_clk_get_parent_name() uses the clock-indices property to resolve clock phandle arguments in case that the argument index does not match the clock-output-names sequence.

This is the case on sunxi, where we use the actual bit index as the argument to the phandle. Add the clock-indices property so that of_clk_get_parent_name() resolves the names correctly.

Signed-off-by Chen-Yu Tsai <[email protected]>

Applied. Are the mask in the clock driver still of any use now? I don't think they are, and if we're going that way, I'd rather have them removed from the driver.

Quoted 6 lines

Quoted 3 lines

Yes they are still passed through factors_data, for mux_clk_ops to know about the width of the mux, which is 3 bits on older SoCs vs 4 bits on sun9i.

Erm.... These are gates. They are not muxable and are not handled through clk-factors, so I'm not sure how it is relevant :)

Sorry. I jumped to the mux mask stuff. Yes the gate masks are still used, and the gates are still referenced by the bit offset.

As described in the commit message, clock-indices is used by of_clk_get_parent_name() to match the index used in the phandle to the correct name in clock-names.

Take apb1 for example:

                       clock-indices = <0>, <1>, <2>, <3>, <4>,
                                       <16>, <17>, <18>, <19>, <20>, <21>;
                       clock-output-names = "apb1_i2c0", "apb1_i2c1",
                                       "apb1_i2c2", "apb1_i2c3", "apb1_i2c4",
                                       "apb1_uart0", "apb1_uart1", ...

Quoted 8 lines

If we have "clocks = <&apb1 16>;" in some device, and we call of_clk_get_parent_name() on said clock, it would try to get clock_output_names[16], which obviously is the wrong one.

With clock-indices, of_clk_get_parent_name first looks at that array, finds an entry matching 16, then uses the index of the matching entry to get the name from clock-output-names.

Yeah, I know what it does, and we do agree on the fact that it's needed.

Quoted 4 lines

So, we are still using the gate bitmask to declare valid clock gates. The sunxi driver does not use clock-indices directly. Nor do I think it was intended to be used by clock drivers directly.

However, the gate bitmask itself carries exactly the same information than clock-indices. It's the exact same list of numbers, just with two different ways of defining it.

If we go with clock-indices, which is the right solution, then we can just drop the other one.

Quoted 3 lines

I actually started to do just this last evening. A31 boots without any gates bit mask but the USB clocks one so far, I intend on converting the others as well.

So as I understand, you want to replace the masks in the clock drivers with clock-indices in the dt. Is this correct? This potentially makes the gates clock driver very generic, which is nice.

I only see drivers/clk/shmobile/clk-mstp.c using it this way though. Didn't we have this for sun6i-apb0-gates at one time?

I'm not against it. Just want to make sure everyone agrees, and we can work who and how we're going about this.

Add the device tree nodes for the mmc config clock nodes.

Signed-off-by Chen-Yu Tsai <[email protected]>

---
 arch/arm/boot/dts/sun9i-a80.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

arch/arm/boot/dts/sun9i-a80.dtsi +0 -0

index 9d0a66c14caf..9b3b71c6f29b 100644

Use the label to reference the pin controller node, so that we can use sunxi-common-regulators with sunxi families that don't share the same address space mappings, such as sun9i.

This patch is mostly space changes due to the reduction of node parents.

Signed-off-by Chen-Yu Tsai <[email protected]>

mmc0 is only available on port F, and is always used with a 4 bit wide bus for the onboard micro-sd slot.

Signed-off-by Chen-Yu Tsai <[email protected]>

Signed-off-by Andreas F?rber <[email protected]>