lkml.org 
[lkml]   [2019]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2] soc: imx: Add generic i.MX8 SoC driver
Date
On 19-02-26 13:34:52, Leonard Crestez wrote:
> On Tue, 2019-02-26 at 10:53 +0000, Abel Vesa wrote:
> > Add generic i.MX8 SoC driver along with the i.MX8MQ SoC specific code.
> > For now, only i.MX8MQ revision B1 is supported. For any other, i.MX8MQ
> > revision it will print 'unknown'.
> >
> > + 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;
>
> Turns out that imx8mq version determination is uniquely messy. I think
> we should try to print the revision number even for older chips so that
> we know how old they are, but this code can be enhanced in later
> patches.
>

Fair enough. I believe we should stick to B1 only for now though.

> In the vendor tree we handle this with a SIP call to ATF, it's not
> clear why we shouldn't just upstream that (in both ATF and Linux).
>

Question here is: do we need to go through psci for things like revision ?
I believe the cost is not worth it.

> Also, there are some imx soc revision declarations in
> include/soc/imx/revision.h. Those are implemented in arch/arm/mach-imx
> for older chips, would it make sense for soc-imx8 to define
> imx_get_soc_revision?
>

I'm totally against the use of imx_get_soc_revision everywhere. Plus,
according to our internal tree there doens't seem to indicate a need for
such a thing for imx8. Anyway, that can be added later on if necessary.

> --
> Regards,
> Leonard
\
 
 \ /
  Last update: 2019-02-27 09:41    [W:0.087 / U:14.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site