Messages in this thread | | | From | Leonard Crestez <> | Subject | Re: [RFC PATCH] soc: imx: Try harder to get imq8mq SoC revisions | Date | Tue, 28 May 2019 13:37:15 +0000 |
| |
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
| |