The kernel doesn't care if one CPU is in OF land while the others
are doing other stuff -- well you have to make sure the OF won't
try to use a hardware device at the same time as the kernel, true.
That statement alone hides an absolute can of worms btw ;-)
Oh I know. With a sane OF implement
The comment used to be inside the "if" block, is this
change correct?
You'd prefer an empty line in there?
Obviously, you should change the comment to include the
conditional, if that is what is needed.
[And, do we want all these changes anyway? I don't care
either way, both sides have thei
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
And ? I don't see why a mostly common implementations wouldn't work,
p
Not single thread -- but a "global OF lock" yes. Not that
it matters too much, (almost) all property accesses are init
time anyway (which is effectively single threaded).
Not that true anymore. A lot of driver probe is being threaded
nowadays,
either bcs of the new multithread probing bits, or
Leaving aside the issue of in-memory or not, I don't think
it is realistic to think any completely common implementation
will work for this -- it might for current SPARC+PowerPC+OLPC,
but more stuff will be added over time...
I see nothing supporting this IMHO bogus claim.
Please keep in mind
[snipping a bit for now]
It's easier to start merging powerpc and sparc I reckon
Well it won't hurt to merge and clean up these two first, sure.
and then, "fix"
that so that it works on x86 :-)
That works, if the goal is to just add x86/OLPC to the list of
platforms that have a device tree
Across different boots using the same 2.6.19 kernel on a quad-core xeon
I see huge variance in the migration_cost being reported during boot.
-migration_cost=39,3940
+migration_cost=25,4941
This CPU has a very large cache which could be key here...
L1 Instruction cache: 32KB, 8-way associative.
Hopefully this patch should solve steve's issue too.
Sure looks like it.
o Older binutils required explicit flags to mark a section allocatable
and executable(AX). Newer binutils automatically mark a section AX if
the name starts with .text.
More exactly, since 2.15 more section names ar
therefore you can't let multiple CPUs call
into OFW at one time. You must use some kind of locking mechanism,
and that locking mechanism is not simple because it has to not just
stop the other cpus, it has to be able to stop the other cpus yet
still allow them to receive SMP cross-calls from the
Kill OF? sparc does not want that IMO, how else should I return to
the 'ok' prompt?
PowerPC kills OF because it really has to,
No it doesn't. It has to on some (very common, heh) subarchs.
that's one of numerous
reasons that it started sucking the device tree into a kernel copy
early in the
In fact, the 'ok' prompt is an ENORMOUS pain in the ass to support
on machines with USB keyboards, because sharing the USB host
controller is beyond non-trivial. I've never implemented support
for that on sparc64 and I frankly have no desire to do the work
necessary to support that. It simply is
One would also expect that cache scrubbing requires hardware
support.
You could just write-back invalidate the whole cache
periodically if there is no explicit hardware support
for cache scrubbing. Less efficient, sure :-)
Signed-off-by: doug thompson <[EMAIL PROTECTED]>
Shouldn't you
And check that we didn't end up stupidly having the initrd share a page
with something else ... (like not aligned end or such thingy).
David tested that yesterday, it's not the case. Too bad,
would have been too easy ;-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe linu
I thought the motivation for div64() was that a 64:32->32 divide could
be done a lot faster on a number of platforms (including the important
x86) than a generic 64:64->64 divide, but gcc doesn't handle the
devolution automatically -- there is no such libgcc function.
That there's no such func
I've not been able to reproduce it since, but I know others (BCC'ed
on
this note) have seen it and might prod them to come forth with
details
(and broken .config files)
In my case, disabling CPU_FREQ_PMAC made the failure go away.
After reverting this patch, CPU_FREQ_PMAC is once again operati
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
...
-47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
+49 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47, bu
pci: each device/function has a unique irq, drivers need not know
about it afaics.
Then there is msi and with msi-x you can have up to 4K irqs.
I have to admit I still don't really understand how this works
at all. Can a driver that uses msi-x have different handlers
for each of those inte
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47, but not 49 either.
Unless it's not CPM5 but CPM3?
Just allocate the four slots and we'll deal with
anything above this in custom products.
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old
Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.
That sounds like more hassle than it's worth. The discontinuous range
may be ann
Please, let's just leave the four we have
No one is suggesting otherwise.
and let
the driver just allocate increasing minor numbers.
If anyone has a product with more than 4 UARTs,
they will have to figure out what to do with the
additional minors.
Since you say no one has ever used more tha
I just got an answer from the hypervisor architects. It turns out
that the hardware _does_ prevent the device from sending MSI messages
to another partition. The OS _can_ write whatever it likes to the MSI
address and data registers. It can potentially lose interrupts (or, I
expect, get the dev
you could use io delay, one outb uses roughly 1us iirc.
On LPC, yes -- or 0.5us or something like that. On ISA it's
a lot faster, on PCI too -- better do 20 or so outb's to be
safe. Or use a *real* timer instead, you'll have to abstract
this for portability anyway...
Segher
-
To unsubscribe
What do you mean by
+ for (reps = 0; reps >= 0; reps++) {
?
If you will not reps is negative. Roughly it is a loop
that will timeout eventually if a usb debug cable is not present.
So since I didn't know how many loop iterations made sense I allowed
it to loop for 2^31 times or until r
Adjusting gcc flags to eliminate optimizations is another way to go.
Adding -fwrapv would be an excellent start. Lack of this flag breaks
most code which checks for integer wrap-around.
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy code).
Lack of the flag does not break any valid C code, only code
making unwarranted assumptions (i.e., buggy code).
Right, if "C" means "strictly conforming ISO C" to you.
Without any further qualification, it of course does, yes.
(in which case, nearly all real-world code is broken)
Not "nearl
I'll happily turn off compiler features that are "clever optimizations
that never actually matter in practice, but are just likely to possible
cause problems".
The "signed wrap is undefined" thing doesn't fit in this category
though:
-- It is an important optimisation for loops with a signed
(in which case, nearly all real-world code is broken)
Not "nearly all" -- but lots of code, yes.
I wouldn't say "lots of code". I would say "all real projects".
All projects that tell the compiler they're written in ISO C,
while they're not, can easily break, sure. You can't say this
is GCC
The largest value we use here is 0x0200. Perhaps v4l2_std_id
shouldn't
be 64-bit?
Too late to change it to 32 bits. It is at V4L2 userspace API since
kernel 2.6.0. We can, however use this approach as a workaround, with
the proper documentation.
Maybe with a BUG_ON(id > UINT_MAX) ?
If t
For a different mailing list indeed; let me just point
out
that for certain important quite common cases it's an
~50%
overall speedup.
Hmm, what code was that? 'signed int does not wrap around' does not
seem to provide _that_ much info...
One of the recent huge threads on the GCC dev list has
setcc() in math-emu is written as a gcc extension statement expression
macro that returns a value. However, it's not used that way and it's
not needed like that, so just make it a do-while non-extension macro
so that we don't use an extension when it's not needed.
Looks fine, except
-#define
I want this:
char v[4];
...
memcmp(v, "abcd", 4) == 0
compile to single cmpl on i386. This (gcc 4.1.1) is ridiculous:
callmemcmp
i686-linux-gcc (GCC) 4.2.0 20060410 (experimental)
movl$4, %ecx#, tmp65
cld
movl$v, %esi#, tm
-#define setcc(cc) ({ \
+#define setcc(cc) do { \
partial_status &= ~(SW_C0|SW_C1|SW_C2|SW_C3); \
- partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); })
+ partial_status |= (cc) & (SW_C0|SW_C1|SW_C2|SW_C3); \
+ } while (0)
There's an extra tab in that last line. Could you also
plea
There's an extra tab in that last line. Could you also
please fix the indenting (use a tab, not spaces) -- I know
it was there originally, but since there are only a few
lines in that file like that... :-)
how's this one?
I meant fix all the wrongly indented lines in that file (there
are onl
With such a change, you would not need to grep for it. You could use
binutils on it. `objdump -sj .rodata.uts vmlinux` would be a start.
Maybe not the prettiest output, but guaranteed to contain only the
banner.
objcopy -j .rodata.uts -O binary vmlinux >(the-checker-script)
Segher
-
To unsubs
../drivers/char$ objcopy -j .modinfo -O binary sonypi.ko
objcopy: stvfMiji: Permission denied
Why does it want to create a file there? This one works better:
objcopy works in-place when only one file argument is passed.
Yeah. The >(...) syntax in my example provides such a file;
of cours
CC [M] drivers/kvm/vmx.o
{standard input}: Assembler messages:
{standard input}:3257: Error: bad register name `%sil'
make[2]: *** [drivers/kvm/vmx.o] Error 1
make[1]: *** [drivers/kvm] Error 2
make: *** [drivers] Error 2
Am I missing something or this is a real problem?
What's on (and sround
Segher has a modification to the devtree patch that creates a lower
level ops vector that can be implemented with callback or
non-callback.
It is still being tested.
It currently only hooks up OLPC, and I don't have any of
those [hint hint], so I need external testers. I'll send
the patch to
I'd like to put in my $.02 in favor of having a way to pass the OF
device tree to the kernel, in much the same way we pass stuff like
ACPI and PIRQ and MP tables now.
This works fine for just passing the device tree, but it will fail for
the next step of being able to use the firmware in the OS,
It's unlikely that this driver will ever be of any use on other
architectures.
It's already being used, for example, the AMD8111 is used
one some PowerPC systems (some with IDE connected even).
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
You don't need to mention _all_ compatible devices in
the "compatible" property, only the few that matter;
typically the oldest one, and sometimes some intermediate
device that has extra features over the original one.
The oldest one is difficult to find out sometime. Can we only set the
self na
So we could remove the "#define _GNU_SOURCE" at the top
of scripts/kallsyms.c too, presumably? If not (i.e. if there are
more GNUisms left in that file anyway), then I'm not sure if we
really gain by the change.
yes, i believe this is true
I only tried in on x86 with my toolchain and it works,
Having the scripts work with other shells is very helpful for porting,
cross building and the like.
I think it is fair game to require bash to build the
kernel -- after all, GCC and GNU make are required
already, and bash has many helpful features that not
every POSIX shell has.
Also on Linux
gcc is a C compiler and claims to follow the C standard.
Not with the options the kernel build uses. But, close
enough -- the differences are really minor stuff.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
Hopefully correct handling of integer constant expressions. Please,
review.
Heh... The first catches are lovely:
struct fxsrAlignAssert {
int _:!(offsetof(struct task_struct,
thread.i387.fxsave) & 15);
If I understand correctly what bugs you are talking about,
most (all?) of those were solved in the dark ages already
(i.e., the 3.x series).
Alas, no. gcc is amazingly (and inconsistently) sloppy about the
things it accepts as integer constant expressions.
Ah yes, now I see what you were talk
Why? I'd say it's not better than BUILD_BUG_ON_ZERO() use
instead of that ?:
Oh, _that_ part I have no problem with. It's more that it seems that
the
gcc optimization is ok at least as an extension.
Sure, but it's not an extension (yet), but an implementation
side-effect; it would have to b
Humm... Right, so __builtin_offsetof() needs special treatment too.
Oh, bugger. Is
offsetof(struct foo, a.x[n])
a documented extension?
It is. See info gcc -> C Extensions -> Offsetof
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
don't forget -> if you're going to accept extra stuff. GCC forgot ->
with the parser rewrite, yes I filed a PR.
-> is not allowed within the second arg to __builtin_offsetof().
Or do you mean something else? What's the PR #, and did it ever
get fixed?
Segher
-
To unsubscribe from this list:
In my experience, -Os produced faster code on gcc-2.95 than -O2 or -O3.
On what CPU? The effect of different optimisations varies
hugely between different CPUs (and architectures).
It was not only because of cache considerations, but because gcc used
different tricks to avoid poor optimizatio
then do we need a new option 'optimize for best overall performance'
that goes for size (and the corresponding wins there) most of the
time, but is ignored where it makes a huge difference?
That's -Os mostly. Some awful CPUs really need higher
loop/label/function alignment though to get any
pe
Also note that whether or not it is profitable to unroll
a particular loop depends largely on how "hot" that loop
is, and GCC doesn't know much about that if you don't feed
it profiling information (it can guess a bit, sure, but it
can guess wrong too).
actually, what you are saying is that the
-Os is "as fast as you can without bloating the code size",
so that is the expected result for CPUs that don't need
special hand-holding around certain performance pitfalls.
this sounds like you are saying that people wanting performance should
pick -Os.
That is true on most CPUs. Some CPUs
In my experience, -Os produced faster code on gcc-2.95 than -O2 or
-O3.
On what CPU? The effect of different optimisations varies
hugely between different CPUs (and architectures).
x86
That's not a CPU, that's an architecture. I hope you
understand there are very big differences between di
+ k) RapidIO
+
+ Required properties:
+
+- device_type : Should be "rapidio"
There is no OF binding, so no.
+- compatible : Should be "fsl,rapidio-v0.0" or "fsl,rapidio-v1.0"
+ and so on. The version number is got from IP Block Revision
+ Register of RapidIO controller.
+- device_type : Should be "rapidio"
There is no OF binding, so no.
So, we need to define it.
If you want to. Until that has been done, don't use
a "device_type". Linux won't use it, anyway.
+- compatible : Should be "fsl,rapidio-v0.0" or
"fsl,rapidio-v1.0"
+ and so on. Th
+- device_type : Should be "rapidio"
There is no OF binding, so no.
So, we need to define it.
If you want to. Until that has been done, don't use
a "device_type". Linux won't use it, anyway.
Do you have another ideas about that? Only remove it?
Yeah, remove it.
Using IP Block Rev
Not at all. On an 8641 it could be
compatible = "fsl,mpc8641-rapidio" "fsl,mpc8548-rapidio";
which states "this is the 8641 thing and it is compatible
to the 8548 thing". Perfectly clear.
The concern is this isn't just compatible = "..8641.." "..8548.." but
something like:
"..8641
+ [EMAIL PROTECTED] {
+ #interrupt-cells = <2>;
Hm, why define that prop for a node with no children?
+ interrupts = <17 8>;
+ interrupt-map = <0 0 0 1 700 17 8>;
+ interrupt-map-mask = <0
gcc for i386 can be used with the assembly prefix ".code16gcc" to
generate
16-bit (real-mode) code. This header file provides the assembly
prefix.
This only works correctly with newer GCCs if you pass the
-fno-toplevel-reorder option (and it only works on older
GCC versions by accident). Th
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
gcc for i386 can be used with the assembly prefix ".code16gcc" to
generate
16-bit (real-mode) code. This header file provides the assembly
prefix.
This only works correctly with newer GCCs if you pass the
-fno-toplevel-reorder option (and it only works on older
GCC versions by accident).
And
gcc for i386 can be used with the assembly prefix ".code16gcc" to
generate
16-bit (real-mode) code. This header file provides the assembly
prefix.
This only works correctly with newer GCCs if you pass the
-fno-toplevel-reorder option (and it only works on older
GCC versions by accident).
And o
Nope. The builtins not only vary between gcc versions, but they also
have a nasty tendency to generate calls to library functions,
sometimes
libgcc functions. Hence -ffreestanding.
-ffreestanding will still generate calls to libgcc functions.
-ffreestanding doesn't disable _all_ of the C li
It seems to me GCC should grow an option to insert .code16gcc
by itself (-m16 perhaps?)
-m16 is the right thing,
Probably not actually, -m16 might have 16-bit "int" etc.
-mabi=16 is closer to what other architectures do here.
and it also provides a proper hook for
eventually having a real 1
Nope. The builtins not only vary between gcc versions, but they
also
have a nasty tendency to generate calls to library functions,
sometimes
libgcc functions. Hence -ffreestanding.
-ffreestanding will still generate calls to libgcc functions.
-ffreestanding doesn't disable _all_ of the C l
Looks good, except you don't want -fno-unit-at-a-time if
-fno-toplevel-reorder works. And of course it would be
good to get rid of -fno-strict-aliasing, but let's not
go there today ;-P
OK, how does this look:
CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP -D__KERNEL__ \
This scales with the number of processors since there is one
decrementer per core (is it per thread on SMT chips?
I don't know).
One per core.
No, each thread has its own decrementer, but the timebase is shared.
Argh, of course you're right, I'm reading the wrong ISA
version again. Sorry.
Yeah, allmodconfig tends to fall over in a heap on a lot of the
less-lavishly-maintained architectures.
To be fair, almost all of the powerpc allmodconfig build
problems are caused by x86-only drivers (and most of those
I doubt still work on x86, even).
Segher
-
To unsubscribe from this list:
I'm pretty sure that no ppc64 machine needs alias resolution in
the kernel,
although some are VIPT. Last time we discussed this, Segher
explained it
to me, but I don't remember which way Cell does it. IIRC, it
automatically
flushes cache lines that are accessed through aliases.
Ah yes, I r
From: Segher Boessenkool <[EMAIL PROTECTED]>
...since this won't work (compiler bug, see <http://gcc.gnu.org/
PR31490>).
The bug report says IA64 is broken, too. Please verify and extend the
patch if possible...
The GCC bug exists on all architectures. Linux build is
+* We must write a positive value to the decrementer to clear
+* the interrupt on the IBM 970 CPU series. In periodic mode,
+* this happens when the decrementer gets reloaded later, but
+* in one-shot mode, we have to do it here since an event handler
+* ma
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event
handler
+ * may skip loadin
Otherwise, when the contents of DEC0 change, the exception effects
of the Decrementer become consistent with the new contents of the
Decrementer reasonably soon after the change.
And that is guaranteed on all PowerPC as far as I can see.
The main thing is that a decrementer exception won't go
It would be better if GCC had a 'nopadding' attribute which gave us
what
we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
Segher
-
To unsubscribe
It would be better if GCC had a 'nopadding' attribute which gave us
what we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
It _might_ make accesses t
+ dev->revision = get_int_prop(node, "revision-id", 0);
It's not clear to me in the spec if nodes are required to have the
"revision-id" property.
It is required for every PCI node.
I guess 0 is a safe default though.
As good as any -- that is, no default is save. 0 should
be "good
Here are three independently invalid non-ICEs that sparse doesn't
diagnose.
extern int f(void);
enum { cast_to_ptr = (int) (void *) 0 };
enum { cast_to_float = (int) (double) 1 };
Those two *really* shouldn't fail. I don't care if the C standard says
so,
that is *fine*.
GCC doesn't guarante
+- #address-cells : Address representation for "rapidio" devices.
+ This field represents the number of cells needed to represent
+ the RapidIO address of the registers. For supporting more than
+ 32-bits RapidIO address, this field should be <2>.
+ See 1) above for more d
+ k) RapidIO
+
+ Required properties:
Should probably recommend a name for the node here, as well. "srio" I
guess, from the example below.
I would prefer "rapidio", being more generic and more
readable. What would parallel RapidIO be, "prio"? No
thanks :-)
Segher
-
To unsubscribe fro
Of course, looking at the device tree, rapidio is a device, not a bus,
because it does not have a device_type and it does not have any
children
of its own.
It's a device _of course_, but it's also a bus parent, since
it has a "#address-cells" not equal to zero (and, if this used
real OF, it wo
+- #address-cells : Address representation for
"rapidio" devices.
+ This field represents the number of cells needed to represent
+ the RapidIO address of the registers. For
supporting more than
+ 32-bits RapidIO address, this field should be <2>.
+ See 1) above for mo
No. The #address-cells is determined by the bus binding,
so that all RapidIO busses on the planet can be represented
in a similar way in the OF device tree. Take for example
the PCI binding, which gives you three address cells -- one
to distinguish between different address spaces (configuration
headers_install by default puts headers into usr/include/ .
They're auto-generated, so should be ignored.
Same for *.orig, *.rej .
If you have .orig or .rej files hanging around, it means you
have an unresolved merge conflict. Better not ignore it.
Segher
-
To unsubscribe from this list: se
Out of curiosity, why would a compiler ever insert padding in a
structure
that has all its elements properly-aligned?
Well, it might decide it would be nicer if some elements were aligned
to
64 bits. Or to a cache line. Or something. I don't care about _why_ --
the point is that it's _allowed
gcc-4.3 appears to have cunningly converted this:
static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
ns += a->tv_nsec;
while(unlikely(ns >= NSEC_PER_SEC)) {
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
a->tv_nsec = ns;
}
into a
I find it extremely silly to implement it as edge anyway. The EE line
is
level triggered, and having a mix of edge and level on the same
exception without a clean way to retrigger the DEC one other than
waiting one tick is just causing trouble.
It isn't edge triggered, it just automatically cle
It's not the compiler who decides -- struct layout is
dictated by the ABI you're compiling for.
This is true in the case of externally-visible stuff. I think the
compiler is permitted to violate the ABI for purely unit-internal
things
if it makes sense though, isn't it?
Sure. It isn't "viol
Unfortunately, FIT exists only on Book E CPUs and MPC74xx aren't Book
E, IIUC.
By the name "FIT" perhaps, but MPC74xx has essentially
the same thing.
Set MMCR0[TBEE], set MMCR0[PMXE], and choose a TBL bit via
MMCR0[TBSEL].
That's the performance monitor, which could very well be
in use alre
and we'll end up
having major kernel releases which don't build on i386 with major gcc
releases, which isn't altogether desirable.
Yeah, like 4.2.0 with powerpc. Seems like no one tested it :-(
Details please. What exactly are the gcc-4.2.0 problems on powerpc?
http://gcc.gnu.org/PR31490 .
and we'll end up
having major kernel releases which don't build on i386 with major
gcc
releases, which isn't altogether desirable.
Yeah, like 4.2.0 with powerpc. Seems like no one tested it :-(
Details please. What exactly are the gcc-4.2.0 problems on powerpc?
http://gcc.gnu.org/PR31490
Over here, the 2.6.21.1 Kernel _builds_ fine with gcc-4.2.0 on an
mpc8540 e500 powerpc
(mpc8540_ads_defconfig)
Yeah, this problem likely doesn't show up on 32-bit platforms.
but it just crashes silently on boot. But that's IMHO a
DeviceTree/U-Boot issue I haven't solved yet.
Quite possible.
In fact, while it's never worded explicitely in the spec, it's always
been strongly in the "spirit" of the architecture that the timebase and
decrementer have a constant frequency.
The architecture mentions varying time base frequencies,
and how to deal with this, actually. It makes no
recommen
* We must write a positive value to the decrementer to clear
-* the interrupt on the IBM 970 CPU series. In periodic mode,
-* this happens when the decrementer gets reloaded later, but
-* in one-shot mode, we have to do it here since an event handler
-* ma
+ compatible = "fsl-i2c-cpm";
"fsl,i2c-cpm" instead.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
For example, you could make this
compatible = "8xx\0mpc885ads";
"mpc885ads-pcmcia\0mpc8xx-pcmcia" or something like that.
Right. I can never remember what goes first...
It doesn't really matter all that much; "correct"
drivers probe for the most specific thing first,
then the next mos
+ [EMAIL PROTECTED] {
+ #interrupt-cells = <1>;
+ interrupt-parent = ;
+ interrupts = ;
+ };
Since this node's children's interrupt representation
is different from the node's parent's, you need a
Since this node's children's interrupt representation
is different from the node's parent's, you need an
interrupt-map in here. You also forgot "#address-cells"
and I think you need "ranges" too?
Well, in fact it does not introduce SoC device different from any
others
represented inside soc885
That's a horrible argument. Please do it properly, and let arch/ppc
die as it should. We shouldn't be adding anything to it anymore
anyway.
I understand your point, but we shouldn't trash existing bits either.
Why not? The things that haven't been ported over yet
obviously are unmaintained.
That patch says
+ outb(0x60, 0x64); /* write Controller Command
Byte */
+ udelay(50);
+ kb_wait();
+ udelay(50);
+ outb(0x14, 0x60); /* set "System flag" */
so the comment doesn't agree with the code: it sets
al
101 - 200 of 516 matches
Mail list logo
