[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Mario Kleiner]

On Dec 22, 2010, at 6:23 PM, Jesse Barnes wrote:

> On Wed, 22 Dec 2010 05:36:13 +0100
> Mario Kleiner  wrote:
>
>>>  
>>> --
>>>
>>> Message: 1
>>> Date: Mon, 20 Dec 2010 19:23:40 -0800
>>> From: Keith Packard 
>>> Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
>>> To: Andy Lutomirski , Jesse Barnes
>>> ,  Chris Wilson >> wilson.co.uk>,
>>> David Airlie 
>>> Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
>>> Message-ID: 
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski 
>>> wrote:
>>>
 Enabling and disabling the vblank interrupt (on devices that
 support it) is cheap.  So disable it quickly after each
 interrupt.
>>>
>>> So, the concern (and reason for the original design) was that you
>>> might
>>> lose count of vblank interrupts as vblanks are counted differently
>>> while
>>> off than while on. If vblank interrupts get enabled near the  
>>> interrupt
>>> time, is it possible that you'll end up off by one somehow?
>>>
>>> Leaving them enabled for 'a while' was supposed to reduce the
>>> impact of
>>> this potential error.
>>>
>>> -- 
>>> keith.packard at intel.com
>>> -- next part --
>>> A non-text attachment was scrubbed...
>>> Name: not available
>>> Type: application/pgp-signature
>>> Size: 189 bytes
>>> Desc: not available
>>> URL: >> 20101220/105a9fb6/attachment-0001.pgp>
>>>
>>> --
>>>
>>> Message: 2
>>> Date: Mon, 20 Dec 2010 22:34:12 -0500
>>> From: Andrew Lutomirski 
>>> Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
>>> To: Keith Packard 
>>> Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard 
>>> wrote:
 On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski 
 wrote:

> Enabling and disabling the vblank interrupt (on devices that
> support it) is cheap. ?So disable it quickly after each
> interrupt.

 So, the concern (and reason for the original design) was that you
 might
 lose count of vblank interrupts as vblanks are counted differently
 while
 off than while on. If vblank interrupts get enabled near the
 interrupt
 time, is it possible that you'll end up off by one somehow?
>>>
>>> So the race is:
>>>
>>> 1. Vblank happens.
>>> 2. vblank_get runs, reads hardware counter, and enables the  
>>> interrupt
>>> (and maybe not quite in that order)
>>> 3. Interrupt fires and increments the counter.  Now the counter is
>>> one too high.
>>>
>>> What if we read the hardware counter from the IRQ the first time  
>>> that
>>> it fires after being enabled?  That way, if the hardware and  
>>> software
>>> counters match (mod 2^23 or whatever the magic number is), we don't
>>> increment the counter.
>>>

 Leaving them enabled for 'a while' was supposed to reduce the
 impact of
 this potential error.

>>>
>>> Fair enough,
>>>
>>> But five seconds is a *long* time, and anything short enough that  
>>> the
>>> interrupt actually gets turned off in normal use risks the same  
>>> race.
>>>
>>> --Andy
>>>
>>>
>>> --
>>>
>>> Message: 3
>>> Date: Mon, 20 Dec 2010 19:47:11 -0800
>>> From: Keith Packard 
>>> Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
>>> To: Andrew Lutomirski 
>>> Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
>>> Message-ID: 
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski
>>>  wrote:
>>>
 But five seconds is a *long* time, and anything short enough  
 that the
 interrupt actually gets turned off in normal use risks the same  
 race.
>>>
>>> Right, so eliminating any race seems like the basic requirement. Can
>>> that be done?
>>>
>>> -- 
>>> keith.packard at intel.com
>>> -- next part --
>>> A non-text attachment was scrubbed...
>>> Name: not available
>>> Type: application/pgp-signature
>>> Size: 189 bytes
>>> Desc: not available
>>> URL: >> 20101220/5ca3b674/attachment-0001.pgp>
>>>
>>> --
>>>
>>> Message: 4
>>> Date: Mon, 20 Dec 2010 22:55:46 -0500
>>> From: Andrew Lutomirski 
>>> Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
>>> To: Keith Packard 
>>> Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
>>> Message-ID:
>>> 
>>> Content-Type: text/plain; charset=ISO-8859-1
>>>
>>> On Mon, Dec 20, 

Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 21:22, Nicolas Pitre  wrote:
> Having accommodations in the kernel for proprietary drivers is not a
> mutual benefit anymore. ?That might be hard to understand from your
> point of view, but the incentives in the Open Source communities aren't
> based on commercial results.

DISCLAIMER: I'm also a Debian developer -have been since 1999 with a
small 2y break- so I _do_ know the F/OSS community point of view. My
goals have been always in promoting open source and free software
solutions when and when not available. Right now open source solutions
are _not_ available, and that is the problem.

I haven't reversed engineered any driver so I can't claim of knowledge in this
matter. However I've been following closely other such projects like nouveau
and it took them a _long_ time to get to this point here -which may be usable
for many people, but it's not even at a beta state according to the Nouveau
developers. Even if we assume the fact that 10 times more ARM F/OSS
developers gather to reverse engineer the binary blobs, how long do you think
it would take until a beta driver appears? 1 year? 2 years? And what will happen
in the meantime?

I'm not advocating that closed source drivers be included in the
kernel, but IMHO,
having an open kernel-space driver would also help the reverse engineering
process at the same time as allowing common users as well as developers to
use and test any 3D applications -don't forget that 3D problems don't
end at the driver,
rather the opposite.

Konstantinos

Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> it would take until a beta driver appears? 1 year? 2 years? And what will 
> happen
> in the meantime?

plainly.some other company will take over the market, and sell products 
with open drivers available.
in meantime arm devices can still be used for i.e. dataloggers, especially
without linux support their market price drops significantly.

i really see no big deal here. it happened before with nvidia -
don't you recall how much their hardware lost in it's value ?
upgraded cards were given-away as buggy and unsupported in linux,
and had very short-life in 2nd hand market.
compare it to i.e. SGI machines which are still circulating and are 
valued, even though their opensource support is actually not so brilliant, 
and hardware performance even worse...

nowadays companies like ARM are again fishing in the same market - people 
who once invested big bucks in nvidia, are now thinking twice.
and it's not really related with opensource - notice how many unsatisfied 
customers turned away from _proprietary_ solutions , tired with messy 
service packs, remote exploits, long-uncorrected bugs, and dropping of 
support for whole OS solutions, leaving users with expensive support 
options and unstable systems behind.

i think if new ARM/freescale products will not have decent opensource 
support now, they will not only loose opensource market, but will not get 
the profit from proprietary market basing on previous 'success' of 
similiar solutions due fact users simply learnt their lesson.


-- 

Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
>  wrote:
>>> So to say that the corporate world might need to consider Open Source to
>>> be competitive and survive, but the reverse is not true i.e. Open Source
>>> doesn't _require_ the corporate world to survive.
>>
>> i agree with it fully, and to support this claim i want to remind the
>> simple rule of capital accumulation. Open Source community
>> _already_ accumulated enough _capital_ in form of algorithms,
>> implementations, social relations, experience, documentation and
>> augmentation with education system .
>
> I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
> thrive and make a difference in the world without the corporate world?
> Definitely not. If you only care about the former that's fine, but
> have no illusion that we would even be having this discussion here
> were it not for the corporate world caring about Linux on ARM.

survive, and serve. despite corporate entities, opensource projects
do not just cease to exist once markets cut the profit down.
this is where corporations loose big time in comparison to opensource.

thrive? come on, discussion starts about small, insignificant toys, and
i repeat - insignificant toys. talking big about '3d in linux'
as any priority sounds funny in world in which 99% of the tcp/ip routing 
is performed by opensource-based solutions, at both enterprise , and
'home' scale. while opensource display system has enough proprietary 
alternatives to choose from at low cost, point of developing it lies
far beyond just cutting few pennies for ... toys. this can be done
without opensource at all.

talking about opensource unable to survive without care of corporate world 
is also funny. current opensource politics allowed such growth thanx to
proper politics when it came to dealing with corporate world. without
opensource certain solutions would never propagate and become 
cost-effective to gain enough markets. so profit opensource gained from it
is fair-earned, and comes from market itself, not from corporate world
attitude. in other words - if certain corporations would not partake 
certain attitude, it would be done by other ones, or certain products 
would just never existed.

still _opensource_ would be same good as before, 
as notice development of certain algorithms and code was conducted in 
parallel, and also sponsored by university environments for solely 
research and educational purposes (to exclude any opensource-ideology 
driven motives) .

my 2 eurocents ;)
-- 

Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 20:39, Piotr Gluszenia Slawinski
 wrote:
>> So to say that the corporate world might need to consider Open Source to
>> be competitive and survive, but the reverse is not true i.e. Open Source
>> doesn't _require_ the corporate world to survive.
>
> i agree with it fully, and to support this claim i want to remind the
> simple rule of capital accumulation. Open Source community
> _already_ accumulated enough _capital_ in form of algorithms,
> implementations, social relations, experience, documentation and
> augmentation with education system .

I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
thrive and make a difference in the world without the corporate world?
Definitely not. If you only care about the former that's fine, but
have no illusion that we would even be having this discussion here
were it not for the corporate world caring about Linux on ARM.

Konstantinos

[git pull] drm fixes

[Linus Torvalds]

On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson  
wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
>> The commit 448f53a1ede54eb854d036abf54573281412d650
>> ? drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>>
>> causes a regression on a SandyBridge machine here.
>> The laptop display (LVDS) becomes blank. ?Reverting the commit fixes
>> the problem.
>
> The question is whose BIOS is wrong?

I don't think so.

> The Lenovo U160's or the
> Sandybridge SDV? And why does it work for that other OS?  rhetorical question of the day here.>

Quite frankly, I don't think the question should *ever* be "whose BIOS
is wrong?"

You should always take for granted that the BIOS is wrong. It's not a
question of "blame the BIOS", it's a question of facts of life.

It's 100% pointless to point fingers and say "the HP BIOS is wrong" or
"the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that
relies on the BIOS to such a degree that it either works or not based
on it is by definition broken.

Why does that code need to figure out some LVDS clock from the BIOS?
Why can't the code look at the actual hardware state or similar, since
presumably the screen is on after boot. THAT we can rely on, since a
BIOS that doesn't initialize LVDS is not going to ever ship even as
pre-release.

Linus

Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> So to say that the corporate world might need to consider Open Source to
> be competitive and survive, but the reverse is not true i.e. Open Source
> doesn't _require_ the corporate world to survive.

i agree with it fully, and to support this claim i want to remind the
simple rule of capital accumulation. Open Source community
_already_ accumulated enough _capital_ in form of algorithms, 
implementations, social relations, experience, documentation and
augmentation with education system .

it can survive just fine without corporate world, while
logical relationship with organisations whole main purpose of existence
is creating profit, is to gain profit from such relationship itself.
otherwise it would be bit like Faust would just give his soul away 
completely free... and everyone knows it's not the point while dealing 
with devil.

i also understand reluctance of some people about such deals -
despite huge gains , one can loose very important things,
and end up escaping from small print obligations.
sometimes it is better to make slower, but steady progress instead.

greetings.
-- 

Freescale Linux BSP review

[Nicolas Pitre]

On Thu, 23 Dec 2010, Xavier Bestel wrote:

> Le mercredi 22 d?cembre 2010 ? 15:29 -0500, Nicolas Pitre a ?crit :
> > It is 
> > not economically viable for the Open Source community to accommodate 
> > proprietary drivers, irrespective of how loud you might advocate for 
> > that.
> 
> I think you can remove the word "economically" from your sentence (or
> replace it with e.g. "technically"), and it's all the more true.

I used that word on purpose. Economic principles do exist in the Open 
Source world too.  It is just not based on monetary profits.


Nicolas

[git pull] drm fixes

[Takashi Iwai]

At Wed, 22 Dec 2010 16:59:06 +,
Chris Wilson wrote:
> 
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
> > The commit 448f53a1ede54eb854d036abf54573281412d650
> >   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
> > 
> > causes a regression on a SandyBridge machine here.
> > The laptop display (LVDS) becomes blank.  Reverting the commit fixes
> > the problem.
> 
> The question is whose BIOS is wrong? The Lenovo U160's or the
> Sandybridge SDV? And why does it work for that other OS?  rhetorical question of the day here.>
> 
> It's back to the square one for one or the other platform...

Yeah, we can blame BIOS :)  And, this is likely the BIOS on my machine
here that is broken.

But this seems like an issue that you can't rely solely on VBT.  We
can never guarantee that BIOS is correct (who can?), and there is no
way to avoid this change as long as it's hard-coded.  We've hit
another regression by VBT check (e-DP  wrongly detected; kernel bug
24822), so I think judging the behavior only from BIOS is rather
dangerous.


thanks,

Takashi

[git pull] drm fixes

[Takashi Iwai]

At Tue, 21 Dec 2010 23:43:18 + (GMT),
Dave Airlie wrote:
> 
> 
> Hi,
> 
> meant to get this out earlier, but I've been off sick as well as having a 
> sick kid, also meant a few things piled up when I wasn't looking
> 
> contains a revert for reported regression in intel and also one in radeon,
> a few radeon fixes, one for a 15s resume time on certain laptops, and one 
> to fix gpu reset on some gpus,
> 
> Dave.
> 
> The following changes since commit a4851d8f7d6351a395d36ae8fdcf41745a832d76:
> 
>   Merge branch 'for_linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-12-15 12:41:17 
> -0800)
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-fixes
> 
> Alex Deucher (7):
>   drm/radeon/kms: disable ss fixed ref divide
>   drm/radeon/kms: disable the r600 cb offset checker for linear surfaces
>   drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb
>   drm/radeon/kms: fix evergreen asic reset
>   drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
>   drm/radeon/kms: reorder display resume to avoid problems
>   drm/radeon/kms: fix bug in r600_gpu_is_lockup
> 
> Benjamin Herrenschmidt (1):
>   drm/radeon: Add early unregister of firmware fb's
> 
> Chris Wilson (5):
>   drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD
>   drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
>   agp/intel: Fix missed cached memory flags setting in i965_write_entry()
>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
>   drm: Include the connector name in the output_poll_execute() debug 
> message

The commit 448f53a1ede54eb854d036abf54573281412d650
  drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks

causes a regression on a SandyBridge machine here.
The laptop display (LVDS) becomes blank.  Reverting the commit fixes
the problem.


thanks,

Takashi

[git pull] drm fixes

[Chris Wilson]

On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai  wrote:
> The commit 448f53a1ede54eb854d036abf54573281412d650
>   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
> 
> causes a regression on a SandyBridge machine here.
> The laptop display (LVDS) becomes blank.  Reverting the commit fixes
> the problem.

The question is whose BIOS is wrong? The Lenovo U160's or the
Sandybridge SDV? And why does it work for that other OS? 

It's back to the square one for one or the other platform...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:

> On 22 December 2010 21:22, Nicolas Pitre  wrote:
> > Having accommodations in the kernel for proprietary drivers is not a
> > mutual benefit anymore. ?That might be hard to understand from your
> > point of view, but the incentives in the Open Source communities aren't
> > based on commercial results.
> 
> DISCLAIMER: I'm also a Debian developer -have been since 1999 with a
> small 2y break- so I _do_ know the F/OSS community point of view. My
> goals have been always in promoting open source and free software
> solutions when and when not available.

Good to know.

> Right now open source solutions are _not_ available, and that is the 
> problem.

Yes, everyone agrees.  Well, I suppose.

That would be the first official statement to make.  Do we really 
consider this a problem?  Because most companies used to the proprietary 
model won't see a problem at all here, and therefore wouldn't consider 
any effort in the direction of open drivers a worthy goal. That would be 
the heart of any subsequent misunderstandings.

I'll let someone else with a bigger Linaro hat make that official 
statement though.

> I haven't reversed engineered any driver so I can't claim of knowledge in this
> matter. However I've been following closely other such projects like nouveau
> and it took them a _long_ time to get to this point here -which may be usable
> for many people, but it's not even at a beta state according to the Nouveau
> developers. Even if we assume the fact that 10 times more ARM F/OSS
> developers gather to reverse engineer the binary blobs, how long do you think
> it would take until a beta driver appears? 1 year? 2 years? And what will 
> happen
> in the meantime?

In the mean time some other company might see a nice opportunity to 
sidestep the competition by making its drivers fully open source.  
That's what happened with WIFI, resulting in the least expected company 
to finally open up its driver like all the others ended up doing.  It 
must have been economically advantageous to them in the end (lower 
support costs, additional customer opportunities, etc.)

> I'm not advocating that closed source drivers be included in the 
> kernel, but IMHO, having an open kernel-space driver would also help 
> the reverse engineering process at the same time as allowing common 
> users as well as developers to use and test any 3D applications -don't 
> forget that 3D problems don't end at the driver, rather the opposite.

Problems don't end at the driver, they start there.

And those proprietary drivers exist and are being used already.  But 
don't expect the mainline kernel to make accommodations for them. It is 
not economically viable for the Open Source community to accommodate 
proprietary drivers, irrespective of how loud you might advocate for 
that.


Nicolas

Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:

> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
>  wrote:
> >> So to say that the corporate world might need to consider Open Source to
> >> be competitive and survive, but the reverse is not true i.e. Open Source
> >> doesn't _require_ the corporate world to survive.
> >
> > i agree with it fully, and to support this claim i want to remind the
> > simple rule of capital accumulation. Open Source community
> > _already_ accumulated enough _capital_ in form of algorithms,
> > implementations, social relations, experience, documentation and
> > augmentation with education system .
> 
> I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
> thrive and make a difference in the world without the corporate world?
> Definitely not. If you only care about the former that's fine, but
> have no illusion that we would even be having this discussion here
> were it not for the corporate world caring about Linux on ARM.

Maybe.  But corporations so far have played by the Open Source rules to 
make ARM Linux what it is.  There was mutual benefits in that and ARM 
Linux did grew faster.

Having accommodations in the kernel for proprietary drivers is not a 
mutual benefit anymore.  That might be hard to understand from your 
point of view, but the incentives in the Open Source communities aren't 
based on commercial results.


Nicolas

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #12 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-22 
13:48:56 PST ---
(In reply to comment #9)
> With the patch from comment 8, try these possible fixes:
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index b0ab185..0be8015 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> (rdev->family == CHIP_RS690) ||
> (rdev->family == CHIP_RS740))
> pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
> -  RADEON_PLL_PREFER_CLOSEST_LOWER);
> +  RADEON_PLL_PREFER_CLOSEST_HIGHER);
> 
> if (ASIC_IS_DCE32(rdev) && mode->clock > 20)/*
> range limits??? */
> pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
> 
> Or:
> 
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index b0ab185..91facc8 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> (rdev->family == CHIP_RS690) ||
> (rdev->family == CHIP_RS740))
> pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
> -  RADEON_PLL_PREFER_CLOSEST_LOWER);
> +  RADEON_PLL_NO_ODD_POST_DIV);
> 
> if (ASIC_IS_DCE32(rdev) && mode->clock > 20)/*
> range limits??? */
> pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

None of the proposed solutions fix the problem for good although there is some
improvement over the flickering frequency.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #11 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-22 
13:47:35 PST ---
Created an attachment (id=41380)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41380)
patch + RADEON_PLL_NO_ODD_POST_DIV

registers for kms with new pll patch applied + RADEON_PLL_NO_ODD_POST_DIV

Screen flickers slightly less than without patch but is still unusable

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #10 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-22 
13:45:40 PST ---
Created an attachment (id=41379)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41379)
patch+RADEON_PLL_PREFER_CLOSEST_HIGHER

registers for kms with new pll patch applied + RADEON_PLL_PREFER_CLOSEST_HIGHER

Screen flickers slightly less than previously but is still unusable

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Freescale Linux BSP review

[Jerome Glisse]

On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
 wrote:
> On 22 December 2010 09:51, Matt Sealey  wrote:
>> Okay I hereby refrain from legal comments.
>>
>> In any case, this code has passed legal at Freescale and AMD *AND*
>> Qualcomm. It would not be GPL if it has not been vetted (and it took
>> them a year to get to this point).
>
> It appears that this discussion ended up on phoronix.com [1], with an
> air of hostility towards Genesi and Matt for no good reason.
>
> I don't know whose idea was that, but it's certainly of very bad taste
> and helps very little to the discussion. Matt poses real questions and
> issues we -as a company producing ARM products- face all the time.
> Admittedly the technical reasons for not including the kernel-space
> driver into mainline presented by Dave Airlie are correct and very
> down-to-earth. But IMHO, *this* should be the starting point to
> continue the discussion, instead of immediately rejecting this driver.
> Is there *any* way that problem posed by Dave could be solved, perhaps
> by throwing the ball to the ARM vendor companies to provide just a
> small extra part of the code needed to do API checks and therefore
> ensuring the kernel guys CAN actually do their work as they like?

It's not enough to provide a toy program/library that just call into
the new kernel API, you really need to provide a full open source use
case that does achieve somethings using the new kernel API you are
introducing. It's the only way we can possibly evaluate the new API.

Open source GPU kernel API are a pain to design and i can tell you
that if i had liberty to change them i would do that a lot until
finding the best one (nouveau is in happy situation here and they are
more than right to wait until they are completely satisfied with the
API before freezing it).

> As for the philosophical problems, well, I'm sure everyone here
> understands that the situation of ARM graphics in the kernel is in no
> way comparable to Intel or Nvidia/ATI chipsets, they had totally
> different starting points. ARM came from the embedded market where it
> thrived for many years with the exact same licensing rules that we all
> would like to abolish in just a few months, where at the same time we
> "swallowed" the fact that it took Intel and ATI/AMD - forget nvidia,
> nv-obfuscated driver IN the kernel for YEARS? really? - many years to
> accept mainline opensource development. And even Intel with all their
> experience made a complete mess of things using the latest cpus.

No body is saying AMD or Intel were fast to jump into open source,
doesn't mean that ARM ecosystem can't do it faster than AMD or Intel
did.

> I *really* do appreciate Linaro and the effort from ARM and the
> relevant vendors towards open source enablement, and Genesi has proven
> that by donating ~50 ARM based netbooks and smarttops to Linaro
> developers at Linaro at UDS -and around ~40 units to other projects
> including Debian and Gentoo -and we intend to give more in the future.
> We know the process and how it works, just as well as everyone here
> does actually. But we also have to be pragmatic. An ARM based
> solution/product with no long-term support from the kernel side will
> find it very hard to survive indeed. I strongly believe that, half a
> solution is better than no solution, and it can also serve a purpose
> until a proper full solution appears. It also does show a leap of good
> faith from the FOSS side, and one which ARM companies will have to
> follow soon.
>
> So, if by chance anyone really expects ARM licensees to do 180 degrees
> change in philosophy overnight, I obviously cannot speak for them, but
> IMHO, that is not bound to happen. It will probably happen in a few
> years but only by discussion and collaboration, seriously not by
> dealing with absolutes. Denying even the smallest step backwards from
> the side of the FOSS community is not a victory, it's a downright
> failure of the community side to actively support and push ARM -based
> devices as an alternative Linux desktop and portable solutions
> (netbook etc).
>
> My 2c.
>

Cheers,
Jerome Glisse

Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Tom Gall wrote:

> The very important part of this whole discussion is getting arm Linux and it's
> 3d driver situation so it TOO is the best.
> 
> Right now it's not and pointing to other elements of the system and saying
> "it's great" is besides the point.

My whole point, if I may resume my conclusion to a few words, is that 
most Open Source folks don't care if you can't open your code for 
whatever reasons.  That won't encourage them to compromise on their 
fundamental principle.  It's up to those companies to balance the cost 
of maintaining their ad hoc proprietary stuff themselves vs the cost of 
opening up their code so it can be merged upstream.

> This discussion is good, but for it to have a positive outcome, we need to
> turn the direction back to how we get to the end goal
> for arm 3D graphics.

Absolutely!

> It's not probably going to happen at once with one patch that does 
> what everyone wants. I think it's going to take graduated steps and 
> some compromises.

Yes.  However, as I said, those compromises may not come on the 
technical aspects of the kernel interfaces.  Just like it is unlikely 
for companies to ever compromise on their profits.  Any compromise 
touching any of those fundamental aspects for their respective parties 
is bound to always fail.

In other words, let's save ourselves some energy and give up on the idea 
that a kernel shim only for a binary only user space library is going to 
ever be accepted in mainline.  This simply will never happen, period.


Nicolas

[Bug 30131] Command & Conquer 3 crashes with r300g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30131

--- Comment #7 from Marek Ol??k  2010-12-22 13:21:40 PST 
---
The game should not crash the X server. If it does, you are probably using
indirect rendering, which might happen with 32-bit apps on x86_64 systems.
Indirect rendering is buggy, slow, contains only a subset of features r300g
offers, and gets very little testing AFAIK. So please make sure the game uses
direct rendering. I should mention that using a 32-bit system may help.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 09:51, Matt Sealey  wrote:
> Okay I hereby refrain from legal comments.
>
> In any case, this code has passed legal at Freescale and AMD *AND*
> Qualcomm. It would not be GPL if it has not been vetted (and it took
> them a year to get to this point).

It appears that this discussion ended up on phoronix.com [1], with an
air of hostility towards Genesi and Matt for no good reason.

I don't know whose idea was that, but it's certainly of very bad taste
and helps very little to the discussion. Matt poses real questions and
issues we -as a company producing ARM products- face all the time.
Admittedly the technical reasons for not including the kernel-space
driver into mainline presented by Dave Airlie are correct and very
down-to-earth. But IMHO, *this* should be the starting point to
continue the discussion, instead of immediately rejecting this driver.
Is there *any* way that problem posed by Dave could be solved, perhaps
by throwing the ball to the ARM vendor companies to provide just a
small extra part of the code needed to do API checks and therefore
ensuring the kernel guys CAN actually do their work as they like?

As for the philosophical problems, well, I'm sure everyone here
understands that the situation of ARM graphics in the kernel is in no
way comparable to Intel or Nvidia/ATI chipsets, they had totally
different starting points. ARM came from the embedded market where it
thrived for many years with the exact same licensing rules that we all
would like to abolish in just a few months, where at the same time we
"swallowed" the fact that it took Intel and ATI/AMD - forget nvidia,
nv-obfuscated driver IN the kernel for YEARS? really? - many years to
accept mainline opensource development. And even Intel with all their
experience made a complete mess of things using the latest cpus.

I *really* do appreciate Linaro and the effort from ARM and the
relevant vendors towards open source enablement, and Genesi has proven
that by donating ~50 ARM based netbooks and smarttops to Linaro
developers at Linaro at UDS -and around ~40 units to other projects
including Debian and Gentoo -and we intend to give more in the future.
We know the process and how it works, just as well as everyone here
does actually. But we also have to be pragmatic. An ARM based
solution/product with no long-term support from the kernel side will
find it very hard to survive indeed. I strongly believe that, half a
solution is better than no solution, and it can also serve a purpose
until a proper full solution appears. It also does show a leap of good
faith from the FOSS side, and one which ARM companies will have to
follow soon.

So, if by chance anyone really expects ARM licensees to do 180 degrees
change in philosophy overnight, I obviously cannot speak for them, but
IMHO, that is not bound to happen. It will probably happen in a few
years but only by discussion and collaboration, seriously not by
dealing with absolutes. Denying even the smallest step backwards from
the side of the FOSS community is not a victory, it's a downright
failure of the community side to actively support and push ARM -based
devices as an alternative Linux desktop and portable solutions
(netbook etc).

My 2c.

Konstantinos

[1]: http://www.phoronix.com/scan.php?page=news_item=ODk0NA

[PATCH] drm: Recover DPMS properly after XRandr re-enablement

[Chris Wilson]

On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson  
wrote:
> From: Takashi Iwai 

> This patch adds a new helper function to manage the drm_connector
> DPMS so that it can be called commonly in both places.
> 
> Signed-off-by: Takashi Iwai 

FWIW,

Reviewed-by: Chris Wilson 

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 30131] Command & Conquer 3 crashes with r300g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=30131

--- Comment #6 from Martin Stolpe  2010-12-22 
12:47:13 PST ---
Created an attachment (id=41378)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=41378)
wine output

Unfortunately this is still a problem with the latest mesa git.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: Recover DPMS properly after XRandr re-enablement

[Chris Wilson]

From: Takashi Iwai 

When the output is turned off via "xrandr --off" and re-enabled again
with the same mode, drm doesn't reset DPMS, thus it results in a black
screen.  A typical example is something like:

 % xrandr --output LVDS1 --mode 1024x768
 % xrandr --output VGA1 --mode 1024x768
 % xrandr --output LVDS1 --off
 % xrandr --output LVDS1 --mode 1024x768

Also, there is another problem with DPMS: the sysfs entries don't
match with the actual state.  In the case above, LVDS1 shows always
Off, while VGA1 shows On.

A part of the cause is that there are (still) two places to keep
the actual DPMS values.  In dpms field of drm_connector and in the
device property.  Thus we need to sync between them.

Another problem is that the DPMS state is always set to ON forcibly
in drm_crtc_helper_set_config() (via commit
bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f).  This results in another
inconsistency.  For recovering the DPMS, we need to set DPMS actaully
ON there.

This patch adds a new helper function to manage the drm_connector
DPMS so that it can be called commonly in both places.

Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/drm_crtc.c|   25 ++---
 drivers/gpu/drm/drm_crtc_helper.c |7 ---
 include/drm/drm_crtc.h|1 +
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2baa670..3a58337 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2383,6 +2383,18 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+int drm_connector_set_dpms(struct drm_connector *connector, int mode)
+{
+   if (connector->funcs->dpms)
+   (*connector->funcs->dpms)(connector, mode);
+   connector->dpms = mode;
+   drm_connector_property_set_value(connector,
+
connector->dev->mode_config.dpms_property,
+mode);
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_set_dpms);
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -2440,15 +2452,14 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,

/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
-   if (connector->funcs->dpms)
-   (*connector->funcs->dpms)(connector, (int) 
out_resp->value);
+   drm_connector_set_dpms(connector, (int) out_resp->value);
ret = 0;
-   } else if (connector->funcs->set_property)
+   } else if (connector->funcs->set_property) {
ret = connector->funcs->set_property(connector, property, 
out_resp->value);
-
-   /* store the property value if successful */
-   if (!ret)
-   drm_connector_property_set_value(connector, property, 
out_resp->value);
+   /* store the property value if successful */
+   if (!ret)
+   drm_connector_property_set_value(connector, property, 
out_resp->value);
+   }
 out:
mutex_unlock(>mode_config.mutex);
return ret;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index bede10a..fee755d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -669,9 +669,10 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
DRM_DEBUG_KMS("Setting connector DPMS state to on\n");
for (i = 0; i < set->num_connectors; i++) {
-   DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", 
set->connectors[i]->base.id,
- drm_get_connector_name(set->connectors[i]));
-   set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+   struct drm_connector *connector = set->connectors[i];
+   DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", 
connector->base.id,
+ drm_get_connector_name(connector));
+   drm_connector_set_dpms(connector, DRM_MODE_DPMS_ON);
}

kfree(save_connectors);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 029aa68..c9a5a80 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,7 @@ extern void drm_mode_set_crtcinfo(struct drm_display_mode 
*p,
 extern void drm_mode_connector_list_update(struct drm_connector *connector);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
+extern int drm_connector_set_dpms(struct drm_connector *connector, int mode);
 extern int drm_connector_property_set_value(struct drm_connector *connector,
 struct drm_property 

Freescale Linux BSP review

[Dave Airlie]

On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski
 wrote:
>> you have two pieces of code, a userspace 3D *driver* (not
>> application), and a kernel driver talking to the hw, if the userspace
>> 3D driver cannot exist without the kernel driver, it could very well
>> be considered a derivative work of the kernel driver. You are not
>> protected by the standard Linux system call exception since it states
>> "normal system calls", so adding a driver to the kernel to expose a
>> bunch of driver specific ioctls to allow the userspace 3D work blurs
>> the lines sufficiently that you are into the domain of derived works
>> and should call your lawyers.
>
> so any user-written (gpl compatible) driver which exposes new ioctls
> which allow other software to work (i.e. network driver allowing closed
> source software to send and recieve packets is illegal aswell?
>
> it is getting confusing...

You need to read before replying.

If the interface is a generic interface that any software can use then
its fine, when the interface is a specific interface for a specific
closed userspace driver it becomes questionable.

Again you are thinking general case when we are talking specifics.

>
> shall everyone hire lawyer prior to using any software under linux?
>

this is a peanut gallery comment, nobody mentioned using any software
under linux here, we are talking about development of linux software.

Please read and understand before replying with pointless emails like this.

Dave.

[PATCH] drm/radeon: Remove DRIVER_DATE for UMS and KMS

[Sedat Dilek]

2010/12/22 Michel D?nzer :
> On Mit, 2010-12-22 at 08:38 +0100, Sedat Dilek wrote:
>>
>> sorry, I still haven't setup a git-send-mail, thus sending the
>> old-fashioned way as attached patch.
>
> Your mailer might allow integrating the output of git format-patch into
> the mail body directly instead.
>
>> This patch (against linux-next) is overdue.
>>
>> "DRIVER_DATE is not maintained or upgraded on changes.
>>
>> Furthermore, one DRIVER_DATE for UMS and KMS makes no sense.
>> It is enough to bump {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
>> {KMS_}DRIVER_PATCHLEVEL defines."
>
> What ends up being printed as the date in dmesg?
>

This patch was not complete.
I could start with KMS-enabled into runlevel-3 (IIRC version of radeon
with (null) in brackets), when wanting to startx, machine died with a
error-message.

I have sent a new patch "[PATCH] drm: Remove DRIVER_DATE and
CORE_DATE" (see [1]), which works as expected.

- Sedat -

[1] http://lists.freedesktop.org/archives/dri-devel/2010-December/006586.html

P.S.:

$ dmesg | egrep -i 'drm|radeon|kms|modeset|frame buffer'
[0.00] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.37-rc6-686
root=UUID=1ceb69a7-ecf4-47e9-a231-b74e0f0a9b62 ro init=/bin/systemd
radeon.modeset=1 lapic 3
[   12.328937] [drm] Initialized drm 1.1.0
[   12.818330] [drm] radeon kernel modesetting enabled.
[   12.818500] radeon :01:00.0: power state changed by ACPI to D0
[   12.818540] radeon :01:00.0: power state changed by ACPI to D0
[   12.818587] radeon :01:00.0: PCI INT A -> Link[LNKA] -> GSI 11
(level, low) -> IRQ 11
[   12.826296] [drm] initializing kernel modesetting (RV250
0x1002:0x4C66).
[   12.841960] [drm] register mmio base: 0xC010
[   12.842001] [drm] register mmio size: 65536
[   12.842524] radeon :01:00.0: putting AGP V2 device into 4x mode
[   12.842587] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF
[   12.842630] radeon :01:00.0: VRAM: 128M 0xE000 -
0xE7FF (64M used)
[   12.842694] [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
[   12.842731] [drm] Driver supports precise vblank timestamp query.
[   12.842785] [drm] radeon: irq initialized.
[   12.845300] [drm] Detected VRAM RAM=128M, BAR=128M
[   12.845342] [drm] RAM width 128bits DDR
[   12.848233] [drm] radeon: 64M of VRAM memory ready
[   12.848273] [drm] radeon: 256M of GTT memory ready.
[   12.850055] radeon :01:00.0: WB enabled
[   12.850766] [drm] Loading R200 Microcode
[   12.969090] [drm] radeon: ring at 0xD0001000
[   12.969152] [drm] ring test succeeded in 1 usecs
[   12.969481] [drm] radeon: ib pool ready.
[   12.970156] [drm] ib test succeeded in 0 usecs
[   12.971841] [drm] Panel ID String: SXGA+ Single (85MHz)
[   12.971878] [drm] Panel Size 1400x1050
[   12.983044] [drm] radeon legacy LVDS backlight initialized
[   12.983737] [drm] No TV DAC info found in BIOS
[   12.983862] [drm] Radeon Display Connectors
[   12.983897] [drm] Connector 0:
[   12.983929] [drm]   VGA
[   12.983963] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[   12.984013] [drm]   Encoders:
[   12.984046] [drm] CRT1: INTERNAL_DAC1
[   12.984080] [drm] Connector 1:
[   12.984112] [drm]   DVI-D
[   12.984144] [drm]   HPD1
[   12.984177] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[   12.984212] [drm]   Encoders:
[   12.984245] [drm] DFP1: INTERNAL_TMDS1
[   12.984278] [drm] Connector 2:
[   12.984310] [drm]   LVDS
[   12.984342] [drm]   Encoders:
[   12.984374] [drm] LCD1: INTERNAL_LVDS
[   12.984407] [drm] Connector 3:
[   12.984439] [drm]   S-video
[   12.984471] [drm]   Encoders:
[   12.984503] [drm] TV1: INTERNAL_DAC2
[   12.992152] [drm] radeon: power management initialized
[   13.038149] [drm] fb mappable at 0xE004
[   13.038188] [drm] vram apper at 0xE000
[   13.038221] [drm] size 5914624
[   13.038254] [drm] fb depth is 24
[   13.038286] [drm]pitch is 5632
[   13.108205] Console: switching to colour frame buffer device 175x65
[   13.143219] fb0: radeondrmfb frame buffer device
[   13.143386] drm: registered panic notifier
[   13.144019] [drm] Initialized radeon 2.8.0 for :01:00.0 on minor 0

- EOT -

Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, David Rusling wrote:

>   Now for a bit of a rant.  Personally, I have a deep and abiding 
> respect for open source (for me, it's the key social invention of the 
> internet age), however I also recognise that it would not exist 
> without companies using open source as part of their products.  Let's 
> face it, an awful lot of open source engineers are getting their 
> mortgages paid by companies that make use of open source.

I cannot be in full agreement with the above statement.  I think the 
reality is way more nuanced than that.

The truth of the matter is that Open Source came into existence without 
and despite involvement from the corporate world.  And the very reason 
it started to attract interest from the corporate world is because of 
Open Source's superior quality and performance at a lower cost.  Open 
Source would have existed even without companies using it as you would 
still have those Open Source activists using it themselves in your 
product, even without the help of the corporate money. The company 
involvement in Open Source did indeed accelerate its development by 
paying many people to work on it full time.  But Open Source would still 
be there and still be in good shape even if corporate involvement didn't 
happen, just like it was before.

And this superior quality and performance characteristics of Open Source 
are not a coincidence.  They are the first motives in a world which is 
not driven by monetary profits, unlike most if not all the proprietary 
alternatives.  The people leading Open Source are driven by the 
technical excellence of their work and the recognition they get from 
their peers.  Money is a far secondary motive, and in this age you can 
choose between different sources of sufficient money not to have to 
worry about it anymore and compromise too much on your primary motives 
when you already have a track record in this Open Source world.

So to say that the corporate world might need to consider Open Source to 
be competitive and survive, but the reverse is not true i.e. Open Source 
doesn't _require_ the corporate world to survive.

> No company invests in open source for philanthropic reasons; they 
> understand that it is necessary for their businesses.  The tricky 
> problem is always in how ethical a company's usage is (and I use the 
> word 'ethical' deliberately because this is wider than mere legal 
> words smithing); whenever I give talks on GPL, I emphasise both the 
> moral as well as the legal duties.  In my experience, most companies 
> struggle to understand open source when they first start to interact 
> with it.  It usually takes some open source zealots within the company 
> to persuade their management of the right way to behave.  The best way 
> to get companies to change their behaviour is to find them and support 
> them.  Making threatening GPL noises in email does not help them in 
> any way.

Here I'm more in agreement with you.  However this is again not the full 
picture.

Ethical or not, the first motive of a company is to make profits.  If 
that was easy to get away with it, all that companies would do is simply 
to grab this body of source code for themselves and never contribute 
back. And a sizable number of companies, even some sizable companies, 
are doing just that.  While this isn't going to kill Open Source, this 
certainly makes it weaker because this is contrary to that very first 
principle that made Open Source a success in the first place.  
Companies doing that are after the immediate monetary profit and not the 
technical excellence and performances.

But even when leaving the ethical aspect aside, it is not going to be 
profitable for companies in the long term to grab Open Source results 
and move it back to the legacy proprietary model.  Doing that will be to 
their disadvantage when some other companies come along to compete on 
the market using Open Source to its fullest technical excellence and 
performance potential.  Fortunately, a sizable number of companies, even 
sizable ones, did understand that already.

But... while some companies are struggling to understand how to interact 
with Open Source, the Open Source world still dash ahead without much 
concerns for corporate profits.  As said above, those strange Open 
Source animals are motivated by the technical excellence of their work, 
and they're going to fight on that front against anything that might 
affect or prevent that goal.  This is again why Open Source has always 
progressed even despite initial attempts to kill it from some 
corporations.  So far, Linux has always been immune to monetary forces, 
whether those forces were against it or not. So it is fair to say that 
Open Source survival depends primarily on its technical advantages above 
anything else.

In conclusion: don't get surprised if technically inferior propositions, 
such as proprietary 3D libraries coupled with kernel-side interfaces, 
are met with 

[Bug 25422] nouveau fails to build on ia64

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=25422


Rafael J. Wysocki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||rjw at sisk.pl
 Resolution||PATCH_ALREADY_AVAILABLE




--- Comment #1 from Rafael J. Wysocki   2010-12-22 12:19:26 ---
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41242
Handled-By : Ben Hutchings 

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Freescale Linux BSP review

[David Rusling]

Konstantinos,
thanks, I agree with your thoughts.   My approach has been to accept 
small steps in the right direction and encourage reasoned discussion.   I also 
think that Linaro's main function is as a place where all the moving parts can 
collaborate.Right now, the GPU 'problem' is that of getting both open 
source and proprietary pieces of the BSPs to work really well together in 
products.   That's really the focus of the Graphics WGs and the partner landing 
teams.   This is a heavy lifting engineering job, and it will take time, but 
everyone is willing and hopeful of good results.Doing this will also help 
us have a reasoned discussion about where the open source and proprietary 
boundaries make sense.

Now for a bit of a rant.   Personally, I have a deep and abiding 
respect for open source (for me, it's the key social invention of the internet 
age), however I also recognise that it would not exist without companies using 
open source as part of their products.Let's face it, an awful lot of open 
source engineers are getting their mortgages paid by companies that make use of 
open source. No company invests in open source for philanthropic reasons; 
they understand that it is necessary for their businesses.The tricky 
problem is always in how ethical a company's usage is (and I use the word 
'ethical' deliberately because this is wider than mere legal words smithing); 
whenever I give talks on GPL, I emphasise both the moral as well as the legal 
duties.In my experience, most companies struggle to understand open source 
when they first start to interact with it.   It usually takes some open source 
zealots within the company to persuade their management of the right way to 
behave.   The best way to get companies to change their behaviour is to find 
them and support them.  Making threatening GPL noises in email does not help 
them in any way.

Dave


David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH

Freescale Linux BSP review

[Tom Gall]

On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre
 wrote:
> On Wed, 22 Dec 2010, David Rusling wrote:
>
>> ? ? ? Now for a bit of a rant. ?Personally, I have a deep and abiding
>> respect for open source (for me, it's the key social invention of the
>> internet age), however I also recognise that it would not exist
>> without companies using open source as part of their products. ?Let's
>> face it, an awful lot of open source engineers are getting their
>> mortgages paid by companies that make use of open source.
>
> I cannot be in full agreement with the above statement. ?I think the
> reality is way more nuanced than that.
>
> The truth of the matter is that Open Source came into existence without
> and despite involvement from the corporate world. ?And the very reason
> it started to attract interest from the corporate world is because of
> Open Source's superior quality and performance at a lower cost. ?Open
> Source would have existed even without companies using it as you would
> still have those Open Source activists using it themselves in your
> product, even without the help of the corporate money. The company
> involvement in Open Source did indeed accelerate its development by
> paying many people to work on it full time. ?But Open Source would still
> be there and still be in good shape even if corporate involvement didn't
> happen, just like it was before.

Right but it didn't happen over night. Getting to this state took time
and wasn't
an immediate quality. Back in them thar early days it took a lot of
figuring out,
in some case with and some cases without the cooperation of the hardware
types. How many years did I pine for token ring drivers sigh.

The very important part of this whole discussion is getting arm Linux and it's
3d driver situation so it TOO is the best.

Right now it's not and pointing to other elements of the system and saying
"it's great" is besides the point.

This discussion is good, but for it to have a positive outcome, we need to
turn the direction back to how we get to the end goal
for arm 3D graphics. It's not probably going to happen at once with one
patch that does what everyone wants. I think it's going to take graduated steps
and some compromises.

Regards,
Tom
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

Freescale Linux BSP review

[Dave Airlie]

On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey  wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann  wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
>>> >> single entity, that span kernel and userspace, one cannot exist
>>> >> without the other, and there are interfaces that join them.
>>> >
>>> > As a copyright holder on the kernel I'll also remind the people concerned
>>> > that the definition of a derivative work is a legal not a technical one
>>> > and if the kernel and user space cannot be used except together and one
>>> > half depends on GPL elements I hope your lawyers have reviewed it
>>> > carefully. I have never given anyone permission to link my GPL kernel
>>> > contributions with anything but GPL code, modular or otherwise, except
>>> > according to the derivative work rules laid down by the GPL (and indeed
>>> > by the boundaries placed on copyright law).
>>>
>>> but it can be circumvented by writing GPL driver which will act as 'glue
>>> logic' inbetween userspace driver and which will work in kernel space?
>>>
>>> technically then driver would be GPL, except it's closed parts which will
>>> be ran in userspace... or can you forbid usage of certain closed userspace
>>> components with kernel?
>>
>> Anyone can try shipping this and risk a lawsuit, and all copyright holders
>> of the kernel can try suing people that distribute such code. Most sensible
>> people stay out of both the shipping questionable code and the suing part,
>> but apparently the entire mobile phone industry is already doing both, so
>> we can just wait and see if anyone has deep enough pockets to bring this
>> up in court first ;-).
>
> Nobody will because it is unenforcable.
>
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
> clause can actually be manipulated to basically disavow closed source
> code from having to be published as open source if it interfaces with
> the standard operating system components. It is meant to protect
> software developers from having to bundle a gigabyte of kernel and
> compiler code with their 100 line app that uses an ioctl, but legally
> it works against ?the GPL in this way. It is what means AMD, nVidia,
> Intel (hi Alan), and others can produce binary code and binary
> executables that run on opensource kernels (wireless regulatory daemon
> in the early days) basically with impunity.
>
> You may think it's a horrible idea, and from a technical perspective
> it is, but from a legal perspective.. it's not a problem.

You should probably refrain from stating legal opinions around here,
Alan stated there is a possible issue legally and you should talk to
lawyers. I find his reasoning to be sane but no idea if its legal. The
point you are missing (you seem to not think much before typing) is
this:

you have two pieces of code, a userspace 3D *driver* (not
application), and a kernel driver talking to the hw, if the userspace
3D driver cannot exist without the kernel driver, it could very well
be considered a derivative work of the kernel driver. You are not
protected by the standard Linux system call exception since it states
"normal system calls", so adding a driver to the kernel to expose a
bunch of driver specific ioctls to allow the userspace 3D work blurs
the lines sufficiently that you are into the domain of derived works
and should call your lawyers.


>
> Frankly, this discussion (besides the sidetrack to the non-existant
> legal issues) did pop up a major problem in the possibility of
> unifying the IPU, dual GPU and other graphics subsystem frameworks on
> the i.MX processor line, and potentially others too (TI's LCDC and PVR
> graphics) in that DRM/DRI security policy will forbid them (in the
> form of David Arlie complaining) from sharing the same memory area,
> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
> acceleration and DMA between the units requires bounce buffers and
> some overly complicated memory copying between memory areas for them
> to interoperate. I think TI hit this problem trying to get a texture
> from the DSP to the GPU to render it to a texture and came up with an
> awful (closed source :) method of ioctls and so on to achieve it. I
> had an idea to solve it using DRM and GEM but it's been shot down in
> concept now... what's the point? It'll never get into mainline.

I never said the security policy would forbid anything, I said they
need to prove
that they've thought about these things and can prove they are secure, if this
requires opening the code and/or documents then that is the way it is. The
thing is if you require a userspace application with user privs to
access these devices
then you must stop the user from doing bad things, from my experience vendors
give little concern for these issues until

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #9 from Alex Deucher  2010-12-22 11:28:24 PST 
---
With the patch from comment 8, try these possible fixes:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..0be8015 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
(rdev->family == CHIP_RS690) ||
(rdev->family == CHIP_RS740))
pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-  RADEON_PLL_PREFER_CLOSEST_LOWER);
+  RADEON_PLL_PREFER_CLOSEST_HIGHER);

if (ASIC_IS_DCE32(rdev) && mode->clock > 20)/*
range limits??? */
pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

Or:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..91facc8 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
(rdev->family == CHIP_RS690) ||
(rdev->family == CHIP_RS740))
pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-  RADEON_PLL_PREFER_CLOSEST_LOWER);
+  RADEON_PLL_NO_ODD_POST_DIV);

if (ASIC_IS_DCE32(rdev) && mode->clock > 20)/*
range limits??? */
pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #8 from Alex Deucher  2010-12-22 11:26:01 PST 
---
Created an attachment (id=41376)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41376
 Review: https://bugs.freedesktop.org/review?bug=32556=41376

add new pll flag

This patch adds a new pll flag to prefer slightly higher frequencies if the
target clock cannot be hit exactly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: fix bug in r600_gpu_is_lockup

[Jerome Glisse]

On Tue, Dec 21, 2010 at 4:05 PM, Alex Deucher  wrote:
> We were using the lockup struct from the wrong union.
>
> Signed-off-by: Alex Deucher 
> Cc: Jerome Glisse 
Reviewed-by: Jerome Glisse 

> ---
> ?drivers/gpu/drm/radeon/r600.c | ? 10 --
> ?1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 2078108..292b282 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -1345,13 +1345,19 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
> ? ? ? ?u32 srbm_status;
> ? ? ? ?u32 grbm_status;
> ? ? ? ?u32 grbm_status2;
> + ? ? ? struct r100_gpu_lockup *lockup;
> ? ? ? ?int r;
>
> + ? ? ? if (rdev->family >= CHIP_RV770)
> + ? ? ? ? ? ? ? lockup = >config.rv770.lockup;
> + ? ? ? else
> + ? ? ? ? ? ? ? lockup = >config.r600.lockup;
> +
> ? ? ? ?srbm_status = RREG32(R_000E50_SRBM_STATUS);
> ? ? ? ?grbm_status = RREG32(R_008010_GRBM_STATUS);
> ? ? ? ?grbm_status2 = RREG32(R_008014_GRBM_STATUS2);
> ? ? ? ?if (!G_008010_GUI_ACTIVE(grbm_status)) {
> - ? ? ? ? ? ? ? r100_gpu_lockup_update(>config.r300.lockup, >cp);
> + ? ? ? ? ? ? ? r100_gpu_lockup_update(lockup, >cp);
> ? ? ? ? ? ? ? ?return false;
> ? ? ? ?}
> ? ? ? ?/* force CP activities */
> @@ -1363,7 +1369,7 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
> ? ? ? ? ? ? ? ?radeon_ring_unlock_commit(rdev);
> ? ? ? ?}
> ? ? ? ?rdev->cp.rptr = RREG32(R600_CP_RB_RPTR);
> - ? ? ? return r100_gpu_cp_is_lockup(rdev, >config.r300.lockup, 
> >cp);
> + ? ? ? return r100_gpu_cp_is_lockup(rdev, lockup, >cp);
> ?}
>
> ?int r600_asic_reset(struct radeon_device *rdev)
> --
> 1.7.1.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH] drm: Remove DRIVER_DATE and CORE_DATE

[Sedat Dilek]

DRIVER_DATE is not maintained or upgraded on changes in many drm drivers.

For example radeon has one DRIVER_DATE for User and Kernel ModeSetting
driver, this makes no sense as UMS and KMS driver have different versions.
And of course this all increases maintenance, too.
For radeon it is enough to bump {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
{KMS_}DRIVER_PATCHLEVEL defines.

Furthermore, I also removed CORE_DATE.

With radeon-KMS my dmesg looks now like this:

[   12.328937] [drm] Initialized drm 1.1.0
[   13.144019] [drm] Initialized radeon 2.8.0 for :01:00.0 on minor 0

Signed-off-by: Sedat Dilek 

Note: Tested with radeon RV250 (KMS) and linux-next (next-20101221).
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-Remove-DRIVER_DATE-and-CORE_DATE.patch
Type: plain/text
Size: 14543 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101222/df11c91d/attachment-0001.bin>

[Bug 32544] [r300g] LLVM support for software TLS implementation doesn't work

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32544

--- Comment #1 from Marek Ol??k  2010-12-22 10:22:58 PST 
---
I don't have a problem with r300g/LLVM.

Could you possibly bisect the issue on your machine?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Jesse Barnes]

On Wed, 22 Dec 2010 05:36:13 +0100
Mario Kleiner  wrote:

> > --
> >
> > Message: 1
> > Date: Mon, 20 Dec 2010 19:23:40 -0800
> > From: Keith Packard 
> > Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
> > To: Andy Lutomirski , Jesse Barnes
> > ,  Chris Wilson  > chris-wilson.co.uk>,
> > David Airlie 
> > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> > Message-ID: 
> > Content-Type: text/plain; charset="us-ascii"
> >
> > On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski   
> > wrote:
> >
> >> Enabling and disabling the vblank interrupt (on devices that
> >> support it) is cheap.  So disable it quickly after each
> >> interrupt.
> >
> > So, the concern (and reason for the original design) was that you  
> > might
> > lose count of vblank interrupts as vblanks are counted differently  
> > while
> > off than while on. If vblank interrupts get enabled near the interrupt
> > time, is it possible that you'll end up off by one somehow?
> >
> > Leaving them enabled for 'a while' was supposed to reduce the  
> > impact of
> > this potential error.
> >
> > -- 
> > keith.packard at intel.com
> > -- next part --
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: application/pgp-signature
> > Size: 189 bytes
> > Desc: not available
> > URL:  > 20101220/105a9fb6/attachment-0001.pgp>
> >
> > --
> >
> > Message: 2
> > Date: Mon, 20 Dec 2010 22:34:12 -0500
> > From: Andrew Lutomirski 
> > Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
> > To: Keith Packard 
> > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> > Message-ID:
> > 
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard   
> > wrote:
> >> On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski   
> >> wrote:
> >>
> >>> Enabling and disabling the vblank interrupt (on devices that
> >>> support it) is cheap. ?So disable it quickly after each
> >>> interrupt.
> >>
> >> So, the concern (and reason for the original design) was that you  
> >> might
> >> lose count of vblank interrupts as vblanks are counted differently  
> >> while
> >> off than while on. If vblank interrupts get enabled near the  
> >> interrupt
> >> time, is it possible that you'll end up off by one somehow?
> >
> > So the race is:
> >
> > 1. Vblank happens.
> > 2. vblank_get runs, reads hardware counter, and enables the interrupt
> > (and maybe not quite in that order)
> > 3. Interrupt fires and increments the counter.  Now the counter is  
> > one too high.
> >
> > What if we read the hardware counter from the IRQ the first time that
> > it fires after being enabled?  That way, if the hardware and software
> > counters match (mod 2^23 or whatever the magic number is), we don't
> > increment the counter.
> >
> >>
> >> Leaving them enabled for 'a while' was supposed to reduce the  
> >> impact of
> >> this potential error.
> >>
> >
> > Fair enough,
> >
> > But five seconds is a *long* time, and anything short enough that the
> > interrupt actually gets turned off in normal use risks the same race.
> >
> > --Andy
> >
> >
> > --
> >
> > Message: 3
> > Date: Mon, 20 Dec 2010 19:47:11 -0800
> > From: Keith Packard 
> > Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
> > To: Andrew Lutomirski 
> > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> > Message-ID: 
> > Content-Type: text/plain; charset="us-ascii"
> >
> > On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski  
> >  wrote:
> >
> >> But five seconds is a *long* time, and anything short enough that the
> >> interrupt actually gets turned off in normal use risks the same race.
> >
> > Right, so eliminating any race seems like the basic requirement. Can
> > that be done?
> >
> > -- 
> > keith.packard at intel.com
> > -- next part --
> > A non-text attachment was scrubbed...
> > Name: not available
> > Type: application/pgp-signature
> > Size: 189 bytes
> > Desc: not available
> > URL:  > 20101220/5ca3b674/attachment-0001.pgp>
> >
> > --
> >
> > Message: 4
> > Date: Mon, 20 Dec 2010 22:55:46 -0500
> > From: Andrew Lutomirski 
> > Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
> > To: Keith Packard 
> > Cc: intel-gfx at lists.freedesktop.org, dri-devel at lists.freedesktop.org
> > Message-ID:
> > 
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Mon, Dec 20, 2010 at 10:47 PM, Keith Packard   
> > wrote:
> >> On Mon, 20 Dec 2010 22:34:12 

drm-nvidia-switch git branch but still vgaswitcheroo not working for i915/nvidia (nouveau) on ASUS U30JC

[Giacomo]

Tried the branchdrm-nvidia-switch .
No way to make vgaswitcheroo work:

both

echo "DDIS" > /sys/kernel/debug/vgaswitcheroo/switch

and

echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch

hang the machine.

The first command hangs immediately, the second at X restart.

DMESG out in the first case:

Dec 21 22:46:10 daphne kernel: fbcon: Remapping primary device, fb0, to tty 1-63
Dec 21 22:46:10 daphne kernel: calling mux switch 0
Dec 21 22:46:10 daphne kernel: mux switched 0
Dec 21 22:46:10 daphne kernel: ACPI Error: Needed
[Buffer/String/Package], found [Integer] 880146f23420
(20101013/exresop-590)
Dec 21 22:46:10 daphne kernel: ACPI Exception: AE_AML_OPERAND_TYPE,
While resolving operands for [OpcodeName unavailable]
(20101013/dswexec-460)
Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution
failed [\_SB_.PCI0.GFX0._DSM] (Node 880147c6d1c8),
AE_AML_OPERAND_TYPE (20101013/psparse-537)
Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution
failed [\_SB_.PCI0.PEG1.GFX0._DSM] (Node 880147c83830),
AE_AML_OPERAND_TYPE (20101013/psparse-537)
Dec 21 22:46:10 daphne kernel: failed to evaluate _DSM: 12291
Dec 21 22:46:10 daphne kernel: vga_switcheroo: switching failed stage 2 12291

-- here need to press power button to force shutdown ---

Second case (echo "OFF"...):

Dec 21 22:43:44 daphne kernel: VGA switcheroo: switched nouveau off
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Disabling
fbcon acceleration...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Unpinning
framebuffer(s)...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Evicting buffers...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Idling channels...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Suspending
GPU objects...
Dec 21 22:43:45 daphne kernel: [drm] nouveau :01:00.0: And we're gone!
Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: PCI INT A disabled
Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: power state
changed by ACPI to D3

starting X hangs the machine immediately.

Let me know if I can help more.

Hope to hearing from you soon, Giacomo, Italy.

---
ASUS U30JC
Gentoo Linux.
x11-drivers/xf86-video-nouveau   0.0.16_pre20101130
* drm-nvidia-switch git branch (checkout on dec,22nd)


Giacomo Strangolino
Elettra Synchrotron Radiation Facility
Trieste, Italy


-- 
Giacomo S.
http://www.giacomos.it

- - - - - - - - - - - - - - - - - - - - - -

* iqfire-wall, un progetto
? open source che implementa un
? filtro di pacchetti di rete per Linux,
? e` disponibile per il download qui:
? http://sourceforge.net/projects/ipfire-wall

* Informazioni e pagina web ufficiale:
? http://www.giacomos.it/iqfire/index.html

- - - - - - - - - - - - - - - - - - - - - -

?. ''? `.
:?? :'? ? :
?`.? ` '
? ? `- Debian GNU/Linux -- The power of freedom
? ? ? ? http://www.debian.org

[PATCH] drm/radeon: Remove DRIVER_DATE for UMS and KMS

[Michel Dänzer]

On Mit, 2010-12-22 at 08:38 +0100, Sedat Dilek wrote: 
> 
> sorry, I still haven't setup a git-send-mail, thus sending the
> old-fashioned way as attached patch.

Your mailer might allow integrating the output of git format-patch into
the mail body directly instead.

> This patch (against linux-next) is overdue.
> 
> "DRIVER_DATE is not maintained or upgraded on changes.
> 
> Furthermore, one DRIVER_DATE for UMS and KMS makes no sense.
> It is enough to bump {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
> {KMS_}DRIVER_PATCHLEVEL defines."

What ends up being printed as the date in dmesg?


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH 0/9] TI DMM-TILER driver

[David Sin]

On Fri, Dec 17, 2010 at 09:28:07AM +1000, Dave Airlie wrote:
> On Fri, Dec 17, 2010 at 5:02 AM, David Sin  wrote:
> I get the impression with the ARM graphics, that you just have a lot
> of separate drivers for separate IP blocks all providing some misc
> random interfaces to userspace where some binary driver binds all the
> functionality together into a useful whole, which seems like a really
> bad design.
> 
> Generally on x86, the tiling hw is part of the GPU and is exposed as
> part of a coherent GPU driver.
> 
> I'm just wonder what the use-cases for this tiler are and what open
> apps can use it for?
> 
> Dave.
Yes -- on the omap4 soc, the dmm-tiler hw block is separate from the 
gpu.  I've had some, but not much, past discusions on hw designs 
where graphics/video related ip blocks are part of the same core.  It's 
a good point that you bring up and it certainly makes sense to me.  
I will bring it up with some omap hw folks that I know, and see if 
something that can be considered in future omap versions.

Some of the use-cases are HD video decoding and encoding.  Also, 
hi-res image capture -- I believe 12MP or greater.  OpenMax IL components 
and other multimedia frameworks can allocate video memory 
through a user space tiler library.  Thanks for your comments, Dave.  
-- 
David Sin

[Bug 28994] [r300c] [r300g] skybox in ut2004 is not seamless

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28994

?lmos  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||NOTOURBUG

--- Comment #13 from ?lmos  2010-12-22 07:27:54 PST ---
Today I had the chance to try it on a geforce fx5200 with the blob driver, and
the skybox is visible on the torlan level with usevbo=true; thus, it is a bug
in the game. Sorry for the false alarm.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

linux-next: Patchsets from Daniel Vetter (drm-next) and backlight-type patchset

[Sedat Dilek]

Hi,

last weekend I upgraded my toolchain and kernel-buildsystem and was
investigating the last days a known issue between systemd and
linux-next (which could be finally solved).

VERY slow scrolling on radeon graphics card: debugging a timing issue?

[Mark Hounschell]

On 12/22/2010 05:00 AM, Andrew Morton wrote:
> (cc dri-devel)
>
> On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev  wrote:
>
>   
>> Hello.
>>
>> A weird problem here, and I'm looking for help in
>> an attempt to solve it.
>>
>> Ever since KMS went into kernel and I tried turning
>> it on, the scrolling speed on the resulting "text"
>> console (with kms it works in one of graphics modes
>> hence "text" in quotes) become really _awful_.
>>
>> For example, running `dmesg' (which has ~2000 lines)
>> on the console takes about 2.5 _minutes_ (!) to
>> complete, -- which means the speed is about 10 lines
>> per second.  On an old notebook I have, with some also
>> nvidia card, the same operation completes in about
>> 0.8 sec.
>>
>> The lines goes up in a slow motion, I can watch every
>> new line appearing and scrolling.
>>
>> It was this way for a long time, and I almost gave up --
>> in X everything works ok, and in order to speed up
>> booting again I just added "quiet" option to the kernel
>> command line, to avoid scrolling of kernel messages.
>>
>> But yesterday I noticed something else entirely, which
>> make me hope the problem actually _can_ be solved.
>>
>> The thing is: that same scrolling becomes much faster
>> when I "do something" else while it scrolls up.  First
>> I noticed this when I wanted to switch to another vt
>> while it were scrolling -- I held down Ctrl key on my
>> keyboard, and out of the sudden the scroll speed up
>> dramatically.
>>
>> It turned out I can speed the thing to about 10 times
>> by generating some load: hit and hold a key on the
>> keyboard (generates interrupts?), run kernel compile
>> in the background (generates disk interrupts?), move
>> mouse...
>>
>> While doing "something", the same scrolling completes
>> in about 8 seconds instead of 2m30s.  Dramatic improvement.
>>
>> Now, when I hold a key or move mouse, the scrolling
>> is "jumpy" - sometimes it slows down back to original
>> "slow" form for a bit, and sometimes it jumps a few
>> lines in one go.
>>
>> I tried to disable cpufreq (selecting "performance"
>> governor) - this changes exactly nothing.
>>
>> Next someone suggested the "perf" tool.  And this one
>> is even more interesting: while `perf top' is running
>> (on another console or X), the scrolling is.. fast
>> again, as if I were moving my mouse!  Once I stop
>> `perf top', it becomes slow again.  So the bug
>> disappears while you watch it.
>>
>> And there I'm stuck again.  I asked in #radeon, but
>> there, Alex Deucher told me that he has no clue and
>> that the behavour is weird (it is weird indeed).
>>
>> Any hints on where to go from there are apprecated.
>>
>> The hardware is an AMD780g-based motherboard with
>> and Athlon CPU, I've seen the same behavour from
>> many other similar boards.  Kernels - all up to
>> the current 2.6.36.2, sine the old days when kms
>> for radeon first appeared in staging.
>>
>> I know kms/fbcon scrolling is slow on radeon because
>> it uses completely unoptimized bitblt routines (even
>> when the hw is pretty much capable of doing all that
>> stuff internally).  But what I see here is something
>> different - the 8 sec to scroll 2000 lines is the
>> result from the un-optimal bitblt, not the 2m30s.
>> 
>

I also see this very problem on several machines I have with radeon video.
For me the worst part is using vi in a konsole. Moving the cursor around
is so slow that I just can't use these machines directly and have to ssh
into them from another machine just to work on them.

I know its probably not proper to mention it, but when I run the ATI
proprietary
driver, that problem does go away. But for other reasons I can't use it.

Regards
Mark

No subject

attached setup.log), which I partly cherry-picked [1] or refreshed
against linux-next (next-20101217).
They worked also with yesterdays next-20101221.
I have attached a follow-up/fix-up patch for one of Daniel's patchsets.
(See below 
"danvet-drm-for-sedat-dilek-v2/0006-drm-nouveau-don-t-munge-in-drm_mm-internals-follow-u.patch")
All 3 patchsets tested with radeon RV250.

Also, I am highly interested in the backlight-type patches [4] (see
below P.S. and attached setup.log).
I have also refreshed them against linux-next (apply against
next-20101221), but tested with radeon-only.
These patches has still not entered platform-driver-x86/for-next.

I would like to see all 4 patchsets in linux-next (namely 2.6.38).
(I am using these patchsets for several weeks, I regularly check with
openarena and in a rough daily-work. YES, I am using the kernels I
built.).

What shall I do to help?
Where to send the refreshed patches?
Some patches from Daniel are complained by scripts/checkpatch.pl (IIRC
80 lines wrapping, etc.).
Approx before 14 days Dave OKed Daniels patchsets on an IRC conversation.

Kind Regards,
- Sedat -

[1] http://cgit.freedesktop.org/~danvet/drm/log/?h=for-sedat-dilek
[2] http://lists.freedesktop.org/archives/dri-devel/2010-November/005847.html
[3] http://lists.freedesktop.org/archives/dri-devel/2010-November/005859.html
[4] http://lists.freedesktop.org/archives/dri-devel/2010-November/005605.html

P.S.:

$ cd $HOME/src/linux-2.6/linux-2.6.37-rc6/debian/patches

$ cat series/2~next20101217.dileks.2
### FROM-DANVET #1
# Patches from 
# v2: 0001..0005 cherry-picked and 0006 is a follow-up patch to 0001
+ 
danvet-drm-for-sedat-dilek-v2/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
+ danvet-drm-for-sedat-dilek-v2/0002-drm-mm-track-free-areas-implicitly.patch
+ 
danvet-drm-for-sedat-dilek-v2/0003-drm-mm-extract-node-insert-helper-functions.patch
+ 
danvet-drm-for-sedat-dilek-v2/0004-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
+ 
danvet-drm-for-sedat-dilek-v2/0005-drm-mm-add-helper-to-unwind-scan-state.patch
+ 
danvet-drm-for-sedat-dilek-v2/0006-drm-nouveau-don-t-munge-in-drm_mm-internals-follow-u.patch

### FROM-DANVET #2
# Patches from 
# For more Details see

+ 
danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object-v2.patch
+ 
danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
+ 
danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch

### FROM-DANVET #3
# Patches from 
# For more Details see

+ 
danvet-radeon-asic-header-cleanup-2/1-7-radeon-consolidate-asic-specific-function-decls-for-pre-r600.patch
+ 
danvet-radeon-asic-header-cleanup-2/2-7-radeon-consolidate-asic-specific-function-decls-for-r600-later.patch
+ 
danvet-radeon-asic-header-cleanup-2/3-7-radeon-drop-extern-from-function-decls.patch
+ 
danvet-radeon-asic-header-cleanup-2/4-7-radeon-kill-decls-for-inline-functions.patch
+ 
danvet-radeon-asic-header-cleanup-2/5-7-radeon-move-blit-functions-to-radeon_asic.h.patch
+ danvet-radeon-asic-header-cleanup-2/6-7-radeon-kill-r100_io_-r-w-reg.patch
+ danvet-radeon-asic-header-cleanup-2/7-7-radeon-kill-rdev--pciep_-r-w-reg.patch

### DRM-RADEON-KMS-WRITEBACK
+ 
drm-radeon-kms-writeback/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch

### BACKLIGHT-TYPE
# Patches from 
# For more Details see

+ backlight-type/1-5-Backlight-Add-backlight-type-v2.patch
+ backlight-type/2-5-i915-Add-native-backlight-control-v2.patch
+ 
backlight-type/3-5-radeon-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch
+ 
backlight-type/4-5-nouveau-Change-the-backlight-parent-device-to-the-connector-not-the-PCI-dev-v2.patch
+ 
backlight-type/5-5-ACPI-Tie-ACPI-backlight-devices-to-PCI-devices-if-possible.patch

- EOT -

--0016364ef320c4c2860497f8bab4
Content-Type: text/x-log; charset=US-ASCII; 
name="setup_linux-next_next20101221.dileks.2.log"
Content-Disposition: attachment; 
filename="setup_linux-next_next20101221.dileks.2.log"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ghzr3s2v0

bWFrZSAtZiBkZWJpYW4vcnVsZXMucmVhbCBzZXR1cC1mbGF2b3VyIEFCSU5BTUU9JycgQVJDSD0n
aTM4NicgQ09NUElMRVI9J2djYy00LjUnIEZFQVRVUkVTRVQ9J25vbmUnIEZMQVZPVVI9JzY4Nicg
SU5JVFJEX0NNRD0ndXBkYXRlLWluaXRyYW1mcycgS0NPTkZJRz0nZGViaWFuL2NvbmZpZy9jb25m
aWcgZGViaWFuL2NvbmZpZy9rZXJuZWxhcmNoLXg4Ni9jb25maWcgZGViaWFuL2NvbmZpZy9rZXJu
ZWxhcmNoLXg4Ni9jb25maWctYXJjaC0zMiBkZWJpYW4vY29uZmlnL2kzODYvbm9uZS9jb25maWcu

Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> You need to read before replying.
>
> If the interface is a generic interface that any software can use then
> its fine, when the interface is a specific interface for a specific
> closed userspace driver it becomes questionable.
>
> Again you are thinking general case when we are talking specifics.

thank you for claryfing , and for your time, excuse me my ignorance.

i think main reason of my confusion is lack of clear specification
of the 'specifics'. discussion becomes plainly too complex
and same development goes - code and strategies are developed before
clarification of the specifics, then people try to explain how they
interpreted law, and start to correct themselves, trying to drag the line
to their side.

i think this wastes time of everyone , of which most loud group are 
users, and most opressed - developers, and excuse me i am making humorous 
comments to point that.

i also hope 3d drivers will finally be free, and not require people to use 
tools like hacked ndiswrapper.


-- 

Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

> you have two pieces of code, a userspace 3D *driver* (not
> application), and a kernel driver talking to the hw, if the userspace
> 3D driver cannot exist without the kernel driver, it could very well
> be considered a derivative work of the kernel driver. You are not
> protected by the standard Linux system call exception since it states
> "normal system calls", so adding a driver to the kernel to expose a
> bunch of driver specific ioctls to allow the userspace 3D work blurs
> the lines sufficiently that you are into the domain of derived works
> and should call your lawyers.

so any user-written (gpl compatible) driver which exposes new ioctls
which allow other software to work (i.e. network driver allowing closed
source software to send and recieve packets is illegal aswell?

it is getting confusing...

shall everyone hire lawyer prior to using any software under linux?

-- 

VERY slow scrolling on radeon graphics card: debugging a timing issue?

[Andrew Morton]

(cc dri-devel)

On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev  wrote:

> Hello.
> 
> A weird problem here, and I'm looking for help in
> an attempt to solve it.
> 
> Ever since KMS went into kernel and I tried turning
> it on, the scrolling speed on the resulting "text"
> console (with kms it works in one of graphics modes
> hence "text" in quotes) become really _awful_.
> 
> For example, running `dmesg' (which has ~2000 lines)
> on the console takes about 2.5 _minutes_ (!) to
> complete, -- which means the speed is about 10 lines
> per second.  On an old notebook I have, with some also
> nvidia card, the same operation completes in about
> 0.8 sec.
> 
> The lines goes up in a slow motion, I can watch every
> new line appearing and scrolling.
> 
> It was this way for a long time, and I almost gave up --
> in X everything works ok, and in order to speed up
> booting again I just added "quiet" option to the kernel
> command line, to avoid scrolling of kernel messages.
> 
> But yesterday I noticed something else entirely, which
> make me hope the problem actually _can_ be solved.
> 
> The thing is: that same scrolling becomes much faster
> when I "do something" else while it scrolls up.  First
> I noticed this when I wanted to switch to another vt
> while it were scrolling -- I held down Ctrl key on my
> keyboard, and out of the sudden the scroll speed up
> dramatically.
> 
> It turned out I can speed the thing to about 10 times
> by generating some load: hit and hold a key on the
> keyboard (generates interrupts?), run kernel compile
> in the background (generates disk interrupts?), move
> mouse...
> 
> While doing "something", the same scrolling completes
> in about 8 seconds instead of 2m30s.  Dramatic improvement.
> 
> Now, when I hold a key or move mouse, the scrolling
> is "jumpy" - sometimes it slows down back to original
> "slow" form for a bit, and sometimes it jumps a few
> lines in one go.
> 
> I tried to disable cpufreq (selecting "performance"
> governor) - this changes exactly nothing.
> 
> Next someone suggested the "perf" tool.  And this one
> is even more interesting: while `perf top' is running
> (on another console or X), the scrolling is.. fast
> again, as if I were moving my mouse!  Once I stop
> `perf top', it becomes slow again.  So the bug
> disappears while you watch it.
> 
> And there I'm stuck again.  I asked in #radeon, but
> there, Alex Deucher told me that he has no clue and
> that the behavour is weird (it is weird indeed).
> 
> Any hints on where to go from there are apprecated.
> 
> The hardware is an AMD780g-based motherboard with
> and Athlon CPU, I've seen the same behavour from
> many other similar boards.  Kernels - all up to
> the current 2.6.36.2, sine the old days when kms
> for radeon first appeared in staging.
> 
> I know kms/fbcon scrolling is slow on radeon because
> it uses completely unoptimized bitblt routines (even
> when the hw is pretty much capable of doing all that
> stuff internally).  But what I see here is something
> different - the 8 sec to scroll 2000 lines is the
> result from the un-optimal bitblt, not the 2m30s.
> 
> Thanks!
> 
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Freescale Linux BSP review

[Matt Sealey]

Okay I hereby refrain from legal comments.

In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).

-- 
Matt Sealey 
Product Development Analyst, Genesi USA, Inc.



On Tue, Dec 21, 2010 at 7:32 PM, Dave Airlie  wrote:
> On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey  wrote:
>> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann  wrote:
>>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
 On Mon, 20 Dec 2010, Alan Cox wrote:

 >> My point which people keep missing is that graphics stacks are a
 >> single entity, that span kernel and userspace, one cannot exist
 >> without the other, and there are interfaces that join them.
 >
 > As a copyright holder on the kernel I'll also remind the people concerned
 > that the definition of a derivative work is a legal not a technical one
 > and if the kernel and user space cannot be used except together and one
 > half depends on GPL elements I hope your lawyers have reviewed it
 > carefully. I have never given anyone permission to link my GPL kernel
 > contributions with anything but GPL code, modular or otherwise, except
 > according to the derivative work rules laid down by the GPL (and indeed
 > by the boundaries placed on copyright law).

 but it can be circumvented by writing GPL driver which will act as 'glue
 logic' inbetween userspace driver and which will work in kernel space?

 technically then driver would be GPL, except it's closed parts which will
 be ran in userspace... or can you forbid usage of certain closed userspace
 components with kernel?
>>>
>>> Anyone can try shipping this and risk a lawsuit, and all copyright holders
>>> of the kernel can try suing people that distribute such code. Most sensible
>>> people stay out of both the shipping questionable code and the suing part,
>>> but apparently the entire mobile phone industry is already doing both, so
>>> we can just wait and see if anyone has deep enough pockets to bring this
>>> up in court first ;-).
>>
>> Nobody will because it is unenforcable.
>>
>> The GPLv2 is written such that the "if you're interfacing the kernel
>> or compiler you don't need to opensource that bit with your app"
>> clause can actually be manipulated to basically disavow closed source
>> code from having to be published as open source if it interfaces with
>> the standard operating system components. It is meant to protect
>> software developers from having to bundle a gigabyte of kernel and
>> compiler code with their 100 line app that uses an ioctl, but legally
>> it works against ?the GPL in this way. It is what means AMD, nVidia,
>> Intel (hi Alan), and others can produce binary code and binary
>> executables that run on opensource kernels (wireless regulatory daemon
>> in the early days) basically with impunity.
>>
>> You may think it's a horrible idea, and from a technical perspective
>> it is, but from a legal perspective.. it's not a problem.
>
> You should probably refrain from stating legal opinions around here,
> Alan stated there is a possible issue legally and you should talk to
> lawyers. I find his reasoning to be sane but no idea if its legal. The
> point you are missing (you seem to not think much before typing) is
> this:
>
> you have two pieces of code, a userspace 3D *driver* (not
> application), and a kernel driver talking to the hw, if the userspace
> 3D driver cannot exist without the kernel driver, it could very well
> be considered a derivative work of the kernel driver. You are not
> protected by the standard Linux system call exception since it states
> "normal system calls", so adding a driver to the kernel to expose a
> bunch of driver specific ioctls to allow the userspace 3D work blurs
> the lines sufficiently that you are into the domain of derived works
> and should call your lawyers.
>
>
>>
>> Frankly, this discussion (besides the sidetrack to the non-existant
>> legal issues) did pop up a major problem in the possibility of
>> unifying the IPU, dual GPU and other graphics subsystem frameworks on
>> the i.MX processor line, and potentially others too (TI's LCDC and PVR
>> graphics) in that DRM/DRI security policy will forbid them (in the
>> form of David Arlie complaining) from sharing the same memory area,
>> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
>> acceleration and DMA between the units requires bounce buffers and
>> some overly complicated memory copying between memory areas for them
>> to interoperate. I think TI hit this problem trying to get a texture
>> from the DSP to the GPU to render it to a texture and came up with an
>> awful (closed source :) method of ioctls and so on to achieve it. I
>> had an idea to solve it using DRM and GEM but it's been shot down in
>> concept now... what's the point? It'll never get into mainline.
>
> I never 

[Bug 25422] nouveau fails to build on ia64

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=25422


Ben Hutchings  changed:

   What|Removed |Added

 Blocks||21782




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 25422] New: nouveau fails to build on ia64

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=25422

   Summary: nouveau fails to build on ia64
   Product: Drivers
   Version: 2.5
Kernel Version: 2.6.37-rc5
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: ben at decadent.org.uk
Regression: Yes


Created an attachment (id=41242)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=41242)
patch for nouveau Kconfig

If CONFIG_ACPI is enabled, CONFIG_NOUVEAU selects CONFIG_ACPI_VIDEO.
However, CONFIG_ACPI_VIDEO depends on more than just CONFIG_ACPI, and in
particular will never be set on ia64.

Previously reported with patch at


-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] drm: Remove DRIVER_DATE and CORE_DATE

[Sedat Dilek]

DRIVER_DATE is not maintained or upgraded on changes in many drm drivers.

For example radeon has one DRIVER_DATE for User and Kernel ModeSetting
driver, this makes no sense as UMS and KMS driver have different versions.
And of course this all increases maintenance, too.
For radeon it is enough to bump {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
{KMS_}DRIVER_PATCHLEVEL defines.

Furthermore, I also removed CORE_DATE.

With radeon-KMS my dmesg looks now like this:

[   12.328937] [drm] Initialized drm 1.1.0
[   13.144019] [drm] Initialized radeon 2.8.0 for :01:00.0 on minor 0

Signed-off-by: Sedat Dilek sedat.di...@gmail.com

Note: Tested with radeon RV250 (KMS) and linux-next (next-20101221).


0001-drm-Remove-DRIVER_DATE-and-CORE_DATE.patch
Description: plain/text
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: Remove DRIVER_DATE for UMS and KMS

[Sedat Dilek]

2010/12/22 Michel Dänzer mic...@daenzer.net:
 On Mit, 2010-12-22 at 08:38 +0100, Sedat Dilek wrote:

 sorry, I still haven't setup a git-send-mail, thus sending the
 old-fashioned way as attached patch.

 Your mailer might allow integrating the output of git format-patch into
 the mail body directly instead.

 This patch (against linux-next) is overdue.

 DRIVER_DATE is not maintained or upgraded on changes.

 Furthermore, one DRIVER_DATE for UMS and KMS makes no sense.
 It is enough to bump {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
 {KMS_}DRIVER_PATCHLEVEL defines.

 What ends up being printed as the date in dmesg?


This patch was not complete.
I could start with KMS-enabled into runlevel-3 (IIRC version of radeon
with (null) in brackets), when wanting to startx, machine died with a
error-message.

I have sent a new patch [PATCH] drm: Remove DRIVER_DATE and
CORE_DATE (see [1]), which works as expected.

- Sedat -

[1] http://lists.freedesktop.org/archives/dri-devel/2010-December/006586.html

P.S.:

$ dmesg | egrep -i 'drm|radeon|kms|modeset|frame buffer'
[0.00] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.37-rc6-686
root=UUID=1ceb69a7-ecf4-47e9-a231-b74e0f0a9b62 ro init=/bin/systemd
radeon.modeset=1 lapic 3
[   12.328937] [drm] Initialized drm 1.1.0
[   12.818330] [drm] radeon kernel modesetting enabled.
[   12.818500] radeon :01:00.0: power state changed by ACPI to D0
[   12.818540] radeon :01:00.0: power state changed by ACPI to D0
[   12.818587] radeon :01:00.0: PCI INT A - Link[LNKA] - GSI 11
(level, low) - IRQ 11
[   12.826296] [drm] initializing kernel modesetting (RV250
0x1002:0x4C66).
[   12.841960] [drm] register mmio base: 0xC010
[   12.842001] [drm] register mmio size: 65536
[   12.842524] radeon :01:00.0: putting AGP V2 device into 4x mode
[   12.842587] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF
[   12.842630] radeon :01:00.0: VRAM: 128M 0xE000 -
0xE7FF (64M used)
[   12.842694] [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
[   12.842731] [drm] Driver supports precise vblank timestamp query.
[   12.842785] [drm] radeon: irq initialized.
[   12.845300] [drm] Detected VRAM RAM=128M, BAR=128M
[   12.845342] [drm] RAM width 128bits DDR
[   12.848233] [drm] radeon: 64M of VRAM memory ready
[   12.848273] [drm] radeon: 256M of GTT memory ready.
[   12.850055] radeon :01:00.0: WB enabled
[   12.850766] [drm] Loading R200 Microcode
[   12.969090] [drm] radeon: ring at 0xD0001000
[   12.969152] [drm] ring test succeeded in 1 usecs
[   12.969481] [drm] radeon: ib pool ready.
[   12.970156] [drm] ib test succeeded in 0 usecs
[   12.971841] [drm] Panel ID String: SXGA+ Single (85MHz)
[   12.971878] [drm] Panel Size 1400x1050
[   12.983044] [drm] radeon legacy LVDS backlight initialized
[   12.983737] [drm] No TV DAC info found in BIOS
[   12.983862] [drm] Radeon Display Connectors
[   12.983897] [drm] Connector 0:
[   12.983929] [drm]   VGA
[   12.983963] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[   12.984013] [drm]   Encoders:
[   12.984046] [drm] CRT1: INTERNAL_DAC1
[   12.984080] [drm] Connector 1:
[   12.984112] [drm]   DVI-D
[   12.984144] [drm]   HPD1
[   12.984177] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[   12.984212] [drm]   Encoders:
[   12.984245] [drm] DFP1: INTERNAL_TMDS1
[   12.984278] [drm] Connector 2:
[   12.984310] [drm]   LVDS
[   12.984342] [drm]   Encoders:
[   12.984374] [drm] LCD1: INTERNAL_LVDS
[   12.984407] [drm] Connector 3:
[   12.984439] [drm]   S-video
[   12.984471] [drm]   Encoders:
[   12.984503] [drm] TV1: INTERNAL_DAC2
[   12.992152] [drm] radeon: power management initialized
[   13.038149] [drm] fb mappable at 0xE004
[   13.038188] [drm] vram apper at 0xE000
[   13.038221] [drm] size 5914624
[   13.038254] [drm] fb depth is 24
[   13.038286] [drm]pitch is 5632
[   13.108205] Console: switching to colour frame buffer device 175x65
[   13.143219] fb0: radeondrmfb frame buffer device
[   13.143386] drm: registered panic notifier
[   13.144019] [drm] Initialized radeon 2.8.0 for :01:00.0 on minor 0

- EOT -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25422] nouveau fails to build on ia64

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=25422


Rafael J. Wysocki r...@sisk.pl changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r...@sisk.pl
 Resolution||PATCH_ALREADY_AVAILABLE




--- Comment #1 from Rafael J. Wysocki r...@sisk.pl  2010-12-22 12:19:26 ---
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41242
Handled-By : Ben Hutchings b...@decadent.org.uk

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Recover DPMS properly after XRandr re-enablement

[Chris Wilson]

From: Takashi Iwai ti...@suse.de

When the output is turned off via xrandr --off and re-enabled again
with the same mode, drm doesn't reset DPMS, thus it results in a black
screen.  A typical example is something like:

 % xrandr --output LVDS1 --mode 1024x768
 % xrandr --output VGA1 --mode 1024x768
 % xrandr --output LVDS1 --off
 % xrandr --output LVDS1 --mode 1024x768

Also, there is another problem with DPMS: the sysfs entries don't
match with the actual state.  In the case above, LVDS1 shows always
Off, while VGA1 shows On.

A part of the cause is that there are (still) two places to keep
the actual DPMS values.  In dpms field of drm_connector and in the
device property.  Thus we need to sync between them.

Another problem is that the DPMS state is always set to ON forcibly
in drm_crtc_helper_set_config() (via commit
bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f).  This results in another
inconsistency.  For recovering the DPMS, we need to set DPMS actaully
ON there.

This patch adds a new helper function to manage the drm_connector
DPMS so that it can be called commonly in both places.

Signed-off-by: Takashi Iwai ti...@suse.de
---
 drivers/gpu/drm/drm_crtc.c|   25 ++---
 drivers/gpu/drm/drm_crtc_helper.c |7 ---
 include/drm/drm_crtc.h|1 +
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2baa670..3a58337 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2383,6 +2383,18 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+int drm_connector_set_dpms(struct drm_connector *connector, int mode)
+{
+   if (connector-funcs-dpms)
+   (*connector-funcs-dpms)(connector, mode);
+   connector-dpms = mode;
+   drm_connector_property_set_value(connector,
+
connector-dev-mode_config.dpms_property,
+mode);
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_set_dpms);
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -2440,15 +2452,14 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
 
/* Do DPMS ourselves */
if (property == connector-dev-mode_config.dpms_property) {
-   if (connector-funcs-dpms)
-   (*connector-funcs-dpms)(connector, (int) 
out_resp-value);
+   drm_connector_set_dpms(connector, (int) out_resp-value);
ret = 0;
-   } else if (connector-funcs-set_property)
+   } else if (connector-funcs-set_property) {
ret = connector-funcs-set_property(connector, property, 
out_resp-value);
-
-   /* store the property value if successful */
-   if (!ret)
-   drm_connector_property_set_value(connector, property, 
out_resp-value);
+   /* store the property value if successful */
+   if (!ret)
+   drm_connector_property_set_value(connector, property, 
out_resp-value);
+   }
 out:
mutex_unlock(dev-mode_config.mutex);
return ret;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index bede10a..fee755d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -669,9 +669,10 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
}
DRM_DEBUG_KMS(Setting connector DPMS state to on\n);
for (i = 0; i  set-num_connectors; i++) {
-   DRM_DEBUG_KMS(\t[CONNECTOR:%d:%s] set DPMS on\n, 
set-connectors[i]-base.id,
- drm_get_connector_name(set-connectors[i]));
-   set-connectors[i]-dpms = DRM_MODE_DPMS_ON;
+   struct drm_connector *connector = set-connectors[i];
+   DRM_DEBUG_KMS(\t[CONNECTOR:%d:%s] set DPMS on\n, 
connector-base.id,
+ drm_get_connector_name(connector));
+   drm_connector_set_dpms(connector, DRM_MODE_DPMS_ON);
}
 
kfree(save_connectors);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 029aa68..c9a5a80 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -676,6 +676,7 @@ extern void drm_mode_set_crtcinfo(struct drm_display_mode 
*p,
 extern void drm_mode_connector_list_update(struct drm_connector *connector);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
struct edid *edid);
+extern int drm_connector_set_dpms(struct drm_connector *connector, int mode);
 extern int drm_connector_property_set_value(struct drm_connector *connector,
 struct drm_property *property,
   

Re: [PATCH] drm: Recover DPMS properly after XRandr re-enablement

[Chris Wilson]

On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson ch...@chris-wilson.co.uk 
wrote:
 From: Takashi Iwai ti...@suse.de

 This patch adds a new helper function to manage the drm_connector
 DPMS so that it can be called commonly in both places.
 
 Signed-off-by: Takashi Iwai ti...@suse.de

FWIW,

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] TI DMM-TILER driver

[David Sin]

On Fri, Dec 17, 2010 at 09:28:07AM +1000, Dave Airlie wrote:
 On Fri, Dec 17, 2010 at 5:02 AM, David Sin david...@ti.com wrote:
 I get the impression with the ARM graphics, that you just have a lot
 of separate drivers for separate IP blocks all providing some misc
 random interfaces to userspace where some binary driver binds all the
 functionality together into a useful whole, which seems like a really
 bad design.
 
 Generally on x86, the tiling hw is part of the GPU and is exposed as
 part of a coherent GPU driver.
 
 I'm just wonder what the use-cases for this tiler are and what open
 apps can use it for?
 
 Dave.
Yes -- on the omap4 soc, the dmm-tiler hw block is separate from the 
gpu.  I've had some, but not much, past discusions on hw designs 
where graphics/video related ip blocks are part of the same core.  It's 
a good point that you bring up and it certainly makes sense to me.  
I will bring it up with some omap hw folks that I know, and see if 
something that can be considered in future omap versions.
 
Some of the use-cases are HD video decoding and encoding.  Also, 
hi-res image capture -- I believe 12MP or greater.  OpenMax IL components 
and other multimedia frameworks can allocate video memory 
through a user space tiler library.  Thanks for your comments, Dave.  
-- 
David Sin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 28994] [r300c] [r300g] skybox in ut2004 is not seamless

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=28994

Álmos aaalmo...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||NOTOURBUG

--- Comment #13 from Álmos aaalmo...@gmail.com 2010-12-22 07:27:54 PST ---
Today I had the chance to try it on a geforce fx5200 with the blob driver, and
the skybox is visible on the torlan level with usevbo=true; thus, it is a bug
in the game. Sorry for the false alarm.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon/kms: fix bug in r600_gpu_is_lockup

[Jerome Glisse]

On Tue, Dec 21, 2010 at 4:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
 We were using the lockup struct from the wrong union.

 Signed-off-by: Alex Deucher alexdeuc...@gmail.com
 Cc: Jerome Glisse jgli...@redhat.com
Reviewed-by: Jerome Glisse jgli...@redhat.com

 ---
  drivers/gpu/drm/radeon/r600.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
 index 2078108..292b282 100644
 --- a/drivers/gpu/drm/radeon/r600.c
 +++ b/drivers/gpu/drm/radeon/r600.c
 @@ -1345,13 +1345,19 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
        u32 srbm_status;
        u32 grbm_status;
        u32 grbm_status2;
 +       struct r100_gpu_lockup *lockup;
        int r;

 +       if (rdev-family = CHIP_RV770)
 +               lockup = rdev-config.rv770.lockup;
 +       else
 +               lockup = rdev-config.r600.lockup;
 +
        srbm_status = RREG32(R_000E50_SRBM_STATUS);
        grbm_status = RREG32(R_008010_GRBM_STATUS);
        grbm_status2 = RREG32(R_008014_GRBM_STATUS2);
        if (!G_008010_GUI_ACTIVE(grbm_status)) {
 -               r100_gpu_lockup_update(rdev-config.r300.lockup, rdev-cp);
 +               r100_gpu_lockup_update(lockup, rdev-cp);
                return false;
        }
        /* force CP activities */
 @@ -1363,7 +1369,7 @@ bool r600_gpu_is_lockup(struct radeon_device *rdev)
                radeon_ring_unlock_commit(rdev);
        }
        rdev-cp.rptr = RREG32(R600_CP_RB_RPTR);
 -       return r100_gpu_cp_is_lockup(rdev, rdev-config.r300.lockup, 
 rdev-cp);
 +       return r100_gpu_cp_is_lockup(rdev, lockup, rdev-cp);
  }

  int r600_asic_reset(struct radeon_device *rdev)
 --
 1.7.1.1

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Chris Wilson]

On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
 The commit 448f53a1ede54eb854d036abf54573281412d650
   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
 
 causes a regression on a SandyBridge machine here.
 The laptop display (LVDS) becomes blank.  Reverting the commit fixes
 the problem.

The question is whose BIOS is wrong? The Lenovo U160's or the
Sandybridge SDV? And why does it work for that other OS? Insert
rhetorical question of the day here.

It's back to the square one for one or the other platform...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Jesse Barnes]

On Wed, 22 Dec 2010 05:36:13 +0100
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:

  --
 
  Message: 1
  Date: Mon, 20 Dec 2010 19:23:40 -0800
  From: Keith Packard kei...@keithp.com
  Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
  To: Andy Lutomirski l...@mit.edu, Jesse Barnes
  jbar...@virtuousgeek.org, Chris Wilson ch...@chris-wilson.co.uk,
  David Airlie airl...@linux.ie
  Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
  Message-ID: yunfwtrrepv@aiko.keithp.com
  Content-Type: text/plain; charset=us-ascii
 
  On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu  
  wrote:
 
  Enabling and disabling the vblank interrupt (on devices that
  support it) is cheap.  So disable it quickly after each
  interrupt.
 
  So, the concern (and reason for the original design) was that you  
  might
  lose count of vblank interrupts as vblanks are counted differently  
  while
  off than while on. If vblank interrupts get enabled near the interrupt
  time, is it possible that you'll end up off by one somehow?
 
  Leaving them enabled for 'a while' was supposed to reduce the  
  impact of
  this potential error.
 
  -- 
  keith.pack...@intel.com
  -- next part --
  A non-text attachment was scrubbed...
  Name: not available
  Type: application/pgp-signature
  Size: 189 bytes
  Desc: not available
  URL: http://lists.freedesktop.org/archives/dri-devel/attachments/ 
  20101220/105a9fb6/attachment-0001.pgp
 
  --
 
  Message: 2
  Date: Mon, 20 Dec 2010 22:34:12 -0500
  From: Andrew Lutomirski l...@mit.edu
  Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
  To: Keith Packard kei...@keithp.com
  Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
  Message-ID:
  aanlktik-1zni1dds6i+1aroenx6p=9jqaaia6t5ug...@mail.gmail.com
  Content-Type: text/plain; charset=ISO-8859-1
 
  On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard kei...@keithp.com  
  wrote:
  On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu  
  wrote:
 
  Enabling and disabling the vblank interrupt (on devices that
  support it) is cheap. ?So disable it quickly after each
  interrupt.
 
  So, the concern (and reason for the original design) was that you  
  might
  lose count of vblank interrupts as vblanks are counted differently  
  while
  off than while on. If vblank interrupts get enabled near the  
  interrupt
  time, is it possible that you'll end up off by one somehow?
 
  So the race is:
 
  1. Vblank happens.
  2. vblank_get runs, reads hardware counter, and enables the interrupt
  (and maybe not quite in that order)
  3. Interrupt fires and increments the counter.  Now the counter is  
  one too high.
 
  What if we read the hardware counter from the IRQ the first time that
  it fires after being enabled?  That way, if the hardware and software
  counters match (mod 2^23 or whatever the magic number is), we don't
  increment the counter.
 
 
  Leaving them enabled for 'a while' was supposed to reduce the  
  impact of
  this potential error.
 
 
  Fair enough,
 
  But five seconds is a *long* time, and anything short enough that the
  interrupt actually gets turned off in normal use risks the same race.
 
  --Andy
 
 
  --
 
  Message: 3
  Date: Mon, 20 Dec 2010 19:47:11 -0800
  From: Keith Packard kei...@keithp.com
  Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
  To: Andrew Lutomirski l...@mit.edu
  Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
  Message-ID: yunbp4frdmo@aiko.keithp.com
  Content-Type: text/plain; charset=us-ascii
 
  On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski  
  l...@mit.edu wrote:
 
  But five seconds is a *long* time, and anything short enough that the
  interrupt actually gets turned off in normal use risks the same race.
 
  Right, so eliminating any race seems like the basic requirement. Can
  that be done?
 
  -- 
  keith.pack...@intel.com
  -- next part --
  A non-text attachment was scrubbed...
  Name: not available
  Type: application/pgp-signature
  Size: 189 bytes
  Desc: not available
  URL: http://lists.freedesktop.org/archives/dri-devel/attachments/ 
  20101220/5ca3b674/attachment-0001.pgp
 
  --
 
  Message: 4
  Date: Mon, 20 Dec 2010 22:55:46 -0500
  From: Andrew Lutomirski l...@mit.edu
  Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
  To: Keith Packard kei...@keithp.com
  Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
  Message-ID:
  aanlktimk6rlkr8lt76cr8nclw_3kax6dqa+=id9_g...@mail.gmail.com
  Content-Type: text/plain; charset=ISO-8859-1
 
  On Mon, Dec 20, 2010 at 10:47 PM, Keith Packard kei...@keithp.com  
  wrote:
  On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski  
  

drm-nvidia-switch git branch but still vgaswitcheroo not working for i915/nvidia (nouveau) on ASUS U30JC

[Giacomo]

Tried the branchdrm-nvidia-switch .
No way to make vgaswitcheroo work:

both

echo DDIS  /sys/kernel/debug/vgaswitcheroo/switch

and

echo OFF  /sys/kernel/debug/vgaswitcheroo/switch

hang the machine.

The first command hangs immediately, the second at X restart.

DMESG out in the first case:

Dec 21 22:46:10 daphne kernel: fbcon: Remapping primary device, fb0, to tty 1-63
Dec 21 22:46:10 daphne kernel: calling mux switch 0
Dec 21 22:46:10 daphne kernel: mux switched 0
Dec 21 22:46:10 daphne kernel: ACPI Error: Needed
[Buffer/String/Package], found [Integer] 880146f23420
(20101013/exresop-590)
Dec 21 22:46:10 daphne kernel: ACPI Exception: AE_AML_OPERAND_TYPE,
While resolving operands for [OpcodeName unavailable]
(20101013/dswexec-460)
Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution
failed [\_SB_.PCI0.GFX0._DSM] (Node 880147c6d1c8),
AE_AML_OPERAND_TYPE (20101013/psparse-537)
Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution
failed [\_SB_.PCI0.PEG1.GFX0._DSM] (Node 880147c83830),
AE_AML_OPERAND_TYPE (20101013/psparse-537)
Dec 21 22:46:10 daphne kernel: failed to evaluate _DSM: 12291
Dec 21 22:46:10 daphne kernel: vga_switcheroo: switching failed stage 2 12291

-- here need to press power button to force shutdown ---

Second case (echo OFF...):

Dec 21 22:43:44 daphne kernel: VGA switcheroo: switched nouveau off
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Disabling
fbcon acceleration...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Unpinning
framebuffer(s)...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Evicting buffers...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Idling channels...
Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Suspending
GPU objects...
Dec 21 22:43:45 daphne kernel: [drm] nouveau :01:00.0: And we're gone!
Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: PCI INT A disabled
Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: power state
changed by ACPI to D3

starting X hangs the machine immediately.

Let me know if I can help more.

Hope to hearing from you soon, Giacomo, Italy.

---
ASUS U30JC
Gentoo Linux.
x11-drivers/xf86-video-nouveau   0.0.16_pre20101130
* drm-nvidia-switch git branch (checkout on dec,22nd)


Giacomo Strangolino
Elettra Synchrotron Radiation Facility
Trieste, Italy


-- 
Giacomo S.
http://www.giacomos.it

- - - - - - - - - - - - - - - - - - - - - -

* iqfire-wall, un progetto
  open source che implementa un
  filtro di pacchetti di rete per Linux,
  e` disponibile per il download qui:
  http://sourceforge.net/projects/ipfire-wall

* Informazioni e pagina web ufficiale:
  http://www.giacomos.it/iqfire/index.html

- - - - - - - - - - - - - - - - - - - - - -

 . ''  `.
:   :'    :
 `.  ` '
    `- Debian GNU/Linux -- The power of freedom
        http://www.debian.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 09:51, Matt Sealey m...@genesi-usa.com wrote:
 Okay I hereby refrain from legal comments.

 In any case, this code has passed legal at Freescale and AMD *AND*
 Qualcomm. It would not be GPL if it has not been vetted (and it took
 them a year to get to this point).

It appears that this discussion ended up on phoronix.com [1], with an
air of hostility towards Genesi and Matt for no good reason.

I don't know whose idea was that, but it's certainly of very bad taste
and helps very little to the discussion. Matt poses real questions and
issues we -as a company producing ARM products- face all the time.
Admittedly the technical reasons for not including the kernel-space
driver into mainline presented by Dave Airlie are correct and very
down-to-earth. But IMHO, *this* should be the starting point to
continue the discussion, instead of immediately rejecting this driver.
Is there *any* way that problem posed by Dave could be solved, perhaps
by throwing the ball to the ARM vendor companies to provide just a
small extra part of the code needed to do API checks and therefore
ensuring the kernel guys CAN actually do their work as they like?

As for the philosophical problems, well, I'm sure everyone here
understands that the situation of ARM graphics in the kernel is in no
way comparable to Intel or Nvidia/ATI chipsets, they had totally
different starting points. ARM came from the embedded market where it
thrived for many years with the exact same licensing rules that we all
would like to abolish in just a few months, where at the same time we
swallowed the fact that it took Intel and ATI/AMD - forget nvidia,
nv-obfuscated driver IN the kernel for YEARS? really? - many years to
accept mainline opensource development. And even Intel with all their
experience made a complete mess of things using the latest cpus.

I *really* do appreciate Linaro and the effort from ARM and the
relevant vendors towards open source enablement, and Genesi has proven
that by donating ~50 ARM based netbooks and smarttops to Linaro
developers at lin...@uds -and around ~40 units to other projects
including Debian and Gentoo -and we intend to give more in the future.
We know the process and how it works, just as well as everyone here
does actually. But we also have to be pragmatic. An ARM based
solution/product with no long-term support from the kernel side will
find it very hard to survive indeed. I strongly believe that, half a
solution is better than no solution, and it can also serve a purpose
until a proper full solution appears. It also does show a leap of good
faith from the FOSS side, and one which ARM companies will have to
follow soon.

So, if by chance anyone really expects ARM licensees to do 180 degrees
change in philosophy overnight, I obviously cannot speak for them, but
IMHO, that is not bound to happen. It will probably happen in a few
years but only by discussion and collaboration, seriously not by
dealing with absolutes. Denying even the smallest step backwards from
the side of the FOSS community is not a victory, it's a downright
failure of the community side to actively support and push ARM -based
devices as an alternative Linux desktop and portable solutions
(netbook etc).

My 2c.

Konstantinos

[1]: http://www.phoronix.com/scan.php?page=news_itempx=ODk0NA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VERY slow scrolling on radeon graphics card: debugging a timing issue?

[Mark Hounschell]

On 12/22/2010 05:00 AM, Andrew Morton wrote:
 (cc dri-devel)

 On Mon, 20 Dec 2010 23:58:21 +0300 Michael Tokarev m...@tls.msk.ru wrote:

   
 Hello.

 A weird problem here, and I'm looking for help in
 an attempt to solve it.

 Ever since KMS went into kernel and I tried turning
 it on, the scrolling speed on the resulting text
 console (with kms it works in one of graphics modes
 hence text in quotes) become really _awful_.

 For example, running `dmesg' (which has ~2000 lines)
 on the console takes about 2.5 _minutes_ (!) to
 complete, -- which means the speed is about 10 lines
 per second.  On an old notebook I have, with some also
 nvidia card, the same operation completes in about
 0.8 sec.

 The lines goes up in a slow motion, I can watch every
 new line appearing and scrolling.

 It was this way for a long time, and I almost gave up --
 in X everything works ok, and in order to speed up
 booting again I just added quiet option to the kernel
 command line, to avoid scrolling of kernel messages.

 But yesterday I noticed something else entirely, which
 make me hope the problem actually _can_ be solved.

 The thing is: that same scrolling becomes much faster
 when I do something else while it scrolls up.  First
 I noticed this when I wanted to switch to another vt
 while it were scrolling -- I held down Ctrl key on my
 keyboard, and out of the sudden the scroll speed up
 dramatically.

 It turned out I can speed the thing to about 10 times
 by generating some load: hit and hold a key on the
 keyboard (generates interrupts?), run kernel compile
 in the background (generates disk interrupts?), move
 mouse...

 While doing something, the same scrolling completes
 in about 8 seconds instead of 2m30s.  Dramatic improvement.

 Now, when I hold a key or move mouse, the scrolling
 is jumpy - sometimes it slows down back to original
 slow form for a bit, and sometimes it jumps a few
 lines in one go.

 I tried to disable cpufreq (selecting performance
 governor) - this changes exactly nothing.

 Next someone suggested the perf tool.  And this one
 is even more interesting: while `perf top' is running
 (on another console or X), the scrolling is.. fast
 again, as if I were moving my mouse!  Once I stop
 `perf top', it becomes slow again.  So the bug
 disappears while you watch it.

 And there I'm stuck again.  I asked in #radeon, but
 there, Alex Deucher told me that he has no clue and
 that the behavour is weird (it is weird indeed).

 Any hints on where to go from there are apprecated.

 The hardware is an AMD780g-based motherboard with
 and Athlon CPU, I've seen the same behavour from
 many other similar boards.  Kernels - all up to
 the current 2.6.36.2, sine the old days when kms
 for radeon first appeared in staging.

 I know kms/fbcon scrolling is slow on radeon because
 it uses completely unoptimized bitblt routines (even
 when the hw is pretty much capable of doing all that
 stuff internally).  But what I see here is something
 different - the 8 sec to scroll 2000 lines is the
 result from the un-optimal bitblt, not the 2m30s.
 


I also see this very problem on several machines I have with radeon video.
For me the worst part is using vi in a konsole. Moving the cursor around
is so slow that I just can't use these machines directly and have to ssh
into them from another machine just to work on them.

I know its probably not proper to mention it, but when I run the ATI
proprietary
driver, that problem does go away. But for other reasons I can't use it.

Regards
Mark
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[David Rusling]

Konstantinos,
thanks, I agree with your thoughts.   My approach has been to accept 
small steps in the right direction and encourage reasoned discussion.   I also 
think that Linaro's main function is as a place where all the moving parts can 
collaborate.Right now, the GPU 'problem' is that of getting both open 
source and proprietary pieces of the BSPs to work really well together in 
products.   That's really the focus of the Graphics WGs and the partner landing 
teams.   This is a heavy lifting engineering job, and it will take time, but 
everyone is willing and hopeful of good results.Doing this will also help 
us have a reasoned discussion about where the open source and proprietary 
boundaries make sense.

Now for a bit of a rant.   Personally, I have a deep and abiding 
respect for open source (for me, it's the key social invention of the internet 
age), however I also recognise that it would not exist without companies using 
open source as part of their products.Let's face it, an awful lot of open 
source engineers are getting their mortgages paid by companies that make use of 
open source. No company invests in open source for philanthropic reasons; 
they understand that it is necessary for their businesses.The tricky 
problem is always in how ethical a company's usage is (and I use the word 
'ethical' deliberately because this is wider than mere legal words smithing); 
whenever I give talks on GPL, I emphasise both the moral as well as the legal 
duties.In my experience, most companies struggle to understand open source 
when they first start to interact with it.   It usually takes some open source 
zealots within the company to persuade their management of the right 
 way to behave.   The best way to get companies to change their behaviour is to 
find them and support them.  Making threatening GPL noises in email does not 
help them in any way.

Dave


David Rusling, CTO
http://www.linaro.org

Linaro
Lockton House
Clarendon Rd
Cambridge
CB2 8FH




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Takashi Iwai]

At Wed, 22 Dec 2010 16:59:06 +,
Chris Wilson wrote:
 
 On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
  The commit 448f53a1ede54eb854d036abf54573281412d650
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
  
  causes a regression on a SandyBridge machine here.
  The laptop display (LVDS) becomes blank.  Reverting the commit fixes
  the problem.
 
 The question is whose BIOS is wrong? The Lenovo U160's or the
 Sandybridge SDV? And why does it work for that other OS? Insert
 rhetorical question of the day here.
 
 It's back to the square one for one or the other platform...

Yeah, we can blame BIOS :)  And, this is likely the BIOS on my machine
here that is broken.

But this seems like an issue that you can't rely solely on VBT.  We
can never guarantee that BIOS is correct (who can?), and there is no
way to avoid this change as long as it's hard-coded.  We've hit
another regression by VBT check (e-DP  wrongly detected; kernel bug
24822), so I think judging the behavior only from BIOS is rather
dangerous.


thanks,

Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, David Rusling wrote:

   Now for a bit of a rant.  Personally, I have a deep and abiding 
 respect for open source (for me, it's the key social invention of the 
 internet age), however I also recognise that it would not exist 
 without companies using open source as part of their products.  Let's 
 face it, an awful lot of open source engineers are getting their 
 mortgages paid by companies that make use of open source.

I cannot be in full agreement with the above statement.  I think the 
reality is way more nuanced than that.

The truth of the matter is that Open Source came into existence without 
and despite involvement from the corporate world.  And the very reason 
it started to attract interest from the corporate world is because of 
Open Source's superior quality and performance at a lower cost.  Open 
Source would have existed even without companies using it as you would 
still have those Open Source activists using it themselves in your 
product, even without the help of the corporate money. The company 
involvement in Open Source did indeed accelerate its development by 
paying many people to work on it full time.  But Open Source would still 
be there and still be in good shape even if corporate involvement didn't 
happen, just like it was before.

And this superior quality and performance characteristics of Open Source 
are not a coincidence.  They are the first motives in a world which is 
not driven by monetary profits, unlike most if not all the proprietary 
alternatives.  The people leading Open Source are driven by the 
technical excellence of their work and the recognition they get from 
their peers.  Money is a far secondary motive, and in this age you can 
choose between different sources of sufficient money not to have to 
worry about it anymore and compromise too much on your primary motives 
when you already have a track record in this Open Source world.

So to say that the corporate world might need to consider Open Source to 
be competitive and survive, but the reverse is not true i.e. Open Source 
doesn't _require_ the corporate world to survive.

 No company invests in open source for philanthropic reasons; they 
 understand that it is necessary for their businesses.  The tricky 
 problem is always in how ethical a company's usage is (and I use the 
 word 'ethical' deliberately because this is wider than mere legal 
 words smithing); whenever I give talks on GPL, I emphasise both the 
 moral as well as the legal duties.  In my experience, most companies 
 struggle to understand open source when they first start to interact 
 with it.  It usually takes some open source zealots within the company 
 to persuade their management of the right way to behave.  The best way 
 to get companies to change their behaviour is to find them and support 
 them.  Making threatening GPL noises in email does not help them in 
 any way.

Here I'm more in agreement with you.  However this is again not the full 
picture.

Ethical or not, the first motive of a company is to make profits.  If 
that was easy to get away with it, all that companies would do is simply 
to grab this body of source code for themselves and never contribute 
back. And a sizable number of companies, even some sizable companies, 
are doing just that.  While this isn't going to kill Open Source, this 
certainly makes it weaker because this is contrary to that very first 
principle that made Open Source a success in the first place.  
Companies doing that are after the immediate monetary profit and not the 
technical excellence and performances.

But even when leaving the ethical aspect aside, it is not going to be 
profitable for companies in the long term to grab Open Source results 
and move it back to the legacy proprietary model.  Doing that will be to 
their disadvantage when some other companies come along to compete on 
the market using Open Source to its fullest technical excellence and 
performance potential.  Fortunately, a sizable number of companies, even 
sizable ones, did understand that already.

But... while some companies are struggling to understand how to interact 
with Open Source, the Open Source world still dash ahead without much 
concerns for corporate profits.  As said above, those strange Open 
Source animals are motivated by the technical excellence of their work, 
and they're going to fight on that front against anything that might 
affect or prevent that goal.  This is again why Open Source has always 
progressed even despite initial attempts to kill it from some 
corporations.  So far, Linux has always been immune to monetary forces, 
whether those forces were against it or not. So it is fair to say that 
Open Source survival depends primarily on its technical advantages above 
anything else.

In conclusion: don't get surprised if technically inferior propositions, 
such as proprietary 3D libraries coupled with kernel-side interfaces, 
are met with strong or even vehement 

[Bug 32544] [r300g] LLVM support for software TLS implementation doesn't work

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32544

--- Comment #1 from Marek Olšák mar...@gmail.com 2010-12-22 10:22:58 PST ---
I don't have a problem with r300g/LLVM.

Could you possibly bisect the issue on your machine?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Tom Gall wrote:

 The very important part of this whole discussion is getting arm Linux and it's
 3d driver situation so it TOO is the best.
 
 Right now it's not and pointing to other elements of the system and saying
 it's great is besides the point.

My whole point, if I may resume my conclusion to a few words, is that 
most Open Source folks don't care if you can't open your code for 
whatever reasons.  That won't encourage them to compromise on their 
fundamental principle.  It's up to those companies to balance the cost 
of maintaining their ad hoc proprietary stuff themselves vs the cost of 
opening up their code so it can be merged upstream.

 This discussion is good, but for it to have a positive outcome, we need to
 turn the direction back to how we get to the end goal
 for arm 3D graphics.

Absolutely!

 It's not probably going to happen at once with one patch that does 
 what everyone wants. I think it's going to take graduated steps and 
 some compromises.

Yes.  However, as I said, those compromises may not come on the 
technical aspects of the kernel interfaces.  Just like it is unlikely 
for companies to ever compromise on their profits.  Any compromise 
touching any of those fundamental aspects for their respective parties 
is bound to always fail.

In other words, let's save ourselves some energy and give up on the idea 
that a kernel shim only for a binary only user space library is going to 
ever be accepted in mainline.  This simply will never happen, period.


Nicolas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Jerome Glisse]

On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 22 December 2010 09:51, Matt Sealey m...@genesi-usa.com wrote:
 Okay I hereby refrain from legal comments.

 In any case, this code has passed legal at Freescale and AMD *AND*
 Qualcomm. It would not be GPL if it has not been vetted (and it took
 them a year to get to this point).

 It appears that this discussion ended up on phoronix.com [1], with an
 air of hostility towards Genesi and Matt for no good reason.

 I don't know whose idea was that, but it's certainly of very bad taste
 and helps very little to the discussion. Matt poses real questions and
 issues we -as a company producing ARM products- face all the time.
 Admittedly the technical reasons for not including the kernel-space
 driver into mainline presented by Dave Airlie are correct and very
 down-to-earth. But IMHO, *this* should be the starting point to
 continue the discussion, instead of immediately rejecting this driver.
 Is there *any* way that problem posed by Dave could be solved, perhaps
 by throwing the ball to the ARM vendor companies to provide just a
 small extra part of the code needed to do API checks and therefore
 ensuring the kernel guys CAN actually do their work as they like?

It's not enough to provide a toy program/library that just call into
the new kernel API, you really need to provide a full open source use
case that does achieve somethings using the new kernel API you are
introducing. It's the only way we can possibly evaluate the new API.

Open source GPU kernel API are a pain to design and i can tell you
that if i had liberty to change them i would do that a lot until
finding the best one (nouveau is in happy situation here and they are
more than right to wait until they are completely satisfied with the
API before freezing it).

 As for the philosophical problems, well, I'm sure everyone here
 understands that the situation of ARM graphics in the kernel is in no
 way comparable to Intel or Nvidia/ATI chipsets, they had totally
 different starting points. ARM came from the embedded market where it
 thrived for many years with the exact same licensing rules that we all
 would like to abolish in just a few months, where at the same time we
 swallowed the fact that it took Intel and ATI/AMD - forget nvidia,
 nv-obfuscated driver IN the kernel for YEARS? really? - many years to
 accept mainline opensource development. And even Intel with all their
 experience made a complete mess of things using the latest cpus.

No body is saying AMD or Intel were fast to jump into open source,
doesn't mean that ARM ecosystem can't do it faster than AMD or Intel
did.

 I *really* do appreciate Linaro and the effort from ARM and the
 relevant vendors towards open source enablement, and Genesi has proven
 that by donating ~50 ARM based netbooks and smarttops to Linaro
 developers at lin...@uds -and around ~40 units to other projects
 including Debian and Gentoo -and we intend to give more in the future.
 We know the process and how it works, just as well as everyone here
 does actually. But we also have to be pragmatic. An ARM based
 solution/product with no long-term support from the kernel side will
 find it very hard to survive indeed. I strongly believe that, half a
 solution is better than no solution, and it can also serve a purpose
 until a proper full solution appears. It also does show a leap of good
 faith from the FOSS side, and one which ARM companies will have to
 follow soon.

 So, if by chance anyone really expects ARM licensees to do 180 degrees
 change in philosophy overnight, I obviously cannot speak for them, but
 IMHO, that is not bound to happen. It will probably happen in a few
 years but only by discussion and collaboration, seriously not by
 dealing with absolutes. Denying even the smallest step backwards from
 the side of the FOSS community is not a victory, it's a downright
 failure of the community side to actively support and push ARM -based
 devices as an alternative Linux desktop and portable solutions
 (netbook etc).

 My 2c.


Cheers,
Jerome Glisse
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

So to say that the corporate world might need to consider Open Source to
be competitive and survive, but the reverse is not true i.e. Open Source
doesn't _require_ the corporate world to survive.


i agree with it fully, and to support this claim i want to remind the
simple rule of capital accumulation. Open Source community
_already_ accumulated enough _capital_ in form of algorithms, 
implementations, social relations, experience, documentation and

augmentation with education system .

it can survive just fine without corporate world, while
logical relationship with organisations whole main purpose of existence
is creating profit, is to gain profit from such relationship itself.
otherwise it would be bit like Faust would just give his soul away 
completely free... and everyone knows it's not the point while dealing 
with devil.


i also understand reluctance of some people about such deals -
despite huge gains , one can loose very important things,
and end up escaping from small print obligations.
sometimes it is better to make slower, but steady progress instead.

greetings.
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 20:39, Piotr Gluszenia Slawinski
curi...@bwv190.internetdsl.tpnet.pl wrote:
 So to say that the corporate world might need to consider Open Source to
 be competitive and survive, but the reverse is not true i.e. Open Source
 doesn't _require_ the corporate world to survive.

 i agree with it fully, and to support this claim i want to remind the
 simple rule of capital accumulation. Open Source community
 _already_ accumulated enough _capital_ in form of algorithms,
 implementations, social relations, experience, documentation and
 augmentation with education system .

I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
thrive and make a difference in the world without the corporate world?
Definitely not. If you only care about the former that's fine, but
have no illusion that we would even be having this discussion here
were it not for the corporate world caring about Linux on ARM.

Konstantinos
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:

 On 22 December 2010 20:39, Piotr Gluszenia Slawinski
 curi...@bwv190.internetdsl.tpnet.pl wrote:
  So to say that the corporate world might need to consider Open Source to
  be competitive and survive, but the reverse is not true i.e. Open Source
  doesn't _require_ the corporate world to survive.
 
  i agree with it fully, and to support this claim i want to remind the
  simple rule of capital accumulation. Open Source community
  _already_ accumulated enough _capital_ in form of algorithms,
  implementations, social relations, experience, documentation and
  augmentation with education system .
 
 I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
 thrive and make a difference in the world without the corporate world?
 Definitely not. If you only care about the former that's fine, but
 have no illusion that we would even be having this discussion here
 were it not for the corporate world caring about Linux on ARM.

Maybe.  But corporations so far have played by the Open Source rules to 
make ARM Linux what it is.  There was mutual benefits in that and ARM 
Linux did grew faster.

Having accommodations in the kernel for proprietary drivers is not a 
mutual benefit anymore.  That might be hard to understand from your 
point of view, but the incentives in the Open Source communities aren't 
based on commercial results.


Nicolas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #8 from Alex Deucher ag...@yahoo.com 2010-12-22 11:26:01 PST ---
Created an attachment (id=41376)
 View: https://bugs.freedesktop.org/attachment.cgi?id=41376
 Review: https://bugs.freedesktop.org/review?bug=32556attachment=41376

add new pll flag

This patch adds a new pll flag to prefer slightly higher frequencies if the
target clock cannot be hit exactly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #9 from Alex Deucher ag...@yahoo.com 2010-12-22 11:28:24 PST ---
With the patch from comment 8, try these possible fixes:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..0be8015 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
(rdev-family == CHIP_RS690) ||
(rdev-family == CHIP_RS740))
pll-flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-  RADEON_PLL_PREFER_CLOSEST_LOWER);
+  RADEON_PLL_PREFER_CLOSEST_HIGHER);

if (ASIC_IS_DCE32(rdev)  mode-clock  20)/*
range limits??? */
pll-flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

Or:

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..91facc8 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
(rdev-family == CHIP_RS690) ||
(rdev-family == CHIP_RS740))
pll-flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
-  RADEON_PLL_PREFER_CLOSEST_LOWER);
+  RADEON_PLL_NO_ODD_POST_DIV);

if (ASIC_IS_DCE32(rdev)  mode-clock  20)/*
range limits??? */
pll-flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Konstantinos Margaritis]

On 22 December 2010 21:22, Nicolas Pitre nicolas.pi...@linaro.org wrote:
 Having accommodations in the kernel for proprietary drivers is not a
 mutual benefit anymore.  That might be hard to understand from your
 point of view, but the incentives in the Open Source communities aren't
 based on commercial results.

DISCLAIMER: I'm also a Debian developer -have been since 1999 with a
small 2y break- so I _do_ know the F/OSS community point of view. My
goals have been always in promoting open source and free software
solutions when and when not available. Right now open source solutions
are _not_ available, and that is the problem.

I haven't reversed engineered any driver so I can't claim of knowledge in this
matter. However I've been following closely other such projects like nouveau
and it took them a _long_ time to get to this point here -which may be usable
for many people, but it's not even at a beta state according to the Nouveau
developers. Even if we assume the fact that 10 times more ARM F/OSS
developers gather to reverse engineer the binary blobs, how long do you think
it would take until a beta driver appears? 1 year? 2 years? And what will happen
in the meantime?

I'm not advocating that closed source drivers be included in the
kernel, but IMHO,
having an open kernel-space driver would also help the reverse engineering
process at the same time as allowing common users as well as developers to
use and test any 3D applications -don't forget that 3D problems don't
end at the driver,
rather the opposite.

Konstantinos
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Dave Airlie]

 I'm not advocating that closed source drivers be included in the
 kernel, but IMHO,
 having an open kernel-space driver would also help the reverse engineering
 process at the same time as allowing common users as well as developers to
 use and test any 3D applications -don't forget that 3D problems don't
 end at the driver,
 rather the opposite.

Again thats a short-term view. So we spend the effort to clean up the open
kernel code, but the vendors want to keep the interface to userspace the
same so the binary modules can keep functioning? How do we clean up
insanities in the interfaces? How do we optimise the stack going forward?

Having the code in mainline won't help anyone who is any good at
reverse engineering.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

On 22 December 2010 20:39, Piotr Gluszenia Slawinski
curi...@bwv190.internetdsl.tpnet.pl wrote:

So to say that the corporate world might need to consider Open Source to
be competitive and survive, but the reverse is not true i.e. Open Source
doesn't _require_ the corporate world to survive.


i agree with it fully, and to support this claim i want to remind the
simple rule of capital accumulation. Open Source community
_already_ accumulated enough _capital_ in form of algorithms,
implementations, social relations, experience, documentation and
augmentation with education system .


I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually
thrive and make a difference in the world without the corporate world?
Definitely not. If you only care about the former that's fine, but
have no illusion that we would even be having this discussion here
were it not for the corporate world caring about Linux on ARM.


survive, and serve. despite corporate entities, opensource projects
do not just cease to exist once markets cut the profit down.
this is where corporations loose big time in comparison to opensource.

thrive? come on, discussion starts about small, insignificant toys, and
i repeat - insignificant toys. talking big about '3d in linux'
as any priority sounds funny in world in which 99% of the tcp/ip routing 
is performed by opensource-based solutions, at both enterprise , and
'home' scale. while opensource display system has enough proprietary 
alternatives to choose from at low cost, point of developing it lies

far beyond just cutting few pennies for ... toys. this can be done
without opensource at all.

talking about opensource unable to survive without care of corporate world 
is also funny. current opensource politics allowed such growth thanx to

proper politics when it came to dealing with corporate world. without
opensource certain solutions would never propagate and become 
cost-effective to gain enough markets. so profit opensource gained from it

is fair-earned, and comes from market itself, not from corporate world
attitude. in other words - if certain corporations would not partake 
certain attitude, it would be done by other ones, or certain products 
would just never existed.


still _opensource_ would be same good as before, 
as notice development of certain algorithms and code was conducted in 
parallel, and also sponsored by university environments for solely 
research and educational purposes (to exclude any opensource-ideology 
driven motives) .


my 2 eurocents ;)
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Piotr Gluszenia Slawinski]

it would take until a beta driver appears? 1 year? 2 years? And what will happen
in the meantime?


plainly.some other company will take over the market, and sell products 
with open drivers available.

in meantime arm devices can still be used for i.e. dataloggers, especially
without linux support their market price drops significantly.

i really see no big deal here. it happened before with nvidia -
don't you recall how much their hardware lost in it's value ?
upgraded cards were given-away as buggy and unsupported in linux,
and had very short-life in 2nd hand market.
compare it to i.e. SGI machines which are still circulating and are 
valued, even though their opensource support is actually not so brilliant, 
and hardware performance even worse...


nowadays companies like ARM are again fishing in the same market - people 
who once invested big bucks in nvidia, are now thinking twice.
and it's not really related with opensource - notice how many unsatisfied 
customers turned away from _proprietary_ solutions , tired with messy 
service packs, remote exploits, long-uncorrected bugs, and dropping of 
support for whole OS solutions, leaving users with expensive support 
options and unstable systems behind.


i think if new ARM/freescale products will not have decent opensource 
support now, they will not only loose opensource market, but will not get 
the profit from proprietary market basing on previous 'success' of 
similiar solutions due fact users simply learnt their lesson.



--

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30131] Command Conquer 3 crashes with r300g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30131

--- Comment #6 from Martin Stolpe martinsto...@gmail.com 2010-12-22 12:47:13 
PST ---
Created an attachment (id=41378)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41378)
wine output

Unfortunately this is still a problem with the latest mesa git.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks

[Mario Kleiner]

On Dec 22, 2010, at 6:23 PM, Jesse Barnes wrote:


On Wed, 22 Dec 2010 05:36:13 +0100
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:

 
--


Message: 1
Date: Mon, 20 Dec 2010 19:23:40 -0800
From: Keith Packard kei...@keithp.com
Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
To: Andy Lutomirski l...@mit.edu, Jesse Barnes
	jbar...@virtuousgeek.org,	Chris Wilson ch...@chris- 
wilson.co.uk,

David Airlie airl...@linux.ie
Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID: yunfwtrrepv@aiko.keithp.com
Content-Type: text/plain; charset=us-ascii

On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu
wrote:


Enabling and disabling the vblank interrupt (on devices that
support it) is cheap.  So disable it quickly after each
interrupt.


So, the concern (and reason for the original design) was that you
might
lose count of vblank interrupts as vblanks are counted differently
while
off than while on. If vblank interrupts get enabled near the  
interrupt

time, is it possible that you'll end up off by one somehow?

Leaving them enabled for 'a while' was supposed to reduce the
impact of
this potential error.

--
keith.pack...@intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.freedesktop.org/archives/dri-devel/attachments/
20101220/105a9fb6/attachment-0001.pgp

--

Message: 2
Date: Mon, 20 Dec 2010 22:34:12 -0500
From: Andrew Lutomirski l...@mit.edu
Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
To: Keith Packard kei...@keithp.com
Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID:
aanlktik-1zni1dds6i+1aroenx6p=9jqaaia6t5ug...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 20, 2010 at 10:23 PM, Keith Packard kei...@keithp.com
wrote:

On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu
wrote:


Enabling and disabling the vblank interrupt (on devices that
support it) is cheap. ?So disable it quickly after each
interrupt.


So, the concern (and reason for the original design) was that you
might
lose count of vblank interrupts as vblanks are counted differently
while
off than while on. If vblank interrupts get enabled near the
interrupt
time, is it possible that you'll end up off by one somehow?


So the race is:

1. Vblank happens.
2. vblank_get runs, reads hardware counter, and enables the  
interrupt

(and maybe not quite in that order)
3. Interrupt fires and increments the counter.  Now the counter is
one too high.

What if we read the hardware counter from the IRQ the first time  
that
it fires after being enabled?  That way, if the hardware and  
software

counters match (mod 2^23 or whatever the magic number is), we don't
increment the counter.



Leaving them enabled for 'a while' was supposed to reduce the
impact of
this potential error.



Fair enough,

But five seconds is a *long* time, and anything short enough that  
the
interrupt actually gets turned off in normal use risks the same  
race.


--Andy


--

Message: 3
Date: Mon, 20 Dec 2010 19:47:11 -0800
From: Keith Packard kei...@keithp.com
Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
To: Andrew Lutomirski l...@mit.edu
Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID: yunbp4frdmo@aiko.keithp.com
Content-Type: text/plain; charset=us-ascii

On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski
l...@mit.edu wrote:

But five seconds is a *long* time, and anything short enough  
that the
interrupt actually gets turned off in normal use risks the same  
race.


Right, so eliminating any race seems like the basic requirement. Can
that be done?

--
keith.pack...@intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.freedesktop.org/archives/dri-devel/attachments/
20101220/5ca3b674/attachment-0001.pgp

--

Message: 4
Date: Mon, 20 Dec 2010 22:55:46 -0500
From: Andrew Lutomirski l...@mit.edu
Subject: Re: [Intel-gfx] [PATCH] drm: Aggressively disable vblanks
To: Keith Packard kei...@keithp.com
Cc: intel-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID:
aanlktimk6rlkr8lt76cr8nclw_3kax6dqa+=id9_g...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Dec 20, 2010 at 10:47 PM, Keith Packard kei...@keithp.com
wrote:

On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski
l...@mit.edu wrote:


But five seconds is a *long* time, and anything short enough that
the
interrupt actually gets turned off in normal use risks the same
race.


Right, so eliminating any race seems like the 

[Bug 30131] Command Conquer 3 crashes with r300g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30131

--- Comment #7 from Marek Olšák mar...@gmail.com 2010-12-22 13:21:40 PST ---
The game should not crash the X server. If it does, you are probably using
indirect rendering, which might happen with 32-bit apps on x86_64 systems.
Indirect rendering is buggy, slow, contains only a subset of features r300g
offers, and gets very little testing AFAIK. So please make sure the game uses
direct rendering. I should mention that using a 32-bit system may help.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #10 from Gildas Le Nadan 3ntr0...@gmail.com 2010-12-22 13:45:40 
PST ---
Created an attachment (id=41379)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41379)
patch+RADEON_PLL_PREFER_CLOSEST_HIGHER

registers for kms with new pll patch applied + RADEON_PLL_PREFER_CLOSEST_HIGHER

Screen flickers slightly less than previously but is still unusable

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32556] screen flickers all the time with desktop image appearing only briefly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=32556

--- Comment #11 from Gildas Le Nadan 3ntr0...@gmail.com 2010-12-22 13:47:35 
PST ---
Created an attachment (id=41380)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=41380)
patch + RADEON_PLL_NO_ODD_POST_DIV

registers for kms with new pll patch applied + RADEON_PLL_NO_ODD_POST_DIV

Screen flickers slightly less than without patch but is still unusable

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Xavier Bestel]

Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
 It is 
 not economically viable for the Open Source community to accommodate 
 proprietary drivers, irrespective of how loud you might advocate for 
 that.

I think you can remove the word economically from your sentence (or
replace it with e.g. technically), and it's all the more true.

Xav

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Freescale Linux BSP review

[Nicolas Pitre]

On Thu, 23 Dec 2010, Xavier Bestel wrote:

 Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
  It is 
  not economically viable for the Open Source community to accommodate 
  proprietary drivers, irrespective of how loud you might advocate for 
  that.
 
 I think you can remove the word economically from your sentence (or
 replace it with e.g. technically), and it's all the more true.

I used that word on purpose. Economic principles do exist in the Open 
Source world too.  It is just not based on monetary profits.


Nicolas___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
 The commit 448f53a1ede54eb854d036abf54573281412d650
   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks

 causes a regression on a SandyBridge machine here.
 The laptop display (LVDS) becomes blank.  Reverting the commit fixes
 the problem.

 The question is whose BIOS is wrong?

I don't think so.

 The Lenovo U160's or the
 Sandybridge SDV? And why does it work for that other OS? Insert
 rhetorical question of the day here.

Quite frankly, I don't think the question should *ever* be whose BIOS
is wrong?

You should always take for granted that the BIOS is wrong. It's not a
question of blame the BIOS, it's a question of facts of life.

It's 100% pointless to point fingers and say the HP BIOS is wrong or
the Lenovo BIOS is wrong. Buggy BIOSes happen. ALWAYS. Any code that
relies on the BIOS to such a degree that it either works or not based
on it is by definition broken.

Why does that code need to figure out some LVDS clock from the BIOS?
Why can't the code look at the actual hardware state or similar, since
presumably the screen is on after boot. THAT we can rely on, since a
BIOS that doesn't initialize LVDS is not going to ever ship even as
pre-release.

Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Peter Stuge]

Linus Torvalds wrote:
 You should always take for granted that the BIOS is wrong.

Better yet, that there is no BIOS. Maybe one happy day, in the future.


//Peter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Dave Airlie]

On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
 On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai ti...@suse.de wrote:
 The commit 448f53a1ede54eb854d036abf54573281412d650
   drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks

 causes a regression on a SandyBridge machine here.
 The laptop display (LVDS) becomes blank.  Reverting the commit fixes
 the problem.

 The question is whose BIOS is wrong?

 I don't think so.

                         The Lenovo U160's or the
 Sandybridge SDV? And why does it work for that other OS? Insert
 rhetorical question of the day here.

 Quite frankly, I don't think the question should *ever* be whose BIOS
 is wrong?

 You should always take for granted that the BIOS is wrong. It's not a
 question of blame the BIOS, it's a question of facts of life.

 It's 100% pointless to point fingers and say the HP BIOS is wrong or
 the Lenovo BIOS is wrong. Buggy BIOSes happen. ALWAYS. Any code that
 relies on the BIOS to such a degree that it either works or not based
 on it is by definition broken.

 Why does that code need to figure out some LVDS clock from the BIOS?
 Why can't the code look at the actual hardware state or similar, since
 presumably the screen is on after boot. THAT we can rely on, since a
 BIOS that doesn't initialize LVDS is not going to ever ship even as
 pre-release.


I've no idea but since this is spread-spectrum related the bios may not enable
spread-spectrum on the panel, though really the question is as always, what does
Windows do.

Dave.
                        Linus
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VERY slow scrolling on radeon graphics card: debugging a timing issue?

[Michel Dänzer]

On Mit, 2010-12-22 at 05:55 -0500, Mark Hounschell wrote: 
 
 I also see this very problem on several machines I have with radeon video.
 For me the worst part is using vi in a konsole. Moving the cursor around
 is so slow that I just can't use these machines directly and have to ssh
 into them from another machine just to work on them.

That's not the same problem as the one described by Michael, which is
about the console on virtual terminals different from X.

For your problem, try choosing a different font (a fontconfig one
instead of a legacy X one) in konsole.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel