Am Montag 11 August 2008 02:53:44 schrieb Stephane Marchesin:
> On 8/2/08, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> > I might be totaly wrong so feel free to ignore these. I got the feeling
> > that the user test base on linux kernel is far bigger than ours. Also
> > i think that our test user
On 8/2/08, Jerome Glisse <[EMAIL PROTECTED]> wrote:
>
> I might be totaly wrong so feel free to ignore these. I got the feeling
> that the user test base on linux kernel is far bigger than ours. Also
> i think that our test user base are people wanting lastest things with
> old kernel, while i u
On Thu, Aug 07, 2008 at 04:08:49PM -0700, Eric Anholt wrote:
> > > a) BSD
> >
> > I'd like to hear Robert's concerns here, but I've been working with some of
> > the BSD folks lately, and it seems like the main concerns are:
> > 1) making it easy for contributors to identify which portions of c
On Thu, 2008-07-31 at 19:53 -0700, Jesse Barnes wrote:
> 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
> >
> > Then this, the thing is to keep it building you need compat code, code
> > that can't go into Linus tree, so we end up with a tree that isn't like
> > Linus tree, and we still have to patch manage transitions so we don't save
> > anything doing this over what we have now.
>
> I was thinki
> > 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
>
On Fri, Aug 1, 2008 at 6:27 PM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>> >
>> > Personally, I only use the existing DRM repo on old kernels because that's
>> > how
>> > it's structured. It's actually more work for me to download & build a
>> > recent
>> > kernel, then update & build the DRM dri
On Fri, 1 Aug 2008 17:29:39 +0100
"Keith Whitwell" <[EMAIL PROTECTED]> wrote:
> > The biggest thing I have against this is that it cuts our testing base
> > down, we have a small testing base already, cutting it further jsut to
> > benefit some developers who are frustrated isn't really a gain.
>
On Fri, 2008-08-01 at 15:45 -0700, Jesse Barnes wrote:
> 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 pai
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
> >
> > Personally, I only use the existing DRM repo on old kernels because that's
> > how
> > it's structured. It's actually more work for me to download & build a
> > recent
> > kernel, then update & build the DRM drivers against it that it is to simply
> > update the DRM drivers and build aga
On Fri, Aug 1, 2008 at 2:40 AM, Dave Airlie <[EMAIL PROTECTED]> 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
>>
On Thu, Jul 31, 2008 at 10:53 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> 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
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
>
> 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'll make upstream merging even easier yet...
The less cra
On Wed, Jul 30, 2008 at 10:58 PM, Dave Airlie <[EMAIL PROTECTED]> wrote:
>> > What do you think?
>>
>> We try to keep #ifdef's out of the code and in drm_compat.h instead.
>> Something like
>>
>> #if linuxversion >= 2.6.27
>> #define drm_on_each_cpu(handler, data, wait) ...
>> #else
>> ...
> > What do you think?
>
> We try to keep #ifdef's out of the code and in drm_compat.h instead.
> Something like
>
> #if linuxversion >= 2.6.27
> #define drm_on_each_cpu(handler, data, wait) ...
> #else
> ...
> #endif
>
> and then just user drm_on_each_cpu in the code.
>
I'd prefer n
On Wed, Jul 30, 2008 at 8:19 AM, Johannes Engel <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> this rather trivial patch makes drm compile again on kernel >= 2.6.27. It is
> necessary since in kernel 2.6.27 on_each_cpu (defined in
> include/linux/smp.h) lost the third argument (retry).
> What do you th
17 00:00:00 2001
From: Johannes Engel <[EMAIL PROTECTED]>
Date: Wed, 30 Jul 2008 13:16:48 +0100
Subject: [PATCH 1/1] Adapt on_each_cpu
Since kernel 2.6.27 on_each_cpu lost its retry argument
Signed-off-by: Johannes Engel <[EMAIL PROTECTED]>
---
linux-core/drm_ttm.c |4
1 f
19 matches
Mail list logo
