RE: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic

2011-05-19 Thread David Laight
 
 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 the semantics of writeq is a global static spinlock.

That sounds like very specific and slightly dodgy hardware.
You don't say what the scope of 'region on the chip' is, but
it looks like you need to disable ALL writes to the memory
area between the first and second writes of the 64bit value
and not just those coming from writeq().
I don't see how this can possibly be done by normal mutexing
around the writeq() sequence, surely you need to lock the bus
between the two transfers.
Even dma writes would be a problem.

The only way I can think to stop other cpus doing writes
is to use IPIs for force them into a busy wait loop.

All rather reminds me of a PCI slave that got things
horribly wrong when a read was done while a write was
still 'posted', or a 2nd master did a cycle did a read
while a read rerun sequence was still in progress.
(required a mutex and dummy cycles).
At least than one wqs confined to one driver.

David


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: [PATCH 1/3] mpt2sas: remove the use of writeq, since writeq isnot atomic

2011-05-18 Thread David Laight
 

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 which writeq was
implemented in the kernel, 
the driver is going to have to always acquire a spin lock each
time we do 64bit write.
...
 I'm just in the process of finding them now on IRC so I can demand an
 explanation: this is a really serious API problem because writeq is
 supposed to be atomic on 64 bit.

Most 32 bit systems don't have atomic 64bit writes.
I'd also have thought there would be code which wouldn't mind the
write being done as two cycles.

I'm not sure that some of the ppc soc systems are capable of
doing a 64bit data pci/pcie cycle except by dma.
So your driver is probably doomed to require a lock.

David


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev