ect: Re: [PATCH] s2io ppc64 fix for readq/writeq
>
> > For consistencies sake we really want to have readq() and writeq()
> available
> > on all platforms. I remember that some IB cards require it to
actually
> > be a 64bit transactions, otherwise they have to do funny
work
> Generally the kernel code should write the two 32-bit chunks to the
> memory-mapped region in order (low dword first), and let things take
> care of themselves from there.
>
> That's pretty much the implementation that -every- driver copies, when
> they need readq/writeq to work on a 32-bit
> For consistencies sake we really want to have readq() and writeq() available
> on all platforms. I remember that some IB cards require it to actually
> be a 64bit transactions, otherwise they have to do funny workarounds.
> I think the best solution is to define ARCH_HAS_ATOMIC_READQ_WRITEQ
On Mon, Nov 06, 2006 at 03:33:19PM -0500, Ramkrishna Vepa wrote:
> The 64 bit io operation on the IA64 platform is a 64 bit transaction on
> the pci bus and is optimal to leave it as such. I prefer Jeff's
> suggestion -
>
> guaranteeing that a "good enough for drivers" readq() and writeq() exist
operation isn't
inherently atomic.
Ram
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Benjamin Herrenschmidt
> Sent: Monday, November 06, 2006 1:57 AM
> To: Jeff Garzik
> Cc: Linus Torvalds; netdev@vger.kernel.org
> Subject: Re
On Mon, 2006-11-06 at 04:55 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
> >> On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
> >>> Anyway, what do you think of Jeff proposal to just implement them as two
> >>> 32 bits oper
Benjamin Herrenschmidt wrote:
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
Anyway, what do you think of Jeff proposal to just implement them as two
32 bits operations ? My arch guy side screams at the idea, but if,
indeed, drivers ge
On Mon, 2006-11-06 at 01:50 -0800, Linus Torvalds wrote:
>
> On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
> >
> > Anyway, what do you think of Jeff proposal to just implement them as two
> > 32 bits operations ? My arch guy side screams at the idea, but if,
> > indeed, drivers generally cope
On Mon, 6 Nov 2006, Benjamin Herrenschmidt wrote:
>
> Anyway, what do you think of Jeff proposal to just implement them as two
> 32 bits operations ? My arch guy side screams at the idea, but if,
> indeed, drivers generally cope fine with it, I suppose that's ok.
Last I saw, that's how normal PC
On Mon, 2006-11-06 at 01:37 -0800, Linus Torvalds wrote:
>
> On Mon, 6 Nov 2006, Jeff Garzik wrote:
> >
> > This seems a bit ugly. Could you add
> >
> > #define readq readq
> >
> > to your platform instead?
>
> Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
> whet
On Mon, 6 Nov 2006, Jeff Garzik wrote:
>
> This seems a bit ugly. Could you add
>
> #define readq readq
>
> to your platform instead?
Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
whether arch-related or otherwise.
Linus
-
To unsubscribe from
Benjamin Herrenschmidt wrote:
This is why I said "good enough for drivers". This is _key_.
I have run into several [PCI] devices with 64-bit registers, and
__none__ of them had requirements such that the Linux platform code
-must- provide an atomic readq/writeq. Probably because everybody wa
> This is why I said "good enough for drivers". This is _key_.
>
> I have run into several [PCI] devices with 64-bit registers, and
> __none__ of them had requirements such that the Linux platform code
> -must- provide an atomic readq/writeq. Probably because everybody wants
> to support 32-b
Benjamin Herrenschmidt wrote:
This seems a bit ugly. Could you add
#define readq readq
to your platform instead?
That's ugly too imho but I suppose I can do it :-)
I generally think it's a bug in the kernel-wide API, if use of said API
requires arch-specific ifdefs.
Yes. I agree.
> This seems a bit ugly. Could you add
>
> #define readq readq
>
> to your platform instead?
That's ugly too imho but I suppose I can do it :-)
> I generally think it's a bug in the kernel-wide API, if use of said API
> requires arch-specific ifdefs.
Yes. I agree. In that specific cas
Benjamin Herrenschmidt wrote:
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather that
The s2io driver is redefining it's own readq/writeq based on
readl/writel when the platform doesn't provide native ones. However, it
currently does so by testing #ifndef readq. While that works for now, we
are about to change ppc64 to use inline functions rather that macros for
all those IO accesso
17 matches
Mail list logo
