Re: [microblaze-uclinux] RE: [PATCH v3] Device tree bindings for Xilinx devices
Hi Grant, >> Hi Steve and all, >> >Here's a full .dts generated using an updated version of >> >gen_mhs_devtree.py, following the proposal. >> >It happens to be a microblaze system, but you get the idea. >> >> I think that is no good idea generate dts with all information. >> Especially information about PVR - number 2 means - Full PVR and you can >> obtain information directly from PVR. It is waste of memory space. >> xilinx,pvr = <2>; >> >> In my opinion will be better generate only parameters which you want not all. >> That smells with unusable parameters. > >That is the hard part about crafting the dts; deciding which >parameters the OS is going to care about and which ones are >irrelevant. The goal is to sufficiently and uniquely describe the >board so that the OS can easily figure out what exactly what it needs >to do to drive the board, but not to try and describe every aspect >which it knows about. Anything that is pollable (ie. USB devices) >doesn't need to be in the tree. > >It's also important to remember that the device tree will *never* be >perfect. Eventually something will come up that the device tree >doesn't describe well(a bug/quirk, something described poorly, etc). >In this case, as long as the device tree is specific enough to >identify which version of the board it is running on; we can alwasy >add platform specific fixups for that unique system. > yes, but I think that is the right time to specify which parameters are relevant. I will focus on in EDK renerator. Michal Simek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: embedded a default dtb in the kernel (was merge dtc)
On Fri, Oct 19, 2007 at 01:09:39PM -0600, Grant Likely wrote: > On 10/19/07, Leisner, Martin <[EMAIL PROTECTED]> wrote: > > Is there a way to embed a default dtb into the kernel? > > When I build a kernel, I want to embed a dtb into it -- > > so I don't have to deal with the headaches of finding the > > right file to match the right board (its always easier to > > deal with 1 file than 2). > > > > If there is, it makes sense to put dtc into the tree. > > If there's not, there should be a way to embed dtb's; and put > > dtc and dts's into the tree. > > If there can't be (I haven't examined this but relaying my > > experiences), then it should be in a separate repository > > (but the DTS and DTC should be in one place). > > It was a little difficult to cobble together a working > > system the first time. > > > > Also, mkimage SHOULD definitely go in the tree. Its necessary > > to build, hence should be in the tree... > > Why? mkimage is u-boot specific, and hence is maintained by u-boot. > If you're not using u-boot, then you don't need mkimage. What is > wrong with it being a prereq like all the other tools we use? If > you're doing embedded development, you're installing non-distribution > cross toolchain anyway. The problem is that we build uImages at present, without option, for a bunch of targets that don't necessarily have u-boot. > dtc and mkimage are embedded development tools. They belong with the > embedded development toolchain. mkimage is already part of ELDK. dtc isn't just for embedded. ps3 uses it already, and more may well do so in future. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: embedded a default dtb in the kernel (was merge dtc)
On Fri, Oct 19, 2007 at 02:30:28PM -0400, Leisner, Martin wrote: > Is there a way to embed a default dtb into the kernel? > When I build a kernel, I want to embed a dtb into it -- > so I don't have to deal with the headaches of finding the > right file to match the right board (its always easier to > deal with 1 file than 2). You can't embed a dtb in the vmlinux, but zImages routinely contain an embedded dtb. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] DTC: Quiet a bogus "May be used uninitialized" warning.
On Fri, Oct 19, 2007 at 12:42:58PM -0500, Jon Loeliger wrote: > > Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> I don't like this one much. The warning is indeed bogus, and my compiler version, at least, doesn't generate it mulberryst:~/dtc$ gcc --version gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Putting in the initializer would mean that even on non-broken compilers, we wouldn't get the warning if we ever changed the contained code so that it really should generate an unitialized variable warning. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] DTC: Reformat grammar rules to not mix language syntax and yacc syntax.
On Fri, Oct 19, 2007 at 12:42:32PM -0500, Jon Loeliger wrote: > > Use consistent indenting on all rule actions. > > Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> Meh, I kind of did it that way to keep the simple rules less bulky, but I don't really care much either way. Acked-by: David Gibson <[EMAIL PROTECTED]> -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
On Fri, Oct 19, 2007 at 12:43:13PM -0500, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
Hrm I'm very dubious about this.
What compiler/platform is this? I can't off the top of my head think
of one where size_t shouldn't be promoted to int automatically.
Or there's the %z modifier, which explicitly specifies a size_t, but
I'm not sure if that's C99 or a glibc extension.
> ---
> tests/get_name.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tests/get_name.c b/tests/get_name.c
> index 2481741..a76bdf8 100644
> --- a/tests/get_name.c
> +++ b/tests/get_name.c
> @@ -55,7 +55,7 @@ void check_name(void *fdt, const char *path)
>
> if (len != strlen(getname))
> FAIL("fdt_get_name(%s) returned length %d instead of %d",
> - path, len, strlen(getname));
> + path, len, (int) strlen(getname));
>
> /* Now check that it doesn't break if we omit len */
> getname2 = fdt_get_name(fdt, offset, NULL);
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
On Fri, Oct 19, 2007 at 12:43:30PM -0500, Jon Loeliger wrote:
>
> Add support for the "/dts-version/ ;" statment.
> Make legacy DTS files version 0 whether explicitly stated
> or implied by a lack of /dts-version/ statement.
>
> Begin supporting a new /dts-version/ 1 that changes the
> format of the literals in a DTS source file. In the new
> format, hex constants are prefixed with 0x or 0X, and
> bare numbers are decimal or octal according to standard
> conventions.
Hurrah! Except that there's a few small details, and one biggish
detail that concern me.
> Property names have been limited to start with
> characters from the set [a-zA-Z,._#?]. That is, the
> digits and the expression symbols have been removed.
Good call. Note that the rationale for the property and node name
regexes is a bit fuzzy: there's a standard for what's allowed in
IEEE1275, but existing IBM and Apple device trees break it in a number
of ways.
> Use of "d#', "o#", "h#" and "b#" are gone in version 1.
Also good. We might want to keep b#, since there's no C way of doing
binary literals, but in that case I'd suggest recognizing it at the
lexical level, not the grammar level as we do now (which would mean a
space between the b# and the digits would no longer be permissible).
> Several warnings are introduced for debatable constructs.
>
> - Only /dts-version/ 0 and 1 are supported yet.
>
> - A missing /dts-version/ statement garners a
> suggestion to add one, and defaults to verion 0.
>
> - The /memreserve/ construct using "-" for ranges looks
> suspiciously like the subtraction of two expressions,
> so its syntax has been changed to use ".." as the range
> indicator.
Ah, yes. An irritating change, but a necessary one, I agree.
Now my big concern with this patch: the dts_version global, set by the
parser, used by the lexer. I assume you've tested this and it works
in practice, but you're relying on the semantic action from the .y
file being executed before the lexer meets any token that depends on
it.
I don't know about you, but I have to think pretty hard about how flow
of control will move between lexer and parser rules in a shift-reduce
parser at the best of times. With the %glr-parser option, bison will
use the Tomita algorithm. That means the parser state could be split
if there are ambiguities, or non-LALR(1) portions of the grammar
(which there are). In that case the execution of the parser rules
will be delayed until after the split is resolved again, however many
tokens down the track.
Now, I'll grant that such a grammar ambiguity is unlikely around the
version statement. But given the complexity of the situation, it
seems pretty risky to rely on execution ordering between parser and
lexer - I don't even know if there's a guarantee that bison won't
buffer lexer tokens before parsing them, which would screw us up in a
much less involved way.
Therefore, I'd prefer that instead of having this general version
number, we introduce a separate token for each new version. So
/dts-version-1/ or whatever. Any new, incompatible, dts version is a
big deal in any case - not something we want to happen often - so a
new token for each version is not a big deal, I think. With this
approach, the version flag can be tripped in the lexer, and the
ordering of lexer rule execution is obvious.
A few more minor comments below:
[snip]
> diff --git a/dtc-lexer.l b/dtc-lexer.l
> index 278a96e..a1c52c4 100644
> --- a/dtc-lexer.l
> +++ b/dtc-lexer.l
> @@ -22,12 +22,19 @@
>
> %x INCLUDE
> %x CELLDATA
> +%x CELLDATA_LEGACY
> %x BYTESTRING
> +%x BYTESTRING_LEGACY
> %x MEMRESERVE
> +%x MEMRESERVE_LEGACY
With the new syntax, integeral literals should no longer be ambiguous
with property or node names. Therefore, we should only need legacy
CELLDATA and MEMRESERVE states, new-style literals can be recognized
in INITIAL state.
I'm also inclined to leave the syntax for bytestrings as it is, in
whichcase we should only need one lexical state for that, too.
[snip]
> +<*>{DOT}{DOT}{
You should be able to just use \.\. or ".." here rather than having to
indirect through a character class.
[snip]
> +0(x|X){HEXDIGIT}+{
Does C recognize both 0x and 0X, or just 0x? I don't remember off the
top of my head.
[snip]
> +u64 expr_from_string(char *s, unsigned int base)
> +{
> + u64 v;
> + char *e;
> +
> + v = strtoull(s, &e, base);
> + if (*e) {
> + fprintf(stderr,
> + "Line %d: Invalid literal value '%s' : "
> + "%c is not a base %d digit; %lld assumed\n",
> + yylloc.first_line, s, *e,
> + base == 0 ? expr_default_base : base,
> + (unsigned long long) v);
Do we need this error checking? Won't the regexes mean that the
string *must* be a valid literal by this point?
[snip]
> @@ -46,25 +47,27 @@ extern struct boot_info *the_boot_info;
> int hexlen;
> u64 addr;
> st
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
David Gibson <[EMAIL PROTECTED]> writes: > What compiler/platform is this? I can't off the top of my head think > of one where size_t shouldn't be promoted to int automatically. Only types narrower than int are subject to integer promotion. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] restore arch/ppc/boot cflags
Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory addition to CFLAGS that was being used by the subdirectory builds. For the other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly sets that to empty as it is explicitly for a single directory only. Append to KBUILD_CFLAGS instead. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- The commit also changed xtensia to export EXTRA_CFLAGS from its boot directory, that needs to be fixed too. from ARCH=ppc prep_defconfig: /data/home/miltonm/work.git/arch/ppc/boot/of1275/write.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/read.c:11:20:/data/home/miltonm/work.git/arch/ppc/boot/of1275/ofstdio.c:11:20: error: error: of1275.h: No such file or directoryof1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/release.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/ofinit.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/map.c:12:22: error: nonstdio.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/map.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/getprop.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/common/ns16550.c:14:20: error: serial.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/common/ns16550.c:13:22: error: nonstdio.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/enter.c:11:20: error: of1275.h: No such file or directory error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/claim.c:12:22: error: nonstdio.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/claim.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/of1275/finddevice.c:11:20: error: of1275.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/common/bootinfo.c:14:22: error: nonstdio.h: No such file or directory /data/home/miltonm/work.git/arch/ppc/boot/common/misc-common.c:18:22: error: nonstdio.h: No such file or directory of1275.h: No such file or directory diff --git a/arch/ppc/boot/Makefile b/arch/ppc/boot/Makefile index 487dc66..52a0d38 100644 --- a/arch/ppc/boot/Makefile +++ b/arch/ppc/boot/Makefile @@ -13,6 +13,7 @@ # modified by Cort ([EMAIL PROTECTED]) # +KBUILD_CFLAGS += -fno-builtin -D__BOOTER__ -Iarch/$(ARCH)/boot/include HOSTCFLAGS += -Iarch/$(ARCH)/boot/include BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: boards in arch/ppc -> arch/powerpc for 85xx
On Wed, 2007-10-17 at 19:54 -0500, Kumar Gala wrote: > This really cracked me up. I have to ask what the sbc8560 was doing > in the boot of your car? The Land Rover was full. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device trees and audio codecs
I'm working on ALSA ASoC support for a codec chip on my mpc5200 based target hardware. How should the codec be represented in the device tree? Under ASoC the device drivers for the codec chips are platform independent. In the current ASoC model there are three device drivers: i2s (or spi, etc), the generic codec, and a platform specific 'fabric' driver. Some codecs are linked to both i2c and i2s. The fabric driver corresponds to the 'layout-id' in the Apple model. It tells how to configure the generic codec driver for the specific configuration needed by the actual platform hardware. For development purposes I'm using an Efika as a target platform. It is easy enough to load the i2s driver using the device tree. I can add entries to the i2s node to trigger loading of the generic sta9766 codec driver. How do I trigger loading the Efika specific fabric driver? My target hardware has a codec that is linked to both i2s and i2c. How should it be represented? Apple has three entries. One for i2s, one for the codec, and one for soundchip. What is the soundchip entry, does it correspond to real hardware? /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: name "i2s-a" device_type "soundbus" compatible "i2sbus" built-in reg 0001 1000 8000 0100 8100 0100 interrupts 001e 0001 0001 0002 interrupt-parent ff981a38 platform-headphone-mute ff9828a0 platform-amp-mute ff9829f8 platform-hw-reset ff982b48 platform-linein-detect ff982c98 platform-headphone-detect ff982e58 platform-get-enable ff97c3b0 platform-enable ff97c3b0 platform-disable ff97c3b0 platform-get-clock-enable ff97c3b0 platform-clock-enable ff97c3b0 platform-clock-disable ff97c3b0 platform-get-sw-reset ff97c3b0 platform-clear-sw-reset ff97c3b0 platform-sw-reset ff97c3b0 platform-get-cell-enable ff97c3b0 platform-cell-enable ff97c3b0 platform-cell-disable ff97c3b0 linux,phandleff985b88 /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound: name "sound" device_type "soundchip" compatible "AOAbase" built-in layout-id0046 (70) object-model-version 0002 vendor-id106b (4203) platform-tas-codec-ref ff98cba8 linux,phandleff985d48 /proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]: name "codec" device_type "codec" compatible "tas3004" "codec" "" reg 006a (106) built-in platform-do-tas-codec-ref ff985d48 0800 0027 linux,phandleff98cba8 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] restore arch/ppc/boot cflags
On Sat, Oct 20, 2007 at 03:58:03AM -0500, Milton Miller wrote:
> Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
> addition to CFLAGS that was being used by the subdirectory builds. For the
> other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
> sets that to empty as it is explicitly for a single directory only.
> Append to KBUILD_CFLAGS instead.
Neat - I had not figured out that the assignmnet took effect
recursively.
I have applied following patch.
Sam
>From 437374e9a95062fe310b901e48585691edaf5dd0 Mon Sep 17 00:00:00 2001
From: Milton Miller <[EMAIL PROTECTED]>
Date: Sat, 20 Oct 2007 03:58:03 -0500
Subject: [PATCH] kbuild: restore arch/{ppc/xtensa}/boot cflags
Commit 9a39e273d4df0560c724c5fe71f6314a0583ca2b removed the boot directory
addition to CFLAGS that was being used by the subdirectory builds. For the
other files, that patch set EXTRA_CFLAGS, but Makefile.build explicitly
sets that to empty as it is explicitly for a single directory only.
Append to KBUILD_CFLAGS instead.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
arch/ppc/boot/Makefile|2 ++
arch/xtensa/boot/Makefile |3 ++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/boot/Makefile b/arch/ppc/boot/Makefile
index 487dc66..500497e 100644
--- a/arch/ppc/boot/Makefile
+++ b/arch/ppc/boot/Makefile
@@ -13,6 +13,8 @@
# modified by Cort ([EMAIL PROTECTED])
#
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -D__BOOTER__ -Iarch/$(ARCH)/boot/include
HOSTCFLAGS += -Iarch/$(ARCH)/boot/include
BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd
diff --git a/arch/xtensa/boot/Makefile b/arch/xtensa/boot/Makefile
index 9c5185f..40aa55b 100644
--- a/arch/xtensa/boot/Makefile
+++ b/arch/xtensa/boot/Makefile
@@ -8,7 +8,8 @@
#
-EXTRA_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
+# KBUILD_CFLAGS used when building rest of boot (takes effect recursively)
+KBUILD_CFLAGS += -fno-builtin -Iarch/$(ARCH)/boot/include
HOSTFLAGS += -Iarch/$(ARCH)/boot/include
BIG_ENDIAN := $(shell echo -e __XTENSA_EB__ | $(CC) -E - | grep -v "\#")
--
1.5.3.4.206.g58ba4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pasemi_mac: fix typo
Add missing &:
drivers/net/pasemi_mac.c: In function 'pasemi_mac_clean_rx':
drivers/net/pasemi_mac.c:553: warning: passing argument 1 of 'prefetch'
makes pointer from integer without a cast
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 9f9a421..ab4d309 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -550,7 +550,7 @@ static int pasemi_mac_clean_rx(struct pasemi_mac *mac, int
limit)
n = mac->rx->next_to_clean;
- prefetch(RX_RING(mac, n));
+ prefetch(&RX_RING(mac, n));
for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Sat, 2007-10-20 at 16:43 +1000, Michael Ellerman wrote:
> On Fri, 2007-10-19 at 17:53 -0700, David Miller wrote:
> > I don't see this, in all cases write_msi_msg() will transfer
> > the given "*msg" to entry->msg by this assignment in
> > drivers/pci/msi.c:
> >
> > void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> > {
> > ...
> > entry->msg = *msg;
> > }
> >
> > So as long as write_msi_msg() is invoked, it will be saved
> > properly.
> >
> > Platforms need not do this explicitly.
>
> I'm short on context here, and it's Saturday, so excuse me if I'm
> missing the point somewhere.
>
> On pseries machines we don't call write_msi_msg(), because we don't
> control the contents of the message, firmware does. So entry->msg will
> be bogus.
>
> That's a pity, but AFAIK it shouldn't be a problem because we don't
> enable CONFIG_PM on those machines anyway. If we ever want to we'll need
> to sort out with firmware how that will work WRT restoring MSI state.
>
The PCI error recovery that Linas is working on requires the MSI state
to be restored after we do PCI reset to recover from PCI errors.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] DTC: Appease the printf() format $Gods with a correct type.
On Sat, Oct 20, 2007 at 10:51:29AM +0200, Andreas Schwab wrote: > David Gibson <[EMAIL PROTECTED]> writes: > > > What compiler/platform is this? I can't off the top of my head think > > of one where size_t shouldn't be promoted to int automatically. > > Only types narrower than int are subject to integer promotion. Duh, yes. Sorry. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
rtlinux rtai interrupt latency
all, hi does anyone knows RTLinux, RTAI interrupt latency and schedule latency on the PPC440, PPC405? Thanks! buroc -- Add: Tianshui South Road 222, Lanzhou, P.R.China Tel: +86-931-8912025 Zip Code: 73 URL: oss.lzu.edu.cn Email: [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: rtlinux rtai interrupt latency
On Sun, 2007-10-21 at 10:45 +0800, Bai Shuwei wrote: > all, hi > does anyone knows RTLinux, RTAI interrupt latency and schedule > latency on the PPC440, PPC405? You'd have to ask Wind River. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
> Property names have been limited to start with > characters from the set [a-zA-Z,._#?]. That is, the > digits and the expression symbols have been removed. This cannot work; many property names start with a digit, for example. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
>> Use of "d#', "o#", "h#" and "b#" are gone in version 1. > > Also good. We might want to keep b#, since there's no C way of doing > binary literals, GCC supports "0b...", and it is proposed new ISO C syntax, too. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
