Tried 2.6.26-rc1+git on ppc (arch/ppc, PReP subarch) and got this:
arch/ppc/kernel/ppc_ksyms.c: At top level:
arch/ppc/kernel/ppc_ksyms.c:152: error: '__flush_icache_range'
undeclared here (not in a function)
That's fixed by [2/3] in
+ compatible = mpc83xx_wdt, fsl,mpc8610-wdt;
You should put the most specific entry first.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
I think that adding zImage.* to clean-files is a bad idea, because we
have zImage.lds.S, zImage.coff.lds.S and zImage.ps3.lds.S in
arch/powerpc/boot that we don't want deleted. It would be OK for
compiling with a separate object directory but would be bad for
compiling in the source directory.
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to
a certain SPI controller
From memory, I measured lwsync is 5 times faster than eieio on
a dual G5. This was on a simple microbenchmark that made use of
smp_wmb for store ordering, but it did not involve any IO access
(which presumably would disadvantage eieio further).
This is very much specific to your particular
+#ifdef __SUBARCH_HAS_LWSYNC
+#define SMPWMB lwsync
+#else
+#define SMPWMB eieio
+#endif
+
#define smp_mb() mb()
#define smp_rmb() rmb()
-#define smp_wmb() eieio()
+#define smp_wmb() __asm__ __volatile__ (__stringify(SMPWMB) : :
:memory)
SMPWMB is used only
This is mostly useless then since lwsync is just a sync to a processor
that doesn't know it (it's a sync with a reservd bit set) :-) Or it's
just to make gas happy if you specify a processor type that doesn't
have
lwsync ?
GAS doesn't care (I tried with -Wa,-m405). Support for this insn
was
The main question is do we care if the downgrade to sync on power3
hurts
performances (and does it ?) and what do we do for 32 bits as
currently,
no 32 bits implementation has lwsync afaik (though that might not be
true for long).
Some time ago, I benchmarked (*) a loop of stw;sync vs.
+ - fsl,fullspeed-clock : specifies the full speed USB clock
source in
+clknum or brgnum format.
+ - fsl,lowspeed-clock : specifies the low speed USB clock source
in
+clknum or brgnum format.
What format is num in?
+ - fsl,usb-mode : should be host.
If
+ Required properties:
+ - #address-cells : should be 0.
+ - #size-cells : should be 0.
Are these properties required at all? Will this node have any
children.
You mean, does this node define a bus. If it doesn't, there
shouldn't be #a and #s; if it does, the binding should
The real problem is we don't yet have good method (or place) to apply
a translation table from compatible values to modaliases. Ideally,
the translations should be part of the drivers themselves, but that
causes a chicken and egg problem of needing to load the driver to get
access to the table
Some of the helper scripts used to run testcases contain some
constructs that are bashisms. Or at least which don't work on dash,
the minimal shell used as /bin/sh on recent Ubuntu systems.
Both of these (the redirection, and source searching the current
directory if the script isn't found in
Nice cleanup! Just one thing...
+- compatible : Should contain entries for all compatible SEC
versions,
+ high to low, e.g., fsl,sec2.1, fsl,sec2.0
*All* compatible versions? That's not really correct -- for
example that would include *future* versions!
The first entry should
Removed clock-frequency and big-endian props as they aren't specified
anywhere.
If you remove big-endian, you'll have to provide some other way
to get that information (like, some new compatible value).
Dunno if we need clock-frequency.
This patch also removes built-in properties. I'm all
Added next-level-cache to the L1 and a reference to the new L2 label.
Where is this property defined? I can't find it.
The PowerPC binding defines an l2-cache property for this (it
points from CPU node to L2 cache node, from L2 cache node to L3
cache node, from L3 cache node to L4 cache node,
Removed clock-frequency and big-endian props as they aren't specified
anywhere.
If you remove big-endian, you'll have to provide some other way
to get that information (like, some new compatible value).
I'm all for big-endian but we don't spec this anywhere and aren't
using it right now. So
Added next-level-cache to the L1 and a reference to the new L2 label.
Where is this property defined? I can't find it.
The PowerPC binding defines an l2-cache property for this (it
points from CPU node to L2 cache node, from L2 cache node to L3
cache node, from L3 cache node to L4 cache node,
I think we should just expand the definition of cell-index to include
standard
device enumeration for when it's needed. The original definition is
too
limited, IMHO.
nak
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just
if you need explicit indexing then use an alias. My opinion however
is that explicit indexing is unnecessary and is just an artifact of
current i2c subsystem internals. There is already enough information
in the device tree to match i2c devices with i2c busses without
resorting to indexes.
-by: Grant Likely [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Acked-by: Segher Boessenkool [EMAIL PROTECTED]
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
No; use an alias in the aliases node. That is what aliases is
designed
for. Something like 'index' is a reinvention of the wheel.
Do aliases work in reverse? That is, if I have a pointer to a device
node, can
I look up its alias directly? Or do I have to scan the aliases node
and do a
From a device tree perspective, index and cell-index are both
incorrect. The IIC macros don't share register blocks with anything,
are enumerated as unique instances per macro in the device tree, and
should be able to be distinguished by regs and/or unit address.
Does anyone disagree with
DTS_FLAGS ?= -P 0x1000
1k seems like more than enough default padding.
Yes. So why specify 4kB?
/me hides
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Well, I just don't see the point of having two different properties
that say the
same thing. I'm not an IEE 1275 purist, so I don't think we should
be hampered
by old node definitions. I especially don't like having a property
specifically
for indexing I2C nodes that can't be used to
Aliases can also provide a reasonable way of enumerating devices, if
reg isn't suitable on its own.
Yes. In almost all cases, drivers and subsystems do not need this at
all though. In OF, one device points to another by putting the
phandle
of that pointed-to device in some property (and
CROSS32AS and CROSS32LD are never used (instead, CROSS32CC is used
with proper command line options).
CROSS32OBJCOPY isn't used anymore either, since the wrapper stuff
was added.
Remove these unused variables.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL
I see. I think I should then also post the bindings (update of
booting-without-of.txt) separately.
Yes please. They are much easier to review that way (and they
should be reviewed as a separate entity anyway).
Segher
___
Linuxppc-dev mailing list
+ - chip-delay : may specify a delay value in milliseconds.
Delay for what? The binding should say. chip-delay is a bit
too generic name as well, it could be more descriptive perhaps.
Shouldn't this be a property of the NAND device anyway, not the
NAND controller?
Segher
+ - chip-delay : may specify a delay value in milliseconds.
Delay for what? The binding should say. chip-delay is a bit
too generic name as well, it could be more descriptive perhaps.
The chip-delay property defines an appropriate maximum delay
time (tR) required for read operations if
Finalizing device tree... using OF tree (promptr=0e1004c4)
( 700 ) Program Exception [ e1004c4 ]
The program check exception happens at 0xe1004c4 ? That looks like the
OF entry point (promptr)... could it be possible that it got corrupted
somewhat ? The only thing I see above there would be
return user_regset_copyout(pos, count, kbuf, ubuf,
- target-thread.fpr, 0, -1);
+ target-thread.fpr, 0, -1);
is there a reason we can drop the ''?
Yes, .fpr is an array. C is _such_ a fun language, heh.
Segher
D'oh. I spent so much time and the solution is so easy.
Thanks everybody. I have updated to binutils-2.18.50.0.6-2.ppc and now
it works again on QS22 and JS21.
So I checked your binary, and the only differences between working and
not-working are a) some section offsets in the file, and b) the
It returns 2 for both i2c-1 and i2c-2.
Well, I'm assuming that the alias property names will follow the
current
convention of nn where is a name and nn is a number. No
dashes or
other punctuation.
Well, yes, your suggested code doesn't allow punctuation either; but
that wasn't my
+static inline unsigned int
+csum_tcpudp_nofold(unsigned long saddr, unsigned long daddr, unsigned
short len,
+ unsigned short proto, unsigned int sum)
+{
+ __asm__(add %0, %4, %1\n\t
+ addc %0, %4, %2\n\t
+ addc %0, %4, %3\n\t
+
I'm really don't like fsl,sec1.0 or any of the variants as a
compatible property either because it can easily be abused (it's not
anchored to a specific physical part so the meaning can shift over
time); but that is another argument and it is well documented in other
email threads
Modern versions of u-boot create a chosen node automatically. So if
we set the chosen node in the dts file, there will be 2 chosen nodes
passed in to the kernel,
That's a bug in uboot, then: when it creates a property, it should
delete an already existing property with the same name in that
you find bug because there is microblaze asm code in generic folder.
No, I found it because I was reading the code, I didn't even notice
this was in asm-generic :-)
Big thanks. I'll fix it and I'll look at parameters too.
Thanks.
Segher
___
interrupt-map = 0x5800 0 0 1 ipic 0x30 0x8 - FPGA @ IRQ0
0x6000 0 0 1 ipic 0x11 0x8 - miniPCI INTA @
IRQ1
0x6000 0 0 2 ipic 0x11 0x8;- miniPCI INTB @
IRQ1
Is it legal to use a single irq pin twice ?
The device tree simply describes the
Also, these made-up names make you do more work: you'll need to
who said they were made up?
I did. These names do not refer to some physical part you can buy.
write up a binding for them, explaining exactly what a 1.0 device
etc. is (or at least point to documentation for it). If you use
What's the cell-index in these nodes used to index? Given the
confusion there's been about the proper use of this property, a
comment indicating which shared registers this is used to index is
probably a good idea.
There's supposed to be a cell-index in the *channels* to index into
the
shared
Also, these made-up names make you do more work: you'll need to
who said they were made up?
I did. These names do not refer to some physical part you can buy.
right, they refer to devices in multiple physical parts you can buy.
Part-you-can-buy documentation clearly indicates the SEC
Yes. As a side note, since there are multiple devices that contain
e.g. a sec-1.0, it would be prudent to describe the exact incarnation
in the device tree, like mpc8272-sec or something, in either model
but 'fsl,sec-X.Y' /does/ describe the exact incarnation,
No it doesn't. If it's on a
We need to use PPC_LCMPI otherwise we get compile errors like:
arch/powerpc/lib/feature-fixups-test.S: Assembler messages:
arch/powerpc/lib/feature-fixups-test.S:142: Error: Unrecognized
opcode: `cmpdi'
arch/powerpc/lib/feature-fixups-test.S:149: Error: Unrecognized
opcode: `cmpdi'
Please point out any patches that have been posted but havent made it
into a git tree related to Freescale chips.
I haven't heard back from Segher, so:
http://patchwork.ozlabs.org/linuxppc/patch?id=19313
You haven't heard back because I feel like I'm talking to a wall.
The compatible
+- compatible : Should contain entries for this and backward compatible
+ SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0
First entry should state the _exact_ version of the device. sec-N.M
isn't good enough; there can be implementation bugs.
There can be more entries; you make it
Just curious... why we're maintaining documentation in the .txt file?
Because it is human-readable text?
Or is this too wild? :-)
Yes :-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
/* deprecated; */
device_type = i2c;
How about deprecated but kept for compatibility with true Open
Firmware
implementations?
Well, except a flat tree isn't compatible with OF at all here.
A device_type promises a certain interface; a flat tree doesn't
even have the open
I'm sure you'll hate for doing this,
No, it's an excellent move :-)
but I've asked Kim to create a new
Documentation/powerpc/fsl-device-tree-bindings.txt as part of his SEC
patch.
As a separate patch, that (at first) _only_ moves the content into
separate
files, please.
Segher
+The SPI master node requires the following properties:
+- #address-cells - number of cells required to define a chip
select
+ address on the SPI bus.
Hrm. Should this (and reg in the child node) be required for SPI
masters that have only one chip select?
+
Its firmware apparently provides a flattened device tree to the OS.
And while this step towards world domination is flattering, it's an
example of what I feared when people first got enthusiastic about the
idea of including flattened device trees in firmwares. The tree has
not, AFAIK, been past
Trying to cross-compile arch/powerpc for an freescale 8280:
Gcc 4.1.2
Binutils 2.17
BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps
previous sections
[etc]
Could you try with binutils 2.18? If not, or if that doesn't help,
we'll need to see your .config .
Segher
. = ALIGN(0x1000) /* this align directive aparently gets lost
when stripping the file */
.rodata: AT (.rodata - LOAD_OFFSET): {
...
}
the effects of that align were dropped during strip, shifting all
following sections up in memory and the resulting failure.
The ELF
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah compatible
values
are bad in device nodes. The
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root node compatible property.
No! Don't do this because it is not true!
If the board actually _is_ compatible to the canyonlands board (it
only _adds_ stuff, doesn't change things or takes away things), it
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah compatible
values
are bad in device nodes. The
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 000..7e9ce81
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
+LED connected to GPIO
+
+Required properties:
+-
Previous threads have mentioned that binutil-2.17 is broken for
building powerpc kernels. It is fixed in binutils-2.18.
Yes.
I have encountered this and upgrading to 2.18 fixed my build. The
symptom is large kernel sizes and a long time in gzip. In my case it
was gziping a 2GB file.
Are you
offb palette handling on Powerstation.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Looks good.
Acked-by: Segher Boessenkool [EMAIL PROTECTED]
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo
This patch changes all LOAD_REG_ADDR macro calls to LOAD_REG_IMMEDIATE
to make sure that we load the correct address.
Did you figure out _why_ LOAD_REG_ADDR doesn't work? Using
LOAD_REG_IMMEDIATE is actually a step back, it makes the kernel
binary non-PIC. And LOAD_REG_ADDR _should_ work just
Other than that quibble, I agree that burning the blob into the
firmware
so that the firmware must be recompiled and reburned to change the
blob
is very undesirable.
I thought the device tree was *supposed* to be an interface between the
firmware and the kernel? What if the firmware produces
to it, its load
address will be zero.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
Tested-By: Milton Miller [EMAIL PROTECTED]
---
arch/powerpc/kernel/vmlinux.lds.S | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel
All of the variables references through @got translated into
relocation
type R_PPC64_GOT16_DS entries. All these entries correspond to one of
the above entries in the .got section. But none of the entries in .got
section are relocated.
If that last statement is really true, then that would be
If you built this kernel yourself, you need to do it from a system
with
an up-to-date binutils (2.18) otherwise, it does this.
Note to the linux-ppc guys; is there any changelog entry which reports
this requirement somewhere? I didn't find one...
That's because there is no such requirement.
[putting linuxppc-dev on Cc:, hope you don't mind]
On 24 jul 2008, at 08:32, Chuck Meade wrote:
I wanted to reply to your original message regarding this, but sadly
I
had
already deleted it. So I am sending directly to you.
This patch broke my link.
Sorry. I didn't test with anything
Anybody else seeing these? With Linus' latest I get three of these
warnings: .tmp_vmlinux1, .tmp_vmlinux2, and vmlinux.
Ah, that's useful information, I think I know what's going on
now. What was your binutils version?
Segher
___
Linuxppc-dev
Just tried to build the latest version from Linus' tree and I am
getting
a link error.
I can reproduce this now, with 3.4.6 + 2.15, on powerpc64 defconfig
(with the drivers that don't compile with 3.4.6 disabled).
I have a fix for the warning with 2.17, but that's just a warning,
so I'll wait
I can help you by testing on 2.15. Send me alternate vmlinux.lds.S
files
to try, and I will test and get back to you ASAP.
No, I will not send you randomly changed source files and hope they
will do something useful for you. Instead, why not provide me the
information I asked for? What
My previous patch to fix compilation with binutils-2.17 causes
a file truncated build error from ld with binutils 2.15 (and
possibly older), and a warning with 2.16 and 2.17.
This fixes it.
Signed-off-by: Segher Boessenkool [EMAIL PROTECTED]
---
arch/powerpc/kernel/vmlinux.lds.S |2 +-
1
compatible = atmel,24c32wp, 24c32, eeprom;
I know this is just an example; but to keep thinks clear, the second
and third values in this compatible property are completely bogus
(for
device trees). The manufacturer prefix needs to be present and
'eeprom' is far to vague.
Isn't 24c32 a
A reasonable compatible value would be something like
serial-eeprom-24c32.
You can go a little bit more generic than that, if you write up in
your binding how the driver should figure out the device size and
the protocol used.
Matching on serial-eeprom-24c32 requires me to convince the at24
So when we receive a spurious irq, EOI it, and then mask it.
What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls? Should you instead first mask
it, and only then EOI it? Or doesn't that work on XICS?
Segher
Instead we now link the bootwrapper with -pie to get a position-
independent executable, and process the relocations in the dynamic
relocation section that the linker puts into the executable.
Hurray! Looks good, just a few nits...
+ bl .+4
+p_base:mflrr10
unsigned int get_PLL_range(unsigned int range, unsigned int config)
{
range = range * 8 + 23;
return ((config range) | (config (32 - range))) 3;
}
The special pattern ((a n) | (a (32 - n))) is recognized by
gcc as
a rotate operation.
It's only valid for 1 = n = 31 though, so for
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not familiar enough with real OF to
+ bl .+4
+p_base:mflrr10 /* r10 now points to runtime addr of
p_base */
bl p_base instead?
I went back and forth on that. I ended up with it that way to
emphasize that the bl does need to branch to the *next* instruction
for the idiom to work.
Right, I
I don't know yet for sure what happens, but a quick look at the commit
seems to show that the driver synchronously spin-waits for up to 2.5ms
That's what the comment says, but the code says 2.5 _seconds_:
+ /* Wait for up to 2.5 milliseconds */
+ for (i = 0; i 25; i++) {
+
Hmm.. my reading of 1275 says that an alias pointing to another alias
is not permitted, but I'm not terribly confident I'm not misreading
it. Segher, do you know whether this is allowed?
My reading is the same: if after expanding an alias the path does
not start with /, the search starts at
- cmpwi 0,r3,0 /* parent or child? */
- bne 1f /* return if parent */
+ bns+1f /* did system call indicate error? */
+ neg r3,r3 /* if so, make return code negative */
+1: cmpwi 0,r3,0 /* parent or
Certain Apple machines don't use the ranges property correctly,
but the
workaround should not be applied on other architectures. This patch
disables the workaround for non-powerpc architectures.
I'm half tempted to add it to the quirk list (which should really be
made generic) so I can
- stw%U0%X0 %L2,%1
- : =m (*ptep), =m (*((unsigned char *)ptep+4))
+ stw%U1%X1 %L2,%1
+ : =m (*ptep), =m (*((unsigned char *)ptep+4))
: r (pte) : memory);
This still isn't correct -- the constraint says that a byte
is written, but the insn changes a
On PowerPC it's very normal to not support all of the physical RAM
in real mode.
Oh? Are you referring to real mode limit, or 32-bit
implementations with
more than 32 address lines, or something else?
Either way, RMO is a really bad name for this, since that name is
already
used for a
There is also a form of mtmsr where all bits need to be addressed.
While the
PPC64 Linux kernel behaves resonably well here, the PPC32 one never
uses the
L=1 form but does mtmsr even for simple things like only changing EE.
You make it sound like the 32-bit kernel does something stupid,
On PowerPC it's very normal to not support all of the physical
RAM in real mode.
Oh? Are you referring to real mode limit, or 32-bit
implementations with
more than 32 address lines, or something else?
The former.
Okay. In that case, the hypervisor can usually access all of physical
There is also a form of mtmsr where all bits need to be
addressed. While the
PPC64 Linux kernel behaves resonably well here, the PPC32 one
never uses the
L=1 form but does mtmsr even for simple things like only changing
EE.
You make it sound like the 32-bit kernel does something stupid,
Also, it seems you construct the physical address by masking out
bits from
the effective address. Most implementations will trap or
machine check if
you address outside of physical address space, instead.
Well the only case where I remember to have hit a real RMO case
is on the PS3 -
why there generated a signal 4 in init process?
That's SIGILL; sounds like you compiled init with the wrong (sub-)arch
or cpu flags.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
These processors will corrupt data if accessing the local bus with
unaligned
addresses. This version fixes the typical case of copying from
Flash on
the
local bus by keeping the source address always aligned.
On many platforms accessing ROM as RAM simply doesn't work(*). You
shouldn't
map
Just whitelist these extra compiler generated symbols.
Fixes these errors:
[...]
I've used an identical patch for almost a year now, so...
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
You probably also need something similar
- stw%U0%X0 %L2,%1
- : =m (*ptep), =m (*((unsigned char *)ptep+4))
+ stw%U1%X1 %L2,%1
+ : =m (*ptep), =m (*((unsigned char *)ptep+4))
: r (pte) : memory);
This still isn't correct -- the constraint says that a byte
is written, but the insn changes
Maybe it was caused by floating exception.I found that,system received
a program check exception,the reason for it was REASON_ILLEGAL.
I also use show_regs to print the NIP in exception,it seemed that
,this exception was caused by 'vmhaddshs' instruction in user mode of
init process .
Is
You probably also need something similar to http://git.infradead.org/
users/segher/linux.git/commitdiff/
98194f54cc8e19ecd752bc10e2d19ef94074f502
(note: only build-tested, not run-tested).
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit send
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit send :-) Either it's way more
complete than what I did, or way more complex because we still
don't link with libgcc :-P
Actually, the 64bit versions of the routines are supplied by the
linker,
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /
dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /
dev/null; done
real0m7.557s
user0m4.121s
sys 0m3.426s
So
v1 - v2:
- RMO - PAM
Except you forgot the subject line.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
+To find out if we're running on KVM or not, we overlay the PVR
register. Usually
+the PVR register contains an id that identifies your CPU type. If,
however, you
+pass KVM_PVR_PARA in the register that you want the PVR result in,
the register
+still contains KVM_PVR_PARA after the mfpvr
Actually, this is something which might need closer attention - and
maybe some support in the device tree indicating which read or
write width a device can accept?
There already is device-width; the drivers never should use any other
access width unless they *know* that will work.
Segher
Hmm, unfortunately, it's usage is not clearly documented in mtd-
physmap.txt,
It's pretty clear I think. Patches for making it better are welcome
of course.
so I never thought of this parameter. And IMHO the problem goes
further - basically *any* chip which is attached to the LPB can be
+ if (prop)
+ prom_remove_property(node, prop);
+ prop = of_find_property(node, linux,devietree-end, NULL);
Either the indentation is wrong, or you're missing some braces here
You're missing a c as well (and a dash).
Segher
V4: Fixed misspelling
Any particular reason you fixed only one of the two
mispelings I pointed out? (device tree is two words,
not one).
+ prop = of_find_property(node, linux,devicetree-start, NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop =
Any particular reason you fixed only one of the two
mispelings I pointed out? (device tree is two words,
not one).
Ahh, my fault.
Well I wasn't terribly clear ;-)
You could use one property instead of two; use addr+len
like every other property does.
You also should use a better name for
401 - 500 of 1470 matches
Mail list logo