from the kvm guest paravirt init code.
Signed-off-by: Liu Yu yu@freescale.com
---
v6:
1. rename epapr_para to epapr_paravirt
2. remove redundant warnings
3. remove unnecessary init
arch/powerpc/include/asm/epapr_hcalls.h |2 +
arch/powerpc/kernel/Makefile|1 +
And add a new flag definition in kvm_ppc_pvinfo to indicate
whether host support EV_IDLE hcall.
Signed-off-by: Liu Yu yu@freescale.com
---
v6: no change
arch/powerpc/include/asm/Kbuild |1 +
arch/powerpc/include/asm/kvm_para.h | 14 --
arch/powerpc/kvm/powerpc.c
If the guest hypervisor node contains has-idle property.
Signed-off-by: Liu Yu yu@freescale.com
---
v6:
reuse the EV_IDLE definition
arch/powerpc/include/asm/epapr_hcalls.h | 11 ++-
arch/powerpc/kernel/epapr_hcalls.S | 27 +++
Discard the old way that invoke hypercall,
instead, use epapr paravirt.
Signed-off-by: Liu Yu yu@freescale.com
---
v6:
select epapr_paravirt when enable fsl_hv driver
arch/powerpc/include/asm/epapr_hcalls.h | 22 +-
arch/powerpc/include/asm/fsl_hcalls.h | 36
What's this stuff doing in generic drivers?
See drivers/gpio/gpio-xilinx.c:
static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
{
struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
return (in_be32(mm_gc-regs + XGPIO_DATA_OFFSET) gpio) 1;
}
Huang Changming-R66093 wrote:
I have one similar patch to remove the select PHYS_64BIT.
http://patchwork.ozlabs.org/patch/132351/
That one doesn't update the defconfigs, which means that the default
kernel will not have PHYS_64BIT enabled.
--
Timur Tabi
Linux kernel developer at Freescale
On Wed, Feb 22, 2012 at 1:41 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2012-02-22 at 11:19 -0700, Bjorn Helgaas wrote:
int maple_pci_get_legacy_ide_irq(struct pci_dev *pdev, int channel)
diff --git a/arch/powerpc/platforms/pasemi/pci.c
We already use pci_flags, so this just sets pci_flags directly and removes
the intermediate step of figuring out pci_probe_only, then using it to set
pci_flags.
The PCI core provides a pci_flags definition (currently __weak), so drop
the powerpc definitions in favor of that.
CC: Benjamin
On Wed, Feb 1, 2012 at 11:06 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
* Grant Likely | 2012-01-30 12:58:42 [-0700]:
Ugh. This isn't easy. The legacy mapping really needs all the
Feel free to
On Thu, 2012-02-23 at 11:29 +, Russell King - ARM Linux wrote:
What's this stuff doing in generic drivers?
Well, I suppose that's because the xilinx stuff used to be ppc
only ? :-)
See drivers/gpio/gpio-xilinx.c:
static int xgpio_get(struct gpio_chip *gc, unsigned int gpio)
{
On Fri, Feb 24, 2012 at 07:18:59AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2012-02-23 at 11:29 +, Russell King - ARM Linux wrote:
What's this stuff doing in generic drivers?
Well, I suppose that's because the xilinx stuff used to be ppc
only ? :-)
Note that's just the first one
On Thu, Feb 23, 2012 at 1:25 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Feb 24, 2012 at 07:18:59AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2012-02-23 at 11:29 +, Russell King - ARM Linux wrote:
What's this stuff doing in generic drivers?
Well, I suppose
On Thu, Feb 23, 2012 at 12:25 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 10 Feb 2012 08:35:58 +1100
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Thu, 2012-02-09 at 11:24 -0800, Bjorn Helgaas wrote:
My point is that the interface between the arch and the PCI core
On 02/23/2012 08:56 PM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 11:06 AM, Grant Likelygrant.lik...@secretlab.ca wrote:
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
* Grant Likely | 2012-01-30 12:58:42 [-0700]:
Ugh. This isn't easy. The legacy
On Thu, Feb 23, 2012 at 10:22:15PM +0100, Sebastian Andrzej Siewior wrote:
On 02/23/2012 08:56 PM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 11:06 AM, Grant Likelygrant.lik...@secretlab.ca
wrote:
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
*
-Original Message-
From: Tabi Timur-B04825
Sent: Thursday, February 23, 2012 8:25 PM
To: Huang Changming-R66093
Cc: ga...@kernel.crashing.org; b...@kernel.crashing.org; Wood Scott-
B07421; Li Yang-R58472; linuxppc-...@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: allow
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be
selectable
Huang Changming-R66093 wrote:
I have one similar patch to remove the select PHYS_64BIT.
http://patchwork.ozlabs.org/patch/132351/
That one doesn't update the defconfigs, which means that the default
I never did get this to work, and now I am back to it again.
On Fri, Oct 14, 2011 at 09:39:51AM +0200, Benjamin Herrenschmidt wrote:
On Wed, 2011-10-12 at 16:08 -0500, Ayman El-Khashab wrote:
I'm using the 460sx (440 core) so no snooping here. What
I've done is reserved the top of memory
Li Yang-R58472 wrote:
I agree with Changming that we shouldn't setting PHYS_64BIT by default.
The default kernel should always be the compatible with as much as
possible. Disabling PHYS_64BIT by default means that the default kernel
will not work with a 36-bit DTS. If you attempt to boot
-Original Message-
From: Tabi Timur-B04825
Sent: Friday, February 24, 2012 10:46 AM
To: Li Yang-R58472
Cc: Huang Changming-R66093; ga...@kernel.crashing.org;
b...@kernel.crashing.org; Wood Scott-B07421; linuxppc-...@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: allow
-Original Message-
From: Tabi Timur-B04825
Sent: Friday, February 24, 2012 10:46 AM
To: Li Yang-R58472
Cc: Huang Changming-R66093; ga...@kernel.crashing.org;
b...@kernel.crashing.org; Wood Scott-B07421; linuxppc-...@ozlabs.org
Subject: Re: [PATCH] powerpc/85xx: allow
Li Yang-R58472 wrote:
Even though the user still need to know the addressing mode that u-boot
is using. It won't work if the addressing mode of u-boot and device
tree are different.
U-Boot will tell the user if the DT does not match. I added code to
U-Boot to do that. So if you have a
Li Yang-R58472 wrote:
Even though the user still need to know the addressing mode that
u-boot is using. It won't work if the addressing mode of u-boot and
device tree are different.
U-Boot will tell the user if the DT does not match. I added code to U-
Boot to do that. So if you
Huang Changming-R66093 wrote:
I want to know if you have the other codes for different address?
The current U-boot just detect the base address of DTS and the CCSR address.
If they are different, u-boot will print the warning and return 0,
so the kernel can't been booted.
I had a patch that
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be
selectable
Li Yang-R58472 wrote:
Even though the user still need to know the addressing mode that
u-boot is using. It won't work if the addressing mode of u-boot and
device tree are different.
U-Boot will tell the
Li Yang-R58472 wrote:
The mpc85xx_defconfig does include silicons with e500v1 core which
doesn't have the 36-bit support. Won't enabling 36-bit support by
default break the support for them?
No. The kernel will detect at runtime that that it's an e500v1 core and
it won't try to create
Subject: Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be
selectable
Li Yang-R58472 wrote:
The mpc85xx_defconfig does include silicons with e500v1 core which
doesn't have the 36-bit support. Won't enabling 36-bit support by
default break the support for them?
No. The
Li Yang-R58472 wrote:
It's a good point. Why can't we decide to use 32-bit/36-bit TLB at runtime
even for e500v2?
That's not what PHYS_64BIT does. PHYS_64BIT determines whether
phys_addr_t is a u64 or a u32. This is something that must be determined
at compilation time.
Please remember
[Just adding the PPC guys]
On Fri, 24 Feb 2012 16:25:04 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Grant,
Today's linux-next merge of the irqdomain tree got a conflict in
arch/powerpc/sysdev/mpic.c between commits 3a7a7176e840 (powerpc/mpic:
Fix use of flags variable in
On Thu, Feb 23, 2012 at 10:30 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
[Just adding the PPC guys]
On Fri, 24 Feb 2012 16:25:04 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Grant,
Today's linux-next merge of the irqdomain tree got a conflict in
30 matches
Mail list logo
