(I apologise for this not having much to do with linux...)
We have a system with an MPC8315 ppc running linux 2.6.32
that uses the PCI express interface in RC mode to interface
to an Altera FPGA.
This uses both PIO and the PEX DMA interfaces (locally
written dma driver).
Under normal
A special pread/pwrite asm stub that just copies
r7 to r0 could be used.
Would it be enough to do:
syscall_pread_pwrite:
mov 0,7
sc
blr
and handle the -ve - errno in C?
Huh? Won't fly, r0 is used for the system call number!
I was copying that from r7!
Actually I
We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).
I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
(the same is true
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -287,7 +287,7 @@ static int wf_sat_probe(struct i2c_client *client,
sens-sat = sat;
sens-sens.ops = wf_sat_ops;
sens-sens.name = (char *) (sens + 1);
-
The function is renamed to make it a little more clear what it does.
It is not added to any .h because it is not for general
consumption, only for bpf internal use (and so by the jits).
I'd have thought it better to put in into a bfp_internal.h
(or similar) with a big warning there about
diff --git a/arch/powerpc/sysdev/fsl_rmu.c
b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..1bba6d1 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -657,7 +658,8 @@ fsl_add_outb_message(struct rio_mport
*mport, struct rio_dev *rdev, int mbox,
int ret
Issue:
Applications using lwarx/stwcx instructions in the core to
compete for a software lock or semaphore with a device on
RapidIO using read atomic set, clr, inc, or dec in a similar
manner may falsely result in both masters seeing the lock
as available. This could result in data
For the file arch/powerpc/sysdev/fsl_rmu.c, there will be
some compile errors while using the corenet64_smp_defconfig:
I'm sure that replacing 'u32' with 'unsigned long'
is really the best thing to do here.
It looks to me as though they should be some pointer type.
David
+struct eeh_stats {
+ unsigned int no_device; /* PCI device not found */
...
+ no device =%d\n
...
Use %u (for all the stats), you really don't want negative
values printed.
I've NFI how long wrapping these counters might take!
If it is
+/*
+ * The struct is used to maintain the EEH global statistic
+ * information. Besides, the EEH global statistics will be
+ * exported to user space through procfs
+ */
+struct eeh_stats {
+ unsigned long no_device;/* PCI device not found
*/
+ unsigned long no_dn;
I am trying to locate the device tree for OMAP platform which
has ARM and TI DSP core.
The background is that we are trying to understand how such
SOCs with dissimilar cores are represented in linux.
Most likely linux runs on the ARM, and the DSP processor
is loaded with specific code
One idea would be to have a structure of function pointers for each
CPU that gets runtime patched into the right places,
similar to how we do some of the MMU fixups.
Sounds good to me :-)
Except the indirect jump/call is almost certainly
never predicted - so will be slow.
You might
Looking at this:
#ifndef atomic_inc_unless_negative
static inline int atomic_inc_unless_negative(atomic_t *p)
{
int v, v1;
for (v = 0; v = 0; v = v1) {
v1 = atomic_cmpxchg(p, v, v + 1);
if (likely(v1 == v))
return 1;
+#define mfdcrx(rn) \
+ ({ \
+ unsigned long rval; \
+ asm volatile(mfdcrx %0,%1 : =r(rval) : g(rn)); \
+ rval; \
+ })
g is never correct on PowerPC, you want r here. You can write
this as a static inline btw, you only need the #define
Subject: [PATCH 2/2] powerpc/85xx: Renamed mpc85xx_common.c
to common.c
The file name is already scoped by the directory its in.
...
rename from arch/powerpc/platforms/85xx/mpc85xx_common.c
rename to arch/powerpc/platforms/85xx/common.c
All very well until you only have a reference to
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be
masked. This can be a problem when pmac_zilog starts up.
Wouldn't this also happen if the interrupt were shared?
Hopefully nothing vaguely modern uses the borked Zilog 8530 SCC
(which I presume is the part in question -
On Tue, 2011-11-15 at 11:26 +, Jenkins, Clive wrote:
fix whitespaces,tabs coding style issue and ...
In my opinion this code was already correct, and would display
correctly
at any TAB setting. This patch changes it so that it displays
incorrectly at all TAB settings other than
We have some connections that suffer very badly from the TCP
'slow start' algorithm. These are connections that will
always be local - they may be MAC-Switch-MAC using RGMII
crossover, they might also be connected via an external
switch. In either case the RTT is most likely to be almost
zero,
How about using clean_dcache_range() to flush the range runtime
address range [ _stext, _end ] ? That would flush the entire
instructions.
Wouldn't that result in more cache flushing than the original
solution?
For example, my kernel is 3.5MB. Assuming a 32 byte cache line
size,
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
On 11/03/11 05:06, Josh Poimboeuf wrote:
On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
@@ -137,6 +137,9 @@ get_type:
lwz r0, 8(r9) /* r_addend */
add r0, r0, r3 /* final
Below are codes for accessing usb sysif_regs in driver:
usb_sys_regs = (struct usb_sys_interface *)
((u32)dr_regs + USB_DR_SYS_OFFSET);
these codes work in 32-bit, but in 64-bit, use u32 to type cast the
address
of ioremap is not right, and accessing members of 'usb_sys_regs' will
On Thu, Nov 3, 2011 at 4:58 AM, Shaohui Xie shaohui@freescale.com wrote:
usb_sys_regs = (struct usb_sys_interface *)
- ((u32)dr_regs + USB_DR_SYS_OFFSET);
+ ((unsigned long)dr_regs +
USB_DR_SYS_OFFSET);
usb_sys_regs = (void *)dr_regs + USB_DR_SYS_OFFSET;
But that is invalid C.
What's invalid about it? I haven't tried compiling this
specific line of code, but I've done stuff like it in the past many
times.
Are you talking about adding an integer to a void pointer?
If so, then
#ifndef CONFIG_ARCH_MXC
if (pdata-have_sysif_regs)
- usb_sys_regs = (struct usb_sys_interface *)
- ((u32)dr_regs + USB_DR_SYS_OFFSET);
+ usb_sys_regs = ioremap(res-start + USB_DR_SYS_OFFSET,
+
Kumar Gala wrote:
+ phys_addr_t addr;
Please add a comment here saying:
1) That 'addr' can be a virtual or physical address
The code and everything else makes that clear
I'm sorry, but I have to strongly disagree here. It is *NOT*
clear that a variable
Then, this statement:
*(u32 *) (tx_desc-ctrl.vlan_tag) |= ring-doorbell_qpn;
...
instead do ... :
*(u32 *) (tx_desc-ctrl.vlan_tag) |=
cpu_to_be32(ring-doorbell_qpn);
(Also get rid of that cast and define vlan_tag as a __be32 to start
with).
Agreed, casts that change the type
What is this __iowrite64_copy... oh I see
Nice, somebody _AGAIN_ added a bunch of generic IO
accessors that are utterly wrong on all archs except
x86 (ok, -almost-).
There isn't a single bloody memory barrier in there !
Actually memory barriers shouldn't really be added to
any of these
static void mlx4_bf_copy(unsigned long *dst, unsigned long *src,
unsigned bytecnt) {
+ int i;
+ __le32 *psrc = (__le32 *)src;
+
+ /*
+ * the buffer is already in big endian. For little endian
machines that's
+ * fine. For big endain machines we must swap since the
Not entirely relevant to the error you are seeing,
but your ISR is:
irqreturn_t cpld_irq_handler(int irq, void * dev_id, struct
pt_regs *regs)
{
wake_up(cpld_intr_wait);
atomic_inc(cpld_intr_data); /* incrementing this will
indicate the poll() that the
Subject: build failure with gcc 4.6.0 array subscript is
above array bounds
...
That corresponds to:
tmp = ((unsigned long *)child-thread.fpr)
[TS_FPRWIDTH * (index - PT_FPR0)];
child-thread.fpr is double fpr[32][TS_FPRWIDTH].
index has already been bounds checked
Joakim Tjernlund joakim.tjernl...@transmode.se writes:
unsigned short my__arch_swab16(unsigned short value)
{
__asm__(rlwimi %0,%0,16,0x00ff
: +r (value));
You are creating a value that does not fit in a short.
Which is a problem because the compiler could
Which is a problem because the compiler could schedule
it be written back to real memory between the instructions.
It can? There is no memory here, just registers. Even if it
is written to memory, how would that affect the register?
Although the function argument is passed in a
I have some and use them in some code, they represent ISA
2.06 MAVN=1 (version 2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
Bitfields are rather non-portable, the compiler has a lot of choice
about how to align the bits in memory.
I'm ok with the masking stuff.
However, I'm actually surprised this is true given the
maturity of our ABIs.
The C standard says nothing at all about how bitfields are
Got it, if the fault_in_user_writeable() is designed to catch the
exact same write permission fault problem we discuss here, so
your patch fixed that very nicely, we should fixup it by directly
calling handle_mm_fault like what you did because we are for sure
to know what just
The fault causing futex_atomic_cmpxchg_inatomic() is
protected by pagefault_disable(), so the page fault handler has
no chance to toggle the SW dirty/young tracking.
Perhaps that is the bug!
Whatever pagefault_disable() does, it shouldn't disable the
SW dirty/young tracking - which should
As a result of changes to Kconfig files, we no longer enable
the lockup and hung task detectors. Both are very light weight
and provide useful information in the event of a hang, so
reenable them.
...
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_DETECT_HUNG_TASK=y
Is one of thise responsible for
On Fri, Jun 17, 2011 at 02:54:00PM +1000, Anton Blanchard wrote:
Implement a POWER7 optimised memcpy using VMX. For large aligned
copies this new loop is over 10% faster and for large unaligned
copies it is over 200% faster.
...
BTW: do you have any statistics on the size distribution
Hello,
Motioned to the memory aligned, now there is such requirement:
When the driver send an packet to hardware, the skb's address passed
by
stack do a dma map into hardware, the skb's dma address must
be 64-byte aligned.
Does the hardware support buffer chaining?
In which case you only
For finding structures, the following pattern tends to work well:
git grep 'struct device_node {'
In general 'typedef.*\type_name\' will find types.
eg: grep -r -n --include '*.h' 'typedef.*\type_name\'
base_of_source_tree
Finding functions (in .c files) is easy if names start in
column 1
The PPC440X currently uses 256M TLB entries to pin the
lowmem. When we go for a relocatable kernel we have to :
1) Restrict the kernel load address to be 256M aligned
OR
2) Use 16M TLB(the next possible TLB page size supported)
entries till the first
256M and then use the 256M TLB
+enum fsl_hv_ioctl_cmd {
+ FSL_HV_IOCTL_PARTITION_RESTART = _IOWR(0, 1, struct
fsl_hv_ioctl_restart),
...
+};
Using a #define here is usually preferred because then you
can use #ifdef in a user application to check if a given
value has been assigned.
It is also possible to
Subject: [gianfar]bandwidth management problem on mpc8313 based board
...
I have mpc8313 powerpc based board with silicon revision 2.1. the
processor has two ETH ports (eTsec1 and eTsec2) i.e. eth0 and eth1.
eth0 is 1Gbps port and eth1 is 100Mbps port. On board there is L2
switch from
Changed the add_usable_mem_property() to accept FILE* fp instead of
int fd,
as most of the other users of read_memory_region_limits() deals with
FILE*.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Could you please let me know your thoughts/comments about this patch ?
Is the
+int __init fsl_add_pci_err(void)
static :-)
and why __ ?
aren't such names reserved in the C language for some purpose.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, May 24, 2011 at 11:16:12PM -0700, efti wrote:
I am trying to run tcl of my PPC460ex board. I have download the
tcl-8.3.3-sol26-sparc-local.gz file. But when I run it I get
the Syntax error.
That tarball seems to indicate it's for both Solaris and Sparc.
PPC460ex is neither
we have a pretty old PCI device driver here that needs some
basic rework running on 2.6.27 on several MPC83xx.
It's a simple char-device with give me some data implemented
using read() resulting in zero-copy DMA to user mem.
There's get_user_pages() working under the hood along with
The specific mpt2sas problem is that if we write a 64 bit register non
atomically, we can't allow any interleaving writes for any other
region
on the chip, otherwise the HW will take the write as complete in the
64
bit register and latch the wrong value. The only way to achieve that
given
On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote:
what is the best book to learn assembly and architecture .
Assuming you have a powerpc compiler available you can use the -S
option to produce assembly listings.
With gcc add -fverbose-asm for more info.
For a general
static inline void writeq(__u64 val, volatile void __iomem
*addr)
{
writel(val, addr);
writel(val 32, addr+4);
}
...
We need the 64 bit completed in one access pci memory write,
else spin lock is required.
Since it's going to be difficult to know
... If you can be completely stateless its easier, but there's
a reason that stacking security modules is hard. Serge has tried in
the
past and both dhowells and casey schaufler are working on it right
now.
Stacking is never as easy as it sounds :)
For a bad example of trying to allow
Introduce an *_dec_not_zero operation. Make this a special case of
*_add_unless because batman-adv uses atomic_dec_not_zero in different
places like re-broadcast queue or aggregation queue management. There
are other non-final patches which may also want to use this macro.
Isn't there a
I keep telling Eric that the code below is incorrect
modulo arithimetic...
+static u64 check_and_compute_delta(u64 prev, u64 val)
+{
+ u64 delta = (val - prev) 0xul;
+
+ /*
+ * POWER7 can roll back counter values, if the new value is
smaller
+ * than the previous
But it isn't, and it doesn't have trouble with 2^32 - 1.
what about:
prev = 0x0001
val = 0x
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
+ if (prev val (prev - val) 256)
+ delta = 0;
+
+ return delta;
Also, 'prev' is a true 64bit value, but 'val' is only ever 32bits.
So once the 64bit 'prev' exceeds 2^32+256 both 'prev val'
and 'prev - val' are true regardless of the value of 'val'.
This will lead to
On Wed, 27 Apr 2011, David Laight wrote:
But it isn't, and it doesn't have trouble with 2^32 - 1.
what about:
prev = 0x0001
val = 0x
Result is 0xfffe and we are fine.
'delta' will be 0xfffe, but you need the function to
return zero - since the underlying
prev and val are both 64 bit variables holding 32 bit numbers, we do
not
accumulate in either, they are both replaced by values directly from
the
registers.
So prev val will not always be true.
The code seems to be:
prev = local64_read(event-hw.prev_count);
val =
From:
linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozl
abs.org] On Behalf Of Nishanth Aravamudan
Sent: 13 April 2011 15:53
To: Ben Herrenschmidt
Cc: linuxppc-...@ozlabs.org; Paul Mackerras; Anton Blanchard
+ u64 delta = 0;
...
+ if (((prev 0x8000) !(val 0x8000)) || (val
prev))
+ delta = (val - prev) 0xul;
+
+ return delta;
The above is incorrect modulo arithmetic.
It is probably intended to do:
s32 delta = val - prev;
return delta 0 ? 0
- xhci_handle_event(xhci);
+ while (xhci_handle_event(xhci)) {}
I must admit I dislike the style with empty loop bodies...
I would use an explicit 'continue;' for the body
of an otherwise empty loop.
David
___
Linuxppc-dev
I've this Quad G5 machine that's sitting pretty much idle with the
latest Debian stable installed, and yet it's got an abnormaly high
load average.
The 'load average' value is rather useless since it seems to
contain any process that is sleeping uninterruptibly, and
IIRC any process that has
Case when ffs return will never arise.This scenario is
already been discussed
on linuxppc-dev@lists.ozlabs.org. Please see below explanation:
sata_fsl_error_intr() is called during device error.The
mentioned scenario
will never comes. It can be observed via code:-
if (cereg)
The patch changes the code to:
if (ap-nr_pmp_links) {
+ int dev_num;
dereg = ioread32(hcr_base + DE);
...
+ dev_num = ffs(dereg)-1;
+ if (dev_num ap-nr_pmp_links) {
+
+ if ((ffs(dereg)-1) ap-nr_pmp_links) {
+ /* array start from 0 */
+ link = ap-pmp_link[ffs(dereg)-1];
I'd only call ffs() once - it could be a slow library function.
Any comment should note that ffs() returns 0
Sorry, I don't understand that. I think u32 is always 32bit
4byte on all archs. Right?
Yes.
Use an unsigned long if you want to hold a pointer correctly on all
arches.
Although that is true for many systems (and probably all ppc Linux)
it isn't necessarily true (eg 64 bit Microsoft
I was completely unaware of that feature. I hunch that many
drivers
are incapable of dealing with an unbind while they are still open.
Hmm, maybe older drivers... Anythig hotpluggable (USB, PCI, etc)
should
be in a better shape because they expect to be yanked at any time.
Whim and
This driver allows userspace to access the data processing
FPGAs on the OVRO CARMA board. It has two modes of operation:
1) random access
This allows users to poke any DATA-FPGA registers by using mmap to map
the address region directly into their memory map.
I needed something
[Marri] If u32 is 8bytes isn't pointer type would be 8bytes
as well.
If u32 is 8bytes 'char' would only be 4 bits!
(IIRC the X code has a fubar that requires a type with 32
in its name to be 64 bits!)
David
___
Linuxppc-dev mailing list
+#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name
+ 3)
Whenever you use a #define macro arg, you should enclose it in ().
About the only time you don't need to is when it is being
passed as an argument to another function
(ie when it's use is also ',' separated).
So the
+#define __BUG_ON(x) do { \
if (__builtin_constant_p(x)) { \
if (x) \
BUG(); \
@@ -85,6 +86,8 @@
}
+ if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12)
+ ((unsigned long)fcb % 0x20) 0x18)) {
You need to check the generated code, but I think you need:
if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_12))
unlikely(((unsigned long)fcb %
What was the ppc you used?
The 8315E PowerQUIICC II
On 85xx/QorIQ-family chips such as P2020, there is no DMA controller
inside the PCIe controller itself (or are you talking about bus
mastering by the PCIe device[1]? interface is a bit ambiguous),
though it was considered part of the
Also in_le32/out_le32/in_be32/out_be32 are
architecture-specific AFAIK.
Isn't the whole patch architecture-specific ?
I'd suggest using readl/writel for LE ops and
__be32_to_cpu(__raw_readl(addr))/__raw_writel(__cpu_to_be32(b),addr)
for BE ops.
Since the ppc doesn't have a byteswap
I'm trying to use FSL DMA engine to perform DMA transfer from
memory buffer obtained by kmalloc() to PCI memory. This is on
custom board based on P2020 running linux-2.6.35. The PCI
device is Altera FPGA, connected directly to SoC PCI-E controller.
You'll need to use the dma engine that is
memcpy_toio() works fine, the data is written correctly. After
DMA, the correct data appears at offsets 0xC, 0x1C, 0x2C, etc.
of the destination buffer. I have 12 bytes of junk, 4 bytes of
correct data, then again 12 bytes of junk and so on.
Does your Avalon MM slave decode the 4 byte
custom board based on P2020 running linux-2.6.35. The PCI
device is Altera FPGA, connected directly to SoC PCI-E
controller.
This sounds like your FPGA doesn't handle burst mode accesses
correctly.
A logic analyzer will help you prove it.
He is doing PCIe, not PCI.
A PCIe transfers
An external IRQ line would let you limit interrupts to rising edges
rather than all edges, though you'd lose the ability to
directly read the line status.
oh, one cannot read the IRQ line? didn't know that. Also I not sure
all Freescale CPUs can do rising edge.
I suspect that you may
The problem cropped up when there was a lot of traffic to the NAND
(Samsung K9WAGU08U1B-PIB0), with the NAND being on the LBC along with
a video chip that needed constant and prompt attention.
What I would see is that, as the writes happened, the erases would
wind up batched and issued
That's the idea. Communication between usermode and the driver is
limited to
simple ioctl calls and the driver receives an interrupt when certain
data has
been placed in memory blocks by the hardware (like a DMA).
Then the user prog figures out where that latest data buffer is (mmap)
and
Another question: I just spent 10 minutes trying to find
where struct device was defined.
Dirty trick #4:
At the top of a source file (before the first include) add:
struct device { int fubar; };
Then try to compile it.
The compiler will the tell where it is defined!
David
A mb() is usually used if you do a write to device and read from it.
With out it, the CPU could perform the read before the write, which
would give you an incorrect result. There's no other way around that.
Possibly the synchronisation functions are doing significantly
more work than is
On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote:
My application needs a fast way to access a specific physical DDR
memory region. The application runs on an MPC8548 PowerPC which has
an
MMU. I've tried two approaches that are typical for Linux, mmap()
and
using a kernel
OOPS! It is wrong here, The right one should be as following:
- memcpy(mem, current-thread.evr[regno-32],
+ memcpy(mem, (void*)current-thread.evr[regno-32],
dbg_reg_def[regno].size);
The (void *) cast should be unnecessary
David
I can't make out what is causing this hang every now an then:
INFO: task snmpd:398 blocked for more than 120 seconds.
My problem with that 'error' message is that there is no way
for a driver to disable it on a per-process basis.
We have some processes whose 'normal state' is to sleep
I'm trying to get a ppc 831x to do PCIe dma transfers, PIO transfers
work ok but are somewhat lethargic (partially due to the slave).
I've done the following:
- All reads/writes (including the dma descriptors) are byteswapped.
- Enabled the dma in PEX_CSB_CTRL (value 0x3f)
- Used the kernel
501 - 585 of 585 matches
Mail list logo
