[lkml]   [2006]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.18-rc5-mm1: drivers/infiniband/hw/amso1100/c2.c compile error
On Fri, 01 Sep 2006 14:05:36 -0700
Roland Dreier <> wrote:

> Andrew> If the hardware/driver absolutely requires that the 64-bit
> Andrew> write be atomic on-the-bus then sure, the fix is to
> Andrew> disable that driver on that architecture in Kconfig.
> Andrew> If, however, the atomicity requirement is a software thing
> Andrew> (we need to be atomic against other CPU reads and writes)
> Andrew> then that can be solved with locking, and we can design
> Andrew> APIs for this which can be implemented efficiently on all
> Andrew> architectures.
> It seems that there are cases of both. ipath needs actual 64-bit bus
> transactions to work properly.

If we define __raw_writeq() to be 64-bit-atomic-on-the-bus then an
appropriate solution for ipath would be to call __raw_writeq() directly.
If the arch cannot implement __raw_write() then build error -> Kconfig fix.

> mthca needs to make sure that if
> doorbell writes are split into two 32-bit halves, then no other writes
> go to the same MMIO page in between the halves.
> What do you think the API would look like? Something along the lines
> of mthca_doorbell.h, where we have macros for
> which get stubbed out on architectures where writeq is already atomic,
> and then pass the lock into writeq()?
> But then you probably need some Kconfig symbol to say if writeq() is
> really atomic or just software atomic (for ipath et al to depend on).

It depends on how many other devices have (or are expected to have)
mthca-like requirements. If the answer is "very few, maybe none" then
perhaps we don't need to go designing generic interfaces to support such

As for interfaces, umm, something like


struct be64_port {
void __iomem *addr;

static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
__raw_writeq(v, port->addr);

#define be64_port_init(port, addr)
port->addr = addr;

#define be64_port_init_external_locking(port, addr, lockp)
be64_port_init(port, addr)


struct be64_port {
void __iomem *addr;
spinlock_t lock;
spinlock_t *lockp;

static inline void atomic_be64_mmio_write(u64 v, struct be64_port *port)
unsigned long flags;

spin_lock_irqsave(port->lockp, flags);
spin_unlock_irqrestore(port->lockp, flags);

#define be64_port_init(port, addr)
port->lockp = &port->lock;
port->addr = addr;

#define be64_port_init_external_locking(port, addr, lockp)
port->lockp = lockp;
port->addr = addr;



btw, 32-bit mthca_write64() is downright scary from an endianness POV. I
guess it's right, but I wouldn't label it "obviously correct" ;)

VGER BF report: H 0
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-09-01 23:37    [W:0.136 / U:5.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site