Re: [PATCH 1/2] mm/vmalloc: Export purge_vmap_area_lazy()
On Wed, Mar 24, 2010 at 1:26 PM, Benjamin Herrenschmidt wrote: > Some powerpc code needs to ensure that all previous iounmap/vunmap has > really been flushed out of the MMU hash table. Without that, various > hotplug operations may fail when trying to return those pieces to > the hypervisor due to existing active mappings. Are you talking about KVM or any other hypervisor ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: HELP:PowerPc-Linux kernel
Have you every worked on device trees before? On 7/28/11, Vijay Nikam wrote: > Hello, > > Start with looking at the configuration of the board done which is > similar to yours > or based on the same CPU as yours. It is important to know role of > device tree so > read the documentation and understand the syntax and concept of device > tree. Once > the complete concept is understood then you should start the > configuration and achieve > successful creation of kernel image. > > Take a step forward and do some hands on. If any problem occurs then > post for specific help, > as porting itself is a big task and dosent have really straight forward > steps. > Good Luck > > Kind Regards, > Vijay Nikam > > On Wed, Jul 27, 2011 at 8:33 PM, wrote: >> >> Hi, >> >> >> >> I have take up the new assignment Board bring up activity with Linux >> kernel on PowerPC MPC8272. >> >> I have been searching Linux bring up on PowerPC processor in Google and >> IBM wiki and not found good stuff. >> >> It would be more helpful for me if you could share related documents. >> >> >> >> Best regards >> >> Naresh Kamboju >> >> >> >> Please do not print this email unless it is absolutely necessary. >> >> The information contained in this electronic message and any attachments >> to this message are intended for the exclusive use of the addressee(s) and >> may contain proprietary, confidential or privileged information. If you >> are not the intended recipient, you should not disseminate, distribute or >> copy this e-mail. Please notify the sender immediately and destroy all >> copies of this message and any attachments. >> >> WARNING: Computer viruses can be transmitted via email. The recipient >> should check this email and any attachments for the presence of viruses. >> The company accepts no liability for any damage caused by any virus >> transmitted by this email. >> >> www.wipro.com >> >> ___ >> Linuxppc-dev mailing list >> Linuxppc-dev@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- -mj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: suspend-to-mem on the mpc8349e-mitx-gp?
"fsl,mpc8349-pmc" has .has_deep_sleep = 0, deep_sleeping=0 so the mem should not do anything and just do a standby. I am not sure if mem is a valid state in that case under /sys/power/state. Scott, u can fix it! -mj On Mon, Mar 23, 2009 at 11:15 AM, Li Yang-R58472 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Friday, March 20, 2009 10:42 PM > > To: Li Yang-R58472 > > Cc: Soohyung Cho; linuxppc-dev@ozlabs.org > > Subject: Re: suspend-to-mem on the mpc8349e-mitx-gp? > > > > Li Yang-R58472 wrote: > > >> However, the code should treat "mem" as "standby" on chips > > that don't > > >> support deep sleep. What does the device tree > > > > > > Well, shouldn't the valid() callback reject unsupported > > states instead > > > of covering up? > > > > I don't think so, in this case. The user is not asking for > > "sleep" or deep sleep"; they are asking for a power state > > that meets the definition of "standby" (which sleep does) or > > which meets the definition of "mem" > > (which both sleep and deep sleep do). When the user asks for > > "mem", we provide the lowest power mode that qualifies. > > In my understanding, "mem" which is suspend-to-ram means all CPU states and > registers are kept in memory and the CPU is completely off during > suspension. I don't think the sleep mode of 8349 qualifies, does it? > > - Leo > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework
On Thu, Jul 1, 2010 at 4:12 PM, Alexander Graf wrote: > On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the > hypervisor extensions. > > While that is all great to show that virtualization is possible, there are > quite some cases where the emulation overhead of privileged instructions is > killing performance. > > This patchset tackles exactly that issue. It introduces a paravirtual > framework > using which KVM and Linux share a page to exchange register state with. That KVM and Linux or KVM and GuestOS ? > way we don't have to switch to the hypervisor just to change a value of a > privileged register. > > To prove my point, I ran the same test I did for the MMU optimizations against > the PV framework. Here are the results: > > [without] > > debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null; > done > > real 0m14.659s > user 0m8.967s > sys 0m5.688s > > [with] > > debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null; > done > > real 0m7.557s > user 0m4.121s > sys 0m3.426s > > > So this is a significant performance improvement! I'm quite happy how fast > this > whole thing becomes :) > > I tried to take all comments I've heard from people so far about such a PV > framework into account. In case you told me something before that is a no-go > and I still did it, please just tell me again. > > Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start > experiencing the power yourself. - heh > > v1 -> v2: > > - change hypervisor calls to use r0 and r3 > - make crit detection only trigger in supervisor mode > - RMO -> PAM > - introduce kvm_patch_ins > - only flush icache when patching > - introduce kvm_patch_ins_b > - update documentation > > Alexander Graf (27): > KVM: PPC: Introduce shared page > KVM: PPC: Convert MSR to shared page > KVM: PPC: Convert DSISR to shared page > KVM: PPC: Convert DAR to shared page. > KVM: PPC: Convert SRR0 and SRR1 to shared page > KVM: PPC: Convert SPRG[0-4] to shared page > KVM: PPC: Implement hypervisor interface > KVM: PPC: Add PV guest critical sections > KVM: PPC: Add PV guest scratch registers > KVM: PPC: Tell guest about pending interrupts > KVM: PPC: Make RMO a define > KVM: PPC: First magic page steps > KVM: PPC: Magic Page Book3s support > KVM: PPC: Magic Page BookE support > KVM: PPC: Expose magic page support to guest > KVM: Move kvm_guest_init out of generic code > KVM: PPC: Generic KVM PV guest support > KVM: PPC: KVM PV guest stubs > KVM: PPC: PV instructions to loads and stores > KVM: PPC: PV tlbsync to nop > KVM: PPC: Introduce kvm_tmp framework > KVM: PPC: Introduce branch patching helper > KVM: PPC: PV assembler helpers > KVM: PPC: PV mtmsrd L=1 > KVM: PPC: PV mtmsrd L=0 and mtmsr > KVM: PPC: PV wrteei > KVM: PPC: Add Documentation about PV interface > > Documentation/kvm/ppc-pv.txt | 185 ++ > arch/powerpc/include/asm/kvm_book3s.h | 1 - > arch/powerpc/include/asm/kvm_host.h | 15 +- > arch/powerpc/include/asm/kvm_para.h | 121 +- > arch/powerpc/include/asm/kvm_ppc.h | 1 + > arch/powerpc/kernel/Makefile | 2 + > arch/powerpc/kernel/asm-offsets.c | 18 ++- > arch/powerpc/kernel/kvm.c | 408 > ++ > arch/powerpc/kernel/kvm_emul.S | 237 + > arch/powerpc/kvm/44x.c | 7 + > arch/powerpc/kvm/44x_tlb.c | 8 +- > arch/powerpc/kvm/book3s.c | 165 - > arch/powerpc/kvm/book3s_32_mmu.c | 28 ++- > arch/powerpc/kvm/book3s_32_mmu_host.c | 16 +- > arch/powerpc/kvm/book3s_64_mmu.c | 42 +++- > arch/powerpc/kvm/book3s_64_mmu_host.c | 16 +- > arch/powerpc/kvm/book3s_emulate.c | 25 +- > arch/powerpc/kvm/book3s_paired_singles.c | 11 +- > arch/powerpc/kvm/booke.c | 113 +++-- > arch/powerpc/kvm/booke.h | 6 +- > arch/powerpc/kvm/booke_emulate.c | 14 +- > arch/powerpc/kvm/booke_interrupts.S | 3 +- > arch/powerpc/kvm/e500.c | 7 + > arch/powerpc/kvm/e500_tlb.c | 31 ++- > arch/powerpc/kvm/e500_tlb.h | 2 +- > arch/powerpc/kvm/emulate.c | 47 +++- > arch/powerpc/kvm/powerpc.c | 42 +++- > arch/powerpc/platforms/Kconfig | 10 + > arch/x86/include/asm/kvm_para.h | 6 + > include/linux/kvm_para.h | 7 +- > 30 files changed, 1420 insertions(+), 174 deletions(-) > create mode 100644 Documentation/kvm/ppc-pv.txt > create mode 100644 arch/powerpc/kernel/kvm.c > create mode 100644 arch/powerpc/kernel/kvm_emul.S > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordo
Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf wrote: > We just introduced a new PV interface that screams for documentation. So here > it is - a shiny new and awesome text file describing the internal works of > the PPC KVM paravirtual interface. > > Signed-off-by: Alexander Graf > > --- > > v1 -> v2: > > - clarify guest implementation > - clarify that privileged instructions still work > - explain safe MSR bits > - Fix dsisr patch description > - change hypervisor calls to use new register values > --- > Documentation/kvm/ppc-pv.txt | 185 > ++ > 1 files changed, 185 insertions(+), 0 deletions(-) > create mode 100644 Documentation/kvm/ppc-pv.txt > > diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt > new file mode 100644 > index 000..82de6c6 > --- /dev/null > +++ b/Documentation/kvm/ppc-pv.txt > @@ -0,0 +1,185 @@ > +The PPC KVM paravirtual interface > += > + > +The basic execution principle by which KVM on PowerPC works is to run all > kernel > +space code in PR=1 which is user space. This way we trap all privileged > +instructions and can emulate them accordingly. > + > +Unfortunately that is also the downfall. There are quite some privileged > +instructions that needlessly return us to the hypervisor even though they > +could be handled differently. > + > +This is what the PPC PV interface helps with. It takes privileged > instructions > +and transforms them into unprivileged ones with some help from the > hypervisor. > +This cuts down virtualization costs by about 50% on some of my benchmarks. > + > +The code for that interface can be found in arch/powerpc/kernel/kvm* > + > +Querying for existence > +== > + > +To find out if we're running on KVM or not, we overlay the PVR register. > Usually > +the PVR register contains an id that identifies your CPU type. If, however, > you > +pass KVM_PVR_PARA in the register that you want the PVR result in, the > register > +still contains KVM_PVR_PARA after the mfpvr call. > + > + LOAD_REG_IMM(r5, KVM_PVR_PARA) > + mfpvr r5 > + [r5 still contains KVM_PVR_PARA] > + > +Once determined to run under a PV capable KVM, you can now use hypercalls as > +described below. > + > +PPC hypercalls > +== > + > +The only viable ways to reliably get from guest context to host context are: > + > + 1) Call an invalid instruction > + 2) Call the "sc" instruction with a parameter to "sc" > + 3) Call the "sc" instruction with parameters in GPRs > + > +Method 1 is always a bad idea. Invalid instructions can be replaced later on > +by valid instructions, rendering the interface broken. > + > +Method 2 also has downfalls. If the parameter to "sc" is != 0 the spec is > +rather unclear if the sc is targeted directly for the hypervisor or the > +supervisor. It would also require that we read the syscall issuing > instruction > +every time a syscall is issued, slowing down guest syscalls. > + > +Method 3 is what KVM uses. We pass magic constants (KVM_SC_MAGIC_R0 and > +KVM_SC_MAGIC_R3) in r0 and r3 respectively. If a syscall instruction with > these > +magic values arrives from the guest's kernel mode, we take the syscall as a > +hypercall. > + > +The parameters are as follows: > + > + r0 KVM_SC_MAGIC_R0 > + r3 KVM_SC_MAGIC_R3 Return code > + r4 Hypercall number > + r5 First parameter > + r6 Second parameter > + r7 Third parameter > + r8 Fourth parameter > + > +Hypercall definitions are shared in generic code, so the same hypercall > numbers > +apply for x86 and powerpc alike. > + > +The magic page > +== > + > +To enable communication between the hypervisor and guest there is a new > shared > +page that contains parts of supervisor visible register state. The guest can > +map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE. > + > +With this hypercall issued the guest always gets the magic page mapped at the > +desired location in effective and physical address space. For now, we always > +map the page to -4096. This way we can access it using absolute load and > store > +functions. The following instruction reads the first field of the magic page: > + > + ld rX, -4096(0) > + > +The interface is designed to be extensible should there be need later to add > +additional registers to the magic page. If you add fields to the magic page, > +also define a new hypercall feature to indicate that the host can give you > more > +registers. Only if the host supports the additional features, make use of > them. > + > +The magic page has the following layout as described in > +arch/powerpc/include/asm/kvm_para.h: > + > +struct kvm_vcpu_arch_shared { > + __u64 scratch1; > + __u64 scratch2; > + __u64 scratch3; > + _
Re: How to use mpc8xxx_gpio.c device driver
u can directly access GPIO registers in kernel, by ioremap of GPIO memory mapped registers. you might need to check - muxing of gpio -mj On Wed, Aug 11, 2010 at 6:57 PM, Ravi Gupta wrote: > Hi, > > I am new to device driver development. I am trying to access the GPIO of > MPC837xERDB eval board. I have upgraded its kernel to linux-2.6.28.9 and > enable support for mpc8xxx_gpio.c. On boot up, it successfully detect two > gpio controllers. Now my question is how I am going to use it to communicate > with the gpio pins? Do I have to modify the code in mpc8xxx_gpio.c file to > do whatever I want to do with gpios or I can use the standard gpio API > provided in kernel ( gpio_request()/gpio_free() ). I also tries the standard > kernel API, but it fails. Here is my code : > > #include > #include /* error codes */ > #include > > static __init int sample_module_init(void) > { > int ret; > > int i; > for (i=1; i<32; i++) { > ret = gpio_request(i, "Sample Driver"); > if (ret) { > printk(KERN_WARNING "sample_driver: unable to request GPIO_PG%d\n", > i); > //return ret; > } > } > > return 0; > } > > static __exit void sample_module_exit(void) > { > gpio_free(9); > } > > MODULE_LICENSE("GPL"); > > module_init(sample_module_init); > module_exit(sample_module_exit); > > It give the following O/P: > > [ 617.075329] sample_driver: unable to request GPIO_PG1 > [ 617.080418] sample_driver: unable to request GPIO_PG2 > [ 617.085470] sample_driver: unable to request GPIO_PG3 > [ 617.090522] sample_driver: unable to request GPIO_PG4 > [ 617.095574] sample_driver: unable to request GPIO_PG5 > [ 617.100625] sample_driver: unable to request GPIO_PG6 > [ 617.105676] sample_driver: unable to request GPIO_PG7 > [ 617.110727] sample_driver: unable to request GPIO_PG8 > [ 617.115779] sample_driver: unable to request GPIO_PG9 > [ 617.120830] sample_driver: unable to request GPIO_PG10 > [ 617.125968] sample_driver: unable to request GPIO_PG11 > [ 617.131106] sample_driver: unable to request GPIO_PG12 > [ 617.136245] sample_driver: unable to request GPIO_PG13 > [ 617.141383] sample_driver: unable to request GPIO_PG14 > [ 617.146521] sample_driver: unable to request GPIO_PG15 > [ 617.151660] sample_driver: unable to request GPIO_PG16 > [ 617.156798] sample_driver: unable to request GPIO_PG17 > [ 617.161936] sample_driver: unable to request GPIO_PG18 > [ 617.167074] sample_driver: unable to request GPIO_PG19 > [ 617.172213] sample_driver: unable to request GPIO_PG20 > [ 617.177351] sample_driver: unable to request GPIO_PG21 > [ 617.182489] sample_driver: unable to request GPIO_PG22 > [ 617.187628] sample_driver: unable to request GPIO_PG23 > [ 617.192767] sample_driver: unable to request GPIO_PG24 > [ 617.197905] sample_driver: unable to request GPIO_PG25 > [ 617.203042] sample_driver: unable to request GPIO_PG26 > [ 617.208182] sample_driver: unable to request GPIO_PG27 > [ 617.213319] sample_driver: unable to request GPIO_PG28 > [ 617.218458] sample_driver: unable to request GPIO_PG29 > [ 617.223597] sample_driver: unable to request GPIO_PG30 > [ 617.228735] sample_driver: unable to request GPIO_PG31 > [ 617.233873] sample_driver: unable to request GPIO_PG32 > > Can someone provide me a sample code or something else. Actually I am trying > to set the GPIO pin no. 9 to active low as it is connected to a LED on > board. > > Thanks in advance > Ravi Gupta > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- -mj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev