* Re: [patch 3/3] mpc8349emitx.dts: Add ds1339 RTC
From: David Gibson @ 2007-09-28 2:45 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <9c20d018e890250443516b886317ceb9@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:33:58PM +0200, Segher Boessenkool wrote:
> >>> Hrm... we probably want an "i2c" device_type class, but I don't think
> >>> we've actually defined one, which is a problem
> >>
> >> By defining new device_type's, or new semantics for device_type,
> >> you open the door to (accidentally) becoming incompatible with
> >> "real" OF.
> >
> > Hrm... perhaps. But is it a realistic danger - I'll have to think
> > more about that.
>
> It is trivial to avoid these dangers completely by not overloading
> the meaning of "device_type".
Hrm. Perhaps.
> >>> I think we want to think a bit more carefully about how to do
> >>> bindings
> >>> for RTC devices. No "rtc" device_type is defined, but again we might
> >>> want to.
> >>
> >> Actually, "device_type" = "rtc" _is_ defined (in the "device support
> >> extensions" recommended practice), and there is no useful way a flat
> >> device tree can implement it (it merely defines get-time and set-time
> >> methods).
> >
> > Ah.. right. That changes things a bit, in that we might want to
> > include device_type purely for similarity with real OF tree.
>
> You should include the device_type only if you implement its binding,
> and a flat device tree does not, and cannot. (In almost all cases,
> a flat device tree cannot implement device_type's semantics -- this
> means that pretty much the only case where a flat tree should use
> device_type is to have it as a workaround for bad kernel requirements).
I really don't think there's an ambiguity here. A flat-tree can
clearly never implement runtime binding features. This is also true
for a flat tree derived from a real OF, and so full of device_type all
over the place.
> > Real OF has a device_type == "nvram" too, doesn't it?
>
> Yes, same "device support extensions" document.
Erm.. I've lost track amongst our various threads. Which same
document?
> > AFAICT the real
> > OF systems I have (which I think all have ISA-like CMOS RTC/NVRAM
> > chips) the RTC is labelled as "nvram" rather than "rtc".
>
> Sounds buggy.
Why?
[snip]
> > I did find one real OF binding for a different Dallas RTC (and NVRAM),
> > see:
> >
> > http://playground.sun.com/1275/proposals/Closed/Remanded/Accepted/346-
> > it.txt
> >
> > It's a little different from the example above.
>
> That is a binding for the nvram part only, not for the RTC.
Hrm. So how do you suggest we do bindings for combined devices?
--
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: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 4:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBD483.6090403@freescale.com>
Scott Wood-2 wrote:
>
> Misbah khan wrote:
>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>> provided by the Linux kernel. I want to know that if anybody is used it
>> and have full faith in its operation then please let me know. Driver in
>> the while loop is calling these API's hence i want to make sure that its
>> operation will remain stable.
>
> They're used all over the place. Is there anything about them that you
> find suspect?
>
> -Scott
>
> I have devloped a character driver for FPGA which is memory mapped and
> using these API's to test a bit , set a bit or to clear a bit in the
> memory for eg :-
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(UINT32 *)(\
> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return -1;
> }
>
> People working for FPGA are sure that they are not making the bit high
> where in my driver is returning -1 from the kernel space aborting it after
> running for few minutes or so . Please let me know that This function is
> stable and i should tell them that the driver is stable in its operation
> and they should check it from there side.
>
> Misbah
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12934517
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 4:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
libfdt.h currently includes fdt.h, then libfdt_env.h. This is
incorrect, because depending on the environment into which libfdt is
embedded, libfdt_env.h may be needed to define datatypes used in
fdt.h. This patch corrects the problem.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/libfdt.h
===================================================================
--- dtc.orig/libfdt/libfdt.h 2007-09-27 15:23:10.000000000 +1000
+++ dtc/libfdt/libfdt.h 2007-09-27 15:23:50.000000000 +1000
@@ -51,8 +51,8 @@
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include <fdt.h>
#include <libfdt_env.h>
+#include <fdt.h>
#define FDT_FIRST_SUPPORTED_VERSION 0x10
#define FDT_LAST_SUPPORTED_VERSION 0x11
--
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: Test rw functions on more trees
From: David Gibson @ 2007-09-28 4:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the testcases for read/write functions (setprop,
del_property and del_node) are only invoked on the single
asm-generated tree, not on any of the other tree images which should
be equivalent. The functions in question will (correctly) not work on
the "unfinished" tree output from sw_tree1, but should work on most of
the others.
This patch extends the run_tests script to invoke the r/w testcases on
more example trees. The testsuite still passes clean with this
addition.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-09-27 17:49:29.000000000 +1000
+++ dtc/tests/run_tests.sh 2007-09-27 17:57:00.000000000 +1000
@@ -49,6 +49,15 @@ tree1_tests () {
run_test nop_node $TREE
}
+tree1_tests_rw () {
+ TREE=$1
+
+ # Read-write tests
+ run_test setprop $TREE
+ run_test del_property $TREE
+ run_test del_node $TREE
+}
+
libfdt_tests () {
# Make sure we don't have stale blobs lying around
rm -f *.test.dtb
@@ -76,11 +85,16 @@ libfdt_tests () {
tree1_tests opened.$tree
tree1_tests repacked.$tree
done
- run_test setprop test_tree1.dtb
- run_test del_property test_tree1.dtb
- run_test del_node test_tree1.dtb
+
+ for tree in test_tree1.dtb sw_tree1.test.dtb; do
+ tree1_tests_rw $tree
+ tree1_tests_rw moved.$tree
+ tree1_tests_rw shunted.$tree
+ tree1_tests_rw deshunted.$tree
+ done
run_test rw_tree1
tree1_tests rw_tree1.test.dtb
+ tree1_tests_rw rw_tree1.test.dtb
# Tests for behaviour on various sorts of corrupted trees
run_test truncated_property
@@ -92,6 +106,7 @@ 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
}
while getopts "vdt:" ARG ; do
--
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: libfdt: libfdt_env.h must be included first
From: Stephen Rothwell @ 2007-09-28 5:13 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070928045206.GA25743@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
>
> libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> incorrect, because depending on the environment into which libfdt is
> embedded, libfdt_env.h may be needed to define datatypes used in
> fdt.h. This patch corrects the problem.
So why doesn't fdt.h include libfdt_env.h, then?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Jeff Mock @ 2007-09-28 5:19 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12934517.post@talk.nabble.com>
Misbah khan wrote:
>
>
> Scott Wood-2 wrote:
>> Misbah khan wrote:
>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>> provided by the Linux kernel. I want to know that if anybody is used it
>>> and have full faith in its operation then please let me know. Driver in
>>> the while loop is calling these API's hence i want to make sure that its
>>> operation will remain stable.
>> They're used all over the place. Is there anything about them that you
>> find suspect?
>>
>> -Scott
>>
>> I have devloped a character driver for FPGA which is memory mapped and
>> using these API's to test a bit , set a bit or to clear a bit in the
>> memory for eg :-
>>
>> /* poll till data is transfered from sdram to dpram */
>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>> && (delay < MAX_DELAY_BUSY))
>> {
>> KDEBUG3(" In the Dfr delay loop \n");
>> mdelay(DELAY);
>> delay+=DELAY;
>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>
>> if(delay==MAX_DELAY_BUSY)
>> {
>> KDEBUG1("Out of the the Dfr busy loop \n");
>> return -1;
>> }
>>
>> People working for FPGA are sure that they are not making the bit high
>> where in my driver is returning -1 from the kernel space aborting it after
>> running for few minutes or so . Please let me know that This function is
>> stable and i should tell them that the driver is stable in its operation
>> and they should check it from there side.
>>
I think a more more likely source of the problem is that the FPGA
pointer is not cast volatile, or perhaps the FPGA is mapped cached and
the hardware doesn't always get touched when you think it does. The bit
manipulation macros are probably fine.
jeff
^ permalink raw reply
* Re: libfdt: libfdt_env.h must be included first
From: David Gibson @ 2007-09-28 5:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070928151322.a9dee5d9.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, Sep 28, 2007 at 03:13:22PM +1000, Stephen Rothwell wrote:
> On Fri, 28 Sep 2007 14:52:06 +1000 David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > libfdt.h currently includes fdt.h, then libfdt_env.h. This is
> > incorrect, because depending on the environment into which libfdt is
> > embedded, libfdt_env.h may be needed to define datatypes used in
> > fdt.h. This patch corrects the problem.
>
> So why doesn't fdt.h include libfdt_env.h, then?
Because libfdt_env.h is specifically for libfdt, whereas fdt.h
contains passive structures only, related to the flat tree structure
but without reference to any particular code for handling it.
Basically, fdt.h includes no other headers as a compromise to make it
more easily usable in various contexts. In fact the only thing it
needs is the C99 fixed-width integer types, but I want it to be also
usable in contexts which don't have a <stdint.h> (e.g. the kernel
bootwrapper).
--
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* libfdt: Make unit address optional for finding nodes
From: David Gibson @ 2007-09-28 5:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
At present, the fdt_subnode_offset() and fdt_path_offset() functions
in libfdt require the exact name of the nodes in question be passed,
including unit address.
This is contrary to traditional OF-like finddevice() behaviour, which
allows the unit address to be omitted (which is useful when the device
name is unambiguous without the address).
This patch introduces similar behaviour to
fdt_subnode_offset_namelen(), and hence to fdt_subnode_offset() and
fdt_path_offset() which are implemented in terms of the former. The
unit address can be omitted from the given node name. If this is
ambiguous, the first such node in the flattened tree will be selected
(this behaviour is consistent with IEEE1275 which specifies only that
an arbitrary node matching the given information be selected).
This very small change is then followed by many more diffs which
change the test examples and testcases to exercise this behaviour.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Jon, I initially considered making this behaviour optional,
i.e. adding a flag to subnode_offset() determining if it needed exact
matches or name-without-address matches. I couldn't see that it was
actually any use, though.
Index: dtc/libfdt/fdt_ro.c
===================================================================
--- dtc.orig/libfdt/fdt_ro.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/libfdt/fdt_ro.c 2007-09-27 18:36:03.000000000 +1000
@@ -62,8 +62,8 @@
return err; \
}
-static int offset_streq(const void *fdt, int offset,
- const char *s, int len)
+static int nodename_eq(const void *fdt, int offset,
+ const char *s, int len)
{
const char *p = fdt_offset_ptr(fdt, offset, len+1);
@@ -74,10 +74,12 @@ static int offset_streq(const void *fdt,
if (memcmp(p, s, len) != 0)
return 0;
- if (p[len] != '\0')
+ if (p[len] == '\0')
+ return 1;
+ else if (!memchr(s, '@', len) && (p[len] == '@'))
+ return 1;
+ else
return 0;
-
- return 1;
}
char *fdt_string(const void *fdt, int stroffset)
@@ -110,7 +112,7 @@ int fdt_subnode_offset_namelen(const voi
level++;
if (level != 1)
continue;
- if (offset_streq(fdt, offset+FDT_TAGSIZE, name, namelen))
+ if (nodename_eq(fdt, offset+FDT_TAGSIZE, name, namelen))
/* Found it! */
return offset;
break;
Index: dtc/tests/trees.S
===================================================================
--- dtc.orig/tests/trees.S 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/trees.S 2007-09-27 17:58:54.000000000 +1000
@@ -78,7 +78,7 @@ test_tree1_struct:
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
PROP_STR(test_tree1, prop_str, TEST_STRING_1)
- BEGIN_NODE("subnode1")
+ BEGIN_NODE("subnode@1")
PROP_INT(test_tree1, prop_int, TEST_VALUE_1)
BEGIN_NODE("subsubnode")
@@ -86,10 +86,10 @@ test_tree1_struct:
END_NODE
END_NODE
- BEGIN_NODE("subnode2")
+ BEGIN_NODE("subnode@2")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
- BEGIN_NODE("subsubnode")
+ BEGIN_NODE("subsubnode@0")
PROP_INT(test_tree1, prop_int, TEST_VALUE_2)
END_NODE
END_NODE
Index: dtc/tests/subnode_offset.c
===================================================================
--- dtc.orig/tests/subnode_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/subnode_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(struct fdt_header *fdt
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -59,13 +59,13 @@ int main(int argc, char *argv[])
{
void *fdt;
int subnode1_offset, subnode2_offset;
- int subsubnode1_offset, subsubnode2_offset;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
if (subnode1_offset == subnode2_offset)
FAIL("Different subnodes have same offset");
@@ -74,10 +74,15 @@ int main(int argc, char *argv[])
check_property_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
check_property_typed(fdt, subsubnode1_offset, "prop-int", TEST_VALUE_1);
check_property_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
+ check_property_typed(fdt, subsubnode2_offset2, "prop-int", TEST_VALUE_2);
+
+ if (subsubnode2_offset != subsubnode2_offset2)
+ FAIL("Different offsets with and without unit address");
PASS();
}
Index: dtc/tests/path_offset.c
===================================================================
--- dtc.orig/tests/path_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/path_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -48,7 +48,7 @@ int check_subnode(void *fdt, int parent,
if (tag != FDT_BEGIN_NODE)
FAIL("Incorrect tag 0x%08x on property \"%s\"", tag, name);
- if (!streq(nh->name, name))
+ if (!nodename_eq(nh->name, name))
FAIL("Subnode name mismatch \"%s\" instead of \"%s\"",
nh->name, name);
@@ -61,8 +61,8 @@ int main(int argc, char *argv[])
int root_offset;
int subnode1_offset, subnode2_offset;
int subnode1_offset_p, subnode2_offset_p;
- int subsubnode1_offset, subsubnode2_offset;
- int subsubnode1_offset_p, subsubnode2_offset_p;
+ int subsubnode1_offset, subsubnode2_offset, subsubnode2_offset2;
+ int subsubnode1_offset_p, subsubnode2_offset_p, subsubnode2_offset2_p;
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
@@ -74,11 +74,11 @@ int main(int argc, char *argv[])
else if (root_offset != 0)
FAIL("fdt_path_offset(\"/\") returns incorrect offset %d",
root_offset);
- subnode1_offset = check_subnode(fdt, 0, "subnode1");
- subnode2_offset = check_subnode(fdt, 0, "subnode2");
+ subnode1_offset = check_subnode(fdt, 0, "subnode@1");
+ subnode2_offset = check_subnode(fdt, 0, "subnode@2");
- subnode1_offset_p = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset_p = fdt_path_offset(fdt, "/subnode2");
+ subnode1_offset_p = fdt_path_offset(fdt, "/subnode@1");
+ subnode2_offset_p = fdt_path_offset(fdt, "/subnode@2");
if (subnode1_offset != subnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
@@ -89,10 +89,12 @@ int main(int argc, char *argv[])
subnode2_offset, subnode2_offset_p);
subsubnode1_offset = check_subnode(fdt, subnode1_offset, "subsubnode");
- subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode");
+ subsubnode2_offset = check_subnode(fdt, subnode2_offset, "subsubnode@0");
+ subsubnode2_offset2 = check_subnode(fdt, subnode2_offset, "subsubnode");
- subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode1_offset_p = fdt_path_offset(fdt, "/subnode@1/subsubnode");
+ subsubnode2_offset_p = fdt_path_offset(fdt, "/subnode@2/subsubnode@0");
+ subsubnode2_offset2_p = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode1_offset != subsubnode1_offset_p)
FAIL("Mismatch between subnode_offset (%d) and path_offset (%d)",
Index: dtc/tests/tests.h
===================================================================
--- dtc.orig/tests/tests.h 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/tests.h 2007-09-27 17:58:54.000000000 +1000
@@ -126,6 +126,7 @@ const void *check_getprop(void *fdt, int
})
#define check_getprop_string(fdt, nodeoffset, name, s) \
check_getprop((fdt), (nodeoffset), (name), strlen(s)+1, (s))
+int nodename_eq(const char *s1, const char *s2);
//void *load_blob(const char *filename);
void *load_blob_arg(int argc, char *argv[]);
void save_blob(const char *filename, void *blob);
Index: dtc/tests/testutils.c
===================================================================
--- dtc.orig/tests/testutils.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/testutils.c 2007-09-27 17:58:54.000000000 +1000
@@ -125,6 +125,21 @@ const void *check_getprop(void *fdt, int
return propval;
}
+int nodename_eq(const char *s1, const char *s2)
+{
+ int len = strlen(s2);
+
+ len = strlen(s2);
+ if (strncmp(s1, s2, len) != 0)
+ return 0;
+ if (s1[len] == '\0')
+ return 1;
+ else if (!memchr(s2, '@', len) && (s1[len] == '@'))
+ return 1;
+ else
+ return 0;
+}
+
#define CHUNKSIZE 128
void *load_blob(const char *filename)
Index: dtc/tests/get_name.c
===================================================================
--- dtc.orig/tests/get_name.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_name.c 2007-09-27 17:58:54.000000000 +1000
@@ -74,10 +74,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_name(fdt, "/");
- check_name(fdt, "/subnode1");
- check_name(fdt, "/subnode2");
- check_name(fdt, "/subnode1/subsubnode");
- check_name(fdt, "/subnode2/subsubnode");
+ check_name(fdt, "/subnode@1");
+ check_name(fdt, "/subnode@2");
+ check_name(fdt, "/subnode@1/subsubnode");
+ check_name(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/get_path.c
===================================================================
--- dtc.orig/tests/get_path.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/get_path.c 2007-09-27 17:58:54.000000000 +1000
@@ -82,10 +82,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/supernode_atdepth_offset.c
===================================================================
--- dtc.orig/tests/supernode_atdepth_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/supernode_atdepth_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -135,10 +135,10 @@ int main(int argc, char *argv[])
fdt = load_blob_arg(argc, argv);
check_path(fdt, "/");
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
PASS();
}
Index: dtc/tests/node_offset_by_prop_value.c
===================================================================
--- dtc.orig/tests/node_offset_by_prop_value.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/node_offset_by_prop_value.c 2007-09-27 17:58:54.000000000 +1000
@@ -83,10 +83,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
- subsubnode1_offset = fdt_path_offset(fdt, "/subnode1/subsubnode");
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ 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))
Index: dtc/tests/nop_node.c
===================================================================
--- dtc.orig/tests/nop_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/nop_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -39,21 +39,21 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find \"/subnode1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -61,21 +61,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -83,19 +83,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_nop_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/notfound.c
===================================================================
--- dtc.orig/tests/notfound.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/notfound.c 2007-09-27 17:58:54.000000000 +1000
@@ -53,7 +53,7 @@ int main(int argc, char *argv[])
val = fdt_getprop(fdt, 0, "nonexistant-property", &lenerr);
check_error("fdt_getprop(\"nonexistant-property\"", lenerr);
- subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode1");
+ subnode1_offset = fdt_subnode_offset(fdt, 0, "subnode@1");
if (subnode1_offset < 0)
FAIL("Couldn't find subnode1: %s", fdt_strerror(subnode1_offset));
Index: dtc/tests/parent_offset.c
===================================================================
--- dtc.orig/tests/parent_offset.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/parent_offset.c 2007-09-27 17:58:54.000000000 +1000
@@ -77,10 +77,10 @@ int main(int argc, char *argv[])
test_init(argc, argv);
fdt = load_blob_arg(argc, argv);
- check_path(fdt, "/subnode1");
- check_path(fdt, "/subnode2");
- check_path(fdt, "/subnode1/subsubnode");
- check_path(fdt, "/subnode2/subsubnode");
+ check_path(fdt, "/subnode@1");
+ check_path(fdt, "/subnode@2");
+ check_path(fdt, "/subnode@1/subsubnode");
+ check_path(fdt, "/subnode@2/subsubnode@0");
err = fdt_parent_offset(fdt, 0);
if (err != -FDT_ERR_NOTFOUND)
FAIL("fdt_parent_offset(/) returns %d instead of "
Index: dtc/tests/del_node.c
===================================================================
--- dtc.orig/tests/del_node.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/del_node.c 2007-09-27 17:58:54.000000000 +1000
@@ -42,21 +42,21 @@ int main(int argc, char *argv[])
oldsize = fdt_totalsize(fdt);
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset < 0)
- FAIL("Couldn't find \"/subnode1\": %s",
+ FAIL("Couldn't find \"/subnode@1\": %s",
fdt_strerror(subnode1_offset));
check_getprop_typed(fdt, subnode1_offset, "prop-int", TEST_VALUE_1);
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2\": %s",
+ FAIL("Couldn't find \"/subnode@2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -64,21 +64,21 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode1): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset < 0)
FAIL("Couldn't find \"/subnode2\": %s",
fdt_strerror(subnode2_offset));
check_getprop_typed(fdt, subnode2_offset, "prop-int", TEST_VALUE_2);
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset < 0)
- FAIL("Couldn't find \"/subnode2/subsubnode\": %s",
+ FAIL("Couldn't find \"/subnode@2/subsubnode\": %s",
fdt_strerror(subsubnode2_offset));
check_getprop_typed(fdt, subsubnode2_offset, "prop-int", TEST_VALUE_2);
@@ -86,19 +86,19 @@ int main(int argc, char *argv[])
if (err)
FAIL("fdt_del_node(subnode2): %s", fdt_strerror(err));
- subnode1_offset = fdt_path_offset(fdt, "/subnode1");
+ subnode1_offset = fdt_path_offset(fdt, "/subnode@1");
if (subnode1_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode1) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode1_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subnode2_offset = fdt_path_offset(fdt, "/subnode2");
+ subnode2_offset = fdt_path_offset(fdt, "/subnode@2");
if (subnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subnode2_offset),
fdt_strerror(-FDT_ERR_NOTFOUND));
- subsubnode2_offset = fdt_path_offset(fdt, "/subnode2/subsubnode");
+ subsubnode2_offset = fdt_path_offset(fdt, "/subnode@2/subsubnode");
if (subsubnode2_offset != -FDT_ERR_NOTFOUND)
FAIL("fdt_path_offset(subsubnode2) returned \"%s\" instead of \"%s\"",
fdt_strerror(subsubnode2_offset),
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/sw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -54,16 +54,16 @@ int main(int argc, char *argv[])
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, "subnode1"));
+ CHECK(fdt_begin_node(fdt, "subnode@1"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
- CHECK(fdt_begin_node(fdt, "subnode2"));
+ CHECK(fdt_begin_node(fdt, "subnode@2"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
- CHECK(fdt_begin_node(fdt, "subsubnode"));
+ CHECK(fdt_begin_node(fdt, "subsubnode@0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_2));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
Index: dtc/tests/rw_tree1.c
===================================================================
--- dtc.orig/tests/rw_tree1.c 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/rw_tree1.c 2007-09-27 17:58:54.000000000 +1000
@@ -72,14 +72,14 @@ int main(int argc, char *argv[])
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, "subnode1"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode@1"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_1));
- OFF_CHECK(offset, fdt_add_subnode(fdt, 0, "subnode2"));
+ 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"));
+ OFF_CHECK(offset, fdt_add_subnode(fdt, offset, "subsubnode@0"));
CHECK(fdt_setprop_typed(fdt, offset, "prop-int", TEST_VALUE_2));
Index: dtc/tests/test_tree1.dts
===================================================================
--- dtc.orig/tests/test_tree1.dts 2007-09-27 17:58:46.000000000 +1000
+++ dtc/tests/test_tree1.dts 2007-09-27 17:58:54.000000000 +1000
@@ -2,7 +2,7 @@
prop-int = <deadbeef>;
prop-str = "hello world";
- subnode1 {
+ subnode@1 {
prop-int = <deadbeef>;
subsubnode {
@@ -10,10 +10,10 @@
};
};
- subnode2 {
+ subnode@2 {
prop-int = <abcd1234>;
- subsubnode {
+ subsubnode@0 {
prop-int = <abcd1234>;
};
};
--
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] Make sure to of_node_get() the result of pci_device_to_OF_node()
From: Michael Ellerman @ 2007-09-28 6:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Arnd Bergmann
In-Reply-To: <8183225ab4b14684bb0939e0c5258caaf5b8102f.1190008974.git.michael@ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]
On Mon, 2007-09-17 at 16:03 +1000, Michael Ellerman wrote:
> pci_device_to_OF_node() returns the device node attached to a PCI device,
> but doesn't actually grab a reference - we need to do it ourselves.
Hi Paul,
Can you stick this in your 24 tree for the moment, the warnings it fixes
are giving people the willys. I'll look at the proper fix of having
pci_device_to_OF_node() take the reference and fixing all the callers.
cheers
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
> index 57a6149..2b2dfcc 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
> const phandle *ph;
> struct axon_msic *msic = NULL;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return NULL;
> @@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
> int len;
> const u32 *prop;
>
> - dn = pci_device_to_OF_node(dev);
> + dn = of_node_get(pci_device_to_OF_node(dev));
> if (!dn) {
> dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
> return -ENODEV;
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] Celleb: New HTAB Guest OS Interface on Beat
From: Ishizaki Kou @ 2007-09-28 6:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
In-Reply-To: <1190881866.6158.13.camel@pasglop>
> On Thu, 2007-09-27 at 16:53 +0900, Ishizaki Kou wrote:
> > This is a patch kit to work with new Guest OS Interface
> > to tweak HTAB on Beat. It detects old and new Guest OS Interfaces
> > automatically.
>
> You may also consider adding an API to Beat to invalidate ranges of
> addresses. We could us that through the batch invalidate mechanism to
> speed up significantly process tear down and forks typically.
Thank you for your suggestion, we'll consider it for next release of
Beat.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Ishizaki Kou @ 2007-09-28 8:04 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <1190932629.6158.37.camel@pasglop>
Ben-san,
> > It should have been set in setup_64.c, in setup_paca() (which is
called
> > twice) in that statement:
> >
> > local_paca = &paca[cpu];
> >
> > As local_paca is defined as being a variable held in register r13.
Maybe
> > something bad's happening with the compiler ?
> Can you check early_setup disassembly, see if r13 is assigned (it
should
> be in two spots) and if it's clobbered by the compiler somewhere ?
> Also, you may want to try adding --ffixed-r13 to the CFLAGS in the
> makefile and let us know if it makes a difference... r13 is marked
> reserved by the ABI but segher seems to imply that gcc may decide to
ues
> it anyway (ouch !)
I reviewed early_setup() disassembly sets r13 correctly. Now I found
the kernel works well without our hack, so I think I can decline the
patch [1/7].
Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
function breaks the SLB table since it is called before setting up
PACA.
Thank you for your hint.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:40 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, linux-fbdev-devel, cbe-oss-dev,
Antonino A. Daplas
In-Reply-To: <46FBE6FD.3030605@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On Thu, 2007-09-27 at 10:23 -0700, Geoff Levand wrote:
> Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> >> Hi,
> >>
> >> Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> >> used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> >> (ps3fb):
> >> [1] ps3av: eliminate unneeded temporary variables
> >> [2] ps3av: eliminate PS3AV_DEBUG
> >> [3] ps3av: use PS3 video mode ids in autodetect code
> >> [4] ps3av: treat DVI-D like HDMI in autodetect
> >> [5] ps3av: add autodetection for VESA modes
> >> [6] ps3av: add quirk database for broken monitors
> >> [7] ps3av: remove unused ps3av_set_mode()
> >> [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> >>
> >> Please review, and queue for 2.6.24 if they're ok. Thanks!
> >>
> >> Question: As several DVI-D displays advertise they support 1080i modes while
> >> they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> >> modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> >> better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> It is not that bad. If a bootloader is configued to use autodetection
> so that it is shown at best video mode, then it should have advertised
> key sequences to default to known video modes, with at least a 480p 'safe'
> mode.
Oh OK, that is a good idea. What's the "safe mode" key sequence for the
otheros.bld you provide on kernel.org?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Michael Ellerman @ 2007-09-28 8:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev, linux-fbdev-devel, cbe-oss-dev, Antonino A. Daplas
In-Reply-To: <Pine.LNX.4.62.0709271344130.10467@pademelon.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
On Thu, 2007-09-27 at 13:53 +0200, Geert Uytterhoeven wrote:
> On Thu, 27 Sep 2007, Michael Ellerman wrote:
> > On Wed, 2007-09-26 at 18:33 +0200, Geert Uytterhoeven wrote:
> > > Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
> > > used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
> > > (ps3fb):
> > > [1] ps3av: eliminate unneeded temporary variables
> > > [2] ps3av: eliminate PS3AV_DEBUG
> > > [3] ps3av: use PS3 video mode ids in autodetect code
> > > [4] ps3av: treat DVI-D like HDMI in autodetect
> > > [5] ps3av: add autodetection for VESA modes
> > > [6] ps3av: add quirk database for broken monitors
> > > [7] ps3av: remove unused ps3av_set_mode()
> > > [8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
> > >
> > > Please review, and queue for 2.6.24 if they're ok. Thanks!
> > >
> > > Question: As several DVI-D displays advertise they support 1080i modes while
> > > they actually don't (cfr. the quirk database), perhaps I should drop 1080i
> > > modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
> > > better than 1080i anyway. What do you think?
> >
> > Definitely. If the autodetection fails Linux is basically unusable on
> > PS3 unless you hack the kernel sources and build your own kboot and
> > otheros.bld - not entirely trivial for novice users. So it's pretty
> > important that it works 100%.
>
> Well, this code has been in Geoff's git tree for a while, and it's been several
> weeks ago I got complaints (which have been adressed by adding displays to the
> quirk database). The new kboot (from Distro Kit 1.4.1) also uses it.
Well yeah. Your instructions for diagnosing a quirk are to add #define
DEBUG to ps3av.c and then send the _output from the kernel log_ ... ?
Not to mention that for every quirk reported there's probably 50 users
who just figured Linux on PS3 was broken and gave up.
> The only 100% (sic) mode is 480p (actual usable resolution is 576x384), which
> is quite limited due to the very low resolution. This is what the current
> mainline kernel uses by default, causing complaints from people who don't like
> their shiny expensive full-HD displays being driven by 480p by default.
Sure that's annoying, but not quite as annoying as getting a completely
black screen that you can do nothing about - short of hacking the kernel
and building your own otheros.bld.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBF9B7.9010007@freescale.com>
On Thursday 27 September 2007 20:43, Scott Wood wrote:
> Jon Smirl wrote:
> > The call to msleep() is inside a block protected with
> >
> > :#define in_interrupt() (irq_count())
> >
> > if (!in_interrupt)
> >
> > The stack trace looks like it is in a timer interrupt so shouldn't
> > irq_count be non-zero?
> > Could there be some lack of coordination on irq_count and the timer
> > tick with the preempt patch applied? Or does irq_count() not count
> > soft irqs?
> >
> > (!in_interrupt) may be the wrong way to protect this code.
>
> I think in_atomic() is what you want.
I tried with in_atomic(). The BUG report is gone, but the problem still=20
exists.=20
While network stress testing:=20
[...]
NETDEV WATCHDOG: eth0: transmit timed out
net eth0: transmit timed out
net eth0: queues didn't drain
net eth0: tx: index: 35, outdex: 36
net eth0: rx: index: 24, outdex: 25
PHY: f0003000:00 - Link is Down
PHY: f0003000:00 - Link is Up - 100/Full
The link is up again, but any connection is dead (no answers to ping etc.).=
=20
But the serial console is still working. I'm not sure if the RT-Preempt pat=
ch=20
*causes* this behavior or only *discover* it. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=C2=A0Pengutronix - Linux Solutions for Science and Industry
=C2=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=C2=A0 =C2=A0 =C2=A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Misbah khan @ 2007-09-28 9:12 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FC8EFE.2000108@mock.com>
Jeff Mock-2 wrote:
>
>
>
> Misbah khan wrote:
>>
>>
>> Scott Wood-2 wrote:
>>> Misbah khan wrote:
>>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions
>>>> provided by the Linux kernel. I want to know that if anybody is used it
>>>> and have full faith in its operation then please let me know. Driver in
>>>> the while loop is calling these API's hence i want to make sure that
>>>> its
>>>> operation will remain stable.
>>> They're used all over the place. Is there anything about them that you
>>> find suspect?
>>>
>>> -Scott
>>>
>>> I have devloped a character driver for FPGA which is memory mapped and
>>> using these API's to test a bit , set a bit or to clear a bit in the
>>> memory for eg :-
>>>
>>> /* poll till data is transfered from sdram to dpram */
>>> while((test_bit(DFR_BUSY,(UINT32 *)(\
>>> (void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>>> && (delay < MAX_DELAY_BUSY))
>>> {
>>> KDEBUG3(" In the Dfr delay loop \n");
>>> mdelay(DELAY);
>>> delay+=DELAY;
>>> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>>
>>> if(delay==MAX_DELAY_BUSY)
>>> {
>>> KDEBUG1("Out of the the Dfr busy loop \n");
>>> return -1;
>>> }
>>>
>>> People working for FPGA are sure that they are not making the bit high
>>> where in my driver is returning -1 from the kernel space aborting it
>>> after
>>> running for few minutes or so . Please let me know that This function is
>>> stable and i should tell them that the driver is stable in its operation
>>> and they should check it from there side.
>>>
>
>
> I think a more more likely source of the problem is that the FPGA
> pointer is not cast volatile, or perhaps the FPGA is mapped cached and
> the hardware doesn't always get touched when you think it does. The bit
> manipulation macros are probably fine.
>
> jeff
>
> FPGA is Indeed mapped non cashed here is the part of the code
>
> /* Physical bus memory is mapped */
> mmap_reg_ptr=(UINT32 *)ioremap_nocache(PHY_MEM_ADDR,PHY_MEM_SIZE);
>
> And is it ok if I caste FPGA pointer volatile like this will reduce the
> probability of failure
>
> /* poll till data is transfered from sdram to dpram */
> while((test_bit(DFR_BUSY,(volatile UINT32 *)(\
> (volatile UINT32 *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> && (delay < MAX_DELAY_BUSY))
> {
> KDEBUG3(" In the Dfr delay loop \n");
> mdelay(DELAY);
> delay+=DELAY;
> }/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>
> if(delay==MAX_DELAY_BUSY)
> {
> KDEBUG1("Out of the the Dfr busy loop \n");
> return CASHEL_FAILURE;
> }
> __________________
>
> is there anything else that we could do to rely fully in our code.
>
> Misbah
> _____________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12937117
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at
From: Benjamin Herrenschmidt @ 2007-09-28 9:29 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linuxppc-dev, paulus, arnd
In-Reply-To: <20070928.170401.-1300520897.kouish@swc.toshiba.co.jp>
On Fri, 2007-09-28 at 17:04 +0900, Ishizaki Kou wrote:
> Commit edd0622bd2e8f755c960827e15aa6908c3c5aa94 seems to break the
> kernel and commit 175587cca7447daf5a13e4a53d32360ed8cba804 backs out
> the symptom. Calling slb_flush_and_rebolt() at slb_initialize()
> function breaks the SLB table since it is called before setting up
> PACA.
>
> Thank you for your hint.
Ah yes, there was a temporary breakage there that got fixed indeed,
I remember.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v4] Make instruction dumping work in real mode.
From: Segher Boessenkool @ 2007-09-28 9:37 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070927183855.GA18226@loki.buserror.net>
> On non-book-E-or-4xx, exceptions execute in real mode. If a fault
> happens
> that leads to a register dump, the kernel currently prints XXXXXXXX
> because
> it doesn't realize that PC is a physical address.
>
> This patch checks the state of the IMMU, and if necessary converts PC
> into a
> virtual address.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> OK, just CONFIG_BOOKE this time. :-P
You forgot to fix the commit message ;-P
Segher
^ permalink raw reply
* Re: [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: Paul Jackson @ 2007-09-28 9:49 UTC (permalink / raw)
To: travis; +Cc: linux-mm, ak, linux-kernel, linuxppc-dev, sparclinux, akpm,
clameter
In-Reply-To: <20070912015647.214306428@sgi.com>
Mike,
I think there is a bug either in this ia64 patch, or in the related
generic arch patch: Convert cpu_sibling_map to be a per cpu variable
(v3).
It dies early in boot on me, on the SGI internal 8 processor IA64
system that you and I know as 'margin'. The death is a hard hang, due
to a corrupt stack, due to a bogus cpu index.
I haven't tracked it down all the way, but have gotten this far. If I add
the following patch, I get a panic on the BUG_ON if I have these two patches
in 2.6.23-rc8-mm1, but it boots just fine if I don't have these two patches.
It seems that the "cpu_sibling_map[cpu]" cpumask_t is empty (all zero
bits) with your two patches applied, but has some non-zero bits
otherwise, which leads to 'group' being NR_CPUS instead of a useful CPU
number. Unfortunately, I have no idea why the "cpu_sibling_map[cpu]"
cpumask_t is empty -- good luck on that part.
The patch that catches this bug earlier is this:
--- 2.6.23-rc8-mm1.orig/kernel/sched.c 2007-09-28 01:42:20.144561024 -0700
+++ 2.6.23-rc8-mm1/kernel/sched.c 2007-09-28 02:27:14.239075497 -0700
@@ -5905,6 +5905,7 @@ static int cpu_to_phys_group(int cpu, co
#else
group = cpu;
#endif
+ BUG_ON(group == NR_CPUS);
if (sg)
*sg = &per_cpu(sched_group_phys, group);
return group;
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Mirek23 @ 2007-09-28 9:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1189180542.4826.33.camel@louie>
Dear All,
Finally I have sorted out few problems with linux and u-boot and I have
tried to come back to the jffs2 and mtd partitioning issue.
I am using CFI driver and I pass partitioning information from command line
via u-boot.
This part works fine:
Unfortunatly I have the problem when accesing the flash partitions because
my Avnet evaluation board is designet in such a way that the data should be
accessed in the mode x16 (16 bits in each goal).
Linux CFI driver is able to detect the x16 mode but it does not handle it
correctly.
I will give you an example:
My mtd1 partition contains the u-boot environment. When I print the mtd1
contents with (busybox) hexdump I get:
00000000 eb 92 00 00 62 6f 00 00 61 72 00 00 3d 63 00 00
|....bo..ar..=c..|
00000010 73 6f 00 00 3d 74 00 00 55 4c 00 00 39 36 00 00
|so..=t..UL..96..|
00000020 20 72 00 00 74 3d 00 00 65 76 00 00 66 73 00 00 |
r..t=..ev..fs..|
00000030 77 20 00 00 73 72 00 00 74 3d 00 00 39 2e 00 00 |w
..sr..t=..9...|
00000040 39 2e 00 00 34 2e 00 00 33 3a 00 00 70 74 00 00
|9...4...3:..pt..|
00000050 6c 64 00 00 31 2f 00 00 63 5f 00 00 78 2c 00 00
|ld..1/..c_..x,..|
00000060 70 20 00 00 70 3d 00 00 3a 3a 00 00 72 74 00 00 |p
..p=..::..rt..|
00000070 34 2d 00 00 72 65 00 00 65 74 00 00 3a 64 00 00
|4-..re..et..:d..|
When I copy the contents of the /dev/mtd1 to the file by 2 bytes (bs=2) I
get correct
readout:
dd if=/dev/mtd1 of=./u-boot_Env.txt bs=2 count=128k
hexdump ./u-boot_Env.txt
00000000 eb 92 c9 6d 62 6f 6f 74 61 72 67 73 3d 63 6f 6e
|...mbootargs=con|
00000010 73 6f 6c 65 3d 74 74 79 55 4c 30 2c 39 36 30 30
|sole=ttyUL0,9600|
00000020 20 72 6f 6f 74 3d 2f 64 65 76 2f 6e 66 73 20 72 | root=/dev/nfs
r|
00000030 77 20 6e 66 73 72 6f 6f 74 3d 31 32 39 2e 31 32 |w
nfsroot=129.12|
00000040 39 2e 31 34 34 2e 31 31 33 3a 2f 6f 70 74 2f 65
|9.144.113:/opt/e|
00000050 6c 64 6b 34 31 2f 70 70 63 5f 34 78 78 2c 74 63
|ldk41/ppc_4xx,tc|
The real problems begin when I want to deal with jffs2 file system.
I have mtd3 partition which is intended to hold jffs2 fs.
To create the jffs2 fs I do:
./mkfs.jffs2 --pad=0xA0000 --eraseblock=0x20000 --root=/tmp/bin/mtd1/work/
--output=image2.jffs2
flash_erase /dev/mtd3
dd if=./image2.jffs2 of=/dev/mtd3 bs=2 count=655360
After that I have jffs2 fs under /dev/mtd3.
When I try to mount the jffs2 partition fun begins:
mount -t jffs2 /dev/mtdblock3 /mnt
[ 2828.462121] jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003,
0x00000000) has invalid CRC 0xf0600000 (calculated 0xf9d690b3)
[ 2828.610485] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000008: 0xf060 instead
[ 2828.719326] jffs2_scan_eraseblock(): Node at 0x0000000c {0x1985, 0xe001,
0x00000000) has invalid CRC 0xc3200000 (calculated 0x92fedd67)
[ 2828.870047] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000014: 0xc320 instead
[ 2828.979854] jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00000024: 0x46fc instead
.
.
.
.
[ 2834.858103] Further such events for this erase block will not be printed
[ 2835.029913] Cowardly refusing to erase blocks on filesystem with no valid
JFFS2 nodes
[ 2835.124378] empty_blocks 0, bad_blocks 0, c->nr_blocks 5
mount: mounting /dev/mtdblock3 on /mnt failed
I have examined carefully the above output and what I see is that linux does
not properly access the flash memory:
I did the hexdump on the image2.jffs2 (which is placed in /dev/mtd3) and
compared it with the jffs2 mount messages:
hexdump -C image2.jffs2
00000000 19 85 20 03 00 00 00 0c f0 60 dc 98 19 85 e0 01 |..
......`......|
00000010 00 00 00 31 c3 20 dd 5d 00 00 00 01 00 00 00 00 |...1.
.]........|
jffs2_scan_eraseblock(): Node at 0x00000000 {0x1985, 0x2003, 0x00000000) has
invalid CRC 0xf0600000 (calculated 0xf9d690b3)
The linux mount complains about wrong CRC (invalid CRC 0xf0600000) but in
the memory it is
f0 60 dc 98 (so it means that it was read in byte by byte mode but not in
x16 (2 bytes) mode).
Does somebody know how to fix this problem?
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12937526
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 2.6.23-rc8 dies somewhere during boot!?
From: Gerhard Pircher @ 2007-09-28 9:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18172.15699.359375.286439@cargo.ozlabs.ibm.com>
-------- Original-Nachricht --------
> Datum: Fri, 28 Sep 2007 09:31:31 +1000
> Von: Paul Mackerras <paulus@samba.org>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: 2.6.23-rc8 dies somewhere during boot!?
> You appear to have a working 16550-style serial port which the udbg
> infrastructure sees. Thus you should be able to use xmon, talking to
I couldn't get udbg running yet. Maybe i didn't specify a proper kernel
boot argument.
> it via the serial port. Put "xmon" on the kernel command line and the
> kernel will drop into xmon early in the boot process (in setup_arch).
> Then, either the kernel will oops at some point and drop into xmon,
> and you can then inspect memory and registers and get a stack trace,
> or it will hang at some point. If it hangs, you can work out where it
> hangs by putting in breakpoints at various points and seeing which
> breakpoints you get to (this might take several boots).
Okay, I'll investigate it. Is there a documentation for xmon (Google
wasn't really helpful in this case).
Thanks!
regards,
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: Valentine Barshak @ 2007-09-28 14:23 UTC (permalink / raw)
To: David Gibson, linuxppc-dev
In-Reply-To: <20070925022935.GI30338@localhost.localdomain>
David Gibson wrote:
> On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
>> Currently zImage is linked at the 4MB base address.
>> Some platforms (using cuboot, treeboot) need the zImage's
>> entry point and base address. They place zImage exactly
>> at the base address it's been linked to. Sometimes 4MB left
>> at the start of the memory is simply not enough to unpack zImage.
>> This could happen with initramfs enabled, since the kernel image
>> packed along with initramfs.cpio could be over 5MB in size.
>> This patch checks vmlinux image size and links zImage at
>> the base address that is equal to the unpacked image size
>> aligned to 4MB boundary. This way zImage base address is 4MB
>> only if unpacked kernel image size is less then 4MB.
>
> Good plan. However..
>
> [snip]
>> diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
>> --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
>> +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
>> @@ -3,7 +3,7 @@
>> EXTERN(_zimage_start)
>> SECTIONS
>> {
>> - . = (4*1024*1024);
>> + . = ALIGN((_kend - _kstart), (4*1024*1024));
>
> ..I don't see any reason to keep the 4MB granularity. I would just
> align the address to say a 64k boundary (64k because that's the
> granularity used in the normal ABI).
Looking deeper at this I've found that currently u-boot thinks that
memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
defined as (8 << 20)), although all physical memory is identity mapped.
That's why it puts command line and board info structure as high as
possible within the first 8MB. This worked fine with uImage, since
u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
(we need space at the start of the memory to eventually put vmlinux
image there). So, if unpacked kernel image crosses 8MB boundary, it gets
damaged by u-boot when it prepares cmd_line and bdinfo. The possible
workaround for that is to always link zImage at >=8MB base or to have
4MB granularity like this:
+ . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
Reserve at least 64K for u-boot cmd_line and bdinfo.
Thanks,
Valentine.
>
>> _start = .;
>> .text :
>> {
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>
^ permalink raw reply
* [patch 2/2] mpc8349emitx.dts: Setup USB-DR for peripheral mode.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ linux-2.6.23-rc8/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -99,6 +99,7 @@
#size-cells = <0>;
interrupt-parent = < &ipic >;
interrupts = <26 8>;
+ dr_mode = "peripheral";
phy_type = "ulpi";
};
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 1/2] Fix mpc834x USB-MPH configuration.
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
In-Reply-To: <20070928142113.163317000@sunsite.dk>
mpc834x USB-MPH configuration got broken by commit
6f442560021aecf08658e26ed9a37e6928ef0fa1. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
arch/powerpc/platforms/83xx/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
===================================================================
--- linux-2.6.23-rc8.orig/arch/powerpc/platforms/83xx/usb.c
+++ linux-2.6.23-rc8/arch/powerpc/platforms/83xx/usb.c
@@ -76,14 +76,14 @@
if (port0_is_dr)
printk(KERN_WARNING
"834x USB port0 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB0;
+ sicrl &= ~MPC834X_SICRL_USB0;
}
prop = of_get_property(np, "port1", NULL);
if (prop) {
if (port1_is_dr)
printk(KERN_WARNING
"834x USB port1 can't be used by both DR and MPH!\n");
- sicrl |= MPC834X_SICRL_USB1;
+ sicrl &= ~MPC834X_SICRL_USB1;
}
of_node_put(np);
}
--
Bye, Peter Korsgaard
^ permalink raw reply
* [patch 0/2] MPC834x USB patches
From: jacmet @ 2007-09-28 14:21 UTC (permalink / raw)
To: galak, leoli, linuxppc-dev
MPC834x USB patches. The first is quite serious and would be nice
to get in 2.6.23.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-09-28 15:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200709271907.50479.jbe@pengutronix.de>
On Thursday 27 September 2007 19:07, Juergen Beisert wrote:
> On Friday 10 August 2007 11:51, Domen Puncer wrote:
> > Not for merge (yet)! But please do review.
> >
> > fec_mpc52xx driver (not in-tree, but floating around) isn't in very
> > good shape, so I tried to change that.
> > Diff against original is quite big (fec_phy.c is completely rewritten)
> > and confuzing, so I'm including whole drivers/net/fec_mpc52xx/ .
> >
> > I still have 'make CONFIG_FEC_MPC52xx_MDIO=3Dn compile and work' on my
> > TODO, maybe even ethtool support.
I add a few more debug outputs and now with this driver I can run a
$ nmap <ip>
from my host against the target and target's network stops always at the sa=
me=20
point.
The last output from the driver is (with DEBUG macro defined):
net eth0: ievent: 08020000
and no further interrupt occurs anymore (I checked all three interrupt entr=
y=20
functions)
nmap on host's side outputs:
Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-28 16:56 CEST
Interesting ports on 192.168.23.226:
Not shown: 852 filtered ports, 843 closed ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
Nmap finished: 1 IP address (1 host up) scanned in 14.120 seconds
But I can't run it a second time, as the network on target's side doesn't=20
respond. Any idea?
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ 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