- 0x0 0x0800;
+ 0x0 0x080;
You might want to write that as 0x0080, otherwise people
will think it says 128M still :-)
Segher
___
Linuxppc-dev mailing list
if (mmap((caddr_t)(1UL (POINTER_SIZE - 1)) - pagesize,
(size_t)((1UL (POINTER_SIZE - 1)) - pagesize),
PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED|
MAP_SHARED, 0, 0)
!= (caddr_t)-1)
With 32-bit userland, this boils down to:
| mmap
If you ignore the VMLINUX_SYMBOL, the only difference is moving the
ALIGN inside the brackets. If I move the ALIGN back where it was, then
the warning goes away.
But other sections moved the ALIGN without an issue. Could it be a
compiler problem? We are using version 4.0.0 (DENX ELDK 4.1
Here is the ld -M output for the bad compile:
.data_nosave0xc0376790 0x870 load address 0x00376790
0xc0377000. = ALIGN (0x1000)
*fill* 0xc0376790 0x870 00
Ah right. Having the ALIGN() inside the output section causes the linker
to put
)
}
+ . = ALIGN(PAGE_SIZE);
.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
NOSAVE_DATA
}
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
The patch is good and fixes a real problem. But, I still don't see how
it caused the warning: allocated section
mmio[0] = address;
mmio[1] = data;
mb();
eieio is enough here.
mmio[3] |= 0x01; /* This triggers an operation - address=data */
/* probably also need an mb() here, if the following code
* depends on the operation to be triggered. */
No, a sync does not guarantee the device has seen the
Nice patchset. Some comments on the emulation part:
+#define OP_31_XOP_EIOIO854
You mean EIEIO.
+ case 19:
+ switch (get_xop(inst)) {
+ case OP_19_XOP_RFID:
+ case OP_19_XOP_RFI:
+ vcpu-arch.pc =
+ case OP_31_XOP_EIOIO:
+ break;
Have you always executed an eieio or sync when you get here, or
do you just not allow direct access to I/O devices? Other context
synchronising insns are not enough, they do not broadcast on the
bus.
There is no device
You need to be a bit more careful tho. You must not allow RAM
managed by
the kernel to be mapped non-cachable.
Even if the user explicitly sets the O_SYNC flag? IMHO, it's a bug of
the application if it uses O_SYNC on main memory to be mmap'ed later.
And we don't need to cover up the bug.
Hi Albert,
+asm (\n\
A file scope asm?! Please don't.
+ * We enter with the cache enabled, the MMU enabled and some known
legacy
+ * memory mappings active. xBAT3 is unused
It would be good if you could depend as little as possible on these
things;
that makes writing another
+ * We enter with an unknown cache, high BATs and MMU status.
What does this mean? You know the low four BATs on entry and
nothing else?
+asm (\n\
Global asm() is evil.
+ mfmsr 9\n\
+ andi. 0, 9, (14)|(15) /* MSR_DR|MSR_IR */\n\
+ andc9, 9, 0\n\
mfmsr 9 ;
Add a config option GAMECUBE_COMMON to be used as a dependency for all
options common to the Nintendo GameCube and Wii video game consoles.
Maybe something like GAMECUBE_OR_WII instead? COMMON is so
common it's meaningless.
Segher
___
Linuxppc-dev
+ If you say yes to this option, support will be included for the
+ USB Gecko adapter as an udbg console.
+ The USB Gecko is a EXI to USB Serial converter that can be plugged
+ into a memcard slot in the Nintendo GameCube/Wii.
Not a memcard slot, only the first
You set up DBAT1 here...
+setup_usbgecko_bat:
+ /* prepare a BAT for early io */
+ lis r8, 0x0c00
+ ori r8, r8, 0x002a /* uncached, guarded ,rw */
+ lis r11, 0xcc00
+ ori r11, r11, 0x3 /* 128K */
+#ifdef CONFIG_WII
+ orisr8, r8, 0x0100
+asm (\n\
A file scope asm?! Please don't.
So what's your proposal then? Placing it within a fake func?
That asm snippet is the entry point. I took as an example how
prpmc2800.c deals with that, providing an own version of the (weak)
_zImage_start.
Use an assembler source file.
+ * We enter with an unknown cache, high BATs and MMU status.
What does this mean? You know the low four BATs on entry and
nothing else?
That means that we do not make assumptions regarding:
- the state of the cache (enabled vs disabled)
- if the high BATs are enabled or not
- if the MMU is
Add a config option GAMECUBE_COMMON to be used as a dependency
for all
options common to the Nintendo GameCube and Wii video game consoles.
Maybe something like GAMECUBE_OR_WII instead? COMMON is so
common it's meaningless.
I don't like either GAMECUBE_OR_WII.
It looks as if it can be
+ If you say yes to this option, support will be included
for the
+ USB Gecko adapter as an udbg console.
+ The USB Gecko is a EXI to USB Serial converter that can be
plugged
+ into a memcard slot in the Nintendo GameCube/Wii.
Not a memcard slot, only the first one, you
config GAMECUBE_COMMON
bool
select NOT_COHERENT_CACHE
+ select FLIPPER_PIC
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
+#define pr_fmt(fmt) DRV_MODULE_NAME : fmt
Unused
+/*
+ * Each interrupt has a corresponding bit in both
+static struct of_device_id gamecube_of_bus[] = {
+ { .compatible = nintendo,flipper, },
+ { },
+};
+
+static int __init gamecube_device_probe(void)
+{
+ if (!machine_is(gamecube))
+ return 0;
+
+ of_platform_bus_probe(NULL, gamecube_of_bus, NULL);
+
+config HLWD_PIC
Are vowels too expensive? :-)
+static void hlwd_pic_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same issue as with Flipper here.
+
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same functionality.
It grants full access to the hardware found on the
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/
powerpc/platforms/embedded6xx/wii.c
+#define DRV_MODULE_NAME rvl
Should this be wii?
+static enum starlet_ipc_flavour starlet_ipc_flavour;
+
+enum starlet_ipc_flavour starlet_get_ipc_flavour(void)
+{
+ return
+ model = NintendoGameCube;
+ compatible = nintendo,gamecube;
To date, we've been using the same form for both the model and
compatible properties. Specifically the vendor,model form to
maintain the namespace.
That, however, is a) useless; and b) not totally correct.
The model
The soc node here tries to represent the big multi-function chip
that integrates most of the devices of the video game consoles
(Flipper on the Nintendo GameCube and Hollywood on the Wii).
Right. Much like many other SoCs.
It isn't a SoC, it's really just a memory bridge / I/O bridge
like
In struct device_node, the phandle is named 'linux_phandle' for
PowerPC
and MicroBlaze, and 'node' for SPARC. There is no good reason for the
difference, it is just an artifact of the code diverging over a couple
of years. This patch renames both to simply .phandle.
Note: the .node also
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O area) */
Like others have said already, don't do this. If you need
a workaround, put it in the platform code.
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
This address is fixed in the DSP hardware, right? If not,
you
+ memory {
+ device_type = memory;
+ /* 24M minus framebuffer memory area (640*576*2*2) */
+ reg = 0x 0x01698000;
Put the whole 24MB here, probe the framebuffer address and size
in the platform code?
+ soc {
+ #address-cells =
So what you are saying is that if the kernel has mapped a physical
page as cacheable while user application is trying to map it as
non-cacheable, there will be machine checks and checkstops rather than
just performance drop? This is new to me. Could you elaborate a bit?
If some data is in
You're right, it's not, but makes merging less complex, and then I
can
refactor properly.
Still, make them __be32 at least
There is no alignment guarantee at all either, better make it all u8
and use accessor functions everywhere.
Segher
___
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
+/*
+ * Each interrupt has a
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above in
the soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the devices
you want.
Segher
Add support for the BootMii 'mini' firmware replacement for the
Starlet processor.
'mini' is an open source IOS replacement written from scratch by
Team Twiizers.
It's not a replacement, it doesn't have any of the same
functionality.
I didn't know 'replacement' had that semantics.
It's
+#ifdef CONFIG_STARLET_MINI
+
+#define HW_RESETS_OF_COMPATIBLEnintendo,hollywood-resets
+#define HW_GPIO_ALIAShw_gpio
This should be unconditional now I think? You access the hardware
directly.
Yes, at this stage direct hardware should be possible, but only if
'mini' support is
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple
+ xfb-start = 0x01698000; /* end-of-ram - xfb-size */
+ xfb-size = 0x168000;
XFB address isn't fixed on the hardware, and the kernel might
want to move it, and you can easily probe for it anyway. Remove
these last two properties please.
Ok but you
So what's your proposal then? Placing it within a fake func?
Just do a .S file :-)
Yeah. You might be able to do one that handles both GC and Wii,
maybe it's easier/clearer to keep them separate though.
Ouch. I wouldn't be surprised if those guys don't do cache coherency
in the bridge
+ soc {
It would be better to rename this as IMMR or the bus type. This node
doesn't actually describe the entire chip, but describes the internal
memory mapped registers.
I would really just call it flipper :-)
Yeah, I came to the same conclusion.
Since you're only doing 1:1
+/memreserve/ 0x0180 0xe80; /* memory hole (includes I/O
area) */
+/memreserve/ 0x1000 0x0004000; /* DSP RAM */
Weird layout... nothing you can do about I suppose.
Out of curiosity, what is that DSP RAM ? Some actual DSP core
somewhere
in the IO chip setup to use memory
BTW. If we want to play with clocks, maybe you should look at
my proposed binding for clocks and implementing the clk API :-)
There are no clocks that are configurable from the PowerPC side
(well, maybe things like the USB clocks, but we do not know how).
+ /* Team Twiizers'
This will probably break other platforms if
CONFIG_PPC_EARLY_DEBUG_USBGECKO
is set. In general, we try hard to make it possible to build generic
kernels for multiple systems, so it would be better to also add a
runtime check here.
No Arnd. The whole point of EARLY_DEBUG is that it is -known- to
+unsigned int flipper_pic_get_irq(void)
+{
+ void __iomem *io_base = flipper_irq_host-host_data;
+ int irq;
+ u32 irq_status;
+
+ irq_status = in_be32(io_base + FLIPPER_ICR)
+in_be32(io_base + FLIPPER_IMR);
+ if (irq_status == 0)
+
+static void hlwd_pic_mask_and_ack(unsigned int virq)
+{
+ int irq = virq_to_hw(virq);
+ void __iomem *io_base = get_irq_chip_data(virq);
+
+ clear_bit(irq, io_base + HW_BROADWAY_IMR);
+ set_bit(irq, io_base + HW_BROADWAY_ICR);
+}
Same comment as with flipper. BTW. It
Sure, the memory controllers don't do coherency. I'm slightly
worried
about two things:
1) Will the generic code use M=0 as well? Is it a problem if it
doesn't?
We can make it not do it.
2) Do lwarx. etc. work in M=0?
They should hopefully... as long as you don't rely on the reservation
The usbgecko is hotplugable and hotswappable.
But as this is mostly a developer feature, not normaly used by end
users, I think that we can just let it be as it is: autodetect it
on boot (now probing for it instead of using information from the
device tree).
If you unplug it later it causes
They are a bit special because registers are in reverse little
endian format,
must be written in 32-bit chunks, and (all things point to) they
have hardware bugs.
Well.. first what is reverse little endian ? :-) Big endian ?
Nah. Little-endian, with a 32-bit bus swizzle. This is not the
There you can find the hardware interface that supports the IPC
mechanism.
It is made up of a pair of registers to pass data between the
processors and a
pair of control/flags registers.
The hardware can interrupt the PowerPC side when there is data
available for it.
Ok. So the right way
Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of
GAMECUBE_COMMON
is a good name?
I'd prefer to not use a name that implies a specific hardware to
describe two (mostly) similar but different hardwares.
Hollywood is 100% compatible to Flipper though.
No. There's no ARAM for example :)
We need it as it currently doesn't match with the default bus ids.
Should I introduce a .type property matching any of those above
in the
soc node, and get rid of the explicit bus probe?
You don't need any fake bus as far as I can see, just probe the
devices
you want.
But it's way
Yup. The idea is to map the first 16MB of MEM1 with a BAT.
Mapping the whole 24MB with BATs may not be possible because we
want the framebuffer
in MEM1 for performance reasons.
How big is the fb ?
A bit more than a megabyte, something like that.
We have plenty of BATs on these things...
If you have only one interrupt controller, like here, you don't
need to refer to it _at all_ :-)
I think Linux requires that you do though. It might be a mistake on
our
part but heh ...
Linux doesn't require it; (old) Macs are like this, for example,
and that works fine. Oh and all Maple
+ soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ #interrupt-cells = 1;
This isn't an interrupt controller, don't put #interrupt-cells
here.
Isn't this needed to define what is to be expected in the
interrupts properties of the child nodes?
Similarly, it is better to use a compatible value of something like:
compatible = nintendo,flipper-immr; (instead of nintendo,flipper)
because your describing just the internal bus, not the entire chip.
I would just call the nodes flipper and hollywood.
Either that, or not have these omnibus
Add a config option GAMECUBE_COMMON to be used as a dependency
for all
options common to the Nintendo GameCube and Wii video game
consoles.
Maybe something like GAMECUBE_OR_WII instead? COMMON is so
common it's meaningless.
I don't like either GAMECUBE_OR_WII.
It looks as if it can be
+/*
+ * Each interrupt has a corresponding bit in both
+ * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
+ *
+ * Enabling/disabling an interrupt line involves asserting/
clearing
+ * the corresponding bit in IMR. ACK'ing a request simply
involves
+ * asserting the
It turns out that we _need_ to ack the RSW (Reset Switch) interrupt.
The other interrupt sources checked (EXI, VI, DI, AI, DSP/ARAM) need
no explicit ack.
That would probably mean that the reset switch interrupt is an edge
interrupt.
Nah, it means that the RSW is a flip-flop.
Segher
The scenario for the first case is that in a multicore system running
ASMP which means different OS runs on different cores. They might
communicate through a shared memory region. The region on every OS
need to be mapped with the same cache perperty to avoid cache paradox.
This isn't true.
...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
---
v1 - v2
- Probe dinamically for usbgecko. Suggestion by Segher Boessenkool.
- Adapt to updated device tree.
arch/powerpc/boot/Makefile |2 +-
arch/powerpc/boot/ugecon.c | 147
Add a device tree source file for the Nintendo GameCube video game
console.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
---
v1 - v2
- Document new bindings in Documentation/powerpc/dts-bindings.
Suggestion by Grant Likely
Boessenkool seg...@kernel.crashing.org
---
v1 - v2
- Use a separate asm file for the entry point code.
Suggestion by Segher Boessenkool and Benjamin Herrenschmidt.
- Do not make assumptions about the state of the cache and MMU on
entry, eliminating dependencies on a particular bootloader
...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
---
v1 - v2
- Get rid of 0-#ifdef'ed code. Suggestion by Segher Boessenkool.
- Probe dinamically for usbgecko. Suggestion by Segher Boessenkool.
- Adapt to updated device tree.
arch/powerpc/platforms/embedded6xx/Kconfig
Add support for the interrupt controller included in the Flipper
chipset of the Nintendo GameCube video game console.
The same interrupt controller is also present in the Hollywood
chipset
of the Nintendo Wii.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Acked-by: Segher Boessenkool
you may want to rename the ug_ prefix, it took me a while looking
back
and forth through the patch to convince myself it wasn't a typo.
What's wrong with ug_ ? (ug = (u)sb(g)ecko)
At first look I thought it was a typo of udbg_early_remap. I prefer
the longer names although we could use
The scenario for the first case is that in a multicore system
running
ASMP which means different OS runs on different cores. They might
communicate through a shared memory region. The region on every OS
need to be mapped with the same cache perperty to avoid cache
paradox.
This isn't
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+setup_usbgecko_bat:
+ /* prepare a BAT for early io */
+#if defined(CONFIG_GAMECUBE)
+ lis r8, 0x0c00
+#elif defined(CONFIG_WII)
+ lis r8, 0x0d00
+#else
+#error Invalid platform for USB Gecko based early debugging.
+#endif
A
Add a device tree source file for the Nintendo Wii video game console.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
Great work Albert!
___
Linuxppc-dev mailing list
Linuxppc-dev
+#ifdef CONFIG_PPC_EARLY_DEBUG_USBGECKO
+setup_usbgecko_bat:
+/* prepare a BAT for early io */
+#if defined(CONFIG_GAMECUBE)
+lisr8, 0x0c00
+#elif defined(CONFIG_WII)
+lisr8, 0x0d00
+#else
+#error Invalid platform for USB Gecko based early debugging.
+#endif
A
-by: Segher Boessenkool seg...@kernel.crashing.org
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Add platform support for the Nintendo Wii video game console.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Another option might be simply to say that if an app has used FP,
VMX or
VSX -once-, then it's likely to do it again and just keep re-enabling
it :-)
I'm serious here, do we know that many cases where these things are
used
seldomly once in a while ?
For FP, I believe many apps use it only
It's very likely that a process which results in the
enabling of FP,VMX, or VSX may continue to use the facility for the
duration of it's lifetime. Threads would be even more likely to
exhibit
this behavior.
The case where this might not be true is if we use VMX or VSX for
string
routine
Right, now turn it into a proper patch submission :-)
if (result 0)
printk(KERN_WARNING wdrtas: reading the thermal sensor
- faild: %li\n, result);
+ faild: %i\n, result);
else
temperature =
,
you can handle it I'm sure :-)
Segher
Signed-off-by: Segher Boessenkool seg...@kernel.crashing.org
Author: Segher Boessenkool seg...@kernel.crashing.org
Date: Fri Mar 27 21:10:59 2009 +0100
powerpc: EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name)
diff --git a/drivers/net/fsl_pq_mdio.c b
Gah, gcc sucks. It should just not warn in these cases where it
doesn't
know wth is going on.
I don't think you'll get any arguments. it only there was a -
Wnowarnunused!
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable.
But I
thought this was about uninitialised var
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-
variable. But I
thought this was about uninitialised var warnings? -Wno-
uninitialized
for that one.
If you are asking for a GCC option that will warn for all suspect
cases
_except_ for the ones where it is obvious to you there is
Unfortunately -Wno-uninitialized also suppresses the warnings that
point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error, instead -- and
it does do
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function
'associativity_show':
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c:562:
warning: 'associativity' may be used uninitialized in this function
/scratch/tony/working/arch/powerpc/kernel/cacheinfo.c: In function
The problem is that GCC does not give an error (only a warning)
even for
things like this where it should be trivial to detect that the
usage *is*
uninitialized, not just might be:
int foo(void)
{
int a;
return a;
}
The compiler must not reject this code, because the undefined
And further, there is no separation of warning classes into might-
be-uninitialized and is-uninitialized-compiler-can-tell-for-sure.
Indeed. Please file a bug report.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
this way,
it won't match the reg! Looks like there is more than one
bug in there.
Code looks good,
Reviewed-by: Segher Boessenkool seg...@kernel.crashing.org
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman
Also, there's a bug in the powerpc implementation. It appears that
oparg is clobbered, and if stwcx fails the operation will be
repeated with incorrect inputs.
If either the lwarx or the stwcx. faults, the routine returns -EFAULT
and doesn't retry (label 3 is the end of the asm).
If the
Sometimes, an special partition is included in the device tree
including all the
partitions. Like in:
partit...@ff00 {
reg = 0x00 0x80 ;
label = Root File System;
};
partit...@ff80 {
reg = 0x80 0x1a ;
label = Bitstream;
};
...
f...@ff00
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
arch/powerpc/math-emu/op-2.h | 75 -
1 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
index 7d6f17c..16d3e3c 100644
_However_ there are significant code changes in there, and I don't
actually understand that code (well, I admit I haven't tried),
Yeah, it's written in 70's style C. Yuck.
so it could definitely use a bit of a commit message explaining
the rationale
Right. I had to fix git-send-email and
While debugging __divdi3 calls in drivers/crypto/hifn_795x.c (due to
the
ndelay() delay call with a s64), I found even more breakage of that
sort. This is after a allnoconfig with ARCH=powerpc in 2.6.25-rc3,
plus CONFIG_MODULES=y and CONFIG_CRYPTO_DEV_HIFN_795X=y:
I cannot reproduce this,
+/*
+ * __ucmpdi2: 64-bit comparison
+ *
+ * R3/R4 has 64 bit value A
+ * R5/R6 has 64 bit value B
+ * result in R3: 0 for A B
+ * 1 for A == B
+ * 2 for A B
+ */
+_GLOBAL(__ucmpdi2)
+ cmplw r7,r3,r5# compare high words
+ li r3,0
Even if it was logically faster (which I still doubt) it's a hell of
a lot
of cache lines to waste.
Yeah, 1 on 64-bit and 3 on 32-bit, that's a terrible lot./sarcasm
Indeed, but there are some corner cases that the C code handles. Like
a length of 0 which may lead to infinite loop in the
Uh.. there's no binding written down, it's just encoded into uic.c.
But UIC doesn't use OpenPIC sensitivity encoding. Like FSL's IPIC,
it
uses Linux IRQ_TYPE values from include/linux/irq.h which makes 8
level sensitive, active-low.
On a related note: aren't we taking a risk here of
It would be a pity if we can't all enjoy this.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature
Every occurrence of r7 here is wrong (and some of the r6).
Can you elucidate?
Sure! It should read either 7 or cr7.
Is there any reason to do this in assembler code at all?
Is there any particular reason not to?
1) If written in assembler, it needs to be written for every
architecture
Using '8' is correct. PCI interrupts are *always* level sensitive and
active
low.
Unless you use one of those strange bridges that stick not gates on the
PCI IRQ inputs :-) But I don't think that's the case on the 440EP.
More generally, the target interrupt descriptors (sense values, in
More generally, the target interrupt descriptors (sense values, in
particular) in a device tree interrupt map describe the interrupts as
seen on the target interrupt controller, *not* as seen on this
(source)
interrupt domain. This should be obvious, but since the source
interrupt
Every occurrence of r7 here is wrong (and some of the r6). Is there
any reason to do this in assembler code at all?
The fact that the obvious C code generates ... a call to __ucmpdi2? :)
Hrm? Here's the obvious C code, portable to all architectures
(modulo the specific types used, this
Do we have any indication that it performs better than the C one ?
I would expect it to, given that the assembler one has two branches in
the per-byte loop compared to 3 in the C version.
But really, does it matter for strncmp() in the kernel?
Anyway, this asm code has bugs, as do both the
Anyway, this asm code has bugs, as do both the current C version in
the
kernel, and the code I posted. We need to do better :-)
The only bug I know of in the asm code is the behaviour when the count
is zero. Do you know of any other?
No, that's the bug I meant. Sorry for using such
This patch was not yet tested. Please confirm it's right.
---
strncpy does not append '\0' if the length of the source string equals
the size parameter, strlcpy does.
strlcpy() doesn't fill the rest of the array with zeroes, strncpy()
does. This could matter (information leak, for example),
do we need similar fixes to arch/ppc ?
Do we care?
arch/ppc needs many fixes, when you have implemented all of that, you
get a clone of arch/powerpc ;-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.
So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on nand-flash.
What's
I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on board-control
I don't see any reason for this. If I have a cpld or fpga why not
just call it that. I don't see what calling it 'board-control' gets
us. There may be non-board control
1 - 100 of 1471 matches
Mail list logo
