On Tue, Jun 14, 2011 at 10:07 PM, Timur Tabi <ti...@freescale.com> wrote: > Timur Tabi wrote: >> Hmmm.... I find that surprising. Memory allocated via ioremap() is supposed >> to >> be available in interrupt handlers, where TLB mappings can't be created >> on-the-fly. I'm not sure that your observation is correct. > > Ok, it turns out I'm wrong. As long as the page is in the page tables (i.e. > physically present in RAM), you can take a TLB miss in an interrupt handler, > and > the TLB miss handler will create a TLB for you. > > This means that ... > >> unsigned long dummy = *(volatile unsigned long *)p; >> (void)dummy; >> } >> >> * After these changes (make sure all code is mapped + make sure to >> read all pages so that the TLBs are updated), my scenario works fine. > > is not going to work reliably, because it assumes that the TLBs created by > your > multiple ioremap() calls will still be there when your code is called. > > If you use just a single ioremap() call, but still touch every page, that > should > work for you just as well.
I am using a single __ioremap call. You have a point about the reliability of this: if an interrupt occurs between the mapping or dummy reading, and the point where the actual code is executing, some TLB entries may have been replaced, right? I think I can make it more reliable by dummy reading the pages *after* I disabled interrupts on that processor, immediately before jumping to the boot code. Is that correct? (note that I have to disable interrupts anyhow for the boot code to work properly without interruptions to 'linux land'. Thanks for your input, Thomas _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
