On Thu, Feb 23, 2012 at 10:30 PM, Stephen Rothwell
wrote:
> [Just adding the PPC guys]
>
> On Fri, 24 Feb 2012 16:25:04 +1100 Stephen Rothwell
> wrote:
>>
>> Hi Grant,
>>
>> Today's linux-next merge of the irqdomain tree got a conflict in
>> arch/powerpc/sysdev/mpic.c between commits 3a7a7176e8
[Just adding the PPC guys]
On Fri, 24 Feb 2012 16:25:04 +1100 Stephen Rothwell
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 mpic_alloc()") and
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 remem
> 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
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 36
> 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
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 t
>
> 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.
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 3
> > -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: a
> -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 CONFIG_
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 su
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 memor
> > 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 tha
> -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 CONFI
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 Likely
> >wrote:
> >>On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
> >> wrote:
> >>>* Grant Likely | 2012-01-30 12:58:42
On 02/23/2012 08:56 PM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 11:06 AM, Grant Likely wrote:
On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
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 mer
On Thu, Feb 23, 2012 at 12:25 PM, Jesse Barnes wrote:
> On Fri, 10 Feb 2012 08:35:58 +1100
> Benjamin Herrenschmidt 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
>> > should be simply the arch telling the
On Thu, Feb 23, 2012 at 1:25 PM, Russell King - ARM Linux
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 that's because the
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 o
On Fri, 10 Feb 2012 08:35:58 +1100
Benjamin Herrenschmidt 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
> > should be simply the arch telling the core "this is the range of bus
> > numbers you can use." If th
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 Wed, Feb 1, 2012 at 11:06 AM, Grant Likely wrote:
> On Wed, Feb 1, 2012 at 7:17 AM, Sebastian Andrzej Siewior
> 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 merge this patch. I don't have the ti
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 Herrensc
On Wed, Feb 22, 2012 at 1:41 PM, Benjamin Herrenschmidt
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
>> b/arch/powerpc/platforms/pasemi/pci.c
>> index b6a
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
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;
}
include/linux/of_gp
Discard the old way that invoke hypercall,
instead, use epapr paravirt.
Signed-off-by: Liu Yu
---
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 +++---
If the guest hypervisor node contains "has-idle" property.
Signed-off-by: Liu Yu
---
v6:
reuse the EV_IDLE definition
arch/powerpc/include/asm/epapr_hcalls.h | 11 ++-
arch/powerpc/kernel/epapr_hcalls.S | 27 +++
arch/powerpc/kernel/epapr_paravirt.c|
And add a new flag definition in kvm_ppc_pvinfo to indicate
whether host support EV_IDLE hcall.
Signed-off-by: Liu Yu
---
v6: no change
arch/powerpc/include/asm/Kbuild |1 +
arch/powerpc/include/asm/kvm_para.h | 14 --
arch/powerpc/kvm/powerpc.c |6 ++
inc
from the kvm guest paravirt init code.
Signed-off-by: Liu Yu
---
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 +
arch/powerpc/kernel/epapr_hcall
31 matches
Mail list logo
