On Sun, 2011-10-09 at 12:30 +0200, Eli Cohen wrote:
Ideally you want to avoid that swapping altogether and use the right
accessor that indicates that your register is BE to start with. IE.
remove the swab32 completely and then use something like
iowrite32be() instead of writel().
I
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
On Mon, 2011-10-10 at 09:20 +0100, David Laight wrote:
For the above I'd actually suggest making 'doorbell_qpn' have the
correct endianness in order to avoid the (potential) swap every
time it is set.
Well, the problem is that either you'll end up swapping on x86 or you'll
end up swapping on
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
On Mon, Oct 10, 2011 at 09:40:17AM +0100, David Laight wrote:
Actually memory barriers shouldn't really be added to
any of these 'accessor' functions.
(Or, at least, ones without barriers should be provided.)
The driver may want to to a series of writes, then a
single barrier, before a
On Mon, 2011-10-10 at 09:40 +0100, David Laight wrote:
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 !
On Mon, 2011-10-10 at 10:47 +0200, Eli Cohen wrote:
On Mon, Oct 10, 2011 at 09:40:17AM +0100, David Laight wrote:
Actually memory barriers shouldn't really be added to
any of these 'accessor' functions.
(Or, at least, ones without barriers should be provided.)
The driver may want to
On Mon, Oct 10, 2011 at 11:01:24AM +0200, Benjamin Herrenschmidt wrote:
The case where things get a bit more nasty is when you try to use MMIO
for low latency small-data type transfers instead of DMA, in which case
you do want the ability for the chipset to write-combine and control the
On Mon, 2011-10-10 at 11:16 +0200, Eli Cohen wrote:
Until then I think we need to have the logic working right on ppc and
measure if blue flame buys us any improvement in ppc. If that's not
the case (e.g because write combining is not working), then maybe we
should avoid using blueflame in
On Mon, Oct 10, 2011 at 11:24:05AM +0200, Benjamin Herrenschmidt wrote:
On Mon, 2011-10-10 at 11:16 +0200, Eli Cohen wrote:
Until then I think we need to have the logic working right on ppc and
measure if blue flame buys us any improvement in ppc. If that's not
the case (e.g because write
On Mon, 2011-10-10 at 11:29 +0200, Eli Cohen wrote:
On Mon, Oct 10, 2011 at 11:24:05AM +0200, Benjamin Herrenschmidt wrote:
On Mon, 2011-10-10 at 11:16 +0200, Eli Cohen wrote:
Until then I think we need to have the logic working right on ppc and
measure if blue flame buys us any
On Tue, 2011-10-04 at 17:26 -0300, Thadeu Lima de Souza Cascardo wrote:
if (ring-bf_enabled desc_size = MAX_BF !bounce
!vlan_tag) {
*(u32 *) (tx_desc-ctrl.vlan_tag) |=
ring-doorbell_qpn;
Could this have endianness problems ?
op_own |=
On Wed, 2011-10-05 at 10:15 +0200, Eli Cohen wrote:
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are
On Thu, 2011-10-06 at 15:57 +0200, Eli Cohen wrote:
On Wed, Oct 05, 2011 at 10:15:02AM +0200, Eli Cohen wrote:
How about this patch - can you give it a try?
From dee60547aa9e35a02835451d9e694cd80dd3072f Mon Sep 17 00:00:00 2001
From: Eli Cohen e...@mellanox.co.il
Date: Thu, 6 Oct 2011
On Sun, Oct 09, 2011 at 09:25:18AM +0200, Benjamin Herrenschmidt wrote:
On Thu, 2011-10-06 at 15:57 +0200, Eli Cohen wrote:
On Wed, Oct 05, 2011 at 10:15:02AM +0200, Eli Cohen wrote:
How about this patch - can you give it a try?
From dee60547aa9e35a02835451d9e694cd80dd3072f Mon Sep
On Sun, 2011-10-09 at 09:35 +0200, Eli Cohen wrote:
On Sun, Oct 09, 2011 at 09:25:18AM +0200, Benjamin Herrenschmidt wrote:
On Thu, 2011-10-06 at 15:57 +0200, Eli Cohen wrote:
On Wed, Oct 05, 2011 at 10:15:02AM +0200, Eli Cohen wrote:
How about this patch - can you give it a try?
On Sun, Oct 09, 2011 at 10:00:54AM +0200, Benjamin Herrenschmidt wrote:
On Sun, 2011-10-09 at 09:35 +0200, Eli Cohen wrote:
On Sun, Oct 09, 2011 at 09:25:18AM +0200, Benjamin Herrenschmidt wrote:
On Thu, 2011-10-06 at 15:57 +0200, Eli Cohen wrote:
On Wed, Oct 05, 2011 at 10:15:02AM
On Sun, 2011-10-09 at 10:07 +0200, Eli Cohen wrote:
Well, first, what do you mean by swapped ? :-) But no, it won't for
all intend and purpose, this is a copy routine, copy routines never
swap, neither do fifo accesses for example.
When I say swapped, I mean not necessairliy by software. I
On Sun, Oct 09, 2011 at 10:38:56AM +0200, Benjamin Herrenschmidt wrote:
On Sun, 2011-10-09 at 10:07 +0200, Eli Cohen wrote:
Well, first, what do you mean by swapped ? :-) But no, it won't for
all intend and purpose, this is a copy routine, copy routines never
swap, neither do fifo
To go back to the driver code, the statements that ring a bell are:
*(u32 *) (tx_desc-ctrl.vlan_tag) |= ring-doorbell_qpn;
This doesn't look right unless doorbell_qpn itself is already somewhat
in the appropriate byte order.
This is something that supports my claim that the
On Sun, Oct 09, 2011 at 11:52:19AM +0200, Benjamin Herrenschmidt wrote:
To go back to the driver code, the statements that ring a bell are:
*(u32 *) (tx_desc-ctrl.vlan_tag) |= ring-doorbell_qpn;
This doesn't look right unless doorbell_qpn itself is already somewhat
in the
On Wed, Oct 05, 2011 at 10:15:02AM +0200, Eli Cohen wrote:
How about this patch - can you give it a try?
From dee60547aa9e35a02835451d9e694cd80dd3072f Mon Sep 17 00:00:00 2001
From: Eli Cohen e...@mellanox.co.il
Date: Thu, 6 Oct 2011 15:50:02 +0200
Subject: [PATCH] mlx4_en: Fix blue flame on
On Tue, Oct 04, 2011 at 05:26:20PM -0300, Thadeu Lima de Souza Cascardo wrote:
I believe we have an endianess problem here. The source buffer is in
big endian - in x86 archs, it will rich the pci device unswapped since
both x86 and pci are little endian. In ppc, it wil be swapped by the
chipset
On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
.../...
Can you also send me the output of ethtool -i?
It seems that there is a problem with write combining on Power processors,
we will check this issue.
Yevgeny
Hello, Yevgeny.
You will find the output
On Tue, Oct 04, 2011 at 08:02:12AM +0200, Benjamin Herrenschmidt wrote:
On Mon, 2011-10-03 at 17:53 -0300, Thadeu Lima de Souza Cascardo wrote:
.../...
Can you also send me the output of ethtool -i?
It seems that there is a problem with write combining on Power
processors, we will
On Mon, Oct 03, 2011 at 02:56:08PM +, Yevgeny Petrilin wrote:
Hello, Yevgeny.
We use a MT26448 (lspci -v output bellow) on a POWER7. Any other
information, tests or debug patches you want me to try, just tell me.
I expected this was really not the proper fix, but thought it would
26 matches
Mail list logo
