This is similar to what the BSP does and needed to e.g. determine
necessary quirks for MIPI DSI.
Signed-off-by: Guido Günther <[email protected]>
---
From the list discussion and changelog it's not clear to me why a
different method was chosen for the B1 silicon so I left that in place
as is and only trigger on the B0 silicon I have here.
---
drivers/soc/imx/soc-imx8.c | 49 ++++++++++++++++++++++++++++----------
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index fc6429f9170a..363acd1151ee 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -3,6 +3,7 @@
* Copyright 2019 NXP.
*/
+#include <linux/arm-smccc.h>
#include <linux/init.h>
#include <linux/io.h>
#include <linux/of_address.h>
@@ -11,16 +12,37 @@
#include <linux/platform_device.h>
#include <linux/of.h>
+#define REV_B0 0x20
#define REV_B1 0x21
+#define IMX8MQ_ATF_GET_SOC_INFO 0xc2000006
#define IMX8MQ_SW_INFO_B1 0x40
#define IMX8MQ_SW_MAGIC_B1 0xff0055aa
+
struct imx8_soc_data {
char *name;
u32 (*soc_revision)(void);
};
+
+static u32 __init imx8mq_soc_revision_from_atf(void)
+{
+ struct arm_smccc_res res;
+ u32 digprog;
+
+ arm_smccc_smc(IMX8MQ_ATF_GET_SOC_INFO, 0, 0, 0, 0, 0, 0, 0, &res);
+ digprog = res.a0;
+ /*
+ * Bit [23:16] is the silicon ID
+ * Bit[7:4] is the base layer revision,
+ * Bit[3:0] is the metal layer revision
+ * e.g. 0x10 stands for Tapeout 1.0
+ */
+ return digprog & 0xff;
+}
+
+
static u32 __init imx8mq_soc_revision(void)
{
struct device_node *np;
@@ -29,20 +51,23 @@ static u32 __init imx8mq_soc_revision(void)
u32 rev = 0;
np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
- if (!np)
- goto out;
-
- ocotp_base = of_iomap(np, 0);
- WARN_ON(!ocotp_base);
-
- magic = readl_relaxed(ocotp_base + IMX8MQ_SW_INFO_B1);
- if (magic == IMX8MQ_SW_MAGIC_B1)
- rev = REV_B1;
-
- iounmap(ocotp_base);
+ if (np) {
+ ocotp_base = of_iomap(np, 0);
+ WARN_ON(!ocotp_base);
+
+ magic = readl_relaxed(ocotp_base + IMX8MQ_SW_INFO_B1);
+ iounmap(ocotp_base);
+ of_node_put(np);
+ if (magic == IMX8MQ_SW_MAGIC_B1)
+ rev = REV_B1;
+ }
+ if (!rev) {
+ magic = imx8mq_soc_revision_from_atf();
+ if (magic == REV_B0)
+ rev = REV_B0;
+ }
out:
- of_node_put(np);
return rev;
}
--
2.20.1
On 03.05.2019 16:53, Guido G?nther wrote:
> This is similar to what the BSP does and needed to e.g. determine
> necessary quirks for MIPI DSI.
>
> Signed-off-by: Guido G?nther <[email protected]>
>
> From the list discussion and changelog it's not clear to me why a
> different method was chosen for the B1 silicon so I left that in place
> as is and only trigger on the B0 silicon I have here.
Fetching revision without an ATF call was done for the sake of avoiding
depending on ATF as much as vendor tree does. I'm not sure avoiding ATF
dependencies is a good approach.
The imx8mq reference manual claims that 0x3036006c is should be soc
revision but that incorrectly reports 0x00824010 meaning "A0" on all
chips. So some nasty hacks are done in ATF instead by poking at ROM and
OCOTP.
There were multiple discussions also for GPCv2 and 8mm about how much to
rely on firmware. I personally think that duplicating ATF workarounds
just makes supporting imx8m harder in Linux. Don't we want firmware to
help us with silicon erratas?
> +#define IMX8MQ_ATF_GET_SOC_INFO 0xc2000006
Any reason not to use original FSL_SIP_GET_SOC_INFO constant name?
Since ATF can fetch revision for B1 as well it makes no sense to keep
the old code if we switch to using a SIP call, just call ATF always.
ATF upstream currently has 8mq support but no SIP call for GET_SOC_INFO,
that could be added easily.
--
Regards,
Leonard
Hi Leonard,
Thanks for your comments. Let's try s.th. different then: identify by
bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
out the DT part and add binding docs if this makes sense). I'm also
happy to drop the whole ATF logic until mailine ATF catched up:
The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
nor does it have the code to identify different imx8mq SOC revisions so
mimic what NXPs ATF does here.
As a fallback use ATF so we can identify new revisions once it gains
support or when using NXPs ATF.
Signed-off-by: Guido G?nther <[email protected]>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 12 ++++
drivers/soc/imx/soc-imx8.c | 68 ++++++++++++++++++-----
2 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6d635ba0904c..52aa1600b33b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -246,6 +246,18 @@
ranges = <0x0 0x0 0x0 0x3e000000>;
dma-ranges = <0x40000000 0x0 0x40000000 0xc0000000>;
+ bus@00000000 { /* ROM */
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00000000 0x00000000 0x20000>;
+
+ rom@00000000 {
+ compatible = "fsl,imx8mq-bootrom";
+ reg = <0x00000000 0x1e800>;
+ };
+ };
+
bus@30000000 { /* AIPS1 */
compatible = "fsl,imx8mq-aips-bus", "simple-bus";
#address-cells = <1>;
diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index fc6429f9170a..0a1fe82efe86 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -3,6 +3,7 @@
* Copyright 2019 NXP.
*/
+#include <linux/arm-smccc.h>
#include <linux/init.h>
#include <linux/io.h>
#include <linux/of_address.h>
@@ -11,39 +12,80 @@
#include <linux/platform_device.h>
#include <linux/of.h>
+#define REV_A0 0x10
+#define REV_B0 0x20
#define REV_B1 0x21
+#define IMX8MQ_SW_INFO_A0 0x800
+#define IMX8MQ_SW_INFO_B0 0x83C
#define IMX8MQ_SW_INFO_B1 0x40
#define IMX8MQ_SW_MAGIC_B1 0xff0055aa
+#define FSL_SIP_GET_SOC_INFO 0xc2000006
+
struct imx8_soc_data {
char *name;
u32 (*soc_revision)(void);
};
-static u32 __init imx8mq_soc_revision(void)
+static u32 __init imx8mq_soc_revision_atf(void)
+{
+ struct arm_smccc_res res = { 0 };
+
+ arm_smccc_smc(FSL_SIP_GET_SOC_INFO, 0, 0, 0, 0, 0, 0, 0, &res);
+ /*
+ * Bit [23:16] is the silicon ID
+ * Bit[7:4] is the base layer revision,
+ * Bit[3:0] is the metal layer revision
+ * e.g. 0x10 stands for Tapeout 1.0
+ */
+ return res.a0 & 0xff;
+}
+
+static u32 __init imx8mq_soc_magic_node(const char *node, u32 offset)
{
struct device_node *np;
- void __iomem *ocotp_base;
+ void __iomem *base;
u32 magic;
- u32 rev = 0;
- np = of_find_compatible_node(NULL, NULL, "fsl,imx8mq-ocotp");
+ np = of_find_compatible_node(NULL, NULL, node);
if (!np)
- goto out;
+ return 0;
+ base = of_iomap(np, 0);
+ WARN_ON(!base);
+
+ magic = readl_relaxed(base + offset);
+ iounmap(base);
+ of_node_put(np);
+
+ return magic;
+}
- ocotp_base = of_iomap(np, 0);
- WARN_ON(!ocotp_base);
+static u32 __init imx8mq_soc_revision(void)
+{
+ u32 magic;
- magic = readl_relaxed(ocotp_base + IMX8MQ_SW_INFO_B1);
+ /* B1 revision identified by ocotop */
+ magic = imx8mq_soc_magic_node("fsl,imx8mq-ocotp", IMX8MQ_SW_INFO_B1);
if (magic == IMX8MQ_SW_MAGIC_B1)
- rev = REV_B1;
+ return REV_B1;
- iounmap(ocotp_base);
+ /* B0 identified by bootrom */
+ magic = imx8mq_soc_magic_node("fsl,imx8mq-bootrom", IMX8MQ_SW_INFO_B0);
+ if ((magic & 0xff) == REV_B0)
+ return REV_B0;
-out:
- of_node_put(np);
- return rev;
+ /* A0 identified by anatop */
+ magic = imx8mq_soc_magic_node("fsl,imx8mq-anatop", IMX8MQ_SW_INFO_A0);
+ if ((magic & 0xff) == REV_A0)
+ return REV_A0;
+
+ /* Read revision from ATF as fallback */
+ magic = imx8mq_soc_revision_atf();
+ if (magic != 0xff)
+ return magic;
+
+ return 0;
}
static const struct imx8_soc_data imx8mq_soc_data = {
--
2.20.1
On 22.05.2019 16:13, Guido G?nther wrote:
> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
Fixed subject
> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido G?nther wrote:
>> Thanks for your comments. Let's try s.th. different then: identify by
>> bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
>> out the DT part and add binding docs if this makes sense). I'm also
>> happy to drop the whole ATF logic until mailine ATF catched up:
>>
>> The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
>> nor does it have the code to identify different imx8mq SOC revisions so
>> mimic what NXPs ATF does here.
>
> Does this makes sense? If so I'll send this out as a series.
Mainline ATF has recently caught up:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/imx/imx8m/imx8mq/imx8mq_bl31_setup.c#n52
>> As a fallback use ATF so we can identify new revisions once it gains
>> support or when using NXPs ATF.
>
> I'm also fine with dropping the ATF part if we don't want to depend on
> it in mainline.
Linux arm64 depends on ATF to implement power management via PSCI:
hotplug cpuidle and suspend.
It is not clear why Linux would avoid other services and insist on
reimplementing hardware workarounds.
--
Regards,
Leonard
Am Mittwoch, den 22.05.2019, 13:30 +0000 schrieb Leonard Crestez:
> On 22.05.2019 16:13, Guido Günther wrote:
> > Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>
> Fixed subject
>
> > On Wed, May 08, 2019 at 02:40:18PM +0200, Guido Günther wrote:
> > > Thanks for your comments. Let's try s.th. different then: identify by
> > > bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
> > > out the DT part and add binding docs if this makes sense). I'm also
> > > happy to drop the whole ATF logic until mailine ATF catched up:
> > >
> > > The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
> > > nor does it have the code to identify different imx8mq SOC revisions so
> > > mimic what NXPs ATF does here.
> >
> > Does this makes sense? If so I'll send this out as a series.
>
> Mainline ATF has recently caught up:
>
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/imx/imx8m/imx8mq/imx8mq_bl31_setup.c#n52
>
> > > As a fallback use ATF so we can identify new revisions once it gains
> > > support or when using NXPs ATF.
> >
> > I'm also fine with dropping the ATF part if we don't want to depend on
> > it in mainline.
>
> Linux arm64 depends on ATF to implement power management via PSCI:
> hotplug cpuidle and suspend.
>
> It is not clear why Linux would avoid other services and insist on
> reimplementing hardware workarounds.
I fully agree. We should not duplicate functionality between ATF and
Linux kernel. If the mainline ATF provides the facilities to do the SoC
identification the kernel should use them as the sole source to get
this information.
Regards,
Lucas
On 22.05.2019 16:40, Lucas Stach wrote:
> Am Mittwoch, den 22.05.2019, 13:30 +0000 schrieb Leonard Crestez:
>> On 22.05.2019 16:13, Guido G?nther wrote:
>>> Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
>>> On Wed, May 08, 2019 at 02:40:18PM +0200, Guido G?nther wrote:
>>>> Thanks for your comments. Let's try s.th. different then: identify by
>>>> bootrom, ocotop and anatop and fall back to ATF afterwards (I'll split
>>>> out the DT part and add binding docs if this makes sense). I'm also
>>>> happy to drop the whole ATF logic until mailine ATF catched up:
>>>>
>>>> The mainline ATF doesn't currently support the FSL_SIP_GET_SOC_INFO call
>>>> nor does it have the code to identify different imx8mq SOC revisions so
>>>> mimic what NXPs ATF does here.
>>>
>>> Does this makes sense? If so I'll send this out as a series.
>>
>> Mainline ATF has recently caught up:
>>
>>>> As a fallback use ATF so we can identify new revisions once it gains
>>>> support or when using NXPs ATF.
>>>
>>> I'm also fine with dropping the ATF part if we don't want to depend on
>>> it in mainline.
>>
>> Linux arm64 depends on ATF to implement power management via PSCI:
>> hotplug cpuidle and suspend.
>>
>> It is not clear why Linux would avoid other services and insist on
>> reimplementing hardware workarounds.
>
> I fully agree. We should not duplicate functionality between ATF and
> Linux kernel.
Excellent, will remember this when debating who should manipulate GPC.
Guido: Are you going to resend a variant of your V1?
You mentioned that you need this for erratas, how exactly are you going
to fetch soc revision from a driver? For 32bit imx there is a global
imx_get_soc_revision(), maybe the definition could be moved from
arch/arm/mach-imx/cpu.c to drivers/soc/imx/revision.c so that it's
available everywhere?
--
Regards,
Leonard