On Tue, Jul 8, 2014 at 7:47 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Tue, Jul 08, 2014 at 03:56:48PM +0200, Tomasz Figa wrote: >> On 02.07.2014 05:11, Chander Kashyap wrote: >> > On Tue, Jul 1, 2014 at 8:22 PM, Russell King - ARM Linux >> > <linux@xxxxxxxxxxxxxxxx> wrote: >> >> On Tue, Jul 01, 2014 at 08:02:36PM +0530, Chander Kashyap wrote: >> >>> This patch series fixes the cpuidle for different states. Also removes arm >> >>> diagnostic and power register save/restore code as it is made generic. >> >>> >> >>> Based on: >> >>> ARM: save/restore diagnostic register on Cortex-A9 suspend/resume >> >>> http://www.spinics.net/lists/arm-kernel/msg340506.html >> >> [Ccing people who participated in discussion in that thread] >> >> >> >> >> As there is an outstanding issue with this patch, we can't proceed with >> >> this set of changes until we know what's going on there. >> > >> > Sure, I will wait for the conclusion. >> >> So I believe the conclusion was that this can't be handled in generic >> way, because on systems running in non-secure mode writing to those >> registers faults. > > That is, unfortunately, correct. > > There is a way around this, but people aren't going to like it. That > is - we move it to the suspend and resume paths anyway. > > In the resume path, we read the register, compare it with the value > which we would update it to, and if it's identical, we avoid the write. > > This gets secure-mode platforms working. > > For non-secure mode platforms, we have to require them to insert some > assembly code into the early resume path which calls their secure > monitor to restore these registers before continuing on to cpu_resume, > thereby ensuring that the CPU specific code sees that the value in the > register is identical with the saved value, and omitting the write. > > This isn't really a new principle - we already have this requirement > for non-secure mode platforms when they're booting a kernel with > various errata enabled. > > I can't see any other alternative which satisfies everyone (by > everyone, I'm including the requirements from the hardware folk who > expect these registers to be static once the MMU is enabled.) > > -- > FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly > improving, and getting towards what was expected from it. In that case i will re-post this after Russell post changes which conflict with that patch. > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
 |