Devicetree
 help / color / mirror / Atom feed
* [PATCH v2 5/5] venus: register separate driver for firmware device
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot
In-Reply-To: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org>

A separate child device is added for video firmware.
This is needed to
[1] configure the firmware context bank with the desired SID.
[2] ensure that the iova for firmware region is from 0x0.

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
---
 .../devicetree/bindings/media/qcom,venus.txt       |  8 +++-
 drivers/media/platform/qcom/venus/core.c           | 48 +++++++++++++++++++---
 drivers/media/platform/qcom/venus/firmware.c       | 20 ++++++++-
 drivers/media/platform/qcom/venus/firmware.h       |  2 +
 4 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
index 00d0d1b..701cbe8 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus.txt
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -53,7 +53,7 @@
 
 * Subnodes
 The Venus video-codec node must contain two subnodes representing
-video-decoder and video-encoder.
+video-decoder and video-encoder, one optional firmware subnode.
 
 Every of video-encoder or video-decoder subnode should have:
 
@@ -79,6 +79,8 @@ Every of video-encoder or video-decoder subnode should have:
 		    power domain which is responsible for collapsing
 		    and restoring power to the subcore.
 
+The firmware sub node must contain the iommus specifiers for ARM9.
+
 * An Example
 	video-codec@1d00000 {
 		compatible = "qcom,msm8916-venus";
@@ -105,4 +107,8 @@ Every of video-encoder or video-decoder subnode should have:
 			clock-names = "core";
 			power-domains = <&mmcc VENUS_CORE1_GDSC>;
 		};
+		venus-firmware {
+			compatible = "qcom,venus-firmware-no-tz";
+			iommus = <&apps_smmu 0x10b2 0x0>;
+		}
 	};
diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 101612b..5cfb3c2 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -179,6 +179,19 @@ static u32 to_v4l2_codec_type(u32 codec)
 	}
 }
 
+static int store_firmware_dev(struct device *dev, void *data)
+{
+	struct venus_core *core = data;
+
+	if (!core)
+		return -EINVAL;
+
+	if (of_device_is_compatible(dev->of_node, "qcom,venus-firmware-no-tz"))
+		core->fw.dev = dev;
+
+	return 0;
+}
+
 static int venus_enumerate_codecs(struct venus_core *core, u32 type)
 {
 	const struct hfi_inst_ops dummy_ops = {};
@@ -279,6 +292,13 @@ static int venus_probe(struct platform_device *pdev)
 	if (ret < 0)
 		goto err_runtime_disable;
 
+	ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+	if (ret)
+		goto err_runtime_disable;
+
+	/* Attempt to store firmware device */
+	device_for_each_child(dev, core, store_firmware_dev);
+
 	ret = venus_boot(core);
 	if (ret)
 		goto err_runtime_disable;
@@ -303,10 +323,6 @@ static int venus_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_core_deinit;
 
-	ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
-	if (ret)
-		goto err_dev_unregister;
-
 	ret = pm_runtime_put_sync(dev);
 	if (ret)
 		goto err_dev_unregister;
@@ -483,7 +499,29 @@ static __maybe_unused int venus_runtime_resume(struct device *dev)
 		.pm = &venus_pm_ops,
 	},
 };
-module_platform_driver(qcom_venus_driver);
+
+static int __init venus_init(void)
+{
+	int ret;
+
+	ret = platform_driver_register(&qcom_video_firmware_driver);
+	if (ret)
+		return ret;
+
+	ret = platform_driver_register(&qcom_venus_driver);
+	if (ret)
+		platform_driver_unregister(&qcom_video_firmware_driver);
+
+	return ret;
+}
+module_init(venus_init);
+
+static void __exit venus_exit(void)
+{
+	platform_driver_unregister(&qcom_venus_driver);
+	platform_driver_unregister(&qcom_video_firmware_driver);
+}
+module_exit(venus_exit);
 
 MODULE_ALIAS("platform:qcom-venus");
 MODULE_DESCRIPTION("Qualcomm Venus video encoder and decoder driver");
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index 058d544..ed29d10 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -12,6 +12,7 @@
  *
  */
 
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/device.h>
 #include <linux/firmware.h>
@@ -124,7 +125,7 @@ static int venus_load_fw(struct device *dev, const char *fwname,
 	}
 	if (qcom_scm_is_available())
 		ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va,
-				*mem_phys, *mem_size);
+				*mem_phys, *mem_size, NULL);
 	else
 		ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
 				mem_va, *mem_phys, *mem_size, NULL);
@@ -243,3 +244,20 @@ int venus_shutdown(struct venus_core *core)
 
 	return ret;
 }
+
+static const struct of_device_id firmware_dt_match[] = {
+	{ .compatible = "qcom,venus-firmware-no-tz" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, firmware_dt_match);
+
+struct platform_driver qcom_video_firmware_driver = {
+	.driver = {
+			.name = "qcom-video-firmware",
+			.of_match_table = firmware_dt_match,
+	},
+};
+
+MODULE_ALIAS("platform:qcom-video-firmware");
+MODULE_DESCRIPTION("Qualcomm Venus firmware driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/platform/qcom/venus/firmware.h b/drivers/media/platform/qcom/venus/firmware.h
index 67fdd89..23c0409 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -21,6 +21,8 @@
 
 struct device;
 
+extern struct platform_driver qcom_video_firmware_driver;
+
 int venus_boot(struct venus_core *core);
 int venus_shutdown(struct venus_core *core);
 int venus_set_hw_state(enum tzbsp_video_state, struct venus_core *core);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* [PATCH v2 4/5] media: venus: add no TZ boot and shutdown routine
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot
In-Reply-To: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org>

Video hardware is mainly comprised of vcodec subsystem
and video control subsystem. Video control has ARM9 which
executes the video firmware instructions whereas vcodec
does the video frame processing.
This change adds support to load the video firmware and
bring ARM9 out of reset for platforms which does not
have trustzone.

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
---
 drivers/media/platform/qcom/venus/core.c     |  6 +-
 drivers/media/platform/qcom/venus/core.h     |  5 ++
 drivers/media/platform/qcom/venus/firmware.c | 86 ++++++++++++++++++++++++++--
 drivers/media/platform/qcom/venus/firmware.h |  7 ++-
 4 files changed, 94 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 9a95f9a..101612b 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -76,7 +76,7 @@ static void venus_sys_error_handler(struct work_struct *work)
 	hfi_core_deinit(core, true);
 	hfi_destroy(core);
 	mutex_lock(&core->lock);
-	venus_shutdown(core->dev);
+	venus_shutdown(core);
 
 	pm_runtime_put_sync(core->dev);
 
@@ -318,7 +318,7 @@ static int venus_probe(struct platform_device *pdev)
 err_core_deinit:
 	hfi_core_deinit(core, false);
 err_venus_shutdown:
-	venus_shutdown(dev);
+	venus_shutdown(core);
 err_runtime_disable:
 	pm_runtime_set_suspended(dev);
 	pm_runtime_disable(dev);
@@ -339,7 +339,7 @@ static int venus_remove(struct platform_device *pdev)
 	WARN_ON(ret);
 
 	hfi_destroy(core);
-	venus_shutdown(dev);
+	venus_shutdown(core);
 	of_platform_depopulate(dev);
 
 	pm_runtime_put_sync(dev);
diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index e7bfb63..f04e25e 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -85,6 +85,10 @@ struct venus_caps {
 	bool valid;
 };
 
+struct video_firmware {
+	struct device *dev;
+	struct iommu_domain *iommu_domain;
+};
 /**
  * struct venus_core - holds core parameters valid for all instances
  *
@@ -129,6 +133,7 @@ struct venus_core {
 	struct device *dev;
 	struct device *dev_dec;
 	struct device *dev_enc;
+	struct video_firmware fw;
 	struct mutex lock;
 	struct list_head instances;
 	atomic_t insts_count;
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index cb7f48ef..058d544 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -12,8 +12,10 @@
  *
  */
 
+#include <linux/platform_device.h>
 #include <linux/device.h>
 #include <linux/firmware.h>
+#include <linux/iommu.h>
 #include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
@@ -27,9 +29,6 @@
 #include "firmware.h"
 #include "hfi_venus_io.h"
 
-#define VENUS_PAS_ID			9
-#define VENUS_FW_MEM_SIZE		(6 * SZ_1M)
-
 static void venus_reset_hw(struct venus_core *core)
 {
 	void __iomem *reg_base = core->base;
@@ -125,7 +124,7 @@ static int venus_load_fw(struct device *dev, const char *fwname,
 	}
 	if (qcom_scm_is_available())
 		ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va,
-				*mem_phys, *mem_size, NULL);
+				*mem_phys, *mem_size);
 	else
 		ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
 				mem_va, *mem_phys, *mem_size, NULL);
@@ -136,6 +135,77 @@ static int venus_load_fw(struct device *dev, const char *fwname,
 	memunmap(mem_va);
 	return ret;
 }
+
+int venus_boot_noTZ(struct venus_core *core, phys_addr_t mem_phys,
+							size_t mem_size)
+{
+	struct iommu_domain *iommu;
+	struct device *dev;
+	int ret;
+
+	if (!core->fw.dev)
+		return -EPROBE_DEFER;
+
+	dev = core->fw.dev;
+
+	iommu = iommu_domain_alloc(&platform_bus_type);
+	if (!iommu) {
+		dev_err(dev, "Failed to allocate iommu domain\n");
+		return -ENOMEM;
+	}
+
+	ret = iommu_attach_device(iommu, dev);
+	if (ret) {
+		dev_err(dev, "could not attach device\n");
+		goto err_attach;
+	}
+
+	ret = iommu_map(iommu, VENUS_FW_START_ADDR, mem_phys, mem_size,
+			IOMMU_READ|IOMMU_WRITE|IOMMU_PRIV);
+	if (ret) {
+		dev_err(dev, "could not map video firmware region\n");
+		goto err_map;
+	}
+	core->fw.iommu_domain = iommu;
+	venus_reset_hw(core);
+
+	return 0;
+
+err_map:
+	iommu_detach_device(iommu, dev);
+err_attach:
+	iommu_domain_free(iommu);
+	return ret;
+}
+
+int venus_shutdown_noTZ(struct venus_core *core)
+{
+	struct iommu_domain *iommu;
+	size_t unmapped = 0;
+	u32 reg;
+	struct device *dev = core->fw.dev;
+	void __iomem *reg_base = core->base;
+
+	/* Assert the reset to ARM9 */
+	reg = readl_relaxed(reg_base + WRAPPER_A9SS_SW_RESET);
+	reg |= BIT(4);
+	writel_relaxed(reg, reg_base + WRAPPER_A9SS_SW_RESET);
+
+	/* Make sure reset is asserted before the mapping is removed */
+	mb();
+
+	iommu = core->fw.iommu_domain;
+
+	unmapped = iommu_unmap(iommu, VENUS_FW_START_ADDR, VENUS_FW_MEM_SIZE);
+	if (unmapped != VENUS_FW_MEM_SIZE)
+		dev_err(dev, "failed to unmap firmware\n");
+
+	iommu_detach_device(iommu, dev);
+	iommu_domain_free(iommu);
+
+	return 0;
+}
+
 int venus_boot(struct venus_core *core)
 {
 	phys_addr_t mem_phys;
@@ -156,16 +226,20 @@ int venus_boot(struct venus_core *core)
 
 	if (qcom_scm_is_available())
 		ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+	else
+		ret = venus_boot_noTZ(core, mem_phys, mem_size);
 
 	return ret;
 }
-EXPORT_SYMBOL_GPL(venus_boot);
 
-int venus_shutdown(struct device *dev)
+int venus_shutdown(struct venus_core *core)
 {
 	int ret = 0;
 
 	if (qcom_scm_is_available())
 		ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
+	else
+		ret = venus_shutdown_noTZ(core);
+
 	return ret;
 }
diff --git a/drivers/media/platform/qcom/venus/firmware.h b/drivers/media/platform/qcom/venus/firmware.h
index 0916826..67fdd89 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -14,10 +14,15 @@
 #ifndef __VENUS_FIRMWARE_H__
 #define __VENUS_FIRMWARE_H__
 
+#define VENUS_PAS_ID			9
+#define VENUS_FW_START_ADDR		0x0
+#define VENUS_FW_MEM_SIZE		(6 * SZ_1M)
+#define VENUS_MAX_MEM_REGION	0xE0000000
+
 struct device;
 
 int venus_boot(struct venus_core *core);
-int venus_shutdown(struct device *dev);
+int venus_shutdown(struct venus_core *core);
 int venus_set_hw_state(enum tzbsp_video_state, struct venus_core *core);
 
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* [PATCH v2 3/5] venus: add check to make scm calls
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot
In-Reply-To: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org>

Split the boot api into firmware load and hardware
boot. Also add the checks to invoke scm calls only
if the platform has the required support.

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
---
 drivers/media/platform/qcom/venus/core.c     |  4 +-
 drivers/media/platform/qcom/venus/firmware.c | 65 ++++++++++++++++++----------
 drivers/media/platform/qcom/venus/firmware.h |  2 +-
 3 files changed, 45 insertions(+), 26 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
index 1308488..9a95f9a 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -84,7 +84,7 @@ static void venus_sys_error_handler(struct work_struct *work)
 
 	pm_runtime_get_sync(core->dev);
 
-	ret |= venus_boot(core->dev, core->res->fwname);
+	ret |= venus_boot(core);
 
 	ret |= hfi_core_resume(core, true);
 
@@ -279,7 +279,7 @@ static int venus_probe(struct platform_device *pdev)
 	if (ret < 0)
 		goto err_runtime_disable;
 
-	ret = venus_boot(dev, core->res->fwname);
+	ret = venus_boot(core);
 	if (ret)
 		goto err_runtime_disable;
 
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index b4664ed..cb7f48ef 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -81,40 +81,35 @@ int venus_set_hw_state(enum tzbsp_video_state state, struct venus_core *core)
 }
 EXPORT_SYMBOL_GPL(venus_set_hw_state);
 
-int venus_boot(struct device *dev, const char *fwname)
+static int venus_load_fw(struct device *dev, const char *fwname,
+		phys_addr_t *mem_phys, size_t *mem_size)
 {
 	const struct firmware *mdt;
 	struct device_node *node;
-	phys_addr_t mem_phys;
 	struct resource r;
 	ssize_t fw_size;
-	size_t mem_size;
 	void *mem_va;
 	int ret;
 
-	if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
-		return -EPROBE_DEFER;
-
 	node = of_parse_phandle(dev->of_node, "memory-region", 0);
 	if (!node) {
 		dev_err(dev, "no memory-region specified\n");
 		return -EINVAL;
 	}
-
 	ret = of_address_to_resource(node, 0, &r);
 	if (ret)
 		return ret;
 
-	mem_phys = r.start;
-	mem_size = resource_size(&r);
+	*mem_phys = r.start;
+	*mem_size = resource_size(&r);
 
-	if (mem_size < VENUS_FW_MEM_SIZE)
+	if (*mem_size < VENUS_FW_MEM_SIZE)
 		return -EINVAL;
 
-	mem_va = memremap(r.start, mem_size, MEMREMAP_WC);
+	mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
 	if (!mem_va) {
 		dev_err(dev, "unable to map memory region: %pa+%zx\n",
-			&r.start, mem_size);
+			&r.start, *mem_size);
 		return -ENOMEM;
 	}
 
@@ -128,25 +123,49 @@ int venus_boot(struct device *dev, const char *fwname)
 		release_firmware(mdt);
 		goto err_unmap;
 	}
-
-	ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
-			    mem_size);
+	if (qcom_scm_is_available())
+		ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va,
+				*mem_phys, *mem_size, NULL);
+	else
+		ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
+				mem_va, *mem_phys, *mem_size, NULL);
 
 	release_firmware(mdt);
 
-	if (ret)
-		goto err_unmap;
-
-	ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
-	if (ret)
-		goto err_unmap;
-
 err_unmap:
 	memunmap(mem_va);
 	return ret;
 }
+int venus_boot(struct venus_core *core)
+{
+	phys_addr_t mem_phys;
+	size_t mem_size;
+	int ret;
+	struct device *dev;
+
+	if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER))
+		return -EPROBE_DEFER;
+
+	dev = core->dev;
+
+	ret = venus_load_fw(dev, core->res->fwname, &mem_phys, &mem_size);
+	if (ret) {
+		dev_err(dev, "fail to load video firmware\n");
+		return -EINVAL;
+	}
+
+	if (qcom_scm_is_available())
+		ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(venus_boot);
 
 int venus_shutdown(struct device *dev)
 {
-	return qcom_scm_pas_shutdown(VENUS_PAS_ID);
+	int ret = 0;
+
+	if (qcom_scm_is_available())
+		ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
+	return ret;
 }
diff --git a/drivers/media/platform/qcom/venus/firmware.h b/drivers/media/platform/qcom/venus/firmware.h
index 1336729..0916826 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -16,7 +16,7 @@
 
 struct device;
 
-int venus_boot(struct device *dev, const char *fwname);
+int venus_boot(struct venus_core *core);
 int venus_shutdown(struct device *dev);
 int venus_set_hw_state(enum tzbsp_video_state, struct venus_core *core);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* [PATCH v2 2/5] media: venus: add a routine to set venus state
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot
In-Reply-To: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org>

Add a new routine which abstracts the TZ call to
set the video hardware state.

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
---
 drivers/media/platform/qcom/venus/core.h      |  5 +++++
 drivers/media/platform/qcom/venus/firmware.c  | 28 +++++++++++++++++++++++++++
 drivers/media/platform/qcom/venus/firmware.h  |  1 +
 drivers/media/platform/qcom/venus/hfi_venus.c | 13 ++++---------
 4 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h
index 85e66e2..e7bfb63 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -35,6 +35,11 @@ struct reg_val {
 	u32 value;
 };
 
+enum tzbsp_video_state {
+	TZBSP_VIDEO_SUSPEND = 0,
+	TZBSP_VIDEO_RESUME
+};
+
 struct venus_resources {
 	u64 dma_mask;
 	const struct freq_tbl *freq_tbl;
diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index 7d89b5a..b4664ed 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -53,6 +53,34 @@ static void venus_reset_hw(struct venus_core *core)
 	/* Bring Arm9 out of reset */
 	writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET);
 }
+
+int venus_set_hw_state(enum tzbsp_video_state state, struct venus_core *core)
+{
+	int ret;
+	struct device *dev = core->dev;
+	void __iomem *reg_base = core->base;
+
+	switch (state) {
+	case TZBSP_VIDEO_SUSPEND:
+		if (qcom_scm_is_available())
+			ret = qcom_scm_set_remote_state(TZBSP_VIDEO_SUSPEND, 0);
+		else
+			writel_relaxed(1, reg_base + WRAPPER_A9SS_SW_RESET);
+		break;
+	case TZBSP_VIDEO_RESUME:
+		if (qcom_scm_is_available())
+			ret = qcom_scm_set_remote_state(TZBSP_VIDEO_RESUME, 0);
+		else
+			venus_reset_hw(core);
+		break;
+	default:
+		dev_err(dev, "invalid state\n");
+		break;
+	}
+	return ret;
+}
+EXPORT_SYMBOL_GPL(venus_set_hw_state);
+
 int venus_boot(struct device *dev, const char *fwname)
 {
 	const struct firmware *mdt;
diff --git a/drivers/media/platform/qcom/venus/firmware.h b/drivers/media/platform/qcom/venus/firmware.h
index 428efb5..1336729 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -18,5 +18,6 @@
 
 int venus_boot(struct device *dev, const char *fwname);
 int venus_shutdown(struct device *dev);
+int venus_set_hw_state(enum tzbsp_video_state, struct venus_core *core);
 
 #endif
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c b/drivers/media/platform/qcom/venus/hfi_venus.c
index f61d34b..797a9f5 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -19,7 +19,6 @@
 #include <linux/interrupt.h>
 #include <linux/iopoll.h>
 #include <linux/kernel.h>
-#include <linux/qcom_scm.h>
 #include <linux/slab.h>
 
 #include "core.h"
@@ -27,6 +26,7 @@
 #include "hfi_msgs.h"
 #include "hfi_venus.h"
 #include "hfi_venus_io.h"
+#include "firmware.h"
 
 #define HFI_MASK_QHDR_TX_TYPE		0xff000000
 #define HFI_MASK_QHDR_RX_TYPE		0x00ff0000
@@ -55,11 +55,6 @@
 #define IFACEQ_VAR_LARGE_PKT_SIZE	512
 #define IFACEQ_VAR_HUGE_PKT_SIZE	(1024 * 12)
 
-enum tzbsp_video_state {
-	TZBSP_VIDEO_STATE_SUSPEND = 0,
-	TZBSP_VIDEO_STATE_RESUME
-};
-
 struct hfi_queue_table_header {
 	u32 version;
 	u32 size;
@@ -574,7 +569,7 @@ static int venus_power_off(struct venus_hfi_device *hdev)
 	if (!hdev->power_enabled)
 		return 0;
 
-	ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
+	ret = venus_set_hw_state(TZBSP_VIDEO_SUSPEND, hdev->core);
 	if (ret)
 		return ret;
 
@@ -594,7 +589,7 @@ static int venus_power_on(struct venus_hfi_device *hdev)
 	if (hdev->power_enabled)
 		return 0;
 
-	ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_RESUME, 0);
+	ret = venus_set_hw_state(TZBSP_VIDEO_RESUME, hdev->core);
 	if (ret)
 		goto err;
 
@@ -607,7 +602,7 @@ static int venus_power_on(struct venus_hfi_device *hdev)
 	return 0;
 
 err_suspend:
-	qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
+	venus_set_hw_state(TZBSP_VIDEO_SUSPEND, hdev->core);
 err:
 	hdev->power_enabled = false;
 	return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* [PATCH v2 1/5] media: venus: add a routine to reset ARM9
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot
In-Reply-To: <1527884768-22392-1-git-send-email-vgarodia@codeaurora.org>

Add a new routine to reset the ARM9 and brings it
out of reset. This is in preparation to add PIL
functionality in venus driver.

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
---
 drivers/media/platform/qcom/venus/firmware.c     | 26 ++++++++++++++++++++++++
 drivers/media/platform/qcom/venus/hfi_venus_io.h |  5 +++++
 2 files changed, 31 insertions(+)

diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c
index 521d4b3..7d89b5a 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -14,6 +14,7 @@
 
 #include <linux/device.h>
 #include <linux/firmware.h>
+#include <linux/delay.h>
 #include <linux/kernel.h>
 #include <linux/io.h>
 #include <linux/of.h>
@@ -22,11 +23,36 @@
 #include <linux/sizes.h>
 #include <linux/soc/qcom/mdt_loader.h>
 
+#include "core.h"
 #include "firmware.h"
+#include "hfi_venus_io.h"
 
 #define VENUS_PAS_ID			9
 #define VENUS_FW_MEM_SIZE		(6 * SZ_1M)
 
+static void venus_reset_hw(struct venus_core *core)
+{
+	void __iomem *reg_base = core->base;
+
+	writel(0, reg_base + WRAPPER_FW_START_ADDR);
+	writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_FW_END_ADDR);
+	writel(0, reg_base + WRAPPER_CPA_START_ADDR);
+	writel(VENUS_FW_MEM_SIZE, reg_base + WRAPPER_CPA_END_ADDR);
+	writel(0x0, reg_base + WRAPPER_CPU_CGC_DIS);
+	writel(0x0, reg_base + WRAPPER_CPU_CLOCK_CONFIG);
+
+	/* Make sure all register writes are committed. */
+	mb();
+
+	/*
+	 * Need to wait 10 cycles of internal clocks before bringing ARM9
+	 * out of reset.
+	 */
+	udelay(1);
+
+	/* Bring Arm9 out of reset */
+	writel_relaxed(0, reg_base + WRAPPER_A9SS_SW_RESET);
+}
 int venus_boot(struct device *dev, const char *fwname)
 {
 	const struct firmware *mdt;
diff --git a/drivers/media/platform/qcom/venus/hfi_venus_io.h b/drivers/media/platform/qcom/venus/hfi_venus_io.h
index 76f4793..39afa5d 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus_io.h
+++ b/drivers/media/platform/qcom/venus/hfi_venus_io.h
@@ -109,6 +109,11 @@
 #define WRAPPER_CPU_CGC_DIS			(WRAPPER_BASE + 0x2010)
 #define WRAPPER_CPU_STATUS			(WRAPPER_BASE + 0x2014)
 #define WRAPPER_SW_RESET			(WRAPPER_BASE + 0x3000)
+#define WRAPPER_CPA_START_ADDR		(WRAPPER_BASE + 0x1020)
+#define WRAPPER_CPA_END_ADDR		(WRAPPER_BASE + 0x1024)
+#define WRAPPER_FW_START_ADDR		(WRAPPER_BASE + 0x1028)
+#define WRAPPER_FW_END_ADDR			(WRAPPER_BASE + 0x102C)
+#define WRAPPER_A9SS_SW_RESET		(WRAPPER_BASE + 0x3000)
 
 /* Venus 4xx */
 #define WRAPPER_VCODEC0_MMCC_POWER_STATUS	(WRAPPER_BASE + 0x90)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply related

* [PATCH v2 0/5] Venus updates - PIL
From: Vikash Garodia @ 2018-06-01 20:26 UTC (permalink / raw)
  To: hverkuil, mchehab, robh, mark.rutland, andy.gross,
	bjorn.andersson, stanimir.varbanov
  Cc: linux-media, linux-kernel, linux-arm-msm, linux-soc, devicetree,
	vgarodia, acourbot

Hello,

Here is v2 with following comments addressed:

* drop 1/4 patch from v1 and use relevant api to load
  firmware without PAS.
* add some details on ARM9 role in video hardware.
* abstract scm calls to set hardware state.
* remove setting aperture range for firmware and vcodec
  context banks.
* add misc code review comments related to return
  handling, unwanted cast, etc.

Comments are welcome!

Vikash Garodia (5):
  media: venus: add a routine to reset ARM9
  media: venus: add a routine to set venus state
  venus: add check to make scm calls
  media: venus: add no TZ boot and shutdown routine
  venus: register separate driver for firmware device

 .../devicetree/bindings/media/qcom,venus.txt       |   8 +-
 drivers/media/platform/qcom/venus/core.c           |  58 +++++-
 drivers/media/platform/qcom/venus/core.h           |  10 +
 drivers/media/platform/qcom/venus/firmware.c       | 217 ++++++++++++++++++---
 drivers/media/platform/qcom/venus/firmware.h       |  12 +-
 drivers/media/platform/qcom/venus/hfi_venus.c      |  13 +-
 drivers/media/platform/qcom/venus/hfi_venus_io.h   |   5 +
 7 files changed, 275 insertions(+), 48 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH] gpio-rcar: document R8A77980 bindings
From: Sergei Shtylyov @ 2018-06-01 20:13 UTC (permalink / raw)
  To: Linus Walleij, Rob Herring, linux-gpio, devicetree
  Cc: Mark Rutland, Sergei Shtylyov

Renesas R-Car V3H (R8A77980) SoC also has the R-Car gen3 compatible GPIO
controllers, so document the SoC specific bindings.

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

---
The patch is against the 'devel' branch of Linus Walleij's 'linux-gpio.git'
repo.

 Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt |    1 +
 1 file changed, 1 insertion(+)

Index: linux-gpio/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
===================================================================
--- linux-gpio.orig/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ linux-gpio/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -17,6 +17,7 @@ Required Properties:
     - "renesas,gpio-r8a7796": for R8A7796 (R-Car M3-W) compatible GPIO controller.
     - "renesas,gpio-r8a77965": for R8A77965 (R-Car M3-N) compatible GPIO controller.
     - "renesas,gpio-r8a77970": for R8A77970 (R-Car V3M) compatible GPIO controller.
+    - "renesas,gpio-r8a77980": for R8A77980 (R-Car V3H) compatible GPIO controller.
     - "renesas,gpio-r8a77990": for R8A77990 (R-Car E3) compatible GPIO controller.
     - "renesas,gpio-r8a77995": for R8A77995 (R-Car D3) compatible GPIO controller.
     - "renesas,rcar-gen1-gpio": for a generic R-Car Gen1 GPIO controller.

^ permalink raw reply

* Re: [RFC PATCH 2/8] coresight: Fix remote endpoint parsing
From: Mathieu Poirier @ 2018-06-01 19:46 UTC (permalink / raw)
  To: Suzuki K Poulose
  Cc: linux-arm-kernel, Sudeep Holla, Rob Herring, Mark Rutland,
	Frank Rowand, Matt Sealey, Charles Garcia-Tobin, John Horley,
	Mike Leach, coresight, Linux Kernel Mailing List, devicetree
In-Reply-To: <20180601193837.GB9838@xps15>

On 1 June 2018 at 13:38, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On Fri, Jun 01, 2018 at 02:16:01PM +0100, Suzuki K Poulose wrote:
>> When parsing the remote endpoint of an output port, we do :
>>      rport = of_graph_get_remote_port(ep);
>>      rparent = of_graph_get_remote_port_parent(ep);
>>
>> and then parse the "remote_port" as if it was the remote endpoint,
>> which is wrong. The code worked fine because we used endpoint number
>> as the port number. Let us fix it and optimise a bit as:
>>
>>      remote_ep = of_graph_get_remote_endpoint(ep);
>>      if (remote_ep)
>>         remote_parent = of_graph_get_port_parent(remote_ep);
>>
>> and then, parse the remote_ep for the port/endpoint details.
>>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>  drivers/hwtracing/coresight/of_coresight.c | 19 ++++++++++---------
>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
>> index 7c37544..e0deab0 100644
>> --- a/drivers/hwtracing/coresight/of_coresight.c
>> +++ b/drivers/hwtracing/coresight/of_coresight.c
>> @@ -128,7 +128,7 @@ of_get_coresight_platform_data(struct device *dev,
>>       struct device *rdev;
>>       struct device_node *ep = NULL;
>>       struct device_node *rparent = NULL;
>> -     struct device_node *rport = NULL;
>> +     struct device_node *rep = NULL;
>>
>>       pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>>       if (!pdata)
>> @@ -169,16 +169,17 @@ of_get_coresight_platform_data(struct device *dev,
>>                       pdata->outports[i] = endpoint.port;
>>
>>                       /*
>> -                      * Get a handle on the remote port and parent
>> -                      * attached to it.
>> +                      * Get a handle on the remote endpoint and the device
>> +                      * it is attached to.
>>                        */
>> -                     rparent = of_graph_get_remote_port_parent(ep);
>> -                     rport = of_graph_get_remote_port(ep);
>> -
>> -                     if (!rparent || !rport)
>> +                     rep = of_graph_get_remote_endpoint(ep);
>> +                     if (!rep)
>> +                             continue;
>> +                     rparent = of_graph_get_port_parent(rep);
>> +                     if (!rparent)
>>                               continue;
>>
>> -                     if (of_graph_parse_endpoint(rport, &rendpoint))
>> +                     if (of_graph_parse_endpoint(rep, &rendpoint))
>>                               continue;
>
> You are correct and I'm out to lunch.
>
>>
>>                       rdev = of_coresight_get_endpoint_device(rparent);
>> @@ -186,7 +187,7 @@ of_get_coresight_platform_data(struct device *dev,
>>                               return ERR_PTR(-EPROBE_DEFER);
>>
>>                       pdata->child_names[i] = dev_name(rdev);
>> -                     pdata->child_ports[i] = rendpoint.id;
>> +                     pdata->child_ports[i] = rendpoint.port;
>
> You need to do a of_node_put() here for both rep and rparent.

Same thing for the "continue" and error condition above.

>
>>
>>                       i++;
>>               } while (ep);
>> --
>> 2.7.4
>>

^ permalink raw reply

* Re: [PATCH v6 05/13] clk: imx7d: reset parent for mipi csi root
From: Stephen Boyd @ 2018-06-01 19:41 UTC (permalink / raw)
  To: Philipp Zabel, Rob Herring, Steve Longerbeam, mchehab,
	sakari.ailus
  Cc: devel, devicetree, Greg Kroah-Hartman, Ryan Harkin,
	Rui Miguel Silva, Fabio Estevam, Shawn Guo, linux-clk,
	linux-media
In-Reply-To: <20180522145245.3143-6-rui.silva@linaro.org>

Quoting Rui Miguel Silva (2018-05-22 07:52:37)
> To guarantee that we do not get Overflow in image FIFO the outer bandwidth has
> to be faster than inputer bandwidth. For that it must be possible to set a
> faster frequency clock. So set new parent to sys_pfd3 clock for the mipi csi
> block.
> 
> Acked-by: Shawn Guo <shawnguo@kernel.org>
> Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH v6 04/13] clk: imx7d: fix mipi dphy div parent
From: Stephen Boyd @ 2018-06-01 19:41 UTC (permalink / raw)
  To: Philipp Zabel, Rob Herring, Steve Longerbeam, mchehab,
	sakari.ailus
  Cc: devel, devicetree, Greg Kroah-Hartman, Ryan Harkin,
	Rui Miguel Silva, Fabio Estevam, Shawn Guo, linux-clk,
	linux-media
In-Reply-To: <20180522145245.3143-5-rui.silva@linaro.org>

Quoting Rui Miguel Silva (2018-05-22 07:52:36)
> Fix the mipi dphy root divider to mipi_dphy_pre_div, this would remove a orphan
> clock and set the correct parent.
> 
> before:
> cat clk_orphan_summary
>                                  enable  prepare  protect
>    clock                          count    count    count        rate   accuracy   phase
> ----------------------------------------------------------------------------------------

Applied to clk-next

^ permalink raw reply

* Re: [RFC PATCH 2/8] coresight: Fix remote endpoint parsing
From: Mathieu Poirier @ 2018-06-01 19:38 UTC (permalink / raw)
  To: Suzuki K Poulose
  Cc: linux-arm-kernel, sudeep.holla, robh, mark.rutland, frowand.list,
	matt.sealey, charles.garcia-tobin, john.horley, mike.leach,
	coresight, linux-kernel, devicetree
In-Reply-To: <1527858967-16047-3-git-send-email-suzuki.poulose@arm.com>

On Fri, Jun 01, 2018 at 02:16:01PM +0100, Suzuki K Poulose wrote:
> When parsing the remote endpoint of an output port, we do :
>      rport = of_graph_get_remote_port(ep);
>      rparent = of_graph_get_remote_port_parent(ep);
> 
> and then parse the "remote_port" as if it was the remote endpoint,
> which is wrong. The code worked fine because we used endpoint number
> as the port number. Let us fix it and optimise a bit as:
> 
>      remote_ep = of_graph_get_remote_endpoint(ep);
>      if (remote_ep)
>         remote_parent = of_graph_get_port_parent(remote_ep);
> 
> and then, parse the remote_ep for the port/endpoint details.
> 
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  drivers/hwtracing/coresight/of_coresight.c | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/hwtracing/coresight/of_coresight.c b/drivers/hwtracing/coresight/of_coresight.c
> index 7c37544..e0deab0 100644
> --- a/drivers/hwtracing/coresight/of_coresight.c
> +++ b/drivers/hwtracing/coresight/of_coresight.c
> @@ -128,7 +128,7 @@ of_get_coresight_platform_data(struct device *dev,
>  	struct device *rdev;
>  	struct device_node *ep = NULL;
>  	struct device_node *rparent = NULL;
> -	struct device_node *rport = NULL;
> +	struct device_node *rep = NULL;
>  
>  	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>  	if (!pdata)
> @@ -169,16 +169,17 @@ of_get_coresight_platform_data(struct device *dev,
>  			pdata->outports[i] = endpoint.port;
>  
>  			/*
> -			 * Get a handle on the remote port and parent
> -			 * attached to it.
> +			 * Get a handle on the remote endpoint and the device
> +			 * it is attached to.
>  			 */
> -			rparent = of_graph_get_remote_port_parent(ep);
> -			rport = of_graph_get_remote_port(ep);
> -
> -			if (!rparent || !rport)
> +			rep = of_graph_get_remote_endpoint(ep);
> +			if (!rep)
> +				continue;
> +			rparent = of_graph_get_port_parent(rep);
> +			if (!rparent)
>  				continue;
>  
> -			if (of_graph_parse_endpoint(rport, &rendpoint))
> +			if (of_graph_parse_endpoint(rep, &rendpoint))
>  				continue;

You are correct and I'm out to lunch.

>  
>  			rdev = of_coresight_get_endpoint_device(rparent);
> @@ -186,7 +187,7 @@ of_get_coresight_platform_data(struct device *dev,
>  				return ERR_PTR(-EPROBE_DEFER);
>  
>  			pdata->child_names[i] = dev_name(rdev);
> -			pdata->child_ports[i] = rendpoint.id;
> +			pdata->child_ports[i] = rendpoint.port;

You need to do a of_node_put() here for both rep and rparent.

>  
>  			i++;
>  		} while (ep);
> -- 
> 2.7.4
> 

^ permalink raw reply

* Re: [PATCH v2 5/6] soc: qcom: rpmh powerdomain driver
From: David Collins @ 2018-06-01 19:19 UTC (permalink / raw)
  To: Rajendra Nayak, viresh.kumar, sboyd, andy.gross, ulf.hansson
  Cc: devicetree, linux-arm-msm, linux-kernel, Lina Iyer
In-Reply-To: <6817acaf-9a68-5cd5-4dd0-ebe12a9aa057@codeaurora.org>

Hello Rajendra,

On 06/01/2018 01:48 AM, Rajendra Nayak wrote:
> On 05/26/2018 06:38 AM, David Collins wrote:
>>
>>> +	[1] = &sdm845_mx,
>>> +	[2] = &sdm845_mx_ao,
>>> +	[3] = &sdm845_cx,
>>> +	[4] = &sdm845_cx_ao,
>>> +	[5] = &sdm845_lmx,
>>> +	[6] = &sdm845_lcx,
>>> +	[7] = &sdm845_gfx,
>>> +	[8] = &sdm845_mss,
>>> +};
>>> +
>>> +static const struct rpmhpd_desc sdm845_desc = {
>>> +	.rpmhpds = sdm845_rpmhpds,
>>> +	.num_pds = ARRAY_SIZE(sdm845_rpmhpds),
>>> +};
>>> +
>>> +static const struct of_device_id rpmhpd_match_table[] = {
>>> +	{ .compatible = "qcom,sdm845-rpmhpd", .data = &sdm845_desc },
>>> +	{ }
>>> +};
>>> +MODULE_DEVICE_TABLE(of, rpmhpd_match_table);
>>> +
>>> +static int rpmhpd_send_corner(struct rpmhpd *pd, int state, unsigned int corner)
>>> +{
>>> +	struct tcs_cmd cmd = {
>>> +		.addr = pd->addr,
>>> +		.data = corner,
>>> +	};
>>> +
>>> +	return rpmh_write(pd->dev, state, &cmd, 1);
>> This can be optimized by calling rpmh_write_async() whenever the corner
>> being sent is smaller than the last value sent.  That way, no time is
>> wasted waiting for an ACK when decreasing voltage.  Would you mind adding
>> the necessary check and previous request caching for this?
> 
> is it safe to assume all sleep votes can be sent as async always? and only
> active votes could be sync/async depending on the last value sent?

Yes, rpmh_write_async() can always be used for RPMH_SLEEP_STATE and
RPMH_WAKE_ONLY_STATE.  The rpmh_write() vs rpmh_write_async() distinction
only matters for RPMH_ACTIVE_ONLY_STATE.

Take care,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* Re: [PATCH] clk: aspeed: Add 24MHz fixed clock
From: Stephen Boyd @ 2018-06-01 19:19 UTC (permalink / raw)
  To: Andrew Jeffery, Joel Stanley, Lei YU, Mark Rutland,
	Michael Turquette, Rob Herring, devicetree, linux-arm-kernel,
	linux-aspeed, linux-clk, linux-kernel
In-Reply-To: <1526633822-17138-1-git-send-email-mine260309@gmail.com>

Quoting Lei YU (2018-05-18 01:57:02)
> Add a 24MHz fixed clock.
> This clock will be used for certain devices, e.g. pwm.
> 
> Signed-off-by: Lei YU <mine260309@gmail.com>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH v8 2/4] dt-bindings: Add bindings for SPI NAND devices
From: Rob Herring @ 2018-06-01 19:18 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Mark Rutland,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Pawel Moll, Ian Campbell, Richard Weinberger, Kumar Gala,
	linux-spi, Marek Vasut, Mark Brown, Geert Uytterhoeven,
	Miquel Raynal, MTD Maling List, Brian Norris, David Woodhouse
In-Reply-To: <20180601190902.17cf5f6f@bbrezillon>

On Fri, Jun 1, 2018 at 12:09 PM, Boris Brezillon
<boris.brezillon@bootlin.com> wrote:
> Hi Geert,
>
> On Fri, 1 Jun 2018 16:42:26 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> Hi Boris,
>>
>> I became interested after reading the cover letter...
>>
>> On Fri, Jun 1, 2018 at 3:13 PM, Boris Brezillon
>> <boris.brezillon@bootlin.com> wrote:
>> > Add bindings for SPI NAND chips.
>> >
>> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
>>
>> Thanks for your patch!
>
> And thanks for reviewing it ;-).
>
>>
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mtd/spi-nand.txt
>> > @@ -0,0 +1,27 @@
>> > +SPI NAND flash
>> > +
>> > +Required properties:
>> > +- compatible: should be "spi-nand"

Seems awfully generic if you expect this alone. No chips with quirks
yet? Is there a standard for detection like jedec?

>> > +- reg: should encode the chip-select line used to access the NAND chip

"see spi.txt" should be enough.

>> > +
>> > +Optional properties
>> > +- spi-max-frequency: maximum frequency of the SPI bus the chip can operate at.
>> > +                    This should encode board limitations (i.e. max freq can't
>> > +                    be achieved due to crosstalk on IO lines).
>> > +                    When unspecified, the driver assumes the chip can run at
>> > +                    the max frequency defined in the spec (information
>> > +                    extracted chip detection time).
>>
>> This is a standard property according to
>> Documentation/devicetree/bindings/spi/spi-bus.txt. Can't you just refer
>> to that file, or just omit it, as it applies to all SPI slaves anyway?
>
> The thing is, the maximum frequency supported by a SPI NAND is directly
> encoded in the NAND device ID and can be auto-detected. Why should we
> define spi-max-frequency in the DT when we can automatically detect
> this information? The only reason one might want to override
> spi-max-frequency is when the board design impose such restrictions,
> hence the precision I give here.

This should always be the case. The operating frequency should be
min(host max, device max) unless the board has restrictions and needs
to set spi-max-frequency (and we really should have used
'bus-frequency' here). No doubt though, that is not what has been
done.

>> > +- spi-tx-bus-width: The bus width (number of data wires) that is used for MOSI.
>> > +                   Only encodes the board constraints (i.e. when not all IO
>> > +                   signals are routed on the board). Device constraints are
>> > +                   extracted when detecting the chip, and controller
>> > +                   constraints are exposed by the SPI mem controller. If this
>> > +                   property is missing that means no constraint at the board
>> > +                   level.
>> > +- spi-rx-bus-width: The bus width (number of data wires) that is used for MISO.
>> > +                   Only encodes the board constraints (i.e. when not all IO
>> > +                   signals are routed on the board). Device constraints are
>> > +                   extracted when detecting the chip, and controller
>> > +                   constraints are exposed by the SPI mem controller. If this
>> > +                   property is missing that means no constraint at the board
>> > +                   level.
>>
>> This does not match Documentation/devicetree/bindings/spi/spi-bus.txt,
>> which says the default is 1.
>
> Yes, I know.

Like frequency, this should have been similar. I imagine for the
common case, the number of host and device lines are 1 so it doesn't
really apply as this was added later on. Perhaps we can reword the
common definition to work for both?

Rob

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH V2 3/3] ARM: dts: imx7: correct enet ipg clock
From: Stephen Boyd @ 2018-06-01 19:18 UTC (permalink / raw)
  To: Anson Huang, adriana.reus, fabio.estevam, kernel, mark.rutland,
	mturquette, robh+dt, rui.silva, shawnguo, stefan
  Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526605266-18464-3-git-send-email-Anson.Huang@nxp.com>

Quoting Anson Huang (2018-05-17 18:01:06)
> ENET "ipg" clock should be IMX7D_ENETx_IPG_ROOT_CLK
> rather than IMX7D_ENET_AXI_ROOT_CLK which is for ENET bus
> clock.
> 
> Based on Andy Duan's patch from the NXP kernel tree.
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH V2 2/3] clk: imx7d: correct enet clock CCGR registers
From: Stephen Boyd @ 2018-06-01 19:18 UTC (permalink / raw)
  To: Anson Huang, adriana.reus, fabio.estevam, kernel, mark.rutland,
	mturquette, robh+dt, rui.silva, shawnguo, stefan
  Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526605266-18464-2-git-send-email-Anson.Huang@nxp.com>

Quoting Anson Huang (2018-05-17 18:01:05)
> Correct enet clock gates as below:
> 
> CCGR6: IMX7D_ENET_AXI_ROOT_CLK (enet1 and enet2 bus clocks)
> CCGR112: IMX7D_ENET1_TIME_ROOT_CLK, IMX7D_ENET1_IPG_ROOT_CLK
> CCGR113: IMX7D_ENET2_TIME_ROOT_CLK, IMX7D_ENET2_IPG_ROOT_CLK
> 
> Just rename unused IMX7D_ENETx_REF_ROOT_CLK for
> IMX7D_ENETx_IPG_ROOT_CLK instead of adding new clocks.
> 
> Based on Andy Duan's patch from the NXP kernel tree.
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH V2 1/3] clk: imx7d: correct enet phy ref clock gates
From: Stephen Boyd @ 2018-06-01 19:18 UTC (permalink / raw)
  To: Anson Huang, adriana.reus, fabio.estevam, kernel, mark.rutland,
	mturquette, robh+dt, rui.silva, shawnguo, stefan
  Cc: Linux-imx, linux-arm-kernel, devicetree, linux-kernel, linux-clk
In-Reply-To: <1526605266-18464-1-git-send-email-Anson.Huang@nxp.com>

Quoting Anson Huang (2018-05-17 18:01:04)
> IMX7D_ENET_PHY_REF_ROOT_DIV supplies clock for PHY directly,
> there is no clock gate after it, rename it to
> IMX7D_ENET_PHY_REF_ROOT_CLK to avoid device tree change.
> 
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH 2/3] clk: bcm: Update and add tingray clock entries
From: Rob Herring @ 2018-06-01 19:02 UTC (permalink / raw)
  To: Ray Jui
  Cc: Michael Turquette, Stephen Boyd, Mark Rutland, linux-clk,
	linux-kernel@vger.kernel.org,
	maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, devicetree,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
	Pramod Kumar
In-Reply-To: <a354f3d1-051d-8b68-e6b3-ce7a739c10c9@broadcom.com>

On Fri, Jun 1, 2018 at 12:56 PM, Ray Jui <ray.jui@broadcom.com> wrote:
> Hi Rob,
>
> On 5/31/2018 9:25 AM, Rob Herring wrote:
>>
>> On Fri, May 25, 2018 at 09:45:16AM -0700, Ray Jui wrote:
>>>
>>> Update and add Stingray clock definitions and tables so they match the
>>> binding document and the latest ASIC datasheet
>>>
>>> Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>> ---
>>>   drivers/clk/bcm/clk-sr.c           | 135
>>> ++++++++++++++++++++++++++++++++-----
>>>   include/dt-bindings/clock/bcm-sr.h |  24 +++++--
>>
>>
>> This goes in the 1st patch.
>
>
> Please help to confirm. You want 1st patch and 2nd patch to be combined into
> a single patch?

No. include/dt-bindings/* is part of the DT binding, so it goes with
patch 1. The driver in patch 2.

Rob

^ permalink raw reply

* Re: [PATCH v5 1/7] clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE pipe_clk
From: Stephen Boyd @ 2018-06-01 18:45 UTC (permalink / raw)
  To: Kishon Vijay Abraham I, robh
  Cc: devicetree, linux-kernel, dianders, evgreen, Vivek Gautam,
	linux-arm-msm, linux-usb, Manu Gautam
In-Reply-To: <1525295174-15995-2-git-send-email-mgautam@codeaurora.org>

Quoting Manu Gautam (2018-05-02 14:06:08)
> The USB and PCIE pipe clocks are sourced from external clocks
> inside the QMP USB/PCIE PHYs. Enabling or disabling of PIPE RCG
> clocks is dependent on PHY initialization sequence hence
> update halt_check to BRANCH_HALT_SKIP for these clocks so
> that clock status bit is not polled when enabling or disabling
> the clocks. It allows to simplify PHY client driver code which
> is both user and source of the pipe_clk and avoid error logging
> related status check on clk_disable/enable.
> 
> Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
> ---

Applied to clk-next

^ permalink raw reply

* Re: [PATCH v2 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
From: Brian Norris @ 2018-06-01 18:31 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Sebastian Reichel, linux-kernel, Rob Herring, linux-pm,
	devicetree, Rhyland Klein, Alexandru Stan, Doug Anderson
In-Reply-To: <20180601173434.GA22509@roeck-us.net>

Hi,

On Fri, Jun 01, 2018 at 10:34:34AM -0700, Guenter Roeck wrote:
> On Fri, Jun 01, 2018 at 10:23:59AM -0700, Brian Norris wrote:
> >  drivers/power/supply/sbs-battery.c | 54 +++++++++++++++++++++++++-----
> >  1 file changed, 46 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
> > index 83d7b4115857..8dea63464a3f 100644
> > --- a/drivers/power/supply/sbs-battery.c
> > +++ b/drivers/power/supply/sbs-battery.c
...

> > @@ -315,6 +320,27 @@ static int sbs_status_correct(struct i2c_client *client, int *intval)
> >  static int sbs_get_battery_presence_and_health(
> >  	struct i2c_client *client, enum power_supply_property psp,
> >  	union power_supply_propval *val)
> > +{
> > +	int ret;
> > +
> > +	if (psp == POWER_SUPPLY_PROP_PRESENT) {
> > +		/* Dummy command; if it succeeds, battery is present. */
> > +		ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
> > +		if (ret < 0)
> > +			val->intval = 0; /* battery disconnected */
> > +		else
> > +			val->intval = 1; /* battery present */
> > +		return 0;
> > +	} else { /* POWER_SUPPLY_PROP_HEALTH */
> 
> Static analyzers may complain that else after return is unnecessary.

I noticed (checkpatch complains) but decided I didn't care. It would be
worse to promote the 'else' to top-level (things would look asymmetric).
I suppose I could pull the 'return 0' out, but I'm not sure that would
make the code any better.

> Other than that
> 
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> 
> > +		/* SBS spec doesn't have a general health command. */
> > +		val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
> > +		return 0;
> > +	}
> > +}
> > +

Brian

^ permalink raw reply

* [PATCH linux-next v5 09/13] dt-bindings: hwmon: Add documents for PECI hwmon client drivers
From: Jae Hyun Yoo @ 2018-06-01 18:22 UTC (permalink / raw)
  To: Rob Herring, Mark Rutland, Haiyue Wang, Vernon Mauery,
	James Feist, devicetree, linux-kernel, openbmc
  Cc: Jae Hyun Yoo, Andrew Jeffery, Arnd Bergmann, Jason M Biils,
	Joel Stanley

This commit adds dt-bindings documents for PECI hwmon client drivers.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Joel Stanley <joel@jms.id.au>
---
 .../devicetree/bindings/hwmon/peci-cputemp.txt      | 11 +++++++++++
 .../devicetree/bindings/hwmon/peci-dimmtemp.txt     | 13 +++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
 create mode 100644 Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt

diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
new file mode 100644
index 000000000000..19c7da57deab
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
@@ -0,0 +1,11 @@
+Bindings for Intel PECI (Platform Environment Control Interface) cputemp driver.
+
+Required properties:
+- compatible : Should be "intel,peci-cputemp".
+
+This node is a subnode of the PECI client MFD.
+
+Example:
+	peci-cputemp {
+		compatible = "intel,peci-cputemp";
+	};
diff --git a/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt b/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
new file mode 100644
index 000000000000..f390900a62b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
@@ -0,0 +1,13 @@
+Bindings for Intel PECI (Platform Environment Control Interface) dimmtemp
+driver.
+
+Required properties:
+- compatible : Should be "intel,peci-dimmtemp".
+
+This node is a subnode of the PECI client MFD.
+
+Example:
+	peci-dimmtemp@30 {
+		compatible = "intel,peci-dimmtemp";
+		reg = <0x30>;
+	};
\ No newline at end of file
-- 
2.17.0

^ permalink raw reply related

* [PATCH linux-next v5 07/13] dt-bindings: mfd: Add a document for PECI client mfd
From: Jae Hyun Yoo @ 2018-06-01 18:22 UTC (permalink / raw)
  To: Lee Jones, Mark Rutland, Rob Herring, devicetree, linux-kernel,
	openbmc
  Cc: Jae Hyun Yoo, Andrew Jeffery, James Feist, Jason M Biils,
	Joel Stanley, Vernon Mauery

This commit adds a dt-bindings document for PECI client multi-function
device.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: James Feist <james.feist@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Joel Stanley <joel@jms.id.au>
Cc: Vernon Mauery <vernon.mauery@linux.intel.com>
---
 .../devicetree/bindings/mfd/peci-client.txt   | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/peci-client.txt

diff --git a/Documentation/devicetree/bindings/mfd/peci-client.txt b/Documentation/devicetree/bindings/mfd/peci-client.txt
new file mode 100644
index 000000000000..4eb8f6bb6ca4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/peci-client.txt
@@ -0,0 +1,23 @@
+* Intel PECI client bindings
+
+Required properties:
+- compatible : Should be "intel,peci-client", "simple-mfd".
+- reg        : Should contain address of a client CPU. Address range of CPU
+	       clients is starting from 0x30 based on PECI specification.
+
+Example:
+	peci-bus@0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		< more properties >
+
+		peci-client@30 {
+			compatible = "intel,peci-client", "simple-mfd";
+			reg = <0x30>;
+		};
+
+		peci-client@31 {
+			compatible = "intel,peci-client", "simple-mfd";
+			reg = <0x31>;
+		};
+	};
-- 
2.17.0

^ permalink raw reply related

* [PATCH linux-next v5 05/13] ARM: dts: aspeed: peci: Add PECI node
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
  To: Rob Herring, Mark Rutland, Joel Stanley, Andrew Jeffery,
	devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
  Cc: Jae Hyun Yoo, Jason M Biils, Ryan Chen

This commit adds PECI bus/adapter node of AST24xx/AST25xx into
aspeed-g4 and aspeed-g5.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>
---
 arch/arm/boot/dts/aspeed-g4.dtsi | 26 ++++++++++++++++++++++++++
 arch/arm/boot/dts/aspeed-g5.dtsi | 26 ++++++++++++++++++++++++++
 2 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 5e947ed496c2..5702f0cfd5f8 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -29,6 +29,7 @@
 		serial3 = &uart4;
 		serial4 = &uart5;
 		serial5 = &vuart;
+		peci0 = &peci0;
 	};
 
 	cpus {
@@ -295,6 +296,13 @@
 				};
 			};
 
+			peci: peci@1e78b000 {
+				compatible = "simple-bus";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1e78b000 0x60>;
+			};
+
 			uart2: serial@1e78d000 {
 				compatible = "ns16550a";
 				reg = <0x1e78d000 0x20>;
@@ -338,6 +346,24 @@
 	};
 };
 
+&peci {
+	peci0: peci-bus@0 {
+		compatible = "aspeed,ast2400-peci";
+		reg = <0x0 0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <15>;
+		clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+		resets = <&syscon ASPEED_RESET_PECI>;
+		clock-frequency = <24000000>;
+		msg-timing = <1>;
+		addr-timing = <1>;
+		rd-sampling-point = <8>;
+		cmd-timeout-ms = <1000>;
+		status = "disabled";
+	};
+};
+
 &i2c {
 	i2c_ic: interrupt-controller@0 {
 		#interrupt-cells = <1>;
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 24eec00c4a95..5741b841fddb 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -29,6 +29,7 @@
 		serial3 = &uart4;
 		serial4 = &uart5;
 		serial5 = &vuart;
+		peci0 = &peci0;
 	};
 
 	cpus {
@@ -352,6 +353,13 @@
 				};
 			};
 
+			peci: peci@1e78b000 {
+				compatible = "simple-bus";
+				#address-cells = <1>;
+				#size-cells = <1>;
+				ranges = <0x0 0x1e78b000 0x60>;
+			};
+
 			uart2: serial@1e78d000 {
 				compatible = "ns16550a";
 				reg = <0x1e78d000 0x20>;
@@ -395,6 +403,24 @@
 	};
 };
 
+&peci {
+	peci0: peci-bus@0 {
+		compatible = "aspeed,ast2500-peci";
+		reg = <0x0 0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <15>;
+		clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+		resets = <&syscon ASPEED_RESET_PECI>;
+		clock-frequency = <24000000>;
+		msg-timing = <1>;
+		addr-timing = <1>;
+		rd-sampling-point = <8>;
+		cmd-timeout-ms = <1000>;
+		status = "disabled";
+	};
+};
+
 &i2c {
 	i2c_ic: interrupt-controller@0 {
 		#interrupt-cells = <1>;
-- 
2.17.0

^ permalink raw reply related

* [PATCH linux-next v5 04/13] dt-bindings: Add a document of PECI adapter driver for ASPEED AST24xx/25xx SoCs
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
  To: Jason M Biils, Rob Herring, Mark Rutland, Joel Stanley,
	Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel, openbmc
  Cc: Jae Hyun Yoo, Benjamin Herrenschmidt, Greg KH, Milton Miller II,
	Pavel Machek, Robin Murphy, Ryan Chen

This commit adds a dt-bindings document of PECI adapter driver for ASPEED
AST24xx/25xx SoCs.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Jason M Biils <jason.m.bills@linux.intel.com>
Cc: Milton Miller II <miltonm@us.ibm.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ryan Chen <ryan_chen@aspeedtech.com>
---
 .../devicetree/bindings/peci/peci-aspeed.txt  | 57 +++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt

diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
new file mode 100644
index 000000000000..8c35f905589d
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
@@ -0,0 +1,57 @@
+Device tree configuration for PECI buses on the AST24XX and AST25XX SoCs.
+
+Required properties:
+- compatible        : Should be "aspeed,ast2400-peci" or "aspeed,ast2500-peci"
+		      - aspeed,ast2400-peci: ASPEED AST2400 family PECI
+					     controller
+		      - aspeed,ast2500-peci: ASPEED AST2500 family PECI
+					     controller
+- reg               : Should contain PECI controller registers location and
+		      length.
+- #address-cells    : Should be <1> required to define a client address.
+- #size-cells       : Should be <0> required to define a client address.
+- interrupts        : Should contain PECI controller interrupt.
+- clocks            : Should contain clock source for PECI controller. Should
+		      reference the external oscillator clock in the second
+		      cell.
+- resets            : Should contain phandle to reset controller with the reset
+		      number in the second cell.
+- clock-frequency   : Should contain the operation frequency of PECI controller
+		      in units of Hz.
+		      187500 ~ 24000000
+
+Optional properties:
+- msg-timing        : Message timing negotiation period. This value will
+		      determine the period of message timing negotiation to be
+		      issued by PECI controller. The unit of the programmed
+		      value is four times of PECI clock period.
+		      0 ~ 255 (default: 1)
+- addr-timing       : Address timing negotiation period. This value will
+		      determine the period of address timing negotiation to be
+		      issued by PECI controller. The unit of the programmed
+		      value is four times of PECI clock period.
+		      0 ~ 255 (default: 1)
+- rd-sampling-point : Read sampling point selection. The whole period of a bit
+		      time will be divided into 16 time frames. This value will
+		      determine the time frame in which the controller will
+		      sample PECI signal for data read back. Usually in the
+		      middle of a bit time is the best.
+		      0 ~ 15 (default: 8)
+- cmd-timeout-ms    : Command timeout in units of ms.
+		      1 ~ 60000 (default: 1000)
+
+Example:
+	peci0: peci-bus@0 {
+		compatible = "aspeed,ast2500-peci";
+		reg = <0x0 0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		interrupts = <15>;
+		clocks = <&syscon ASPEED_CLK_GATE_REFCLK>;
+		resets = <&syscon ASPEED_RESET_PECI>;
+		clock-frequency = <24000000>;
+		msg-timing = <1>;
+		addr-timing = <1>;
+		rd-sampling-point = <8>;
+		cmd-timeout-ms = <1000>;
+	};
-- 
2.17.0

^ permalink raw reply related

* [PATCH linux-next v5 01/13] dt-bindings: Add a document of PECI subsystem
From: Jae Hyun Yoo @ 2018-06-01 18:21 UTC (permalink / raw)
  To: Rob Herring, Mark Rutland, devicetree, linux-kernel, openbmc
  Cc: Jae Hyun Yoo, Andrew Jeffery, Joel Stanley

This commit adds a document of generic PECI bus, adapter and client
driver.

Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
Reviewed-by: James Feist <james.feist@linux.intel.com>
Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Joel Stanley <joel@jms.id.au>
---
 .../devicetree/bindings/peci/peci.txt         | 59 +++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/peci/peci.txt

diff --git a/Documentation/devicetree/bindings/peci/peci.txt b/Documentation/devicetree/bindings/peci/peci.txt
new file mode 100644
index 000000000000..8db2b1e56a01
--- /dev/null
+++ b/Documentation/devicetree/bindings/peci/peci.txt
@@ -0,0 +1,59 @@
+Generic device tree configuration for PECI buses
+================================================
+
+Required properties:
+- compatible     : Should be "simple-bus".
+- #address-cells : Should be present if the device has sub-nodes.
+- #size-cells    : Should be present if the device has sub-nodes.
+- ranges         : Should contain PECI controller registers ranges.
+
+Example:
+	peci: peci@10000000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0x0 0x10000000 0x1000>;
+	};
+
+Generic device tree configuration for PECI adapters
+===================================================
+
+Required properties:
+- #address-cells : Should be <1>. Read more about client addresses below.
+- #size-cells    : Should be <0>. Read more about client addresses below.
+
+The cells properties above define that an address of CPU clients of a PECI bus
+are described by a single value.
+
+Example:
+	peci0: peci-bus@0 {
+		compatible = "soc,soc-peci";
+		reg = <0x0 0x1000>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+
+Generic device tree configuration for PECI clients
+==================================================
+
+Required properties:
+- compatible : Should contain name of PECI client.
+- reg        : Should contain address of a client CPU. Address range of CPU
+	       clients is starting from 0x30 based on PECI specification.
+
+Example:
+	peci-bus@0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		< more properties >
+
+		peci-client@30 {
+			compatible = "intel,peci-client";
+			reg = <0x30>;
+		};
+
+		peci-client@31 {
+			compatible = "intel,peci-client";
+			reg = <0x31>;
+		};
+	};
-- 
2.17.0

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox