Re: [Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on
On Wed, Sep 15, 2021 at 1:47 AM Jani Nikula wrote: > > On Tue, 14 Sep 2021, Vasily Khoruzhick wrote: > > On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula > > wrote: > >> > >> On Tue, 14 Sep 2021, Lyude Paul wrote: > >> > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote: > >> >> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote: > >> >> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface > >> >> > to > >> >> > control brightness, apparently needs a delay before setting brightness > >> >> > after power on. Without this delay the panel does accept the setting > >> >> > and may come up with some arbitrary brightness (sometimes it's too > >> >> > dark, > >> >> > sometimes it's too bright, I wasn't able to find a system). > >> >> > > >> >> > I don't have access to the spec, so I'm not sure if it's expected > >> >> > behavior or a quirk for particular device. > >> >> > > >> >> > Delay was chosen by experiment: it works with 100ms, but fails with > >> >> > anything lower than 75ms. > >> >> > >> >> Looks like we don't respect the panel delays for DPCD backlight. The > >> >> values are used for setting up the panel power sequencer, and thus PWM > >> >> based backlight, but we should probably use the delays in DPCD backlight > >> >> code too. > >> > > >> > This makes sense to me, you're referring to the panel delays in the VBT > >> > correct? > >> > >> Yes. See pps_init_delays() and intel_pps_backlight_on(). The delays > >> aren't applied to DPCD backlight, I think it would make sense if they > >> were. > > > > I guess it explains why it usually stops working after suspend. > > Probably BIOS doesn't re-init the power sequencer on resume. > > The point is, the DPCD backlight isn't driven via the power sequencer, > while the PWM pin would be. > > Please file a bug at [1], and attach /sys/kernel/debug/dri/0/i915_vbt as > well as dmesg from boot with drm.debug=14 module parameter set. Done, see https://gitlab.freedesktop.org/drm/intel/-/issues/4170 > Thanks, > Jani. > > > [1] https://gitlab.freedesktop.org/drm/intel/issues/new > > > > > > >> BR, > >> Jani. > >> > >> > > >> >> > >> >> BR, > >> >> Jani. > >> >> > >> >> > >> >> > > >> >> > Signed-off-by: Vasily Khoruzhick > >> >> > --- > >> >> > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 > >> >> > 1 file changed, 4 insertions(+) > >> >> > > >> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> >> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> >> > index 4f8337c7fd2e..c4f35e1b5870 100644 > >> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> >> > @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct > >> >> > intel_crtc_state *crtc_state, > >> >> > > >> >> > ctrl = old_ctrl; > >> >> > if (panel->backlight.edp.intel.sdr_uses_aux) { > >> >> > + /* Wait 100ms to ensure that panel is ready otherwise > >> >> > it > >> >> > may not > >> >> > +* set chosen backlight level > >> >> > +*/ > >> >> > + msleep(100); > >> >> > ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE; > >> >> > intel_dp_aux_hdr_set_aux_backlight(conn_state, level); > >> >> > } else { > >> >> > >> > >> -- > >> Jani Nikula, Intel Open Source Graphics Center > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on
On Tue, Sep 14, 2021 at 3:31 PM Jani Nikula wrote: > > On Tue, 14 Sep 2021, Lyude Paul wrote: > > On Tue, 2021-09-14 at 12:09 +0300, Jani Nikula wrote: > >> On Mon, 13 Sep 2021, Vasily Khoruzhick wrote: > >> > Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to > >> > control brightness, apparently needs a delay before setting brightness > >> > after power on. Without this delay the panel does accept the setting > >> > and may come up with some arbitrary brightness (sometimes it's too dark, > >> > sometimes it's too bright, I wasn't able to find a system). > >> > > >> > I don't have access to the spec, so I'm not sure if it's expected > >> > behavior or a quirk for particular device. > >> > > >> > Delay was chosen by experiment: it works with 100ms, but fails with > >> > anything lower than 75ms. > >> > >> Looks like we don't respect the panel delays for DPCD backlight. The > >> values are used for setting up the panel power sequencer, and thus PWM > >> based backlight, but we should probably use the delays in DPCD backlight > >> code too. > > > > This makes sense to me, you're referring to the panel delays in the VBT > > correct? > > Yes. See pps_init_delays() and intel_pps_backlight_on(). The delays > aren't applied to DPCD backlight, I think it would make sense if they > were. I guess it explains why it usually stops working after suspend. Probably BIOS doesn't re-init the power sequencer on resume. > BR, > Jani. > > > > >> > >> BR, > >> Jani. > >> > >> > >> > > >> > Signed-off-by: Vasily Khoruzhick > >> > --- > >> > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 > >> > 1 file changed, 4 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> > index 4f8337c7fd2e..c4f35e1b5870 100644 > >> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c > >> > @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct > >> > intel_crtc_state *crtc_state, > >> > > >> > ctrl = old_ctrl; > >> > if (panel->backlight.edp.intel.sdr_uses_aux) { > >> > + /* Wait 100ms to ensure that panel is ready otherwise it > >> > may not > >> > +* set chosen backlight level > >> > +*/ > >> > + msleep(100); > >> > ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE; > >> > intel_dp_aux_hdr_set_aux_backlight(conn_state, level); > >> > } else { > >> > > -- > Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915/dp: add a delay before setting panel brightness after power on
Panel in my Dell XPS 7590, that uses Intel's HDR backlight interface to control brightness, apparently needs a delay before setting brightness after power on. Without this delay the panel does accept the setting and may come up with some arbitrary brightness (sometimes it's too dark, sometimes it's too bright, I wasn't able to find a system). I don't have access to the spec, so I'm not sure if it's expected behavior or a quirk for particular device. Delay was chosen by experiment: it works with 100ms, but fails with anything lower than 75ms. Signed-off-by: Vasily Khoruzhick --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c index 4f8337c7fd2e..c4f35e1b5870 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -210,6 +210,10 @@ intel_dp_aux_hdr_enable_backlight(const struct intel_crtc_state *crtc_state, ctrl = old_ctrl; if (panel->backlight.edp.intel.sdr_uses_aux) { + /* Wait 100ms to ensure that panel is ready otherwise it may not +* set chosen backlight level +*/ + msleep(100); ctrl |= INTEL_EDP_HDR_TCON_BRIGHTNESS_AUX_ENABLE; intel_dp_aux_hdr_set_aux_backlight(conn_state, level); } else { -- 2.33.0
Re: [Intel-gfx] [PATCH v5 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
On Thu, Jan 7, 2021 at 2:52 PM Lyude Paul wrote: > > Currently, every different type of backlight hook that i915 supports is > pretty straight forward - you have a backlight, probably through PWM > (but maybe DPCD), with a single set of platform-specific hooks that are > used for controlling it. > > HDR backlights, in particular VESA and Intel's HDR backlight > implementations, can end up being more complicated. With Intel's > proprietary interface, HDR backlight controls always run through the > DPCD. When the backlight is in SDR backlight mode however, the driver > may need to bypass the TCON and control the backlight directly through > PWM. > > So, in order to support this we'll need to split our backlight callbacks > into two groups: a set of high-level backlight control callbacks in > intel_panel, and an additional set of pwm-specific backlight control > callbacks. This also implies a functional changes for how these > callbacks are used: > > * We now keep track of two separate backlight level ranges, one for the > high-level backlight, and one for the pwm backlight range > * We also keep track of backlight enablement and PWM backlight > enablement separately > * Since the currently set backlight level might not be the same as the > currently programmed PWM backlight level, we stop setting > panel->backlight.level with the currently programmed PWM backlight > level in panel->backlight.pwm_funcs->setup(). Instead, we rely > on the higher level backlight control functions to retrieve the > current PWM backlight level (in this case, intel_pwm_get_backlight()). > Note that there are still a few PWM backlight setup callbacks that > do actually need to retrieve the current PWM backlight level, although > we no longer save this value in panel->backlight.level like before. > > Additionally, we drop the call to lpt_get_backlight() in > lpt_setup_backlight(), and avoid unconditionally writing the PWM value that > we get from it and only write it back if we're in CPU mode, and switching > to PCH mode. The reason for this is because in the original codepath for > this, it was expected that the intel_panel_bl_funcs->setup() hook would be > responsible for fetching the initial backlight level. On lpt systems, the > only time we could ever be in PCH backlight mode is during the initial > driver load - meaning that outside of the setup() hook, lpt_get_backlight() > will always be the callback used for retrieving the current backlight > level. After this patch we still need to fetch and write-back the PCH > backlight value if we're switching from CPU mode to PCH, but because > intel_pwm_setup_backlight() will retrieve the backlight level after setup() > using the get() hook, which always ends up being lpt_get_backlight(). Thus > - an additional call to lpt_get_backlight() in lpt_setup_backlight() is > made redundant. > > v5: > * Fix indenting warnings from checkpatch > v4: > * Fix commit message > * Remove outdated comment in intel_panel.c > * Rename pwm_(min|max) to pwm_level_(min|max) > * Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of > indirection > * Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of > intel_panel_init_backlight_funcs() quite yet > v3: > * Reuse intel_panel_bl_funcs() for pwm_funcs > * Explain why we drop lpt_get_backlight() > > Signed-off-by: Lyude Paul > Cc: thay...@noraisin.net > Cc: Vasily Khoruzhick Whole series is: Tested-by: Vasily Khoruzhick > --- > .../drm/i915/display/intel_display_types.h| 4 + > drivers/gpu/drm/i915/display/intel_panel.c| 333 ++ > 2 files changed, 187 insertions(+), 150 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h > b/drivers/gpu/drm/i915/display/intel_display_types.h > index 1067bd073c95..ee5c2d50b81a 100644 > --- a/drivers/gpu/drm/i915/display/intel_display_types.h > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h > @@ -252,6 +252,9 @@ struct intel_panel { > bool alternate_pwm_increment; /* lpt+ */ > > /* PWM chip */ > + u32 pwm_level_min; > + u32 pwm_level_max; > + bool pwm_enabled; > bool util_pin_active_low; /* bxt+ */ > u8 controller; /* bxt+ only */ > struct pwm_device *pwm; > @@ -263,6 +266,7 @@ struct intel_panel { > struct backlight_device *device; > > const struct intel_panel_bl_funcs *funcs; > + const struct intel_panel_bl_funcs *pwm_funcs; > void (*power)(struct intel_connector *, bool enable); > } backlig
Re: [Intel-gfx] [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels
On Wed, Sep 16, 2020 at 10:19 AM Lyude Paul wrote: > > Since we're about to start adding support for Intel's magic HDR > backlight interface over DPCD, we need to ensure we're properly > programming this field so that Intel specific sink services are exposed. > Otherwise, 0x300-0x3ff will just read zeroes. > > We also take care not to reprogram the source OUI if it already matches > what we expect. This is just to be careful so that we don't accidentally > take the panel out of any backlight control modes we found it in. > > v2: > * Add careful parameter to intel_edp_init_source_oui() to avoid > re-writing the source OUI if it's already been set during driver > initialization > > Signed-off-by: Lyude Paul > Cc: thay...@noraisin.net > Cc: Vasily Khoruzhick Hi Lyude, Sorry for a late reply. Whole series is: Tested-by: Vasily Khoruzhick Regards, Vasily > --- > drivers/gpu/drm/i915/display/intel_dp.c | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 4bd10456ad188..7db2b6a3cd52e 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -3424,6 +3424,29 @@ void intel_dp_sink_set_decompression_state(struct > intel_dp *intel_dp, > enable ? "enable" : "disable"); > } > > +static void > +intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful) > +{ > + struct drm_i915_private *i915 = dp_to_i915(intel_dp); > + u8 oui[] = { 0x00, 0xaa, 0x01 }; > + u8 buf[3] = { 0 }; > + > + /* > +* During driver init, we want to be careful and avoid changing the > source OUI if it's > +* already set to what we want, so as to avoid clearing any state by > accident > +*/ > + if (careful) { > + if (drm_dp_dpcd_read(_dp->aux, DP_SOURCE_OUI, buf, > sizeof(buf)) < 0) > + drm_err(>drm, "Failed to read source OUI\n"); > + > + if (memcmp(oui, buf, sizeof(oui)) == 0) > + return; > + } > + > + if (drm_dp_dpcd_write(_dp->aux, DP_SOURCE_OUI, oui, > sizeof(oui)) < 0) > + drm_err(>drm, "Failed to write source OUI\n"); > +} > + > /* If the sink supports it, try to set the power state appropriately */ > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode) > { > @@ -3443,6 +3466,10 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int > mode) > } else { > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); > > + /* Write the source OUI as early as possible */ > + if (intel_dp_is_edp(intel_dp)) > + intel_edp_init_source_oui(intel_dp, false); > + > /* > * When turning on, we need to retry for 1ms to give the sink > * time to wake up. > @@ -4607,6 +4634,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > intel_dp_get_dsc_sink_cap(intel_dp); > > + /* > +* If needed, program our source OUI so we can make various > Intel-specific AUX services > +* available (such as HDR backlight controls) > +*/ > + intel_edp_init_source_oui(intel_dp, true); > + > return true; > } > > -- > 2.26.2 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware
Hi Zhigang, On Tue, Oct 28, 2014 at 7:31 AM, Zhigang Gong zhigang.g...@linux.intel.com wrote: Vasily, Could you try ImageMagick(convert) again with latest git master beignet(git-e46764f). It should work now. It works fine now. Thank you! Regards, Vasily Thanks, Zhigang Gong. On Fri, Oct 24, 2014 at 04:36:49PM +0300, Vasily Khoruzhick wrote: Hi Zhigang, On Fri, Oct 24, 2014 at 12:13 PM, Zhigang Gong zhigang.g...@linux.intel.com wrote: Hi, Luxmark (both 2.0/2.1) works fine on my IVB machine. The back trace you provided below doesn't indicate it's a beignet related problem. It hadn't enter beignet domain and just crashed in luxmark internal. I'm testing with Luxmark-1.3.1. Luxmark 2.0 works fine. On Fri, Oct 24, 2014 at 12:04:29PM +0300, Vasily Khoruzhick wrote: Hi Zhigang, Luxmark crashes with following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() () (gdb) bt #0 0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() () #1 0x00482236 in slg::RenderEngine::Stop() () #2 0x0047be9b in slg::RenderSession::~RenderSession() () #3 0x00468a77 in LuxMarkApp::Stop() () #4 0x00468b46 in LuxMarkApp::InitRendering(LuxMarkAppMode, char const*) () After a quick analysis, I confirm that the second case is indeed a beignet bug. Beignet lacks of some llvm intrinsics support such as llvm.uadd.with.overflow.i32(). Will fix it next week. Ok, thank you! Thanks, Zhigang Gong. Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware
zhigang.g...@linux.intel.com wrote: I just checked again, and found both 3.17 and 3.17.1 should work fine on IVB with beignet. I just tested beignet on IVB with kernel 3.17.1, all unit tests passed successfully. For IVB user, no need to wait for 3.18. Don't know which application you were testing on your IVB machine. If it could be reproduced easily, please open a bug on fd.o. Thanks, Zhigang Gong. On Fri, Oct 24, 2014 at 10:27:23AM +0800, Zhigang Gong wrote: Hi, For IVB, I just checked the 3.18-rc1, it has the following patch: commit c9224faa59c3071ecfa2d4b24592f4eb61e57069 Author: Brad Volkin bradley.d.vol...@intel.com Date: Tue Jun 17 14:10:34 2014 -0700 drm/i915: Add some L3 registers to the parser whitelist Beignet needs these in order to program the L3 cache config for OpenCL workloads, particularly when using SLM. Signed-off-by: Brad Volkin bradley.d.vol...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch So, beignet should work fine with 3.18 on IVB/BYT. But for the HSW,I'm not quite sure when we could get a workable vanilla kernel. Something I found at the intel-gfx mail list as below and it doesn't sound good. http://lists.freedesktop.org/archives/intel-gfx/2014-May/044694.html http://lists.freedesktop.org/archives/intel-gfx/2014-May/045088.html CC to intel-gfx mail list. Hope we can get an official anwser here. Thanks, Zhigang Gong. On Thu, Oct 23, 2014 at 03:39:35PM +0300, Vasily Khoruzhick wrote: Hi, As you maybe know, any application which uses beignet OpenCL implementation crashes on Ivy Bridge hardware when using vanilla 3.17.1 kernel. I guess it's due to batchbuffer security and patch to disable batchbuffer security is required, but guys, it fails since 3.16, and 3.17 was released quite a while ago. Could you cooperate with i915 driver devs to make Beignet working on vanilla kernel without extra patches? Thanks! Regards, Vasily ___ Beignet mailing list beig...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Beignet] Beignet crashes on vanilla 3.17.1 with IVB hardware
Hi Zhigang, On Fri, Oct 24, 2014 at 12:13 PM, Zhigang Gong zhigang.g...@linux.intel.com wrote: Hi, Luxmark (both 2.0/2.1) works fine on my IVB machine. The back trace you provided below doesn't indicate it's a beignet related problem. It hadn't enter beignet domain and just crashed in luxmark internal. I'm testing with Luxmark-1.3.1. Luxmark 2.0 works fine. On Fri, Oct 24, 2014 at 12:04:29PM +0300, Vasily Khoruzhick wrote: Hi Zhigang, Luxmark crashes with following backtrace: Program received signal SIGSEGV, Segmentation fault. 0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() () (gdb) bt #0 0x004cd8b0 in slg::PathOCLRenderEngine::StopLockLess() () #1 0x00482236 in slg::RenderEngine::Stop() () #2 0x0047be9b in slg::RenderSession::~RenderSession() () #3 0x00468a77 in LuxMarkApp::Stop() () #4 0x00468b46 in LuxMarkApp::InitRendering(LuxMarkAppMode, char const*) () After a quick analysis, I confirm that the second case is indeed a beignet bug. Beignet lacks of some llvm intrinsics support such as llvm.uadd.with.overflow.i32(). Will fix it next week. Ok, thank you! Thanks, Zhigang Gong. Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote: On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote: On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote: Keith, first of all thanks for your prompt reply. Then... On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote: On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov k...@mns.spb.ru wrote: And now after v3.0 is out, I've tested it again, and yes, like it was broken on v3.0-rc5, it is (now even more) broken on v3.0 -- after first bad io access the system freezes completely: I looked at this when I first saw it (a couple of weeks ago), and I couldn't see any obvious reason this patch would cause this particular problem. I didn't want to revert the patch at that point as I feared it would cause other subtle problems. Given that you've got a work-around, it seemed best to just push this off past 3.0. What kind of a workaround are you talking about? Sorry, to me it all looked like UMS is being ignored forever. Anyway, let's move on to try to solve the issue. Given the failing address passed to ioread32, this seems like it's probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit units within the hardware status page. If the status_page.page_addr value was zero, then the computed address would end up being 0x84. And, it looks like status_page.page_addr *will* end up being zero as a result of the patch in question. The patch resets the entire ring structure contents back to the initial values, which includes smashing the status_page structure to zero, clearing the value of status_page.page_addr set in i915_init_phys_hws. Here's an untested patch which moves the initialization of status_page.page_addr into intel_render_ring_init_dri. I note that intel_init_render_ring_buffer *already* has the setting of the status_page.page_addr value, and so I've removed the setting of status_page.page_addr from i915_init_phys_hws. I suspect we could remove the memset from intel_init_render_ring_buffer; it seems entirely superfluous given the memset in i915_init_phys_hws. From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Fri, 22 Jul 2011 10:44:39 -0700 Subject: [PATCH] drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring-status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_dma.c |6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++ 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device *dev) static int i915_init_phys_hws(struct drm_device *dev) { drm_i915_private_t *dev_priv = dev-dev_private; - struct intel_ring_buffer *ring = LP_RING(dev_priv); /* Program Hardware Status Page */ dev_priv-status_page_dmah = @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device *dev) DRM_ERROR(Can not allocate hardware status page\n); return -ENOMEM; } - ring-status_page.page_addr = - (void __force __iomem *)dev_priv-status_page_dmah-vaddr; - memset_io(ring-status_page.page_addr, 0, PAGE_SIZE); + memset_io((void __force __iomem *)dev_priv-status_page_dmah-vaddr, +0, PAGE_SIZE); i915_write_hws_pga(dev); diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e961568..47b9b27 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1321,6 +1321,9 @@ int intel_render_ring_init_dri(struct drm_device *dev, u64 start, u32 size) ring-get_seqno = pc_render_get_seqno; } + if
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote: On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote: On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote: On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote: On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote: Keith, first of all thanks for your prompt reply. Then... On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote: On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov k...@mns.spb.ru wrote: And now after v3.0 is out, I've tested it again, and yes, like it was broken on v3.0-rc5, it is (now even more) broken on v3.0 -- after first bad io access the system freezes completely: I looked at this when I first saw it (a couple of weeks ago), and I couldn't see any obvious reason this patch would cause this particular problem. I didn't want to revert the patch at that point as I feared it would cause other subtle problems. Given that you've got a work-around, it seemed best to just push this off past 3.0. What kind of a workaround are you talking about? Sorry, to me it all looked like UMS is being ignored forever. Anyway, let's move on to try to solve the issue. Given the failing address passed to ioread32, this seems like it's probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit units within the hardware status page. If the status_page.page_addr value was zero, then the computed address would end up being 0x84. And, it looks like status_page.page_addr *will* end up being zero as a result of the patch in question. The patch resets the entire ring structure contents back to the initial values, which includes smashing the status_page structure to zero, clearing the value of status_page.page_addr set in i915_init_phys_hws. Here's an untested patch which moves the initialization of status_page.page_addr into intel_render_ring_init_dri. I note that intel_init_render_ring_buffer *already* has the setting of the status_page.page_addr value, and so I've removed the setting of status_page.page_addr from i915_init_phys_hws. I suspect we could remove the memset from intel_init_render_ring_buffer; it seems entirely superfluous given the memset in i915_init_phys_hws. From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Fri, 22 Jul 2011 10:44:39 -0700 Subject: [PATCH] drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring-status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_dma.c |6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++ 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device *dev) static int i915_init_phys_hws(struct drm_device *dev) { drm_i915_private_t *dev_priv = dev-dev_private; - struct intel_ring_buffer *ring = LP_RING(dev_priv); /* Program Hardware Status Page */ dev_priv-status_page_dmah = @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device *dev) DRM_ERROR(Can not allocate hardware status page\n); return -ENOMEM; } - ring-status_page.page_addr = - (void __force __iomem *)dev_priv-status_page_dmah-vaddr; - memset_io(ring-status_page.page_addr, 0, PAGE_SIZE); + memset_io((void __force __iomem *)dev_priv-status_page_dmah-vaddr, +0, PAGE_SIZE); i915_write_hws_pga(dev); diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index e961568..47b9b27 100644
Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?
On Tuesday 09 August 2011 18:34:46 Kirill Smelkov wrote: On Tue, Aug 09, 2011 at 06:09:57PM +0300, Vasily Khoruzhick wrote: On Tuesday 09 August 2011 17:47:56 Kirill Smelkov wrote: On Tue, Aug 09, 2011 at 05:00:52PM +0300, Vasily Khoruzhick wrote: On Tuesday 09 August 2011 15:08:03 Kirill Smelkov wrote: On Tue, Jul 26, 2011 at 05:48:27PM +0400, Kirill Smelkov wrote: On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote: Keith, first of all thanks for your prompt reply. Then... On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote: On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov k...@mns.spb.ru wrote: And now after v3.0 is out, I've tested it again, and yes, like it was broken on v3.0-rc5, it is (now even more) broken on v3.0 -- after first bad io access the system freezes completely: I looked at this when I first saw it (a couple of weeks ago), and I couldn't see any obvious reason this patch would cause this particular problem. I didn't want to revert the patch at that point as I feared it would cause other subtle problems. Given that you've got a work-around, it seemed best to just push this off past 3.0. What kind of a workaround are you talking about? Sorry, to me it all looked like UMS is being ignored forever. Anyway, let's move on to try to solve the issue. Given the failing address passed to ioread32, this seems like it's probably the call to READ_BREADCRUMB -- I915_BREADCRUMB_INDEX is 0x21, which is an offset in 32-bit units within the hardware status page. If the status_page.page_addr value was zero, then the computed address would end up being 0x84. And, it looks like status_page.page_addr *will* end up being zero as a result of the patch in question. The patch resets the entire ring structure contents back to the initial values, which includes smashing the status_page structure to zero, clearing the value of status_page.page_addr set in i915_init_phys_hws. Here's an untested patch which moves the initialization of status_page.page_addr into intel_render_ring_init_dri. I note that intel_init_render_ring_buffer *already* has the setting of the status_page.page_addr value, and so I've removed the setting of status_page.page_addr from i915_init_phys_hws. I suspect we could remove the memset from intel_init_render_ring_buffer; it seems entirely superfluous given the memset in i915_init_phys_hws. From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Fri, 22 Jul 2011 10:44:39 -0700 Subject: [PATCH] drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring-status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_dma.c |6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++ 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 1271282..8a3942c 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -61,7 +61,6 @@ static void i915_write_hws_pga(struct drm_device *dev) static int i915_init_phys_hws(struct drm_device *dev) { drm_i915_private_t *dev_priv = dev-dev_private; - struct intel_ring_buffer *ring = LP_RING(dev_priv); /* Program Hardware Status Page */ dev_priv-status_page_dmah = @@ -71,10 +70,9 @@ static int i915_init_phys_hws(struct drm_device *dev) DRM_ERROR(Can not allocate hardware status page\n); return -ENOMEM; } - ring-status_page.page_addr = - (void __force __iomem *)dev_priv
Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote: This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help? Sorry, but it does not. glxgears is still jerky. Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use PM QoS to prevent C-state memory starvation of the GPU
On Wednesday 08 December 2010 19:54:59 Andrew Lutomirski wrote: On Wed, Dec 8, 2010 at 12:00 PM, Vasily Khoruzhick anars...@gmail.com wrote: On Wednesday 08 December 2010 18:54:21 Chris Wilson wrote: On Wed, 8 Dec 2010 18:44:41 +0200, Vasily Khoruzhick anars...@gmail.com wrote: On Wednesday 08 December 2010 18:24:35 Chris Wilson wrote: This is just a preliminary attempt to see if this even helps. Obviously some more effort will need to be spent investigating a better choice of latency and when we need to request it, but first: does this help? Sorry, but it does not. glxgears is still jerky. Do you have the 2.6.36.2 candidate patch that fixes pm_qos in? From the description, it looks like pm_qos doesn't work at all without it. Nope, where I can get this patch? Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] less load less performance
On Sunday 31 October 2010 18:44:47 Alexey Fisher wrote: Hallo all, after testing latest intel_drm_next v2.6.36-07547-g100519e on my netbook i have seen interesting issue. Standardly started glxgears performs not so well, it drops some times to 25fps. if start glxgears in fullscrean mode it performs well - about 60fps. It's a know bug for 945GM(E) chipset: https://bugs.freedesktop.org/show_bug.cgi?id=30364 Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
On 27 of September 2010 03:46:23 Shaohua Li wrote: does disable msi help with 'pci=nomsi'? Doesn't help on my system :( ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
On 26 of September 2010 13:53:35 Stefan Biereigel wrote: Hello Everyone, just to add on to reports of this problem, there was a Thread here in LKML some months ago targeting the same problem (but not really attacking it at the Chipset driver). As I have one of those Laptops with a 945GM-Chipset and am stuck with the same Problem (disabled tickless now as a workaround and set ticks to 1000) I could maybe do some testing of patches. So what I can summarize is what the others did before: Disabling CPU1 helps, adding nohz=off helps, changing the Clocksource afterwards helps, binding the Interrupt does NOT help. So here's the Link to the old Discussion with follow-ups, maybe you can get some furter information from there. http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html We targeted the BIOS itself as everyone in this thread happened to own an Phoenix BIOS with some special version string. best, Stefan Yep, my laptop has Phoenix BIOS too. Btw, this BIOS has buggy DSDT (thermal and battery don't work reliably without patching DSDT). But I tested with and without patched DSDT - so my custom DSDT is not cause of bug in my case. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
On 24 of September 2010 22:39:01 Jesse Barnes wrote: On Thu, 16 Sep 2010 23:06:46 +0300 Vasily Khoruzhick anars...@gmail.com wrote: В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал: Ok. The problematic part of HPET was not the clocksource, it was the clock event device which failed to deliver interrupts occasionally. It was worth a try at least. Hm, it seems that jerky glxgears is not related to jerky keyboard events. Keyboard is jerky only in konsole (kde terminal emulator), it seems something happened it seems that font rendering performance is much worse in latest xf86-video-intel than in xf86-video-intel-2.12.0. Len just had me try a few things too: - maxcpus=1 lets things work - offlining cpu1 at runtime (echo 0 /sys/devices/system/cpu/cpu1/online) lets things work - binding the i915 interrupt to cpu 0 does *not* help Vasily and Paolo, do you both have Atom CPUs with hyperthreading enabled? Nope, I have Core2Duo T5500, dual-core, no hyperthreading :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 17 of September 2010 19:30:26 автор Jesse Barnes написал: Yeah if that works we could definitely add some qos calls to the driver. When vblanks are alive we'd need a latency less tha the refresh rate, and when commands are oustanding we'd probably want it even lower. Vasily, can you try the qos workaround on your machine and see if it works too? Thanks, Just give me a patch :) Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал: processor.max_cstate=2 Nope, it doesn't work with max_cstate=2 Perhaps intel_idle is being used? Any mention of it in dmesg? Sitsofe, maybe you misunderstood me, I mean with max_cstate=1 graphics is smooth, with higher values (i.e. max_cstate=2) graphics is jerky. Btw, Jesse, any comments/solutions/workarounds except one with processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo bugzilla? signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал: Btw, Jesse, any comments/solutions/workarounds except one with processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo bugzilla? we fixed a HPET related bug a few days ago, which might be the cause for your problem as well. Nope, it doesn't help :( Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 16 of September 2010 21:30:58 автор Vasily Khoruzhick написал: В сообщении от 16 of September 2010 21:07:39 автор Thomas Gleixner написал: Btw, Jesse, any comments/solutions/workarounds except one with processor.max_cstate=1 in kernel commandline? Should I file a bug on fdo bugzilla? we fixed a HPET related bug a few days ago, which might be the cause for your problem as well. Nope, it doesn't help :( Btw, I suspect hpet is not related, I disabled hpet completely in kernel config but issue is still here (clocksource is acpi_pm) Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал: Ok. The problematic part of HPET was not the clocksource, it was the clock event device which failed to deliver interrupts occasionally. It was worth a try at least. Hm, it seems that jerky glxgears is not related to jerky keyboard events. Keyboard is jerky only in konsole (kde terminal emulator), it seems something happened it seems that font rendering performance is much worse in latest xf86-video-intel than in xf86-video-intel-2.12.0. Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] vsync problems with recent graphics stack and 945gm
Hi there, I've just built graphics stack (xf86-video-intel, libdrm, mesa) from git (but I'm on 2.6.35.x kernel) and still experiencing vsync troubles without composite manager, here's output of glxgears: $ glxgears Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 243 frames in 5.0 seconds = 48.124 FPS 157 frames in 5.0 seconds = 31.300 FPS 155 frames in 5.0 seconds = 30.864 FPS But I'm pretty sure that vertical refresh is 60 hz! And gears are jerky (not smooth at all). If I move mouse cursor over glxgears window FPS goes up to 60. And main problem is that keyboard events are also jerky, i.e. I press key and system receives press event in 0.1-0.5 sec or so (tested via xev). There's no such problem when composition manager is running (i.e. effects are enabled in KDE) Is there any solution for this problem? It really annoys me. Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:19:55 автор Jesse Barnes написал: On Tue, 14 Sep 2010 00:10:08 +0300 Vasily Khoruzhick anars...@gmail.com wrote: В сообщении от 13 of September 2010 23:44:41 автор Jesse Barnes написал: I remember seeing a similar problem on an Eee PC I had; it seemed to be timer/interrupt related somehow. If I booted with clocksource=tsc (or maybe it was pit) I got nice smooth animations, but if I used the HPET things were really slow. Does the same work for you? Yeah, it works for me (will use it as temporary workaround). But it definitely is not clean solution, as I can't use nohz mode with tsc clocksource :) Thomas, does this ring any bells for you? I think the root symptom of the issue is that we get a much reduced i915 interrupt frequency (or no interrupts) on some 945GM platforms when using HPET as our clock source. In fact, on the platform I tested, it seemed that the i915 IRQs wouldn't generate interrupts at all when HPET was used. But shaking the mouse or generating network traffic was enough to get i915 interrupts coming in, even though neither of those interrupts were shared with the i915 device. Here's hoping you have some ideas to try... Thanks, Jesse, is it possible to disable wait for vsync somehow? cpufreq is not working for me with nohz=no for some reason, as result cpu temperature and power usage are higher. I prefer to see tearing but with low power usage and without jerky keyboard :) Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал: Yes, you can set vblank_mode=0 in your environment or drirc. At least I think 0 is no vsync. :) That doesn't help, glxgears shows ~1000fps, but it's output is jerky. signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
В сообщении от 14 of September 2010 00:59:52 автор Jesse Barnes написал: On Tue, 14 Sep 2010 00:52:31 +0300 Vasily Khoruzhick anars...@gmail.com wrote: В сообщении от 14 of September 2010 00:46:32 автор Jesse Barnes написал: Yes, you can set vblank_mode=0 in your environment or drirc. At least I think 0 is no vsync. :) That doesn't help, glxgears shows ~1000fps, but it's output is jerky. Is it smooth with clocksource=tsc? I wonder if the GPU batch interrupts are also getting delayed, and possibly timer ticks... Yes, it's smooth with clocksource=tsc nohz=off Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel 2010Q2 release
В сообщении от 27 июня 2010 15:31:28 автор Chris Wilson написал: On Sun, 27 Jun 2010 14:30:24 +0300, Vasily Khoruzhick anars...@gmail.com wrote: Ok, I'll file bug once I reproduce it once again (can't reproduce it since posted first mail :(). Thankyou, the information will be appreciated. Here it is: https://bugs.freedesktop.org/show_bug.cgi?id=28785 signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel 2010Q2 release
В сообщении от 27 июня 2010 15:31:28 автор Chris Wilson написал: You need libdrm.git, in particular: commit 726210f87d558d558022f35bc8c839e798a19f0c Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Jun 24 11:38:00 2010 +0100 intel: Limit tiled pitches to 8192 on pre-i965. Fixes: Bug 28515 - Failed to allocate framebuffer when exceed 2048 width https://bugs.freedesktop.org/show_bug.cgi?id=28515 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Then you should release new libdrm, you can't say to ordinary users that they need version from git, they just can't compile it. Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] 945gm: xrandr crashes X
Hi, after upgrade to 2.6.34 kernel I'm unable to configure external VGA monitor anymore, any attempt to use xrandr results in X crash with following message: X: intel_bufmgr_gem.c:900: drm_intel_gem_bo_unreference_locked_timed: Assertion `((bo_gem-refcount)-atomic) 0' failed. There's a bug entry in gentoo bugzilla, however they blame xorg-server, but xorg-server-1.8.x works for me with 2.6.33.x kernel: http://bugs.gentoo.org/show_bug.cgi?id=318743 Is it known/fixed issue, or should I file a new bug on fd.o bugzilla? Regards Vasily signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx