* Re: [PATCH -V2 1/4] mm/cma: Move dma contiguous changes into a seperate config
From: Aneesh Kumar K.V @ 2013-07-01 13:01 UTC (permalink / raw)
To: Michal Nazarewicz, benh, paulus, linux-mm, m.szyprowski; +Cc: linuxppc-dev
In-Reply-To: <xa1tzju6sdjx.fsf@mina86.com>
Michal Nazarewicz <mina86@mina86.com> writes:
> On Fri, Jun 28 2013, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> We want to use CMA for allocating hash page table and real mode area for
>> PPC64. Hence move DMA contiguous related changes into a seperate config
>> so that ppc64 can enable CMA without requiring DMA contiguous.
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
>
>> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
>> index 07abd9d..74b7c98 100644
>> --- a/drivers/base/Kconfig
>> +++ b/drivers/base/Kconfig
>> @@ -202,11 +202,10 @@ config DMA_SHARED_BUFFER
>> APIs extension; the file's descriptor can then be passed on to other
>> driver.
>>
>> -config CMA
>> - bool "Contiguous Memory Allocator"
>> - depends on HAVE_DMA_CONTIGUOUS && HAVE_MEMBLOCK
>> - select MIGRATION
>> - select MEMORY_ISOLATION
>> +config DMA_CMA
>> + bool "DMA Contiguous Memory Allocator"
>> + depends on HAVE_DMA_CONTIGUOUS
>> + select CMA
>
> Just to be on the safe side, I'd add
>
> depends on HAVE_MEMBLOCK
>
> or change this so that it does not select CMA but depends on CMA.
updated this to
+config DMA_CMA
+ bool "DMA Contiguous Memory Allocator"
+ depends on HAVE_DMA_CONTIGUOUS && CMA
>
>> help
>> This enables the Contiguous Memory Allocator which allows drivers
>> to allocate big physically-contiguous blocks of memory for use with
>> @@ -215,17 +214,7 @@ config CMA
>> For more information see <include/linux/dma-contiguous.h>.
>> If unsure, say "n".
>>
>> -if CMA
>> -
>> -config CMA_DEBUG
>> - bool "CMA debug messages (DEVELOPMENT)"
>> - depends on DEBUG_KERNEL
>> - help
>> - Turns on debug messages in CMA. This produces KERN_DEBUG
>> - messages for every CMA call as well as various messages while
>> - processing calls such as dma_alloc_from_contiguous().
>> - This option does not affect warning and error messages.
>> -
Thanks
-aneesh
^ permalink raw reply
* [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci, Russell King, Grant Likely, Rob Herring,
Thomas Gleixner, Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, linux-mips, linux-ia64, Heiko Carstens,
Thierry Reding, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-s390, x86, Ingo Molnar, Ezequiel Garcia, Fenghua Yu,
Chris Metcalf, linux-arm-kernel, Tony Luck, Ralf Baechle,
Maen Suleiman, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Until now, the MSI architecture-specific functions could be overloaded
using a fairly complex set of #define and compile-time
conditionals. In order to prepare for the introduction of the msi_chip
infrastructure, it is desirable to switch all those functions to use
the 'weak' mechanism. This commit converts all the architectures that
were overidding those MSI functions to use the new strategy.
Note that we keep a separate, non-weak, function
default_teardown_msi_irqs() for the default behavior of the
arch_teardown_msi_irqs(), as the default behavior is needed by the Xen
x86 PCI code.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
---
arch/mips/include/asm/pci.h | 5 -----
arch/powerpc/include/asm/pci.h | 5 -----
arch/s390/include/asm/pci.h | 4 ----
arch/x86/include/asm/pci.h | 28 --------------------------
arch/x86/kernel/x86_init.c | 21 ++++++++++++++++++++
drivers/pci/msi.c | 45 +++++++++++++++++++-----------------------
include/linux/msi.h | 7 ++++++-
7 files changed, 47 insertions(+), 68 deletions(-)
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index b8e24fd..031f4c1 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -137,11 +137,6 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
return channel ? 15 : 14;
}
-#ifdef CONFIG_CPU_CAVIUM_OCTEON
-/* MSI arch hook for OCTEON */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#endif
-
extern char * (*pcibios_plat_setup)(char *str);
#ifdef CONFIG_OF
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 6653f27..95145a1 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -113,11 +113,6 @@ extern int pci_domain_nr(struct pci_bus *bus);
/* Decide whether to display the domain number in /proc */
extern int pci_proc_domain(struct pci_bus *bus);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-#define arch_msi_check_device arch_msi_check_device
-
struct vm_area_struct;
/* Map a range of PCI memory or I/O space for a device into user space */
int pci_mmap_page_range(struct pci_dev *pdev, struct vm_area_struct *vma,
diff --git a/arch/s390/include/asm/pci.h b/arch/s390/include/asm/pci.h
index 6c18012..8641e8d 100644
--- a/arch/s390/include/asm/pci.h
+++ b/arch/s390/include/asm/pci.h
@@ -21,10 +21,6 @@ void pci_iounmap(struct pci_dev *, void __iomem *);
int pci_domain_nr(struct pci_bus *);
int pci_proc_domain(struct pci_bus *);
-/* MSI arch hooks */
-#define arch_setup_msi_irqs arch_setup_msi_irqs
-#define arch_teardown_msi_irqs arch_teardown_msi_irqs
-
#define ZPCI_BUS_NR 0 /* default bus number */
#define ZPCI_DEVFN 0 /* default device number */
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index d9e9e6c..8c61de0 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -100,29 +100,6 @@ static inline void early_quirks(void) { }
extern void pci_iommu_alloc(void);
#ifdef CONFIG_PCI_MSI
-/* MSI arch specific hooks */
-static inline int x86_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
-{
- return x86_msi.setup_msi_irqs(dev, nvec, type);
-}
-
-static inline void x86_teardown_msi_irqs(struct pci_dev *dev)
-{
- x86_msi.teardown_msi_irqs(dev);
-}
-
-static inline void x86_teardown_msi_irq(unsigned int irq)
-{
- x86_msi.teardown_msi_irq(irq);
-}
-static inline void x86_restore_msi_irqs(struct pci_dev *dev, int irq)
-{
- x86_msi.restore_msi_irqs(dev, irq);
-}
-#define arch_setup_msi_irqs x86_setup_msi_irqs
-#define arch_teardown_msi_irqs x86_teardown_msi_irqs
-#define arch_teardown_msi_irq x86_teardown_msi_irq
-#define arch_restore_msi_irqs x86_restore_msi_irqs
/* implemented in arch/x86/kernel/apic/io_apic. */
struct msi_desc;
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
@@ -130,11 +107,6 @@ void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev, int irq);
int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
unsigned int irq_base, unsigned int irq_offset);
-/* default to the implementation in drivers/lib/msi.c */
-#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#define HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_teardown_msi_irqs(struct pci_dev *dev);
-void default_restore_msi_irqs(struct pci_dev *dev, int irq);
#else
#define native_setup_msi_irqs NULL
#define native_teardown_msi_irq NULL
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 45a14db..a2b189c 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -116,6 +116,27 @@ struct x86_msi_ops x86_msi = {
.setup_hpet_msi = default_setup_hpet_msi,
};
+/* MSI arch specific hooks */
+int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ return x86_msi.setup_msi_irqs(dev, nvec, type);
+}
+
+void arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ x86_msi.teardown_msi_irqs(dev);
+}
+
+void arch_teardown_msi_irq(unsigned int irq)
+{
+ x86_msi.teardown_msi_irq(irq);
+}
+
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq)
+{
+ x86_msi.restore_msi_irqs(dev, irq);
+}
+
struct x86_io_apic_ops x86_io_apic_ops = {
.init = native_io_apic_init_mappings,
.read = native_io_apic_read,
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 2c10752..289fbfd 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -30,20 +30,21 @@ static int pci_msi_enable = 1;
/* Arch hooks */
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
{
- return 0;
+ return -EINVAL;
}
-#endif
-#ifndef arch_setup_msi_irqs
-# define arch_setup_msi_irqs default_setup_msi_irqs
-# define HAVE_DEFAULT_MSI_SETUP_IRQS
-#endif
+void __weak arch_teardown_msi_irq(unsigned int irq)
+{
+}
-#ifdef HAVE_DEFAULT_MSI_SETUP_IRQS
-int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+ return 0;
+}
+
+int __weak arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
struct msi_desc *entry;
int ret;
@@ -65,14 +66,11 @@ int default_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
return 0;
}
-#endif
-#ifndef arch_teardown_msi_irqs
-# define arch_teardown_msi_irqs default_teardown_msi_irqs
-# define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
-#endif
-
-#ifdef HAVE_DEFAULT_MSI_TEARDOWN_IRQS
+/*
+ * We have a default implementation available as a separate non-weak
+ * function, as it is used by the Xen x86 PCI code
+ */
void default_teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *entry;
@@ -86,15 +84,13 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
arch_teardown_msi_irq(entry->irq + i);
}
}
-#endif
-#ifndef arch_restore_msi_irqs
-# define arch_restore_msi_irqs default_restore_msi_irqs
-# define HAVE_DEFAULT_MSI_RESTORE_IRQS
-#endif
+void __weak arch_teardown_msi_irqs(struct pci_dev *dev)
+{
+ return default_teardown_msi_irqs(dev);
+}
-#ifdef HAVE_DEFAULT_MSI_RESTORE_IRQS
-void default_restore_msi_irqs(struct pci_dev *dev, int irq)
+void __weak arch_restore_msi_irqs(struct pci_dev *dev, int irq)
{
struct msi_desc *entry;
@@ -111,7 +107,6 @@ void default_restore_msi_irqs(struct pci_dev *dev, int irq)
if (entry)
write_msi_msg(irq, &entry->msg);
}
-#endif
static void msi_set_enable(struct pci_dev *dev, int enable)
{
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 20c2d6d..c82ff8d 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -50,12 +50,17 @@ struct msi_desc {
};
/*
- * The arch hook for setup up msi irqs
+ * The arch hooks to setup up msi irqs. Those functions are
+ * implemented as weak symbols so that they /can/ be overriden by
+ * architecture specific code if needed.
*/
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
void arch_teardown_msi_irq(unsigned int irq);
int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
void arch_teardown_msi_irqs(struct pci_dev *dev);
int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
+void arch_restore_msi_irqs(struct pci_dev *dev, int irq);
+
+void default_teardown_msi_irqs(struct pci_dev *dev);
#endif /* LINUX_MSI_H */
--
1.8.1.2
^ permalink raw reply related
* [PATCHv4 03/11] pci: remove ARCH_SUPPORTS_MSI kconfig option
From: Thomas Petazzoni @ 2013-07-01 13:42 UTC (permalink / raw)
To: Bjorn Helgaas, linux-pci, Russell King, Grant Likely, Rob Herring,
Thomas Gleixner, Jason Cooper, Andrew Lunn, Gregory Clement
Cc: Lior Amsalem, linux-mips, linux-ia64, Heiko Carstens,
Thierry Reding, Paul Mackerras, H. Peter Anvin, sparclinux,
linux-s390, x86, Ingo Molnar, Ezequiel Garcia, Fenghua Yu,
Chris Metcalf, linux-arm-kernel, Tony Luck, Ralf Baechle,
Maen Suleiman, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
In-Reply-To: <1372686136-1370-1-git-send-email-thomas.petazzoni@free-electrons.com>
Now that we have weak versions for each of the PCI MSI architecture
functions, we can actually build the MSI support for all platforms,
regardless of whether they provide or not architecture-specific
versions of those functions. For this reason, the ARCH_SUPPORTS_MSI
hidden kconfig boolean becomes useless, and this patch gets rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: David S. Miller <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
---
arch/arm/Kconfig | 1 -
arch/ia64/Kconfig | 1 -
arch/mips/Kconfig | 2 --
arch/powerpc/Kconfig | 1 -
arch/s390/Kconfig | 1 -
arch/sparc/Kconfig | 1 -
arch/tile/Kconfig | 1 -
arch/x86/Kconfig | 1 -
drivers/pci/Kconfig | 4 ----
9 files changed, 13 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8ab5962..3413679 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -435,7 +435,6 @@ config ARCH_NETX
config ARCH_IOP13XX
bool "IOP13xx-based"
depends on MMU
- select ARCH_SUPPORTS_MSI
select CPU_XSC3
select NEED_MACH_MEMORY_H
select NEED_RET_TO_USER
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 1a2b774..943d425 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -9,7 +9,6 @@ config IA64
select PCI if (!IA64_HP_SIM)
select ACPI if (!IA64_HP_SIM)
select PM if (!IA64_HP_SIM)
- select ARCH_SUPPORTS_MSI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 7a58ab9..96c1225 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -763,7 +763,6 @@ config CAVIUM_OCTEON_REFERENCE_BOARD
select SYS_HAS_CPU_CAVIUM_OCTEON
select SWAP_IO_SPACE
select HW_HAS_PCI
- select ARCH_SUPPORTS_MSI
select ZONE_DMA32
select USB_ARCH_HAS_OHCI
select USB_ARCH_HAS_EHCI
@@ -799,7 +798,6 @@ config NLM_XLR_BOARD
select CEVT_R4K
select CSRC_R4K
select IRQ_CPU
- select ARCH_SUPPORTS_MSI
select ZONE_DMA32 if 64BIT
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..f9d9d8e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -734,7 +734,6 @@ config PCI
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx && !GAMECUBE_COMMON
default PCI_QSPAN if !4xx && !CPM2 && 8xx
- select ARCH_SUPPORTS_MSI
select GENERIC_PCI_IOMAP
help
Find out whether your system includes a PCI bus. PCI is the name of
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index da183c5..9a6225b 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -429,7 +429,6 @@ menuconfig PCI
bool "PCI support"
default n
depends on 64BIT
- select ARCH_SUPPORTS_MSI
select PCI_MSI
help
Enable PCI support.
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 9ac9f16..822e1a1 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -52,7 +52,6 @@ config SPARC32
config SPARC64
def_bool 64BIT
- select ARCH_SUPPORTS_MSI
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_GRAPH_FP_TEST
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 3aa3766..d2d519c 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -379,7 +379,6 @@ config PCI
select PCI_DOMAINS
select GENERIC_PCI_IOMAP
select TILE_GXIO_TRIO if TILEGX
- select ARCH_SUPPORTS_MSI if TILEGX
select PCI_MSI if TILEGX
---help---
Enable PCI root complex support, so PCIe endpoint devices can
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 685692c..4229ce0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1999,7 +1999,6 @@ menu "Bus options (PCI etc.)"
config PCI
bool "PCI support"
default y
- select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
---help---
Find out whether you have a PCI motherboard. PCI is the name of a
bus system, i.e. the way the CPU talks to the other stuff inside
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index ac45398..3d4c061 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -1,13 +1,9 @@
#
# PCI configuration
#
-config ARCH_SUPPORTS_MSI
- bool
-
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on ARCH_SUPPORTS_MSI
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] of: Specify initrd location using 64-bit
From: Santosh Shilimkar @ 2013-07-01 13:58 UTC (permalink / raw)
Cc: Nicolas Pitre, linux-mips, Aurelien Jacquiot, Catalin Marinas,
Sebastian Andrzej Siewior, Will Deacon, Max Filippov,
Paul Mackerras, Jonas Bonn, Russell King, linux-c6x-dev,
the arch/x86 maintainers, arm@kernel.org, Geert Uytterhoeven,
Grant Likely, Rob Herring, Jean-Christophe PLAGNIOL-VILLARD,
linux-xtensa, James Hogan, devicetree-discuss, Rob Herring,
linux-arm-kernel@lists.infradead.org, Chris Zankel, Vineet Gupta,
Linux Kernel Mailing List, Ralf Baechle,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAMuHMdV6YM3-hASqjxkguEukZjnjK80gBjDNiabxjfQtC=c8ag@mail.gmail.com>
On Monday 01 July 2013 03:59 AM, Geert Uytterhoeven wrote:
> On Mon, Jul 1, 2013 at 9:48 AM, Sebastian Andrzej Siewior
> <bigeasy@linutronix.de> wrote:
>> On 06/29/2013 01:43 AM, Santosh Shilimkar wrote:
>>> Apart from waste of 32bit, what is the other concern you
>>> have ?
>>
>> You pass a u64 as a physical address which is represented in other
>> parts of the kernel (for a good reason) by phys_addr_t.
>>
>>> I really want to converge on this patch because it
>>> has been a open ended discussion for quite some time. Does
>>> that really break any thing on x86 or your concern is more
>>> from semantics of the physical address.
>> You want to have your code in so you can continue with your work, that
>> is okay. The other two arguments why u64 here is a good thing was "due
>> to what I said earlier" and "+1" and I don't have the time to look
>> that up.
>>
>> There should be no problems on x86 if this goes in as it is now.
>>
>> But think about this: What happens if you boot your ARM device without
>> PAE and your initrd is in the upper region? If you are lucky the kernel
>> looks at a different place where it also has a read permission, notices
>> nothing sane is there, writes a message and continues. And if it is not
>> allowed to read? It is clearly the user's fault for booting a non-PAE
>> kernel.
>
> That's actual the original reason: DT has it as 64 bit, and passes it to a
> 32 bit kernel when running in 32 bit mode without PAE.
>
Thanks all for comments and useful discussion. I will resubmit the
patch with update to fix the printk warnings reported by Vineet and
James post the $subject change.
Am assuming the patch will go via Grant Likely's tree.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH 3/3 v18] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Alex Williamson @ 2013-07-01 14:35 UTC (permalink / raw)
To: Varun Sethi
Cc: stuart.yoder, joro, linux-kernel, iommu, scottwood, Timur Tabi,
linuxppc-dev
In-Reply-To: <1372673475-20929-1-git-send-email-Varun.Sethi@freescale.com>
On Mon, 2013-07-01 at 15:41 +0530, Varun Sethi wrote:
> Following is a brief description of the PAMU hardware:
> PAMU determines what action to take and whether to authorize the action on
> the basis of the memory address, a Logical IO Device Number (LIODN), and
> PAACT table (logically) indexed by LIODN and address. Hardware devices which
> need to access memory must provide an LIODN in addition to the memory address.
>
> Peripheral Access Authorization and Control Tables (PAACTs) are the primary
> data structures used by PAMU. A PAACT is a table of peripheral access
> authorization and control entries (PAACE).Each PAACE defines the range of
> I/O bus address space that is accessible by the LIOD and the associated access
> capabilities.
>
> There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT
> (SPAACT).A given physical I/O device may be able to act as one or more
> independent logical I/O devices (LIODs). Each such logical I/O device is
> assigned an identifier called logical I/O device number (LIODN). A LIODN is
> allocated a contiguous portion of the I/O bus address space called the DSA window
> for performing DSA operations. The DSA window may optionally be divided into
> multiple sub-windows, each of which may be used to map to a region in system
> storage space. The first sub-window is referred to as the primary sub-window
> and the remaining are called secondary sub-windows.
>
> This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU
> API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c)
> has been derived from the work done by Ashish Kalra and Timur Tabi.
>
> Signed-off-by: Timur Tabi <timur@tabi.org>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
For iommu group support
Acked-by: Alex Williamson <alex.williamson@redhat.com>
^ permalink raw reply
* RE: [PATCH 3/3 v18] iommu/fsl: Freescale PAMU driver and iommu implementation.
From: Sethi Varun-B16395 @ 2013-07-01 14:36 UTC (permalink / raw)
To: Alex Williamson
Cc: Wood Scott-B07421, Timur Tabi, joro@8bytes.org,
linux-kernel@vger.kernel.org, Yoder Stuart-B08248,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1372689326.30572.788.camel@ul30vt.home>
VGhhbmtzIEFsZXguDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxl
eCBXaWxsaWFtc29uIFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6
IE1vbmRheSwgSnVseSAwMSwgMjAxMyA4OjA1IFBNDQo+IFRvOiBTZXRoaSBWYXJ1bi1CMTYzOTUN
Cj4gQ2M6IGpvcm9AOGJ5dGVzLm9yZzsgaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmc7
IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZzsgbGludXgta2VybmVsQHZnZXIua2Vy
bmVsLm9yZzsNCj4gYmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnOyBnYWxha0BrZXJuZWwuY3Jhc2hp
bmcub3JnOyBZb2RlciBTdHVhcnQtQjA4MjQ4Ow0KPiBXb29kIFNjb3R0LUIwNzQyMTsgVGltdXIg
VGFiaQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDMvMyB2MThdIGlvbW11L2ZzbDogRnJlZXNjYWxl
IFBBTVUgZHJpdmVyIGFuZCBpb21tdQ0KPiBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IE9uIE1vbiwg
MjAxMy0wNy0wMSBhdCAxNTo0MSArMDUzMCwgVmFydW4gU2V0aGkgd3JvdGU6DQo+ID4gRm9sbG93
aW5nIGlzIGEgYnJpZWYgZGVzY3JpcHRpb24gb2YgdGhlIFBBTVUgaGFyZHdhcmU6DQo+ID4gUEFN
VSBkZXRlcm1pbmVzIHdoYXQgYWN0aW9uIHRvIHRha2UgYW5kIHdoZXRoZXIgdG8gYXV0aG9yaXpl
IHRoZQ0KPiA+IGFjdGlvbiBvbiB0aGUgYmFzaXMgb2YgdGhlIG1lbW9yeSBhZGRyZXNzLCBhIExv
Z2ljYWwgSU8gRGV2aWNlIE51bWJlcg0KPiA+IChMSU9ETiksIGFuZCBQQUFDVCB0YWJsZSAobG9n
aWNhbGx5KSBpbmRleGVkIGJ5IExJT0ROIGFuZCBhZGRyZXNzLg0KPiA+IEhhcmR3YXJlIGRldmlj
ZXMgd2hpY2ggbmVlZCB0byBhY2Nlc3MgbWVtb3J5IG11c3QgcHJvdmlkZSBhbiBMSU9ETiBpbg0K
PiBhZGRpdGlvbiB0byB0aGUgbWVtb3J5IGFkZHJlc3MuDQo+ID4NCj4gPiBQZXJpcGhlcmFsIEFj
Y2VzcyBBdXRob3JpemF0aW9uIGFuZCBDb250cm9sIFRhYmxlcyAoUEFBQ1RzKSBhcmUgdGhlDQo+
ID4gcHJpbWFyeSBkYXRhIHN0cnVjdHVyZXMgdXNlZCBieSBQQU1VLiBBIFBBQUNUIGlzIGEgdGFi
bGUgb2YgcGVyaXBoZXJhbA0KPiA+IGFjY2VzcyBhdXRob3JpemF0aW9uIGFuZCBjb250cm9sIGVu
dHJpZXMgKFBBQUNFKS5FYWNoIFBBQUNFIGRlZmluZXMNCj4gPiB0aGUgcmFuZ2Ugb2YgSS9PIGJ1
cyBhZGRyZXNzIHNwYWNlIHRoYXQgaXMgYWNjZXNzaWJsZSBieSB0aGUgTElPRCBhbmQNCj4gPiB0
aGUgYXNzb2NpYXRlZCBhY2Nlc3MgY2FwYWJpbGl0aWVzLg0KPiA+DQo+ID4gVGhlcmUgYXJlIHR3
byB0eXBlcyBvZiBQQUFDVHM6IHByaW1hcnkgUEFBQ1QgKFBQQUFDVCkgYW5kIHNlY29uZGFyeQ0K
PiA+IFBBQUNUIChTUEFBQ1QpLkEgZ2l2ZW4gcGh5c2ljYWwgSS9PIGRldmljZSBtYXkgYmUgYWJs
ZSB0byBhY3QgYXMgb25lDQo+ID4gb3IgbW9yZSBpbmRlcGVuZGVudCBsb2dpY2FsIEkvTyBkZXZp
Y2VzIChMSU9EcykuIEVhY2ggc3VjaCBsb2dpY2FsIEkvTw0KPiA+IGRldmljZSBpcyBhc3NpZ25l
ZCBhbiBpZGVudGlmaWVyIGNhbGxlZCBsb2dpY2FsIEkvTyBkZXZpY2UgbnVtYmVyDQo+ID4gKExJ
T0ROKS4gQSBMSU9ETiBpcyBhbGxvY2F0ZWQgYSBjb250aWd1b3VzIHBvcnRpb24gb2YgdGhlIEkv
TyBidXMNCj4gPiBhZGRyZXNzIHNwYWNlIGNhbGxlZCB0aGUgRFNBIHdpbmRvdyBmb3IgcGVyZm9y
bWluZyBEU0Egb3BlcmF0aW9ucy4gVGhlDQo+ID4gRFNBIHdpbmRvdyBtYXkgb3B0aW9uYWxseSBi
ZSBkaXZpZGVkIGludG8gbXVsdGlwbGUgc3ViLXdpbmRvd3MsIGVhY2gNCj4gPiBvZiB3aGljaCBt
YXkgYmUgdXNlZCB0byBtYXAgdG8gYSByZWdpb24gaW4gc3lzdGVtIHN0b3JhZ2Ugc3BhY2UuIFRo
ZQ0KPiA+IGZpcnN0IHN1Yi13aW5kb3cgaXMgcmVmZXJyZWQgdG8gYXMgdGhlIHByaW1hcnkgc3Vi
LXdpbmRvdyBhbmQgdGhlDQo+IHJlbWFpbmluZyBhcmUgY2FsbGVkIHNlY29uZGFyeSBzdWItd2lu
ZG93cy4NCj4gPg0KPiA+IFRoaXMgcGF0Y2ggcHJvdmlkZXMgdGhlIFBBTVUgZHJpdmVyIChmc2xf
cGFtdS5jKSBhbmQgdGhlIGNvcnJlc3BvbmRpbmcNCj4gPiBJT01NVSBBUEkgaW1wbGVtZW50YXRp
b24gKGZzbF9wYW11X2RvbWFpbi5jKS4gVGhlIFBBTVUgaGFyZHdhcmUgZHJpdmVyDQo+ID4gKGZz
bF9wYW11LmMpIGhhcyBiZWVuIGRlcml2ZWQgZnJvbSB0aGUgd29yayBkb25lIGJ5IEFzaGlzaCBL
YWxyYSBhbmQNCj4gVGltdXIgVGFiaS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFRpbXVyIFRh
YmkgPHRpbXVyQHRhYmkub3JnPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFZhcnVuIFNldGhpIDxWYXJ1
bi5TZXRoaUBmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiANCj4gRm9yIGlvbW11IGdyb3VwIHN1
cHBvcnQNCj4gDQo+IEFja2VkLWJ5OiBBbGV4IFdpbGxpYW1zb24gPGFsZXgud2lsbGlhbXNvbkBy
ZWRoYXQuY29tPg0KPiANCg0K
^ permalink raw reply
* [PATCH 1/2] powerpc/booke64: Use common defines for AltiVec interrupts numbers
From: Mihai Caraman @ 2013-07-01 15:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mihai Caraman, kvm, kvm-ppc
On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
common defines to indentify these numbers.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kernel/exceptions-64e.S | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 645170a..0c379e9 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -399,7 +399,7 @@ interrupt_end_book3e:
/* Altivec Unavailable Interrupt */
START_EXCEPTION(altivec_unavailable);
- NORMAL_EXCEPTION_PROLOG(0x200, BOOKE_INTERRUPT_ALTIVEC_UNAVAIL,
+ NORMAL_EXCEPTION_PROLOG(0x200, BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL,
PROLOG_ADDITION_NONE)
/* we can probably do a shorter exception entry for that one... */
EXCEPTION_COMMON(0x200, PACA_EXGEN, INTS_KEEP)
@@ -421,7 +421,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
/* AltiVec Assist */
START_EXCEPTION(altivec_assist);
- NORMAL_EXCEPTION_PROLOG(0x220, BOOKE_INTERRUPT_ALTIVEC_ASSIST,
+ NORMAL_EXCEPTION_PROLOG(0x220,
+ BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST,
PROLOG_ADDITION_NONE)
EXCEPTION_COMMON(0x220, PACA_EXGEN, INTS_DISABLE)
bl .save_nvgprs
--
1.7.3.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/fsl-booke: Use common defines for SPE/FP interrupts numbers
From: Mihai Caraman @ 2013-07-01 15:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mihai Caraman, kvm, kvm-ppc
In-Reply-To: <1372692931-16324-1-git-send-email-mihai.caraman@freescale.com>
On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
common defines to indentify these numbers.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
---
arch/powerpc/kernel/head_fsl_booke.S | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index d10a7ca..f1dd4a9 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -555,28 +555,28 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
#ifdef CONFIG_SPE
/* SPE Unavailable */
START_EXCEPTION(SPEUnavailable)
- NORMAL_EXCEPTION_PROLOG(SPE_UNAVAIL)
+ NORMAL_EXCEPTION_PROLOG(SPE_ALTIVEC_UNAVAIL)
beq 1f
bl load_up_spe
b fast_exception_return
1: addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE_LITE(0x2010, KernelSPE)
#else
- EXCEPTION(0x2020, SPE_UNAVAIL, SPEUnavailable, \
+ EXCEPTION(0x2020, SPE_ALTIVEC_UNAVAIL, SPEUnavailable, \
unknown_exception, EXC_XFER_EE)
#endif /* CONFIG_SPE */
/* SPE Floating Point Data */
#ifdef CONFIG_SPE
- EXCEPTION(0x2030, SPE_FP_DATA, SPEFloatingPointData, \
- SPEFloatingPointException, EXC_XFER_EE);
+ EXCEPTION(0x2030, SPE_FP_DATA_ALTIVEC_ASSIST, SPEFloatingPointData,
+ SPEFloatingPointException, EXC_XFER_EE)
/* SPE Floating Point Round */
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
SPEFloatingPointRoundException, EXC_XFER_EE)
#else
- EXCEPTION(0x2040, SPE_FP_DATA, SPEFloatingPointData, \
- unknown_exception, EXC_XFER_EE)
+ EXCEPTION(0x2040, SPE_FP_DATA_ALTIVEC_ASSIST, SPEFloatingPointData,
+ unknown_exception, EXC_XFER_EE)
EXCEPTION(0x2050, SPE_FP_ROUND, SPEFloatingPointRound, \
unknown_exception, EXC_XFER_EE)
#endif /* CONFIG_SPE */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
From: Scott Wood @ 2013-07-01 16:55 UTC (permalink / raw)
To: Wang Dongsheng-B40534; +Cc: linuxppc-dev@lists.ozlabs.org, Wood Scott-B07421
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259F916BF@039-SN2MPN1-022.039d.mgd.msft.net>
On 06/30/2013 09:38:15 PM, Wang Dongsheng-B40534 wrote:
> Hi Benjamin & Kumar & scott,
>=20
> I am not sure who can apply these patches...
>=20
> Scott already ACK these patches.
>=20
> A few days ago Scott have a pull request, Scott can accept them? Or ?
>=20
> [v3,1/4] powerpc/mpic: add irq_set_wake support
> http://patchwork.ozlabs.org/patch/234934/
>=20
> [v3,2/4] powerpc/mpic: add global timer support
> http://patchwork.ozlabs.org/patch/234935/
>=20
> [v3,3/4] powerpc/mpic: create mpic subsystem object
> http://patchwork.ozlabs.org/patch/234936
>=20
> [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> http://patchwork.ozlabs.org/patch/234937/
I've been picking patches and hope to send a pull request soon. I =20
already have these patches queued up as part of it.
-Scott=
^ permalink raw reply
* [PATCH v2] of: Specify initrd location using 64-bit
From: Santosh Shilimkar @ 2013-07-01 18:20 UTC (permalink / raw)
To: grant.likely
Cc: Nicolas Pitre, linux-mips, Aurelien Jacquiot, Catalin Marinas,
Sebastian Andrzej Siewior, Will Deacon, Max Filippov,
Paul Mackerras, Jonas Bonn, Russell King, linux-c6x-dev, x86, arm,
Geert Uytterhoeven, Mark Salter, robherring2,
Jean-Christophe PLAGNIOL-VILLARD, linux-xtensa, James Hogan,
devicetree-discuss, Rob Herring, linux-arm-kernel, Chris Zankel,
Michal Simek, Vineet Gupta, Ralf Baechle, Santosh Shilimkar,
linuxppc-dev
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.
There has been quite a bit of debate about whether to use u64 or phys_addr_t.
It was concluded to stick to u64 to be consistent with rest of the device
tree code. As summarized by Geert, "The address to load the initrd is decided
by the bootloader/user and set at that point later in time. The dtb should not
be tied to the kernel you are booting"
More details on the discussion can be found here:
https://lkml.org/lkml/2013/6/20/690
https://lkml.org/lkml/2012/9/13/544
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: x86@kernel.org
Cc: arm@kernel.org
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: bigeasy@linutronix.de
Cc: robherring2@gmail.com
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-xtensa@linux-xtensa.org
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arc/mm/init.c | 5 ++---
arch/arm/mm/init.c | 2 +-
arch/arm64/mm/init.c | 3 +--
arch/c6x/kernel/devicetree.c | 3 +--
arch/metag/mm/init.c | 5 ++---
arch/microblaze/kernel/prom.c | 3 +--
arch/mips/kernel/prom.c | 3 +--
arch/openrisc/kernel/prom.c | 3 +--
arch/powerpc/kernel/prom.c | 3 +--
arch/x86/kernel/devicetree.c | 3 +--
arch/xtensa/kernel/setup.c | 3 +--
drivers/of/fdt.c | 10 ++++++----
include/linux/of_fdt.h | 3 +--
13 files changed, 20 insertions(+), 29 deletions(-)
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index 4a17736..7991e08 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
#endif
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
- pr_err("%s(%lx, %lx)\n", __func__, start, end);
+ pr_err("%s(%llx, %llx)\n", __func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 9a5cdc0..afeaef7 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
__tagtable(ATAG_INITRD2, parse_tag_initrd2);
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f497ca7..7047708 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
phys_addr_t memstart_addr __read_mostly = 0;
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
phys_initrd_start = start;
phys_initrd_size = end - start;
diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
index bdb56f0..287d0e6 100644
--- a/arch/c6x/kernel/devicetree.c
+++ b/arch/c6x/kernel/devicetree.c
@@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
index d05b845..bdc4811 100644
--- a/arch/metag/mm/init.c
+++ b/arch/metag/mm/init.c
@@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long end)
#endif
#ifdef CONFIG_OF_FLATTREE
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
- pr_err("%s(%lx, %lx)\n",
+ pr_err("%s(%llx, %llx)\n",
__func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */
diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
index 0a2c68f..62e2e8f 100644
--- a/arch/microblaze/kernel/prom.c
+++ b/arch/microblaze/kernel/prom.c
@@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 5712bb5..32b8788 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -58,8 +58,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
index 5869e3f..150215a 100644
--- a/arch/openrisc/kernel/prom.c
+++ b/arch/openrisc/kernel/prom.c
@@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 8b6f7a9..2f3e252 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -550,8 +550,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index b158152..2fbad6b 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
}
#ifdef CONFIG_BLK_DEV_INITRD
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
index 6dd25ec..d45e602 100644
--- a/arch/xtensa/kernel/setup.c
+++ b/arch/xtensa/kernel/setup.c
@@ -170,8 +170,7 @@ static int __init parse_tag_fdt(const bp_tag_t *tag)
__tagtable(BP_TAG_FDT, parse_tag_fdt);
-void __init early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end)
+void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
initrd_start = (void *)__va(start);
initrd_end = (void *)__va(end);
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 808be06..21123b8 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -550,7 +550,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
*/
void __init early_init_dt_check_for_initrd(unsigned long node)
{
- unsigned long start, end, len;
+ u64 start, end;
+ unsigned long len;
__be32 *prop;
pr_debug("Looking for initrd properties... ");
@@ -558,15 +559,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
if (!prop)
return;
- start = of_read_ulong(prop, len/4);
+ start = of_read_number(prop, len/4);
prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
if (!prop)
return;
- end = of_read_ulong(prop, len/4);
+ end = of_read_number(prop, len/4);
early_init_dt_setup_initrd_arch(start, end);
- pr_debug("initrd_start=0x%lx initrd_end=0x%lx\n", start, end);
+ pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n",
+ (unsigned long long)start, (unsigned long long)end);
}
#else
inline void early_init_dt_check_for_initrd(unsigned long node)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..4a17939 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
* physical addresses.
*/
#ifdef CONFIG_BLK_DEV_INITRD
-extern void early_init_dt_setup_initrd_arch(unsigned long start,
- unsigned long end);
+extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
#endif
/* Early flat tree scan hooks */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] of: Specify initrd location using 64-bit
From: Rob Herring @ 2013-07-01 21:34 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Nicolas Pitre, linux-mips, Aurelien Jacquiot, Catalin Marinas,
Sebastian Andrzej Siewior, Will Deacon, Max Filippov,
Paul Mackerras, Jonas Bonn, Russell King, linux-c6x-dev, x86, arm,
Geert Uytterhoeven, Mark Salter, grant.likely,
Jean-Christophe PLAGNIOL-VILLARD, linux-xtensa, James Hogan,
devicetree-discuss, Rob Herring, linux-arm-kernel, Chris Zankel,
Michal Simek, Vineet Gupta, Ralf Baechle, linuxppc-dev
In-Reply-To: <1372702835-5333-1-git-send-email-santosh.shilimkar@ti.com>
On 07/01/2013 01:20 PM, Santosh Shilimkar wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
>
> There has been quite a bit of debate about whether to use u64 or phys_addr_t.
> It was concluded to stick to u64 to be consistent with rest of the device
> tree code. As summarized by Geert, "The address to load the initrd is decided
> by the bootloader/user and set at that point later in time. The dtb should not
> be tied to the kernel you are booting"
That was quoting me. Otherwise:
Acked-by: Rob Herring <rob.herring@calxeda.com>
Unless Grant feels compelled to pick this up for 3.11, I think it has to
wait for 3.12.
Rob
>
> More details on the discussion can be found here:
> https://lkml.org/lkml/2013/6/20/690
> https://lkml.org/lkml/2012/9/13/544
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Vineet Gupta <vgupta@synopsys.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Salter <msalter@redhat.com>
> Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
> Cc: James Hogan <james.hogan@imgtec.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Jonas Bonn <jonas@southpole.se>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: x86@kernel.org
> Cc: arm@kernel.org
> Cc: Chris Zankel <chris@zankel.net>
> Cc: Max Filippov <jcmvbkbc@gmail.com>
> Cc: bigeasy@linutronix.de
> Cc: robherring2@gmail.com
> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-c6x-dev@linux-c6x.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-xtensa@linux-xtensa.org
> Cc: devicetree-discuss@lists.ozlabs.org
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arc/mm/init.c | 5 ++---
> arch/arm/mm/init.c | 2 +-
> arch/arm64/mm/init.c | 3 +--
> arch/c6x/kernel/devicetree.c | 3 +--
> arch/metag/mm/init.c | 5 ++---
> arch/microblaze/kernel/prom.c | 3 +--
> arch/mips/kernel/prom.c | 3 +--
> arch/openrisc/kernel/prom.c | 3 +--
> arch/powerpc/kernel/prom.c | 3 +--
> arch/x86/kernel/devicetree.c | 3 +--
> arch/xtensa/kernel/setup.c | 3 +--
> drivers/of/fdt.c | 10 ++++++----
> include/linux/of_fdt.h | 3 +--
> 13 files changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index 4a17736..7991e08 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -157,9 +157,8 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
> #endif
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> - pr_err("%s(%lx, %lx)\n", __func__, start, end);
> + pr_err("%s(%llx, %llx)\n", __func__, start, end);
> }
> #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 9a5cdc0..afeaef7 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index f497ca7..7047708 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -44,8 +44,7 @@ static unsigned long phys_initrd_size __initdata = 0;
>
> phys_addr_t memstart_addr __read_mostly = 0;
>
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/metag/mm/init.c b/arch/metag/mm/init.c
> index d05b845..bdc4811 100644
> --- a/arch/metag/mm/init.c
> +++ b/arch/metag/mm/init.c
> @@ -419,10 +419,9 @@ void free_initrd_mem(unsigned long start, unsigned long end)
> #endif
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> - pr_err("%s(%lx, %lx)\n",
> + pr_err("%s(%llx, %llx)\n",
> __func__, start, end);
> }
> #endif /* CONFIG_OF_FLATTREE */
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 0a2c68f..62e2e8f 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
> index 5712bb5..32b8788 100644
> --- a/arch/mips/kernel/prom.c
> +++ b/arch/mips/kernel/prom.c
> @@ -58,8 +58,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
> index 5869e3f..150215a 100644
> --- a/arch/openrisc/kernel/prom.c
> +++ b/arch/openrisc/kernel/prom.c
> @@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 8b6f7a9..2f3e252 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -550,8 +550,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index b158152..2fbad6b 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/xtensa/kernel/setup.c b/arch/xtensa/kernel/setup.c
> index 6dd25ec..d45e602 100644
> --- a/arch/xtensa/kernel/setup.c
> +++ b/arch/xtensa/kernel/setup.c
> @@ -170,8 +170,7 @@ static int __init parse_tag_fdt(const bp_tag_t *tag)
>
> __tagtable(BP_TAG_FDT, parse_tag_fdt);
>
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (void *)__va(start);
> initrd_end = (void *)__va(end);
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 808be06..21123b8 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -550,7 +550,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
> */
> void __init early_init_dt_check_for_initrd(unsigned long node)
> {
> - unsigned long start, end, len;
> + u64 start, end;
> + unsigned long len;
> __be32 *prop;
>
> pr_debug("Looking for initrd properties... ");
> @@ -558,15 +559,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
> prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
> if (!prop)
> return;
> - start = of_read_ulong(prop, len/4);
> + start = of_read_number(prop, len/4);
>
> prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
> if (!prop)
> return;
> - end = of_read_ulong(prop, len/4);
> + end = of_read_number(prop, len/4);
>
> early_init_dt_setup_initrd_arch(start, end);
> - pr_debug("initrd_start=0x%lx initrd_end=0x%lx\n", start, end);
> + pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n",
> + (unsigned long long)start, (unsigned long long)end);
> }
> #else
> inline void early_init_dt_check_for_initrd(unsigned long node)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index ed136ad..4a17939 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
> * physical addresses.
> */
> #ifdef CONFIG_BLK_DEV_INITRD
> -extern void early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end);
> +extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
> #endif
>
> /* Early flat tree scan hooks */
>
^ permalink raw reply
* [PATCH] powerpc: Handle both new style and old style reserve maps
From: Benjamin Herrenschmidt @ 2013-07-01 22:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy Kerr, anton
When Jeremy introduced the new device-tree based reserve map, he made
the code in early_reserve_mem_dt() bail out if it found one, thus not
reserving the initrd nor processing the old style map.
I hit problems with variants of kexec that didn't put the initrd in
the new style map either. While these could/will be fixed, I believe
we should be safe here and rather reserve more than not enough.
We could have a firmware passing stuff via the new style map, and
in the middle, a kexec that knows nothing about it and adding other
things to the old style map.
I don't see a big issue with processing both and reserving everything
that needs to be. memblock_reserve() supports overlaps fine these days.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 9c753bc..eb23ac9 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -559,7 +559,7 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
}
#endif
-static bool __init early_reserve_mem_dt(void)
+static void __init early_reserve_mem_dt(void)
{
unsigned long i, len, dt_root;
const __be32 *prop;
@@ -569,7 +569,9 @@ static bool __init early_reserve_mem_dt(void)
prop = of_get_flat_dt_prop(dt_root, "reserved-ranges", &len);
if (!prop)
- return false;
+ return;
+
+ DBG("Found new-style reserved-ranges\n");
/* Each reserved range is an (address,size) pair, 2 cells each,
* totalling 4 cells per range. */
@@ -579,11 +581,11 @@ static bool __init early_reserve_mem_dt(void)
base = of_read_number(prop + (i * 4) + 0, 2);
size = of_read_number(prop + (i * 4) + 2, 2);
- if (size)
+ if (size) {
+ DBG("reserving: %llx -> %llx\n", base, size);
memblock_reserve(base, size);
+ }
}
-
- return true;
}
static void __init early_reserve_mem(void)
@@ -601,20 +603,16 @@ static void __init early_reserve_mem(void)
self_size = initial_boot_params->totalsize;
memblock_reserve(self_base, self_size);
- /*
- * Try looking for reserved-regions property in the DT first; if
- * it's present, it'll contain all of the necessary reservation
- * info
- */
- if (early_reserve_mem_dt())
- return;
+ /* Look for the new "reserved-regions" property in the DT */
+ early_reserve_mem_dt();
#ifdef CONFIG_BLK_DEV_INITRD
- /* then reserve the initrd, if any */
- if (initrd_start && (initrd_end > initrd_start))
+ /* Then reserve the initrd, if any */
+ if (initrd_start && (initrd_end > initrd_start)) {
memblock_reserve(_ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE),
_ALIGN_UP(initrd_end, PAGE_SIZE) -
_ALIGN_DOWN(initrd_start, PAGE_SIZE));
+ }
#endif /* CONFIG_BLK_DEV_INITRD */
#ifdef CONFIG_PPC32
@@ -626,6 +624,8 @@ static void __init early_reserve_mem(void)
u32 base_32, size_32;
u32 *reserve_map_32 = (u32 *)reserve_map;
+ DBG("Found old 32-bit reserve map\n");
+
while (1) {
base_32 = *(reserve_map_32++);
size_32 = *(reserve_map_32++);
@@ -640,6 +640,9 @@ static void __init early_reserve_mem(void)
return;
}
#endif
+ DBG("Processing reserve map\n");
+
+ /* Handle the reserve map in the fdt blob if it exists */
while (1) {
base = *(reserve_map++);
size = *(reserve_map++);
^ permalink raw reply related
* Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
From: Benjamin Herrenschmidt @ 2013-07-01 22:16 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, Wang Dongsheng-B40534,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1372697716.8183.81@snotra>
On Mon, 2013-07-01 at 11:55 -0500, Scott Wood wrote:
> I've been picking patches and hope to send a pull request soon. I
> already have these patches queued up as part of it.
Hurry !
Next time, I'd like the bulk of your stuff around -rc2 or 3 if possible,
ie, keep feeding me rather than one big pull in the merge window.
Thanks !
Cheers,
Ben.
^ permalink raw reply
* Please pull 'next' branch of 5xxx tree
From: Anatolij Gustschin @ 2013-07-01 22:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben !
Please pull mpc5xxx patches for v3.11. There are small cleanups
and fixes for mpc512x common code, mpc512x_defconfig updates and
soft reboot support for mpc5125 based boards.
Thanks,
Anatolij
The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:
Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git next
for you to fetch changes up to dd0120dea601de654a5a6d959da3a632a02200f0:
powerpc/mpc512x: enable USB support in defconfig (2013-06-25 08:51:19 +0200)
----------------------------------------------------------------
Anatolij Gustschin (1):
powerpc/mpc512x: enable USB support in defconfig
Gerhard Sittig (3):
powerpc/mpc512x: move common code to shared.c file
powerpc/mpc512x: initialize board restart earlier
powerpc/mpc512x: commit re-generated defconfig
Matteo Facchinetti (1):
powerpc/mpc512x: add MPC5125 reset module support for system restart
arch/powerpc/configs/mpc512x_defconfig | 27 ++++++++-------------
arch/powerpc/include/asm/mpc5121.h | 1 -
arch/powerpc/platforms/512x/mpc5121_ads.c | 6 ++---
arch/powerpc/platforms/512x/mpc512x.h | 12 +++-------
arch/powerpc/platforms/512x/mpc512x_generic.c | 4 ++--
arch/powerpc/platforms/512x/mpc512x_shared.c | 31 ++++++++++++++++++++++---
arch/powerpc/platforms/512x/pdm360ng.c | 4 ++--
7 files changed, 47 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
From: Scott Wood @ 2013-07-01 22:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Wood Scott-B07421, Wang Dongsheng-B40534,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1372717011.18612.160.camel@pasglop>
On 07/01/2013 05:16:51 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-07-01 at 11:55 -0500, Scott Wood wrote:
> > I've been picking patches and hope to send a pull request soon. I
> > already have these patches queued up as part of it.
>=20
> Hurry !
>=20
> Next time, I'd like the bulk of your stuff around -rc2 or 3 if =20
> possible,
> ie, keep feeding me rather than one big pull in the merge window.
>=20
> Thanks !
I'll send it tonight after I verify no obvious breakage.
I realize it's late, but I wasn't involved until a few weeks ago, and =20
there was a large backlog (of which I've only been able to get through =20
a portion so far). Most of what I have gone through was done in the =20
past week -- I wasn't just holding on to it.
-Scott=
^ permalink raw reply
* Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
From: Benjamin Herrenschmidt @ 2013-07-01 22:59 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, Wang Dongsheng-B40534,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1372718200.8183.96@snotra>
On Mon, 2013-07-01 at 17:36 -0500, Scott Wood wrote:
> I'll send it tonight after I verify no obvious breakage.
>
> I realize it's late, but I wasn't involved until a few weeks ago, and
> there was a large backlog (of which I've only been able to get through
> a portion so far). Most of what I have gone through was done in the
> past week -- I wasn't just holding on to it.
Sure, I know :-) Just saying for next time ... I prefer a regular trickle
to a big batch too late.
Cheers,
Ben.
^ permalink raw reply
* Pull request: scottwood/linux.git next
From: Scott Wood @ 2013-07-01 23:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Note to contributors: This is only a fraction of the outstanding patches
for FSL PPC. I haven't been able to process the entire backlog since
starting to help Kumar with this a few weeks ago. If your patch is still
"action required" in patchwork, I haven't forgotten it -- but it will not
make it into this merge window.
The following changes since commit 1a5272866f87d7fbf04dc8060f8da3e8456490ab:
powerpc: Optimize hugepage invalidate (2013-06-21 16:01:58 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
for you to fetch changes up to a63b3bc7db32b63bfe5f48fa8582f931db81c86e:
powerpc/fsl: add MPIC timer wakeup support (2013-07-01 18:38:42 -0500)
----------------------------------------------------------------
Chunhe Lan (1):
powerpc/fsl: Enable CONFIG_E1000E in mpc85xx_smp_defconfig
Dongsheng.wang@freescale.com (4):
powerpc/mpic: add irq_set_wake support
powerpc/mpic: add global timer support
powerpc/mpic: create mpic subsystem object
powerpc/fsl: add MPIC timer wakeup support
Hongtao Jia (1):
powerpc/mpic: Add get_version API both for internal and external use
Joe Liccese (1):
powerpc: Add T4 LAC device tree binding & defs
Kevin Hao (1):
powerpc/85xx: enable coreint for all the 64bit boards
LEROY Christophe (1):
powerpc/8xx: Erroneous double irq_eoi() on CPM IRQ in MPC8xx
Sachin Surendran (1):
i2c-cpm: Fix to takeback i2c bus master-ship after a collision
Tudor Laurentiu (1):
powerpc/watchdog: Don't enable interrupt on PPC64 BookE
Wei Yongjun (1):
powerpc/83xx: use module_i2c_driver to simplify the code
.../bindings/powerpc/fsl/interlaken-lac.txt | 309 +++++++++++
.../boot/dts/fsl/interlaken-lac-portals.dtsi | 156 ++++++
arch/powerpc/boot/dts/fsl/interlaken-lac.dtsi | 45 ++
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/include/asm/mpic.h | 5 +
arch/powerpc/include/asm/mpic_timer.h | 46 ++
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 12 +-
arch/powerpc/platforms/85xx/p5020_ds.c | 5 -
arch/powerpc/platforms/85xx/p5040_ds.c | 5 -
arch/powerpc/platforms/85xx/t4240_qds.c | 5 -
arch/powerpc/platforms/8xx/m8xx_setup.c | 13 +-
arch/powerpc/platforms/Kconfig | 21 +
arch/powerpc/sysdev/Makefile | 2 +
arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 161 ++++++
arch/powerpc/sysdev/mpic.c | 58 +-
arch/powerpc/sysdev/mpic_timer.c | 593 +++++++++++++++++++++
drivers/i2c/busses/i2c-cpm.c | 8 +
drivers/watchdog/booke_wdt.c | 8 +
18 files changed, 1410 insertions(+), 43 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt
create mode 100644 arch/powerpc/boot/dts/fsl/interlaken-lac-portals.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/interlaken-lac.dtsi
create mode 100644 arch/powerpc/include/asm/mpic_timer.h
create mode 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
create mode 100644 arch/powerpc/sysdev/mpic_timer.c
^ permalink raw reply
* Re: [PATCH V6] powerpc/MPIC: Add get_version API both for internal and external use
From: Scott Wood @ 2013-07-01 23:58 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev, b38951
In-Reply-To: <1372656366-769-1-git-send-email-hongtao.jia@freescale.com>
On 07/01/2013 12:26:06 AM, Jia Hongtao wrote:
> From: Hongtao Jia <hongtao.jia@freescale.com>
>=20
> MPIC version is useful information for both mpic_alloc() and =20
> mpic_init().
> The patch provide an API to get MPIC version for reusing the code.
> Also, some other IP block may need MPIC version for their own use.
> The API for external use is also provided.
>=20
> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> V6:
> * Fix compile error on mpc83xx.
I already applied V5 before realizing that it was this patch that you =20
updated, rather than the MSI patch that depends on it. There is no =20
compile error until the MSI patch that starts using this (which I =20
haven't yet applied, due to the error). Could you send a followup =20
patch that just adds the stub?
> +/* Get the version of primary MPIC */
> +#ifdef CONFIG_MPIC
> +extern u32 fsl_mpic_primary_get_version(void);
> +#else
> +static inline u32 fsl_mpic_primary_get_version(void)
> +{
> + return -ENOTSUPP;
> +}
> +#endif
[snip]
> +static u32 fsl_mpic_get_version(struct mpic *mpic)
> +{
> + u32 brr1;
> +
> + if (!(mpic->flags & MPIC_FSL))
> + return 0;
In one case, calling this without having an FSL MPIC returns -ENOTSUPP, =20
and in another case it returns 0... Shouldn't it be consistent?
Also returning a negative number as a u32 is not very nice.
-Scott=
^ permalink raw reply
* Re: [PATCH] DTS: Add compatible list for eSDHC
From: Scott Wood @ 2013-07-02 0:04 UTC (permalink / raw)
To: Haijun Zhang; +Cc: Fleming Andrew-AFLEMING, linuxppc-dev, Haijun Zhang
In-Reply-To: <1372656110-13876-1-git-send-email-Haijun.Zhang@freescale.com>
On 07/01/2013 12:21:50 AM, Haijun Zhang wrote:
> Add compatible of esdhc for below board:
> p2041 p3041 p4080 p5020 p5040
>=20
> Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com>
> CC: Scott Wood <scottwood@freescale.com>
> CC: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 1 +
> 5 files changed, 5 insertions(+)
Is there something specific that depends on this, or are you just =20
trying to conform to other examples?
I don't think we need the SoC name here, given that eSDHC has a version =20
register that you can read (and an SVR in the unlikely case that that =20
isn't adequate). If you did end up relying on this device tree change, =20
you'd be broken if an older device trees is used.
-Scott=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/booke64: Use common defines for AltiVec interrupts numbers
From: Alexander Graf @ 2013-07-02 0:18 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1372692931-16324-1-git-send-email-mihai.caraman@freescale.com>
On 01.07.2013, at 17:35, Mihai Caraman wrote:
> On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
> common defines to indentify these numbers.
So why didn't this happen from the beginning? Why the change?
Alex
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/exceptions-64e.S =
b/arch/powerpc/kernel/exceptions-64e.S
> index 645170a..0c379e9 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -399,7 +399,7 @@ interrupt_end_book3e:
>=20
> /* Altivec Unavailable Interrupt */
> START_EXCEPTION(altivec_unavailable);
> - NORMAL_EXCEPTION_PROLOG(0x200, BOOKE_INTERRUPT_ALTIVEC_UNAVAIL,
> + NORMAL_EXCEPTION_PROLOG(0x200, =
BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL,
> PROLOG_ADDITION_NONE)
> /* we can probably do a shorter exception entry for that one... =
*/
> EXCEPTION_COMMON(0x200, PACA_EXGEN, INTS_KEEP)
> @@ -421,7 +421,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
>=20
> /* AltiVec Assist */
> START_EXCEPTION(altivec_assist);
> - NORMAL_EXCEPTION_PROLOG(0x220, BOOKE_INTERRUPT_ALTIVEC_ASSIST,
> + NORMAL_EXCEPTION_PROLOG(0x220,
> + =
BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST,
> PROLOG_ADDITION_NONE)
> EXCEPTION_COMMON(0x220, PACA_EXGEN, INTS_DISABLE)
> bl .save_nvgprs
> --=20
> 1.7.3.4
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: enable the relocatable support for the fsl booke 32bit kernel
From: Scott Wood @ 2013-07-02 0:30 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130630073310.GA32268@pek-khao-d1.corp.ad.wrs.com>
On 06/30/2013 02:33:10 AM, Kevin Hao wrote:
> On Thu, Jun 27, 2013 at 08:47:27PM -0500, Scott Wood wrote:
> > On 06/27/2013 08:36:37 PM, Kevin Hao wrote:
> > >On Thu, Jun 27, 2013 at 02:58:34PM -0500, Scott Wood wrote:
> > >> On 06/26/2013 09:00:33 PM, Kevin Hao wrote:
> > >> >This is based on the codes in the head_44x.S. Since we always
> > >align to
> > >> >256M before mapping the PAGE_OFFSET for a relocatable kernel,
> > >we also
> > >> >change the init tlb map to 256M size.
> > >>
> > >> Why 256M?
> > >
> > >For two reasons:
> > > 1. This is the size which both e500v1 and e500v2 support.
> > > 2. Since we always use the PAGE_OFFSET as 0xc0000000, the 256M is
> > > max alignment value we can use for this virtual address.
> >
> > Is there any reason why 64M won't continue to work here?
>=20
> Yes. In general we would map the 0 ~ 256M memory region in the first
> tlb1 entry. If we align to 64M, the relocatable kernel would not work
> if loaded above 64M memory. For example, if we load a relocatable =20
> kernel
> at 64M memory, we will relocate it as:
> __pa(PAGE_OFFSET) =3D 0x4000000
>=20
> But in map_mem_in_cams function, it will create a memory map as:
> __pa(PAGE_OFFSET) =3D 0x0
>=20
> The kernel will definitely not work in this case.
That's a problem with map_mem_in_cams(), as discussed in the thread on =20
other patch. Perhaps fully solving those problems is not worthwhile at =20
this time, but we should at least be able to determine the TLB size =20
automatically based on the alignment of the address you're trying to =20
map. 64M would be used unless (address & (256M - 1)) >=3D 64M. I hope =20
we can continue to assume the kernel won't cross a 64M boundary.
> > >> This tightens the alignment requirement for dynamic memstart.
> > >
> > >Yes. But since RELOCATABLE is a superset of DYNAMIC_MEMSTART, we
> > >can always
> > >use RELOCATABLE instead of DYNAMIC_MEMSTART for fsl booke board in
> > >any cases.
> >
> > The extra flexibility of RELOCATABLE may help some use cases, but
> > you'd still require the entire 256M naturally aligned region
> > containing the kernel to be present and owned by this instance of
> > Linux.
> >
> > >So DYNAMIC_MEMSTART will seem not so useful after we enable this
> > >feature.
> >
> > Then why doesn't this patch remove it?
>=20
> According to the Kconfig it is still used by 44x.
RELOCATABLE appears to be supported on 44x, and is what CRASH_DUMP uses =20
on 44x.
> And maybe someone still want to use this relocation method.
Then you don't get to dismiss claims that you're changing =20
DYNAMIC_MEMSTART alignment requirements by saying that RELOCATABLE is a =20
strict superset. :-) Given the requirement that the kernel be in the =20
first TLB entry, though, using RELOCATABLE rather than DYNAMIC_MEMSTART =20
doesn't fix the alignment problem.
I don't think it makes sense to keep both mechanisms around unless =20
there's some obvious reason to prefer DYNAMIC_MEMSTART.
> > >> And
> > >> what about boards with less than 256 MiB of RAM?
> > >
> > >It should be fine. We just create the map in the tlb. The MM still =20
> use
> > >the real size of memory.
> >
> > No, you must not map anything that is not present with a mapping
> > that is executable and/or not guarded, or you could get speculative
> > accesses to who-knows-what.
>=20
> Yes, there may be speculative access in this case.
>=20
> > Even if RAM is present there but owned
> > by some other entity, you could be creating illegal aliases if that
> > other entity mapped it cache-inhibited or similar.
>=20
> Fair enough. So it seems error prone if we map this 256M memory region
> blindly. But if we don't do this, it seems that we have to do twice =20
> relocation.
> The first time we just align to a predefined value (64M for example), =20
> and
> then parse the device tree and get the real memstart_addr. After that =20
> we
> should relocate the kernel to the real start address. It seems a =20
> little
> complicated. Do you have any better ideas?
This seems like the proper way to address it, assuming we're unwilling =20
to map the kernel image somewhere other than the normal lowmem mapping =20
(and I think we're unwilling, given how tight the address space is on =20
32-bit, and the intrusiveness of the change). The dynamic =20
determination of 64M versus 256M could be an acceptable alternative =20
though, if we're OK with not supporting arbitrary relocatable =20
scenarios, but just those that are either needed by kdump, or supported =20
by current kernels (with DYNAMIC_MEMSTART, or just starting at zero =20
with less than 256M of RAM). If we go that route, the limitations =20
should be documented.
-Scott=
^ permalink raw reply
* Re: [PATCHv4 02/11] pci: use weak functions for MSI arch-specific functions
From: Michael Ellerman @ 2013-07-02 0:53 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, Andrew Lunn, linux-ia64, linux-mips, linux-pci,
Heiko Carstens, Bjorn Helgaas, Thierry Reding, Paul Mackerras,
H. Peter Anvin, sparclinux, linux-s390, Russell King, x86,
Ingo Molnar, Ezequiel Garcia, Fenghua Yu, Jason Cooper,
Rob Herring, Chris Metcalf, Gregory Clement, Thomas Gleixner,
linux-arm-kernel, Tony Luck, Ralf Baechle, Maen Suleiman,
Martin Schwidefsky, linux390, linuxppc-dev, David S. Miller
In-Reply-To: <1372686136-1370-3-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, 2013-07-01 at 15:42 +0200, Thomas Petazzoni wrote:
> Until now, the MSI architecture-specific functions could be overloaded
> using a fairly complex set of #define and compile-time
> conditionals. In order to prepare for the introduction of the msi_chip
> infrastructure, it is desirable to switch all those functions to use
> the 'weak' mechanism. This commit converts all the architectures that
> were overidding those MSI functions to use the new strategy.
The MSI code used to use weak functions, until we discovered they were
being miscompiled on some toolchains (11df1f0). I assume these days
we're confident they work correctly.
cheers
^ permalink raw reply
* linux-next: build failure after merge of the powerpc tree
From: Stephen Rothwell @ 2013-07-02 0:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, linux-kernel, Aruna Balakrishnaiah
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
Hi all,
After merging the powerpc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/pstore/ftrace.c: In function 'pstore_ftrace_call':
fs/pstore/ftrace.c:47:6: warning: passing argument 7 of 'psinfo->write_buf' makes integer from pointer without a cast [enabled by default]
sizeof(rec), psinfo);
^
fs/pstore/ftrace.c:47:6: note: expected 'size_t' but argument is of type 'struct pstore_info *'
fs/pstore/ftrace.c:47:6: error: too few arguments to function 'psinfo->write_buf'
Caused by commit 6bbbca735936 ("pstore: Pass header size in the pstore
write callback").
I have used the version from next-20130701 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/booke64: Use common defines for AltiVec interrupts numbers
From: Scott Wood @ 2013-07-02 0:56 UTC (permalink / raw)
To: Alexander Graf; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <8F554F03-E6B0-4140-8830-D4FD6249CEF9@suse.de>
On 07/01/2013 07:18:21 PM, Alexander Graf wrote:
>=20
> On 01.07.2013, at 17:35, Mihai Caraman wrote:
>=20
> > On Book3E some SPE/FP/AltiVec interrupts share the same number. Use
> > common defines to indentify these numbers.
>=20
> So why didn't this happen from the beginning?
Ask Kumar.
> Why the change?
So we can remove this hack in kvm_asm.h:
/*
* TODO: Unify 32-bit and 64-bit kernel exception handlers to use same =20
defines
*/
#define BOOKE_INTERRUPT_SPE_UNAVAIL BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL
#define BOOKE_INTERRUPT_SPE_FP_DATA =20
BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST
#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL =20
BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL
#define BOOKE_INTERRUPT_ALTIVEC_ASSIST \
=20
BOOKE_INTERRUPT_SPE_FP_DATA_ALTIVEC_ASSIST
It was added as a compilation fix, and it was less intrusive to =20
temporarily fix it this way.
I am curious why the above code wasn't removed at the end of this =20
patchset. :-)
-Scott=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_booke: enable the relocatable for the kdump kernel
From: Scott Wood @ 2013-07-02 1:00 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc
In-Reply-To: <20130630073521.GC32268@pek-khao-d1.corp.ad.wrs.com>
On 06/30/2013 02:35:21 AM, Kevin Hao wrote:
> On Thu, Jun 27, 2013 at 09:19:06PM -0500, Scott Wood wrote:
> > On 06/26/2013 09:00:34 PM, Kevin Hao wrote:
> > >diff --git a/arch/powerpc/include/asm/mmu-book3e.h
> > >b/arch/powerpc/include/asm/mmu-book3e.h
> > >index 936db36..bf422db 100644
> > >--- a/arch/powerpc/include/asm/mmu-book3e.h
> > >+++ b/arch/powerpc/include/asm/mmu-book3e.h
> > >@@ -214,6 +214,11 @@
> > > #define TLBILX_T_CLASS2 6
> > > #define TLBILX_T_CLASS3 7
> > >
> > >+#ifdef CONFIG_PPC32
> > >+/* The max size that one tlb can map in a 32bit kernel. */
> > >+#define PPC_PIN_SIZE (1 << 28) /* 256M */
> > >+#endif
> >
> > That comment is not true for all chips.
>=20
> This is not for the hardware limitation.
It's not for a general software limitation, either. We can use 1G =20
mappings for user hugetlb (if the default mmap address is moved out of =20
the way) or for the kernel lowmem mapping (if the address is moved to =20
0x80000000 instead of 0xc0000000).
It's also possible (although unlikely at this point) that someone could =20
make a 32-bit booke chip that cannot handle 256M mappings.
> > Pardon my ignorance about how kdump/kexec works, but I'm a bit
> > confused by exactly what the situation is with crashkernel. How do
> > we know that we are the crash kernel, and that we should limit our
> > RAM usage to that area?
>=20
> The kexec tool will parse the command line of the boot kernel and get
> the reserved memory info (such as start address, size) and then pass
> these informations to the kdump kernel via device tree.
Does this alter memstart_addr or just mark the region as reserved?
> > >+ while (1) {
> > >+ cam_sz =3D calc_cam_sz(ram, virt, phys);
> > >+ if (cam_sz + phys > PHYSICAL_START + _end - _stext)
> > >+ break;
> > >+ ram =3D 1 << (ilog2(ram) + 1);
> > >+ }
> >
> > The ram that was passed in is as much as you have. Don't map more.
> >
> > What happens if (e.g.) memstart_addr is 512M, with a size of 512M,
> > and the kernel starts at 768M? Increasing the size will never get
> > you a mapping that covers kernstart, because calc_cam_sz will never
> > return more than 256M.
>=20
> Yes, the current code still can't handle this case. We always assume
> that the kernel is in the memory region which can be covered by the
> first tlb entry.
Assuming memstart_addr isn't affected by the crashkernel reservation =20
(if it is, could you point out where?), you'd then have a problem with =20
the crashkernel area going anywhere above 256M.
-Scott=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox