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
