On Sun, Oct 30, 2011 at 06:29:13PM -0700, Ben Widawsky wrote:
> I didn't really check to see if there is actually an issue here, but
> instead of 60, do you want to play nice with timeouts such as
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT (ie. the min of all the timeouts and
> 60)?
Yeah, 60s should be ha
On Sun, Oct 30, 2011 at 08:16:45PM -0700, Ben Widawsky wrote:
[snip]
> -int
> -i915_gpu_idle(struct drm_device *dev)
> +int i915_gem_gpu_idle(struct drm_device *dev, bool strictly_idle)
> {
> drm_i915_private_t *dev_priv = dev->dev_private;
> int ret, i;
>
> /* Flush everythi
On Sun, Oct 30, 2011 at 06:50:05PM -0700, Ben Widawsky wrote:
> Ah, just saw patch 5... I guess I find this a little weird way to break
> it up, but I think I did a much worse job in my patches.
Safe when the change is really small (i.e. a few one-liner hunks), always
separate the refactor from th
Hi, all.
SW Kim gmail.com> writes:
>
> Daniel Vetter ffwll.ch> writes:
>
> [snip]
>
> > > struct drm_mode_fb_cmd2 {
> > > __u32 fb_id;
> > > __u32 width, height;
> > > __u32 pixel_format; /* fourcc code from videodev2.h */
> > > __u64 priv; /* private data, depends on pixelformat */
I have a question about ironlake_panel_vdd_work(). Should it use
the device struct_mutex, or need it to be the mode_config.mutex
instead ?
pgpc539Zhpaxd.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lis
On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> I have a question about ironlake_panel_vdd_work(). Should it use
> the device struct_mutex, or need it to be the mode_config.mutex
> instead ?
Yeah. This was actually flagged in review by Chris and me, but seems to
have been lo
On Mon, Oct 31, 2011 at 12:15:45 +1100, Bojan Smojver wrote:
> On Sun, 2011-10-30 at 16:57 +, Chris Wilson wrote:
> > Bugs fixed in this snapshot (compared to 2.16.0)
>
> No hibernation memory corruption fix. Sniff, sniff... :-(
>
Pretty sure what you should be looking for is in the kernel,
On Sun, 30 Oct 2011 19:30:08 -0400, Chun-Yu Shei wrote:
> I had to disable sna in 2.16.0 when running compiz or I'd get some
> graphics corruption, and the problem seems to still exist in 2.16.901 as
> well. Here's a screenshot I just took on the RC with sna enabled:
> http://i.imgur.com/UtQpv
On Mon, 31 Oct 2011 11:40:57 + (UTC)
Inki Dae wrote:
> below is my simple idea.
> 1. user requests buffer allocation with pixel format and resolution through
> gem framework.
> 2. gem framework checks pixel format.
> 3. specific gem framework allocates buffers as plane count according to the
On 10/29/11 9:00 AM, Jarek wrote:
Is there something beside the modeline, which my affect setting display
mode ? How to compare what is set with iegd that the display is working,
and how to force xf86-video-intel to do the same ?
The first thing that comes to mind is infoframe setup for HDMI.
On Sat, 29 Oct 2011 00:05:22 -0700
"Keith Packard" wrote:
>
> Steve Langasek came over today and we hacked on the i915 driver
> initialization code to try and avoid the initial mode set. I thought I'd
> summarize what we found out.
>
> * Ubuntu has hacked up grub2 so that it gets the boot mon
This patchset adds support for enabling SNA support via a configuration
file option.
This way, it is possible to switch between UXA and SNA via config file changes,
instead of having to recompile and install full driver.
Second patch goes a bit onwards and also unifies the options between SNA and
This allows to use UXA and SNA from within the same driver, by setting
an "UseSNA" option in the driver config - for example, by creating an
/etc/X11/xorg.conf.d/99-intel-sna.conf:
Section "Device"
Identifier "intel"
driver "intel"
Option "UseSna" "True"
EndSection
This al
Unifies available options for both UXA and SNA drivers, and
moves them into a common header file, intel_opts.h.
Signed-off-by: Eugeni Dodonov
---
src/intel_driver.c | 63
src/intel_module.c |8 ++---
src/intel_opts.h|
Dnia 2011-10-31, pon o godzinie 12:42 -0400, Adam Jackson pisze:
> On 10/29/11 9:00 AM, Jarek wrote:
>
> > Is there something beside the modeline, which my affect setting display
> > mode ? How to compare what is set with iegd that the display is working,
> > and how to force xf86-video-intel to d
On 10/29/11 3:05 AM, Keith Packard wrote:
* Would UEFI do any better? It does provide a native mode on my MBA,
it would be nice to know if this is at all common on regular PC
hardware that has UEFI support.
UEFI firmwares are not required to get native mode on the panel right by
On 10/30/11 12:24 AM, Keith Packard wrote:
On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" wrote:
* I've got LVDS pulling the current mode out of the hardware
With a machine that has a native VBE mode for the panel, the problem is
that clock computed from the hardware settings is not
On 10/31/11 1:48 PM, Jarek wrote:
Dnia 2011-10-31, pon o godzinie 12:42 -0400, Adam Jackson pisze:
Also, how does the output of intel_reg_dumper compare between the two
drivers?
As I understand, I should execute it, from running xorg. Am I right?
Yes.
If I will find difference, what should
On Mon, 31 Oct 2011 14:34:46 +0100, Daniel Vetter wrote:
> On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> > I have a question about ironlake_panel_vdd_work(). Should it use
> > the device struct_mutex, or need it to be the mode_config.mutex
> > instead ?
>
> Yeah. This was
On Mon, 31 Oct 2011 12:56:58 -0400, Adam Jackson wrote:
> Yeah, it won't be precise. That's why there's PLL search code at all,
> and why it has a fuzz factor for finding "good enough".
Right, so we'll need a similar fuzz factor when deciding whether we
actually need to flip modes or not. Make
On Mon, 31 Oct 2011 09:57:26 -0700, Jesse Barnes
wrote:
> Easier to just copy the contents out of the current framebuffer into a
> new one before flipping to the new buffer.
I'm not excited about doing the copy, but I don't see a better plan --
we want to be able to use stolen memory for other
On 10/31/11 2:43 PM, Keith Packard wrote:
On Mon, 31 Oct 2011 12:56:58 -0400, Adam Jackson wrote:
Yeah, it won't be precise. That's why there's PLL search code at all,
and why it has a fuzz factor for finding "good enough".
Right, so we'll need a similar fuzz factor when deciding whether we
On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov
wrote:
> This allows to avoid talking to a non-existent bus repeatedly until we
> finally timeout. The non-existent bus is signalled by -ENXIO error,
> provided by i2c_algo_bit:bit_doAddress call.
>
> As the advantage of such change, all the oth
On Fri, Oct 14, 2011 at 4:46 PM, Simon Que wrote:
> In the native backlight driver, use 4096 (0x1000) as the default backlight
> period, and use the period as the default max brightness.
>
> The default brightness is defined in a separate function that can be
> expanded to allow for different defa
--- Original message ---
From: Julien Cristau
Pretty sure what you should be looking for is in the kernel, not the X
driver.
I thought this announcement covered the kernel side of things too, which it
then obviously does not. OK, there is hope then. ;-)
--
Bojan
_
On Mon, Oct 31, 2011 at 11:33:22AM -0700, Keith Packard wrote:
> On Mon, 31 Oct 2011 14:34:46 +0100, Daniel Vetter wrote:
> > On Mon, Oct 31, 2011 at 03:01:33PM +0200, Konstantin Belousov wrote:
> > > I have a question about ironlake_panel_vdd_work(). Should it use
> > > the device struct_mutex, o
On Fri, Oct 14, 2011 at 04:46:57PM -0700, Simon Que wrote:
Sorry, I thought I'd replied to this already. Sorry about that.
> +static u32 intel_panel_get_default_backlight_period(struct drm_device *dev)
> +{
> + /* The default number of clock cycles in one backlight PWM period. */
> + retu
I do not use hibernate, I have my lid close set to suspend.
Up until I upgraded to 3.2.0 kernel (rawhide) my suspend/wakup cycles
had been stable.
On Sat, Oct 29, 2011 at 01:45:31AM +1100, Bojan Smojver wrote:
> --- Original message ---
> >From: Nicolas Kalkhof
>
> >No Idea if all of the
28 matches
Mail list logo
