date:20110524

Re: i915 and boot freeze

2011-05-24 Thread Jean Delvare

Hi Yermandu,

Please pay attention when writing and proofread yourself before
sending. You certainly meant i915, not i195, in the subject line. I've
fixed it. This is important if you want to get the attention of the
relevant maintainers and developers.

On Mon, 23 May 2011 19:33:15 -0300, Yermandu Patapitafious wrote:
> since kernel .39 i can not boot, when kernel go to gmbus start the issue.
> I try capture a dump with kexec, but no success, so i have the idea to
> make video booting,
> kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem.

What is the last kernel that works for you?

Are you running self-built or distribution kernels?

Can we please see the kernel configuration file? You seem to have
verbose debugging options enabled (CONFIG_DEBUG_KOBJECT at least.) it
makes the logs harder to read.

> http://www.vimeo.com/24138372

Unfortunately the beginning is pretty hard to read. It would be great
if you were able to get us the kernel logs in a text form, using some
form of serial console.

I see references to i2c_for_each_dev, a new function which only i2c-dev
and i2c-core are using at the moment. So if you have CONFIG_I2C_CHARDEV
set, and this is a self-built kernel, try again without it just to get
it out of the picture.

Note that logs from a pure 2.6.39 kernel would probably be more useful
than from a later git snapshot. The 2.6.40 development branch is very
young and could have other problems.

Alternatively, if you are familiar with git, a git bisection would help
too.

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

Re: (Short?) merge window reminder

2011-05-24 Thread Arnd Bergmann

On Tuesday 24 May 2011, Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
> 
> Because of our historical even/odd model, I wouldn't do a 2.7.x -
> there's just too much history of 2.1, 2.3, 2.5 being development
> trees. But if I do 3.0, then I'd be chucking that whole thing out the
> window, and the next release would be 3.1, 3.2, etc..

I like that. While I don't really care if you call it 2.7, 2.8 or 3.0
(or 4.0 even, if you want to keep continuity following .38 and .39),
the current 2.5/2.6 numbering cycle is almost 10 years old and has
obviously lost all significance.

The only reason I can see that would make it worthwhile waiting for
is if the enterprise and embedded people were to decide on a common
longterm kernel and call that e.g. 2.7.x or 2.8.x while you continue with
2.9.x or 3.0.x or 3.x. My impression is however that the next longterm
release is still one or two years away, so probably not worth waiting
for and hard to estimate in advance.

> Because all our releases are supposed to be stable releases these
> days, and if we get rid of one level of numbering, I feel perfectly
> fine with getting rid of the even/odd history too.

We still have stable and unstable releases, except that you call the
unstable ones -rcX and they are all nice and short, unlike the infamous
2.1.xxx series ;-)

IMHO simply changing the names from 2.6.40-rcX to 2.7.X and from
2.6.40.X to 2.6.8.X etc would be the most straightforward change
if you want to save the 3.0 release for a special moment.

Enough bike shedding from my side, please just make a decision.

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

[git pull] drm pull for gardenshed-rc1

2011-05-24 Thread Dave Airlie


Hi Linus,

core: updates for 30-bit color
intel: Ivybridge support + hopeful rc6 support
nouveau: rewritten engine support for adding PCOPY engine
radeon: Displayport overhaul for pending Llano APU along with more cayman 
and fusion fixes.

There is also a platform/x86 driver for the MXM GPU standard for allowing 
switchable graphics support on nvidia hw, Matthew has acked it coming via 
my tree. Also the VGA ARB is now smarter about devices hiding behind 
bridges.

Dave.

The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e:

  Linux 2.6.39-rc6 (2011-05-03 19:59:13 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (31):
  drm/radeon/kms: remove some underscan leftovers
  drm/radeon/kms: add support for thermal chips on combios asics
  drm/radeon/kms: set i2c adapter class to I2C_CLASS_DDC
  drm/radeon/kms: fix up r1xx-rs4xx i2c buses
  drm/radeon/kms: fix some logic errors in combios i2c mapping
  drm/radeon/kms: DCE4.1 DIG encoders are fully routeable just like DCE3.2
  drm/radeon/kms: properly handle bpc >8 in atom command tables
  drm/radeon/kms: spread spectrum fixes
  drm/radeon/kms: fix up DP clock programming on DCE4/5
  drm/radeon/kms: adjust eDP handling (v2)
  drm/radeon/kms: fix eDP panel power function
  drm/radeon/kms: make sure eDP panel is on for modesetting
  drm/radeon/kms: add some dp encoder/connector helper funcs
  drm/radeon/kms: improve DP detect logic
  drm/radeon/kms: improve aux error handling
  drm/radeon/kms: handle DP bridges
  drm/dp: add some new DP regs for DP 1.2
  drm/radeon/kms: atombios.h updates for DP panel mode
  drm/radeon/kms/atom: add support for setting DP panel mode
  drm/radeon/kms: rewrite DP handling
  drm/radeon/kms: simplify hotplug handler logic
  drm/radeon/kms: bail early for eDP in hotplug callback
  drm/radeon/kms: fixup eDP connector handling
  drm/radeon/kms: properly set the CLK_REF bit for DCE3 devices
  drm/radeon/kms: the SS_Id field in the LCD table if for LVDS only
  drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when 
asked
  drm/radeon/kms: fix typo in spread spectrum code
  drm/radeon/kms/cayman: fix typo in register mask
  drm/radeon/kms/atom: move dig phy init out of modesetting
  drm/radeon/kms: properly set num banks for fusion asics
  drm/radeon/kms: bump kms version number

Alex Williamson (2):
  vga_switcheroo: Remove unbalanced pci_enable_device
  drm/i915/lvds: Only act on lid notify when the device is on

Andrew Morton (1):
  drivers/gpu/drm/radeon/atom.c: fix warning

Ben Skeggs (43):
  drm/nvc0: more vm fault engines
  drm/nvc0: more vm fault reasons
  drm/nvc0: decode gpc/hubclient on vm fault
  drm/nouveau: use static vidshift of 2 on volt 0x30 tables
  drm/nouveau: move engine object creation into per-engine hooks
  drm/nouveau: remove some unused members from dev_priv
  drm/nouveau: working towards a common way to represent engines
  drm/nv50/gr: move to exec engine interfaces
  drm/nvc0/gr: move to exec engine interfaces
  drm/nv40/gr: move to exec engine interfaces
  drm/nv20-nv30/gr: move to exec engine interface
  drm/nv10/gr: move to exec engine interfaces
  drm/nv04/gr: move to exec engine interfaces
  drm/nouveau: move set_tile_region to nouveau_exec_engine
  drm/nouveau: remove remnants of nouveau_pgraph_engine from nouveau_channel
  drm/nouveau: fix suspend failure path to reinitialise all engines
  drm/nouveau: remove remnants of nouveau_pgraph_engine
  drm/nva3: implement support for copy engine
  drm/nvc0: implement support for copy engines
  drm/nv40/vpe: add support for PMPEG
  drm/nv84: add support for PMPEG
  drm/nv50: rename nv84_mpeg to nv50_mpeg
  drm/nv50: support PMPEG on original nv50
  drm/nvc0/gr: better handling of fuc firmware
  drm/nvc0/fifo: kick channels off during suspend
  drm/nvc0/fifo: restore context table on resume
  drm/nvc0/gr: no need to store context in graph_fini()
  drm/nvc0/fifo: stick user area into a gpuobj rather than a bo
  drm/nv40/gr: oops, fix random bits getting set in engine obj
  drm/nouveau: pull refclk from vbios on limits 0x40 boards
  drm/nva3: somewhat improve clock reporting
  drm/nouveau: fix uninitialised variable warning
  drm/nouveau: recognise DCB connector type 0x41 as LVDS
  drm/nv50: respect LVDS link count from EDID on SPWG panels
  drm/nvc0/gr: calculate some more of our magic numbers
  drm/nva3/pm: initial pass at set_clock() hook
  drm/nva3: support for memory timing map table
  drm/nouveau/pm: remove memtiming support check when assigning to perflvl
  drm/nvc0/pm: correct core/mem/shader perflvl parsing
  drm/nvc0/pm: parse clo

Re: [2.6.39-rc7] i915: kworker busily spinning...

2011-05-24 Thread Daniel J Blueman

On 17 May 2011 12:27, Daniel J Blueman  wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a HDMI display, and also when no
> display has been plugged (ie only the internal LVDS connection is
> active).
>
> Across multiple kernel task captures, I see the kernel thread
> consistently reading one of the connector's EDID data [1]; I guess
> either it's having a hard time reading from a disconnected connector
> and retrying, or is incorrectly detecting a change when there is none.
>
> I'll enable DRM debugging to see what connectors it believes it needs
> to read from. Anything else that would be handy to capture, or any
> thoughts?
>
> Also, the 100ms connector change polling seems overkill, particularly
> when power consumption is important; 1000-2000ms would be sufficient,
> do you think?
>
> Thanks,
>  Daniel
>
> --- [1]
>
> kworker/2:2     R  running task     5048    86      2 0x
>  0002 88021e804040 88021e85f9b0 88021e804040
>  88021e85e000 4000 8802210a4040 88021e804040
>  0046 81c18b20 88022106c000 8270b740
> Call Trace:
>  [] ? mark_held_locks+0x70/0xa0
>  [] ? get_parent_ip+0x11/0x50
>  [] ? sub_preempt_count+0x9d/0xd0
>  [] schedule_timeout+0x175/0x250
>  [] ? run_timer_softirq+0x2a0/0x2a0
>  [] schedule_timeout_uninterruptible+0x19/0x20
>  [] msleep+0x18/0x20
>  [] gmbus_xfer+0x400/0x620 [i915]
>  [] i2c_transfer+0xa2/0xf0
>  [] drm_do_probe_ddc_edid+0x66/0xa0 [drm]
>  [] drm_get_edid+0x29/0x60 [drm]
>  [] intel_hdmi_detect+0x56/0xe0 [i915]
>  [] output_poll_execute+0xd7/0x1a0 [drm_kms_helper]
>  [] process_one_work+0x1a4/0x450
>  [] ? process_one_work+0x146/0x450
>  [] ?
> drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper]
>  [] process_scheduled_works+0x2c/0x40
>  [] worker_thread+0x284/0x350
>  [] ? manage_workers.clone.23+0x120/0x120
>  [] kthread+0xb6/0xc0
>  [] ? trace_hardirqs_on_caller+0x13d/0x180
>  [] kernel_thread_helper+0x4/0x10
>  [] ? finish_task_switch+0x6f/0x100
>  [] ? retint_restore_args+0xe/0xe
>  [] ? __init_kthread_worker+0x70/0x70
>  [] ? gs_change+0xb/0xb

Interestingly, I appear to observe this behaviour when the laptop
battery is charging. Anyway, we see continual connector update events
[1], booted drm.debug=0x4. This reproduces with 2.6.39.

Any thoughts?

Daniel

--- [1]

[   67.035097] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.046549] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.047063] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047065] [drm:ironlake_dp_detect], DPCD: 
[   67.047066] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.047578] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.047579] [drm:ironlake_dp_detect], DPCD: 
[   67.047581] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.047588] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4, result 0
[   67.047591] [drm:intel_crt_detect], CRT not detected via hotplug
[   67.047593] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status
updated from 2 to 2
[   67.059062] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1]
status updated from 2 to 2
[   67.059573] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.059575] [drm:ironlake_dp_detect], DPCD: 
[   67.059576] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status
updated from 2 to 2
[   67.059886] [drm:i915_hotplug_work_func], running encoder hotplug functions
<85 lines the same>
[   67.153172] [drm:i915_hotplug_work_func], running encoder hotplug functions
[   67.155109] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2]
status updated from 2 to 2
[   67.166569] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3]
status updated from 2 to 2
[   67.167082] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167084] [drm:ironlake_dp_detect], DPCD: 
[   67.167086] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status
updated from 2 to 2
[   67.167598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.167600] [drm:ironlake_dp_detect], DPCD: 
[   67.167601] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status
updated from 2 to 2
[   67.167608] [drm:intel_ironlake_crt_detect_hotplug], ironlake
hotplug adpa=0xf4, result 0
[   67.167610] [drm:intel_crt_detect], CRT not detected via hotplug
[   67.167612] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status
updated from 2 to 2
[   67.179051] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1]
status updated from 2 to 2
[   67.179563] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e
[   67.179564] [drm:ironlake_dp_detect], DPCD: 00

Re: [2.6.39-rc7] i915: kworker busily spinning...

2011-05-24 Thread Andy Lutomirski

On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a HDMI display, and also when no
> display has been plugged (ie only the internal LVDS connection is
> active).
> 
> Across multiple kernel task captures, I see the kernel thread
> consistently reading one of the connector's EDID data [1]; I guess
> either it's having a hard time reading from a disconnected connector
> and retrying, or is incorrectly detecting a change when there is none.
> 
> I'll enable DRM debugging to see what connectors it believes it needs
> to read from. Anything else that would be handy to capture, or any
> thoughts?
> 
> Also, the 100ms connector change polling seems overkill, particularly
> when power consumption is important; 1000-2000ms would be sufficient,
> do you think?

I think it's meant to be every 10 seconds.

In any case, the output_poll_execute code does more work than necessary,
which might exacerbate the problem.  Here's an old patch I wrote that
probably doesn't apply any more but might help.

commit 82c9114cdc60aba7d9bec1396d818362a208cfdc
Author: Andy Lutomirski 
Date:   Tue Aug 17 09:38:59 2010 -0400

drm: Try to poll fewer unnecessary outputs

We used to poll all outputs that had any kind of polling enabled every time
that the output polling work ran (i.e. every ten seconds).  Now only poll
hotplug-interrupt capable outputs when hotplug is detected and we only
poll POLL_CONNECT and POLL_DISCONNECT when in the appropriate state.

Signed-off-by: Andy Lutomirski 

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 9b2a541..5a39e3c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -817,31 +817,38 @@ static void output_poll_execute(struct slow_work *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device, 
mode_config.output_poll_slow_work);
struct drm_connector *connector;
enum drm_connector_status old_status, status;
-   bool repoll = false, changed = false;
+   bool repoll = false, changed = false, need_poll, hpd_detected;
int ret;
 
+   hpd_detected = ACCESS_ONCE(dev->mode_config.hpd_detected);
+   ACCESS_ONCE(dev->mode_config.hpd_detected) = 0;
+
mutex_lock(&dev->mode_config.mutex);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
 
-   /* if this is HPD or polled don't check it -
-  TV out for instance */
+   /* don't poll unless the drivers asked us to. */
if (!connector->polled)
continue;
 
-   else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT | 
DRM_CONNECTOR_POLL_DISCONNECT))
-   repoll = true;
+   /* poll if we got an HPD request... */
+   need_poll = hpd_detected;
 
+   /* ...or if we're supposed to poll all the time */
old_status = connector->status;
-   /* if we are connected and don't want to poll for disconnect
-  skip it */
-   if (old_status == connector_status_connected &&
-   !(connector->polled & DRM_CONNECTOR_POLL_DISCONNECT) &&
-   !(connector->polled & DRM_CONNECTOR_POLL_HPD))
-   continue;
+   if (old_status == connector_status_connected ?
+   (connector->polled & DRM_CONNECTOR_POLL_CONNECT) :
+   (connector->polled & DRM_CONNECTOR_POLL_DISCONNECT))
+   need_poll = true;
 
-   status = connector->funcs->detect(connector);
-   if (old_status != status)
-   changed = true;
+   /* Do we re-queue? */
+   if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT | 
DRM_CONNECTOR_POLL_DISCONNECT))
+   repoll = true;
+
+   if (need_poll) {
+   status = connector->funcs->detect(connector);
+   if (old_status != status)
+   changed = true;
+   }
}
 
mutex_unlock(&dev->mode_config.mutex);
@@ -911,6 +918,7 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
return;
delayed_slow_work_cancel(&dev->mode_config.output_poll_slow_work);
/* schedule a slow work asap */
+   ACCESS_ONCE(dev->mode_config.hpd_detected) = true;
delayed_slow_work_enqueue(&dev->mode_config.output_poll_slow_work, 0);
 }
 EXPORT_SYMBOL(drm_helper_hpd_irq_event);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 93a1a31..586f41f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -596,6 +596,

Re: [2.6.39-rc7] i915: kworker busily spinning...

2011-05-24 Thread Daniel J Blueman

On 24 May 2011 12:02, Andy Lutomirski  wrote:
> On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
>> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
>> sometimes I find one of the kworker threads busily running with 15-20%
>> system time for some minutes, causing terrible interactivity latency.
>> I've seen it occur when plugging eg a HDMI display, and also when no
>> display has been plugged (ie only the internal LVDS connection is
>> active).
>>
>> Across multiple kernel task captures, I see the kernel thread
>> consistently reading one of the connector's EDID data [1]; I guess
>> either it's having a hard time reading from a disconnected connector
>> and retrying, or is incorrectly detecting a change when there is none.
>>
>> I'll enable DRM debugging to see what connectors it believes it needs
>> to read from. Anything else that would be handy to capture, or any
>> thoughts?
>>
>> Also, the 100ms connector change polling seems overkill, particularly
>> when power consumption is important; 1000-2000ms would be sufficient,
>> do you think?
>
> I think it's meant to be every 10 seconds.
>
> In any case, the output_poll_execute code does more work than necessary,
> which might exacerbate the problem.  Here's an old patch I wrote that
> probably doesn't apply any more but might help.

Thanks for the patch Andy; I'll test it after we've found a fix for
the underlying issue.

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

Re: (Short?) merge window reminder

2011-05-24 Thread Thomas Gleixner

On Mon, 23 May 2011, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.

So the voices tell you to avoid .42 ?

Thanks,

tglx

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

Re: (Short?) merge window reminder

2011-05-24 Thread James Bottomley

On Mon, 2011-05-23 at 12:22 -0700, Greg KH wrote:
> On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> > PS. The voices in my head also tell me that the numbers are getting
> > too big. I may just call the thing 2.8.0. And I almost guarantee that
> > this PS is going to result in more discussion than the rest, but when
> > the voices tell me to do things, I listen.
> 
> If you do this, I will buy you a bottle of whatever whiskey you want
> that I can get my hands on in Tokyo next week.

I can recommend Hanyu Ace of Spades ...  I can even arrange to be on
hand just to make sure it's as good as it should be ...

James


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

Re: (Short?) merge window reminder

2011-05-24 Thread Alexey Zaytsev

On Tue, May 24, 2011 at 00:33, Linus Torvalds
 wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.
>
> There's also the timing issue - since we no longer do version numbers
> based on features, but based on time, just saying "we're about to
> start the third decade" works as well as any other excuse.
>
> But we'll see.

Maybe, 2011.x, or 11.x, x increasing for every merge window started this year?
This would better reflect the steady nature of the releases, but would
certainly break a lot of scripts. ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-24 Thread Steven Rostedt

On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote:
> 
> They tell him to avoid the question to which 42 is the answer.

What 2.6 Linux kernel version was the last before 3.0?

-- Steve

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

Re: (Short?) merge window reminder

2011-05-24 Thread Oliver Pinter

On 5/23/11, Linus Torvalds  wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)

I think, the best time for this, after reorganize the ARM arch folder / tree.

>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.
>
> But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
> fairly nice round number.
>
> There's also the timing issue - since we no longer do version numbers
> based on features, but based on time, just saying "we're about to
> start the third decade" works as well as any other excuse.
>
> But we'll see.
>
>Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-24 Thread Ted Ts'o

On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
> 
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would get the third digit rather than
> the fourth one.

If we change from 2.6.X to 3.X, then if we don't change anything else,
then successive stable release will cause the LINUX_VERSION_CODE to be
incremented.  This isn't necessary bad, but it would be a different
from what we have now.

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

Re: (Short?) merge window reminder

2011-05-24 Thread Matthew Wilcox

On Mon, May 23, 2011 at 03:21:21PM -0700, Greg KH wrote:
> On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
> > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar  wrote:
> > > I really hope there's also a voice that tells you to wait until .42 before
> > > cutting 3.0.0! :-)
> > 
> > So I'm toying with 3.0 (and in that case, it really would be "3.0",
> > not "3.0.0" - the stable team would get the third digit rather than
> > the fourth one.
> 
> I like that, it would make things much easier for me to keep track of
> stuff.

As long as 3.14 turns into a long-term support kernel and gets up to 159 ...

In all serious, I'm very supportive of this move.  I'm heartily sick
of people claiming "we have version 2.6 support" when they really mean
they haven't updated since version 2.6.9.  Yeah, congratulations, you're
seven years out of date.

-- 
Matthew Wilcox  Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-24 Thread Jan Engelhardt

On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:

>Another advantage of switching numbering models (ie 3.0 instead of
>2.8.x) would be that it would also make the "odd numbers are also
>numbers" transition much more natural.
>
>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>there's just too much history of 2.1, 2.3, 2.5 being development
>trees.

.oO(Though once 2.{7 or more, odd} trickle into the distros, it would 
become pretty much apparent that they are not devel.)

>And then in another few years (probably before getting close to 3.40,
>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>do 4.0 etc.

While 2.6 has certainly worn out, already thinking of a 4.0 is highly 
reminiscient of the version number arms race Firefox and ChromeBrowser 
are doing currently.

>Because all our releases are supposed to be stable releases these
>days, and if we get rid of one level of numbering, I feel perfectly
>fine with getting rid of the even/odd history too.

If I remember past-time discussions right, ELF was the contributing 
factor to bump the major number to 2.0 back then; ever since 2.0, no 
similarly breakthrough-ing event has occurred.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-24 Thread Jacek Luczak

2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>
>>Another advantage of switching numbering models (ie 3.0 instead of
>>2.8.x) would be that it would also make the "odd numbers are also
>>numbers" transition much more natural.
>>
>>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>>there's just too much history of 2.1, 2.3, 2.5 being development
>>trees.
>
> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> become pretty much apparent that they are not devel.)
>
>>And then in another few years (probably before getting close to 3.40,
>>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>>do 4.0 etc.
>
> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> reminiscient of the version number arms race Firefox and ChromeBrowser
> are doing currently.
>
>>Because all our releases are supposed to be stable releases these
>>days, and if we get rid of one level of numbering, I feel perfectly
>>fine with getting rid of the even/odd history too.
>
> If I remember past-time discussions right, ELF was the contributing
> factor to bump the major number to 2.0 back then; ever since 2.0, no
> similarly breakthrough-ing event has occurred.

What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.

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

Re: (Short?) merge window reminder

2011-05-24 Thread Jan Engelhardt

On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:

>2011/5/24 Jan Engelhardt :
>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>
>>>Another advantage of switching numbering models (ie 3.0 instead of
>>>2.8.x) would be that it would also make the "odd numbers are also
>>>numbers" transition much more natural.
>>>
>>>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>>>there's just too much history of 2.1, 2.3, 2.5 being development
>>>trees.
>>
>> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
>> become pretty much apparent that they are not devel.)
>>
>>>And then in another few years (probably before getting close to 3.40,
>>>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>>>do 4.0 etc.
>>
>> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
>> reminiscient of the version number arms race Firefox and ChromeBrowser
>> are doing currently.
>>
>>>Because all our releases are supposed to be stable releases these
>>>days, and if we get rid of one level of numbering, I feel perfectly
>>>fine with getting rid of the even/odd history too.
>>
>> If I remember past-time discussions right, ELF was the contributing
>> factor to bump the major number to 2.0 back then; ever since 2.0, no
>> similarly breakthrough-ing event has occurred.
>
>What then about BKL removal? Nice place to celebrate with version jump
>and heaving some beers.

The BKL going away was not a change that would require new 
userspace programs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (Short?) merge window reminder

2011-05-24 Thread Jacek Luczak

2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>
>>2011/5/24 Jan Engelhardt :
>>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>>
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers are also
numbers" transition much more natural.

Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
>>>
>>> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
>>> become pretty much apparent that they are not devel.)
>>>
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = "third decade"), I'd just
do 4.0 etc.
>>>
>>> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
>>> reminiscient of the version number arms race Firefox and ChromeBrowser
>>> are doing currently.
>>>
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
>>>
>>> If I remember past-time discussions right, ELF was the contributing
>>> factor to bump the major number to 2.0 back then; ever since 2.0, no
>>> similarly breakthrough-ing event has occurred.
>>
>>What then about BKL removal? Nice place to celebrate with version jump
>>and heaving some beers.
>
> The BKL going away was not a change that would require new
> userspace programs.

True but as you I guess - kind off - notice there's no such event that
would launch fireworks and we get features smoothly. By that then we
should celebrate killing old nightmares aka BKL. It's more like - lets
not find the reason but include one just to feel better. At the end
the simplified  version convention is the best reason to do this cut
off. I even plan to send a truck full of chickens to Linus if this
will convince him :) Then, while describing new kernel deployment, I
won't need to pronounce the cool sounding - ,,Mika so I've now
installed two(dot)six(dot)thirty-five(dot)forty-one(dash)one
version.''

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

Re: (Short?) merge window reminder

2011-05-24 Thread Alan Cox

> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented.  This isn't necessary bad, but it would be a different
> from what we have now.

I think I prefer 3 digits. Otherwise we will have to pass 3.0, 3.1 and
3.11 all of which numbers still give older sysadmins flashbacks and will
have them waking screaming in the middle of the night.

Also saves breaking all the tools and assumptions people have been used
to for some many years

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

Re: (Short?) merge window reminder

2011-05-24 Thread Alan Cox

Can we drop most of MCA, EISA and ISA bus if we are going to have a big
version change ? A driver spring clean is much overdue and it's all in
git in case someone wishes to sneak out at midnight and bring some crawly
horror back from the dead.

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

Re: (Short?) merge window reminder

2011-05-24 Thread jonsm...@gmail.com

On Tue, May 24, 2011 at 10:43 AM, Alan Cox  wrote:
> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back from the dead.

2.8 could mark the beginning of the great cleanup
  --- work out the details of what needs to be cleaned and set a goal
  --- remove old buses/driver, switch to device tree, graphics, 32/64
merges, etc
3.0 would mark its completion

-- 
Jon Smirl
jonsm...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

2011-05-24 Thread bugzilla-daemon

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

Michel Dänzer  changed:

   What|Removed |Added

  Attachment #47089|text/x-log  |text/plain
  mime type||

-- 
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 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

2011-05-24 Thread bugzilla-daemon

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

--- Comment #12 from Michel Dänzer  2011-05-24 08:43:15 PDT 
---
Could be a mipmap generation issue then. Is it still broken with r600g from
upstream Git master?

-- 
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: How are GLX Visuals Created???

2011-05-24 Thread Pauli Nieminen

On Sun, May 22, 2011 at 6:15 PM, Dee Sharpe
 wrote:
> Hello all,
>
> I'm not sure that this is really the appropriate place to pose this
> question; but, I was wondering how GLX Visuals are created internally. What
> info does a video driver give that allows the XServer & also GLX to
> configure a list of Visuals? How is this info combined & shaped into
> Visuals? I'm looking specifically for functions & variables. If someone
> could point me to a few files, I'd be immensely grateful!
>

http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxscreens.c#n322

Is that what you are looking for?

> --
>
> Dee Sharpe
>
> The difference between what IS done
> &  what COULD be done is relational to
> what you ARE doing&  what you COULD be doing!
>
> ___
> 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

[Bug 28125] DRI2 prevents indirect glx

2011-05-24 Thread bugzilla-daemon

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

Marc Gariépy  changed:

   What|Removed |Added

 CC||mgari...@ubuntu.com
   See Also||https://launchpad.net/bugs/
   ||785368

-- 
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: (Short?) merge window reminder

2011-05-24 Thread H. Peter Anvin

On 05/24/2011 08:07 AM, jonsm...@gmail.com wrote:
> On Tue, May 24, 2011 at 10:43 AM, Alan Cox  wrote:
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak out at midnight and bring some crawly
>> horror back from the dead.
> 
> 2.8 could mark the beginning of the great cleanup
>   --- work out the details of what needs to be cleaned and set a goal
>   --- remove old buses/driver, switch to device tree, graphics, 32/64
> merges, etc
> 3.0 would mark its completion
> 

I think this whole discussion misses the essence of the new development
model, which is that we no longer do these kinds of feature-based major
milestones.  If we want to to deprecate lots of drivers (which I
personally would advocate against -- I have built systems specifically
to run a real floppy drive since the Linux floppy driver is amazingly
flexible and can read/write a lot of formats that nothing else can,
including USB floppies) then we should do that in the normal course of
action, incrementally, and listed in feature-removal-schedule.txt, not
all at once due to some arbitrary milestone.

We have found it works better this way.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

Re: (Short?) merge window reminder

2011-05-24 Thread Linus Torvalds

On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin  wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.

Indeed.

It's not about features. It hasn't been about features for forever.

So a renumbering would be purely about dropping the numbers to
something smaller and more easily recognized. The ABI wouldn't change.
The API wouldn't change. There wouldn't be any big "because we finally
did xyz".

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

[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent

2011-05-24 Thread bugzilla-daemon

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

--- Comment #3 from Sven Arvidsson  2011-05-24 10:48:14 PDT ---
(In reply to comment #2)
> Close the other one as duplicate of this one (despite anachronism) ?

That's probably a good idea. You could also reassign this bug to component
"Mesa core" as it isn't a problem specific to r600g.

-- 
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 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent

2011-05-24 Thread bugzilla-daemon

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

Benoit Jacob  changed:

   What|Removed |Added

 CC||pavel.ondra...@email.cz

--- Comment #4 from Benoit Jacob  2011-05-24 10:53:14 PDT 
---
*** Bug 33188 has been marked as a duplicate of this bug. ***

-- 
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 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent

2011-05-24 Thread bugzilla-daemon

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

Benoit Jacob  changed:

   What|Removed |Added

  Component|Drivers/Gallium/r600|Mesa core
 AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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 35434] [RADEON:KMS:R600G] etqw: broken ground textures

2011-05-24 Thread bugzilla-daemon

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

--- Comment #11 from Sven Arvidsson  2011-05-24 12:30:03 PDT ---
(In reply to comment #10)
> In fact, I have these 2 issues also with gallium-swrast.

I just tried ETQW with llvmpipe and it's rendering correctly.

Can you confirm that you're getting software rendering? Check the renderer
string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check
which driver is loaded.

If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps
and a loading time of several minutes...

-- 
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 35434] [RADEON:KMS:R600G] etqw: broken ground textures

2011-05-24 Thread bugzilla-daemon

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

--- Comment #12 from Benjamin Bellec  2011-05-24 13:10:52 
PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > In fact, I have these 2 issues also with gallium-swrast.
> 
> I just tried ETQW with llvmpipe and it's rendering correctly.
> 
> Can you confirm that you're getting software rendering? Check the renderer
> string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check
> which driver is loaded.
> 
> If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps
> and a loading time of several minutes...

Shame on me!
ETQW has loaded r600_dri.so from /usr/local/dri (my former dri install) when I
deleted it from /usr/dri ! So I believed I was on llvmpipe (Gnome 3 was in
fallback-mode, and glxinfo said that too).

You are right, ETQW is too slow to move the mouse.

-- 
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 35434] [RADEON:KMS:R600G] etqw: broken ground textures

2011-05-24 Thread bugzilla-daemon

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

--- Comment #13 from Sven Arvidsson  2011-05-24 13:12:43 PDT ---
(In reply to comment #12)
> 
> You are right, ETQW is too slow to move the mouse.

Yeah, that sounds about right for software rendering :)

-- 
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 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

2011-05-24 Thread bugzilla-daemon

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

--- Comment #13 from William Pitcock  2011-05-24 
13:34:59 PDT ---
i don't know, and my concern is mostly with the non-gallium driver right now.

i can test the gallium driver, but i need the normal driver to work as i have
32-bit applications i am running in a debian chroot.  thusly, i do not really
use the gallium driver yet... i only tested it to see if it did the same thing,
which it does.

the result is not the same everytime you trigger that kwin effect though;
sometimes i get part of a console framebuffer (e.g. radeondrmfb).

so would it make more sense for me to test non-gallium driver first?

-- 
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 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

2011-05-24 Thread bugzilla-daemon

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

--- Comment #14 from Alex Deucher  2011-05-24 14:19:34 PDT ---
(In reply to comment #13)
> i don't know, and my concern is mostly with the non-gallium driver right now.
> 
> i can test the gallium driver, but i need the normal driver to work as i have
> 32-bit applications i am running in a debian chroot.  thusly, i do not really
> use the gallium driver yet... i only tested it to see if it did the same 
> thing,
> which it does.
> 
> the result is not the same everytime you trigger that kwin effect though;
> sometimes i get part of a console framebuffer (e.g. radeondrmfb).
> 
> so would it make more sense for me to test non-gallium driver first?

No one is really working on the non gallium driver any more, so it's not likely
to get much more attention.

-- 
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: (Short?) merge window reminder

2011-05-24 Thread Andy Lutomirski

On 05/23/2011 04:33 PM, Linus Torvalds wrote:

On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:

I really hope there's also a voice that tells you to wait until .42 before
cutting 3.0.0! :-)

So I'm toying with 3.0 (and in that case, it really would be "3.0",
not "3.0.0" - the stable team would get the third digit rather than
the fourth one.

But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a
fairly nice round number.

There's also the timing issue - since we no longer do version numbers
based on features, but based on time, just saying "we're about to
start the third decade" works as well as any other excuse.

I don't think year-based versions (like 2011.0 for the first 2011
release, or maybe 2011.5 for May 2011) are pretty, but I'll make an
argument for them anyway: it makes it easier to figure out when hardware
ought to be supported.

So if I buy a 2014-model laptop and the coffee-making button doesn't
work, and my favorite distro is running the 2013 kernel, then I know I
shouldn't expect to it to work. (Graphics drivers are probably a more
realistic example.)

Also, when someone in my lab installs here> on a box that's running software I wrote that needs to support
modern high-speed peripherals, then I can say "What? You seriously
expect this stuff to work on Linux 2007? Let's install a slightly less
stable distro from at least 2010." This sounds a lot less nerdy than
"What? You seriously expect this stuff to work on Linux 2.6.27? Let's
install a slightly less stable distro that uses at least 2.6.36."

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

[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1

2011-05-24 Thread bugzilla-daemon

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

--- Comment #15 from William Pitcock  2011-05-24 
14:32:50 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > i don't know, and my concern is mostly with the non-gallium driver right 
> > now.
> > 
> > i can test the gallium driver, but i need the normal driver to work as i 
> > have
> > 32-bit applications i am running in a debian chroot.  thusly, i do not 
> > really
> > use the gallium driver yet... i only tested it to see if it did the same 
> > thing,
> > which it does.
> > 
> > the result is not the same everytime you trigger that kwin effect though;
> > sometimes i get part of a console framebuffer (e.g. radeondrmfb).
> > 
> > so would it make more sense for me to test non-gallium driver first?
> 
> No one is really working on the non gallium driver any more, so it's not 
> likely
> to get much more attention.

well, i will try and see if r600g git master solves the problem. 
unfortunately, i think this means i'm screwed when it comes to running
proprietary apps in chroots.

-- 
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 28125] DRI2 prevents indirect glx

2011-05-24 Thread bugzilla-daemon

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

--- Comment #4 from ajax at nwnk dot net  2011-05-24 15:02:46 
PDT ---
Patch posted:

http://lists.freedesktop.org/archives/mesa-dev/2011-May/007789.html

A less robust version was tested by the reporter on IRC.

-- 
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

[PATCH] uv/x2apic: update for change in pci bridge handling.

2011-05-24 Thread Dave Airlie

From: Dave Airlie 

I forgot about the special uv handling code for this, so this
patch fixes it up.

Signed-off-by: Dave Airlie 
---
 arch/x86/kernel/apic/x2apic_uv_x.c |8 
 drivers/pci/pci.c  |4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 33b10a0..185cd1e 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -599,14 +599,14 @@ late_initcall(uv_init_heartbeat);
 
 /* Direct Legacy VGA I/O traffic to designated IOH */
 int uv_set_vga_state(struct pci_dev *pdev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
 {
int domain, bus, rc;
 
-   PR_DEVEL("devfn %x decode %d cmd %x chg_brdg %d\n",
-   pdev->devfn, decode, command_bits, change_bridge);
+   PR_DEVEL("devfn %x decode %d cmd %x flags %d\n",
+   pdev->devfn, decode, command_bits, flags);
 
-   if (!change_bridge)
+   if (!(flags & PCI_VGA_STATE_CHANGE_BRIDGE))
return 0;
 
if ((command_bits & PCI_COMMAND_IO) == 0)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a339237..4528ee7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2862,11 +2862,11 @@ void __init 
pci_register_set_vga_state(arch_set_vga_state_t func)
 }
 
 static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
 {
if (arch_set_vga_state)
return arch_set_vga_state(dev, decode, command_bits,
-   change_bridge);
+   flags);
return 0;
 }
 
-- 
1.7.1

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

[PATCH 1/2] drm/radeon/kms/blit: workaround some hw issues on evergreen+

2011-05-24 Thread Alex Deucher

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_blit_kms.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c 
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index ba06a69..4086729 100644
--- a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -199,6 +199,16 @@ static void
 set_scissors(struct radeon_device *rdev, int x1, int y1,
 int x2, int y2)
 {
+   /* workaround some hw bugs */
+   if (x2 == 0)
+   x1 = 1;
+   if (y2 == 0)
+   y1 = 1;
+   if (rdev->family == CHIP_CAYMAN) {
+   if ((x2 == 1) && (y2 == 1))
+   x2 = 2;
+   }
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONTEXT_REG, 2));
radeon_ring_write(rdev, (PA_SC_SCREEN_SCISSOR_TL - 
PACKET3_SET_CONTEXT_REG_START) >> 2);
radeon_ring_write(rdev, (x1 << 0) | (y1 << 16));
-- 
1.7.1.1

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

[PATCH 2/2] drm/radeon/kms: add blit support for cayman

2011-05-24 Thread Alex Deucher

Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/cayman_blit_shaders.c |  326 -
 drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
 drivers/gpu/drm/radeon/evergreen_blit_kms.c  |  505 ++
 drivers/gpu/drm/radeon/ni.c  |   13 +-
 drivers/gpu/drm/radeon/radeon_asic.c |6 +-
 5 files changed, 598 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c 
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
 
 const u32 cayman_default_state[] =
 {
-   /* XXX fill in additional blit state */
+   0xc0066900,
+   0x,
+   0x0060, /* DB_RENDER_CONTROL */
+   0x, /* DB_COUNT_CONTROL */
+   0x, /* DB_DEPTH_VIEW */
+   0x002a, /* DB_RENDER_OVERRIDE */
+   0x, /* DB_RENDER_OVERRIDE2 */
+   0x, /* DB_HTILE_DATA_BASE */
 
0xc0026900,
-   0x0316,
-   0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
-   0x0010, /*  */
+   0x000a,
+   0x, /* DB_STENCIL_CLEAR */
+   0x, /* DB_DEPTH_CLEAR */
+
+   0xc0036900,
+   0x000f,
+   0x, /* DB_DEPTH_INFO */
+   0x, /* DB_Z_INFO */
+   0x, /* DB_STENCIL_INFO */
+
+   0xc0016900,
+   0x0080,
+   0x, /* PA_SC_WINDOW_OFFSET */
+
+   0xc00d6900,
+   0x0083,
+   0x, /* PA_SC_CLIPRECT_RULE */
+   0x, /* PA_SC_CLIPRECT_0_TL */
+   0x20002000, /* PA_SC_CLIPRECT_0_BR */
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x,
+   0x20002000,
+   0x, /* PA_SC_EDGERULE */
+   0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+   0x000f, /* CB_TARGET_MASK */
+   0x000f, /* CB_SHADER_MASK */
+
+   0xc0226900,
+   0x0094,
+   0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+   0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x8000,
+   0x20002000,
+   0x, /* PA_SC_VPORT_ZMIN_0 */
+   0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+   0xc0016900,
+   0x00d4,
+   0x, /* SX_MISC */
 
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+   0xc0096900,
+   0x0100,
+   0x00ff, /* VGT_MAX_VTX_INDX */
+   0x, /* VGT_MIN_VTX_INDX */
+   0x, /* VGT_INDX_OFFSET */
+   0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+   0x, /* SX_ALPHA_TEST_CONTROL */
+   0x, /* CB_BLEND_RED */
+   0x, /* CB_BLEND_GREEN */
+   0x, /* CB_BLEND_BLUE */
+   0x, /* CB_BLEND_ALPHA */
+
+   0xc0016900,
+   0x0187,
+   0x0100, /* SPI_VS_OUT_ID_0 */
+
+   0xc0026900,
+   0x0191,
+   0x0100, /* SPI_PS_INPUT_CNTL_0 */
+   0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+   0xc0016900,
+   0x01b1,
+   0x, /* SPI_VS_OUT_CONFIG */
+
+   0xc0106900,
+   0x01b3,
+   0x2001, /* SPI_PS_IN_CONTROL_0 */
+   0x, /* SPI_PS_IN_CONTROL_1 */
+   0x, /* SPI_INTERP_CONTROL_0 */
+   0x, /* SPI_INPUT_Z */
+   0x, /* SPI_FOG_CNTL */
+   0x0010, /* SPI_BARYC_CNTL */
+   0x, /* SPI_PS_IN_CONTROL_2 */
+   0x, /* SPI_COMPUTE_INPUT_CNTL */
+   0x, /* SPI_COMPUTE_NUM_THREAD_X */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+   0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+   0x, /* SPI_GPR_MGMT */
+   0x, /* SPI_LDS_MGMT */
+   0x, /* SPI_STACK_MGMT */
+   0x, /* SPI_WAVE_MGMT_1 */
+   0x, /* SPI_WAVE_MGMT_2 */
+
+   0xc0016900,
+   0x01e0,
+   0x, /* CB_BLEND0_CONTROL */
+
+   0xc00e6900,
+   0x0200,
+   0x, /* DB_DEPTH_CONTROL */
+   0x, /* DB_EQAA */
+   0x00cc0010, /* CB_COLOR_CONTROL */
+   0x0210, /* DB_SHADER_CONTROL */
+   0x0001, /* PA_CL_CLIP_CNTL */
+   0x0004, /* PA_SU_SC_MODE_CNT

Re: (Short?) merge window reminder

2011-05-24 Thread Valdis . Kletnieks

On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
> 2011/5/24 Jan Engelhardt :
> > On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
> >
> >>Another advantage of switching numbering models (ie 3.0 instead of
> >>2.8.x) would be that it would also make the "odd numbers are also
> >>numbers" transition much more natural.
> >>
> >>Because of our historical even/odd model, I wouldn't do a 2.7.x -
> >>there's just too much history of 2.1, 2.3, 2.5 being development
> >>trees.
> >
> > .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> > become pretty much apparent that they are not devel.)
> >
> >>And then in another few years (probably before getting close to 3.40,
> >>so I'm not going to make a big deal of 3 = "third decade"), I'd just
> >>do 4.0 etc.
> >
> > While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> > reminiscient of the version number arms race Firefox and ChromeBrowser
> > are doing currently.
> >
> >>Because all our releases are supposed to be stable releases these
> >>days, and if we get rid of one level of numbering, I feel perfectly
> >>fine with getting rid of the even/odd history too.
> >
> > If I remember past-time discussions right, ELF was the contributing
> > factor to bump the major number to 2.0 back then; ever since 2.0, no
> > similarly breakthrough-ing event has occurred.
> 
> What then about BKL removal? Nice place to celebrate with version jump
> and heaving some beers.

Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)


pgp21lBpIoZeR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

86 matches

Mail list logo