Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 26/11/14 18:41, Nicolas Pitre wrote:
On Wed, 26 Nov 2014, Kevin Hilman wrote:

Abhilash Kesavan <kesavan.abhilash@xxxxxxxxx> writes:

Hi Kevin,

On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
[...]

More specifically, with only the loopback call to turn off CCI commented
out, the imprecise aborts go away.

I can't see how enabling snoops for the boot cluster is causing these
aborts. Perhaps as Krzysztof commented it has something to do with the
secure firmware/tz software on these boards ? Other than there does
not appear to be any difference between the working/non-working
setups.

Perhaps the secure firmware is preventing the CCI to be enabled by the
kernel, and that is causing the imprecise abort?

That is well possible.

Now...... if the bootloader/firmware does not let Linux deal with both
the CCI and caches then MCPM simply has no more purpose for this board.
The whole point of MCPM is actually to handle the CCI properly and the
most efficient way despite all the possible races and opportunities for
memory corruptions. And yes, this is a complex task.

So there is actually two choices: the firmware let Linux take care of it
via the MCPM layer (easy), or the firmware has to implement it all
_properly_ (hard) behind an interface such as PSCI, at which point MCPM
should be configured out.

If the firmware does not let Linux interact with the CCI _and_ does not
implement full MCPM-like services then the platform is broken and only a
firmware upgrade could fix that.  It might still be possible to boot all
CPUs through other means, but power management would then be severely
limited.


Thanks Nico for the detailed description on the requirements for using
MCPM. This is the kind of issue I was worried in the other thread on
Fijitsu platform. That's the reason I was asking the information about
their secure firmware and what exactly it configures so that we won't
end up with similar situation on there too and definitely not to push
PSCI. I completely agree with you that making a some change in firmware
to give control of CCI to kernel is easy.

Probably if the vendors disagree to apply this small fix to the firmware
we should provide them with *only choice* of PSCI implementation which
is quite complex and easy to get it wrong. That might trigger them to
provide a small fix to use MCPM.

Regards,
Sudeep



--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux