* [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: Kumar Gala @ 2008-08-14 13:28 UTC (permalink / raw)
To: jdl, devicetree-discuss; +Cc: linuxppc-dev, David Gibson
If the path doesn't start with '/' check to see if it matches some alias
under "/aliases" and substitute the matching alias value in the path
and retry the lookup.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Simplify down the aliases.dts to only whats needed for the test.
- k
libfdt/fdt_ro.c | 21 ++++++++++++++-
tests/Makefile.tests | 2 +-
tests/aliases.dts | 21 +++++++++++++++
tests/path_offset_aliases.c | 59 +++++++++++++++++++++++++++++++++++++++++++
tests/run_tests.sh | 4 +++
5 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 tests/aliases.dts
create mode 100644 tests/path_offset_aliases.c
diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c
index ebd1260..2f3ff48 100644
--- a/libfdt/fdt_ro.c
+++ b/libfdt/fdt_ro.c
@@ -139,8 +139,25 @@ int fdt_path_offset(const void *fdt, const char *path)
FDT_CHECK_HEADER(fdt);
- if (*path != '/')
- return -FDT_ERR_BADPATH;
+ /* see if we have an alias */
+ if (*path != '/') {
+ const char *q;
+ int aliasoffset = fdt_path_offset(fdt, "/aliases");
+
+ if (aliasoffset < 0)
+ return -FDT_ERR_BADPATH;
+
+ q = strchr(path, '/');
+ if (!q)
+ q = end;
+
+ p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
+ if (!p)
+ return -FDT_ERR_BADPATH;
+ offset = fdt_path_offset(fdt, p);
+
+ p = q;
+ }
while (*p) {
const char *q;
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index 704c95d..44021b0 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -11,7 +11,7 @@ LIB_TESTS_L = get_mem_rsv \
open_pack rw_tree1 set_name setprop del_property del_node \
string_escapes references path-references boot-cpuid incbin \
dtbs_equal_ordered \
- add_subnode_with_nops
+ add_subnode_with_nops path_offset_aliases
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
diff --git a/tests/aliases.dts b/tests/aliases.dts
new file mode 100644
index 0000000..39d88ff
--- /dev/null
+++ b/tests/aliases.dts
@@ -0,0 +1,21 @@
+/dts-v1/;
+
+/ {
+ aliases {
+ s1 = &sub1;
+ ss1 = &subsub1;
+ sss1 = &subsubsub1;
+ };
+
+ sub1: subnode@1 {
+ compatible = "subnode1";
+
+ subsub1: subsubnode {
+ compatible = "subsubnode1", "subsubnode";
+
+ subsubsub1: subsubsubnode {
+ compatible = "subsubsubnode1", "subsubsubnode";
+ };
+ };
+ };
+};
diff --git a/tests/path_offset_aliases.c b/tests/path_offset_aliases.c
new file mode 100644
index 0000000..191edd2
--- /dev/null
+++ b/tests/path_offset_aliases.c
@@ -0,0 +1,59 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_path_offset()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ * Copyright 2008 Kumar Gala, Freescale Semiconductor, Inc.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_alias(void *fdt, const char *full_path, const char *alias_path)
+{
+ int offset, offset_a;
+
+ offset = fdt_path_offset(fdt, full_path);
+ offset_a = fdt_path_offset(fdt, alias_path);
+
+ if (offset != offset_a)
+ FAIL("Mismatch between %s path_offset (%d) and %s path_offset alias (%d)",
+ full_path, offset, alias_path, offset_a);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_alias(fdt, "/subnode@1", "s1");
+ check_alias(fdt, "/subnode@1/subsubnode", "ss1");
+ check_alias(fdt, "/subnode@1/subsubnode", "s1/subsubnode");
+ check_alias(fdt, "/subnode@1/subsubnode/subsubsubnode", "sss1");
+ check_alias(fdt, "/subnode@1/subsubnode/subsubsubnode", "ss1/subsubsubnode");
+ check_alias(fdt, "/subnode@1/subsubnode/subsubsubnode", "s1/subsubnode/subsubsubnode");
+
+ PASS();
+}
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index 7bfc399..eb29462 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -214,6 +214,10 @@ dtc_tests () {
run_dtc_test -I dts -O dtb -o dtc_comments-cmp.test.dtb comments-cmp.dts
run_test dtbs_equal_ordered dtc_comments.test.dtb dtc_comments-cmp.test.dtb
+ # Check aliases support in fdt_path_offset
+ run_dtc_test -I dts -O dtb -o aliases.dtb aliases.dts
+ run_test path_offset_aliases aliases.dtb
+
# Check /include/ directive
run_dtc_test -I dts -O dtb -o includes.test.dtb include0.dts
run_test dtbs_equal_ordered includes.test.dtb test_tree1.dtb
--
1.5.5.1
^ permalink raw reply related
* Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: David Gibson @ 2008-08-14 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <Pine.LNX.4.64.0808140827220.2701@blarg.am.freescale.net>
On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
> If the path doesn't start with '/' check to see if it matches some alias
> under "/aliases" and substitute the matching alias value in the path
> and retry the lookup.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: How to use ramdisk on the ml300?
From: Jens Wirth @ 2008-08-14 13:54 UTC (permalink / raw)
To: linuxppc-embedded, wangyanlong
In-Reply-To: <18979320.post@talk.nabble.com>
Hi
On Thu, Aug 14, 2008 at 12:44 PM, wangyanlong <killyouatonce@gmail.com> wrote:
>
> Hi JensWirth,
> Thanks for your reply :). I have some questions here.
> (1)You told me "make simpleImage.virtex405-ml300",i only know "make
> zImage" and "make zImage.initrd" ,what it is this command mean???
It's a relatively new target in the arch/powerpc/boot/Makefile which
wraps your compressed kernel and bootcode together with a device tree
blob. A device tree blob is created using a device tree source (dts).
> (2)What is dts ? I don't know what is this :(
A device tree source is plain text. Look inside arch/powerpc/boot/dts.
A device tree is essential if you want to boot an ARCH=powerpc
Linux-Kernel. Read this:
http://ols.fedoraproject.org/OLS/Reprints-2008/likely2-reprint.pdf
I supposed you were using 2.6.26 or 2.6.27-rcX
Regards
Jens
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Laurent Pinchart @ 2008-08-14 14:04 UTC (permalink / raw)
To: linuxppc-dev
Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, David Brownell,
Li Yang, Timur Tabi
In-Reply-To: <20080808161813.GA31258@polina.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
On Friday 08 August 2008, Anton Vorontsov wrote:
> We'll need this function to write platform-specific hooks to deal
> with pin's dedicated functions. Quite obviously this will work only
> for the platforms with 1-to-1 GPIO to PIN mapping.
>
> This is stopgap solution till we think out and implement a proper
> api (pinlib?).
How do you support reverting the GPIO mode to non-dedicated ?
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/gpio/gpiolib.c | 3 ++-
> include/asm-generic/gpio.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 8d29405..9536fa8 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -81,10 +81,11 @@ static void gpio_ensure_requested(struct gpio_desc *desc)
> }
>
> /* caller holds gpio_lock *OR* gpio is marked as requested */
> -static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
> +struct gpio_chip *gpio_to_chip(unsigned gpio)
> {
> return gpio_desc[gpio].chip;
> }
> +EXPORT_SYMBOL_GPL(gpio_to_chip);
>
> /* dynamic allocation of GPIOs, e.g. on a hotplugged device */
> static int gpiochip_find_base(int ngpio)
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index 0f99ad3..d70ee45 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -81,6 +81,7 @@ struct gpio_chip {
> unsigned exported:1;
> };
>
> +extern struct gpio_chip *gpio_to_chip(unsigned gpio);
> extern const char *gpiochip_is_requested(struct gpio_chip *chip,
> unsigned offset);
> extern int __must_check gpiochip_reserve(int start, int ngpio);
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Anton Vorontsov @ 2008-08-14 14:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <200808141604.22287.laurentp@cse-semaphore.com>
On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote:
> On Friday 08 August 2008, Anton Vorontsov wrote:
> > We'll need this function to write platform-specific hooks to deal
> > with pin's dedicated functions. Quite obviously this will work only
> > for the platforms with 1-to-1 GPIO to PIN mapping.
> >
> > This is stopgap solution till we think out and implement a proper
> > api (pinlib?).
>
> How do you support reverting the GPIO mode to non-dedicated ?
As we always do with the GPIO API: gpio_direction_*() calls.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Laurent Pinchart @ 2008-08-14 14:45 UTC (permalink / raw)
To: avorontsov
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <20080814141428.GA32296@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 980 bytes --]
On Thursday 14 August 2008, Anton Vorontsov wrote:
> On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote:
> > On Friday 08 August 2008, Anton Vorontsov wrote:
> > > We'll need this function to write platform-specific hooks to deal
> > > with pin's dedicated functions. Quite obviously this will work only
> > > for the platforms with 1-to-1 GPIO to PIN mapping.
> > >
> > > This is stopgap solution till we think out and implement a proper
> > > api (pinlib?).
> >
> > How do you support reverting the GPIO mode to non-dedicated ?
>
> As we always do with the GPIO API: gpio_direction_*() calls.
So the proper sequence to configure a pin in dedicated mode is to set the direction first (which will unset the dedicated mode bit) and then set dedicated mode (which will not touch the direction bit) ?
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()
From: Grant Likely @ 2008-08-14 15:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: miltonm, linuxppc-dev, paulus, scottwood
In-Reply-To: <1C19524E-8400-4F61-AEB1-19CF20E71098@kernel.crashing.org>
On Thu, Aug 14, 2008 at 7:00 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 12, 2008, at 10:03 PM, Grant Likely wrote:
>
>> +/**
>> + * ioremap_early - Allow large persistant IO regions to be mapped early.
>> + * @addr: physical address of region
>> + * @size: size of region
>> + *
>> + * This routine uses setbat() to set up IO ranges before the MMU is
>> + * fully configured.
>> + *
>> + * This routine can be called really early, before MMU_init() is called.
>> It
>> + * is useful for setting up early debug output consoles and frequently
>> + * accessed IO regions, like the internally memory mapped registers
>> (IMMR)
>> + * in an SoC. Ranges mapped with this function persist even after
>> MMU_init()
>> + * is called and the MMU is turned on 'for real.'
>> + *
>> + * The region mapped is large (minimum size of 128k) and virtual mapping
>> must
>> + * be aligned against this boundary. Therefore, to avoid fragmentation
>> all
>> + * calls to ioremap_early() are best made before any calls to ioremap
>> + * for smaller regions.
>> + */
>> +void __iomem * __init
>> +ioremap_early(phys_addr_t addr, unsigned long size)
>> +{
>> + unsigned long v, p;
>> + int i;
>> +
>> + /* Be loud and annoying if someone calls this too late.
>> + * No need to crash the kernel though */
>> + WARN_ON(mem_init_done);
>> + if (mem_init_done)
>> + return NULL;
>> +
>> + /* Make sure request is sane */
>> + if (size == 0)
>> + return NULL;
>> +
>> + /* If the region is already block mapped, then there is nothing
>> + * to do; just return the mapped address */
>> + v = p_mapped_by_bats(addr);
>> + if (v)
>> + return (void __iomem *)v;
>> +
>> + /* Adjust size to reflect aligned region */
>> + p = _ALIGN_DOWN(addr, 128 << 10); /* BATs align on 128k boundaries
>> */
>> + size = ALIGN(addr - p + size, 128 << 10);
>> +
>> + /* Allocate the aligned virtual base address. ALIGN_DOWN is used
>> + * to ensure no overlaps occur with normal 4k ioremaps. */
>> + v = ioremap_bot = _ALIGN_DOWN(ioremap_bot, 128 << 10) - size;
>> +
>> + /* Set up a BAT for this IO region */
>> + i = loadbat(v, p, size, _PAGE_IO);
>
> what happens if we run out of bats?
Then it returns NULL and the caller must handle it. The board port
maintainer needs understand the board/CPU/SoC and not depend on more
BATs than are available. They also need to understand that there is a
tradeoff between BATs for IO and BATs for RAM. If the board port uses
up all the BATs for IO, then RAM above 256MB ends up getting mapped
with PTEs and there is a performance hit. My expectation is that only
platform code will use this facility. Device drivers should continue
to use ioremap() and will gain the benefit of the BATs if platform
code already set them up. I can add some text to the documentation to
describe this.
I'm not going to make any attempt to fallback to PTEs for IO when
there isn't enough BATs. Doing so adds an order of magnitude more
complexity.
> does this actually build on any non-BAT based ppc32 system?
Heh, oops. I had built the older version of this on 4xx, but I didn't
do this one. I'll fix it in v3
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: Jon Loeliger @ 2008-08-14 15:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <Pine.LNX.4.64.0808140827220.2701@blarg.am.freescale.net>
> If the path doesn't start with '/' check to see if it matches some alias
> under "/aliases" and substitute the matching alias value in the path
> and retry the lookup.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
jdl
^ permalink raw reply
* RPC source code
From: Steve Iribarne (GMail) @ 2008-08-14 15:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 172 bytes --]
Where in the heck does one find the source code for RPC? I need to cross
compile it... ideas??
thanks.
-stv
--
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/
[-- Attachment #2: Type: text/html, Size: 251 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Anton Vorontsov @ 2008-08-14 15:10 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <200808141645.56418.laurentp@cse-semaphore.com>
On Thu, Aug 14, 2008 at 04:45:52PM +0200, Laurent Pinchart wrote:
> On Thursday 14 August 2008, Anton Vorontsov wrote:
> > On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote:
> > > On Friday 08 August 2008, Anton Vorontsov wrote:
> > > > We'll need this function to write platform-specific hooks to deal
> > > > with pin's dedicated functions. Quite obviously this will work only
> > > > for the platforms with 1-to-1 GPIO to PIN mapping.
> > > >
> > > > This is stopgap solution till we think out and implement a proper
> > > > api (pinlib?).
> > >
> > > How do you support reverting the GPIO mode to non-dedicated ?
> >
> > As we always do with the GPIO API: gpio_direction_*() calls.
>
> So the proper sequence to configure a pin in dedicated mode is to set
> the direction first (which will unset the dedicated mode bit) and
> then set dedicated mode (which will not touch the direction bit) ?
Not exactly. But you can do this way, if you need to preserve
a direction. What I did is a bit different though.
qe_gpio_set_dedicated() actually just restores a mode that
firmware had set up, including direction (since direction could
be a part of dedicated configuration).
That is, upon GPIO controller registration, we save all registers,
then driver can set up a pin to a GPIO mode via standard API, and
then it can _revert_ a pin to a dedicated function via
qe_gpio_set_dedicated() call. Dedicated function is specified by
the firmware (or board file), we're just restoring it.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang?
From: Vince Asbridge @ 2008-08-14 16:05 UTC (permalink / raw)
To: 'Fillod Stephane', 'linuxppc-embedded'
Cc: u-boot, 'Stephen Shirron'
In-Reply-To: <0B45E93C5FF65740AEAE690BF3848B7AD38359@rennsmail04.eu.thmulti.com>
Stephane,
Thanks so much for your prompt reply.
We will pursue your suggestions, and let the forum know what we find. =
We're
at 1.3.0 uboot version.
Vince
> -----Original Message-----
> From: Fillod Stephane [mailto:stephane.fillod@thomson.net]=20
> Sent: Thursday, August 14, 2008 8:06 AM
> To: Vince Asbridge; linuxppc-embedded
> Cc: u-boot@lists.denx.de
> Subject: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just=20
> doesn't work! Can anyone pointme to how to debug this hang?
>=20
> Vince Asbridge wrote:
> > We have an 8548 design, which implements a DDR2 on a SODIMM=20
> We have an=20
> > issue with dual rank memory (specific part number Viking=20
> VR5DR287218EBSS1), which is a 1G ECC Registered SODIMM part,=20
> with two ranks.
> > Our platform wires CS0 and CS1 to the SODIMM slot.=20
> > At uBoot, all is well.=A0 Memory is discovered as ECC 533, 1G=20
> DDR2 64Bit 4 beat bursts, and mtest can read and write all 1G=20
> of the SODIMM.
> [...]
> > Other DDR2s (identical except for vendor and # of ranks),=20
> work perfectly!=20
> > Anyone got a clue what I could look at to try to figure this out?=20
> > We've tried enable / disable ECC at uboot We've tried=20
> enable / disable=20
> > Interleaving at uboot uboot always works (and can read/write entire=20
> > DDR), Linux always hangs on boot!
>=20
> U-Boot is too gentle when testing SDRAM. Make sure the caches=20
> are enabled under U-Boot, and put on heavy stress with DMA,=20
> pipelined prefetch's, etc.
> This is what your CPU is enduring under Linux.=20
>=20
> Your question is definitely a question for the U-Boot mailing list.
> BTW, what is the version of U-Boot in use? U-Boot is still=20
> missing the following patch:
>=20
> MPC85xx BA bits not set for 3-bit bank address DIMM of CS1
>=20
> The current implementation set the number of bank address bits
> (BA) in the processor for CS0 but not for CS1.=20
>=20
> Signed-off-by: Stephane Fillod <stephane.fillod@thomson.net>
>=20
> --- u-boot/cpu/mpc85xx/spd_sdram.c
> +++ u-boot/cpu/mpc85xx/spd_sdram.c
> @@ -365,6 +365,7 @@
> ddr->cs1_config =3D ( 1<<31
> | (odt_rd_cfg << 20)
> | (odt_wr_cfg << 16)
> + | (ba_bits << 14)
> | (spd.nrow_addr - 12) << 8
> | (spd.ncol_addr - 8) );
> debug("DDR: cs1_bnds =3D 0x%08x\n", ddr->cs1_bnds);
>=20
>=20
>=20
> Otherwise, recompile with -DDEBUG and CFG_CMD_SDRAM, grab the=20
> Viking datasheet and a scope, and a full cup of coffee/tea=20
> much needed during cross-checking :-)
>=20
> Cheers
> --
> Stephane
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-14 16:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <200808141153.07983.arnd@arndb.de>
On Thu, 14 Aug 2008 11:53:07 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> > + ndfc->ndfcbase = ioremap(reg[1], reg[2]);
>
> This could be better expressed as of_iomap().
I tried of_iomap(), but it doesn't seem to like the 3 value reg. i.e.
It doesn't skip the chip select. And since I need to read the reg
property to get the chip select any way, I just used the value directly.
>
> > - platform_set_drvdata(pdev, ndfc);
> > + __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
> >
> > - printk("NDFC NAND Driver initialized. Chip-Rev: 0x%08x\n",
> > - __raw_readl(ndfc->ndfcbase + NDFC_REVID));
> > + /* Set the bank settings */
> > + reg = of_get_property(ofdev->node, "bank_settings", NULL);
> > + bank_settings = reg ? *reg : 0x80002222;
>
> Your device tree does have a bank_setting, so why not assume that
> all others will have it as well? I would remove the default.
I am thinking of making the bank settings an optional value. I assume
most people with 44x chips with NAND will be using u-boot. If you
enable NAND in u-boot, it should configure the bank settings for you.
I put the bank setting in my dts just to show a "complete"
configuration.
Cheers,
Sean
^ permalink raw reply
* Re: [RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()
From: Kumar Gala @ 2008-08-14 16:24 UTC (permalink / raw)
To: Grant Likely; +Cc: miltonm, linuxppc-dev, paulus, scottwood
In-Reply-To: <fa686aa40808140800s417af75ex76ae73ec990be58d@mail.gmail.com>
>> what happens if we run out of bats?
>
> Then it returns NULL and the caller must handle it. The board port
> maintainer needs understand the board/CPU/SoC and not depend on more
> BATs than are available. They also need to understand that there is a
> tradeoff between BATs for IO and BATs for RAM. If the board port uses
> up all the BATs for IO, then RAM above 256MB ends up getting mapped
> with PTEs and there is a performance hit. My expectation is that only
> platform code will use this facility. Device drivers should continue
> to use ioremap() and will gain the benefit of the BATs if platform
> code already set them up. I can add some text to the documentation to
> describe this.
>
> I'm not going to make any attempt to fallback to PTEs for IO when
> there isn't enough BATs. Doing so adds an order of magnitude more
> complexity.
that's fine.. I just didn't look at setbat() to see it errors out.
Also can we get rid of LOAD_BAT in head_32.S?
- k
^ permalink raw reply
* Re: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just doesn't work! Can anyone pointme to how to debug this hang?
From: Jon Loeliger @ 2008-08-14 16:31 UTC (permalink / raw)
To: Vince Asbridge
Cc: u-boot, 'Stephen Shirron', 'linuxppc-embedded'
In-Reply-To: <0b1f01c8fe27$81d6b250$4b01a8c0@sanblaze.com>
Vince Asbridge wrote:
> Stephane,
>
> Thanks so much for your prompt reply.
>
> We will pursue your suggestions, and let the forum know what we find. We're
> at 1.3.0 uboot version.
>
> Vince
>
>> -----Original Message-----
>> From: Fillod Stephane [mailto:stephane.fillod@thomson.net]
>> Sent: Thursday, August 14, 2008 8:06 AM
>> To: Vince Asbridge; linuxppc-embedded
>> Cc: u-boot@lists.denx.de
>> Subject: [PATCH] RE: Some memory (DDR2 ECC Dual Rank) just
>> doesn't work! Can anyone pointme to how to debug this hang?
>>
>> Vince Asbridge wrote:
>>> We have an 8548 design, which implements a DDR2 on a SODIMM
>> We have an
>>> issue with dual rank memory (specific part number Viking
>> VR5DR287218EBSS1), which is a 1G ECC Registered SODIMM part,
>> with two ranks.
>>> Our platform wires CS0 and CS1 to the SODIMM slot.
>>> At uBoot, all is well. Memory is discovered as ECC 533, 1G
>> DDR2 64Bit 4 beat bursts, and mtest can read and write all 1G
>> of the SODIMM.
>> [...]
>>> Other DDR2s (identical except for vendor and # of ranks),
>> work perfectly!
>>> Anyone got a clue what I could look at to try to figure this out?
>>> We've tried enable / disable ECC at uboot We've tried
>> enable / disable
>>> Interleaving at uboot uboot always works (and can read/write entire
>>> DDR), Linux always hangs on boot!
>> U-Boot is too gentle when testing SDRAM. Make sure the caches
>> are enabled under U-Boot, and put on heavy stress with DMA,
>> pipelined prefetch's, etc.
>> This is what your CPU is enduring under Linux.
>>
>> Your question is definitely a question for the U-Boot mailing list.
>> BTW, what is the version of U-Boot in use? U-Boot is still
>> missing the following patch:
>>
>> MPC85xx BA bits not set for 3-bit bank address DIMM of CS1
>>
>> The current implementation set the number of bank address bits
>> (BA) in the processor for CS0 but not for CS1.
>>
>> Signed-off-by: Stephane Fillod <stephane.fillod@thomson.net>
>>
>> --- u-boot/cpu/mpc85xx/spd_sdram.c
>> +++ u-boot/cpu/mpc85xx/spd_sdram.c
>> @@ -365,6 +365,7 @@
>> ddr->cs1_config = ( 1<<31
>> | (odt_rd_cfg << 20)
>> | (odt_wr_cfg << 16)
>> + | (ba_bits << 14)
>> | (spd.nrow_addr - 12) << 8
>> | (spd.ncol_addr - 8) );
>> debug("DDR: cs1_bnds = 0x%08x\n", ddr->cs1_bnds);
>>
>>
>>
>> Otherwise, recompile with -DDEBUG and CFG_CMD_SDRAM, grab the
>> Viking datasheet and a scope, and a full cup of coffee/tea
>> much needed during cross-checking :-)
>>
That bug fix, along with many, many others, as well as some
new support for multiple controllers and such are all present
in the DDR re-write patch set that Kumar just posted. You may
want to try that code too. It will be replacing the entire
85xx/86xx and eventually the 83xx line of memory controller
initialization. It also contains some support for a pretty
useful interactive DDR configuration setup mechanism too.
jdl
^ permalink raw reply
* Re: [PATCH 2/2] port ndfc driver to of platform
From: Jon Loeliger @ 2008-08-14 16:32 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, devicetree-discuss, Sean MacLennan
In-Reply-To: <200808141208.57345.arnd@arndb.de>
Arnd Bergmann wrote:
> Did we ever come to a conclusion on how this could be done, e.g. with
> preprocessed dts files or simpler dynamic patching of binary device
> trees?
>
I am working on it.
jdl
^ permalink raw reply
* Re: [RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()
From: Grant Likely @ 2008-08-14 16:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: miltonm, linuxppc-dev, paulus, scottwood
In-Reply-To: <9E78DE5E-7B94-4990-81CB-1EBF806923C1@kernel.crashing.org>
On Thu, Aug 14, 2008 at 10:24 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>> what happens if we run out of bats?
>>
>> Then it returns NULL and the caller must handle it. The board port
>> maintainer needs understand the board/CPU/SoC and not depend on more
>> BATs than are available. They also need to understand that there is a
>> tradeoff between BATs for IO and BATs for RAM. If the board port uses
>> up all the BATs for IO, then RAM above 256MB ends up getting mapped
>> with PTEs and there is a performance hit. My expectation is that only
>> platform code will use this facility. Device drivers should continue
>> to use ioremap() and will gain the benefit of the BATs if platform
>> code already set them up. I can add some text to the documentation to
>> describe this.
>>
>> I'm not going to make any attempt to fallback to PTEs for IO when
>> there isn't enough BATs. Doing so adds an order of magnitude more
>> complexity.
>
> that's fine.. I just didn't look at setbat() to see it errors out.
>
> Also can we get rid of LOAD_BAT in head_32.S?
Mostly. It is still needed for BAT0 when setting up RAM, but the rest
of it can be dumped.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/83xx: mpc836x_mds: add support for the nor flash
From: Anton Vorontsov @ 2008-08-14 17:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This patch adds the localbus node, moves the bcsr node into the
localbus node, and adds the flash node.
Also enable MTD support in the defconfig.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 23 ++++++-
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 79 ++++++++++++++++++++++-
2 files changed, 98 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
index a3b76a7..ada8446 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -52,9 +52,26 @@
reg = <0x00000000 0x10000000>;
};
- bcsr@f8000000 {
- device_type = "board-control";
- reg = <0xf8000000 0x8000>;
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
+ "simple-bus";
+ reg = <0xe0005000 0xd8>;
+ ranges = <0 0 0xfe000000 0x02000000
+ 1 0 0xf8000000 0x00008000>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x2000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ bcsr@1,0 {
+ device_type = "board-control";
+ reg = <1 0 0x8000>;
+ };
};
soc8360@e0000000 {
diff --git a/arch/powerpc/configs/83xx/mpc836x_mds_defconfig b/arch/powerpc/configs/83xx/mpc836x_mds_defconfig
index 20fd9f5..c76194b 100644
--- a/arch/powerpc/configs/83xx/mpc836x_mds_defconfig
+++ b/arch/powerpc/configs/83xx/mpc836x_mds_defconfig
@@ -357,7 +357,84 @@ CONFIG_PREVENT_FIRMWARE_BUILD=y
# CONFIG_FW_LOADER is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+# CONFIG_MTD_OF_PARTS is not set
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
# CONFIG_PARPORT is not set
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-14 17:21 UTC (permalink / raw)
Cc: linuxppc-dev, dwmw2, Arnd Bergmann
In-Reply-To: <20080814120829.1ad4ed74@lappy.seanm.ca>
Second version of patch with cleanups. Note that this patch is slightly
different.... I diffed the last patch against my master git rather than
Linus' master git :( The difference is that my git already had the
ports to arch/powerpc.
Cheers,
Sean
Port of the ndfc driver to an of platform driver.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 955959e..f09cd27 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -5,9 +5,13 @@
* Platform independend driver for NDFC (NanD Flash Controller)
* integrated into EP440 cores
*
+ * Ported to an OF platform driver by Sean MacLennan
+ *
* Author: Thomas Gleixner
*
* Copyright 2006 IBM
+ * Copyright 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -21,27 +25,17 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/ndfc.h>
#include <linux/mtd/mtd.h>
-#include <linux/platform_device.h>
-
+#include <linux/of_platform.h>
#include <asm/io.h>
-#ifdef CONFIG_40x
-#include <asm/ibm405.h>
-#else
-#include <asm/ibm44x.h>
-#endif
-
-struct ndfc_nand_mtd {
- struct mtd_info mtd;
- struct nand_chip chip;
- struct platform_nand_chip *pl_chip;
-};
-static struct ndfc_nand_mtd ndfc_mtd[NDFC_MAX_BANKS];
struct ndfc_controller {
- void __iomem *ndfcbase;
- struct nand_hw_control ndfc_control;
- atomic_t childs_active;
+ struct of_device *ofdev;
+ void __iomem *ndfcbase;
+ struct mtd_info mtd;
+ struct nand_chip chip;
+ int chip_select;
+ struct nand_hw_control ndfc_control;
};
static struct ndfc_controller ndfc_ctrl;
@@ -50,17 +44,14 @@ static void ndfc_select_chip(struct mtd_info *mtd, int chip)
{
uint32_t ccr;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct nand_chip *nandchip = mtd->priv;
- struct ndfc_nand_mtd *nandmtd = nandchip->priv;
- struct platform_nand_chip *pchip = nandmtd->pl_chip;
- ccr = __raw_readl(ndfc->ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc->ndfcbase + NDFC_CCR);
if (chip >= 0) {
ccr &= ~NDFC_CCR_BS_MASK;
- ccr |= NDFC_CCR_BS(chip + pchip->chip_offset);
+ ccr |= NDFC_CCR_BS(chip + ndfc->chip_select);
} else
ccr |= NDFC_CCR_RESET_CE;
- __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
}
static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
@@ -80,7 +71,7 @@ static int ndfc_ready(struct mtd_info *mtd)
{
struct ndfc_controller *ndfc = &ndfc_ctrl;
- return __raw_readl(ndfc->ndfcbase + NDFC_STAT) & NDFC_STAT_IS_READY;
+ return in_be32(ndfc->ndfcbase + NDFC_STAT) & NDFC_STAT_IS_READY;
}
static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
@@ -88,9 +79,9 @@ static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
uint32_t ccr;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- ccr = __raw_readl(ndfc->ndfcbase + NDFC_CCR);
+ ccr = in_be32(ndfc->ndfcbase + NDFC_CCR);
ccr |= NDFC_CCR_RESET_ECC;
- __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
wmb();
}
@@ -102,9 +93,10 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
uint8_t *p = (uint8_t *)&ecc;
wmb();
- ecc = __raw_readl(ndfc->ndfcbase + NDFC_ECC);
- ecc_code[0] = p[1];
- ecc_code[1] = p[2];
+ ecc = in_be32(ndfc->ndfcbase + NDFC_ECC);
+ /* The NDFC uses Smart Media (SMC) bytes order */
+ ecc_code[0] = p[2];
+ ecc_code[1] = p[1];
ecc_code[2] = p[3];
return 0;
@@ -123,7 +115,7 @@ static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- *p++ = __raw_readl(ndfc->ndfcbase + NDFC_DATA);
+ *p++ = in_be32(ndfc->ndfcbase + NDFC_DATA);
}
static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@ -132,7 +124,7 @@ static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- __raw_writel(*p++, ndfc->ndfcbase + NDFC_DATA);
+ out_be32(ndfc->ndfcbase + NDFC_DATA, *p++);
}
static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
@@ -141,7 +133,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
uint32_t *p = (uint32_t *) buf;
for(;len > 0; len -= 4)
- if (*p++ != __raw_readl(ndfc->ndfcbase + NDFC_DATA))
+ if (*p++ != in_be32(ndfc->ndfcbase + NDFC_DATA))
return -EFAULT;
return 0;
}
@@ -149,10 +141,19 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
/*
* Initialize chip structure
*/
-static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
+static int ndfc_chip_init(struct ndfc_controller *ndfc,
+ struct device_node *node)
{
- struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct nand_chip *chip = &mtd->chip;
+#ifdef CONFIG_MTD_PARTITIONS
+#ifdef CONFIG_MTD_CMDLINE_PARTS
+ static const char *part_types[] = { "cmdlinepart", NULL };
+#else
+ static const char *part_types[] = { NULL };
+#endif
+ struct mtd_partition *parts;
+#endif
+ struct nand_chip *chip = &ndfc->chip;
+ int ret;
chip->IO_ADDR_R = ndfc->ndfcbase + NDFC_DATA;
chip->IO_ADDR_W = ndfc->ndfcbase + NDFC_DATA;
@@ -160,8 +161,6 @@ static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
chip->dev_ready = ndfc_ready;
chip->select_chip = ndfc_select_chip;
chip->chip_delay = 50;
- chip->priv = mtd;
- chip->options = mtd->pl_chip->options;
chip->controller = &ndfc->ndfc_control;
chip->read_buf = ndfc_read_buf;
chip->write_buf = ndfc_write_buf;
@@ -172,143 +171,120 @@ static void ndfc_chip_init(struct ndfc_nand_mtd *mtd)
chip->ecc.mode = NAND_ECC_HW;
chip->ecc.size = 256;
chip->ecc.bytes = 3;
- chip->ecclayout = chip->ecc.layout = mtd->pl_chip->ecclayout;
- mtd->mtd.priv = chip;
- mtd->mtd.owner = THIS_MODULE;
-}
-
-static int ndfc_chip_probe(struct platform_device *pdev)
-{
- struct platform_nand_chip *nc = pdev->dev.platform_data;
- struct ndfc_chip_settings *settings = nc->priv;
- struct ndfc_controller *ndfc = &ndfc_ctrl;
- struct ndfc_nand_mtd *nandmtd;
-
- if (nc->chip_offset >= NDFC_MAX_BANKS || nc->nr_chips > NDFC_MAX_BANKS)
- return -EINVAL;
- /* Set the bank settings */
- __raw_writel(settings->bank_settings,
- ndfc->ndfcbase + NDFC_BCFG0 + (nc->chip_offset << 2));
+ ndfc->mtd.priv = chip;
+ ndfc->mtd.owner = THIS_MODULE;
- nandmtd = &ndfc_mtd[pdev->id];
- if (nandmtd->pl_chip)
- return -EBUSY;
+ ret = nand_scan(&ndfc->mtd, 1);
+ if (ret)
+ return ret;
- nandmtd->pl_chip = nc;
- ndfc_chip_init(nandmtd);
-
- /* Scan for chips */
- if (nand_scan(&nandmtd->mtd, nc->nr_chips)) {
- nandmtd->pl_chip = NULL;
- return -ENODEV;
- }
+ ndfc->mtd.name = ndfc->ofdev->dev.bus_id;
#ifdef CONFIG_MTD_PARTITIONS
- printk("Number of partitions %d\n", nc->nr_partitions);
- if (nc->nr_partitions) {
- /* Add the full device, so complete dumps can be made */
- add_mtd_device(&nandmtd->mtd);
- add_mtd_partitions(&nandmtd->mtd, nc->partitions,
- nc->nr_partitions);
-
- } else
-#else
- add_mtd_device(&nandmtd->mtd);
+ ret = parse_mtd_partitions(&ndfc->mtd, part_types, &parts, 0);
+ if (ret < 0)
+ return ret;
+
+#ifdef CONFIG_MTD_OF_PARTS
+ if (ret == 0) {
+ ret = of_mtd_parse_partitions(&ndfc->ofdev->dev, &ndfc->mtd,
+ node, &parts);
+ if (ret < 0)
+ return ret;
+ }
#endif
- atomic_inc(&ndfc->childs_active);
- return 0;
-}
+ if (ret > 0)
+ return add_mtd_partitions(&ndfc->mtd, parts, ret);
+#endif
-static int ndfc_chip_remove(struct platform_device *pdev)
-{
- return 0;
+ return add_mtd_device(&ndfc->mtd);
}
-static int ndfc_nand_probe(struct platform_device *pdev)
+static int __devinit ndfc_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
{
- struct platform_nand_ctrl *nc = pdev->dev.platform_data;
- struct ndfc_controller_settings *settings = nc->priv;
- struct resource *res = pdev->resource;
struct ndfc_controller *ndfc = &ndfc_ctrl;
- unsigned long long phys = settings->ndfc_erpn | res->start;
+ const u32 *reg;
+ u32 ccr;
+ int err, len;
-#ifndef CONFIG_PHYS_64BIT
- ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
-#else
- ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
-#endif
+ spin_lock_init(&ndfc->ndfc_control.lock);
+ init_waitqueue_head(&ndfc->ndfc_control.wq);
+ ndfc->ofdev = ofdev;
+ dev_set_drvdata(&ofdev->dev, ndfc);
+
+ /* Read the reg property to get the chip select */
+ reg = of_get_property(ofdev->node, "reg", &len);
+ if (reg == NULL || len != 12) {
+ dev_err(&ofdev->dev, "unable read reg property (%d)\n", len);
+ return -ENOENT;
+ }
+ ndfc->chip_select = reg[0];
+
+ ndfc->ndfcbase = ioremap(reg[1], reg[2]);
if (!ndfc->ndfcbase) {
- printk(KERN_ERR "NDFC: ioremap failed\n");
+ dev_err(&ofdev->dev, "failed to get memory\n");
return -EIO;
}
- __raw_writel(settings->ccr_settings, ndfc->ndfcbase + NDFC_CCR);
+ ccr = NDFC_CCR_BS(ndfc->chip_select);
- spin_lock_init(&ndfc->ndfc_control.lock);
- init_waitqueue_head(&ndfc->ndfc_control.wq);
+ /* It is ok if ccr does not exist - just default to 0 */
+ reg = of_get_property(ofdev->node, "ccr", NULL);
+ if (reg)
+ ccr |= *reg;
+
+ out_be32(ndfc->ndfcbase + NDFC_CCR, ccr);
- platform_set_drvdata(pdev, ndfc);
+ /* Set the bank settings if given */
+ reg = of_get_property(ofdev->node, "bank-settings", NULL);
+ if (reg) {
+ int offset = NDFC_BCFG0 + (ndfc->chip_select << 2);
+ out_be32(ndfc->ndfcbase + offset, *reg);
+ }
- printk("NDFC NAND Driver initialized. Chip-Rev: 0x%08x\n",
- __raw_readl(ndfc->ndfcbase + NDFC_REVID));
+ err = ndfc_chip_init(ndfc, ofdev->node);
+ if (err) {
+ iounmap(ndfc->ndfcbase);
+ return err;
+ }
return 0;
}
-static int ndfc_nand_remove(struct platform_device *pdev)
+static int __devexit ndfc_remove(struct of_device *ofdev)
{
- struct ndfc_controller *ndfc = platform_get_drvdata(pdev);
+ struct ndfc_controller *ndfc = dev_get_drvdata(&ofdev->dev);
- if (atomic_read(&ndfc->childs_active))
- return -EBUSY;
+ nand_release(&ndfc->mtd);
- if (ndfc) {
- platform_set_drvdata(pdev, NULL);
- iounmap(ndfc_ctrl.ndfcbase);
- ndfc_ctrl.ndfcbase = NULL;
- }
return 0;
}
-/* driver device registration */
-
-static struct platform_driver ndfc_chip_driver = {
- .probe = ndfc_chip_probe,
- .remove = ndfc_chip_remove,
- .driver = {
- .name = "ndfc-chip",
- .owner = THIS_MODULE,
- },
+static const struct of_device_id ndfc_match[] = {
+ { .compatible = "amcc,ndfc", },
+ {}
};
-static struct platform_driver ndfc_nand_driver = {
- .probe = ndfc_nand_probe,
- .remove = ndfc_nand_remove,
- .driver = {
- .name = "ndfc-nand",
- .owner = THIS_MODULE,
+static struct of_platform_driver ndfc_driver = {
+ .driver = {
+ .name = "ndfc",
},
+ .match_table = ndfc_match,
+ .probe = ndfc_probe,
+ .remove = __devexit_p(ndfc_remove),
};
static int __init ndfc_nand_init(void)
{
- int ret;
-
- spin_lock_init(&ndfc_ctrl.ndfc_control.lock);
- init_waitqueue_head(&ndfc_ctrl.ndfc_control.wq);
-
- ret = platform_driver_register(&ndfc_nand_driver);
- if (!ret)
- ret = platform_driver_register(&ndfc_chip_driver);
- return ret;
+ return of_register_platform_driver(&ndfc_driver);
}
static void __exit ndfc_nand_exit(void)
{
- platform_driver_unregister(&ndfc_chip_driver);
- platform_driver_unregister(&ndfc_nand_driver);
+ of_unregister_platform_driver(&ndfc_driver);
}
module_init(ndfc_nand_init);
@@ -316,6 +292,4 @@ module_exit(ndfc_nand_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Thomas Gleixner <tglx@linutronix.de>");
-MODULE_DESCRIPTION("Platform driver for NDFC");
-MODULE_ALIAS("platform:ndfc-chip");
-MODULE_ALIAS("platform:ndfc-nand");
+MODULE_DESCRIPTION("OF Platform driver for NDFC");
^ permalink raw reply related
* Re: [PATCH v3] libfdt: Add support for using aliases in fdt_path_offset()
From: Scott Wood @ 2008-08-14 17:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, devicetree-discuss, David Gibson
In-Reply-To: <Pine.LNX.4.64.0808140827220.2701@blarg.am.freescale.net>
On Thu, Aug 14, 2008 at 08:28:19AM -0500, Kumar Gala wrote:
> - if (*path != '/')
> - return -FDT_ERR_BADPATH;
> + /* see if we have an alias */
> + if (*path != '/') {
> + const char *q;
> + int aliasoffset = fdt_path_offset(fdt, "/aliases");
> +
> + if (aliasoffset < 0)
> + return -FDT_ERR_BADPATH;
> +
> + q = strchr(path, '/');
> + if (!q)
> + q = end;
> +
> + p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
> + if (!p)
> + return -FDT_ERR_BADPATH;
> + offset = fdt_path_offset(fdt, p);
> +
> + p = q;
> + }
Can we limit the recursion depth to avoid falling off the stack if an
alias points to itself? Or if aliases pointing to aliases are
disallowed, check for a leading '/' before recursively calling
fdt_path_offset.
-Scott
^ permalink raw reply
* oops in proc_sys_compare
From: Hugh Dickins @ 2008-08-14 18:31 UTC (permalink / raw)
To: Al Viro; +Cc: linuxppc-dev, linux-kernel
I got this oops below, after several hours of swap-heavy kernel builds
in tmpfs, on 2.6.27-rc1-mm1 a couple of weeks ago. Tried to reproduce
it without success, then got a very similar trace (not saved) from
2.6.27-rc3 itself doing the same test yesterday: again oopsing in
proc_sys_compare on address -16, looks like it's trying for
PROC_I(dentry->d_inode)->sysctl but d_inode is NULL.
I looked to see what's been going on in fs/proc recently, and your
[PATCH] sanitize proc_sysctl 9043476f726802f4b00c96d0c4f418dde48d1304
does sound like it might be implicated. I've only seen this on
PowerPC G5, similar tests on x86_32 and _64 haven't shown it:
maybe a memory barrier needed somewhere?
Hugh
Unable to handle kernel paging request for data at address 0xfffffffffffffff0
Faulting instruction address: 0xc000000000121ec4
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=4 PowerMac
Modules linked in:
NIP: c000000000121ec4 LR: c000000000121eb4 CTR: 0000000000000000
REGS: c000000002af33f0 TRAP: 0300 Not tainted (2.6.27-rc1-mm1)
MSR: 9000000000009032 <EE,ME,IR,DR> CR: 24222482 XER: 00000000
DAR: fffffffffffffff0, DSISR: 0000000040000000
TASK = c000000002d22500[26561] 'sh' THREAD: c000000002af0000 CPU: 3
GPR00: 0000000000000078 c000000002af3670 c0000000005cf520 0000000000000000
GPR04: c0000000021ba01b 000000000000000b c000000015e63596 c0000000021ba011
GPR08: 0001f59632fdb346 0000000000000000 000000000001ffff 0000000000000000
GPR12: 0000000020222424 c0000000005ec800 0000000000000000 0000000000000000
GPR16: 00000000200be41c 0000000000000000 c000000002af38d0 c000000002af38b0
GPR20: c000000002af38c0 c000000002af3bf8 0000000000000101 0000000000000024
GPR24: c0000000021ba011 0000000032fdb346 000000000000000b c000000002af38c0
GPR28: c000000015e634f8 c000000015e634e0 c000000000562498 c000000015e63510
NIP [c000000000121ec4] .proc_sys_compare+0x48/0x7c
LR [c000000000121eb4] .proc_sys_compare+0x38/0x7c
Call Trace:
[c000000002af3670] [c000000000522620] root_table_header+0x0/0x58 (unreliable)
[c000000002af36f0] [c0000000000dabdc] .__d_lookup+0xf4/0x1f0
[c000000002af37a0] [c0000000000d0978] .do_lookup+0x38/0x128
[c000000002af3840] [c0000000000d1438] .__link_path_walk+0x9d0/0xf30
[c000000002af3950] [c0000000000d19f0] .path_walk+0x58/0xc4
[c000000002af3a00] [c0000000000d1b94] .do_path_lookup+0x138/0x17c
[c000000002af3ab0] [c0000000000d1cc8] .__path_lookup_intent_open+0x78/0xdc
[c000000002af3b60] [c0000000000d2960] .do_filp_open+0xcc/0x764
[c000000002af3d00] [c0000000000c5454] .do_sys_open+0x80/0x14c
[c000000002af3db0] [c000000000108378] .compat_sys_open+0x24/0x38
[c000000002af3e30] [c0000000000076ac] syscall_exit+0x0/0x40
Instruction dump:
60000000 80a40004 80090004 7f802800 409e003c e8890008 e87f0008 4bf0aa45
60000000 2fa30000 409e0024 e93fffe0 <e869fff0> 4bf2f84d 60000000 7c630034
---[ end trace ac14ee183d55eec5 ]---
^ permalink raw reply
* Re: [RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()
From: Kumar Gala @ 2008-08-14 19:59 UTC (permalink / raw)
To: Grant Likely; +Cc: miltonm, linuxppc-dev, paulus, scottwood
In-Reply-To: <fa686aa40808140943v218d826p9ac6dc683a5ccff4@mail.gmail.com>
On Aug 14, 2008, at 11:43 AM, Grant Likely wrote:
> On Thu, Aug 14, 2008 at 10:24 AM, Kumar Gala <galak@kernel.crashing.org
> > wrote:
>>>> what happens if we run out of bats?
>>>
>>> Then it returns NULL and the caller must handle it. The board port
>>> maintainer needs understand the board/CPU/SoC and not depend on more
>>> BATs than are available. They also need to understand that there
>>> is a
>>> tradeoff between BATs for IO and BATs for RAM. If the board port
>>> uses
>>> up all the BATs for IO, then RAM above 256MB ends up getting mapped
>>> with PTEs and there is a performance hit. My expectation is that
>>> only
>>> platform code will use this facility. Device drivers should
>>> continue
>>> to use ioremap() and will gain the benefit of the BATs if platform
>>> code already set them up. I can add some text to the
>>> documentation to
>>> describe this.
>>>
>>> I'm not going to make any attempt to fallback to PTEs for IO when
>>> there isn't enough BATs. Doing so adds an order of magnitude more
>>> complexity.
>>
>> that's fine.. I just didn't look at setbat() to see it errors out.
>>
>> Also can we get rid of LOAD_BAT in head_32.S?
>
> Mostly. It is still needed for BAT0 when setting up RAM, but the rest
> of it can be dumped.
Can we not do BAT0 in C code?
- k
^ permalink raw reply
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Arnd Bergmann @ 2008-08-14 20:16 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <20080814120829.1ad4ed74@lappy.seanm.ca>
On Thursday 14 August 2008, Sean MacLennan wrote:
> On Thu, 14 Aug 2008 11:53:07 +0200
> "Arnd Bergmann" <arnd@arndb.de> wrote:
>
> > > + ndfc->ndfcbase = ioremap(reg[1], reg[2]);
> >
> > This could be better expressed as of_iomap().
>
> I tried of_iomap(), but it doesn't seem to like the 3 value reg. i.e.
> It doesn't skip the chip select. And since I need to read the reg
> property to get the chip select any way, I just used the value directly.
If of_iomap and of_address_to_resource don't work properly, there
is probably something wrong in your device tree, maybe an incorrect
#size-cells or #address-cells or ranges property in one of
the parents. You need to fix this anyway.
> > > - platform_set_drvdata(pdev, ndfc);
> > > + __raw_writel(ccr, ndfc->ndfcbase + NDFC_CCR);
> > >
> > > - printk("NDFC NAND Driver initialized. Chip-Rev: 0x%08x\n",
> > > - __raw_readl(ndfc->ndfcbase + NDFC_REVID));
> > > + /* Set the bank settings */
> > > + reg = of_get_property(ofdev->node, "bank_settings", NULL);
> > > + bank_settings = reg ? *reg : 0x80002222;
> >
> > Your device tree does have a bank_setting, so why not assume that
> > all others will have it as well? I would remove the default.
>
> I am thinking of making the bank settings an optional value. I assume
> most people with 44x chips with NAND will be using u-boot. If you
> enable NAND in u-boot, it should configure the bank settings for you.
>
> I put the bank setting in my dts just to show a "complete"
> configuration.
Ok, I guess that in the absence of the property, you should not do anything
with this value then, rather than assuming a default.
Arnd <><
^ permalink raw reply
* __attribute_used__ in 2.6.24
From: Kevin Diggs @ 2008-08-14 20:33 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Something in a function signature called "__attribute_used__" would
compile in 2.6.24. This does not compile in 2.6.26. Using the
"store_##NAME" template from arch/powerpc/kernel/sysfs.c as a guide,
this appears to have changed to "__used". Anything work in both?
"__used" seems to have compiled in 2.6.24?
kevin
^ permalink raw reply
* Re: [RFC/PATCH v2] powerpc: add ioremap_early() function for mapping IO regions before MMU_init()
From: Grant Likely @ 2008-08-14 20:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: miltonm, linuxppc-dev, paulus, scottwood
In-Reply-To: <4A0D4C49-48F8-4E0D-9C42-EB0503EA4BCB@kernel.crashing.org>
On Thu, Aug 14, 2008 at 1:59 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Aug 14, 2008, at 11:43 AM, Grant Likely wrote:
>
>> On Thu, Aug 14, 2008 at 10:24 AM, Kumar Gala <galak@kernel.crashing.org>
>> wrote:
>>>>>
>>>>> what happens if we run out of bats?
>>>>
>>>> Then it returns NULL and the caller must handle it. The board port
>>>> maintainer needs understand the board/CPU/SoC and not depend on more
>>>> BATs than are available. They also need to understand that there is a
>>>> tradeoff between BATs for IO and BATs for RAM. If the board port uses
>>>> up all the BATs for IO, then RAM above 256MB ends up getting mapped
>>>> with PTEs and there is a performance hit. My expectation is that only
>>>> platform code will use this facility. Device drivers should continue
>>>> to use ioremap() and will gain the benefit of the BATs if platform
>>>> code already set them up. I can add some text to the documentation to
>>>> describe this.
>>>>
>>>> I'm not going to make any attempt to fallback to PTEs for IO when
>>>> there isn't enough BATs. Doing so adds an order of magnitude more
>>>> complexity.
>>>
>>> that's fine.. I just didn't look at setbat() to see it errors out.
>>>
>>> Also can we get rid of LOAD_BAT in head_32.S?
>>
>> Mostly. It is still needed for BAT0 when setting up RAM, but the rest
>> of it can be dumped.
>
> Can we not do BAT0 in C code?
Not easily. Currently BAT0 gives us the first 16M of RAM during early
boot. The new code protects BAT0 and makes sure it can only be used
for mapping RAM. If it got chosen for an IO mapping, then it would
get blown away immediately and the kernel would crash. Its okay for
BAT0 to be used for RAM because RAM doesn't need to be immediately
mapped. It can wait just setup the data and wait for LOAD_BAT to fix
it up.
An alternate solution is to reserve a second BAT higher up to use as
the 'real' RAM mapping so that 'real' mapping of RAM could be
performed immediately while leaving the old one intact. That would
eliminate the need for LOAD_BAT, but it also leaves only 2 BAT slots
available for IO and memory above 256M. On the other hand, it might
be okay to release the reserved BATs after the first real RAM mapping
is established, but doing so adds some complexity to the handling of
__map_without_bats because the initial mapping still needs to be
disabled in head_32.S.
g.
^ permalink raw reply
* Re: [PATCH 1/2] port ndfc driver to of platform
From: Sean MacLennan @ 2008-08-14 20:54 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, dwmw2
In-Reply-To: <200808142216.45763.arnd@arndb.de>
On Thu, 14 Aug 2008 22:16:45 +0200
"Arnd Bergmann" <arnd@arndb.de> wrote:
> If of_iomap and of_address_to_resource don't work properly, there
> is probably something wrong in your device tree, maybe an incorrect
> #size-cells or #address-cells or ranges property in one of
> the parents. You need to fix this anyway.
Gahhhh, no my dts is wrong. I must have looked at it a dozen times
before I clued in that now that ndfc is a proper of driver I need to
specify the chip select and the *offset*, not the chip select and the
*address*.
New patches soon.
Cheers,
Sean
^ 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