Hi Nicolas,
On Thu, Nov 27, 2014 at 10:36 PM, Nicolas Pitre
<nicolas.pitre@xxxxxxxxxx> wrote:
> On Thu, 27 Nov 2014, Abhilash Kesavan wrote:
>
>> Hi Kevin,
>>
>> On Thu, Nov 27, 2014 at 12:11 AM, Nicolas Pitre
>> <nicolas.pitre@xxxxxxxxxx> 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.
>>
>> How about restricting the mcpm initialization to only known working
>> boards like chromebooks and smdk. This would be better than disabling
>> the config altogether from exynos_defconfig. The non-working boards
>> would then default to platsmp. Assuming that the firmware handles all
>> CCI/cache activities then platsmp may work for secondary core boot-up
>> ?
>>
>> Can you please apply the below diff and test the non-working boards
>> with CONFIG_EXYNOS5420_MCPM enabled.
>
> I'd much prefer if the CCI is non accessible on some board that the
> device tree file for that board be modified instead by marking the CCI
> as unavailable.
I will post a patch disabling CCI for Arndale-Octa.
Abhilasj
>
>
>>
>> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
>> b/arch/arm/mach-exynos/mcpm-exynos.c
>> index b0d3c2e..34d77bb 100644
>> --- a/arch/arm/mach-exynos/mcpm-exynos.c
>> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
>> @@ -316,8 +316,9 @@ static void __init exynos_cache_off(void)
>> }
>>
>> static const struct of_device_id exynos_dt_mcpm_match[] = {
>> - { .compatible = "samsung,exynos5420" },
>> - { .compatible = "samsung,exynos5800" },
>> + { .compatible = "samsung,smdk5420" },
>> + { .compatible = "google,pi" },
>> + { .compatible = "google,pit" },
>> {},
>> };
>>
>> On a different note, I did not see any mainline support for Odroid
>> Xu3, are you testing this board with a non-mainline kernel ?
>>
>> Regards,
>> Abhilash
>> >
>> >
>> >
>> > Nicolas
>>
>>
--
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
