Skip to contentSkip to conversation

nvmem: meson: efuse updates

PATCH Applied Jerome Brunet 3 participants 12 messages Oct 30, 2018 – Nov 13, 2018

Subsystems (3)
lore
Share & tools
lore

Jerome Brunet

author reviewer
#0 lore raw

cover nvmem: meson: efuse updates

The first change of this patchset just adds add error message in case of failure. If there is problem with the secure monitor, the SM_EFUSE_USER_MAX call will be first one to fail so it is better if it give us a clue to help debugging, instead af silently failing.

Next this series adds the peripheral clock missing in this driver. Like many other device in amlogic's SoC, the efuse requires a peripheral clock to operate. ATM, the clock controller has CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the bootloader left the clock enabled

At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a driver needs a clock, it needs to properly claim it.

Srinivas, Kevin,
The dts change needs to land before the actual driver change, to avoid breaking the efuse on our users. If there an agreement on this series, Kevin could you provide a tag to Srinivas ?

Cheers
Jerome

Jerome Brunet (4):
nvmem: meson-efuse: add error message on user_max failure.
nvmem: meson-efuse: bindings: add peripheral clock
arm64: dts: meson-gx: add efuse pclk
nvmem: meson-efuse: add peripheral clock

 .../bindings/nvmem/amlogic-efuse.txt          |  3 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi   |  4 +++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi    |  4 +++
 drivers/nvmem/meson-efuse.c                   | 29 ++++++++++++++++++-
 4 files changed, 39 insertions(+), 1 deletion(-)
Signature · 1 line
2.17.2
author reviewer
#1 lore raw

PATCH 1/4 nvmem: meson-efuse: add error message on user_max failure.

Add an explicit error message when SM_EFUSE_USER_MAX command fails

---
 drivers/nvmem/meson-efuse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/nvmem/meson-efuse.c +3 -1
index d769840d1e18..40b9df1d030d 100644
@@ -48,8 +48,10 @@ static int meson_efuse_probe(struct platform_device *pdev)
 	struct nvmem_config *econfig;
 	unsigned int size;
 
-	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0)
+	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0) {
+		dev_err(dev, "failed to get max user");
 		return -EINVAL;
+	}
 
 	econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
 	if (!econfig)
Signature · 1 line
2.17.2
#2 lore raw

Re: [PATCH 1/4] nvmem: meson-efuse: add error message on user_max failure.

Quoted 6 lines · Jerome Brunet

Add an explicit error message when SM_EFUSE_USER_MAX command fails

---
  drivers/nvmem/meson-efuse.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Applied to nvmem for-next branch!

thanks,
srini

author reviewer
#3 lore raw

PATCH 2/4 nvmem: meson-efuse: bindings: add peripheral clock

In reply to Jerome Brunet

The efuse found in gx SoC requires a peripheral clock to properly operate. We have been able to work without it until now because the clock was on by default, and left on by the CCF. Soon, it will not be the case anymore, so the device needs to claim the clock it needs

---
 Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 3 +++
 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt +3 -0
index e3298e18de26..2e0723ab3384 100644
@@ -2,6 +2,8 @@
 
 Required properties:
 - compatible: should be "amlogic,meson-gxbb-efuse"
+- clocks: phandle to the efuse peripheral clock provided by the
+	  clock controller.
 
 = Data cells =
 Are child nodes of eFuse, bindings of which as described in
@@ -11,6 +13,7 @@ Example:
 
 	efuse: efuse {
 		compatible = "amlogic,meson-gxbb-efuse";
+		clocks = <&clkc CLKID_EFUSE>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 
Signature · 1 line
2.17.2
maintainer
#4 lore raw

PATCH 2/4 nvmem: meson-efuse: bindings: add peripheral clock

Quoted 10 lines · Jerome Brunet

The efuse found in gx SoC requires a peripheral clock to properly operate. We have been able to work without it until now because the clock was on by default, and left on by the CCF. Soon, it will not be the case anymore, so the device needs to claim the clock it needs

---
 Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 3 +++
 1 file changed, 3 insertions(+)
#5 lore raw

Re: [PATCH 2/4] nvmem: meson-efuse: bindings: add peripheral clock

In reply to Jerome Brunet
Quoted 9 lines · Jerome Brunet

The efuse found in gx SoC requires a peripheral clock to properly operate. We have been able to work without it until now because the clock was on by default, and left on by the CCF. Soon, it will not be the case anymore, so the device needs to claim the clock it needs

---
  Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 3 +++
  1 file changed, 3 insertions(+)

Applied, thanks,

--
Srini

author reviewer
#6 lore raw

PATCH 3/4 arm64: dts: meson-gx: add efuse pclk

In reply to Jerome Brunet

Add the required peripheral clock for the efuse device.

---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 4 ++++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 4 ++++
 2 files changed, 8 insertions(+)
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi +4 -0
index 1ade7e486828..524f533e41d4 100644
@@ -282,6 +282,10 @@
 	compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
 };
 
+&efuse {
+	clocks = <&clkc CLKID_EFUSE>;
+};
+
 &ethmac {
 	clocks = <&clkc CLKID_ETH>,
 		 <&clkc CLKID_FCLK_DIV2>,
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi +4 -0
index 8f0bb3c44bd6..8ccab9a1ebcc 100644
@@ -75,6 +75,10 @@
 	};
 };
 
+&efuse {
+	clocks = <&clkc CLKID_EFUSE>;
+};
+
 &ethmac {
 	reg = <0x0 0xc9410000 0x0 0x10000
 	       0x0 0xc8834540 0x0 0x4>;
Signature · 1 line
2.17.2
author reviewer
#7 lore raw

PATCH 4/4 nvmem: meson-efuse: add peripheral clock

In reply to Jerome Brunet

Get and enable the peripheral clock required by the efuse device. The driver has been handle to work without it so far because the clock was left enabled by default but it won't be the case soon.

---
 drivers/nvmem/meson-efuse.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
drivers/nvmem/meson-efuse.c +25 -0
index 40b9df1d030d..99372768446b 100644
@@ -14,6 +14,7 @@
  * more details.
  */
 
+#include <linux/clk.h>
 #include <linux/module.h>
 #include <linux/nvmem-provider.h>
 #include <linux/of.h>
@@ -46,7 +47,31 @@ static int meson_efuse_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct nvmem_device *nvmem;
 	struct nvmem_config *econfig;
+	struct clk *clk;
 	unsigned int size;
+	int ret;
+
+	clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(clk)) {
+		ret = PTR_ERR(clk);
+		if (ret != -EPROBE_DEFER)
+			dev_err(dev, "failed to get efuse gate");
+		return ret;
+	}
+
+	ret = clk_prepare_enable(clk);
+	if (ret) {
+		dev_err(dev, "failed to enable gate");
+		return ret;
+	}
+
+	ret = devm_add_action_or_reset(dev,
+				       (void(*)(void *))clk_disable_unprepare,
+				       clk);
+	if (ret) {
+		dev_err(dev, "failed to add disable callback");
+		return ret;
+	}
 
 	if (meson_sm_call(SM_EFUSE_USER_MAX, &size, 0, 0, 0, 0, 0) < 0) {
 		dev_err(dev, "failed to get max user");
Signature · 1 line
2.17.2
#8 lore raw

Re: [PATCH 4/4] nvmem: meson-efuse: add peripheral clock

Quoted 8 lines · Jerome Brunet

Get and enable the peripheral clock required by the efuse device. The driver has been handle to work without it so far because the clock was left enabled by default but it won't be the case soon.

---
  drivers/nvmem/meson-efuse.c | 25 +++++++++++++++++++++++++
  1 file changed, 25 insertions(+)

Applied, thanks,

--
Srini

#9 lore raw
In reply to Jerome Brunet
Quoted 11 lines · Jerome Brunet

The first change of this patchset just adds add error message in case of failure. If there is problem with the secure monitor, the SM_EFUSE_USER_MAX call will be first one to fail so it is better if it give us a clue to help debugging, instead af silently failing.

Next this series adds the peripheral clock missing in this driver. Like many other device in amlogic's SoC, the efuse requires a peripheral clock to operate. ATM, the clock controller has CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the bootloader left the clock enabled

Quoted 7 lines

At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a driver needs a clock, it needs to properly claim it.

Srinivas, Kevin,
The dts change needs to land before the actual driver change, to avoid breaking the efuse on our users. If there an agreement on this series, Kevin could you provide a tag to Srinivas ?

These are not fixes to any bugs/regressions, so its new material which can only go in next dev cycle!

I guess that should also address the patch sequencing issue!

Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.

thanks,
srini

Quoted 3 lines

Cheers
Jerome

author reviewer
#10 lore raw
Quoted 16 lines · Srinivas Kandagatla
Quoted 14 lines · Jerome Brunet

The first change of this patchset just adds add error message in case of failure. If there is problem with the secure monitor, the SM_EFUSE_USER_MAX call will be first one to fail so it is better if it give us a clue to help debugging, instead af silently failing.

Next this series adds the peripheral clock missing in this driver. Like many other device in amlogic's SoC, the efuse requires a peripheral clock to operate. ATM, the clock controller has CLK_IGNORE_UNUSED on this clock and we have been lucky enough that the bootloader left the clock enabled

At some point, we would like to remove those CLK_IGNORE_UNUSED, so if a driver needs a clock, it needs to properly claim it.

Quoted 8 lines
Quoted 4 lines

Srinivas, Kevin,
The dts change needs to land before the actual driver change, to avoid breaking the efuse on our users. If there an agreement on this series, Kevin could you provide a tag to Srinivas ?

These are not fixes to any bugs/regressions, so its new material which can only go in next dev cycle!

It is not fixing a regression, indeed. It fixing a problem in the driver itself, I think I described this above.

I don't expect this to go a fixes for 4.20. I was targeting next.

Quoted 1 line

I guess that should also address the patch sequencing issue!

Same issue still applies. If there is an agreement on this series, Patch 3 must land before patch 4 to avoid any problems for our users. I mentionning it because patch 3 is supposed to go through Kevin's tree, while the rest go through yours

Quoted 2 lines

Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.

I understand for patch 2, but don't really get it for patch 4 ?

Quoted 6 lines

thanks,
srini

Quoted 2 lines

Cheers
Jerome

#11 lore raw
Quoted 2 lines · jbrunet at baylibre.com
Quoted 1 line

Also I need ack from dt-maintaners on clk bindings to pick patch 2 and 4.

I understand for patch 2, but don't really get it for patch 4 ?

Patch 2 is bindings which what I need ack from DT maintainers. Patch 4 is driver changes related to patch 2, am okay with the changes!

So it makes sense for patch 2 & 4 to go together.
Once I get ack for 2, I can take 2 & 4 both.

thanks,
srini

Quoted 1 line