[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB6434B72679CD26C22FFB420BEE000@AM0PR04MB6434.eurprd04.prod.outlook.com>
Date: Wed, 22 May 2019 13:30:54 +0000
From: Leonard Crestez <leonard.crestez@....com>
To: Guido Günther <agx@...xcpu.org>,
Abel Vesa <abel.vesa@....com>,
Lucas Stach <l.stach@...gutronix.de>
CC: Jacky Bai <ping.bai@....com>, Anson Huang <anson.huang@....com>,
Fabio Estevam <festevam@...il.com>,
Sascha Hauer <s.hauer@...gutronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Shawn Guo <shawnguo@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions
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
Powered by blists - more mailing lists