[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

Hi,

This is minor rework of the series[1] from Neil Armstrong's to support
legacy SCPI protocol to make DT bindings more generic and move out all
the platform specific bindings out of the generic binding document.

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Neil Armstrong (4):
  firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
  firmware: arm_scpi: add alternative legacy structures, functions and
    macros
  firmware: arm_scpi: allow firmware with get_capabilities not
    implemented
  Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

Sudeep Holla (4):
  firmware: arm_scpi: add command indirection to support legacy commands
  Documentation: bindings: decouple juno specific details from generic
    binding
  Documentation: bindings: add compatible specific to legacy SCPI
    protocol
  firmware: arm_scpi: add support for legacy SCPI compatible

 .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
 Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
 .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
 drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
 4 files changed, 300 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

-- 
1.9.1

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

Hi,

This is minor rework of the series[1] from Neil Armstrong's to support
legacy SCPI protocol to make DT bindings more generic and move out all
the platform specific bindings out of the generic binding document.

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Neil Armstrong (4):
  firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
  firmware: arm_scpi: add alternative legacy structures, functions and
    macros
  firmware: arm_scpi: allow firmware with get_capabilities not
    implemented
  Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

Sudeep Holla (4):
  firmware: arm_scpi: add command indirection to support legacy commands
  Documentation: bindings: decouple juno specific details from generic
    binding
  Documentation: bindings: add compatible specific to legacy SCPI
    protocol
  firmware: arm_scpi: add support for legacy SCPI compatible

 .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
 Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
 .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
 drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
 4 files changed, 300 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

-- 
1.9.1

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

Hi,

This is minor rework of the series[1] from Neil Armstrong's to support
legacy SCPI protocol to make DT bindings more generic and move out all
the platform specific bindings out of the generic binding document.

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Neil Armstrong (4):
  firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
  firmware: arm_scpi: add alternative legacy structures, functions and
    macros
  firmware: arm_scpi: allow firmware with get_capabilities not
    implemented
  Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

Sudeep Holla (4):
  firmware: arm_scpi: add command indirection to support legacy commands
  Documentation: bindings: decouple juno specific details from generic
    binding
  Documentation: bindings: add compatible specific to legacy SCPI
    protocol
  firmware: arm_scpi: add support for legacy SCPI compatible

 .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
 Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
 .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
 drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
 4 files changed, 300 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

Hi,

This is minor rework of the series[1] from Neil Armstrong's to support
legacy SCPI protocol to make DT bindings more generic and move out all
the platform specific bindings out of the generic binding document.

--
Regards,
Sudeep

[1] http://www.spinics.net/lists/arm-kernel/msg534999.html

Neil Armstrong (4):
  firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
  firmware: arm_scpi: add alternative legacy structures, functions and
    macros
  firmware: arm_scpi: allow firmware with get_capabilities not
    implemented
  Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

Sudeep Holla (4):
  firmware: arm_scpi: add command indirection to support legacy commands
  Documentation: bindings: decouple juno specific details from generic
    binding
  Documentation: bindings: add compatible specific to legacy SCPI
    protocol
  firmware: arm_scpi: add support for legacy SCPI compatible

 .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
 Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
 .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
 drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
 4 files changed, 300 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

-- 
1.9.1

[PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands

[Sudeep Holla]

Since the legacy SCPI and the SCPI v1.0 differ in the command values,
it's better to create some sort of command indirection in the driver
to avoid repeated version check at multiple places.

This patch adds the indirection command table to allow different values
of the command across SCPI versions.

[narmstrong at baylibre.com: added cmd check in scpi_send_message]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 71 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 57 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index ce2bc2a38101..9e9b022450eb 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -99,6 +99,7 @@ enum scpi_error_codes {
 	SCPI_ERR_MAX
 };
 
+/* SCPI Standard commands */
 enum scpi_std_cmd {
 	SCPI_CMD_INVALID		= 0x00,
 	SCPI_CMD_SCPI_READY		= 0x01,
@@ -132,6 +133,38 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
+/* List of all commands used by this driver, used as indices */
+enum scpi_drv_cmds {
+	CMD_SCPI_CAPABILITIES = 0,
+	CMD_GET_CLOCK_INFO,
+	CMD_GET_CLOCK_VALUE,
+	CMD_SET_CLOCK_VALUE,
+	CMD_GET_DVFS,
+	CMD_SET_DVFS,
+	CMD_GET_DVFS_INFO,
+	CMD_SENSOR_CAPABILITIES,
+	CMD_SENSOR_INFO,
+	CMD_SENSOR_VALUE,
+	CMD_SET_DEVICE_PWR_STATE,
+	CMD_GET_DEVICE_PWR_STATE,
+	CMD_MAX_COUNT,
+};
+
+static int scpi_std_commands[CMD_MAX_COUNT] = {
+	SCPI_CMD_SCPI_CAPABILITIES,
+	SCPI_CMD_GET_CLOCK_INFO,
+	SCPI_CMD_GET_CLOCK_VALUE,
+	SCPI_CMD_SET_CLOCK_VALUE,
+	SCPI_CMD_GET_DVFS,
+	SCPI_CMD_SET_DVFS,
+	SCPI_CMD_GET_DVFS_INFO,
+	SCPI_CMD_SENSOR_CAPABILITIES,
+	SCPI_CMD_SENSOR_INFO,
+	SCPI_CMD_SENSOR_VALUE,
+	SCPI_CMD_SET_DEVICE_PWR_STATE,
+	SCPI_CMD_GET_DEVICE_PWR_STATE,
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -161,6 +194,7 @@ struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
 	int num_chans;
+	int *commands;
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -344,14 +378,20 @@ static void put_scpi_xfer(struct scpi_xfer *t, struct scpi_chan *ch)
 	mutex_unlock(&ch->xfers_lock);
 }
 
-static int scpi_send_message(u8 cmd, void *tx_buf, unsigned int tx_len,
+static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 			     void *rx_buf, unsigned int rx_len)
 {
 	int ret;
 	u8 chan;
+	u8 cmd;
 	struct scpi_xfer *msg;
 	struct scpi_chan *scpi_chan;
 
+	if (scpi_info->commands[idx] < 0)
+		return -EOPNOTSUPP;
+
+	cmd = scpi_info->commands[idx];
+
 	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
@@ -397,7 +437,7 @@ static u32 scpi_get_version(void)
 	struct clk_get_info clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_INFO, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_INFO, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
 	if (!ret) {
 		*min = le32_to_cpu(clk.min_rate);
@@ -412,8 +452,9 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
 	struct clk_get_value clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_VALUE, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
+
 	return ret ? ret : le32_to_cpu(clk.rate);
 }
 
@@ -425,7 +466,7 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 		.rate = cpu_to_le32(rate)
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
 				 &stat, sizeof(stat));
 }
 
@@ -434,8 +475,9 @@ static int scpi_dvfs_get_idx(u8 domain)
 	int ret;
 	u8 dvfs_idx;
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS, &domain, sizeof(domain),
 				&dvfs_idx, sizeof(dvfs_idx));
+
 	return ret ? ret : dvfs_idx;
 }
 
@@ -444,7 +486,7 @@ static int scpi_dvfs_set_idx(u8 domain, u8 index)
 	int stat;
 	struct dvfs_set dvfs = {domain, index};
 
-	return scpi_send_message(SCPI_CMD_SET_DVFS, &dvfs, sizeof(dvfs),
+	return scpi_send_message(CMD_SET_DVFS, &dvfs, sizeof(dvfs),
 				 &stat, sizeof(stat));
 }
 
@@ -468,9 +510,8 @@ static struct scpi_dvfs_info *scpi_dvfs_get_info(u8 domain)
 	if (scpi_info->dvfs[domain])	/* data already populated */
 		return scpi_info->dvfs[domain];
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS_INFO, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS_INFO, &domain, sizeof(domain),
 				&buf, sizeof(buf));
-
 	if (ret)
 		return ERR_PTR(ret);
 
@@ -503,7 +544,7 @@ static int scpi_sensor_get_capability(u16 *sensors)
 	struct sensor_capabilities cap_buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
+	ret = scpi_send_message(CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
 				sizeof(cap_buf));
 	if (!ret)
 		*sensors = le16_to_cpu(cap_buf.sensors);
@@ -517,7 +558,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
 	struct _scpi_sensor_info _info;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_INFO, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_INFO, &id, sizeof(id),
 				&_info, sizeof(_info));
 	if (!ret) {
 		memcpy(info, &_info, sizeof(*info));
@@ -533,7 +574,7 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
 	struct sensor_value buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
 				&buf, sizeof(buf));
 	if (!ret)
 		*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
@@ -548,7 +589,7 @@ static int scpi_device_get_power_state(u16 dev_id)
 	u8 pstate;
 	__le16 id = cpu_to_le16(dev_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_DEVICE_PWR_STATE, &id,
+	ret = scpi_send_message(CMD_GET_DEVICE_PWR_STATE, &id,
 				sizeof(id), &pstate, sizeof(pstate));
 	return ret ? ret : pstate;
 }
@@ -561,7 +602,7 @@ static int scpi_device_set_power_state(u16 dev_id, u8 pstate)
 		.pstate = pstate,
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_DEVICE_PWR_STATE, &dev_set,
+	return scpi_send_message(CMD_SET_DEVICE_PWR_STATE, &dev_set,
 				 sizeof(dev_set), &stat, sizeof(stat));
 }
 
@@ -591,7 +632,7 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 	int ret;
 	struct scp_capabilities caps;
 
-	ret = scpi_send_message(SCPI_CMD_SCPI_CAPABILITIES, NULL, 0,
+	ret = scpi_send_message(CMD_SCPI_CAPABILITIES, NULL, 0,
 				&caps, sizeof(caps));
 	if (!ret) {
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
@@ -755,6 +796,8 @@ static int scpi_probe(struct platform_device *pdev)
 
 	scpi_info->channels = scpi_chan;
 	scpi_info->num_chans = count;
+	scpi_info->commands = scpi_std_commands;
+
 	platform_set_drvdata(pdev, scpi_info);
 
 	ret = scpi_init_versions(scpi_info);
-- 
1.9.1

[PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands

[Sudeep Holla]

Since the legacy SCPI and the SCPI v1.0 differ in the command values,
it's better to create some sort of command indirection in the driver
to avoid repeated version check at multiple places.

This patch adds the indirection command table to allow different values
of the command across SCPI versions.

[narmstrong@baylibre.com: added cmd check in scpi_send_message]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 71 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 57 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index ce2bc2a38101..9e9b022450eb 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -99,6 +99,7 @@ enum scpi_error_codes {
 	SCPI_ERR_MAX
 };
 
+/* SCPI Standard commands */
 enum scpi_std_cmd {
 	SCPI_CMD_INVALID		= 0x00,
 	SCPI_CMD_SCPI_READY		= 0x01,
@@ -132,6 +133,38 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
+/* List of all commands used by this driver, used as indices */
+enum scpi_drv_cmds {
+	CMD_SCPI_CAPABILITIES = 0,
+	CMD_GET_CLOCK_INFO,
+	CMD_GET_CLOCK_VALUE,
+	CMD_SET_CLOCK_VALUE,
+	CMD_GET_DVFS,
+	CMD_SET_DVFS,
+	CMD_GET_DVFS_INFO,
+	CMD_SENSOR_CAPABILITIES,
+	CMD_SENSOR_INFO,
+	CMD_SENSOR_VALUE,
+	CMD_SET_DEVICE_PWR_STATE,
+	CMD_GET_DEVICE_PWR_STATE,
+	CMD_MAX_COUNT,
+};
+
+static int scpi_std_commands[CMD_MAX_COUNT] = {
+	SCPI_CMD_SCPI_CAPABILITIES,
+	SCPI_CMD_GET_CLOCK_INFO,
+	SCPI_CMD_GET_CLOCK_VALUE,
+	SCPI_CMD_SET_CLOCK_VALUE,
+	SCPI_CMD_GET_DVFS,
+	SCPI_CMD_SET_DVFS,
+	SCPI_CMD_GET_DVFS_INFO,
+	SCPI_CMD_SENSOR_CAPABILITIES,
+	SCPI_CMD_SENSOR_INFO,
+	SCPI_CMD_SENSOR_VALUE,
+	SCPI_CMD_SET_DEVICE_PWR_STATE,
+	SCPI_CMD_GET_DEVICE_PWR_STATE,
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -161,6 +194,7 @@ struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
 	int num_chans;
+	int *commands;
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -344,14 +378,20 @@ static void put_scpi_xfer(struct scpi_xfer *t, struct scpi_chan *ch)
 	mutex_unlock(&ch->xfers_lock);
 }
 
-static int scpi_send_message(u8 cmd, void *tx_buf, unsigned int tx_len,
+static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 			     void *rx_buf, unsigned int rx_len)
 {
 	int ret;
 	u8 chan;
+	u8 cmd;
 	struct scpi_xfer *msg;
 	struct scpi_chan *scpi_chan;
 
+	if (scpi_info->commands[idx] < 0)
+		return -EOPNOTSUPP;
+
+	cmd = scpi_info->commands[idx];
+
 	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
@@ -397,7 +437,7 @@ static u32 scpi_get_version(void)
 	struct clk_get_info clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_INFO, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_INFO, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
 	if (!ret) {
 		*min = le32_to_cpu(clk.min_rate);
@@ -412,8 +452,9 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
 	struct clk_get_value clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_VALUE, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
+
 	return ret ? ret : le32_to_cpu(clk.rate);
 }
 
@@ -425,7 +466,7 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 		.rate = cpu_to_le32(rate)
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
 				 &stat, sizeof(stat));
 }
 
@@ -434,8 +475,9 @@ static int scpi_dvfs_get_idx(u8 domain)
 	int ret;
 	u8 dvfs_idx;
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS, &domain, sizeof(domain),
 				&dvfs_idx, sizeof(dvfs_idx));
+
 	return ret ? ret : dvfs_idx;
 }
 
@@ -444,7 +486,7 @@ static int scpi_dvfs_set_idx(u8 domain, u8 index)
 	int stat;
 	struct dvfs_set dvfs = {domain, index};
 
-	return scpi_send_message(SCPI_CMD_SET_DVFS, &dvfs, sizeof(dvfs),
+	return scpi_send_message(CMD_SET_DVFS, &dvfs, sizeof(dvfs),
 				 &stat, sizeof(stat));
 }
 
@@ -468,9 +510,8 @@ static struct scpi_dvfs_info *scpi_dvfs_get_info(u8 domain)
 	if (scpi_info->dvfs[domain])	/* data already populated */
 		return scpi_info->dvfs[domain];
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS_INFO, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS_INFO, &domain, sizeof(domain),
 				&buf, sizeof(buf));
-
 	if (ret)
 		return ERR_PTR(ret);
 
@@ -503,7 +544,7 @@ static int scpi_sensor_get_capability(u16 *sensors)
 	struct sensor_capabilities cap_buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
+	ret = scpi_send_message(CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
 				sizeof(cap_buf));
 	if (!ret)
 		*sensors = le16_to_cpu(cap_buf.sensors);
@@ -517,7 +558,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
 	struct _scpi_sensor_info _info;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_INFO, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_INFO, &id, sizeof(id),
 				&_info, sizeof(_info));
 	if (!ret) {
 		memcpy(info, &_info, sizeof(*info));
@@ -533,7 +574,7 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
 	struct sensor_value buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
 				&buf, sizeof(buf));
 	if (!ret)
 		*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
@@ -548,7 +589,7 @@ static int scpi_device_get_power_state(u16 dev_id)
 	u8 pstate;
 	__le16 id = cpu_to_le16(dev_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_DEVICE_PWR_STATE, &id,
+	ret = scpi_send_message(CMD_GET_DEVICE_PWR_STATE, &id,
 				sizeof(id), &pstate, sizeof(pstate));
 	return ret ? ret : pstate;
 }
@@ -561,7 +602,7 @@ static int scpi_device_set_power_state(u16 dev_id, u8 pstate)
 		.pstate = pstate,
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_DEVICE_PWR_STATE, &dev_set,
+	return scpi_send_message(CMD_SET_DEVICE_PWR_STATE, &dev_set,
 				 sizeof(dev_set), &stat, sizeof(stat));
 }
 
@@ -591,7 +632,7 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 	int ret;
 	struct scp_capabilities caps;
 
-	ret = scpi_send_message(SCPI_CMD_SCPI_CAPABILITIES, NULL, 0,
+	ret = scpi_send_message(CMD_SCPI_CAPABILITIES, NULL, 0,
 				&caps, sizeof(caps));
 	if (!ret) {
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
@@ -755,6 +796,8 @@ static int scpi_probe(struct platform_device *pdev)
 
 	scpi_info->channels = scpi_chan;
 	scpi_info->num_chans = count;
+	scpi_info->commands = scpi_std_commands;
+
 	platform_set_drvdata(pdev, scpi_info);
 
 	ret = scpi_init_versions(scpi_info);
-- 
1.9.1

[PATCH v5 1/8] firmware: arm_scpi: add command indirection to support legacy commands

[Sudeep Holla]

Since the legacy SCPI and the SCPI v1.0 differ in the command values,
it's better to create some sort of command indirection in the driver
to avoid repeated version check at multiple places.

This patch adds the indirection command table to allow different values
of the command across SCPI versions.

[narmstrong at baylibre.com: added cmd check in scpi_send_message]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 71 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 57 insertions(+), 14 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index ce2bc2a38101..9e9b022450eb 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -99,6 +99,7 @@ enum scpi_error_codes {
 	SCPI_ERR_MAX
 };
 
+/* SCPI Standard commands */
 enum scpi_std_cmd {
 	SCPI_CMD_INVALID		= 0x00,
 	SCPI_CMD_SCPI_READY		= 0x01,
@@ -132,6 +133,38 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
+/* List of all commands used by this driver, used as indices */
+enum scpi_drv_cmds {
+	CMD_SCPI_CAPABILITIES = 0,
+	CMD_GET_CLOCK_INFO,
+	CMD_GET_CLOCK_VALUE,
+	CMD_SET_CLOCK_VALUE,
+	CMD_GET_DVFS,
+	CMD_SET_DVFS,
+	CMD_GET_DVFS_INFO,
+	CMD_SENSOR_CAPABILITIES,
+	CMD_SENSOR_INFO,
+	CMD_SENSOR_VALUE,
+	CMD_SET_DEVICE_PWR_STATE,
+	CMD_GET_DEVICE_PWR_STATE,
+	CMD_MAX_COUNT,
+};
+
+static int scpi_std_commands[CMD_MAX_COUNT] = {
+	SCPI_CMD_SCPI_CAPABILITIES,
+	SCPI_CMD_GET_CLOCK_INFO,
+	SCPI_CMD_GET_CLOCK_VALUE,
+	SCPI_CMD_SET_CLOCK_VALUE,
+	SCPI_CMD_GET_DVFS,
+	SCPI_CMD_SET_DVFS,
+	SCPI_CMD_GET_DVFS_INFO,
+	SCPI_CMD_SENSOR_CAPABILITIES,
+	SCPI_CMD_SENSOR_INFO,
+	SCPI_CMD_SENSOR_VALUE,
+	SCPI_CMD_SET_DEVICE_PWR_STATE,
+	SCPI_CMD_GET_DEVICE_PWR_STATE,
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -161,6 +194,7 @@ struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
 	int num_chans;
+	int *commands;
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -344,14 +378,20 @@ static void put_scpi_xfer(struct scpi_xfer *t, struct scpi_chan *ch)
 	mutex_unlock(&ch->xfers_lock);
 }
 
-static int scpi_send_message(u8 cmd, void *tx_buf, unsigned int tx_len,
+static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 			     void *rx_buf, unsigned int rx_len)
 {
 	int ret;
 	u8 chan;
+	u8 cmd;
 	struct scpi_xfer *msg;
 	struct scpi_chan *scpi_chan;
 
+	if (scpi_info->commands[idx] < 0)
+		return -EOPNOTSUPP;
+
+	cmd = scpi_info->commands[idx];
+
 	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
@@ -397,7 +437,7 @@ static u32 scpi_get_version(void)
 	struct clk_get_info clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_INFO, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_INFO, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
 	if (!ret) {
 		*min = le32_to_cpu(clk.min_rate);
@@ -412,8 +452,9 @@ static unsigned long scpi_clk_get_val(u16 clk_id)
 	struct clk_get_value clk;
 	__le16 le_clk_id = cpu_to_le16(clk_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_CLOCK_VALUE, &le_clk_id,
+	ret = scpi_send_message(CMD_GET_CLOCK_VALUE, &le_clk_id,
 				sizeof(le_clk_id), &clk, sizeof(clk));
+
 	return ret ? ret : le32_to_cpu(clk.rate);
 }
 
@@ -425,7 +466,7 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 		.rate = cpu_to_le32(rate)
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
 				 &stat, sizeof(stat));
 }
 
@@ -434,8 +475,9 @@ static int scpi_dvfs_get_idx(u8 domain)
 	int ret;
 	u8 dvfs_idx;
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS, &domain, sizeof(domain),
 				&dvfs_idx, sizeof(dvfs_idx));
+
 	return ret ? ret : dvfs_idx;
 }
 
@@ -444,7 +486,7 @@ static int scpi_dvfs_set_idx(u8 domain, u8 index)
 	int stat;
 	struct dvfs_set dvfs = {domain, index};
 
-	return scpi_send_message(SCPI_CMD_SET_DVFS, &dvfs, sizeof(dvfs),
+	return scpi_send_message(CMD_SET_DVFS, &dvfs, sizeof(dvfs),
 				 &stat, sizeof(stat));
 }
 
@@ -468,9 +510,8 @@ static struct scpi_dvfs_info *scpi_dvfs_get_info(u8 domain)
 	if (scpi_info->dvfs[domain])	/* data already populated */
 		return scpi_info->dvfs[domain];
 
-	ret = scpi_send_message(SCPI_CMD_GET_DVFS_INFO, &domain, sizeof(domain),
+	ret = scpi_send_message(CMD_GET_DVFS_INFO, &domain, sizeof(domain),
 				&buf, sizeof(buf));
-
 	if (ret)
 		return ERR_PTR(ret);
 
@@ -503,7 +544,7 @@ static int scpi_sensor_get_capability(u16 *sensors)
 	struct sensor_capabilities cap_buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
+	ret = scpi_send_message(CMD_SENSOR_CAPABILITIES, NULL, 0, &cap_buf,
 				sizeof(cap_buf));
 	if (!ret)
 		*sensors = le16_to_cpu(cap_buf.sensors);
@@ -517,7 +558,7 @@ static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
 	struct _scpi_sensor_info _info;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_INFO, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_INFO, &id, sizeof(id),
 				&_info, sizeof(_info));
 	if (!ret) {
 		memcpy(info, &_info, sizeof(*info));
@@ -533,7 +574,7 @@ static int scpi_sensor_get_value(u16 sensor, u64 *val)
 	struct sensor_value buf;
 	int ret;
 
-	ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, &id, sizeof(id),
+	ret = scpi_send_message(CMD_SENSOR_VALUE, &id, sizeof(id),
 				&buf, sizeof(buf));
 	if (!ret)
 		*val = (u64)le32_to_cpu(buf.hi_val) << 32 |
@@ -548,7 +589,7 @@ static int scpi_device_get_power_state(u16 dev_id)
 	u8 pstate;
 	__le16 id = cpu_to_le16(dev_id);
 
-	ret = scpi_send_message(SCPI_CMD_GET_DEVICE_PWR_STATE, &id,
+	ret = scpi_send_message(CMD_GET_DEVICE_PWR_STATE, &id,
 				sizeof(id), &pstate, sizeof(pstate));
 	return ret ? ret : pstate;
 }
@@ -561,7 +602,7 @@ static int scpi_device_set_power_state(u16 dev_id, u8 pstate)
 		.pstate = pstate,
 	};
 
-	return scpi_send_message(SCPI_CMD_SET_DEVICE_PWR_STATE, &dev_set,
+	return scpi_send_message(CMD_SET_DEVICE_PWR_STATE, &dev_set,
 				 sizeof(dev_set), &stat, sizeof(stat));
 }
 
@@ -591,7 +632,7 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 	int ret;
 	struct scp_capabilities caps;
 
-	ret = scpi_send_message(SCPI_CMD_SCPI_CAPABILITIES, NULL, 0,
+	ret = scpi_send_message(CMD_SCPI_CAPABILITIES, NULL, 0,
 				&caps, sizeof(caps));
 	if (!ret) {
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
@@ -755,6 +796,8 @@ static int scpi_probe(struct platform_device *pdev)
 
 	scpi_info->channels = scpi_chan;
 	scpi_info->num_chans = count;
+	scpi_info->commands = scpi_std_commands;
+
 	platform_set_drvdata(pdev, scpi_info);
 
 	ret = scpi_init_versions(scpi_info);
-- 
1.9.1

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase
the OPP structure size.

This patch increases the MAX_DVFS_OPPS to 16.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 9e9b022450eb..21542a32ad9f 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -63,7 +63,7 @@
 #define SCPI_SLOT		0
 
 #define MAX_DVFS_DOMAINS	8
-#define MAX_DVFS_OPPS		8
+#define MAX_DVFS_OPPS		16
 #define DVFS_LATENCY(hdr)	(le32_to_cpu(hdr) >> 16)
 #define DVFS_OPP_COUNT(hdr)	((le32_to_cpu(hdr) >> 8) & 0xff)
 
-- 
1.9.1

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase
the OPP structure size.

This patch increases the MAX_DVFS_OPPS to 16.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 9e9b022450eb..21542a32ad9f 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -63,7 +63,7 @@
 #define SCPI_SLOT		0
 
 #define MAX_DVFS_DOMAINS	8
-#define MAX_DVFS_OPPS		8
+#define MAX_DVFS_OPPS		16
 #define DVFS_LATENCY(hdr)	(le32_to_cpu(hdr) >> 16)
 #define DVFS_OPP_COUNT(hdr)	((le32_to_cpu(hdr) >> 8) & 0xff)
 
-- 
1.9.1

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

[Sudeep Holla]

From: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase
the OPP structure size.

This patch increases the MAX_DVFS_OPPS to 16.

Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
 drivers/firmware/arm_scpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 9e9b022450eb..21542a32ad9f 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -63,7 +63,7 @@
 #define SCPI_SLOT		0
 
 #define MAX_DVFS_DOMAINS	8
-#define MAX_DVFS_OPPS		8
+#define MAX_DVFS_OPPS		16
 #define DVFS_LATENCY(hdr)	(le32_to_cpu(hdr) >> 16)
 #define DVFS_OPP_COUNT(hdr)	((le32_to_cpu(hdr) >> 8) & 0xff)
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/8] firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Since Amlogic SoCs supports more than 8 OPPs per domains, we need increase
the OPP structure size.

This patch increases the MAX_DVFS_OPPS to 16.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 9e9b022450eb..21542a32ad9f 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -63,7 +63,7 @@
 #define SCPI_SLOT		0
 
 #define MAX_DVFS_DOMAINS	8
-#define MAX_DVFS_OPPS		8
+#define MAX_DVFS_OPPS		16
 #define DVFS_LATENCY(hdr)	(le32_to_cpu(hdr) >> 16)
 #define DVFS_OPP_COUNT(hdr)	((le32_to_cpu(hdr) >> 8) & 0xff)
 
-- 
1.9.1

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

This patch adds support for the Legacy SCPI protocol that is available
in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some
Rockchip SoC are also known to use this version of protocol with
extended vendor commands.

In order to support the legacy SCPI protocol variant, we need to add the
structures and macros definitions that varies against the final SCPI v1.0
specification.

We add the indirection table for legacy commands set so that it can
co-exist with the standard v1.0 command set. It also adds bitmap field
for channel selection since the legacy protocol mandates to send only
selected subset of the commands on the high priority channel.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla at arm.com: Updated the changelog]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 174 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a32ad9f..2982bc7b8c33 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
 #define CMD_TOKEN_ID_MASK	0xff
 #define CMD_DATA_SIZE_SHIFT	16
 #define CMD_DATA_SIZE_MASK	0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT	20
+#define CMD_LEGACY_DATA_SIZE_MASK	0x1ff
 #define PACK_SCPI_CMD(cmd_id, tx_sz)			\
 	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |	\
 	(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
 #define ADD_SCPI_TOKEN(cmd, token)			\
 	((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)				\
+	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |			       \
+	(((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
 
 #define CMD_SIZE(cmd)	(((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)	(((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+					CMD_LEGACY_DATA_SIZE_MASK)
 #define CMD_UNIQ_MASK	(CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
 #define CMD_XTRACT_UNIQ(cmd)	((cmd) & CMD_UNIQ_MASK)
 
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+	LEGACY_SCPI_CMD_INVALID			= 0x00,
+	LEGACY_SCPI_CMD_SCPI_READY		= 0x01,
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES	= 0x02,
+	LEGACY_SCPI_CMD_EVENT			= 0x03,
+	LEGACY_SCPI_CMD_SET_CSS_PWR_STATE	= 0x04,
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE	= 0x05,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT	= 0x06,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT	= 0x07,
+	LEGACY_SCPI_CMD_SYS_PWR_STATE		= 0x08,
+	LEGACY_SCPI_CMD_L2_READY		= 0x09,
+	LEGACY_SCPI_CMD_SET_AP_TIMER		= 0x0a,
+	LEGACY_SCPI_CMD_CANCEL_AP_TIME		= 0x0b,
+	LEGACY_SCPI_CMD_DVFS_CAPABILITIES	= 0x0c,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO		= 0x0d,
+	LEGACY_SCPI_CMD_SET_DVFS		= 0x0e,
+	LEGACY_SCPI_CMD_GET_DVFS		= 0x0f,
+	LEGACY_SCPI_CMD_GET_DVFS_STAT		= 0x10,
+	LEGACY_SCPI_CMD_SET_RTC			= 0x11,
+	LEGACY_SCPI_CMD_GET_RTC			= 0x12,
+	LEGACY_SCPI_CMD_CLOCK_CAPABILITIES	= 0x13,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX		= 0x14,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE		= 0x15,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE		= 0x16,
+	LEGACY_SCPI_CMD_PSU_CAPABILITIES	= 0x17,
+	LEGACY_SCPI_CMD_SET_PSU			= 0x18,
+	LEGACY_SCPI_CMD_GET_PSU			= 0x19,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES	= 0x1a,
+	LEGACY_SCPI_CMD_SENSOR_INFO		= 0x1b,
+	LEGACY_SCPI_CMD_SENSOR_VALUE		= 0x1c,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC	= 0x1d,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS	= 0x1e,
+	LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE	= 0x1f,
+	LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_RTC,
+	LEGACY_SCPI_CMD_GET_RTC,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_PSU,
+	LEGACY_SCPI_CMD_GET_PSU,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
 enum scpi_drv_cmds {
 	CMD_SCPI_CAPABILITIES = 0,
 	CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
 	SCPI_CMD_GET_DEVICE_PWR_STATE,
 };
 
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+	-1, /* GET_CLOCK_INFO */
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+	LEGACY_SCPI_CMD_SENSOR_INFO,
+	LEGACY_SCPI_CMD_SENSOR_VALUE,
+	-1, /* SET_DEVICE_PWR_STATE */
+	-1, /* GET_DEVICE_PWR_STATE */
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
 struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
+	bool is_legacy;
 	int num_chans;
 	int *commands;
+	DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
 	u8 payload[0];
 } __packed;
 
+struct legacy_scpi_shared_mem {
+	__le32 status;
+	u8 payload[0];
+} __packed;
+
 struct scp_capabilities {
 	__le32 protocol_version;
 	__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
 	__le32 rate;
 } __packed;
 
+struct legacy_clk_set_value {
+	__le32 rate;
+	__le16 id;
+	__le16 reserved;
+} __packed;
+
 struct dvfs_info {
 	__le32 header;
 	struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
 		return;
 	}
 
-	list_for_each_entry(t, &ch->rx_pending, node)
-		if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
-			list_del(&t->node);
-			match = t;
-			break;
-		}
+	/* Command type is not replied by the SCP Firmware in legacy Mode
+	 * We should consider that command is the head of pending RX commands
+	 * if the list is not empty. In TX only mode, the list would be empty.
+	 */
+	if (scpi_info->is_legacy) {
+		match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+					 node);
+		list_del(&match->node);
+	} else {
+		list_for_each_entry(t, &ch->rx_pending, node)
+			if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+				list_del(&t->node);
+				match = t;
+				break;
+			}
+	}
 	/* check if wait_for_completion is in progress or timed-out */
 	if (match && !completion_done(&match->done)) {
-		struct scpi_shared_mem *mem = ch->rx_payload;
-		unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+		unsigned int len;
+
+		if (scpi_info->is_legacy) {
+			struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+			/* RX Length is not replied by the legacy Firmware */
+			len = match->rx_len;
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		} else {
+			struct scpi_shared_mem *mem = ch->rx_payload;
+
+			len = min(match->rx_len, CMD_SIZE(cmd));
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		}
 
-		match->status = le32_to_cpu(mem->status);
-		memcpy_fromio(match->rx_buf, mem->payload, len);
 		if (match->rx_len > len)
 			memset(match->rx_buf + len, 0, match->rx_len - len);
 		complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
 {
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = ch->rx_payload;
-	u32 cmd = le32_to_cpu(mem->command);
+	u32 cmd = 0;
+
+	if (!scpi_info->is_legacy)
+		cmd = le32_to_cpu(mem->command);
 
 	scpi_process_cmd(ch, cmd);
 }
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	if (t->tx_buf)
-		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	if (t->tx_buf) {
+		if (scpi_info->is_legacy)
+			memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+		else
+			memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	}
+
 	if (t->rx_buf) {
 		if (!(++ch->token))
 			++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
-	mem->command = cpu_to_le32(t->cmd);
+
+	if (!scpi_info->is_legacy)
+		mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 
 	cmd = scpi_info->commands[idx];
 
-	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+	if (scpi_info->is_legacy)
+		chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+	else
+		chan = atomic_inc_return(&scpi_info->next_chan) %
+			scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
 	msg = get_scpi_xfer(scpi_chan);
 	if (!msg)
 		return -ENOMEM;
 
-	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	if (scpi_info->is_legacy) {
+		msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+		msg->slot = msg->cmd;
+	} else {
+		msg->slot = BIT(SCPI_SLOT);
+		msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	}
 	msg->tx_buf = tx_buf;
 	msg->tx_len = tx_len;
 	msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 				 &stat, sizeof(stat));
 }
 
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+	int stat;
+	struct legacy_clk_set_value clk = {
+		.id = cpu_to_le16(clk_id),
+		.rate = cpu_to_le32(rate)
+	};
+
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+				 &stat, sizeof(stat));
+}
+
 static int scpi_dvfs_get_idx(u8 domain)
 {
 	int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scpi_info);
 
+	if (scpi_info->is_legacy) {
+		/* Replace with legacy variants */
+		scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+		scpi_info->commands = scpi_legacy_commands;
+
+		/* Fill priority bitmap */
+		for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+			set_bit(legacy_hpriority_cmds[idx],
+				scpi_info->cmd_priority);
+	}
+
 	ret = scpi_init_versions(scpi_info);
 	if (ret) {
 		dev_err(dev, "incorrect or no SCP firmware found\n");
-- 
1.9.1

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

This patch adds support for the Legacy SCPI protocol that is available
in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some
Rockchip SoC are also known to use this version of protocol with
extended vendor commands.

In order to support the legacy SCPI protocol variant, we need to add the
structures and macros definitions that varies against the final SCPI v1.0
specification.

We add the indirection table for legacy commands set so that it can
co-exist with the standard v1.0 command set. It also adds bitmap field
for channel selection since the legacy protocol mandates to send only
selected subset of the commands on the high priority channel.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla@arm.com: Updated the changelog]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 174 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a32ad9f..2982bc7b8c33 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
 #define CMD_TOKEN_ID_MASK	0xff
 #define CMD_DATA_SIZE_SHIFT	16
 #define CMD_DATA_SIZE_MASK	0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT	20
+#define CMD_LEGACY_DATA_SIZE_MASK	0x1ff
 #define PACK_SCPI_CMD(cmd_id, tx_sz)			\
 	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |	\
 	(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
 #define ADD_SCPI_TOKEN(cmd, token)			\
 	((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)				\
+	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |			       \
+	(((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
 
 #define CMD_SIZE(cmd)	(((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)	(((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+					CMD_LEGACY_DATA_SIZE_MASK)
 #define CMD_UNIQ_MASK	(CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
 #define CMD_XTRACT_UNIQ(cmd)	((cmd) & CMD_UNIQ_MASK)
 
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+	LEGACY_SCPI_CMD_INVALID			= 0x00,
+	LEGACY_SCPI_CMD_SCPI_READY		= 0x01,
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES	= 0x02,
+	LEGACY_SCPI_CMD_EVENT			= 0x03,
+	LEGACY_SCPI_CMD_SET_CSS_PWR_STATE	= 0x04,
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE	= 0x05,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT	= 0x06,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT	= 0x07,
+	LEGACY_SCPI_CMD_SYS_PWR_STATE		= 0x08,
+	LEGACY_SCPI_CMD_L2_READY		= 0x09,
+	LEGACY_SCPI_CMD_SET_AP_TIMER		= 0x0a,
+	LEGACY_SCPI_CMD_CANCEL_AP_TIME		= 0x0b,
+	LEGACY_SCPI_CMD_DVFS_CAPABILITIES	= 0x0c,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO		= 0x0d,
+	LEGACY_SCPI_CMD_SET_DVFS		= 0x0e,
+	LEGACY_SCPI_CMD_GET_DVFS		= 0x0f,
+	LEGACY_SCPI_CMD_GET_DVFS_STAT		= 0x10,
+	LEGACY_SCPI_CMD_SET_RTC			= 0x11,
+	LEGACY_SCPI_CMD_GET_RTC			= 0x12,
+	LEGACY_SCPI_CMD_CLOCK_CAPABILITIES	= 0x13,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX		= 0x14,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE		= 0x15,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE		= 0x16,
+	LEGACY_SCPI_CMD_PSU_CAPABILITIES	= 0x17,
+	LEGACY_SCPI_CMD_SET_PSU			= 0x18,
+	LEGACY_SCPI_CMD_GET_PSU			= 0x19,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES	= 0x1a,
+	LEGACY_SCPI_CMD_SENSOR_INFO		= 0x1b,
+	LEGACY_SCPI_CMD_SENSOR_VALUE		= 0x1c,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC	= 0x1d,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS	= 0x1e,
+	LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE	= 0x1f,
+	LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_RTC,
+	LEGACY_SCPI_CMD_GET_RTC,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_PSU,
+	LEGACY_SCPI_CMD_GET_PSU,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
 enum scpi_drv_cmds {
 	CMD_SCPI_CAPABILITIES = 0,
 	CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
 	SCPI_CMD_GET_DEVICE_PWR_STATE,
 };
 
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+	-1, /* GET_CLOCK_INFO */
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+	LEGACY_SCPI_CMD_SENSOR_INFO,
+	LEGACY_SCPI_CMD_SENSOR_VALUE,
+	-1, /* SET_DEVICE_PWR_STATE */
+	-1, /* GET_DEVICE_PWR_STATE */
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
 struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
+	bool is_legacy;
 	int num_chans;
 	int *commands;
+	DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
 	u8 payload[0];
 } __packed;
 
+struct legacy_scpi_shared_mem {
+	__le32 status;
+	u8 payload[0];
+} __packed;
+
 struct scp_capabilities {
 	__le32 protocol_version;
 	__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
 	__le32 rate;
 } __packed;
 
+struct legacy_clk_set_value {
+	__le32 rate;
+	__le16 id;
+	__le16 reserved;
+} __packed;
+
 struct dvfs_info {
 	__le32 header;
 	struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
 		return;
 	}
 
-	list_for_each_entry(t, &ch->rx_pending, node)
-		if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
-			list_del(&t->node);
-			match = t;
-			break;
-		}
+	/* Command type is not replied by the SCP Firmware in legacy Mode
+	 * We should consider that command is the head of pending RX commands
+	 * if the list is not empty. In TX only mode, the list would be empty.
+	 */
+	if (scpi_info->is_legacy) {
+		match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+					 node);
+		list_del(&match->node);
+	} else {
+		list_for_each_entry(t, &ch->rx_pending, node)
+			if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+				list_del(&t->node);
+				match = t;
+				break;
+			}
+	}
 	/* check if wait_for_completion is in progress or timed-out */
 	if (match && !completion_done(&match->done)) {
-		struct scpi_shared_mem *mem = ch->rx_payload;
-		unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+		unsigned int len;
+
+		if (scpi_info->is_legacy) {
+			struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+			/* RX Length is not replied by the legacy Firmware */
+			len = match->rx_len;
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		} else {
+			struct scpi_shared_mem *mem = ch->rx_payload;
+
+			len = min(match->rx_len, CMD_SIZE(cmd));
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		}
 
-		match->status = le32_to_cpu(mem->status);
-		memcpy_fromio(match->rx_buf, mem->payload, len);
 		if (match->rx_len > len)
 			memset(match->rx_buf + len, 0, match->rx_len - len);
 		complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
 {
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = ch->rx_payload;
-	u32 cmd = le32_to_cpu(mem->command);
+	u32 cmd = 0;
+
+	if (!scpi_info->is_legacy)
+		cmd = le32_to_cpu(mem->command);
 
 	scpi_process_cmd(ch, cmd);
 }
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	if (t->tx_buf)
-		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	if (t->tx_buf) {
+		if (scpi_info->is_legacy)
+			memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+		else
+			memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	}
+
 	if (t->rx_buf) {
 		if (!(++ch->token))
 			++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
-	mem->command = cpu_to_le32(t->cmd);
+
+	if (!scpi_info->is_legacy)
+		mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 
 	cmd = scpi_info->commands[idx];
 
-	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+	if (scpi_info->is_legacy)
+		chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+	else
+		chan = atomic_inc_return(&scpi_info->next_chan) %
+			scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
 	msg = get_scpi_xfer(scpi_chan);
 	if (!msg)
 		return -ENOMEM;
 
-	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	if (scpi_info->is_legacy) {
+		msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+		msg->slot = msg->cmd;
+	} else {
+		msg->slot = BIT(SCPI_SLOT);
+		msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	}
 	msg->tx_buf = tx_buf;
 	msg->tx_len = tx_len;
 	msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 				 &stat, sizeof(stat));
 }
 
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+	int stat;
+	struct legacy_clk_set_value clk = {
+		.id = cpu_to_le16(clk_id),
+		.rate = cpu_to_le32(rate)
+	};
+
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+				 &stat, sizeof(stat));
+}
+
 static int scpi_dvfs_get_idx(u8 domain)
 {
 	int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scpi_info);
 
+	if (scpi_info->is_legacy) {
+		/* Replace with legacy variants */
+		scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+		scpi_info->commands = scpi_legacy_commands;
+
+		/* Fill priority bitmap */
+		for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+			set_bit(legacy_hpriority_cmds[idx],
+				scpi_info->cmd_priority);
+	}
+
 	ret = scpi_init_versions(scpi_info);
 	if (ret) {
 		dev_err(dev, "incorrect or no SCP firmware found\n");
-- 
1.9.1

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

This patch adds support for the Legacy SCPI protocol that is available
in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some
Rockchip SoC are also known to use this version of protocol with
extended vendor commands.

In order to support the legacy SCPI protocol variant, we need to add the
structures and macros definitions that varies against the final SCPI v1.0
specification.

We add the indirection table for legacy commands set so that it can
co-exist with the standard v1.0 command set. It also adds bitmap field
for channel selection since the legacy protocol mandates to send only
selected subset of the commands on the high priority channel.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla@arm.com: Updated the changelog]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 174 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a32ad9f..2982bc7b8c33 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
 #define CMD_TOKEN_ID_MASK	0xff
 #define CMD_DATA_SIZE_SHIFT	16
 #define CMD_DATA_SIZE_MASK	0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT	20
+#define CMD_LEGACY_DATA_SIZE_MASK	0x1ff
 #define PACK_SCPI_CMD(cmd_id, tx_sz)			\
 	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |	\
 	(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
 #define ADD_SCPI_TOKEN(cmd, token)			\
 	((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)				\
+	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |			       \
+	(((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
 
 #define CMD_SIZE(cmd)	(((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)	(((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+					CMD_LEGACY_DATA_SIZE_MASK)
 #define CMD_UNIQ_MASK	(CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
 #define CMD_XTRACT_UNIQ(cmd)	((cmd) & CMD_UNIQ_MASK)
 
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+	LEGACY_SCPI_CMD_INVALID			= 0x00,
+	LEGACY_SCPI_CMD_SCPI_READY		= 0x01,
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES	= 0x02,
+	LEGACY_SCPI_CMD_EVENT			= 0x03,
+	LEGACY_SCPI_CMD_SET_CSS_PWR_STATE	= 0x04,
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE	= 0x05,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT	= 0x06,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT	= 0x07,
+	LEGACY_SCPI_CMD_SYS_PWR_STATE		= 0x08,
+	LEGACY_SCPI_CMD_L2_READY		= 0x09,
+	LEGACY_SCPI_CMD_SET_AP_TIMER		= 0x0a,
+	LEGACY_SCPI_CMD_CANCEL_AP_TIME		= 0x0b,
+	LEGACY_SCPI_CMD_DVFS_CAPABILITIES	= 0x0c,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO		= 0x0d,
+	LEGACY_SCPI_CMD_SET_DVFS		= 0x0e,
+	LEGACY_SCPI_CMD_GET_DVFS		= 0x0f,
+	LEGACY_SCPI_CMD_GET_DVFS_STAT		= 0x10,
+	LEGACY_SCPI_CMD_SET_RTC			= 0x11,
+	LEGACY_SCPI_CMD_GET_RTC			= 0x12,
+	LEGACY_SCPI_CMD_CLOCK_CAPABILITIES	= 0x13,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX		= 0x14,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE		= 0x15,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE		= 0x16,
+	LEGACY_SCPI_CMD_PSU_CAPABILITIES	= 0x17,
+	LEGACY_SCPI_CMD_SET_PSU			= 0x18,
+	LEGACY_SCPI_CMD_GET_PSU			= 0x19,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES	= 0x1a,
+	LEGACY_SCPI_CMD_SENSOR_INFO		= 0x1b,
+	LEGACY_SCPI_CMD_SENSOR_VALUE		= 0x1c,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC	= 0x1d,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS	= 0x1e,
+	LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE	= 0x1f,
+	LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_RTC,
+	LEGACY_SCPI_CMD_GET_RTC,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_PSU,
+	LEGACY_SCPI_CMD_GET_PSU,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
 enum scpi_drv_cmds {
 	CMD_SCPI_CAPABILITIES = 0,
 	CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
 	SCPI_CMD_GET_DEVICE_PWR_STATE,
 };
 
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+	-1, /* GET_CLOCK_INFO */
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+	LEGACY_SCPI_CMD_SENSOR_INFO,
+	LEGACY_SCPI_CMD_SENSOR_VALUE,
+	-1, /* SET_DEVICE_PWR_STATE */
+	-1, /* GET_DEVICE_PWR_STATE */
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
 struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
+	bool is_legacy;
 	int num_chans;
 	int *commands;
+	DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
 	u8 payload[0];
 } __packed;
 
+struct legacy_scpi_shared_mem {
+	__le32 status;
+	u8 payload[0];
+} __packed;
+
 struct scp_capabilities {
 	__le32 protocol_version;
 	__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
 	__le32 rate;
 } __packed;
 
+struct legacy_clk_set_value {
+	__le32 rate;
+	__le16 id;
+	__le16 reserved;
+} __packed;
+
 struct dvfs_info {
 	__le32 header;
 	struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
 		return;
 	}
 
-	list_for_each_entry(t, &ch->rx_pending, node)
-		if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
-			list_del(&t->node);
-			match = t;
-			break;
-		}
+	/* Command type is not replied by the SCP Firmware in legacy Mode
+	 * We should consider that command is the head of pending RX commands
+	 * if the list is not empty. In TX only mode, the list would be empty.
+	 */
+	if (scpi_info->is_legacy) {
+		match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+					 node);
+		list_del(&match->node);
+	} else {
+		list_for_each_entry(t, &ch->rx_pending, node)
+			if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+				list_del(&t->node);
+				match = t;
+				break;
+			}
+	}
 	/* check if wait_for_completion is in progress or timed-out */
 	if (match && !completion_done(&match->done)) {
-		struct scpi_shared_mem *mem = ch->rx_payload;
-		unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+		unsigned int len;
+
+		if (scpi_info->is_legacy) {
+			struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+			/* RX Length is not replied by the legacy Firmware */
+			len = match->rx_len;
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		} else {
+			struct scpi_shared_mem *mem = ch->rx_payload;
+
+			len = min(match->rx_len, CMD_SIZE(cmd));
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		}
 
-		match->status = le32_to_cpu(mem->status);
-		memcpy_fromio(match->rx_buf, mem->payload, len);
 		if (match->rx_len > len)
 			memset(match->rx_buf + len, 0, match->rx_len - len);
 		complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
 {
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = ch->rx_payload;
-	u32 cmd = le32_to_cpu(mem->command);
+	u32 cmd = 0;
+
+	if (!scpi_info->is_legacy)
+		cmd = le32_to_cpu(mem->command);
 
 	scpi_process_cmd(ch, cmd);
 }
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	if (t->tx_buf)
-		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	if (t->tx_buf) {
+		if (scpi_info->is_legacy)
+			memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+		else
+			memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	}
+
 	if (t->rx_buf) {
 		if (!(++ch->token))
 			++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
-	mem->command = cpu_to_le32(t->cmd);
+
+	if (!scpi_info->is_legacy)
+		mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 
 	cmd = scpi_info->commands[idx];
 
-	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+	if (scpi_info->is_legacy)
+		chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+	else
+		chan = atomic_inc_return(&scpi_info->next_chan) %
+			scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
 	msg = get_scpi_xfer(scpi_chan);
 	if (!msg)
 		return -ENOMEM;
 
-	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	if (scpi_info->is_legacy) {
+		msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+		msg->slot = msg->cmd;
+	} else {
+		msg->slot = BIT(SCPI_SLOT);
+		msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	}
 	msg->tx_buf = tx_buf;
 	msg->tx_len = tx_len;
 	msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 				 &stat, sizeof(stat));
 }
 
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+	int stat;
+	struct legacy_clk_set_value clk = {
+		.id = cpu_to_le16(clk_id),
+		.rate = cpu_to_le32(rate)
+	};
+
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+				 &stat, sizeof(stat));
+}
+
 static int scpi_dvfs_get_idx(u8 domain)
 {
 	int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scpi_info);
 
+	if (scpi_info->is_legacy) {
+		/* Replace with legacy variants */
+		scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+		scpi_info->commands = scpi_legacy_commands;
+
+		/* Fill priority bitmap */
+		for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+			set_bit(legacy_hpriority_cmds[idx],
+				scpi_info->cmd_priority);
+	}
+
 	ret = scpi_init_versions(scpi_info);
 	if (ret) {
 		dev_err(dev, "incorrect or no SCP firmware found\n");
-- 
1.9.1

[PATCH v5 3/8] firmware: arm_scpi: add alternative legacy structures, functions and macros

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

This patch adds support for the Legacy SCPI protocol that is available
in very early JUNO versions and shipped Amlogic ARMv8 based SoCs. Some
Rockchip SoC are also known to use this version of protocol with
extended vendor commands.

In order to support the legacy SCPI protocol variant, we need to add the
structures and macros definitions that varies against the final SCPI v1.0
specification.

We add the indirection table for legacy commands set so that it can
co-exist with the standard v1.0 command set. It also adds bitmap field
for channel selection since the legacy protocol mandates to send only
selected subset of the commands on the high priority channel.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla at arm.com: Updated the changelog]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 192 +++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 174 insertions(+), 18 deletions(-)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 21542a32ad9f..2982bc7b8c33 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -50,13 +50,20 @@
 #define CMD_TOKEN_ID_MASK	0xff
 #define CMD_DATA_SIZE_SHIFT	16
 #define CMD_DATA_SIZE_MASK	0x1ff
+#define CMD_LEGACY_DATA_SIZE_SHIFT	20
+#define CMD_LEGACY_DATA_SIZE_MASK	0x1ff
 #define PACK_SCPI_CMD(cmd_id, tx_sz)			\
 	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |	\
 	(((tx_sz) & CMD_DATA_SIZE_MASK) << CMD_DATA_SIZE_SHIFT))
 #define ADD_SCPI_TOKEN(cmd, token)			\
 	((cmd) |= (((token) & CMD_TOKEN_ID_MASK) << CMD_TOKEN_ID_SHIFT))
+#define PACK_LEGACY_SCPI_CMD(cmd_id, tx_sz)				\
+	((((cmd_id) & CMD_ID_MASK) << CMD_ID_SHIFT) |			       \
+	(((tx_sz) & CMD_LEGACY_DATA_SIZE_MASK) << CMD_LEGACY_DATA_SIZE_SHIFT))
 
 #define CMD_SIZE(cmd)	(((cmd) >> CMD_DATA_SIZE_SHIFT) & CMD_DATA_SIZE_MASK)
+#define CMD_LEGACY_SIZE(cmd)	(((cmd) >> CMD_LEGACY_DATA_SIZE_SHIFT) & \
+					CMD_LEGACY_DATA_SIZE_MASK)
 #define CMD_UNIQ_MASK	(CMD_TOKEN_ID_MASK << CMD_TOKEN_ID_SHIFT | CMD_ID_MASK)
 #define CMD_XTRACT_UNIQ(cmd)	((cmd) & CMD_UNIQ_MASK)
 
@@ -133,7 +140,62 @@ enum scpi_std_cmd {
 	SCPI_CMD_COUNT
 };
 
-/* List of all commands used by this driver, used as indices */
+/* SCPI Legacy Commands */
+enum legacy_scpi_std_cmd {
+	LEGACY_SCPI_CMD_INVALID			= 0x00,
+	LEGACY_SCPI_CMD_SCPI_READY		= 0x01,
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES	= 0x02,
+	LEGACY_SCPI_CMD_EVENT			= 0x03,
+	LEGACY_SCPI_CMD_SET_CSS_PWR_STATE	= 0x04,
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE	= 0x05,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT	= 0x06,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT	= 0x07,
+	LEGACY_SCPI_CMD_SYS_PWR_STATE		= 0x08,
+	LEGACY_SCPI_CMD_L2_READY		= 0x09,
+	LEGACY_SCPI_CMD_SET_AP_TIMER		= 0x0a,
+	LEGACY_SCPI_CMD_CANCEL_AP_TIME		= 0x0b,
+	LEGACY_SCPI_CMD_DVFS_CAPABILITIES	= 0x0c,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO		= 0x0d,
+	LEGACY_SCPI_CMD_SET_DVFS		= 0x0e,
+	LEGACY_SCPI_CMD_GET_DVFS		= 0x0f,
+	LEGACY_SCPI_CMD_GET_DVFS_STAT		= 0x10,
+	LEGACY_SCPI_CMD_SET_RTC			= 0x11,
+	LEGACY_SCPI_CMD_GET_RTC			= 0x12,
+	LEGACY_SCPI_CMD_CLOCK_CAPABILITIES	= 0x13,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX		= 0x14,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE		= 0x15,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE		= 0x16,
+	LEGACY_SCPI_CMD_PSU_CAPABILITIES	= 0x17,
+	LEGACY_SCPI_CMD_SET_PSU			= 0x18,
+	LEGACY_SCPI_CMD_GET_PSU			= 0x19,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES	= 0x1a,
+	LEGACY_SCPI_CMD_SENSOR_INFO		= 0x1b,
+	LEGACY_SCPI_CMD_SENSOR_VALUE		= 0x1c,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC	= 0x1d,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS	= 0x1e,
+	LEGACY_SCPI_CMD_SENSOR_ASYNC_VALUE	= 0x1f,
+	LEGACY_SCPI_CMD_COUNT
+};
+
+/* List all commands that are required to go through the high priority link */
+static int legacy_hpriority_cmds[] = {
+	LEGACY_SCPI_CMD_GET_CSS_PWR_STATE,
+	LEGACY_SCPI_CMD_CFG_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_GET_PWR_STATE_STAT,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_RTC,
+	LEGACY_SCPI_CMD_GET_RTC,
+	LEGACY_SCPI_CMD_SET_CLOCK_INDEX,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_PSU,
+	LEGACY_SCPI_CMD_GET_PSU,
+	LEGACY_SCPI_CMD_SENSOR_CFG_PERIODIC,
+	LEGACY_SCPI_CMD_SENSOR_CFG_BOUNDS,
+};
+
+/* List all commands used by this driver, used as indexes */
 enum scpi_drv_cmds {
 	CMD_SCPI_CAPABILITIES = 0,
 	CMD_GET_CLOCK_INFO,
@@ -165,6 +227,21 @@ enum scpi_drv_cmds {
 	SCPI_CMD_GET_DEVICE_PWR_STATE,
 };
 
+static int scpi_legacy_commands[CMD_MAX_COUNT] = {
+	LEGACY_SCPI_CMD_SCPI_CAPABILITIES,
+	-1, /* GET_CLOCK_INFO */
+	LEGACY_SCPI_CMD_GET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_SET_CLOCK_VALUE,
+	LEGACY_SCPI_CMD_GET_DVFS,
+	LEGACY_SCPI_CMD_SET_DVFS,
+	LEGACY_SCPI_CMD_GET_DVFS_INFO,
+	LEGACY_SCPI_CMD_SENSOR_CAPABILITIES,
+	LEGACY_SCPI_CMD_SENSOR_INFO,
+	LEGACY_SCPI_CMD_SENSOR_VALUE,
+	-1, /* SET_DEVICE_PWR_STATE */
+	-1, /* GET_DEVICE_PWR_STATE */
+};
+
 struct scpi_xfer {
 	u32 slot; /* has to be first element */
 	u32 cmd;
@@ -193,8 +270,10 @@ struct scpi_chan {
 struct scpi_drvinfo {
 	u32 protocol_version;
 	u32 firmware_version;
+	bool is_legacy;
 	int num_chans;
 	int *commands;
+	DECLARE_BITMAP(cmd_priority, LEGACY_SCPI_CMD_COUNT);
 	atomic_t next_chan;
 	struct scpi_ops *scpi_ops;
 	struct scpi_chan *channels;
@@ -211,6 +290,11 @@ struct scpi_shared_mem {
 	u8 payload[0];
 } __packed;
 
+struct legacy_scpi_shared_mem {
+	__le32 status;
+	u8 payload[0];
+} __packed;
+
 struct scp_capabilities {
 	__le32 protocol_version;
 	__le32 event_version;
@@ -236,6 +320,12 @@ struct clk_set_value {
 	__le32 rate;
 } __packed;
 
+struct legacy_clk_set_value {
+	__le32 rate;
+	__le16 id;
+	__le16 reserved;
+} __packed;
+
 struct dvfs_info {
 	__le32 header;
 	struct {
@@ -307,19 +397,43 @@ static void scpi_process_cmd(struct scpi_chan *ch, u32 cmd)
 		return;
 	}
 
-	list_for_each_entry(t, &ch->rx_pending, node)
-		if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
-			list_del(&t->node);
-			match = t;
-			break;
-		}
+	/* Command type is not replied by the SCP Firmware in legacy Mode
+	 * We should consider that command is the head of pending RX commands
+	 * if the list is not empty. In TX only mode, the list would be empty.
+	 */
+	if (scpi_info->is_legacy) {
+		match = list_first_entry(&ch->rx_pending, struct scpi_xfer,
+					 node);
+		list_del(&match->node);
+	} else {
+		list_for_each_entry(t, &ch->rx_pending, node)
+			if (CMD_XTRACT_UNIQ(t->cmd) == CMD_XTRACT_UNIQ(cmd)) {
+				list_del(&t->node);
+				match = t;
+				break;
+			}
+	}
 	/* check if wait_for_completion is in progress or timed-out */
 	if (match && !completion_done(&match->done)) {
-		struct scpi_shared_mem *mem = ch->rx_payload;
-		unsigned int len = min(match->rx_len, CMD_SIZE(cmd));
+		unsigned int len;
+
+		if (scpi_info->is_legacy) {
+			struct legacy_scpi_shared_mem *mem = ch->rx_payload;
+
+			/* RX Length is not replied by the legacy Firmware */
+			len = match->rx_len;
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		} else {
+			struct scpi_shared_mem *mem = ch->rx_payload;
+
+			len = min(match->rx_len, CMD_SIZE(cmd));
+
+			match->status = le32_to_cpu(mem->status);
+			memcpy_fromio(match->rx_buf, mem->payload, len);
+		}
 
-		match->status = le32_to_cpu(mem->status);
-		memcpy_fromio(match->rx_buf, mem->payload, len);
 		if (match->rx_len > len)
 			memset(match->rx_buf + len, 0, match->rx_len - len);
 		complete(&match->done);
@@ -331,7 +445,10 @@ static void scpi_handle_remote_msg(struct mbox_client *c, void *msg)
 {
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = ch->rx_payload;
-	u32 cmd = le32_to_cpu(mem->command);
+	u32 cmd = 0;
+
+	if (!scpi_info->is_legacy)
+		cmd = le32_to_cpu(mem->command);
 
 	scpi_process_cmd(ch, cmd);
 }
@@ -343,8 +460,13 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 	struct scpi_chan *ch = container_of(c, struct scpi_chan, cl);
 	struct scpi_shared_mem *mem = (struct scpi_shared_mem *)ch->tx_payload;
 
-	if (t->tx_buf)
-		memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	if (t->tx_buf) {
+		if (scpi_info->is_legacy)
+			memcpy_toio(ch->tx_payload, t->tx_buf, t->tx_len);
+		else
+			memcpy_toio(mem->payload, t->tx_buf, t->tx_len);
+	}
+
 	if (t->rx_buf) {
 		if (!(++ch->token))
 			++ch->token;
@@ -353,7 +475,9 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
 		list_add_tail(&t->node, &ch->rx_pending);
 		spin_unlock_irqrestore(&ch->rx_lock, flags);
 	}
-	mem->command = cpu_to_le32(t->cmd);
+
+	if (!scpi_info->is_legacy)
+		mem->command = cpu_to_le32(t->cmd);
 }
 
 static struct scpi_xfer *get_scpi_xfer(struct scpi_chan *ch)
@@ -392,15 +516,24 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
 
 	cmd = scpi_info->commands[idx];
 
-	chan = atomic_inc_return(&scpi_info->next_chan) % scpi_info->num_chans;
+	if (scpi_info->is_legacy)
+		chan = test_bit(cmd, scpi_info->cmd_priority) ? 1 : 0;
+	else
+		chan = atomic_inc_return(&scpi_info->next_chan) %
+			scpi_info->num_chans;
 	scpi_chan = scpi_info->channels + chan;
 
 	msg = get_scpi_xfer(scpi_chan);
 	if (!msg)
 		return -ENOMEM;
 
-	msg->slot = BIT(SCPI_SLOT);
-	msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	if (scpi_info->is_legacy) {
+		msg->cmd = PACK_LEGACY_SCPI_CMD(cmd, tx_len);
+		msg->slot = msg->cmd;
+	} else {
+		msg->slot = BIT(SCPI_SLOT);
+		msg->cmd = PACK_SCPI_CMD(cmd, tx_len);
+	}
 	msg->tx_buf = tx_buf;
 	msg->tx_len = tx_len;
 	msg->rx_buf = rx_buf;
@@ -470,6 +603,18 @@ static int scpi_clk_set_val(u16 clk_id, unsigned long rate)
 				 &stat, sizeof(stat));
 }
 
+static int legacy_scpi_clk_set_val(u16 clk_id, unsigned long rate)
+{
+	int stat;
+	struct legacy_clk_set_value clk = {
+		.id = cpu_to_le16(clk_id),
+		.rate = cpu_to_le32(rate)
+	};
+
+	return scpi_send_message(CMD_SET_CLOCK_VALUE, &clk, sizeof(clk),
+				 &stat, sizeof(stat));
+}
+
 static int scpi_dvfs_get_idx(u8 domain)
 {
 	int ret;
@@ -800,6 +945,17 @@ static int scpi_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, scpi_info);
 
+	if (scpi_info->is_legacy) {
+		/* Replace with legacy variants */
+		scpi_ops.clk_set_val = legacy_scpi_clk_set_val;
+		scpi_info->commands = scpi_legacy_commands;
+
+		/* Fill priority bitmap */
+		for (idx = 0; idx < ARRAY_SIZE(legacy_hpriority_cmds); idx++)
+			set_bit(legacy_hpriority_cmds[idx],
+				scpi_info->cmd_priority);
+	}
+
 	ret = scpi_init_versions(scpi_info);
 	if (ret) {
 		dev_err(dev, "incorrect or no SCP firmware found\n");
-- 
1.9.1

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is
not supported, failover by using 0.0.0 version.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla at arm.com: changed the subject]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 2982bc7b8c33..902233642bd3 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -783,6 +783,10 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
 		info->firmware_version = le32_to_cpu(caps.platform_version);
 	}
+	/* Ignore error if not implemented */
+	if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
+		return 0;
+
 	return ret;
 }
 
-- 
1.9.1

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is
not supported, failover by using 0.0.0 version.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla@arm.com: changed the subject]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 2982bc7b8c33..902233642bd3 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -783,6 +783,10 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
 		info->firmware_version = le32_to_cpu(caps.platform_version);
 	}
+	/* Ignore error if not implemented */
+	if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
+		return 0;
+
 	return ret;
 }
 
-- 
1.9.1

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is
not supported, failover by using 0.0.0 version.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla@arm.com: changed the subject]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 2982bc7b8c33..902233642bd3 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -783,6 +783,10 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
 		info->firmware_version = le32_to_cpu(caps.platform_version);
 	}
+	/* Ignore error if not implemented */
+	if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
+		return 0;
+
 	return ret;
 }
 
-- 
1.9.1

[PATCH v5 4/8] firmware: arm_scpi: allow firmware with get_capabilities not implemented

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

On Amlogic SCPI legacy implementation, the GET_CAPABILITIES command is
not supported, failover by using 0.0.0 version.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
[sudeep.holla at arm.com: changed the subject]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 2982bc7b8c33..902233642bd3 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -783,6 +783,10 @@ static int scpi_init_versions(struct scpi_drvinfo *info)
 		info->protocol_version = le32_to_cpu(caps.protocol_version);
 		info->firmware_version = le32_to_cpu(caps.platform_version);
 	}
+	/* Ignore error if not implemented */
+	if (scpi_info->is_legacy && ret == -EOPNOTSUPP)
+		return 0;
+
 	return ret;
 }
 
-- 
1.9.1

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Sudeep Holla]

Since SCPI is a generic protocol and the bindings are intended to be
generic, we need to decouple all the platform specific binding details
out of the generic bindings.

This patch moves are the Juno platform specific details into a separate
binding document.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
 .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
 2 files changed, 33 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index faa4b44572e3..d1882c4540d0 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -59,18 +59,14 @@ SRAM and Shared Memory for SCPI
 A small area of SRAM is reserved for SCPI communication between application
 processors and SCP.
 
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
-
-The rest of the properties should follow the generic mmio-sram description
-found in ../../sram/sram.txt
+The properties should follow the generic mmio-sram description found in [3]
 
 Each sub-node represents the reserved area for SCPI.
 
 Required sub-node properties:
 - reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
-	       shared memory on Juno platforms
+- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
+	       shared memory
 
 Sensor bindings for the sensors based on SCPI Message Protocol
 --------------------------------------------------------------
@@ -81,11 +77,9 @@ SCPI provides an API to access the various sensors on the SoC.
 - #thermal-sensor-cells: should be set to 1. This property follows the
 			 thermal device tree bindings[2].
 
-			 Valid cell values are raw identifiers (Sensor
-			 ID) as used by the firmware. Refer to
-			 platform documentation for your
-			 implementation for the IDs to use. For Juno
-			 R0 and Juno R1 refer to [3].
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
 
 Power domain bindings for the power domains based on SCPI Message Protocol
 ------------------------------------------------------------
@@ -112,7 +106,7 @@ PM domain consumers
 [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/thermal/thermal.txt
-[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
+[3] Documentation/devicetree/bindings/sram/sram.txt
 [4] Documentation/devicetree/bindings/power/power_domain.txt
 
 Example:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
new file mode 100644
index 000000000000..2ace8696bbee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt
@@ -0,0 +1,26 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+
+Juno SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
+	       shared memory on Juno platforms
+
+Sensor bindings for the sensors based on SCPI Message Protocol
+--------------------------------------------------------------
+Required properties:
+- compatible : should be "arm,scpi-sensors".
+- #thermal-sensor-cells: should be set to 1.
+			 For Juno R0 and Juno R1 refer to [1] for the
+			 sensor identifiers
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
+[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
-- 
1.9.1

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Sudeep Holla]

Since SCPI is a generic protocol and the bindings are intended to be
generic, we need to decouple all the platform specific binding details
out of the generic bindings.

This patch moves are the Juno platform specific details into a separate
binding document.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
 .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
 2 files changed, 33 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index faa4b44572e3..d1882c4540d0 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -59,18 +59,14 @@ SRAM and Shared Memory for SCPI
 A small area of SRAM is reserved for SCPI communication between application
 processors and SCP.
 
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
-
-The rest of the properties should follow the generic mmio-sram description
-found in ../../sram/sram.txt
+The properties should follow the generic mmio-sram description found in [3]
 
 Each sub-node represents the reserved area for SCPI.
 
 Required sub-node properties:
 - reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
-	       shared memory on Juno platforms
+- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
+	       shared memory
 
 Sensor bindings for the sensors based on SCPI Message Protocol
 --------------------------------------------------------------
@@ -81,11 +77,9 @@ SCPI provides an API to access the various sensors on the SoC.
 - #thermal-sensor-cells: should be set to 1. This property follows the
 			 thermal device tree bindings[2].
 
-			 Valid cell values are raw identifiers (Sensor
-			 ID) as used by the firmware. Refer to
-			 platform documentation for your
-			 implementation for the IDs to use. For Juno
-			 R0 and Juno R1 refer to [3].
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
 
 Power domain bindings for the power domains based on SCPI Message Protocol
 ------------------------------------------------------------
@@ -112,7 +106,7 @@ PM domain consumers
 [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/thermal/thermal.txt
-[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
+[3] Documentation/devicetree/bindings/sram/sram.txt
 [4] Documentation/devicetree/bindings/power/power_domain.txt
 
 Example:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
new file mode 100644
index 000000000000..2ace8696bbee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt
@@ -0,0 +1,26 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+
+Juno SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
+	       shared memory on Juno platforms
+
+Sensor bindings for the sensors based on SCPI Message Protocol
+--------------------------------------------------------------
+Required properties:
+- compatible : should be "arm,scpi-sensors".
+- #thermal-sensor-cells: should be set to 1.
+			 For Juno R0 and Juno R1 refer to [1] for the
+			 sensor identifiers
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
+[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
-- 
1.9.1

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Sudeep Holla]

Since SCPI is a generic protocol and the bindings are intended to be
generic, we need to decouple all the platform specific binding details
out of the generic bindings.

This patch moves are the Juno platform specific details into a separate
binding document.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
 .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
 2 files changed, 33 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index faa4b44572e3..d1882c4540d0 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -59,18 +59,14 @@ SRAM and Shared Memory for SCPI
 A small area of SRAM is reserved for SCPI communication between application
 processors and SCP.
 
-Required properties:
-- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
-
-The rest of the properties should follow the generic mmio-sram description
-found in ../../sram/sram.txt
+The properties should follow the generic mmio-sram description found in [3]
 
 Each sub-node represents the reserved area for SCPI.
 
 Required sub-node properties:
 - reg : The base offset and size of the reserved area with the SRAM
-- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
-	       shared memory on Juno platforms
+- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
+	       shared memory
 
 Sensor bindings for the sensors based on SCPI Message Protocol
 --------------------------------------------------------------
@@ -81,11 +77,9 @@ SCPI provides an API to access the various sensors on the SoC.
 - #thermal-sensor-cells: should be set to 1. This property follows the
 			 thermal device tree bindings[2].
 
-			 Valid cell values are raw identifiers (Sensor
-			 ID) as used by the firmware. Refer to
-			 platform documentation for your
-			 implementation for the IDs to use. For Juno
-			 R0 and Juno R1 refer to [3].
+			 Valid cell values are raw identifiers (Sensor ID)
+			 as used by the firmware. Refer to  platform details
+			 for your implementation for the IDs to use.
 
 Power domain bindings for the power domains based on SCPI Message Protocol
 ------------------------------------------------------------
@@ -112,7 +106,7 @@ PM domain consumers
 [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 [2] Documentation/devicetree/bindings/thermal/thermal.txt
-[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
+[3] Documentation/devicetree/bindings/sram/sram.txt
 [4] Documentation/devicetree/bindings/power/power_domain.txt
 
 Example:
diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt
new file mode 100644
index 000000000000..2ace8696bbee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/juno,scpi.txt
@@ -0,0 +1,26 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+
+Juno SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- reg : The base offset and size of the reserved area with the SRAM
+- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
+	       shared memory on Juno platforms
+
+Sensor bindings for the sensors based on SCPI Message Protocol
+--------------------------------------------------------------
+Required properties:
+- compatible : should be "arm,scpi-sensors".
+- #thermal-sensor-cells: should be set to 1.
+			 For Juno R0 and Juno R1 refer to [1] for the
+			 sensor identifiers
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
+[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
-- 
1.9.1

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
> 
> This patch moves are the Juno platform specific details into a separate
> binding document.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
>  .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
> 
> This patch moves are the Juno platform specific details into a separate
> binding document.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
>  .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v5 5/8] Documentation: bindings: decouple juno specific details from generic binding

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:08PM -0600, Sudeep Holla wrote:
> Since SCPI is a generic protocol and the bindings are intended to be
> generic, we need to decouple all the platform specific binding details
> out of the generic bindings.
> 
> This patch moves are the Juno platform specific details into a separate
> binding document.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 20 ++++++-----------
>  .../devicetree/bindings/arm/juno,scpi.txt          | 26 ++++++++++++++++++++++
>  2 files changed, 33 insertions(+), 13 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

This patch adds specific compatible to support legacy SCPI protocol.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index d1882c4540d0..ebd03fc93135 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
 
 Required properties:
 
-- compatible : should be "arm,scpi"
+- compatible : should be
+	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
+	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
 - mboxes: List of phandle and mailbox channel specifiers
 	  All the channels reserved by remote SCP firmware for use by
 	  SCPI message protocol should be specified in any order
-- 
1.9.1

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

This patch adds specific compatible to support legacy SCPI protocol.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index d1882c4540d0..ebd03fc93135 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
 
 Required properties:
 
-- compatible : should be "arm,scpi"
+- compatible : should be
+	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
+	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
 - mboxes: List of phandle and mailbox channel specifiers
 	  All the channels reserved by remote SCP firmware for use by
 	  SCPI message protocol should be specified in any order
-- 
1.9.1

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

This patch adds specific compatible to support legacy SCPI protocol.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index d1882c4540d0..ebd03fc93135 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
 
 Required properties:
 
-- compatible : should be "arm,scpi"
+- compatible : should be
+	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
+	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
 - mboxes: List of phandle and mailbox channel specifiers
 	  All the channels reserved by remote SCP firmware for use by
 	  SCPI message protocol should be specified in any order
-- 
1.9.1

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

Hi Rob,

On 03/11/16 04:52, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>

Sorry for messing it up before, I think this version is much better.

Only this patch introduces new compatible, while 5,7,8/8 are just
reorganization to move the platform specific stuff out of the generic
SCPI bindings. It would be good if you can have a quick look and
provide ack if you are happy with these patches.

-- 
Regards,
Sudeep

> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
>  Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>  - mboxes: List of phandle and mailbox channel specifiers
>  	  All the channels reserved by remote SCP firmware for use by
>  	  SCPI message protocol should be specified in any order
>

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

Hi Rob,

On 03/11/16 04:52, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>

Sorry for messing it up before, I think this version is much better.

Only this patch introduces new compatible, while 5,7,8/8 are just
reorganization to move the platform specific stuff out of the generic
SCPI bindings. It would be good if you can have a quick look and
provide ack if you are happy with these patches.

-- 
Regards,
Sudeep

> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
>  Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>  - mboxes: List of phandle and mailbox channel specifiers
>  	  All the channels reserved by remote SCP firmware for use by
>  	  SCPI message protocol should be specified in any order
>

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

Hi Rob,

On 03/11/16 04:52, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>

Sorry for messing it up before, I think this version is much better.

Only this patch introduces new compatible, while 5,7,8/8 are just
reorganization to move the platform specific stuff out of the generic
SCPI bindings. It would be good if you can have a quick look and
provide ack if you are happy with these patches.

-- 
Regards,
Sudeep

> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
>  Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>  - mboxes: List of phandle and mailbox channel specifiers
>  	  All the channels reserved by remote SCP firmware for use by
>  	  SCPI message protocol should be specified in any order
>

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

Hi Rob,

On 03/11/16 04:52, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
>

Sorry for messing it up before, I think this version is much better.

Only this patch introduces new compatible, while 5,7,8/8 are just
reorganization to move the platform specific stuff out of the generic
SCPI bindings. It would be good if you can have a quick look and
provide ack if you are happy with these patches.

-- 
Regards,
Sudeep

> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>
>  Required properties:
>
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>  - mboxes: List of phandle and mailbox channel specifiers
>  	  All the channels reserved by remote SCP firmware for use by
>  	  SCPI message protocol should be specified in any order
>

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>  
>  Required properties:
>  
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0

I'd prefer that we explicitly enumerate the old versions. Are there 
many?

Rob

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>  
>  Required properties:
>  
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0

I'd prefer that we explicitly enumerate the old versions. Are there 
many?

Rob

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
> 
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>  
>  Required properties:
>  
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0

I'd prefer that we explicitly enumerate the old versions. Are there 
many?

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
> This patch adds specific compatible to support legacy SCPI protocol.
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> index d1882c4540d0..ebd03fc93135 100644
> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>  
>  Required properties:
>  
> -- compatible : should be "arm,scpi"
> +- compatible : should be
> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0

I'd prefer that we explicitly enumerate the old versions. Are there 
many?

Rob

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>>  Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>

I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>>  Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>

I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>>  Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>

I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>>  Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> +	* "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> +	* "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>

I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.

I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.

-- 
Regards,
Sudeep

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>>  Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.

This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.

Rob

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>>  Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.

This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.

Rob

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>>  Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.

This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.

Rob

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>>  Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>

OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>>  Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>

OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>>  Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>

OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>>  Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>

OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.

E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.

Is that not acceptable ?

-- 
Regards,
Sudeep

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Olof Johansson]

On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 14:12, Rob Herring wrote:
>>
>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>
>>>
>>>
>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>> operations.
>>>>>
>>>>>  Required properties:
>>>>>
>>>>> -- compatible : should be "arm,scpi"
>>>>> +- compatible : should be
>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>> above
>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>> v1.0
>>>>
>>>>
>>>>
>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>> many?
>>>>
>>>
>>> I understand your concern, but this legacy SCPI protocol was not
>>> officially released. It was just WIP which vendors picked up from very
>>> early releases. Since they are not numbered, it's hard to have specific
>>> compatibles with different versions until v1.0. That's one of the reason
>>> to retain platform specific compatible so that we can add any quirks
>>> based on them if needed.
>>>
>>> I will probably add these information in the commit log so that it's
>>> clear why we can't do version based compatible.
>>
>>
>> This is exactly my point. By enumerate, I meant having platform
>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>> who knows what version they followed and they may all be different.
>>
>
> OK, but IIUC Olof's concern wanted a generic one along with the platform
> specific compatible which kind of makes sense as so far we have seen
> some commonality between Amlogic and Rockchip.
>
> E.g. Amlogic follows most of the legacy protocol though it deviates in
> couple of things which we can handle with platform specific compatible
> (in the following patch in the series). When another user(Rockchip ?)
> make use of this legacy protocol, we can start using those platform
> specific compatible for deviations only.
>
> Is that not acceptable ?

If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.

What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.

I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.


-Olof

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Olof Johansson]

On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 14:12, Rob Herring wrote:
>>
>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>
>>>
>>>
>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>> operations.
>>>>>
>>>>>  Required properties:
>>>>>
>>>>> -- compatible : should be "arm,scpi"
>>>>> +- compatible : should be
>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>> above
>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>> v1.0
>>>>
>>>>
>>>>
>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>> many?
>>>>
>>>
>>> I understand your concern, but this legacy SCPI protocol was not
>>> officially released. It was just WIP which vendors picked up from very
>>> early releases. Since they are not numbered, it's hard to have specific
>>> compatibles with different versions until v1.0. That's one of the reason
>>> to retain platform specific compatible so that we can add any quirks
>>> based on them if needed.
>>>
>>> I will probably add these information in the commit log so that it's
>>> clear why we can't do version based compatible.
>>
>>
>> This is exactly my point. By enumerate, I meant having platform
>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>> who knows what version they followed and they may all be different.
>>
>
> OK, but IIUC Olof's concern wanted a generic one along with the platform
> specific compatible which kind of makes sense as so far we have seen
> some commonality between Amlogic and Rockchip.
>
> E.g. Amlogic follows most of the legacy protocol though it deviates in
> couple of things which we can handle with platform specific compatible
> (in the following patch in the series). When another user(Rockchip ?)
> make use of this legacy protocol, we can start using those platform
> specific compatible for deviations only.
>
> Is that not acceptable ?

If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.

What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.

I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.


-Olof

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Olof Johansson]

On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 14:12, Rob Herring wrote:
>>
>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
>>>
>>>
>>>
>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>
>>>>
>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>
>>>>>
>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>
>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>> operations.
>>>>>
>>>>>  Required properties:
>>>>>
>>>>> -- compatible : should be "arm,scpi"
>>>>> +- compatible : should be
>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>> above
>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>> v1.0
>>>>
>>>>
>>>>
>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>> many?
>>>>
>>>
>>> I understand your concern, but this legacy SCPI protocol was not
>>> officially released. It was just WIP which vendors picked up from very
>>> early releases. Since they are not numbered, it's hard to have specific
>>> compatibles with different versions until v1.0. That's one of the reason
>>> to retain platform specific compatible so that we can add any quirks
>>> based on them if needed.
>>>
>>> I will probably add these information in the commit log so that it's
>>> clear why we can't do version based compatible.
>>
>>
>> This is exactly my point. By enumerate, I meant having platform
>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>> who knows what version they followed and they may all be different.
>>
>
> OK, but IIUC Olof's concern wanted a generic one along with the platform
> specific compatible which kind of makes sense as so far we have seen
> some commonality between Amlogic and Rockchip.
>
> E.g. Amlogic follows most of the legacy protocol though it deviates in
> couple of things which we can handle with platform specific compatible
> (in the following patch in the series). When another user(Rockchip ?)
> make use of this legacy protocol, we can start using those platform
> specific compatible for deviations only.
>
> Is that not acceptable ?

If there's no shared legacy feature set, then it's probably less
useful to have a shared less precise compatible value.

What the main point I was trying to get across was that we shouldn't
expand the generic binding with per-vendor compatible fields, instead
we should have those as extensions on the side.

I'm also a little apprehensive of using "legacy", it goes in the same
bucket as "misc". At some point 1.0 will be legacy too, etc.


-Olof

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:
> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 14:12, Rob Herring wrote:
>>>
>>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>>> operations.
>>>>>>
>>>>>>  Required properties:
>>>>>>
>>>>>> -- compatible : should be "arm,scpi"
>>>>>> +- compatible : should be
>>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>>> above
>>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>>> v1.0
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>>> many?
>>>>>
>>>>
>>>> I understand your concern, but this legacy SCPI protocol was not
>>>> officially released. It was just WIP which vendors picked up from very
>>>> early releases. Since they are not numbered, it's hard to have specific
>>>> compatibles with different versions until v1.0. That's one of the reason
>>>> to retain platform specific compatible so that we can add any quirks
>>>> based on them if needed.
>>>>
>>>> I will probably add these information in the commit log so that it's
>>>> clear why we can't do version based compatible.
>>>
>>>
>>> This is exactly my point. By enumerate, I meant having platform
>>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>>> who knows what version they followed and they may all be different.
>>>
>>
>> OK, but IIUC Olof's concern wanted a generic one along with the platform
>> specific compatible which kind of makes sense as so far we have seen
>> some commonality between Amlogic and Rockchip.
>>
>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>> couple of things which we can handle with platform specific compatible
>> (in the following patch in the series). When another user(Rockchip ?)
>> make use of this legacy protocol, we can start using those platform
>> specific compatible for deviations only.
>>
>> Is that not acceptable ?
>
> If there's no shared legacy feature set, then it's probably less
> useful to have a shared less precise compatible value.
>

There is and will be some shared feature set for sure. At the least the
standard command set will be shared.

> What the main point I was trying to get across was that we shouldn't
> expand the generic binding with per-vendor compatible fields, instead
> we should have those as extensions on the side.
>

Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.

> I'm also a little apprehensive of using "legacy", it goes in the same
> bucket as "misc". At some point 1.0 will be legacy too, etc.
>

True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:
> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 14:12, Rob Herring wrote:
>>>
>>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>>> operations.
>>>>>>
>>>>>>  Required properties:
>>>>>>
>>>>>> -- compatible : should be "arm,scpi"
>>>>>> +- compatible : should be
>>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>>> above
>>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>>> v1.0
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>>> many?
>>>>>
>>>>
>>>> I understand your concern, but this legacy SCPI protocol was not
>>>> officially released. It was just WIP which vendors picked up from very
>>>> early releases. Since they are not numbered, it's hard to have specific
>>>> compatibles with different versions until v1.0. That's one of the reason
>>>> to retain platform specific compatible so that we can add any quirks
>>>> based on them if needed.
>>>>
>>>> I will probably add these information in the commit log so that it's
>>>> clear why we can't do version based compatible.
>>>
>>>
>>> This is exactly my point. By enumerate, I meant having platform
>>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>>> who knows what version they followed and they may all be different.
>>>
>>
>> OK, but IIUC Olof's concern wanted a generic one along with the platform
>> specific compatible which kind of makes sense as so far we have seen
>> some commonality between Amlogic and Rockchip.
>>
>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>> couple of things which we can handle with platform specific compatible
>> (in the following patch in the series). When another user(Rockchip ?)
>> make use of this legacy protocol, we can start using those platform
>> specific compatible for deviations only.
>>
>> Is that not acceptable ?
>
> If there's no shared legacy feature set, then it's probably less
> useful to have a shared less precise compatible value.
>

There is and will be some shared feature set for sure. At the least the
standard command set will be shared.

> What the main point I was trying to get across was that we shouldn't
> expand the generic binding with per-vendor compatible fields, instead
> we should have those as extensions on the side.
>

Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.

> I'm also a little apprehensive of using "legacy", it goes in the same
> bucket as "misc". At some point 1.0 will be legacy too, etc.
>

True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:
> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>>
>>
>> On 10/11/16 14:12, Rob Herring wrote:
>>>
>>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>>
>>>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>>> operations.
>>>>>>
>>>>>>  Required properties:
>>>>>>
>>>>>> -- compatible : should be "arm,scpi"
>>>>>> +- compatible : should be
>>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>>> above
>>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>>> v1.0
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>>> many?
>>>>>
>>>>
>>>> I understand your concern, but this legacy SCPI protocol was not
>>>> officially released. It was just WIP which vendors picked up from very
>>>> early releases. Since they are not numbered, it's hard to have specific
>>>> compatibles with different versions until v1.0. That's one of the reason
>>>> to retain platform specific compatible so that we can add any quirks
>>>> based on them if needed.
>>>>
>>>> I will probably add these information in the commit log so that it's
>>>> clear why we can't do version based compatible.
>>>
>>>
>>> This is exactly my point. By enumerate, I meant having platform
>>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>>> who knows what version they followed and they may all be different.
>>>
>>
>> OK, but IIUC Olof's concern wanted a generic one along with the platform
>> specific compatible which kind of makes sense as so far we have seen
>> some commonality between Amlogic and Rockchip.
>>
>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>> couple of things which we can handle with platform specific compatible
>> (in the following patch in the series). When another user(Rockchip ?)
>> make use of this legacy protocol, we can start using those platform
>> specific compatible for deviations only.
>>
>> Is that not acceptable ?
>
> If there's no shared legacy feature set, then it's probably less
> useful to have a shared less precise compatible value.
>

There is and will be some shared feature set for sure. At the least the
standard command set will be shared.

> What the main point I was trying to get across was that we shouldn't
> expand the generic binding with per-vendor compatible fields, instead
> we should have those as extensions on the side.
>

Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.

> I'm also a little apprehensive of using "legacy", it goes in the same
> bucket as "misc". At some point 1.0 will be legacy too, etc.
>

True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 10/11/16 19:03, Olof Johansson wrote:
> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 10/11/16 14:12, Rob Herring wrote:
>>>
>>> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 10/11/16 01:22, Rob Herring wrote:
>>>>>
>>>>>
>>>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>>>
>>>>>>
>>>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>>>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> index d1882c4540d0..ebd03fc93135 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>>>> operations.
>>>>>>
>>>>>>  Required properties:
>>>>>>
>>>>>> -- compatible : should be "arm,scpi"
>>>>>> +- compatible : should be
>>>>>> +       * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>>>> above
>>>>>> +       * "arm,legacy-scpi" : For implementations complying pre SCPI
>>>>>> v1.0
>>>>>
>>>>>
>>>>>
>>>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>>>> many?
>>>>>
>>>>
>>>> I understand your concern, but this legacy SCPI protocol was not
>>>> officially released. It was just WIP which vendors picked up from very
>>>> early releases. Since they are not numbered, it's hard to have specific
>>>> compatibles with different versions until v1.0. That's one of the reason
>>>> to retain platform specific compatible so that we can add any quirks
>>>> based on them if needed.
>>>>
>>>> I will probably add these information in the commit log so that it's
>>>> clear why we can't do version based compatible.
>>>
>>>
>>> This is exactly my point. By enumerate, I meant having platform
>>> specific compatibles. Having "arm,legacy-scpi" is pointless because
>>> who knows what version they followed and they may all be different.
>>>
>>
>> OK, but IIUC Olof's concern wanted a generic one along with the platform
>> specific compatible which kind of makes sense as so far we have seen
>> some commonality between Amlogic and Rockchip.
>>
>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>> couple of things which we can handle with platform specific compatible
>> (in the following patch in the series). When another user(Rockchip ?)
>> make use of this legacy protocol, we can start using those platform
>> specific compatible for deviations only.
>>
>> Is that not acceptable ?
>
> If there's no shared legacy feature set, then it's probably less
> useful to have a shared less precise compatible value.
>

There is and will be some shared feature set for sure. At the least the
standard command set will be shared.

> What the main point I was trying to get across was that we shouldn't
> expand the generic binding with per-vendor compatible fields, instead
> we should have those as extensions on the side.
>

Yes I get the point. We will have per-vendor compatibles for handle the
deviations but generic one to handle the shared set.

> I'm also a little apprehensive of using "legacy", it goes in the same
> bucket as "misc". At some point 1.0 will be legacy too, etc.
>

True and I agree, how about "arm,scpi-pre-1.0" instead ?

--
Regards,
Sudeep

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 10/11/16 19:03, Olof Johansson wrote:
>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>> couple of things which we can handle with platform specific compatible
>>> (in the following patch in the series). When another user(Rockchip ?)
>>> make use of this legacy protocol, we can start using those platform
>>> specific compatible for deviations only.
>>>
>>> Is that not acceptable ?
>>
>>
>> If there's no shared legacy feature set, then it's probably less
>> useful to have a shared less precise compatible value.
>>
>
> There is and will be some shared feature set for sure. At the least the
> standard command set will be shared.
>
>> What the main point I was trying to get across was that we shouldn't
>> expand the generic binding with per-vendor compatible fields, instead
>> we should have those as extensions on the side.
>>
>
> Yes I get the point. We will have per-vendor compatibles for handle the
> deviations but generic one to handle the shared set.
>
>> I'm also a little apprehensive of using "legacy", it goes in the same
>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>
>
> True and I agree, how about "arm,scpi-pre-1.0" instead ?

That's still meaningless. Convince me that multiple implementations
are identical, then we can have a common property. For example, how
many releases did ARM make before 1.0.

Rob

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 10/11/16 19:03, Olof Johansson wrote:
>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>> couple of things which we can handle with platform specific compatible
>>> (in the following patch in the series). When another user(Rockchip ?)
>>> make use of this legacy protocol, we can start using those platform
>>> specific compatible for deviations only.
>>>
>>> Is that not acceptable ?
>>
>>
>> If there's no shared legacy feature set, then it's probably less
>> useful to have a shared less precise compatible value.
>>
>
> There is and will be some shared feature set for sure. At the least the
> standard command set will be shared.
>
>> What the main point I was trying to get across was that we shouldn't
>> expand the generic binding with per-vendor compatible fields, instead
>> we should have those as extensions on the side.
>>
>
> Yes I get the point. We will have per-vendor compatibles for handle the
> deviations but generic one to handle the shared set.
>
>> I'm also a little apprehensive of using "legacy", it goes in the same
>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>
>
> True and I agree, how about "arm,scpi-pre-1.0" instead ?

That's still meaningless. Convince me that multiple implementations
are identical, then we can have a common property. For example, how
many releases did ARM make before 1.0.

Rob

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
> On 10/11/16 19:03, Olof Johansson wrote:
>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> wrote:

[...]

>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>> couple of things which we can handle with platform specific compatible
>>> (in the following patch in the series). When another user(Rockchip ?)
>>> make use of this legacy protocol, we can start using those platform
>>> specific compatible for deviations only.
>>>
>>> Is that not acceptable ?
>>
>>
>> If there's no shared legacy feature set, then it's probably less
>> useful to have a shared less precise compatible value.
>>
>
> There is and will be some shared feature set for sure. At the least the
> standard command set will be shared.
>
>> What the main point I was trying to get across was that we shouldn't
>> expand the generic binding with per-vendor compatible fields, instead
>> we should have those as extensions on the side.
>>
>
> Yes I get the point. We will have per-vendor compatibles for handle the
> deviations but generic one to handle the shared set.
>
>> I'm also a little apprehensive of using "legacy", it goes in the same
>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>
>
> True and I agree, how about "arm,scpi-pre-1.0" instead ?

That's still meaningless. Convince me that multiple implementations
are identical, then we can have a common property. For example, how
many releases did ARM make before 1.0.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Rob Herring]

On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 10/11/16 19:03, Olof Johansson wrote:
>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>> couple of things which we can handle with platform specific compatible
>>> (in the following patch in the series). When another user(Rockchip ?)
>>> make use of this legacy protocol, we can start using those platform
>>> specific compatible for deviations only.
>>>
>>> Is that not acceptable ?
>>
>>
>> If there's no shared legacy feature set, then it's probably less
>> useful to have a shared less precise compatible value.
>>
>
> There is and will be some shared feature set for sure. At the least the
> standard command set will be shared.
>
>> What the main point I was trying to get across was that we shouldn't
>> expand the generic binding with per-vendor compatible fields, instead
>> we should have those as extensions on the side.
>>
>
> Yes I get the point. We will have per-vendor compatibles for handle the
> deviations but generic one to handle the shared set.
>
>> I'm also a little apprehensive of using "legacy", it goes in the same
>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>
>
> True and I agree, how about "arm,scpi-pre-1.0" instead ?

That's still meaningless. Convince me that multiple implementations
are identical, then we can have a common property. For example, how
many releases did ARM make before 1.0.

Rob

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 13:34, Rob Herring wrote:
> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 10/11/16 19:03, Olof Johansson wrote:
>>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>
> [...]
>
>>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>>> couple of things which we can handle with platform specific compatible
>>>> (in the following patch in the series). When another user(Rockchip ?)
>>>> make use of this legacy protocol, we can start using those platform
>>>> specific compatible for deviations only.
>>>>
>>>> Is that not acceptable ?
>>>
>>>
>>> If there's no shared legacy feature set, then it's probably less
>>> useful to have a shared less precise compatible value.
>>>
>>
>> There is and will be some shared feature set for sure. At the least the
>> standard command set will be shared.
>>
>>> What the main point I was trying to get across was that we shouldn't
>>> expand the generic binding with per-vendor compatible fields, instead
>>> we should have those as extensions on the side.
>>>
>>
>> Yes I get the point. We will have per-vendor compatibles for handle the
>> deviations but generic one to handle the shared set.
>>
>>> I'm also a little apprehensive of using "legacy", it goes in the same
>>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>>
>>
>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>
> That's still meaningless. Convince me that multiple implementations
> are identical, then we can have a common property. For example, how
> many releases did ARM make before 1.0.
>

None officially, so I tend to agree with you on this.

But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))

IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 13:34, Rob Herring wrote:
> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 10/11/16 19:03, Olof Johansson wrote:
>>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>
> [...]
>
>>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>>> couple of things which we can handle with platform specific compatible
>>>> (in the following patch in the series). When another user(Rockchip ?)
>>>> make use of this legacy protocol, we can start using those platform
>>>> specific compatible for deviations only.
>>>>
>>>> Is that not acceptable ?
>>>
>>>
>>> If there's no shared legacy feature set, then it's probably less
>>> useful to have a shared less precise compatible value.
>>>
>>
>> There is and will be some shared feature set for sure. At the least the
>> standard command set will be shared.
>>
>>> What the main point I was trying to get across was that we shouldn't
>>> expand the generic binding with per-vendor compatible fields, instead
>>> we should have those as extensions on the side.
>>>
>>
>> Yes I get the point. We will have per-vendor compatibles for handle the
>> deviations but generic one to handle the shared set.
>>
>>> I'm also a little apprehensive of using "legacy", it goes in the same
>>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>>
>>
>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>
> That's still meaningless. Convince me that multiple implementations
> are identical, then we can have a common property. For example, how
> many releases did ARM make before 1.0.
>

None officially, so I tend to agree with you on this.

But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))

IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 13:34, Rob Herring wrote:
> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>> On 10/11/16 19:03, Olof Johansson wrote:
>>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>> wrote:
>
> [...]
>
>>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>>> couple of things which we can handle with platform specific compatible
>>>> (in the following patch in the series). When another user(Rockchip ?)
>>>> make use of this legacy protocol, we can start using those platform
>>>> specific compatible for deviations only.
>>>>
>>>> Is that not acceptable ?
>>>
>>>
>>> If there's no shared legacy feature set, then it's probably less
>>> useful to have a shared less precise compatible value.
>>>
>>
>> There is and will be some shared feature set for sure. At the least the
>> standard command set will be shared.
>>
>>> What the main point I was trying to get across was that we shouldn't
>>> expand the generic binding with per-vendor compatible fields, instead
>>> we should have those as extensions on the side.
>>>
>>
>> Yes I get the point. We will have per-vendor compatibles for handle the
>> deviations but generic one to handle the shared set.
>>
>>> I'm also a little apprehensive of using "legacy", it goes in the same
>>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>>
>>
>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>
> That's still meaningless. Convince me that multiple implementations
> are identical, then we can have a common property. For example, how
> many releases did ARM make before 1.0.
>

None officially, so I tend to agree with you on this.

But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))

IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 13:34, Rob Herring wrote:
> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 10/11/16 19:03, Olof Johansson wrote:
>>> On Thu, Nov 10, 2016 at 6:34 AM, Sudeep Holla <sudeep.holla@arm.com>
>>> wrote:
>
> [...]
>
>>>> E.g. Amlogic follows most of the legacy protocol though it deviates in
>>>> couple of things which we can handle with platform specific compatible
>>>> (in the following patch in the series). When another user(Rockchip ?)
>>>> make use of this legacy protocol, we can start using those platform
>>>> specific compatible for deviations only.
>>>>
>>>> Is that not acceptable ?
>>>
>>>
>>> If there's no shared legacy feature set, then it's probably less
>>> useful to have a shared less precise compatible value.
>>>
>>
>> There is and will be some shared feature set for sure. At the least the
>> standard command set will be shared.
>>
>>> What the main point I was trying to get across was that we shouldn't
>>> expand the generic binding with per-vendor compatible fields, instead
>>> we should have those as extensions on the side.
>>>
>>
>> Yes I get the point. We will have per-vendor compatibles for handle the
>> deviations but generic one to handle the shared set.
>>
>>> I'm also a little apprehensive of using "legacy", it goes in the same
>>> bucket as "misc". At some point 1.0 will be legacy too, etc.
>>>
>>
>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>
> That's still meaningless. Convince me that multiple implementations
> are identical, then we can have a common property. For example, how
> many releases did ARM make before 1.0.
>

None officially, so I tend to agree with you on this.

But so far we have seen some commonality between Rockchip and Amlogic
implementations, which in fact shares some commonality with early
release of SCPI from ARM (there are based on the same SCP code base,
which is closed source and released to partners only). ARM improved the
specification and the code base before the official release but by then
it was adopted(as usual we were late ;))

IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
and platform specific "amlogic,meson-gxbb-scpi"

-- 
Regards,
Sudeep

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>

Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?

I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.

-- 
Regards,
Sudeep

Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>

Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?

I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.

-- 
Regards,
Sudeep

[PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol

[Sudeep Holla]

On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:

[...]

>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>

Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?

I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.

-- 
Regards,
Sudeep

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
(decoupled from the generic scpi binding)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
new file mode 100644
index 000000000000..7b9a861e9306
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -0,0 +1,20 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+----------------------------------------------------------
+Required properties
+
+- compatible : should be "amlogic,meson-gxbb-scpi"
+
+AMLOGIC SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "amlogic,meson-gxbb-sram"
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
+		memory on Amlogic GXBB SoC.
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-- 
1.9.1

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
(decoupled from the generic scpi binding)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
new file mode 100644
index 000000000000..7b9a861e9306
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -0,0 +1,20 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+----------------------------------------------------------
+Required properties
+
+- compatible : should be "amlogic,meson-gxbb-scpi"
+
+AMLOGIC SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "amlogic,meson-gxbb-sram"
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
+		memory on Amlogic GXBB SoC.
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-- 
1.9.1

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Sudeep Holla]

From: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
(decoupled from the generic scpi binding)
Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
---
 .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
new file mode 100644
index 000000000000..7b9a861e9306
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -0,0 +1,20 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+----------------------------------------------------------
+Required properties
+
+- compatible : should be "amlogic,meson-gxbb-scpi"
+
+AMLOGIC SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "amlogic,meson-gxbb-sram"
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
+		memory on Amlogic GXBB SoC.
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Sudeep Holla]

From: Neil Armstrong <narmstrong@baylibre.com>

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
(decoupled from the generic scpi binding)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
new file mode 100644
index 000000000000..7b9a861e9306
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt
@@ -0,0 +1,20 @@
+System Control and Power Interface (SCPI) Message Protocol
+(in addition to the standard binding in [0])
+----------------------------------------------------------
+Required properties
+
+- compatible : should be "amlogic,meson-gxbb-scpi"
+
+AMLOGIC SRAM and Shared Memory for SCPI
+------------------------------------
+
+Required properties:
+- compatible : should be "amlogic,meson-gxbb-sram"
+
+Each sub-node represents the reserved area for SCPI.
+
+Required sub-node properties:
+- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
+		memory on Amlogic GXBB SoC.
+
+[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
-- 
1.9.1

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> 
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
>  .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 7/8] Documentation: bindings: Add support for Amlogic GXBB SCPI protocol

[Rob Herring]

On Wed, Nov 02, 2016 at 10:52:10PM -0600, Sudeep Holla wrote:
> From: Neil Armstrong <narmstrong@baylibre.com>
> 
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> (decoupled from the generic scpi binding)
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  .../devicetree/bindings/arm/amlogic,scpi.txt         | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt

Acked-by: Rob Herring <robh@kernel.org>

[PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible

[Sudeep Holla]

This patch adds new DT match table to setup the support for legacy SCPI
protocol. It aldo adds "arm,legacy-scpi" to the legacy match entry.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 902233642bd3..a38e1537fb8e 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -871,6 +871,11 @@ static int scpi_alloc_xfer_list(struct device *dev, struct scpi_chan *ch)
 	return 0;
 }
 
+static const struct of_device_id legacy_scpi_of_match[] = {
+	{.compatible = "arm,legacy-scpi"},
+	{},
+};
+
 static int scpi_probe(struct platform_device *pdev)
 {
 	int count, idx, ret;
@@ -883,6 +888,9 @@ static int scpi_probe(struct platform_device *pdev)
 	if (!scpi_info)
 		return -ENOMEM;
 
+	if (of_match_device(legacy_scpi_of_match, &pdev->dev))
+		scpi_info->is_legacy = true;
+
 	count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
 	if (count < 0) {
 		dev_err(dev, "no mboxes property in '%s'\n", np->full_name);
@@ -984,6 +992,7 @@ static int scpi_probe(struct platform_device *pdev)
 
 static const struct of_device_id scpi_of_match[] = {
 	{.compatible = "arm,scpi"},
+	{.compatible = "arm,legacy-scpi"},
 	{},
 };
 
-- 
1.9.1

[PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible

[Sudeep Holla]

This patch adds new DT match table to setup the support for legacy SCPI
protocol. It aldo adds "arm,legacy-scpi" to the legacy match entry.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 902233642bd3..a38e1537fb8e 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -871,6 +871,11 @@ static int scpi_alloc_xfer_list(struct device *dev, struct scpi_chan *ch)
 	return 0;
 }
 
+static const struct of_device_id legacy_scpi_of_match[] = {
+	{.compatible = "arm,legacy-scpi"},
+	{},
+};
+
 static int scpi_probe(struct platform_device *pdev)
 {
 	int count, idx, ret;
@@ -883,6 +888,9 @@ static int scpi_probe(struct platform_device *pdev)
 	if (!scpi_info)
 		return -ENOMEM;
 
+	if (of_match_device(legacy_scpi_of_match, &pdev->dev))
+		scpi_info->is_legacy = true;
+
 	count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
 	if (count < 0) {
 		dev_err(dev, "no mboxes property in '%s'\n", np->full_name);
@@ -984,6 +992,7 @@ static int scpi_probe(struct platform_device *pdev)
 
 static const struct of_device_id scpi_of_match[] = {
 	{.compatible = "arm,scpi"},
+	{.compatible = "arm,legacy-scpi"},
 	{},
 };
 
-- 
1.9.1

[PATCH v5 8/8] firmware: arm_scpi: add support for legacy SCPI compatible

[Sudeep Holla]

This patch adds new DT match table to setup the support for legacy SCPI
protocol. It aldo adds "arm,legacy-scpi" to the legacy match entry.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/arm_scpi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index 902233642bd3..a38e1537fb8e 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -871,6 +871,11 @@ static int scpi_alloc_xfer_list(struct device *dev, struct scpi_chan *ch)
 	return 0;
 }
 
+static const struct of_device_id legacy_scpi_of_match[] = {
+	{.compatible = "arm,legacy-scpi"},
+	{},
+};
+
 static int scpi_probe(struct platform_device *pdev)
 {
 	int count, idx, ret;
@@ -883,6 +888,9 @@ static int scpi_probe(struct platform_device *pdev)
 	if (!scpi_info)
 		return -ENOMEM;
 
+	if (of_match_device(legacy_scpi_of_match, &pdev->dev))
+		scpi_info->is_legacy = true;
+
 	count = of_count_phandle_with_args(np, "mboxes", "#mbox-cells");
 	if (count < 0) {
 		dev_err(dev, "no mboxes property in '%s'\n", np->full_name);
@@ -984,6 +992,7 @@ static int scpi_probe(struct platform_device *pdev)
 
 static const struct of_device_id scpi_of_match[] = {
 	{.compatible = "arm,scpi"},
+	{.compatible = "arm,legacy-scpi"},
 	{},
 };
 
-- 
1.9.1

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Neil Armstrong]

On 11/03/2016 05:52 AM, Sudeep Holla wrote:
> Hi,
> 
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
> 
> --
> Regards,
> Sudeep
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg534999.html
> 
> Neil Armstrong (4):
>   firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
>   firmware: arm_scpi: add alternative legacy structures, functions and
>     macros
>   firmware: arm_scpi: allow firmware with get_capabilities not
>     implemented
>   Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
> 
> Sudeep Holla (4):
>   firmware: arm_scpi: add command indirection to support legacy commands
>   Documentation: bindings: decouple juno specific details from generic
>     binding
>   Documentation: bindings: add compatible specific to legacy SCPI
>     protocol
>   firmware: arm_scpi: add support for legacy SCPI compatible
> 
>  .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
>  Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
>  .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
>  drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
>  4 files changed, 300 insertions(+), 46 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
> 

Hi Sudeep,

Ok for me, I submitted the fix for the GXBB dtsi.

Neil

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Neil Armstrong]

On 11/03/2016 05:52 AM, Sudeep Holla wrote:
> Hi,
> 
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
> 
> --
> Regards,
> Sudeep
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg534999.html
> 
> Neil Armstrong (4):
>   firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
>   firmware: arm_scpi: add alternative legacy structures, functions and
>     macros
>   firmware: arm_scpi: allow firmware with get_capabilities not
>     implemented
>   Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
> 
> Sudeep Holla (4):
>   firmware: arm_scpi: add command indirection to support legacy commands
>   Documentation: bindings: decouple juno specific details from generic
>     binding
>   Documentation: bindings: add compatible specific to legacy SCPI
>     protocol
>   firmware: arm_scpi: add support for legacy SCPI compatible
> 
>  .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
>  Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
>  .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
>  drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
>  4 files changed, 300 insertions(+), 46 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
> 

Hi Sudeep,

Ok for me, I submitted the fix for the GXBB dtsi.

Neil

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Neil Armstrong]

On 11/03/2016 05:52 AM, Sudeep Holla wrote:
> Hi,
> 
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
> 
> --
> Regards,
> Sudeep
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg534999.html
> 
> Neil Armstrong (4):
>   firmware: arm_scpi: increase MAX_DVFS_OPPS to 16 entries
>   firmware: arm_scpi: add alternative legacy structures, functions and
>     macros
>   firmware: arm_scpi: allow firmware with get_capabilities not
>     implemented
>   Documentation: bindings: Add support for Amlogic GXBB SCPI protocol
> 
> Sudeep Holla (4):
>   firmware: arm_scpi: add command indirection to support legacy commands
>   Documentation: bindings: decouple juno specific details from generic
>     binding
>   Documentation: bindings: add compatible specific to legacy SCPI
>     protocol
>   firmware: arm_scpi: add support for legacy SCPI compatible
> 
>  .../devicetree/bindings/arm/amlogic,scpi.txt       |  20 ++
>  Documentation/devicetree/bindings/arm/arm,scpi.txt |  24 +-
>  .../devicetree/bindings/arm/juno,scpi.txt          |  26 ++
>  drivers/firmware/arm_scpi.c                        | 276 ++++++++++++++++++---
>  4 files changed, 300 insertions(+), 46 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/amlogic,scpi.txt
>  create mode 100644 Documentation/devicetree/bindings/arm/juno,scpi.txt
> 

Hi Sudeep,

Ok for me, I submitted the fix for the GXBB dtsi.

Neil

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.

Is this what would be in my HBI0282B Juno?

(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.

Is this what would be in my HBI0282B Juno?

(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.

Is this what would be in my HBI0282B Juno?

(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.

Is this what would be in my HBI0282B Juno?

(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>

No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.

> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>

I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.

I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>

No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.

> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>

I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.

I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>

No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.

> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>

I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.

I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>

No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.

> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>

I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.

I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
> On 08/11/16 14:51, Russell King - ARM Linux wrote:
> >On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> >>This is minor rework of the series[1] from Neil Armstrong's to support
> >>legacy SCPI protocol to make DT bindings more generic and move out all
> >>the platform specific bindings out of the generic binding document.
> >
> >Is this what would be in my HBI0282B Juno?
> >
> 
> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
> that except that old firmware use it internally. By that I mean some
> version of trusted firmware used legacy SCPI but they are generally
> bundled together in fip, so you should not see any issue with upgrade.

I was wondering whether it'd work with my existing 1st September 2014
version of the trusted firmware.  I've pretty much come to the
conclusion that there's no way I can run the later firmware on this
hardware.

> I am currently trying to run Linaro 16.10 release, I don't see any issue
> except network boot from UEFI which is known and reported.

Interesting - maybe the hardware is different then?

> I will go through your logs in detail and try to replicate your issue.
> I assume you have tried replacing the entry contents of the uSD with the
> release. I will start with that now.

I haven't wiped it and copied the entire contents of the zip file over.
I instead backed up the old board.txt and images.txt files, and copied
the HBI0282B directories on top of the others.

This correctly causes all the various components to be updated when the
board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
flash with the updated images.  I even diff'd what was on the uSD card
and what was supplied in the zip file.

That's one state I tested: it also allowed me to edit the board.txt and
similar to wind back to what I have now on the board - which is all the
old versions of the firmware except for the MBB BIOS.

Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
over:


ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872

ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016

Time :  15:18:35
Date :  08:11:2016

Cmd> usb_on
Enabling debug USB...

Cmd> reboot

Powering up system...

Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp   : 26 degC

Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA  config: PASSED
OSC CLK config: PASSED

Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2

Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1

Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000

Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000

Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000

Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000

Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000

Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000

Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000

Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...

Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118   test: PASSED
KMI1/2    test: PASSED
MMC       test: PASSED
PB/LEDs   test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED

SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.

SoC SMB clock enabled.

Testing SMB clock...
SMB clock running
Releasing system resets...

UART0 set to SoC UART0
UART1 set to SoC UART1

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.2(debug):99e8937
NOTICE:  BL1: Built : 12:57:25, Nov  1 2016
INFO:    BL1: RAM 0x4037000 - 0x4040000
INFO:    Using crypto library 'mbed TLS'
INFO:    BL1: Loading BL2
INFO:    Loading image id=6 at address 0x4006000
INFO:    Skip reserving region [base = 0x4006000, size = 0x37f]
INFO:    Image id=6 loaded at address 0x4006000, size = 0x37f
INFO:    Loading image id=1 at address 0x4006000
INFO:    Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE:  BL1: Booting BL2
INFO:    Entry point address = 0x4006000
INFO:    SPSR = 0x3c5
NOTICE:  BL2: v1.2(debug):99e8937
NOTICE:  BL2: Built : 12:57:25, Nov  1 2016
INFO:    Using crypto library 'mbed TLS'
INFO:    BL2: Loading SCP_BL2
INFO:    Loading image id=7 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO:    Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO:    Loading image id=8 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=8 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=12 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=12 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=2 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0xf334]
INFO:    Image id=2 loaded at address 0x4023000, size = 0xf334
INFO:    BL2: Initiating SCP_BL2 transfer to SCP
INFO:    BL2: SCP_BL2 transferred to SCP
INFO:    Configuring TrustZone Controller
INFO:    BL2: Loading BL31
INFO:    Loading image id=9 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=9 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=13 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=13 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=3 at address 0x4023000
INFO:    Image id=3 loaded at address 0x4023000, size = 0xc020
INFO:    BL2: Loading BL32
INFO:    Loading image id=10 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x488]
INFO:    Image id=10 loaded at address 0xff000000, size = 0x488
INFO:    Loading image id=14 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x397]
INFO:    Image id=14 loaded at address 0xff000000, size = 0x397
INFO:    Loading image id=4 at address 0xff000000
INFO:    Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO:    BL2: Loading BL33
INFO:    Loading image id=11 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO:    Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO:    Loading image id=15 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO:    Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO:    Loading image id=5 at address 0xe0000000
INFO:    Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE:  BL1: Booting BL31
INFO:    Entry point address = 0x4023000
INFO:    SPSR = 0x3cd
NOTICE:  BL31: v1.2(debug):99e8937
NOTICE:  BL31: Built : 12:57:25, Nov  1 2016
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xe0000000
INFO:    SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov  1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
FV Hob            0xE0000000 - 0xE00EFFFF
FV Hob            0xFE07B000 - 0xFE8253BF
FV2 Hob           0xFE07B000 - 0xFE8253BF

which looks more hopeful... except it stops there.

As it contains a zero sized Image and .dtb files, I tried copying my
Image and .dtb over, and also copied my original config.txt (only
change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
this point.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
> On 08/11/16 14:51, Russell King - ARM Linux wrote:
> >On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> >>This is minor rework of the series[1] from Neil Armstrong's to support
> >>legacy SCPI protocol to make DT bindings more generic and move out all
> >>the platform specific bindings out of the generic binding document.
> >
> >Is this what would be in my HBI0282B Juno?
> >
> 
> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
> that except that old firmware use it internally. By that I mean some
> version of trusted firmware used legacy SCPI but they are generally
> bundled together in fip, so you should not see any issue with upgrade.

I was wondering whether it'd work with my existing 1st September 2014
version of the trusted firmware.  I've pretty much come to the
conclusion that there's no way I can run the later firmware on this
hardware.

> I am currently trying to run Linaro 16.10 release, I don't see any issue
> except network boot from UEFI which is known and reported.

Interesting - maybe the hardware is different then?

> I will go through your logs in detail and try to replicate your issue.
> I assume you have tried replacing the entry contents of the uSD with the
> release. I will start with that now.

I haven't wiped it and copied the entire contents of the zip file over.
I instead backed up the old board.txt and images.txt files, and copied
the HBI0282B directories on top of the others.

This correctly causes all the various components to be updated when the
board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
flash with the updated images.  I even diff'd what was on the uSD card
and what was supplied in the zip file.

That's one state I tested: it also allowed me to edit the board.txt and
similar to wind back to what I have now on the board - which is all the
old versions of the firmware except for the MBB BIOS.

Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
over:


ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872

ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016

Time :  15:18:35
Date :  08:11:2016

Cmd> usb_on
Enabling debug USB...

Cmd> reboot

Powering up system...

Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp   : 26 degC

Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA  config: PASSED
OSC CLK config: PASSED

Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2

Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1

Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000

Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000

Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000

Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000

Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000

Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000

Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000

Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...

Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118   test: PASSED
KMI1/2    test: PASSED
MMC       test: PASSED
PB/LEDs   test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED

SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.

SoC SMB clock enabled.

Testing SMB clock...
SMB clock running
Releasing system resets...

UART0 set to SoC UART0
UART1 set to SoC UART1

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.2(debug):99e8937
NOTICE:  BL1: Built : 12:57:25, Nov  1 2016
INFO:    BL1: RAM 0x4037000 - 0x4040000
INFO:    Using crypto library 'mbed TLS'
INFO:    BL1: Loading BL2
INFO:    Loading image id=6 at address 0x4006000
INFO:    Skip reserving region [base = 0x4006000, size = 0x37f]
INFO:    Image id=6 loaded at address 0x4006000, size = 0x37f
INFO:    Loading image id=1 at address 0x4006000
INFO:    Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE:  BL1: Booting BL2
INFO:    Entry point address = 0x4006000
INFO:    SPSR = 0x3c5
NOTICE:  BL2: v1.2(debug):99e8937
NOTICE:  BL2: Built : 12:57:25, Nov  1 2016
INFO:    Using crypto library 'mbed TLS'
INFO:    BL2: Loading SCP_BL2
INFO:    Loading image id=7 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO:    Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO:    Loading image id=8 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=8 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=12 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=12 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=2 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0xf334]
INFO:    Image id=2 loaded at address 0x4023000, size = 0xf334
INFO:    BL2: Initiating SCP_BL2 transfer to SCP
INFO:    BL2: SCP_BL2 transferred to SCP
INFO:    Configuring TrustZone Controller
INFO:    BL2: Loading BL31
INFO:    Loading image id=9 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=9 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=13 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=13 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=3 at address 0x4023000
INFO:    Image id=3 loaded at address 0x4023000, size = 0xc020
INFO:    BL2: Loading BL32
INFO:    Loading image id=10 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x488]
INFO:    Image id=10 loaded at address 0xff000000, size = 0x488
INFO:    Loading image id=14 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x397]
INFO:    Image id=14 loaded at address 0xff000000, size = 0x397
INFO:    Loading image id=4 at address 0xff000000
INFO:    Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO:    BL2: Loading BL33
INFO:    Loading image id=11 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO:    Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO:    Loading image id=15 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO:    Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO:    Loading image id=5 at address 0xe0000000
INFO:    Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE:  BL1: Booting BL31
INFO:    Entry point address = 0x4023000
INFO:    SPSR = 0x3cd
NOTICE:  BL31: v1.2(debug):99e8937
NOTICE:  BL31: Built : 12:57:25, Nov  1 2016
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xe0000000
INFO:    SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov  1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
FV Hob            0xE0000000 - 0xE00EFFFF
FV Hob            0xFE07B000 - 0xFE8253BF
FV2 Hob           0xFE07B000 - 0xFE8253BF

which looks more hopeful... except it stops there.

As it contains a zero sized Image and .dtb files, I tried copying my
Image and .dtb over, and also copied my original config.txt (only
change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
this point.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
> On 08/11/16 14:51, Russell King - ARM Linux wrote:
> >On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> >>This is minor rework of the series[1] from Neil Armstrong's to support
> >>legacy SCPI protocol to make DT bindings more generic and move out all
> >>the platform specific bindings out of the generic binding document.
> >
> >Is this what would be in my HBI0282B Juno?
> >
> 
> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
> that except that old firmware use it internally. By that I mean some
> version of trusted firmware used legacy SCPI but they are generally
> bundled together in fip, so you should not see any issue with upgrade.

I was wondering whether it'd work with my existing 1st September 2014
version of the trusted firmware.  I've pretty much come to the
conclusion that there's no way I can run the later firmware on this
hardware.

> I am currently trying to run Linaro 16.10 release, I don't see any issue
> except network boot from UEFI which is known and reported.

Interesting - maybe the hardware is different then?

> I will go through your logs in detail and try to replicate your issue.
> I assume you have tried replacing the entry contents of the uSD with the
> release. I will start with that now.

I haven't wiped it and copied the entire contents of the zip file over.
I instead backed up the old board.txt and images.txt files, and copied
the HBI0282B directories on top of the others.

This correctly causes all the various components to be updated when the
board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
flash with the updated images.  I even diff'd what was on the uSD card
and what was supplied in the zip file.

That's one state I tested: it also allowed me to edit the board.txt and
similar to wind back to what I have now on the board - which is all the
old versions of the firmware except for the MBB BIOS.

Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
over:


ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872

ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016

Time :  15:18:35
Date :  08:11:2016

Cmd> usb_on
Enabling debug USB...

Cmd> reboot

Powering up system...

Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp   : 26 degC

Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA  config: PASSED
OSC CLK config: PASSED

Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2

Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1

Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000

Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000

Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000

Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000

Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000

Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000

Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000

Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...

Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118   test: PASSED
KMI1/2    test: PASSED
MMC       test: PASSED
PB/LEDs   test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED

SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.

SoC SMB clock enabled.

Testing SMB clock...
SMB clock running
Releasing system resets...

UART0 set to SoC UART0
UART1 set to SoC UART1

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.2(debug):99e8937
NOTICE:  BL1: Built : 12:57:25, Nov  1 2016
INFO:    BL1: RAM 0x4037000 - 0x4040000
INFO:    Using crypto library 'mbed TLS'
INFO:    BL1: Loading BL2
INFO:    Loading image id=6 at address 0x4006000
INFO:    Skip reserving region [base = 0x4006000, size = 0x37f]
INFO:    Image id=6 loaded at address 0x4006000, size = 0x37f
INFO:    Loading image id=1 at address 0x4006000
INFO:    Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE:  BL1: Booting BL2
INFO:    Entry point address = 0x4006000
INFO:    SPSR = 0x3c5
NOTICE:  BL2: v1.2(debug):99e8937
NOTICE:  BL2: Built : 12:57:25, Nov  1 2016
INFO:    Using crypto library 'mbed TLS'
INFO:    BL2: Loading SCP_BL2
INFO:    Loading image id=7 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO:    Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO:    Loading image id=8 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=8 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=12 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=12 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=2 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0xf334]
INFO:    Image id=2 loaded at address 0x4023000, size = 0xf334
INFO:    BL2: Initiating SCP_BL2 transfer to SCP
INFO:    BL2: SCP_BL2 transferred to SCP
INFO:    Configuring TrustZone Controller
INFO:    BL2: Loading BL31
INFO:    Loading image id=9 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x47a]
INFO:    Image id=9 loaded at address 0x4023000, size = 0x47a
INFO:    Loading image id=13 at address 0x4023000
INFO:    Skip reserving region [base = 0x4023000, size = 0x389]
INFO:    Image id=13 loaded at address 0x4023000, size = 0x389
INFO:    Loading image id=3 at address 0x4023000
INFO:    Image id=3 loaded at address 0x4023000, size = 0xc020
INFO:    BL2: Loading BL32
INFO:    Loading image id=10 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x488]
INFO:    Image id=10 loaded at address 0xff000000, size = 0x488
INFO:    Loading image id=14 at address 0xff000000
INFO:    Skip reserving region [base = 0xff000000, size = 0x397]
INFO:    Image id=14 loaded at address 0xff000000, size = 0x397
INFO:    Loading image id=4 at address 0xff000000
INFO:    Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO:    BL2: Loading BL33
INFO:    Loading image id=11 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO:    Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO:    Loading image id=15 at address 0xe0000000
INFO:    Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO:    Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO:    Loading image id=5 at address 0xe0000000
INFO:    Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE:  BL1: Booting BL31
INFO:    Entry point address = 0x4023000
INFO:    SPSR = 0x3cd
NOTICE:  BL31: v1.2(debug):99e8937
NOTICE:  BL31: Built : 12:57:25, Nov  1 2016
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0xe0000000
INFO:    SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov  1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
FV Hob            0xE0000000 - 0xE00EFFFF
FV Hob            0xFE07B000 - 0xFE8253BF
FV2 Hob           0xFE07B000 - 0xFE8253BF

which looks more hopeful... except it stops there.

As it contains a zero sized Image and .dtb files, I tried copying my
Image and .dtb over, and also copied my original config.txt (only
change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
this point.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.

Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.0(release):14b6608
NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.0(release):14b6608
NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL3-1
NOTICE:  BL3-1: v1.0(release):14b6608
NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.

and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:

[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:

and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.)  "devices" shows nothing that's even remotely English.

So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.

Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.0(release):14b6608
NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.0(release):14b6608
NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL3-1
NOTICE:  BL3-1: v1.0(release):14b6608
NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.

and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:

[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:

and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.)  "devices" shows nothing that's even remotely English.

So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.

Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.0(release):14b6608
NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.0(release):14b6608
NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
NOTICE:  BL1: Booting BL3-1
NOTICE:  BL3-1: v1.0(release):14b6608
NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.

and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:

[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:

and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.)  "devices" shows nothing that's even remotely English.

So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 16:06, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> As it contains a zero sized Image and .dtb files, I tried copying my
>> Image and .dtb over, and also copied my original config.txt (only
>> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> this point.
>
> Well, it seems that I can't even go back to my original set of firmware
> as UEFI has stopped working:
>
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v1.0(release):14b6608
> NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v1.0(release):14b6608
> NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL3-1
> NOTICE:  BL3-1: v1.0(release):14b6608
> NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> Warning: Fail to load FDT file 'juno.dtb'.
>

This again because of incompatibility of the configuration data saved in
NOR flash. The erase command I gave early is to erase that when you
switched between the UEFI binaries. It's really horrible mess UEFI
created in the initial days of Juno, and hopefully they have moved to
some standard format these days.

> and UEFI is the most unfriendly thing going - the "boot manager" thing
> doesn't let you view the configuration:
>

I completely agree. I had real bad times in past dealing with such
things in UEFI.

> [1] Linux from NOR Flash
> [2] Shell
> [3] Boot Manager
> Start: 3
> [1] Add Boot Device Entry
> [2] Update Boot Device Entry
> [3] Remove Boot Device Entry
> [4] Reorder Boot Device Entries
> [5] Update FDT path
> [6] Set Boot Timeout
> [7] Return to main menu
> Choice:
>
> and dropping into the shell... well, I've no idea how to get a listing
> of what it thinks is in the NOR device (or even how to refer to the
> NOR device.)  "devices" shows nothing that's even remotely English.
>

I think startup.nsh needs some edits. Just replace it with something like:

"norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
alike. Currently it just echos and stops.

Regarding the new firmware stopping abruptly, I have no clue, except
asking you to erase the flash completely when switching between the
firmware versions. That has worked for me for all UEFI related issues in
the past. It's really annoying I understand.

flash> eraseall

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 16:06, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> As it contains a zero sized Image and .dtb files, I tried copying my
>> Image and .dtb over, and also copied my original config.txt (only
>> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> this point.
>
> Well, it seems that I can't even go back to my original set of firmware
> as UEFI has stopped working:
>
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v1.0(release):14b6608
> NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v1.0(release):14b6608
> NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL3-1
> NOTICE:  BL3-1: v1.0(release):14b6608
> NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> Warning: Fail to load FDT file 'juno.dtb'.
>

This again because of incompatibility of the configuration data saved in
NOR flash. The erase command I gave early is to erase that when you
switched between the UEFI binaries. It's really horrible mess UEFI
created in the initial days of Juno, and hopefully they have moved to
some standard format these days.

> and UEFI is the most unfriendly thing going - the "boot manager" thing
> doesn't let you view the configuration:
>

I completely agree. I had real bad times in past dealing with such
things in UEFI.

> [1] Linux from NOR Flash
> [2] Shell
> [3] Boot Manager
> Start: 3
> [1] Add Boot Device Entry
> [2] Update Boot Device Entry
> [3] Remove Boot Device Entry
> [4] Reorder Boot Device Entries
> [5] Update FDT path
> [6] Set Boot Timeout
> [7] Return to main menu
> Choice:
>
> and dropping into the shell... well, I've no idea how to get a listing
> of what it thinks is in the NOR device (or even how to refer to the
> NOR device.)  "devices" shows nothing that's even remotely English.
>

I think startup.nsh needs some edits. Just replace it with something like:

"norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
alike. Currently it just echos and stops.

Regarding the new firmware stopping abruptly, I have no clue, except
asking you to erase the flash completely when switching between the
firmware versions. That has worked for me for all UEFI related issues in
the past. It's really annoying I understand.

flash> eraseall

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 16:06, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> As it contains a zero sized Image and .dtb files, I tried copying my
>> Image and .dtb over, and also copied my original config.txt (only
>> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> this point.
>
> Well, it seems that I can't even go back to my original set of firmware
> as UEFI has stopped working:
>
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v1.0(release):14b6608
> NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v1.0(release):14b6608
> NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> NOTICE:  BL1: Booting BL3-1
> NOTICE:  BL3-1: v1.0(release):14b6608
> NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> Warning: Fail to load FDT file 'juno.dtb'.
>

This again because of incompatibility of the configuration data saved in
NOR flash. The erase command I gave early is to erase that when you
switched between the UEFI binaries. It's really horrible mess UEFI
created in the initial days of Juno, and hopefully they have moved to
some standard format these days.

> and UEFI is the most unfriendly thing going - the "boot manager" thing
> doesn't let you view the configuration:
>

I completely agree. I had real bad times in past dealing with such
things in UEFI.

> [1] Linux from NOR Flash
> [2] Shell
> [3] Boot Manager
> Start: 3
> [1] Add Boot Device Entry
> [2] Update Boot Device Entry
> [3] Remove Boot Device Entry
> [4] Reorder Boot Device Entries
> [5] Update FDT path
> [6] Set Boot Timeout
> [7] Return to main menu
> Choice:
>
> and dropping into the shell... well, I've no idea how to get a listing
> of what it thinks is in the NOR device (or even how to refer to the
> NOR device.)  "devices" shows nothing that's even remotely English.
>

I think startup.nsh needs some edits. Just replace it with something like:

"norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
alike. Currently it just echos and stops.

Regarding the new firmware stopping abruptly, I have no clue, except
asking you to erase the flash completely when switching between the
firmware versions. That has worked for me for all UEFI related issues in
the past. It's really annoying I understand.

flash> eraseall

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
> 
> 
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE:  Booting Trusted Firmware
> >NOTICE:  BL1: v1.0(release):14b6608
> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL2
> >NOTICE:  BL2: v1.0(release):14b6608
> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
> >NOTICE:  BL1: Booting BL3-1
> >NOTICE:  BL3-1: v1.0(release):14b6608
> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
> 
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.

Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)

> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
> 
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
> 
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.)  "devices" shows nothing that's even remotely English.
> >
> 
> I think startup.nsh needs some edits. Just replace it with something like:
> 
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
> 
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
> 
> flash> eraseall

I've tried that, it still stops at the same point, after:

FV2 Hob           0xFE07B000 - 0xFE8253BF

and remains unresponsive.

I do notice that the uSD card becomes visible through USB at this point
though.

Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Ryan Harkin]

On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE:  Booting Trusted Firmware
>> >NOTICE:  BL1: v1.0(release):14b6608
>> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL2
>> >NOTICE:  BL2: v1.0(release):14b6608
>> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL3-1
>> >NOTICE:  BL3-1: v1.0(release):14b6608
>> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.)  "devices" shows nothing that's even remotely English.
>> >

Using UEFI is painful enough on Juno.  Using a 2 year old version with
"that" menu system is even worse.

So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.

The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:

http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip

Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.

Switching to u-boot won't solve any thermal sensor calibration problems.


>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Ryan Harkin]

On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE:  Booting Trusted Firmware
>> >NOTICE:  BL1: v1.0(release):14b6608
>> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL2
>> >NOTICE:  BL2: v1.0(release):14b6608
>> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL3-1
>> >NOTICE:  BL3-1: v1.0(release):14b6608
>> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.)  "devices" shows nothing that's even remotely English.
>> >

Using UEFI is painful enough on Juno.  Using a 2 year old version with
"that" menu system is even worse.

So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.

The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:

http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip

Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.

Switching to u-boot won't solve any thermal sensor calibration problems.


>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Ryan Harkin]

On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE:  Booting Trusted Firmware
>> >NOTICE:  BL1: v1.0(release):14b6608
>> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL2
>> >NOTICE:  BL2: v1.0(release):14b6608
>> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL3-1
>> >NOTICE:  BL3-1: v1.0(release):14b6608
>> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.)  "devices" shows nothing that's even remotely English.
>> >

Using UEFI is painful enough on Juno.  Using a 2 year old version with
"that" menu system is even worse.

So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.

The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:

http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip

Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.

Switching to u-boot won't solve any thermal sensor calibration problems.


>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Ryan Harkin]

On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE:  Booting Trusted Firmware
>> >NOTICE:  BL1: v1.0(release):14b6608
>> >NOTICE:  BL1: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL2
>> >NOTICE:  BL2: v1.0(release):14b6608
>> >NOTICE:  BL2: Built : 14:15:51, Sep  1 2014
>> >NOTICE:  BL1: Booting BL3-1
>> >NOTICE:  BL3-1: v1.0(release):14b6608
>> >NOTICE:  BL3-1: Built : 14:15:53, Sep  1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.)  "devices" shows nothing that's even remotely English.
>> >

Using UEFI is painful enough on Juno.  Using a 2 year old version with
"that" menu system is even worse.

So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.

The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:

http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip

Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.

Switching to u-boot won't solve any thermal sensor calibration problems.


>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 21/11/16 15:04, Ryan Harkin wrote:

[...]

> Switching to u-boot won't solve any thermal sensor calibration problems.
>

Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 21/11/16 15:04, Ryan Harkin wrote:

[...]

> Switching to u-boot won't solve any thermal sensor calibration problems.
>

Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 21/11/16 15:04, Ryan Harkin wrote:

[...]

> Switching to u-boot won't solve any thermal sensor calibration problems.
>

Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.

-- 
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 21/11/16 15:04, Ryan Harkin wrote:

[...]

> Switching to u-boot won't solve any thermal sensor calibration problems.
>

Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware.  I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>

No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.

>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>

No, we have seen issues in past especially UEFI.

>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images.  I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>

[...]

> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob            0xE0000000 - 0xE00EFFFF
> FV Hob            0xFE07B000 - 0xFE8253BF
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>

Ah that's good, some progress.

> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.
>

I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.

Cmd> flash
 

Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
 

Flash> ERASERANGE 0x0BFC0000 0x0BFF0000

I will looking into that further.

-- 
Regards,
Sudeep

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware.  I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>

No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.

>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>

No, we have seen issues in past especially UEFI.

>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images.  I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>

[...]

> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob            0xE0000000 - 0xE00EFFFF
> FV Hob            0xFE07B000 - 0xFE8253BF
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>

Ah that's good, some progress.

> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.
>

I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.

Cmd> flash
 

Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
 

Flash> ERASERANGE 0x0BFC0000 0x0BFF0000

I will looking into that further.

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Sudeep Holla]

On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware.  I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>

No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.

>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>

No, we have seen issues in past especially UEFI.

>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images.  I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>

[...]

> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob            0xE0000000 - 0xE00EFFFF
> FV Hob            0xFE07B000 - 0xFE8253BF
> FV2 Hob           0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>

Ah that's good, some progress.

> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE).  It still doesn't appear to boot beyond
> this point.
>

I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.

Cmd> flash
 

Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
 

Flash> ERASERANGE 0x0BFC0000 0x0BFF0000

I will looking into that further.

-- 
Regards,
Sudeep

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 04:08:38PM +0000, Sudeep Holla wrote:
> I will focus on this and see what's happening. I have issue with network
> on my setup with debug build and Linaro guys are not seeing it. I revert
> to release build of UEFI for that. Anyways one suggestion I have right
> now is to erase the second partition of NOR flash where the old UEFI
> config is placed and it could be conflicting with the new UEFI image.
> 
> Cmd> flash
> 
> 
> Switching on main power...
> PMIC RAM configuration (pms_v105.bin)...
> IOFPGA config: PASSED
> Enabling usb remote...
> 
> 
> Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
> 
> I will looking into that further.

Still behaves the same, stopping at:

FV2 Hob           0xFE07B000 - 0xFE8253BF


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 04:08:38PM +0000, Sudeep Holla wrote:
> I will focus on this and see what's happening. I have issue with network
> on my setup with debug build and Linaro guys are not seeing it. I revert
> to release build of UEFI for that. Anyways one suggestion I have right
> now is to erase the second partition of NOR flash where the old UEFI
> config is placed and it could be conflicting with the new UEFI image.
> 
> Cmd> flash
> 
> 
> Switching on main power...
> PMIC RAM configuration (pms_v105.bin)...
> IOFPGA config: PASSED
> Enabling usb remote...
> 
> 
> Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
> 
> I will looking into that further.

Still behaves the same, stopping at:

FV2 Hob           0xFE07B000 - 0xFE8253BF


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol

[Russell King - ARM Linux]

On Tue, Nov 08, 2016 at 04:08:38PM +0000, Sudeep Holla wrote:
> I will focus on this and see what's happening. I have issue with network
> on my setup with debug build and Linaro guys are not seeing it. I revert
> to release build of UEFI for that. Anyways one suggestion I have right
> now is to erase the second partition of NOR flash where the old UEFI
> config is placed and it could be conflicting with the new UEFI image.
> 
> Cmd> flash
> 
> 
> Switching on main power...
> PMIC RAM configuration (pms_v105.bin)...
> IOFPGA config: PASSED
> Enabling usb remote...
> 
> 
> Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
> 
> I will looking into that further.

Still behaves the same, stopping at:

FV2 Hob           0xFE07B000 - 0xFE8253BF


-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.