I got this error when I tried to build linux-solo-ia64:
gcc -c -I. -I../../../include -I../../../src/mesa -I../../../src/mesa/main
-I../../../src/mesa/glapi -I../../../src/mesa/math
-I../../../src/mesa/transform -I../../../src/mesa/swrast
-I../../../src/mesa/swrast_setup -I../../../src/mesa/dri
Ok, so I've got everything built and the sample server starts (after applying
the attached patch):
[EMAIL PROTECTED] miniglx]# ./sample_server
[miniglx] probed chipset 0x4e4b
got MMIOAddress 0x20001090 offset 268435456
[drm] added 65536 byte SAREA at 0xa00204fa
[drm] mapped SAREA
On Friday, March 04, 2005 6:01 pm, Roland Scheidegger wrote:
> Paul Mackerras wrote:
> > Note that that check is also wrong for ppc64. I think it is going to
> > be wrong for most 64-bit platforms, since it is assuming that you can
> > never have ram at a higher physical address than any I/O devic
Ok, so I've applied Stephane's fixes and sample_server comes up and
miniglxtest no longer segfaults. However, after setting the mode,
sample_server seems to die and wedge my display. miniglxtest just fails
right away with this message:
[EMAIL PROTECTED] miniglx]$ ./miniglxtest
[miniglx] probe
On Tuesday, March 8, 2005 12:01 am, Vladimir Dergachev wrote:
> Hi Jesse !
>
> On Mon, 7 Mar 2005, Jesse Barnes wrote:
> > Ok, so I've applied Stephane's fixes and sample_server comes up and
> > miniglxtest no longer segfaults. However, after setting the mode,
>
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid "mixing code & declarations" warnings and
adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for
pointing out the resource size mismatch. The patch just fixes that (PCI
resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and
adds the checking for write combining regions I posted earlier sinc
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
> for pointing out the resource size mismatch. The patch just fixes that
> (PCI resources in Linux are 'unsigned long' at the moment, not 'u
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
> for pointing out the resource size mismatch. The patch just fixes that
> (PCI resources in Linux are 'unsigned long' at the moment, not 'u
On Tuesday, March 8, 2005 10:43 am, Jesse Barnes wrote:
> This small patch fixes some warnings I saw when building on ia64. I think
> it's safe to apply. It just moves some of the RING_LOCALS macros to below
> the local stack variables to avoid "mixing code & declaratio
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
> On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> > Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
> > for pointing out the resource size mismatch. The patch just fixes that
> > (P
On Tuesday, March 8, 2005 12:24 pm, Jesse Barnes wrote:
> On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote:
> > On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
> > > Here are a few small fixes to get r300 going on ia64. Thanks to
> > > Stephane for poi
On Tuesday, March 08, 2005 4:24 pm, Paul Mackerras wrote:
> Jesse Barnes writes:
> > Anyone have a preference on this stuff? Should we remove the checks
> > altogether or just the ones against the highmem variable? If we did the
> > latter, we could remove the #ifdefs altog
On Tuesday, March 15, 2005 6:36 am, Dave Jones wrote:
> I saw one report where the recent drm security hole fix broke dri
> for one user. Whilst it seems an isolated incident, could this have
> more impact than we first realised ?
>
> Worse case scenario we can drop out the multi-bridge support fo
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote:
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I'd be happy to test and fix things, but the page table walker patches
> > broke ia64... Once that's cleared up I can go digging.
>
> We're hoping th
On Thursday, March 24, 2005 2:33 am, Dave Airlie wrote:
> Hi Andrew, Dave,
>
> I've put a couple of patches into my drm-2.6 tree that hopefully fix up
> the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop
> the two patches in your tree.. the one from Brice and the one I attache
On Thursday, March 24, 2005 10:18 am, Dave Jones wrote:
> > I'm trying to get ahold of one--so hopefully I'll be able to test and
> > fix this stuff up when I do.
>
> Aparently backing out the changes to via's tlb_flush routine fixed it
> for one VIA user. I've not had a chance to look into it ju
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
> My solution to this is to make radeon DRM depend on radeonfb.
> radeonfb properly attaches to the device and marks everything in use.
> I chose this method because Xegl wants radeonfb loaded and this
> scheme has minimal code impact.
Seems reaso
On Friday, June 10, 2005 8:39 am, Jon Smirl wrote:
> On 6/10/05, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Friday, June 10, 2005 8:09 am, Jon Smirl wrote:
> > > My solution to this is to make radeon DRM depend on radeonfb.
> > > radeonfb properly attaches to t
On Friday, June 10, 2005 8:52 am, Jon Smirl wrote:
> On 6/10/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > My solution to this is to make radeon DRM depend on radeonfb.
> > > radeonfb properly attaches to the device and marks everything in
> > > use. I chose this method because Xegl wants radeo
On Friday, June 10, 2005 9:07 am, Jon Smirl wrote:
> The Xegl model lets you pick where you get your drivers from. It just
> runs on top of a driver stack providing the OpenGL/ES+EGL API. The
> embedded systems I am aware of are ignoring mesa, drm, fbdev and and
> building their own optimized OpenG
On Friday, June 10, 2005 10:46 am, Jon Smirl wrote:
> We don't have enough people to finish one set of drivers and cetainly
> not enough to finish two. What we are going to end up with is two
> half finished systems. People working on KAA are capable of making
> valuable contributions to DRI/DRM if
On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote:
> Anyway, I really want a slightly different approach than what Jon is
> doing, that is a 3 modules scenario:
>
> - A basic "stub" module that attaches to the PCI card. It doesn't
> touch the hardware per-se (thus won't break your VGA
On Thursday, November 24, 2005 4:50 am, Thomas Hellström wrote:
> There is some info in the old precision insight documentation about
> the DRI infrastructure, (can't seem to find a link right now) But
> generally there is only one global lock and something called the
> drawable spinlock that is ap
I just add a device specific DRM_IOCTL to
accomplish this (using get_user_pages() etc.) or is there some existing
code I could leverage?
Thanks,
Jesse
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/drivers/char/drm/Makefile b/drivers/char/drm/Makefile
index 9d180c4..a212
On Monday, March 6, 2006 12:28 pm, Thomas Hellström wrote:
> The via driver has code that does this (via_dmablit.c) as a
> device-specific IOCTL.
>
> It maintains a queue of blit operations and fire them off when the
> previous one is completed. The user calls a sync IOCTL to verify that
> the oper
Until last night, it had been over a month since a vblank problem was
reported, so I figure now is a good time to try to break things again.
The vblank-rework tree has been soaking for quite awhile now, and I don't
think it'll get anymore exposure as a branch of the main drm tree. Since it
act
On Tuesday, January 22, 2008 9:55 am Jesse Barnes wrote:
> Until last night, it had been over a month since a vblank problem was
> reported, so I figure now is a good time to try to break things again.
>
> The vblank-rework tree has been soaking for quite awhile now, and I don't
On Wednesday, January 23, 2008 4:29 am Michel Dänzer wrote:
> On Tue, 2008-01-22 at 15:17 -0800, Jesse Barnes wrote:
> > @@ -378,6 +380,15 @@ u32 i915_get_vblank_counter(struct drm_device *dev,
> > int plane)
> >
> > count = (high1 << 8) | low;
> >
>
On Wednesday, January 23, 2008 8:28 am Jesse Barnes wrote:
> On Wednesday, January 23, 2008 4:29 am Michel Dänzer wrote:
> > On Tue, 2008-01-22 at 15:17 -0800, Jesse Barnes wrote:
> > > @@ -378,6 +380,15 @@ u32 i915_get_vblank_counter(struct drm_device
> > > *dev, int
On Wednesday, February 06, 2008 9:37 pm Dave Airlie wrote:
> Hi Linus,
>
> Please pull the 'drm-patches' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
> drm-patches
>
> Sorry this is so late, after much talking at LCA we decided to pull TTM
> from this round and
On Wednesday, February 13, 2008 1:28 am Dave Airlie wrote:
> So I've been thinking about this stuff a lot lately wrt to getting the
> DRM into a state that enables fast-user-switching, GPGPU apps,
> different users on a per head one a single card..
>
> http://dri.freedesktop.org/wiki/DRMRedesign
>
On Wednesday, February 13, 2008 2:22 pm Stephane Marchesin wrote:
> On 2/13/08, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > So I've been thinking about this stuff a lot lately wrt to getting the
> > DRM into a state that enables fast-user-switching, GPGPU apps,
> > different users on a per head one
On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote:
> > You don't want any application to be able to change CRTC<->output
> > mappings, or bind BOs to CRTCs. Ideally you'd just have one app that
> > could do that on a given system, and it would contain the distribution's
> > policy r
On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote:
> Dave there is one things that is needed to be redone: frame buffer
> creation & handling. And i would like we not freeze the API until
> we had some time to play with it a bit. So i guess my question is
> does this means modesetting API
On Thursday, February 28, 2008 11:33 am Dave Airlie wrote:
> the current API abstracts connectors from outputs, so in reality it
> is encoders with connector properties at the moment.
>
> you define a connector type and a connector id for each output and
> can gang them together..
>
> so wrt to the
On Sunday, March 02, 2008 10:17 pm Nan hai Zou wrote:
> shared-core/i915_irq.c |7 +++
> 1 file changed, 7 insertions(+)
>
> New commits:
> commit 63fd6f284ddd1096d34b39941683ae244c1e01fc
> Author: Zou Nan hai <[EMAIL PROTECTED]>
> Date: Mon Mar 3 14:49:49 2008 +0800
>
> [i915] 2D
On Monday, March 03, 2008 10:34 am Thomas Hellström wrote:
> 1) Allocating all pages at once:
> Yes, I think this might improve performance in some cases. The reason
> it hasn't been done already is the added complexity needed to keep track
> of the different allocation sizes. One optimization th
On Friday, March 07, 2008 1:21 am Tom Cooksey wrote:
> I'm a developer working on getting OpenGL ES working with QWS - the window
> system built into Qt/Embedded. That is, Trolltech's own windowing system,
> completely independent of X. The typical hardware we're working with is
> PowerVR MBX, an O
I found myself pointing people at krh's blog post on building the stack a lot
recently, so I figured it should be made into an x.org wiki page. We already
had a git development guide started, so I updated it based on krh's guide and
a couple of the replies in his blog.
Please give it a try and
On Monday, March 10, 2008 2:02 am Thomas Fritzsche wrote:
> Hi Jesse,
>
> thanks for the x.org wiki-page.
> The other day I also tried to follow-up on the krh's blog, but as you
> mentioned, all this proto & libs really send me in a dependency hell.
> I like to build git x-server (intel), but with
On Tuesday, March 18, 2008 9:54 am Tom Cooksey wrote:
> I've had some time to play with the modesetting branch. I am using a laptop
> with an Intel 965GM, is this likely to work? At the moment, when I run
> tests/modedemo I get a hard lock. :-/
Yeah, that should be a good platform...
> I have a f
On Tuesday, March 04, 2008 3:38 am Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Fri, 2008-02-29 at 16:03 +0100, Thomas Hellström wrote:
> >> Hi.
> >>
> >> I've pushed the intel-post-reloc branch with the following stuff:
> >>
> >> 1) Full backwards compatibility.
> >> 2) A new reloc type 1,
On Wednesday, March 19, 2008 3:14 pm Thomas Hellström wrote:
> > IIRC Eric had the relocation costs down in the "negligible" range, but
> > with the latest Mesa & DRM bits, applying relocations seems to be a big
> > part of openarena profiles at least:
> >
> > samples %app name
On Friday, April 04, 2008 11:14 am Thomas Hellström wrote:
> Dave Airlie wrote:
> > I'm just wondering if rather than specify all the CACHED and MAPPABLE and
> > SHAREABLE flags we make the BO interface in terms of CPU and GPU
> > operations..
> >
> > So we define
> > CPU_READ - cpu needs to read
I just pushed a few changes updating the DRM modesetting sysfs support, both
for debugging and eventual HAL friendliness.
So far, the support is limited to describing outputs and generating hotplug
events. A typical "card0" directory now looks like this:
.
|-- card0-DAC-1
| |-- device -> ../
[Sorry for the DUP, forgot to cc lkml]
I just pushed a few changes updating the DRM modesetting sysfs support, both
for debugging and eventual HAL friendliness.
So far, the support is limited to describing outputs and generating hotplug
events. A typical "card0" directory now looks like this:
On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote:
> I was going to suggest that you plug it into the hotplug_stage_two
> function but it looks like you have already done that. Things might be
> routed differently now then since the last time I looked at the code,
> are you sure that sta
On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote:
> On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote:
> > On Wednesday, April 09, 2008 1:57 am Jakob Bornecrantz wrote:
> > > I was going to suggest that you plug it into the hotplug_stage_two
> > > function
On Wednesday, April 09, 2008 10:23 am Alan Hourihane wrote:
> On Wed, 2008-04-09 at 09:34 -0700, Jesse Barnes wrote:
> > On Wednesday, April 09, 2008 9:15 am Alan Hourihane wrote:
> > > On Wed, 2008-04-09 at 08:17 -0700, Jesse Barnes wrote:
> > > > On Wednesday
On Wednesday, April 09, 2008 10:39 am Jesse Barnes wrote:
> > With VGA (i.e. ADPA) output ?
> >
> > If so, that's the problem. From what I can tell of i915 docs, they only
> > support hotplug for SDVO devices only, so that's how it's coded up at
> >
On Sunday, April 27, 2008 3:25 am Michel Dänzer wrote:
> On Sat, 2008-04-26 at 17:14 -0700, Jesse Barnes wrote:
> > New commits:
> > commit b45fe49bcd989be4e1327c13dd734410b395761c
> > Author: Jesse Barnes <[EMAIL PROTECTED](none)>
> > Date: Sat Apr 26 17:11:18 2
On Monday, May 05, 2008 11:22 am Miles Lane wrote:
> On Mon, May 5, 2008 at 4:15 AM, Michel Dänzer
>
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 2008-05-04 at 21:12 -0400, Miles Lane wrote:
> > > When I boot this kernel, everything seems okay, but after I leave the
> > > machine for 30 minutes or so
The attached patches, which depend on kernel mode setting, will allow us to
see some kernel messages even if a panic occurs while X is running.
I think the approach is fairly sound (using a notifier to let mode setting
drivers switch the front buffer), but there are some details to be worked out
On Friday, May 16, 2008 2:26 pm Stephen Hemminger wrote:
> After the screensaver does it's idle shut off of the monitor, it never
> comes back. This is a new problem and only shows up post 2.6.25.
>
> Console log messages:
> Note: this message should be WARN_ON_ONCE() since it fills the disk!
>
> M
On Thursday, May 29, 2008 11:26 pm Dave Airlie wrote:
> On Thu, May 29, 2008 at 9:02 PM, David Woodhouse <[EMAIL PROTECTED]>
wrote:
> > On Thu, 2008-05-29 at 10:46 +1000, Dave Airlie wrote:
> >> Hi,
> >>
> >> So I've been growing more annoyed with the current layout of the drm
> >> tree in the ker
On Tuesday, June 03, 2008 2:54 am Michel Dänzer wrote:
> Nan hai (I hope I got that right), Jesse,
>
>
> I think your drm commits 63fd6f284ddd1096d34b39941683ae244c1e01fc
> ("[i915] 2D driver may reset Frame count value, this may lead driver")
> and c7ee6cc269c26d8e7ed98a16a272eca63daab201 ("Remove
On Friday, June 20, 2008 2:27 pm Jesse Barnes wrote:
> On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
> > Michel, can you take a look at this? vblank wait is working really well
> > for me with the latest bits, but I found what I think is a page flip
> > related b
On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
> Michel, can you take a look at this? vblank wait is working really well
> for me with the latest bits, but I found what I think is a page flip
> related bug on 965. I've been testing with the attached pre- &
> post-modes
Michel, can you take a look at this? vblank wait is working really well for
me with the latest bits, but I found what I think is a page flip related bug
on 965. I've been testing with the attached pre- & post-modeset ioctl patch
to the 2D driver. Changing modes, adding & removing outputs and
On Sunday, June 22, 2008 6:55 am Pekka Paalanen wrote:
> On Thu, 19 Jun 2008 15:13:51 -0700
>
> Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > In a shameless attempt to capitalize on the recent enthusiasm for
> > documenting things, I've put together a skeletal
On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
> On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
> > On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
> > > Michel, can you take a look at this? vblank wait is working really
> > > well for me with t
On Monday, June 23, 2008 11:02 am Jesse Barnes wrote:
> On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
> > On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
> > > On Friday, June 20, 2008 2:09 pm Jesse Barnes wrote:
> > > > Michel, can you take a look at
On Wednesday, June 25, 2008 10:28 am Steven J Newbury wrote:
> On Wed, 2008-06-25 at 16:29 +0100, Johannes Engel wrote:
> > Steven J Newbury wrote:
> > > When building with a separate objdir -I$(top_srcdir)/libdrm needs to be
> > > added to the intel Makefile.am otherwise only $(top_builddir)/libdr
On Monday, June 23, 2008 11:50 pm Michel Dänzer wrote:
> On Mon, 2008-06-23 at 11:02 -0700, Jesse Barnes wrote:
> > On Monday, June 23, 2008 12:51 am Michel Dänzer wrote:
> > > On Fri, 2008-06-20 at 14:27 -0700, Jesse Barnes wrote:
> > > > On Friday, June 20, 2
On Sunday, July 06, 2008 12:29 am vehemens wrote:
> Would anyone object to using a struct for the vblank crtc data to eliminate
> the multiple allocs / frees?
>
> For example:
>
> struct drm_vblank {
> wait_queue_head_t vbl_queue;
> atomic_t _vblank_count;
> struct drm_vbl_s
On Thursday, July 10, 2008 3:59 pm Tiago Vignatti wrote:
> Simon Thum escreveu:
> > But all this in the kernel is an impedance mismatch to me. What could it
> > buy us we don't have today?
>
> Improve heavy-load behavior -- no jumping pointer.
>
> (BTW, your mouse acceleration proposal [0] doesn't
On Thursday, July 10, 2008 9:14:20 pm Dave Airlie wrote:
> > Right, and it's actually fairly common in other OSes. It sounds like the
> > biggest chunk of additional code will be dealing with acceleration; I'm
> > not sure how complex the latest algorithms are... Also input
> > transformation is
Here's a patch that implements what we've been talking about:
- uses the atomic counter while interrupts are on, which means the
get_vblank_counter callback is only used when going from off->on to
account for missed events
- won't disable interrupts until the modeset ioctl is called, to
On Wednesday, July 16, 2008 11:51 pm Michel Dänzer wrote:
> On Wed, 2008-07-16 at 16:01 -0700, Jesse Barnes wrote:
> > Here's a patch that implements what we've been talking about:
> > - uses the atomic counter while interrupts are on, which means the
> > get_
On Friday, July 18, 2008 1:12 am Michel Dänzer wrote:
> On Thu, 2008-07-17 at 09:32 -0700, Jesse Barnes wrote:
> > On Wednesday, July 16, 2008 11:51 pm Michel Dänzer wrote:
> > > On Wed, 2008-07-16 at 16:01 -0700, Jesse Barnes wrote:
> > > > @@ -408,8 +426,1
On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
> On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
> > On Friday, July 18, 2008 1:12 am Michel Dänzer wrote:
> > > On Thu, 2008-07-17 at 09:32 -0700, Jesse Barnes wrote:
> > > > On Wednesday, July 16, 200
On Friday, July 18, 2008 10:15 am Jesse Barnes wrote:
> On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
> > On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
> > > On Friday, July 18, 2008 1:12 am Michel Dänzer wrote:
> > > > On Thu, 2008-07-17 at 0
On Friday, July 18, 2008 10:24 am Jesse Barnes wrote:
> On Friday, July 18, 2008 10:15 am Jesse Barnes wrote:
> > On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
> > > On Fri, 2008-07-18 at 09:41 -0700, Jesse Barnes wrote:
> > > > On Friday, July 18, 20
On Friday, July 18, 2008 10:36 am Jesse Barnes wrote:
> On Friday, July 18, 2008 10:24 am Jesse Barnes wrote:
> > On Friday, July 18, 2008 10:15 am Jesse Barnes wrote:
> > > On Friday, July 18, 2008 10:09 am Michel Dänzer wrote:
> > > > On Fri, 2008-07-18 at 0
On Saturday, July 19, 2008 5:01 am Michel Dänzer wrote:
> On Fri, 2008-07-18 at 14:41 -0700, Jesse Barnes wrote:
> > I failed to get the old update_vblank approach working, messing with the
> > counter is different under the new interrupt counter scheme.
>
> Okay, I don&#x
On Sunday, July 20, 2008 3:10 am Maarten Maathuis wrote:
> Has it been considered to put this up somewhere for autogeneration?
>
> I'm not very familiar with these documentation schemes, but i imagine
> it's a matter of putting appropriately styled comments in code and
> they'll appear?
>
> It woul
On Sunday, July 20, 2008 3:46 am Michel Dänzer wrote:
> On Sat, 2008-07-19 at 12:54 -0400, Robert Noland wrote:
> > One other issue that I spotted while testing is that we initialize
> > vblank_disable_allowed to 0. The only place that it ever becomes true
> > is in post modeset. So, for me... vb
On Friday, July 25, 2008 1:09 pm Robert Noland wrote:
> The changes that we discussed on irc are turning out to be slightly more
> difficult than I expected... In the meantime, I'd like to push this to
> master to get things more or less working again.
>
> One thing I discovered was that, at least
On Thursday, July 31, 2008 3:25 pm Jesse Barnes wrote:
> Given the way master is now, would this be a simpler fix?
>
> It basically just makes drivers responsible for doing vblank init &
> cleanup. They can move it to load/unload or irq install/uninstall whenever
> they want.
O
On Thursday, July 31, 2008 6:40 pm Dave Airlie wrote:
> > Well, if the overhead of merging upstream is a concern, then how about
> > not worrying about bc at all and let people who want to back port deal
> > with it? Oh, and what about just keeping the drm drivers in a linux
> > kernel tree? That
On Friday, August 1, 2008 3:27:33 pm Dave Airlie wrote:
> > So, I very much agree with your proposal and don't feel I can add
> > much, except to point out that a migration to in-tree drm development
> > doesn't need to be a big and painful process. Basically, we just
> > decide to do it, and desi
> > As we discussed on IRC last night, I think these changes are perfectly
> > reasonable (in fact just what I'd expect if we moved to this model).
> > Sure, it will force contributors to be more disciplined, but that's
> > probably a good thing anyway. I'd still like to hear from the BSD guys
>
VMA and address space taken care of by the
parent do_mmap_pgoff function. I think that would mean messing with shmem.c
though, since it won't pass down an mmap call for us...
On the plus side, these patches seem to work and bring performance on
modesetting-gem back to reasonable levels
On Thursday, August 21, 2008 2:27 pm Jesse Barnes wrote:
> Here's what I've been hacking on wrt GTT mapping. The kernel's mmap_region
> function was almost exactly what we needed, but it doesn't give us a way to
> avoid the backing store for the attached file, thus
makes it easier
to share this file with BSD.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b032808..c4bbda6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -3,7 +3,8 @@
#
Author: Zhenyu Wang <[EMAIL PROTECTED]>
i915: official name for GM45 chipset
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
Acked-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a82b487..71326ca 100644
te it.
Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]>
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 61ed515..d6d6be4 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -132,7 +132,6 @@ static int drm_irq_install(struct drm_device * dev)
hanged, 355 insertions(+), 457 deletions(-)
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 16829fb..3daefef 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -125,7 +125,7 @@ int dr
On Tuesday, August 26, 2008 12:03 pm Stephane Marchesin wrote:
> On Tue, Aug 26, 2008 at 8:57 PM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > The DRM design includes ioctls to allow a userland driver to tell the
> > kernel driver when to register its interrupt handler and o
On Tuesday, August 26, 2008 12:23 pm Thomas Hellström wrote:
> Jesse Barnes wrote:
> > The DRM design includes ioctls to allow a userland driver to tell the
> > kernel driver when to register its interrupt handler and on what IRQ.
> > This is a really bad idea for several rea
instream linux routinely because you don't really care.
I think this is an overreaction to an RFC. If I had pushed this into DRM
master, leaving several drivers broken I think there would be real cause for
complaint. However, I haven'
On Tuesday, August 26, 2008 1:28 pm Stephane Marchesin wrote:
> On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
> >> > As for the "new development model"... Things are
On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
> On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
> >> > As for the "new development model"... Things are
the core code. I think we could manage this
in i915 fairly easily at least, but even then I don't think we'd want to do
it until the vblank-rework stuff is upstream (which I'm working on now).
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
---
I tried to go down that
> path, so I just settled to only move the vblank bits...
I'll post the upstream vblank-rework code as soon as I have it working well;
fixing this particular problem should be fairly easy w/o having to rip out
all the IRQ stuff (though I was kinda hoping that would
ore they happen. It would be nice to tinderbox
> build the drm mainline and drm-testing against the last 6 released
> kernels.
On Linux at least, some subsystems do this with their linux-next branch. They
pull in all the various topic branches that may or may not get into the next
Linus re
On Tuesday, August 26, 2008 9:03 pm Robert Noland wrote:
> On Tue, 2008-08-26 at 18:02 -0700, Jesse Barnes wrote:
> > On Tuesday, August 26, 2008 5:13 pm Robert Noland wrote:
> > > I kinda prompted this topic to come back to life... I'm less concerned
> > > with
On Saturday, August 30, 2008 1:20 am Maksym Veremeyenko wrote:
> Jesse Barnes написав(ла):
> > On Wednesday, August 27, 2008 1:20 pm Jesse Barnes wrote:
> >> Here's a tested (on i915) patch for vblank-rework against drm-next with
> >> my
>
> Could you give a
On Saturday, August 30, 2008 1:02 am Maksym Veremeyenko wrote:
> Michel Dänzer написав(ла):
> [...]
>
> >> Is it normal that no interrupts happens from board?
> >> or i need more initializing ioctl call to /dev/dri/0 to allow interrupts
> >> from hardware?
> >
> > This is probably due to the DRM_I8
201 - 300 of 741 matches
Mail list logo
