On 4/5/2019 2:28 PM, Maciej W. Rozycki wrote:
You basically can't remove the mb() after __ioread() and before
__iowrite() unless your architecture guarantees IO vs. memory ordering.
I never suggested that; please check my example too.
Sounds good. Sorry for the noise.
I just wanted to make
On 4/5/2019 1:29 PM, Maciej W. Rozycki wrote:
Obviously you do need that `mb' before `__ioread' in the second case,
just like in the first one, because otherwise the read bus access issued
by `__ioread' can be reordered ahead of the write bus access issued by the
preceding `__iowrite'.
On 2/27/2019 12:12 PM, Mikulas Patocka wrote:
It used to be like that and it worked.
Then, commits cd0e00c106722eca40b38ebf11cf134c01901086 and
92d7223a74235054f2aa7227d207d9c57f84dca0 came.
These commits claim that they changed the code to be consistent with the
specification (now we have
On 8/22/2018 3:56 PM, Mikulas Patocka wrote:
On Wed, 22 Aug 2018, Sinan Kaya wrote:
On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
If ARM guarantees that the accesses to a given device are not reordered -
then the barriers in readl and writel are superfluous.
It is not. ARM only guarantees
On 8/22/2018 1:47 PM, Mikulas Patocka wrote:
If ARM guarantees that the accesses to a given device are not reordered -
then the barriers in readl and writel are superfluous.
It is not. ARM only guarantees ordering of read/write transactions targeting
a device not memory.
example:
write
On 8/22/2018 7:59 AM, Mikulas Patocka wrote:
I did some tests on framebuffer and found out that "read+read+write+write"
is faster than "read+write+read+write" - that may suggest that the reads
flush the write queue.
I think we are worried about correctness at this moment like a raw_read
On 8/20/2018 6:39 PM, Maciej W. Rozycki wrote:
On Mon, 20 Aug 2018, Sinan Kaya wrote:
That is that the caller must not
assume that writes issued by `writeX' calls will be observed in order on
the external bus or specifically by the device addressed.
Where do you see it?
Right
On 8/20/2018 5:50 PM, Maciej W. Rozycki wrote:
That is that the caller must not
assume that writes issued by `writeX' calls will be observed in order on
the external bus or specifically by the device addressed.
Where do you see it?
I interpret that two writeX() need to be observed in order
On 8/19/2018 11:41 AM, Arnd Bergmann wrote:
Sounds like we need a similar solution for all architectures that
require mmiowb().
That depends on how expensive the barrier is on a given architecture.
It's possible that doing adding the barrier every time is actually
cheaper than keeping track of
On 8/19/2018 11:21 AM, Arnd Bergmann wrote:
This matches my understanding of mmiowb. In fact, mmiowb is a powerpc
thing. All other architectures stub out.
There are a few architectures that define mmiowb to something other
than a nop: some ia64, some mips and sh in particular, plus also the
new
On 4/20/2018 12:20 PM, Sinan Kaya wrote:
> Hi Matt,
>
> On 4/17/2018 2:43 PM, Sinan Kaya wrote:
>> On 4/16/2018 6:16 PM, Sinan Kaya wrote:
>>> memory-barriers.txt has been updated with the following requirement.
>>>
>>> "When using wri
Hi Matt,
On 4/17/2018 2:43 PM, Sinan Kaya wrote:
> On 4/16/2018 6:16 PM, Sinan Kaya wrote:
>> memory-barriers.txt has been updated with the following requirement.
>>
>> "When using writel(), a prior wmb() is not needed to guarantee that the
>> cache coherent mem
On 4/2/2018 1:48 PM, Sinan Kaya wrote:
> memory-barriers.txt has been updated with the following requirement.
>
> "When using writel(), a prior wmb() is not needed to guarantee that the
> cache coherent memory writes have completed before writing to the MMIO
> region.&
satisfying this requirement as the barrier is after the register write.
Move mb() in writeX() and iowriteX() functions to guarantee that HW
observes memory changes before performing register operations.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Reported-by: Arnd Bergmann <a...@
(addr);
mb();
return ret;
}
extern inline void writel(u32 b, volatile void __iomem *addr)
{
__raw_writel(b, addr);
mb();
}
There is a barrier in writel /after/ the access but not before."
Can somebody familiar with alpha evaluate this?
Sinan
--
Sinan Kay
On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Use pci_get_domain_bus_and_slot() with a domain numbe
the actual domain number from
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
arch/alpha/kernel/pci.c | 2 +-
arch/alpha/kernel/sys_nautilus.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
17 matches
Mail list logo
