* dtc: Don't delete *.test.dtb between testgroups
From: David Gibson @ 2007-10-16 3:53 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The dtc/libfdt testsuite creates a number of .dtb files during its
run. To ensure a clean test run, these are currently deleted before
each group of tests.
This is, in fact, a mistake, since if something goes wrong in the
first group of tests, deleting the .dtb at the beginning of the second
group of tests makes it harder to figure out what the problem was.
This patch changes the script to only delete the files once, before
the whole test run.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-10-12 15:09:43.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-10-12 15:10:13.000000000 +1000
@@ -60,9 +60,6 @@ tree1_tests_rw () {
}
libfdt_tests () {
- # Make sure we don't have stale blobs lying around
- rm -f *.test.dtb
-
tree1_tests test_tree1.dtb
# Sequential write tests
@@ -102,9 +99,6 @@ libfdt_tests () {
}
dtc_tests () {
- # Make sure we don't have stale blobs lying around
- rm -f *.test.dtb
-
run_test dtc.sh -f -I dts -O dtb -o dtc_tree1.test.dtb test_tree1.dts
tree1_tests dtc_tree1.test.dtb
tree1_tests_rw dtc_tree1.test.dtb
@@ -125,6 +119,9 @@ if [ -z "$TESTSETS" ]; then
TESTSETS="libfdt dtc"
fi
+# Make sure we don't have stale blobs lying around
+rm -f *.test.dtb
+
for set in $TESTSETS; do
case $set in
"libfdt")
--
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
* libfdt: Add functions for handling the "compatible" property
From: David Gibson @ 2007-10-16 3:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch adds functions for dealing with the compatible property.
fdt_node_check_compatible() can be used to determine whether a node is
compatible with a given string and fdt_node_offset_by_compatible()
locates nodes with a given compatible string.
Testcases for these functions are also included.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-10-12 15:09:27.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-10-12 15:10:39.000000000 +1000
@@ -477,3 +477,86 @@ int fdt_node_offset_by_prop_value(const
return -FDT_ERR_NOTFOUND;
}
+
+int _stringlist_contains(const void *strlist, int listlen, const char *str)
+{
+ int len = strlen(str);
+ const void *p;
+
+ while (listlen >= len) {
+ if (memcmp(str, strlist, len+1) == 0)
+ return 1;
+ p = memchr(strlist, '\0', listlen);
+ if (!p)
+ return 0; /* malformed strlist.. */
+ listlen -= (p-strlist) + 1;
+ strlist = p + 1;
+ }
+ return 0;
+}
+
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+ const char *compatible)
+{
+ const void *prop;
+ int len;
+
+ prop = fdt_getprop(fdt, nodeoffset, "compatible", &len);
+ if (!prop)
+ return len;
+ if (_stringlist_contains(prop, len, compatible))
+ return 0;
+ else
+ return 1;
+}
+
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+ const char *compatible)
+{
+ uint32_t tag;
+ int offset, nextoffset;
+ int err;
+
+ CHECK_HEADER(fdt);
+
+ if (startoffset >= 0) {
+ tag = _fdt_next_tag(fdt, startoffset, &nextoffset);
+ if (tag != FDT_BEGIN_NODE)
+ return -FDT_ERR_BADOFFSET;
+ } else {
+ nextoffset = 0;
+ }
+
+ /* FIXME: The algorithm here is pretty horrible: we scan each
+ * property of a node in fdt_node_check_compatible(), then if
+ * that didn't find what we want, we scan over them again
+ * making our way to the next node. Still it's the easiest to
+ * implement approach; performance can come later. */
+ do {
+ offset = nextoffset;
+ tag = _fdt_next_tag(fdt, offset, &nextoffset);
+
+ switch (tag) {
+ case FDT_BEGIN_NODE:
+ err = fdt_node_check_compatible(fdt, offset,
+ compatible);
+ if ((err < 0)
+ && (err != -FDT_ERR_NOTFOUND))
+ return err;
+ else if (err == 0)
+ return offset;
+ break;
+
+ case FDT_PROP:
+ case FDT_END:
+ case FDT_END_NODE:
+ case FDT_NOP:
+ break;
+
+ default:
+ return -FDT_ERR_BADSTRUCTURE;
+ }
+ } while (tag != FDT_END);
+
+ return -FDT_ERR_NOTFOUND;
+}
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-10-12 15:09:27.000000000 +1000
+++ dtc/tests/trees.S 2007-10-12 15:10:39.000000000 +1000
@@ -83,13 +83,16 @@ test_tree1_rsvmap:
test_tree1_struct:
BEGIN_NODE("")
+ PROP_STR(test_tree1, compatible, "test_tree1")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
PROP_STR(test_tree1, prop_str, TEST_STRING_1)
BEGIN_NODE("subnode@1")
+ PROP_STR(test_tree1, compatible, "subnode1")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
BEGIN_NODE("subsubnode")
+ PROP_STR(test_tree1, compatible, "subsubnode1\0subsubnode")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
END_NODE
END_NODE
@@ -98,6 +101,7 @@ test_tree1_struct:
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
BEGIN_NODE("subsubnode@0")
+ PROP_STR(test_tree1, compatible, "subsubnode2\0subsubnode")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
END_NODE
@@ -106,6 +110,7 @@ test_tree1_struct:
FDTLONG(FDT_END)
test_tree1_strings:
+ STRING(test_tree1, compatible, "compatible")
STRING(test_tree1, prop_int, "prop-int")
STRING(test_tree1, prop_str, "prop-str")
test_tree1_end:
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-10-12 15:09:27.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-10-12 15:10:39.000000000 +1000
@@ -2,6 +2,7 @@ LIB_TESTS_L = get_mem_rsv \
root_node find_property subnode_offset path_offset \
get_name getprop get_path supernode_atdepth_offset parent_offset \
node_offset_by_prop_value \
+ node_check_compatible node_offset_by_compatible \
notfound \
setprop_inplace nop_property nop_node \
sw_tree1 \
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-10-12 15:10:13.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-10-12 15:10:39.000000000 +1000
@@ -42,6 +42,8 @@ tree1_tests () {
run_test supernode_atdepth_offset $TREE
run_test parent_offset $TREE
run_test node_offset_by_prop_value $TREE
+ run_test node_check_compatible $TREE
+ run_test node_offset_by_compatible $TREE
run_test notfound $TREE
# Write-in-place tests
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-10-12 15:09:27.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-10-12 15:10:39.000000000 +1000
@@ -153,6 +153,11 @@ int fdt_node_offset_by_prop_value(const
const char *propname,
const void *propval, int proplen);
+int fdt_node_check_compatible(const void *fdt, int nodeoffset,
+ const char *compatible);
+int fdt_node_offset_by_compatible(const void *fdt, int startoffset,
+ const char *compatible);
+
/* Write-in-place functions */
int fdt_setprop_inplace(void *fdt, int nodeoffset, const char *name,
const void *val, int len);
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-10-12 15:09:27.000000000 +1000
+++ dtc/tests/rw_tree1.c 2007-10-12 15:10:39.000000000 +1000
@@ -72,18 +72,23 @@ int main(int argc, char *argv[])
CHECK(fdt_add_mem_rsv(fdt, TEST_ADDR_1, TEST_SIZE_1));
CHECK(fdt_add_mem_rsv(fdt, TEST_ADDR_2, TEST_SIZE_2));
+ CHECK(fdt_setprop_string(fdt, 0, "compatible", "test_tree1"));
CHECK(fdt_setprop_typed(fdt, 0, "prop-int", TEST_VALUE_1));
CHECK(fdt_setprop_string(fdt, 0, "prop-str", TEST_STRING_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
+ CHECK(fdt_setprop_string(fdt, offset, "compatible", "subnode1"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
+ CHECK(fdt_setprop(fdt, offset, "compatible",
+ "subsubnode1\0subsubnode", 23));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@2"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
-
+ CHECK(fdt_setprop(fdt, offset, "compatible",
+ "subsubnode2\0subsubnode", 23));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
CHECK(fdt_pack(fdt));
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-10-12 15:09:27.000000000 +1000
+++ dtc/tests/sw_tree1.c 2007-10-12 15:10:39.000000000 +1000
@@ -54,12 +54,17 @@ int main(int argc, char *argv[])
CHECK(fdt_finish_reservemap(fdt));
CHECK(fdt_begin_node(fdt, ""));
+ CHECK(fdt_property_string(fdt, "compatible", "test_tree1"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_property_string(fdt, "prop-str", TEST_STRING_1));
CHECK(fdt_begin_node(fdt, "subnode@1"));
+ CHECK(fdt_property_string(fdt, "compatible", "subnode1"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
+ CHECK(fdt_property(fdt, "compatible", "subsubnode1\0subsubnode",
+ 23));
+ CHECK(fdt_property_string(fdt, "compatible", "subsubnode1\0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
@@ -67,6 +72,8 @@ int main(int argc, char *argv[])
CHECK(fdt_begin_node(fdt, "subnode@2"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_begin_node(fdt, "subsubnode@0"));
+ CHECK(fdt_property(fdt, "compatible", "subsubnode2\0subsubnode",
+ 23));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/test_tree1.dts
===================================================================
--- dtc.orig/tests/test_tree1.dts 2007-10-12 15:09:27.000000000 +1000
+++ dtc/tests/test_tree1.dts 2007-10-12 15:10:39.000000000 +1000
@@ -2,13 +2,16 @@
/memreserve/ abcd1234 00001234;
/ {
+ compatible = "test_tree1";
prop-int = <deadbeef>;
prop-str = "hello world";
subnode@1 {
+ compatible = "subnode1";
prop-int = <deadbeef>;
subsubnode {
+ compatible = "subsubnode1", "subsubnode";
prop-int = <deadbeef>;
};
};
@@ -17,6 +20,7 @@
prop-int = <abcd1234>;
subsubnode@0 {
+ compatible = "subsubnode2", "subsubnode";
prop-int = <abcd1234>;
};
};
Index: dtc/tests/node_offset_by_compatible.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/node_offset_by_compatible.c 2007-10-12 15:22:40.000000000 +1000
@@ -0,0 +1,86 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_node_offset_by_compatible()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * 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 <stdarg.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+void check_search(void *fdt, const char *compat, ...)
+{
+ va_list ap;
+ int offset = -1, target;
+
+ va_start(ap, compat);
+ do {
+ target = va_arg(ap, int);
+ verbose_printf("Searching (target = %d): %d ->",
+ target, offset);
+ offset = fdt_node_offset_by_compatible(fdt, offset, compat);
+ verbose_printf("%d\n", offset);
+
+ if (offset != target)
+ FAIL("fdt_node_offset_by_compatible(%s) returns %d "
+ "instead of %d", compat, offset, target);
+ } while (target >= 0);
+
+ va_end(ap);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int subnode1_offset, subnode2_offset;
+ int subsubnode1_offset, subsubnode2_offset;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
+ subsubnode1_offset = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
+
+ if ((subnode1_offset < 0) || (subnode2_offset < 0)
+ || (subsubnode1_offset < 0) || (subsubnode2_offset < 0))
+ FAIL("Can't find required nodes");
+
+ check_search(fdt, "test_tree1", 0, -FDT_ERR_NOTFOUND);
+ check_search(fdt, "subnode1", subnode1_offset, -FDT_ERR_NOTFOUND);
+ check_search(fdt, "subsubnode1", subsubnode1_offset, -FDT_ERR_NOTFOUND);
+ check_search(fdt, "subsubnode2", subsubnode2_offset, -FDT_ERR_NOTFOUND);
+ /* Eek.. HACK to make this work whatever the order in the
+ * example tree */
+ if (subsubnode1_offset < subsubnode2_offset)
+ check_search(fdt, "subsubnode", subsubnode1_offset,
+ subsubnode2_offset, -FDT_ERR_NOTFOUND);
+ else
+ check_search(fdt, "subsubnode", subsubnode2_offset,
+ subsubnode1_offset, -FDT_ERR_NOTFOUND);
+ check_search(fdt, "nothing-like-this", -FDT_ERR_NOTFOUND);
+
+ PASS();
+}
--
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: [PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx
From: Grant Likely @ 2007-10-16 4:21 UTC (permalink / raw)
To: Grant Likely, Scott Wood, Jean Delvare, linuxppc-dev,
Stefan Roese, i2c
In-Reply-To: <20071016032041.GN26787@localhost.localdomain>
On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> As the inventor of "linux,network-index", please don't invent
> "linux,i2c-index". linux,network-index was and is a hack - it's
> badness is limited by the fact that it's essentially local to the
> bootwrapper. It's only used in the bootwrapper, and I only really
> intended it for use in bootwrappers which provide their own device
> tree, so as to match the device nodes against whatever order the MAC
> addresses were supplied by the firmware.
>
> I plan to replace the linux,network-index thing with aliases
> (including some dtc support to make that easy) just as soon as I get
> around to it... don't hold your breath.
>
> Using a similar property from an actual kernel driver would be much
> uglier, and harder to clean up later.
This I know from first hand experience; it is Uh-gly! :-)
>
> Using aliases would be.. less bad, but it would still require that
> the device tree always supply an alias for the iic driver to work
> which is kind of nasty.
>
> In fact I think it may be acceptle to do the idx++ thing in this
> situation. Bus numbers are ugly, but it's not the worst ugliness in
> the horrible mess that is the Linux i2c subsystem. It means that bus
> numbers are theoretically unstable, but that's increasingly true of
> devices of all sorts - it's up to udev to assign meaningful labels at
> the user level.
I think the real problem here comes into play when there are 2 types
of i2c busses in the system. If they both maintain their own idx++
values; then they will conflict. If an auto assigned bus number is
used; then it needs to be assigned by the i2c infrastructure; not by
the driver.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Stefan Roese @ 2007-10-16 4:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <7DBC0977-0367-40F5-8A30-ACA02FD4E9FA@kernel.crashing.org>
Hi Kumar,
On Tuesday 16 October 2007, Kumar Gala wrote:
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
> * TQM 85xx
> * SBC 8560
>
> I'm told WR doesn't care about the SBC 8560, so I'll see if David does.
>
> I'm willing to look into doing the port over, but would need some
> help testing.
Yes, it would be greatly appreciated if you could start this TQM85xx port. I
will of course do the testing.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Merge dtc
From: David Gibson @ 2007-10-16 5:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This very large patch incorporates a copy of dtc into the kernel
source, in arch/powerpc/boot/dtc-src. This means that dtc is no
longer an external dependency to build kernels with configurations
which need a dtb file.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Too big for the list, full patch at
http://ozlabs.org/~dgibson/home/merge-dtc.patch
--
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: boards in arch/ppc -> arch/powerpc for 85xx
From: Kumar Gala @ 2007-10-16 5:06 UTC (permalink / raw)
To: Stefan Roese; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <200710160640.47010.sr@denx.de>
On Oct 15, 2007, at 11:40 PM, Stefan Roese wrote:
> Hi Kumar,
>
> On Tuesday 16 October 2007, Kumar Gala wrote:
>> I was wondering if you cared about the following boards existing in
>> arch/powerpc:
>>
>> * STX GP3
>> * TQM 85xx
>> * SBC 8560
>>
>> I'm told WR doesn't care about the SBC 8560, so I'll see if David
>> does.
>>
>> I'm willing to look into doing the port over, but would need some
>> help testing.
>
> Yes, it would be greatly appreciated if you could start this
> TQM85xx port. I
> will of course do the testing.
Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
1. what processors does this actually support/run on. I'm guessing
MPC8541, MPC8555? But not really sure
2. can you send the results of a bd_info from u-boot on the board
3. can you send me the results of cat /proc/iomem & /proc/ioports
from a linux boot.
thanks
- k
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 5:08 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071016050217.GA9052@localhost.localdomain>
On Oct 16, 2007, at 12:02 AM, David Gibson wrote:
> This very large patch incorporates a copy of dtc into the kernel
> source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> longer an external dependency to build kernels with configurations
> which need a dtb file.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Too big for the list, full patch at
> http://ozlabs.org/~dgibson/home/merge-dtc.patch
Dare I ask why we are including dtc in the kernel source tree? We
don't really have precedence for this and there are users outside of
linux for dtc.
- k
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Dan Malek @ 2007-10-16 4:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Stefan Roese, David Woodhouse
In-Reply-To: <7DBC0977-0367-40F5-8A30-ACA02FD4E9FA@kernel.crashing.org>
On Oct 15, 2007, at 7:07 PM, Kumar Gala wrote:
> I was wondering if you cared about the following boards existing in
> arch/powerpc:
>
> * STX GP3
I have GP3 and GP3-SSA for testing.
If you can make a first pass at the changes
I'll debug and finish.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] mpc8349emitx(gp): add UHCI support and other misc defconfig changes
From: Kumar Gala @ 2007-10-16 5:18 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20071015163324.8520.3528.stgit@trillian.cg.shawcable.net>
On Oct 15, 2007, at 11:33 AM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> USB support for the 8349itx got added a while back; but the defconfig
> never got updated. This patch updates defconfig and adds the
> appropriate
> USB config options.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> CC: Scott Wood <scottwood@freescale.com>
> CC: Kumar Gala <galak@kernel.crashing.org>
> CC: Timur Tabi <timur@freescale.com>
> ---
>
> arch/powerpc/configs/mpc834x_itx_defconfig | 87 ++++++++----
> arch/powerpc/configs/mpc834x_itxgp_defconfig | 190 +++++++++++++++
> +++++++----
> 2 files changed, 224 insertions(+), 53 deletions(-)
Can you limit this to the USB support? The other changes like
enabling SLUB, and PRINTK_TIME, should really be clearly documented
and discussed some.
- k
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-16 5:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <B17BEF48-34FC-44E0-AC23-1DB7522EB198@kernel.crashing.org>
On Tue, Oct 16, 2007 at 12:08:06AM -0500, Kumar Gala wrote:
>
> On Oct 16, 2007, at 12:02 AM, David Gibson wrote:
>
> > This very large patch incorporates a copy of dtc into the kernel
> > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > longer an external dependency to build kernels with configurations
> > which need a dtb file.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> >
> > Too big for the list, full patch at
> > http://ozlabs.org/~dgibson/home/merge-dtc.patch
>
> Dare I ask why we are including dtc in the kernel source tree? We
Well, we aren't unless Paul merges it..
> don't really have precedence for this and there are users outside of
> linux for dtc.
Because having dtc as an external dependency is inconvenient. This is
supposed to remain an embedded copy of dtc, not become the main dtc
repository.
--
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: boards in arch/ppc -> arch/powerpc for 85xx
From: Stefan Roese @ 2007-10-16 5:28 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <B9E8682B-5455-48EA-B078-CB0EDCB2060A@kernel.crashing.org>
On Tuesday 16 October 2007, Kumar Gala wrote:
> >> I'm willing to look into doing the port over, but would need some
> >> help testing.
> >
> > Yes, it would be greatly appreciated if you could start this
> > TQM85xx port. I
> > will of course do the testing.
>
> Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
>
> 1. what processors does this actually support/run on. I'm guessing
> MPC8541, MPC8555? But not really sure
IIRC there are 4 different versions of the board:
- 8540, 8541, 8555 & 8560
> 2. can you send the results of a bd_info from u-boot on the board
I have two version available right now
8540:
U-Boot 1.3.0-rc2-g527c80f0-dirty (Oct 5 2007 - 15:57:38)
CPU: 8540, Version: 2.0, (0x80300020)
Core: E500, Version: 2.0, (0x80200020)
Clock Configuration:
CPU: 833 MHz, CCB: 333 MHz,
DDR: 166 MHz, LBC: 41 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: TQM8540, serial# TQM8540DCBAD7-APFBC.0204 11341240 4
PCI1: 32 bit, 33 MHz (compiled)
I2C: ready
DTT: 1 is 31 C
DRAM: 256 MB (CL=2.5)
FLASH: 32 MB
L2 cache 256KB: enabled
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1, FEC
PS/2: No device found
Kbd: reset failed, no ACK
Type run flash_nfs to mount root filesystem over NFS
=> bdinfo
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x02000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xE0000000
bootflags = 0xE4013F80
intfreq = 833.333 MHz
busfreq = 333.333 MHz
ethaddr = 00:D0:93:08:12:E2
eth1addr = 00:D0:93:08:12:E3
eth2addr = 00:D0:93:08:12:E4
IP addr = 192.168.210.1
baudrate = 115200 bps
8560:
U-Boot 1.2.0-ge9792fc6 (Aug 7 2007 - 08:43:55)
CPU: 8560, Version: 2.0, (0x80700020)
Core: E500, Version: 2.0, (0x80200020)
Clock Configuration:
CPU: 833 MHz, CCB: 333 MHz,
DDR: 166 MHz, LBC: 41 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: TQM8560, serial# TQM8560DCBAD7-APFBC.0204 11301266 4
PCI1: 32 bit, 33 MHz (compiled)
I2C: ready
DTT: 1 is 22 C
DRAM: 256 MB (CL=2.5)
FLASH: 32 MB
L2 cache 256KB: enabled
In: serial
Out: serial
Err: serial
Net: TSEC0, TSEC1, FCC3 ETHERNET
Type run flash_nfs to mount root filesystem over NFS
Hit any key to stop autoboot: 0
=> bdinfo
memstart = 0x00000000
memsize = 0x10000000
flashstart = 0xFE000000
flashsize = 0x02000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xE0000000
bootflags = 0x00000036
vco = 666.666 MHz
sccfreq = 166.666 MHz
brgfreq = 166.666 MHz
intfreq = 833.333 MHz
cpmfreq = 333.333 MHz
busfreq = 333.333 MHz
ethaddr = 16:CC:31:E8:8C:12
eth1addr = 16:CC:31:E8:8C:13
eth2addr = 16:CC:31:E8:8C:14
IP addr = 192.168.210.2
baudrate = 115200 bps
> 3. can you send me the results of cat /proc/iomem & /proc/ioports
> from a linux boot.
8540:
bash-3.00# cat /proc/iomem
80000000-9fffffff : PCI1 host bridge
9fff8000-9fff9fff : 0000:00:1c.1
9fffbc00-9fffbfff : 0000:00:1c.1
9fffc000-9fffdfff : 0000:00:1c.0
9ffffc00-9fffffff : 0000:00:1c.0
e0003000-e00030ff : fsl-i2c.1
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0021100-e002117f : fsl-dma.0
e0021180-e00211ff : fsl-dma.1
e0021200-e002127f : fsl-dma.2
e0021280-e00212ff : fsl-dma.3
e0024000-e0024fff : fsl-gianfar.1
e0024520-e002453f : fsl-gianfar_mdio.0
e0025000-e0025fff : fsl-gianfar.2
e0026000-e0026fff : fsl-gianfar.3
e00e1000-e00e1fff : fsl-perfmon.1
bash-3.00# cat /proc/ioports
00000000-00ffffff : PCI1 host bridge
00fffe00-00fffeff : 0000:00:1c.1
00ffff00-00ffffff : 0000:00:1c.0
8560:
-bash-3.2# cat /proc/iomem
80000000-9fffffff : PCI1 host bridge
9f7fdf00-9f7fdfff : 0000:00:1c.0
9fbfe000-9fbfefff : 0000:00:0b.1
9ffff000-9fffffff : 0000:00:0b.0
e0003000-e00030ff : fsl-i2c.1
e0021100-e002117f : fsl-dma.0
e0021180-e00211ff : fsl-dma.1
e0021200-e002127f : fsl-dma.2
e0021280-e00212ff : fsl-dma.3
e0024000-e0024fff : fsl-gianfar.1
e0024520-e002453f : fsl-gianfar_mdio.0
e0025000-e0025fff : fsl-gianfar.2
e0088400-e00884ff : fcc_pram
e0088500-e00885ff : fcc_pram
e0088600-e00886ff : fcc_pram
e0091300-e009131f : fcc_regs
e0091320-e009133f : fcc_regs
e0091340-e009135f : fcc_regs
e0091380-e009139f : fcc_regs_c
e00913a0-e00913cf : fcc_regs_c
e00913d0-e00913ff : fcc_regs_c
e0091860-e00918bf : fsl-cpm-i2c.1
e0091a00-e0091a1f : fsl-cpm-scc.1
e0091a20-e0091a3f : fsl-cpm-scc.2
e0091a40-e0091a5f : fsl-cpm-scc.3
e0091a60-e0091a7f : fsl-cpm-scc.4
e0091aa0-e0091aff : fsl-cpm-spi.1
e0091b30-e0091b3f : fsl-cpm-mcc.1
e0091b50-e0091b5f : fsl-cpm-mcc.2
e00e1000-e00e1fff : fsl-perfmon.1
-bash-3.2# cat /proc/ioports
00000000-00ffffff : PCI1 host bridge
00ff7f00-00ff7fff : 0000:00:1c.0
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: Merge dtc
From: Paul Mackerras @ 2007-10-16 5:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <B17BEF48-34FC-44E0-AC23-1DB7522EB198@kernel.crashing.org>
Kumar Gala writes:
> Dare I ask why we are including dtc in the kernel source tree? We
> don't really have precedence for this and there are users outside of
> linux for dtc.
You must have missed the thread where various people where complaining
about how powerpc is the only architecture where they can't build
kernels without some external tool that they don't have, etc., etc.
We thought about shipping compiled DTBs for various platforms, but the
problem there is that they can't be updated with a patch, so whoever
commits a patch to the relevant .dts would have to remember to run dtc
and commit the updated .dtb as well, which seems a bit error-prone.
In the end, dtc isn't all that much code. We already have several
other programs that run on the host in the process of making a zImage,
such as wrapper, hack-coff, and addnote, not to mention the various C
programs that are part of Kbuild, and unifdef, kallsyms, etc.
So I think there definitely is a precedent for including dtc.
Paul.
^ permalink raw reply
* [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 5:40 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the "hot" loop that results of a pending signal
here will spin without even a cpu_relax ... what do you guys think would
be the best way to handle this ?
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-16 15:27:27.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-16 15:27:38.000000000 +1000
@@ -394,6 +394,21 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep_interruptible(1);
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* [PATCH] net: Fix new EMAC driver for NAPI changes
From: Benjamin Herrenschmidt @ 2007-10-16 5:40 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
net: Fix new EMAC driver for NAPI changes
This fixes the new EMAC driver for the NAPI updates. The previous patch
by Roland Dreier (already applied) to do that doesn't actually work. This
applies on top of it makes it work on my test Ebony machine.
This patch depends on "net: Add __napi_sycnhronize() to sync with napi poll"
posted previously.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
The old EMAC driver does things a bit differently (doesn't do useful
locking :-) and seems to work with Roland patch. So I'm not going to
touch it unless somebody reports me that it has problems
Index: linux-work/drivers/net/ibm_newemac/mal.c
===================================================================
--- linux-work.orig/drivers/net/ibm_newemac/mal.c 2007-10-16 14:51:11.000000000 +1000
+++ linux-work/drivers/net/ibm_newemac/mal.c 2007-10-16 14:59:23.000000000 +1000
@@ -45,6 +45,8 @@ int __devinit mal_register_commac(struct
return -EBUSY;
}
+ if (list_empty(&mal->list))
+ napi_enable(&mal->napi);
mal->tx_chan_mask |= commac->tx_chan_mask;
mal->rx_chan_mask |= commac->rx_chan_mask;
list_add(&commac->list, &mal->list);
@@ -67,6 +69,8 @@ void __devexit mal_unregister_commac(str
mal->tx_chan_mask &= ~commac->tx_chan_mask;
mal->rx_chan_mask &= ~commac->rx_chan_mask;
list_del_init(&commac->list);
+ if (list_empty(&mal->list))
+ napi_disable(&mal->napi);
spin_unlock_irqrestore(&mal->lock, flags);
}
@@ -182,7 +186,7 @@ static inline void mal_enable_eob_irq(st
set_mal_dcrn(mal, MAL_CFG, get_mal_dcrn(mal, MAL_CFG) | MAL_CFG_EOPIE);
}
-/* synchronized by __LINK_STATE_RX_SCHED bit in ndev->state */
+/* synchronized by NAPI state */
static inline void mal_disable_eob_irq(struct mal_instance *mal)
{
// XXX might want to cache MAL_CFG as the DCR read can be slooooow
@@ -317,8 +321,8 @@ void mal_poll_disable(struct mal_instanc
while (test_and_set_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags))
msleep(1);
- /* Synchronize with the MAL NAPI poller. */
- napi_disable(&mal->napi);
+ /* Synchronize with the MAL NAPI poller */
+ __napi_synchronize(&mal->napi);
}
void mal_poll_enable(struct mal_instance *mal, struct mal_commac *commac)
@@ -326,7 +330,12 @@ void mal_poll_enable(struct mal_instance
smp_wmb();
clear_bit(MAL_COMMAC_POLL_DISABLED, &commac->flags);
- // XXX might want to kick a poll now...
+ /* Feels better to trigger a poll here to catch up with events that
+ * may have happened on this channel while disabled. It will most
+ * probably be delayed until the next interrupt but that's mostly a
+ * non-issue in the context where this is called.
+ */
+ napi_schedule(&mal->napi);
}
static int mal_poll(struct napi_struct *napi, int budget)
@@ -336,8 +345,7 @@ static int mal_poll(struct napi_struct *
int received = 0;
unsigned long flags;
- MAL_DBG2(mal, "poll(%d) %d ->" NL, *budget,
- rx_work_limit);
+ MAL_DBG2(mal, "poll(%d)" NL, budget);
again:
/* Process TX skbs */
list_for_each(l, &mal->poll_list) {
@@ -528,11 +536,12 @@ static int __devinit mal_probe(struct of
}
INIT_LIST_HEAD(&mal->poll_list);
- mal->napi.weight = CONFIG_IBM_NEW_EMAC_POLL_WEIGHT;
- mal->napi.poll = mal_poll;
INIT_LIST_HEAD(&mal->list);
spin_lock_init(&mal->lock);
+ netif_napi_add(NULL, &mal->napi, mal_poll,
+ CONFIG_IBM_NEW_EMAC_POLL_WEIGHT);
+
/* Load power-on reset defaults */
mal_reset(mal);
^ permalink raw reply
* [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-16 5:49 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Roland Dreier, David S. Miller, linuxppc-dev list
net: Add __napi_sycnhronize() to sync with napi poll
The EMAC driver which needs to handle multiple devices with one
NAPI instance implements its own per-channel disable bit. However,
when setting such a bit, it needs to synchronize with the poller
(that is make sure that any pending poller instance has completed,
or is started late enough to see that disable bit).
This implements a low level __napi_synchronize() function to acheive
that. The underscores are to emphasis the low level aspect of it and
to discourage driver writers who don't know what they are doing to
use it (to please DaveM :-)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
(Use correct address for Stephen this time)
If the approach is accepted, I would like to have this merged now
so the EMAC patch to make it work again can follow :-)
Note: I use msleep_interruptible(1); just like napi_disable(). However
I'm not too happy that the "hot" loop that results of a pending signal
here will spin without even a cpu_relax ... what do you guys think would
be the best way to handle this ?
Index: linux-work/include/linux/netdevice.h
===================================================================
--- linux-work.orig/include/linux/netdevice.h 2007-10-16 15:27:27.000000000 +1000
+++ linux-work/include/linux/netdevice.h 2007-10-16 15:27:38.000000000 +1000
@@ -394,6 +394,21 @@ static inline void napi_disable(struct n
}
/**
+ * __napi_synchronize - synchronize with a concurrent poll
+ * @n: napi context
+ *
+ * Synchronizes with a concurrent poll. Not to be used in normal
+ * drivers, mostly useful if you end up with multiple interfaces
+ * on one NAPI instance.
+ */
+static inline void __napi_synchronize(struct napi_struct *n)
+{
+ smp_mb();
+ while (test_bit(NAPI_STATE_SCHED, &n->state))
+ msleep_interruptible(1);
+}
+
+/**
* napi_enable - enable NAPI scheduling
* @n: napi context
*
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 5:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <18196.20112.728499.256646@cargo.ozlabs.ibm.com>
On Oct 16, 2007, at 12:39 AM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Dare I ask why we are including dtc in the kernel source tree? We
>> don't really have precedence for this and there are users outside of
>> linux for dtc.
>
> You must have missed the thread where various people where complaining
> about how powerpc is the only architecture where they can't build
> kernels without some external tool that they don't have, etc., etc.
I must have missed this thread.
> We thought about shipping compiled DTBs for various platforms, but the
> problem there is that they can't be updated with a patch, so whoever
> commits a patch to the relevant .dts would have to remember to run dtc
> and commit the updated .dtb as well, which seems a bit error-prone.
agreed, would seem .S would have been a better choice than .dtb, but
I agree the keeping a .dts and .S form insync would be a bit of a pain.
> In the end, dtc isn't all that much code. We already have several
> other programs that run on the host in the process of making a zImage,
> such as wrapper, hack-coff, and addnote, not to mention the various C
> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>
> So I think there definitely is a precedent for including dtc.
Just out of interest who's complaining? We don't include mkimage for
u-boot related builds and I haven't seen any gripes related to that.
- k
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Kumar Gala @ 2007-10-16 5:51 UTC (permalink / raw)
To: Stefan Roese; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <200710160728.38897.sr@denx.de>
On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> On Tuesday 16 October 2007, Kumar Gala wrote:
>>>> I'm willing to look into doing the port over, but would need some
>>>> help testing.
>>>
>>> Yes, it would be greatly appreciated if you could start this
>>> TQM85xx port. I
>>> will of course do the testing.
>>
>> Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
>>
>> 1. what processors does this actually support/run on. I'm guessing
>> MPC8541, MPC8555? But not really sure
>
> IIRC there are 4 different versions of the board:
> - 8540, 8541, 8555 & 8560
do they all boot/run with the code that exists in arch/ppc ?
thanks for the other info, that's exactly what I needed.
- k
^ permalink raw reply
* Re: Merge dtc
From: Benjamin Herrenschmidt @ 2007-10-16 6:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <18196.20112.728499.256646@cargo.ozlabs.ibm.com>
> You must have missed the thread where various people where complaining
> about how powerpc is the only architecture where they can't build
> kernels without some external tool that they don't have, etc., etc.
>
> We thought about shipping compiled DTBs for various platforms, but the
> problem there is that they can't be updated with a patch, so whoever
> commits a patch to the relevant .dts would have to remember to run dtc
> and commit the updated .dtb as well, which seems a bit error-prone.
>
> In the end, dtc isn't all that much code. We already have several
> other programs that run on the host in the process of making a zImage,
> such as wrapper, hack-coff, and addnote, not to mention the various C
> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>
> So I think there definitely is a precedent for including dtc.
Note that I just tried to build a 4xx kernel today ... and failed due to
the lack of mkimage ..
Another one that we need to either add to the kernel or make the
building of cuImage's optional.
Ben.
^ permalink raw reply
* Re: Merge dtc
From: Benjamin Herrenschmidt @ 2007-10-16 6:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <5E3B6FCC-5930-4C76-AB4B-86B35551B9E0@kernel.crashing.org>
On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
> Just out of interest who's complaining? We don't include mkimage
> for
> u-boot related builds and I haven't seen any gripes related to that.
It's a pain in the neck since those are built even for things that don't
need them (such as 4xx where I use the treeboot images).
Ben.
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Wolfgang Denk @ 2007-10-16 6:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org>
Dear Kumar,
in message <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org> you wrote:
>
> >> 1. what processors does this actually support/run on. I'm guessing
> >> MPC8541, MPC8555? But not really sure
> >
> > IIRC there are 4 different versions of the board:
> > - 8540, 8541, 8555 & 8560
>
> do they all boot/run with the code that exists in arch/ppc ?
Yes, they do.
> thanks for the other info, that's exactly what I needed.
Just let us know what you need...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Technology is dominated by those who manage what they do not under-
stand.
^ permalink raw reply
* Re: boards in arch/ppc -> arch/powerpc for 85xx
From: Stefan Roese @ 2007-10-16 6:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Woodhouse, linuxppc-dev list
In-Reply-To: <D332B7CF-6633-494C-8031-807F7DF53D78@kernel.crashing.org>
On Tuesday 16 October 2007, Kumar Gala wrote:
> On Oct 16, 2007, at 12:28 AM, Stefan Roese wrote:
> > On Tuesday 16 October 2007, Kumar Gala wrote:
> >>>> I'm willing to look into doing the port over, but would need some
> >>>> help testing.
> >>>
> >>> Yes, it would be greatly appreciated if you could start this
> >>> TQM85xx port. I
> >>> will of course do the testing.
> >>
> >> Ok, for the TQM85xx code in arch/ppc can I get a few things from you:
> >>
> >> 1. what processors does this actually support/run on. I'm guessing
> >> MPC8541, MPC8555? But not really sure
> >
> > IIRC there are 4 different versions of the board:
> > - 8540, 8541, 8555 & 8560
>
> do they all boot/run with the code that exists in arch/ppc ?
Yes. I have to admit though, that I'm not sure if the denx arch/ppc version
differs from the kernel.org version.
Best regards,
Stefan
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 6:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1192514497.19073.29.camel@pasglop>
On Oct 16, 2007, at 1:01 AM, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-10-16 at 00:50 -0500, Kumar Gala wrote:
>> Just out of interest who's complaining? We don't include mkimage
>> for
>> u-boot related builds and I haven't seen any gripes related to that.
>
> It's a pain in the neck since those are built even for things that
> don't
> need them (such as 4xx where I use the treeboot images).
That was Paul's decision :)
- k
^ permalink raw reply
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 6:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <1192514455.19073.27.camel@pasglop>
On Oct 16, 2007, at 1:00 AM, Benjamin Herrenschmidt wrote:
>
>> You must have missed the thread where various people where
>> complaining
>> about how powerpc is the only architecture where they can't build
>> kernels without some external tool that they don't have, etc., etc.
>>
>> We thought about shipping compiled DTBs for various platforms, but
>> the
>> problem there is that they can't be updated with a patch, so whoever
>> commits a patch to the relevant .dts would have to remember to run
>> dtc
>> and commit the updated .dtb as well, which seems a bit error-prone.
>>
>> In the end, dtc isn't all that much code. We already have several
>> other programs that run on the host in the process of making a
>> zImage,
>> such as wrapper, hack-coff, and addnote, not to mention the various C
>> programs that are part of Kbuild, and unifdef, kallsyms, etc.
>>
>> So I think there definitely is a precedent for including dtc.
>
> Note that I just tried to build a 4xx kernel today ... and failed
> due to
> the lack of mkimage ..
>
> Another one that we need to either add to the kernel or make the
> building of cuImage's optional.
I think if we add dtc we add mkimage since its even smaller.
- k
^ permalink raw reply
* dtc: Improve support for string escapes
From: David Gibson @ 2007-10-16 6:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
dtc supports the use of C-style escapes (\n, \t and so forth) in
string property definitions via the data_copy_escape_string()
function. However, while it supports the most common escape
characters, it doesn't support the full set that C does, which is a
potential gotcha.
Worse, a bug in the lexer means that while data_copy_escape_string()
can handle the \" escape, a string with such an escape won't lex
correctly.
This patch fixes both problems, extending data_copy_escape_string() to
support the missing escapes, and fixing the regex for strings in the
lexer to handle internal escaped quotes.
This also adds a testcase for string escape functionality.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2007-10-16 16:29:37.000000000 +1000
+++ dtc/data.c 2007-10-16 16:29:37.000000000 +1000
@@ -150,12 +150,24 @@ struct data data_copy_escape_string(char
c = s[i++];
assert(c);
switch (c) {
+ case 'a':
+ q[d.len++] = '\a';
+ break;
+ case 'b':
+ q[d.len++] = '\b';
+ break;
case 't':
q[d.len++] = '\t';
break;
case 'n':
q[d.len++] = '\n';
break;
+ case 'v':
+ q[d.len++] = '\v';
+ break;
+ case 'f':
+ q[d.len++] = '\f';
+ break;
case 'r':
q[d.len++] = '\r';
break;
Index: dtc/dtc-lexer.l
===================================================================
--- dtc.orig/dtc-lexer.l 2007-10-16 16:29:37.000000000 +1000
+++ dtc/dtc-lexer.l 2007-10-16 16:38:03.000000000 +1000
@@ -69,7 +69,7 @@ REFCHAR ({PROPCHAR}|{UNITCHAR}|[/@])
}
}
-\"[^"]*\" {
+\"([^\\"]|\\.)*\" {
yylloc.filenum = srcpos_filenum;
yylloc.first_line = yylineno;
DPRINT("String: %s\n", yytext);
Index: dtc/tests/testdata.h
===================================================================
--- dtc.orig/tests/testdata.h 2007-10-16 16:29:37.000000000 +1000
+++ dtc/tests/testdata.h 2007-10-16 16:29:37.000000000 +1000
@@ -24,6 +24,7 @@
#define TEST_VALUE_2 cell_to_fdt(0xabcd1234)
#define TEST_STRING_1 "hello world"
+#define TEST_STRING_2 "nastystring: \a\b\t\n\v\f\r\\\"\xff"
#ifndef __ASSEMBLY__
extern struct fdt_header _test_tree1;
Index: dtc/tests/escapes.dts
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/escapes.dts 2007-10-16 16:29:37.000000000 +1000
@@ -0,0 +1,4 @@
+/ {
+ compatible = "test_string_escapes";
+ escape-str = "nastystring: \a\b\t\n\v\f\r\\\"\xff";
+};
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-10-16 16:29:37.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-10-16 16:30:13.000000000 +1000
@@ -104,6 +104,9 @@ dtc_tests () {
run_test dtc.sh -f -I dts -O dtb -o dtc_tree1.test.dtb test_tree1.dts
tree1_tests dtc_tree1.test.dtb
tree1_tests_rw dtc_tree1.test.dtb
+
+ run_test dtc.sh -f -I dts -O dtb -o dtc_escapes.test.dtb escapes.dts
+ run_test string_escapes dtc_escapes.test.dtb
}
while getopts "vdt:" ARG ; do
Index: dtc/tests/string_escapes.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/tests/string_escapes.c 2007-10-16 16:34:20.000000000 +1000
@@ -0,0 +1,42 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for strinc escapes in dtc
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * 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"
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ check_getprop(fdt, 0, "escape-str",
+ strlen(TEST_STRING_2)+1, TEST_STRING_2);
+
+ PASS();
+}
Index: dtc/tests/Makefile.tests
===================================================================
--- dtc.orig/tests/Makefile.tests 2007-10-16 16:31:44.000000000 +1000
+++ dtc/tests/Makefile.tests 2007-10-16 16:32:41.000000000 +1000
@@ -7,7 +7,8 @@ LIB_TESTS_L = get_mem_rsv \
setprop_inplace nop_property nop_node \
sw_tree1 \
move_and_save \
- open_pack rw_tree1 setprop del_property del_node
+ open_pack rw_tree1 setprop del_property del_node \
+ string_escapes
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
--
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: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Herbert Xu @ 2007-10-16 6:06 UTC (permalink / raw)
To: benh; +Cc: netdev, rdreier, shemminger, davem, linuxppc-dev
In-Reply-To: <1192513792.19073.23.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> Note: I use msleep_interruptible(1); just like napi_disable(). However
> I'm not too happy that the "hot" loop that results of a pending signal
> here will spin without even a cpu_relax ... what do you guys think would
> be the best way to handle this ?
Well since the loop does not check signals at all, it should
just use msleep.
Granted the process will end up in the D state and contribute
to the load average. But if this loop executes long enough
for that to be noticed then we've got bigger problems to worry
about.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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