On Apr 15, 2010, at 1:45 PM, Anton Vorontsov wrote: > On Thu, Feb 25, 2010 at 12:38:02AM +0300, Anton Vorontsov wrote: >> This is started as swsusp_32.S modifications, but the amount of #ifdefs >> made the whole file horribly unreadable, so let's put the support into >> its own separate file. >> >> The code should be relatively easy to modify to support 44x BookEs as >> well, but since I don't have any 44x to test, let's confine the code to >> FSL BookE. (The only FSL-specific parts are 'flush_dcache_L1' and TLB >> invalidation code). >> >> Signed-off-by: Anton Vorontsov <avoront...@ru.mvista.com> >> --- >> >> Sorry for the delayed response... >> >> On Tue, Jan 12, 2010 at 01:34:08PM +1100, Benjamin Herrenschmidt wrote: >> [...] >>> Here's a quick review. Looks good but two things: >>> >>> - Please make it swsusp_booke.c, 44x support is trivial and I don't >>> want to rename the file :-) >> >> Done. >> >>> - Is there really an SDR1 register on FSL BookE ? It's supposed to be >>> the pointer to the hash table on server ... >> >> Thanks, fixed. >> >>> - You probably should save/restore the TCR and ack pending crap DEC or >>> FIT interrupts in the TSR right before you kick the decrementer >> >> Done. >> >>> - Nowadays, we still assume that the "loader" kernel is exactly the >>> same as the "loaded" kernel on resume ? >> >> I'm pretty sure today we do rely on this, yes. This is not some >> generic code limitation though, it's just hard to test the case >> when loader != loaded. In most cases it will work fine since the >> loader kernel wouldn't differ a lot from the loaded kernel, so >> it'll setup the low level stuff the same way. >> >> We may try to link the loader kernel to a different address >> (relocate it as in kdump case), and hope that it'll trigger >> all sort of problems so that we could fix them. >> >> Though, the better test case would be to resume the hibernated >> kernel directly from the bootloader. > > Kumar, > > According to patchwork, this is now delegated to you. Do you > have any objections to merge this?
Would like Scott's Ack. - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
