Prev: [PATCH] Change struct flchip_shared spinlock locking into mutex
Next: [GIT PULL] 9p file system changes for the 2.6.36 merge window
From: H. Peter Anvin on 2 Aug 2010 17:50 On 08/02/2010 02:35 PM, Ondrej Zary wrote: > > The patch below fixes it for me. Is it correct on all architectures? > > --- linux-2.6.35-rc2/drivers/video/matrox/matroxfb_base.h 2010-06-06 05:43:24.000000000 +0200 > +++ linux-2.6.35-rc3/drivers/video/matrox/matroxfb_base.h 2010-08-02 23:31:34.000000000 +0200 > @@ -157,7 +157,7 @@ static inline void mga_memcpy_toio(vaddr > * (3) It copes with unaligned source (destination is guaranteed to be page > * aligned and length is guaranteed to be multiple of 4). > */ > - memcpy_toio(va.vaddr, src, len); > + iowrite32_rep(va.vaddr, src, len); > #else > u_int32_t __iomem* addr = va.vaddr; > I don't think so; in particular I don't *think* non-x86 architectures will deal with the requirement that it handles an unaligned source. As such, the #if would still be necessary; the #else clause could be replaced with a get_unaligned() ... iowrite32() loop. The other thing to watch out for is that "len" passed to iowrite32_rep() is a count of 32-bit words, whereas memcpy_toio() takes a byte count... you need to >> 2 there. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Chris Rankin on 2 Aug 2010 20:10 > matroxfb (at least with Mystique and Mystique 220) stopped working > in 2.6.34 - the screen is completely corrupted. Interesting... I have just upgraded one of my old machines with a Matrox Millenium II card to 2.6.33.7, and have noticed that the matroxfb console has developed a slight wobble. (Think of a subtle "heat haze" / "one too many beers" kind of effect.) Have any relevant changes been back-ported to 2.6.33.x-stable, please? Cheers, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ondrej Zary on 3 Aug 2010 14:40
On Monday 02 August 2010 23:42:29 H. Peter Anvin wrote: > On 08/02/2010 02:35 PM, Ondrej Zary wrote: > > The patch below fixes it for me. Is it correct on all architectures? > > > > --- linux-2.6.35-rc2/drivers/video/matrox/matroxfb_base.h 2010-06-06 > > 05:43:24.000000000 +0200 +++ > > linux-2.6.35-rc3/drivers/video/matrox/matroxfb_base.h 2010-08-02 > > 23:31:34.000000000 +0200 @@ -157,7 +157,7 @@ static inline void > > mga_memcpy_toio(vaddr > > * (3) It copes with unaligned source (destination is guaranteed to be > > page * aligned and length is guaranteed to be multiple of 4). */ > > - memcpy_toio(va.vaddr, src, len); > > + iowrite32_rep(va.vaddr, src, len); > > #else > > u_int32_t __iomem* addr = va.vaddr; > > I don't think so; in particular I don't *think* non-x86 architectures > will deal with the requirement that it handles an unaligned source. As > such, the #if would still be necessary; the #else clause could be > replaced with a get_unaligned() ... iowrite32() loop. Just tested the #else part on sparc and it seems to work fine - so I'm not going to touch (break) it. > The other thing to watch out for is that "len" passed to iowrite32_rep() > is a count of 32-bit words, whereas memcpy_toio() takes a byte count... > you need to >> 2 there. Thanks. Here's v2 patch: Fix incorrect use of memcpy_toio() in matroxfb that broke in 2.6.34. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- linux-2.6.35-rc2/drivers/video/matrox/matroxfb_base.h 2010-06-06 05:43:24.000000000 +0200 +++ linux-2.6.35-rc3/drivers/video/matrox/matroxfb_base.h 2010-08-03 18:13:46.000000000 +0200 @@ -151,13 +151,13 @@ static inline void mga_writel(vaddr_t va static inline void mga_memcpy_toio(vaddr_t va, const void* src, int len) { #if defined(__alpha__) || defined(__i386__) || defined(__x86_64__) /* - * memcpy_toio works for us if: + * iowrite32_rep works for us if: * (1) Copies data as 32bit quantities, not byte after byte, * (2) Performs LE ordered stores, and * (3) It copes with unaligned source (destination is guaranteed to be page * aligned and length is guaranteed to be multiple of 4). */ - memcpy_toio(va.vaddr, src, len); + iowrite32_rep(va.vaddr, src, len >> 2); #else u_int32_t __iomem* addr = va.vaddr; -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |