Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
Hi Heiko, On Mon, Jan 24, 2011 at 10:57:38AM +0100, Heiko Schocher wrote: - add binding to OF, compatible name smi,sm501 The MFD part looks fine to me: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v4] video, sm501: add I/O functions for use on powerpc
Hi Heiko, On Mon, Jan 24, 2011 at 10:57:20AM +0100, Heiko Schocher wrote: - add read/write functions for using this driver also on powerpc plattforms Not sure whose tree this is going through. Probably Paul's one though. The mfd part looks fine to me, please add my: Acked-by: Samuel Ortiz sa...@linux.intel.com Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3 RFC] dt: add documentation of ARM dt boot interface
On Mon, Jan 31, 2011 at 12:45:41AM -0700, Grant Likely wrote: Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- For RFC only. I do not plan to merge this change yet. g. Documentation/devicetree/booting-without-of.txt | 40 +++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 6bca668..3950aea 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -232,6 +233,45 @@ it with special cases. cannot support both configurations with Book E and configurations with classic Powerpc architectures. +2) Entry point for arch/arm +--- + + There is one and one single entry point to the kernel, at the start one and one ? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] dt: Remove obsolete description of powerpc boot interface
On Mon, Jan 31, 2011 at 12:45:05AM -0700, Grant Likely wrote: 32 and 64 bit powerpc support has been merged for a while now, but the booting-without-of.txt document still describes 32 bit as not supporting multiplatform, which is no longer true. This patch fixes the documentation. Also remove references to powerpc-specific details outside of section I in preparation to add details for other architectures. There's a line around 500 that starts: The kernel powerpc generic code does... Perhaps the powerpc reference should be dropped there? Also, there are several mentions of real Open Firmware, which are probably just fine, and prom_init(), which are probably arch specific. There is a section that talks about ranges that starts with: For a new 64-bit powerpc board, I Section III 5) has all kinds of powerpc specific stuff. CHRP, pSeries, PAPR in the root node. The references to Apple machines for examples are probably OK, but it shouldn't make PowerPC items as explicit requirements. Section III 5e) references a file that doesn't exist: arch/ppc64/kernel/setup.c Section V, paragraph 2 references a file that doesn't exist: arch/ppc64/kernel/prom.c Hope that helps you... josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] dt: Move device tree documentation out of powerpc directory
On Mon, Jan 31, 2011 at 12:44:57AM -0700, Grant Likely wrote: The device tree is used by more than just PowerPC. Make the documentation directory available to all. v2: reorganized files while moving to create arch and driver specific directories. Thanks Grant. Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3 RFC] dt: add documentation of ARM dt boot interface
-Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely Sent: Sunday, January 30, 2011 11:46 PM To: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org Cc: s...@ravnborg.org Subject: [PATCH 3/3 RFC] dt: add documentation of ARM dt boot interface Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- For RFC only. I do not plan to merge this change yet. g. Documentation/devicetree/booting-without-of.txt | 40 +++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting- without-of.txt index 6bca668..3950aea 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt In order to make this more generic, perhaps it should change names, so that it is actually a description of what the file describes, as opposed to what it doesn't describe. booting.txt? @@ -13,6 +13,7 @@ Table of Contents I - Introduction 1) Entry point for arch/powerpc +2) Entry point for arch/arm We should probably include microblaze here too... Steve This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3 RFC] dt: add documentation of ARM dt boot interface
On Mon, Jan 31, 2011 at 11:00 AM, Stephen Neuendorffer stephen.neuendorf...@xilinx.com wrote: -Original Message- From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org [mailto:linuxppc-dev- bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely Sent: Sunday, January 30, 2011 11:46 PM To: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org Cc: s...@ravnborg.org Subject: [PATCH 3/3 RFC] dt: add documentation of ARM dt boot interface Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- For RFC only. I do not plan to merge this change yet. g. Documentation/devicetree/booting-without-of.txt | 40 +++ 1 files changed, 40 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting- without-of.txt index 6bca668..3950aea 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt In order to make this more generic, perhaps it should change names, so that it is actually a description of what the file describes, as opposed to what it doesn't describe. booting.txt? I though about that, but I think I'd like to leave it as-is for the time being so that it is easier for people to find where it has moved to. @@ -13,6 +13,7 @@ Table of Contents I - Introduction 1) Entry point for arch/powerpc + 2) Entry point for arch/arm We should probably include microblaze here too... Awesome, thanks for volunteering to write the patch! :-) g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 31/42] USB: ehci-fsl: Fix 'have_sysif_regs' detection
From: Peter Tyser pty...@xes-inc.com
Previously a check was done on an ID register at the base of a CPU's
internal USB registers to determine if system interface regsiters were
present. The check looked for an ID register that had the format
ID[0:5] == ~ID[8:13] as described in the MPC5121 User's Manual to
determine if a MPC5121 or MPC83xx/85xx was being used.
There are two issues with this method:
- The ID register is not defined on the MPC83xx/85xx CPUs, so its
unclear what is being checked on them.
- Newer CPUs such as the P4080 also don't document the ID register, but
do share the same format as the MPC5121. Thus the previous code did
not set 'have_sysif_regs' properly which results in the P4080 not
properly initializing its USB ports.
Using the device tree 'compatible' node is a cleaner way to determine if
'have_sysif_regs' should be set and resolves the USB initialization issue
seen on the P4080.
Tested on a P4080-based system and compile tested on mpc512x_defconfig
with Freescale EHCI driver enabled.
Cc: Anatolij Gustschin ag...@denx.de
Cc: David Brownell dbrown...@users.sourceforge.net
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Peter Tyser pty...@xes-inc.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/usb/host/ehci-fsl.c | 13 -
drivers/usb/host/ehci-fsl.h |3 ---
drivers/usb/host/fsl-mph-dr-of.c | 11 ---
3 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 86e4289..5c761df 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -52,7 +52,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver *driver,
struct resource *res;
int irq;
int retval;
- unsigned int temp;
pr_debug(initializing FSL-SOC USB Controller\n);
@@ -126,18 +125,6 @@ static int usb_hcd_fsl_probe(const struct hc_driver
*driver,
goto err3;
}
- /*
-* Check if it is MPC5121 SoC, otherwise set pdata-have_sysif_regs
-* flag for 83xx or 8536 system interface registers.
-*/
- if (pdata-big_endian_mmio)
- temp = in_be32(hcd-regs + FSL_SOC_USB_ID);
- else
- temp = in_le32(hcd-regs + FSL_SOC_USB_ID);
-
- if ((temp ID_MSK) != (~((temp NID_MSK) 8) ID_MSK))
- pdata-have_sysif_regs = 1;
-
/* Enable USB controller, 83xx or 8536 */
if (pdata-have_sysif_regs)
setbits32(hcd-regs + FSL_SOC_USB_CTRL, 0x4);
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 2c83537..3fabed3 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -19,9 +19,6 @@
#define _EHCI_FSL_H
/* offsets for the non-ehci registers in the FSL SOC USB controller */
-#define FSL_SOC_USB_ID 0x0
-#define ID_MSK 0x3f
-#define NID_MSK0x3f00
#define FSL_SOC_USB_ULPIVP 0x170
#define FSL_SOC_USB_PORTSC10x184
#define PORT_PTS_MSK (330)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 574b99e..79a66d6 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -262,19 +262,24 @@ static void fsl_usb2_mpc5121_exit(struct platform_device
*pdev)
}
}
-struct fsl_usb2_platform_data fsl_usb2_mpc5121_pd = {
+static struct fsl_usb2_platform_data fsl_usb2_mpc5121_pd = {
.big_endian_desc = 1,
.big_endian_mmio = 1,
.es = 1,
+ .have_sysif_regs = 0,
.le_setup_buf = 1,
.init = fsl_usb2_mpc5121_init,
.exit = fsl_usb2_mpc5121_exit,
};
#endif /* CONFIG_PPC_MPC512x */
+static struct fsl_usb2_platform_data fsl_usb2_mpc8xxx_pd = {
+ .have_sysif_regs = 1,
+};
+
static const struct of_device_id fsl_usb2_mph_dr_of_match[] = {
- { .compatible = fsl-usb2-mph, },
- { .compatible = fsl-usb2-dr, },
+ { .compatible = fsl-usb2-mph, .data = fsl_usb2_mpc8xxx_pd, },
+ { .compatible = fsl-usb2-dr, .data = fsl_usb2_mpc8xxx_pd, },
#ifdef CONFIG_PPC_MPC512x
{ .compatible = fsl,mpc5121-usb2-dr, .data = fsl_usb2_mpc5121_pd, },
#endif
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: add devmem_is_allowed() for STRICT_DEVMEM checking
Provide devmem_is_allowed() routine to restrict access to kernel
memory from userspace.
Set CONFIG_STRICT_DEVMEM config option to switch on checking.
Signed-off-by: Steve Best sfb...@us.ibm.com
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..6805d5d 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -299,4 +299,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+def_bool y
+prompt Filter access to /dev/mem
+---help---
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 53b64be..f225032 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -262,6 +262,11 @@ extern void copy_user_page(void *to, void *from, unsigned
long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+static inline int devmem_is_allowed(unsigned long pfn)
+{
+return 0;
+}
+
#ifdef CONFIG_PPC_SMLPAR
void arch_free_page(struct page *page, int order);
#define HAVE_ARCH_FREE_PAGE
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add devmem_is_allowed() for STRICT_DEVMEM checking
On Mon, Jan 31, 2011 at 2:16 PM, Steve Best sfb...@us.ibm.com wrote:
Provide devmem_is_allowed() routine to restrict access to kernel
memory from userspace.
Set CONFIG_STRICT_DEVMEM config option to switch on checking.
Signed-off-by: Steve Best sfb...@us.ibm.com
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..6805d5d 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -299,4 +299,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+ def_bool y
+ prompt Filter access to /dev/mem
+ ---help---
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 53b64be..f225032 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -262,6 +262,11 @@ extern void copy_user_page(void *to, void *from,
unsigned long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+static inline int devmem_is_allowed(unsigned long pfn)
+{
+ return 0;
+}
+
Er, should this be toggled via CONFIG_STRICT_DEVMEM somehow? Or I
guess I'm missing why the config option had to be added if not.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add devmem_is_allowed() for STRICT_DEVMEM checking
On Mon, Jan 31, 2011 at 2:25 PM, Josh Boyer jwbo...@gmail.com wrote:
On Mon, Jan 31, 2011 at 2:16 PM, Steve Best sfb...@us.ibm.com wrote:
Provide devmem_is_allowed() routine to restrict access to kernel
memory from userspace.
Set CONFIG_STRICT_DEVMEM config option to switch on checking.
Signed-off-by: Steve Best sfb...@us.ibm.com
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..6805d5d 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -299,4 +299,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+ def_bool y
+ prompt Filter access to /dev/mem
+ ---help---
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the
kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h
b/arch/powerpc/include/asm/page.h
index 53b64be..f225032 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -262,6 +262,11 @@ extern void copy_user_page(void *to, void *from,
unsigned long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+static inline int devmem_is_allowed(unsigned long pfn)
+{
+ return 0;
+}
+
Er, should this be toggled via CONFIG_STRICT_DEVMEM somehow? Or I
guess I'm missing why the config option had to be added if not.
Nevermind. I see that it's done in the drivers/char/mem.c file.
Should have looked more first.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add devmem_is_allowed() for STRICT_DEVMEM checking
On Mon, 31 Jan 2011 14:16:00 -0500
Steve Best sfb...@us.ibm.com wrote:
Provide devmem_is_allowed() routine to restrict access to kernel
memory from userspace.
Set CONFIG_STRICT_DEVMEM config option to switch on checking.
Signed-off-by: Steve Best sfb...@us.ibm.com
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..6805d5d 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -299,4 +299,16 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config STRICT_DEVMEM
+def_bool y
+prompt Filter access to /dev/mem
+---help---
+ This option restricts access to /dev/mem. If this option is
+ disabled, you allow userspace access to all memory, including
+ kernel and userspace memory. Accidental memory access is likely
+ to be disastrous.
+ Memory access is required for experts who want to debug the kernel.
+
+ If you are unsure, say Y.
+
endmenu
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 53b64be..f225032 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -262,6 +262,11 @@ extern void copy_user_page(void *to, void *from,
unsigned long vaddr,
struct page *p);
extern int page_is_ram(unsigned long pfn);
+static inline int devmem_is_allowed(unsigned long pfn)
+{
+return 0;
+}
+
I don't see how this is a sane thing to turn on by default (you're not
restricting it, BTW -- you're completely disabling it with that
implementation of devmem_is_allowed). It will break anything that
uses /dev/mem to access I/O, possibly including desktoppy stuff like X
servers, as well as lots of stuff that goes on in embedded setups.
You need to be root to access /dev/mem, and root has plenty of
other options for causing disastrous results. You don't just stumble
onto /dev/mem by accident.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MMC on MPC8379
I'm running 2.6.32 on MPC8379, trying to use the SDHCI interface. It seems to work, reads are fine, but when I write to the device (I've tried both eMMC soldered-on and pluggable MMC/SD cards), I get intermittent failures. Specifically, some blocks will be written while others fail. I haven't yet found a pattern. Is there anything special about this interface? I notice that it's not really used by any FSL platforms although the driver claims support. Any ideas? Thanks -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] dt: Remove obsolete description of powerpc boot interface
32 and 64 bit powerpc support has been merged for a while now, but the booting-without-of.txt document still describes 32 bit as not supporting multiplatform, which is no longer true. This patch fixes the documentation. Also remove references to powerpc-specific details outside of section I in preparation to add details for other architectures. v3: cleaned up a lot more powerpc-isms and updated text to reflect current usage conventions. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- Documentation/devicetree/booting-without-of.txt | 165 --- 1 files changed, 54 insertions(+), 111 deletions(-) diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 7400d75..28b1c9d 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -13,7 +13,6 @@ Table of Contents I - Introduction 1) Entry point for arch/powerpc -2) Board support II - The DT block format 1) Header @@ -41,13 +40,6 @@ Table of Contents VI - System-on-a-chip devices and nodes 1) Defining child nodes of an SOC 2) Representing devices without a current OF specification - a) PHY nodes - b) Interrupt controllers - c) 4xx/Axon EMAC ethernet nodes - d) Xilinx IP cores - e) USB EHCI controllers - f) MDIO on GPIOs - g) SPI busses VII - Specifying interrupt information for devices 1) interrupts property @@ -123,7 +115,7 @@ Revision Information I - Introduction -During the recent development of the Linux/ppc64 kernel, and more +During the development of the Linux/ppc64 kernel, and more specifically, the addition of new platform types outside of the old IBM pSeries/iSeries pair, it was decided to enforce some strict rules regarding the kernel entry and bootloader - kernel interfaces, in @@ -146,7 +138,7 @@ section III, but, for example, the kernel does not require you to create a node for every PCI device in the system. It is a requirement to have a node for PCI host bridges in order to provide interrupt routing informations and memory/IO ranges, among others. It is also -recommended to define nodes for on chip devices and other busses that +recommended to define nodes for on chip devices and other buses that don't specifically fit in an existing OF specification. This creates a great flexibility in the way the kernel can then probe those and match drivers to device, without having to hard code all sorts of tables. It @@ -158,7 +150,7 @@ it with special cases. 1) Entry point for arch/powerpc --- - There is one and one single entry point to the kernel, at the start + There is one single entry point to the kernel, at the start of the kernel image. That entry point supports two calling conventions: @@ -210,12 +202,6 @@ it with special cases. with all CPUs. The way to do that with method b) will be described in a later revision of this document. - -2) Board support - - -64-bit kernels: - Board supports (platforms) are not exclusive config options. An arbitrary set of board supports can be built in a single kernel image. The kernel will know what set of functions to use for a @@ -234,48 +220,11 @@ it with special cases. containing the various callbacks that the generic code will use to get to your platform specific code -c) Add a reference to your ppc_md structure in the -machines table in arch/powerpc/kernel/setup_64.c if you are -a 64-bit platform. - -d) request and get assigned a platform number (see PLATFORM_* -constants in arch/powerpc/include/asm/processor.h - -32-bit embedded kernels: - - Currently, board support is essentially an exclusive config option. - The kernel is configured for a single platform. Part of the reason - for this is to keep kernels on embedded systems small and efficient; - part of this is due to the fact the code is already that way. In the - future, a kernel may support multiple platforms, but only if the + A kernel image may support multiple platforms, but only if the platforms feature the same core architecture. A single kernel build cannot support both configurations with Book E and configurations with classic Powerpc architectures. - 32-bit embedded platforms that are moved into arch/powerpc using a - flattened device tree should adopt the merged tree practice of - setting ppc_md up dynamically, even though the kernel is currently - built with support for only a single platform at a time. This allows - unification of the setup code, and will make it easier to go to a - multiple-platform-support model in the future. - -NOTE: I believe the above will be true once Ben's done with the merge -of the boot sequences someone speak up if this is wrong! - - To add a 32-bit embedded platform
[PATCH v3 3/3 RFC] dt: add documentation of ARM dt boot interface
v3: added details to Documentation/arm/Booting This is RFC only. I'm not asking for this to be merged until arm-dt support is accepted in mainline. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- Documentation/arm/Booting | 33 +-- Documentation/devicetree/booting-without-of.txt | 40 +++ 2 files changed, 69 insertions(+), 4 deletions(-) diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 7685029..4e686a2 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -65,13 +65,19 @@ looks at the connected hardware is beyond the scope of this document. The boot loader must ultimately be able to provide a MACH_TYPE_xxx value to the kernel. (see linux/arch/arm/tools/mach-types). - -4. Setup the kernel tagged list +4. Setup boot data +-- Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED New boot loaders: MANDATORY +The boot loader must provide either a tagged list or a dtb image for +passing configuration data to the kernel. The physical address of the +boot data is passed to the kernel in register r2. + +4a. Setup the kernel tagged list + + The boot loader must create and initialise the kernel tagged list. A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag @@ -101,6 +107,24 @@ The tagged list must be placed in a region of memory where neither the kernel decompressor nor initrd 'bootp' program will overwrite it. The recommended placement is in the first 16KiB of RAM. +4b. Setup the device tree +- + +The boot loader must load a device tree image (dtb) into system ram +at a 64bit aligned address and initialize it with the boot data. The +dtb format is documented in Documentation/devicetree/booting-without-of.txt. +The kernel will look for the dtb magic value of 0xd00dfeed at the dtb +physical address to determine if a dtb has been passed instead of a +tagged list. + +The boot loader must pass at a minimum the size and location of the +system memory, and the root filesystem location. The dtb must be +placed in a region of memory where the kernel decompressor will not +overwrite it. The recommended placement is in the first 16KiB of RAM +with the caveat that it may not be located at physical address 0 since +the kernel interprets a value of 0 in r2 to mean neither a tagged list +nor a dtb were passed. + 5. Calling the kernel image --- @@ -125,7 +149,8 @@ In either case, the following conditions must be met: - CPU register settings r0 = 0, r1 = machine type number discovered in (3) above. - r2 = physical address of tagged list in system RAM. + r2 = physical address of tagged list in system RAM, or + physical address of device tree block (dtb) in system RAM - CPU mode All forms of interrupts must be disabled (IRQs and FIQs) diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 28b1c9d..9381a14 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -13,6 +13,7 @@ Table of Contents I - Introduction 1) Entry point for arch/powerpc +2) Entry point for arch/arm II - The DT block format 1) Header @@ -225,6 +226,45 @@ it with special cases. cannot support both configurations with Book E and configurations with classic Powerpc architectures. +2) Entry point for arch/arm +--- + + There is one single entry point to the kernel, at the start + of the kernel image. That entry point supports two calling + conventions. A summary of the interface is described here. A full + description of the boot requirements is documented in + Documentation/arm/Booting + +a) ATAGS interface. Minimal information is passed from firmware +to the kernel with a tagged list of predefined parameters. + +r0 : 0 + +r1 : Machine type number + +r2 : Physical address of tagged list in system RAM + +b) Entry with a flattened device-tree block. Firmware loads the +physical address of the flattened device tree block (dtb) into r2, +r1 is not used, but it is considered good practise to use a valid +machine number as described in Documentation/arm/Booting. + +r0 : 0 + +r1 : Valid machine type number. When using a device tree, +a single machine type number will often be assigned to +represent a class or family of SoCs. + +r2 : physical pointer to the device-tree block +(defined in chapter II) in RAM. Device tree can be located +anywhere in system RAM, but it should be aligned
Re: [PATCH 2/3] dt: Remove obsolete description of powerpc boot interface
On Mon, Jan 31, 2011 at 4:36 AM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Mon, Jan 31, 2011 at 12:45:05AM -0700, Grant Likely wrote: 32 and 64 bit powerpc support has been merged for a while now, but the booting-without-of.txt document still describes 32 bit as not supporting multiplatform, which is no longer true. This patch fixes the documentation. Also remove references to powerpc-specific details outside of section I in preparation to add details for other architectures. There's a line around 500 that starts: The kernel powerpc generic code does... Perhaps the powerpc reference should be dropped there? Done Also, there are several mentions of real Open Firmware, which are probably just fine, and prom_init(), which are probably arch specific. The prom_init() reference is just an example, and so I'm okay with it staying in. The example is relevant to look at regardless of the architecture you are working on. Oh, but I should drop the reference to every node requiring a device_type property. There is a section that talks about ranges that starts with: For a new 64-bit powerpc board, I Fixed. Section III 5) has all kinds of powerpc specific stuff. CHRP, pSeries, PAPR in the root node. The references to Apple machines for examples are probably OK, but it shouldn't make PowerPC items as explicit requirements. Right, fixed. Section III 5e) references a file that doesn't exist: arch/ppc64/kernel/setup.c Fixed Section V, paragraph 2 references a file that doesn't exist: arch/ppc64/kernel/prom.c Hope that helps you... josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] dt: Move device tree documentation out of powerpc directory
The device tree is used by more than just PowerPC. Make the documentation
directory available to all.
v2: reorganized files while moving to create arch and driver specific
directories.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
Oops; resending 1/3 because last post sent raw patch which is too big
for the lists. This repost uses the git file rename diff format.
Sorry for the noise.
g.
Documentation/devicetree/bindings/ata/fsl-sata.txt |0
Documentation/devicetree/bindings/eeprom.txt |0
.../devicetree/bindings/gpio/8xxx_gpio.txt |0
Documentation/devicetree/bindings/gpio/gpio.txt|0
Documentation/devicetree/bindings/gpio/led.txt |0
Documentation/devicetree/bindings/i2c/fsl-i2c.txt |0
Documentation/devicetree/bindings/marvell.txt |0
.../devicetree/bindings/mmc/fsl-esdhc.txt |0
.../devicetree/bindings/mmc/mmc-spi-slot.txt |0
.../devicetree/bindings/mtd/fsl-upm-nand.txt |0
.../devicetree/bindings/mtd/mtd-physmap.txt|0
.../devicetree/bindings/net/can/mpc5xxx-mscan.txt |0
.../devicetree/bindings/net/can/sja1000.txt|0
.../devicetree/bindings/net/fsl-tsec-phy.txt |0
.../devicetree/bindings/net/mdio-gpio.txt |0
Documentation/devicetree/bindings/net/phy.txt |0
.../devicetree/bindings/pci/83xx-512x-pci.txt |0
.../devicetree/bindings/powerpc/4xx/cpm.txt|0
.../devicetree/bindings/powerpc/4xx/emac.txt |0
.../devicetree/bindings/powerpc/4xx/ndfc.txt |0
.../bindings/powerpc/4xx/ppc440spe-adma.txt|0
.../devicetree/bindings/powerpc/4xx/reboot.txt |0
.../devicetree/bindings/powerpc/fsl/board.txt |0
.../devicetree/bindings/powerpc/fsl/cpm_qe/cpm.txt |0
.../bindings/powerpc/fsl/cpm_qe/cpm/brg.txt|0
.../bindings/powerpc/fsl/cpm_qe/cpm/i2c.txt|0
.../bindings/powerpc/fsl/cpm_qe/cpm/pic.txt|0
.../bindings/powerpc/fsl/cpm_qe/cpm/usb.txt|0
.../bindings/powerpc/fsl/cpm_qe/gpio.txt |0
.../bindings/powerpc/fsl/cpm_qe/network.txt|0
.../devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt |0
.../bindings/powerpc/fsl/cpm_qe/qe/firmware.txt|0
.../bindings/powerpc/fsl/cpm_qe/qe/par_io.txt |0
.../bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt |0
.../bindings/powerpc/fsl/cpm_qe/qe/ucc.txt |0
.../bindings/powerpc/fsl/cpm_qe/qe/usb.txt |0
.../bindings/powerpc/fsl/cpm_qe/serial.txt |0
.../devicetree/bindings/powerpc/fsl/diu.txt|0
.../devicetree/bindings/powerpc/fsl/dma.txt|0
.../devicetree/bindings/powerpc/fsl/ecm.txt|0
.../devicetree/bindings/powerpc/fsl/gtm.txt|0
.../devicetree/bindings/powerpc/fsl/guts.txt |0
.../devicetree/bindings/powerpc/fsl/lbc.txt|0
.../devicetree/bindings/powerpc/fsl/mcm.txt|0
.../bindings/powerpc/fsl/mcu-mpc8349emitx.txt |0
.../bindings/powerpc/fsl/mpc5121-psc.txt |0
.../devicetree/bindings/powerpc/fsl/mpc5200.txt|0
.../devicetree/bindings/powerpc/fsl/mpic.txt |0
.../devicetree/bindings/powerpc/fsl/msi-pic.txt|0
.../devicetree/bindings/powerpc/fsl/pmc.txt|0
.../devicetree/bindings/powerpc/fsl/sec.txt|0
.../devicetree/bindings/powerpc/fsl/ssi.txt|0
.../bindings/powerpc/nintendo/gamecube.txt |0
.../devicetree/bindings/powerpc/nintendo/wii.txt |0
Documentation/devicetree/bindings/spi/fsl-spi.txt |0
Documentation/devicetree/bindings/spi/spi-bus.txt |0
Documentation/devicetree/bindings/usb/fsl-usb.txt |0
Documentation/devicetree/bindings/usb/usb-ehci.txt |0
Documentation/devicetree/bindings/xilinx.txt |0
Documentation/devicetree/booting-without-of.txt|0
60 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/{powerpc/dts-bindings/fsl/sata.txt =
devicetree/bindings/ata/fsl-sata.txt} (100%)
rename Documentation/{powerpc/dts-bindings/eeprom.txt =
devicetree/bindings/eeprom.txt} (100%)
rename Documentation/{powerpc/dts-bindings/fsl/8xxx_gpio.txt =
devicetree/bindings/gpio/8xxx_gpio.txt} (100%)
rename Documentation/{powerpc/dts-bindings/gpio/gpio.txt =
devicetree/bindings/gpio/gpio.txt} (100%)
rename Documentation/{powerpc/dts-bindings/gpio/led.txt =
devicetree/bindings/gpio/led.txt} (100%)
rename Documentation/{powerpc/dts-bindings/fsl/i2c.txt =
devicetree/bindings/i2c/fsl-i2c.txt} (100%)
rename Documentation/{powerpc/dts-bindings/marvell.txt =
devicetree/bindings/marvell.txt} (100%)
rename Documentation/{powerpc/dts-bindings/fsl/esdhc.txt =
devicetree/bindings/mmc/fsl-esdhc.txt} (100%)
rename
Re: [PATCH 0/3] dt: documentation reorganization
On Mon, Jan 31, 2011 at 12:44:41AM -0700, Grant Likely wrote: This series reorganizes and cleans up the device tree documentation to make the directory useful for non-powerpc users. Looks better than first try. But the structure is very flat. Did you consider an arch/* for all arch specific stuff? Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] dt: documentation reorganization
On Mon, Jan 31, 2011 at 09:34:49PM +0100, Sam Ravnborg wrote: On Mon, Jan 31, 2011 at 12:44:41AM -0700, Grant Likely wrote: This series reorganizes and cleans up the device tree documentation to make the directory useful for non-powerpc users. Looks better than first try. But the structure is very flat. Did you consider an arch/* for all arch specific stuff? Yes I did; but this stuff is pretty sparse so I didn't want to create a whole lot of levels when it isn't warranted. If really required in the future I'll split the arch and drivers into two separate directories. In the mean time I'm going to stick with this. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] dt: add of_platform_bus_snoop() which attaches nodes to devices
On Mon, Jan 31, 2011 at 3:01 PM, Grant Likely grant.lik...@secretlab.ca wrote: This patch implements an alternate method for using device tree data for populating machine device registration. Traditionally, board support has directly generated and registered devices based on nodes in the device tree. The board support code starts at the root of the tree and begins allocating devices for each device node it finds. Similarly, bus drivers (i2c, spi, etc.) use their child nodes to register child devices. This model can be seen in almost all the powerpc board ports (arch/powerpc/platforms/*). However, for many of the ARM SoCs, there already exists complete board support for many SoCs that have their own code for registering the basic set of platform devices with non-trivial dependencies on clock structure and machine specific platform code. While starting at the base of the tree and working up is certainly possible, it requires modifying a lot of machine support code to get it working. Instead, this patch provides an alternate approach. Instead of starting at the root of the tree and working up, this patch allows the SoC support code to register its standard set of platform devices in the normal way. However, it also registers a platform_bus notifier function which compares platform_device registrations with data in the device tree. Whenever it finds a matching node, it increments the node reference count and assigns it to the device's of_node pointer so that it is available for the device driver to use and bind against. For example, an spi master driver would have access to the spi node which contains information about all the spi slaves on the bus. One more note. It might also be a good idea to do something like this for the PCI and AMBA buses. I've not yet looked at how much code could be made common for implementing that. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] dt: documentation reorganization
On Mon, Jan 31, 2011 at 02:01:31PM -0700, Grant Likely wrote: On Mon, Jan 31, 2011 at 09:34:49PM +0100, Sam Ravnborg wrote: On Mon, Jan 31, 2011 at 12:44:41AM -0700, Grant Likely wrote: This series reorganizes and cleans up the device tree documentation to make the directory useful for non-powerpc users. Looks better than first try. But the structure is very flat. Did you consider an arch/* for all arch specific stuff? Yes I did; but this stuff is pretty sparse so I didn't want to create a whole lot of levels when it isn't warranted. If really required in the future I'll split the arch and drivers into two separate directories. In the mean time I'm going to stick with this. OK. Sam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] dt: add of_platform_bus_snoop() which attaches nodes to devices
This patch implements an alternate method for using device tree data
for populating machine device registration. Traditionally, board
support has directly generated and registered devices based on nodes
in the device tree. The board support code starts at the root of the
tree and begins allocating devices for each device node it finds.
Similarly, bus drivers (i2c, spi, etc.) use their child nodes to
register child devices. This model can be seen in almost all the powerpc
board ports (arch/powerpc/platforms/*).
However, for many of the ARM SoCs, there already exists complete board
support for many SoCs that have their own code for registering the
basic set of platform devices with non-trivial dependencies on clock
structure and machine specific platform code. While starting at the
base of the tree and working up is certainly possible, it requires
modifying a lot of machine support code to get it working.
Instead, this patch provides an alternate approach. Instead of
starting at the root of the tree and working up, this patch allows the
SoC support code to register its standard set of platform devices in
the normal way. However, it also registers a platform_bus notifier
function which compares platform_device registrations with data in the
device tree. Whenever it finds a matching node, it increments the
node reference count and assigns it to the device's of_node pointer so
that it is available for the device driver to use and bind against.
For example, an spi master driver would have access to the spi node
which contains information about all the spi slaves on the bus.
An example usage of this facility is to allow a single 'devicetree'
board support file to support multiple machines all using the same
SoC. The common code would register SoC devices unconditionally, and
the board support code would depend entirely on device tree data.
Note: Board ports using this facility are still required to provide a
fully populated device tree blob. It is not a shortcut to providing
an accurate device tree model of the machine to the point that it
would be reasonably possible to switch to a direct registration model
for all devices without change the device tree. ie. The SoC still
needs to be correctly identified and there should be nodes for all the
discrete devices.
I'm not convinced that this is the model to pursue over the long term,
but it greatly simplifies the task of getting device tree support up
and running, and it provides a migration path to full dt device
registration (if it makes sense to do so).
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
This patch can be found in my devicetree/test branch (frequently rebased)
git://git.secretlab.ca/git/linux-2.6 devicetree/test
I'll move it to devicetree/arm (never rebased) once it is stable.
g.
arch/arm/mach-versatile/core.c |3 +
drivers/of/address.c | 14 ++
drivers/of/base.c |3 +
drivers/of/platform.c | 230
include/linux/of_address.h |1
include/linux/of_platform.h|2
6 files changed, 253 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-versatile/core.c b/arch/arm/mach-versatile/core.c
index 136c32e..86ad01d 100644
--- a/arch/arm/mach-versatile/core.c
+++ b/arch/arm/mach-versatile/core.c
@@ -21,6 +21,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/of_platform.h
#include linux/platform_device.h
#include linux/sysdev.h
#include linux/interrupt.h
@@ -873,6 +874,8 @@ void __init versatile_init(void)
clkdev_add_table(lookups, ARRAY_SIZE(lookups));
+ of_platform_bus_snoop(NULL, NULL);
+
platform_device_register(versatile_flash_device);
platform_device_register(versatile_i2c_device);
platform_device_register(smc91x_device);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index b4559c5..b43ff66 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -556,6 +556,20 @@ static int __of_address_to_resource(struct device_node
*dev,
}
/**
+ * of_address_count - Return the number of entries in the reg property
+ */
+int of_address_count(struct device_node *np)
+{
+ struct resource temp_res;
+ int num_reg = 0;
+
+ while (of_address_to_resource(np, num_reg, temp_res) == 0)
+ num_reg++;
+ return num_reg;
+}
+EXPORT_SYMBOL_GPL(of_address_count);
+
+/**
* of_address_to_resource - Translate device tree address and return as
resource
*
* Note that if your address is a PIO address, the conversion will fail if
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 710b53b..632ebae 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -496,6 +496,9 @@ EXPORT_SYMBOL(of_find_node_with_property);
const struct of_device_id *of_match_node(const struct of_device_id *matches,
const struct device_node *node)
{
+ if (!matches)
+
State of suspend-to-ram?
Hi all! First of all: Sorry, this is the wrong mailing list, but I searched a lot and found none that would fit to PPC user-related problems -- linux-ppc would have been one but this one seems to be dead since 2004?! I've a G4 based Mac mini and would like to suspend it to RAM, though the vanilla kernel doesn't allow me to do this (/sys/power/state mentions only disk). The reason for this is my platform is marked as PMAC_MB_MAY_SLEEP instead of PMAC_MB_CAN_SLEEP in arch/powerpc/platforms/powermac/feature.c. So I changed that to be PMAC_MB_CAN_SLEEP and was able to suspend the system using the pm-suspend script from the pm-utils suite. The LED on the front was pulsing like it is when suspended under MacOS X. After pushing the power button the system started to resume but just got stuck. I see no messages on the console, nothing in syslog. So I assume the system panics pretty early in the resume path. Because the system has no serial console the debug capabilities are fairly limited. Any hints why this doesn't work or how to debug this any further? Some system information: mk@maxi:~$ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1416.61MHz revision: 1.2 (pvr 8003 0102) bogomips: 83.24 timebase: 41620997 platform: PowerMac model : PowerMac10,1 machine : PowerMac10,1 motherboard : PowerMac10,1 MacRISC3 Power Macintosh detected as : 287 (Mac mini) pmac flags : 0001 L2 cache: 512K unified pmac-generation : NewWorld Memory : 1024 MB mk@maxi:~$ uname -a Linux maxi 2.6.37+ #2 Mon Jan 24 08:56:01 CET 2011 ppc GNU/Linux Regards, Mathias ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
