On Fri, 01 Sep 2006 14:05:36 -0700
Roland Dreier <[email protected]> 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
>
> DECLARE_WRITEQ_LOCK()
> INIT_WRITEQ_LOCK()
> GET_WRITEQ_LOCK()
>
> 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
things.
As for interfaces, umm, something like
#ifdef CONFIG_ARCH_HAS_64BIT_ATOMIC_MMIO_WRITES
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)
#else
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);
__raw_writel(...);
__raw_writel(...);
spin_unlock_irqrestore(port->lockp, flags);
}
#define be64_port_init(port, addr)
spin_lock_init(&port->lock);
port->lockp = &port->lock;
port->addr = addr;
#define be64_port_init_external_locking(port, addr, lockp)
port->lockp = lockp;
port->addr = addr;
#endif
perhaps?
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
