From: Jesse Barnes
Date: Fri, 5 Mar 2010 10:02:44 -0800
> So from that perspective, the graphics stack is the most complex one in
> Linux by a long shot. It's even worse than if we had STREAMS
> networking with a ton of different modules up in userspace messing with
> protocol. :)
Maybe :-)
--
From: Xavier Bestel
Date: Fri, 05 Mar 2010 18:50:24 +0100
> On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote:
>> From: Daniel Stone
>> Date: Fri, 5 Mar 2010 17:41:43 +0200
>>
>> > I understand that you guys are upset about this, so maybe you'd li
From: Daniel Stone
Date: Fri, 5 Mar 2010 18:04:34 +0200
> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for
From: Alan Cox
Date: Fri, 5 Mar 2010 16:02:17 +
>> You can't unleash something like this on a userbase of this magnitude
>> and then throw your hands up in the air and say "I'm not willing to
>> support this in a reasonable way."
>
> Not to belabour the obvious - they didn't. Linus ordered t
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:41:43 +0200
> I understand that you guys are upset about this, so maybe you'd like to
> donate, say, 10% of your developer base to help out? That'd be pretty
> ace.
You have to support less than %10 of the amount of hardware we have to
support.
--
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:40:09 +0200
> On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote:
>> In fact, I argue that the moment nouveau went into Fedora and
>> was turned on by default, the interfaces needed to be frozen.
>
> That's a ma
From: Daniel Stone
Date: Fri, 5 Mar 2010 17:17:54 +0200
> On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote:
>> If it effects such a large number of people, which this noveau thing
>> does, it's entirely relevant to everyone. And the way it's breaking
>>
From: Alan Cox
Date: Fri, 5 Mar 2010 15:09:34 +
> I think you miss a bigger picture ?
>
> If Fedora hadn't merged it then it wouldn't have gotten to the state of
> usability it had. If Fedora hadn't merged it then several hundred
> thousand users wouldn't have had useful working machines.
I
From: Alan Cox
Date: Fri, 5 Mar 2010 12:38:34 +
>> The conclusion is crystal clear, breaking an ABI via a "flag day"
>> cleanup/feature/etc is:
>
> Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor
> junk that is in there being cleaned up it would be *insane* to keep
From: Alan Cox
Date: Fri, 11 Dec 2009 09:18:43 +
> However the fundamental point stands. The only people who can sign it off
> are the people who wrote it. Those are the rules. Red Hat didn't write the
> code, Red Hat cannot sign it off however much you rant at them. You also
> previously sai
> Cc: Al Viro
> Cc: Arnd Bergmann
> Reported-by: David Miller
> Signed-off-by: Heiko Carstens
Acked-by: David S. Miller
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 16:40:18 +0100
> I'm pretty sure it was ok when we started adding the compat_ioctl
> handlers years ago. I think most people just ignored these for
> the majority of drivers that can't possibly run on s390. Even
> on s390, gcc will always do the right th
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 13:13:32 +0100
> The ioctl argument actually needs a compat_ptr() conversion as well.
> For the s390 case, we can't do that in common code, because some
> ioctl methods put a 32 bit integer into the argument. Not sure if we
> want to fix that everywhere,
From: Arnd Bergmann
Date: Wed, 28 Oct 2009 13:13:32 +0100
> IMHO a better way to handle the radeon specific ioctls would be to
> avoid the compat_alloc_user_space and just define the common
> function taking a kernel pointer, with two implementations of the
> copy operation:
Agreed, that would b
From: Andi Kleen
Date: Wed, 28 Oct 2009 09:19:09 +0100
> On Wed, Oct 28, 2009 at 01:11:41AM -0700, David Miller wrote:
>> From: Andi Kleen
>> Date: Wed, 28 Oct 2009 08:59:08 +0100
>>
>> >> }
>> >> - chunk_array_ptr = (uint64_t *)(unsigned l
From: Andi Kleen
Date: Wed, 28 Oct 2009 08:59:08 +0100
>> }
>> -chunk_array_ptr = (uint64_t *)(unsigned long)(cs->chunks);
>> +#ifdef CONFIG_COMPAT
>> +if (is_compat_task())
>
> Are the COMPAT ifdefs really needed? The compiler should optimize that
> away anyways on non compat aware
From: David Miller
Date: Tue, 27 Oct 2009 23:04:50 -0700 (PDT)
> From: Dave Airlie
> Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
>
>> I'll add this to my TODO for before the next merge window as its
>> definitely more than I can manage now.
>
> I'll do it
From: Dave Airlie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
> I'll add this to my TODO for before the next merge window as its
> definitely more than I can manage now.
I'll do it.
--
Come build with us! The BlackBerry
From: Andi Kleen
Date: Wed, 28 Oct 2009 05:36:11 +0100
> On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
>> On sparc64, in order to make debugging easier, we trap any time
>> the kernel does a userspace access to a compat task and any
>> of the upper
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
>>
>> > we already opencoded this (probably before it was macroisied or we just
>> > pasted it), so the radeon one is buggy, I should just go and compat_* all
>> > of these then and we should be all happy?
>>
>> It should be, it's
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
> we already opencoded this (probably before it was macroisied or we just
> pasted it), so the radeon one is buggy, I should just go and compat_* all
> of these then and we should be all happy?
It should be, it's only working becaus
From: Andi Kleen
Date: Wed, 28 Oct 2009 04:34:55 +0100
> On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
>> Well this was what I was trying to gather, so maybe I just need to write
>> something up to state that compat_ioctl is always required for new ioctls
>> that pass pointers or 6
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:28:10 +1000
> On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen wrote:
>> On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
>>> We've designed that into a/c also, we pad all 64-bit values to 64-bit
>>> alignment on all the
>>> ioctls we've added t
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:05:08 +1000
> DrNick on irc suggested just doing:
> if (is_compat_task()) ptr &= 0x;
>
> Is there a one liner I can just do in the actual ioctls instead of
> adding 20 compat
> ones?
Just do the right thing and pass all userland compat
From: Andi Kleen
Date: Wed, 28 Oct 2009 03:53:17 +0100
> Dave Airlie writes:
>
>> Now I thought cool I don't need to worry about compat ioctl hackery I can
>> run 32 on 64 bit apps fine and it'll all just work.
>>
>> Now Dave Miller points out that I'm obivously deluded and we really need
>> to
From: Dave Airlie
Date: Wed, 28 Oct 2009 11:22:18 +1000
> Is there really no way to avoid compat ioctls? was I delusional in
> thinking there was?
If you use pointers in your interfaces in any way, no.
And for this drm_radeon_info thing the pointer is "pointless",
you're just returning 32-bit v
From: Andrew Morton
Date: Thu, 19 Feb 2009 15:27:26 -0800
> eg:
>
> arch/xtensa/include/asm/shmparam.h
> #define SHMLBA ((PAGE_SIZE > DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE)
>
>
> But including linux/shm.h here seems a bit silly. We'll see..
If DRM even builds on XTENSA, let alone i
From: Arnd Bergmann
Date: Thu, 19 Feb 2009 15:19:01 +0100
> On Wednesday 18 February 2009, David Miller wrote:
> > drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
> >
> > Only X86 32-bit uses a different alignment for "unsigned long long"
&
Ok, this is the last DRM bug I am aware of with Radeon on sparc64.
What kills me is that I fixed this bug 6 or 7 years ago :)
drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
Platforms such as sparc64 have D-cache aliasing issues. We
cannot allow virtual mappi
From: Benjamin Herrenschmidt
Date: Thu, 19 Feb 2009 08:59:50 +1100
> Could that be related to the kernel spewing a bunch of
>
> [drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace
Yep, that is exactly caused by this bug.
--
drm: radeon: Fix unaligned access in r300_scratch().
In compat mode, the cmdbuf->buf 64-bit address cookie can
potentially be only 32-bit aligned. Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.
Use get_unaligned() to fix.
Signed-off-by: David S. Miller
Ben, I'm pretty sure you're hitting this too on powerpc. Every time a
32-bit process tries to upload cliprects it's going to fail with
-EFAULT or similar.
Nothing in userspace checks the return value for errors, etc. :-/
The only reason I caught this is because I have a debugging check on
sparc
From: Sedat Dilek
Date: Sun, 15 Feb 2009 10:28:29 +0100
> unfortunately, your latest DRM patch [1] is broken while building
> against Linux-2.6.25-rc5.
>
> This is my patch-series:
Did you read my patch postings? I said my work was relative
to dri-next, as sparc64 also needs the changes David
From: Michel Dänzer
Date: Sat, 14 Feb 2009 10:59:59 +0100
> On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote:
> > This allocates a physical surface for the PCI GART table, this way no
> > matter what other surface configurations exist the GART table will
> > always be
From: David Miller
Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST)
> From: Benjamin Herrenschmidt
> Date: Sat, 14 Feb 2009 20:07:54 +1100
>
> > We can do that by registering a surface from the kernel to cover the
> > GART I suppose, and clean things a bit so that when using t
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.
We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV. On
From: Benjamin Herrenschmidt
Date: Sat, 14 Feb 2009 20:07:54 +1100
> > I did some research, and it does appear that the GART does read the
> > PTEs from the VRAM using the Host Data Path. This means the surface
> > control byte swapping settings are applied.
> >
> > So for depths of 16 and 24,
From: Dave Airlie
Date: Sat, 14 Feb 2009 17:42:02 +1000
> On Sat, Feb 14, 2009 at 4:09 PM, David Miller wrote:
> > 1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead
> > of the constant 4096 to determine how many GART entries there
> > are. The PCI
drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().
The variable 'max_pages' is ambiguous. There are two concepts
of "pages" being used in this function.
First, we have ATI GART pages which are always 4096 bytes.
Then, we have system pages which are of size PAGE_SIZE.
Eliminate the co
From: Benjamin Herrenschmidt
Date: Thu, 12 Feb 2009 21:35:59 +1100
> Oh BTW something else to be careful with, though I suppose it's working
> some what by accident right now... when the GART is in the frame buffer
> it gets applied the current fb swapper setting... ouch !
>
> So it might be a g
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:26:51 +1000
> On Thu, Feb 12, 2009 at 8:15 PM, David Miller wrote:
> >
> > David, this work is against your drm-next branch.
> >
> > Here are a collection of bug fixes for the Radeon DRM support. Most
> > of them
From: Dave Airlie
Date: Thu, 12 Feb 2009 21:23:13 +1000
> are you on a PCI or PCIE card, I've no idea what buses you have on sparc64.
>
> On the PCI cards the GART table will always be in main memory.
> PCIE always in VRAM.
PCI-E
From: Benjamin Herrenschmidt
Date: Thu, 12 Feb 2009 21:35:59 +1100
> Oh BTW something else to be careful with, though I suppose it's working
> some what by accident right now... when the GART is in the frame buffer
> it gets applied the current fb swapper setting... ouch !
>
> So it might be a g
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/radeon/radeon_cp.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/rad
The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.
However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.
Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd memory
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller
---
drivers/gpu/drm/ati_pcigar
David, this work is against your drm-next branch.
Here are a collection of bug fixes for the Radeon DRM support. Most
of them have to do with trying to access kernel virtual addresses
using DRM_READ32() and DRM_WRITE32().
With these patches at least the writeback test works on sparc64 and
the C
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some syste
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 15:15:48 +1000
> > Perhaps we'll have to create something ugly like vmalloc_nobounce().
> >
> > Remind me again why you're ending up with swiotlb'd pages?
> > vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus
> > RA
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 14:08:13 +1000
> > >
> > > So when swiotlb happens, as you can guess it all falls apart as the
> > > drm never calls sync functions at any stage...
> >
> > You would have hit this on any platform that does caching
> > in the PCI control
From: "Dave Airlie" <[EMAIL PROTECTED]>
Date: Mon, 2 Apr 2007 09:44:41 +1000
> Okay I've got a bug reported before and now again about > 4GB + radeon
> blows up the DRM... on Intel hw...
>
> What the drm currently does for the PCI GART table is it allocates a
> chunk of memory (8MB) with vmalloc_
52 matches
Mail list logo
