On Sat, Jul 27, 2013 at 09:13:38AM +1000, Dave Airlie wrote:
> >
> > Hey, overall it's actually quite a bit of fun.
> >
> > I do agree that QA is really important for a fastpaced process, but
> > it's also not the only peace to get something in. Review (both of the
> > patch itself but also of the
>
> Hey, overall it's actually quite a bit of fun.
>
> I do agree that QA is really important for a fastpaced process, but
> it's also not the only peace to get something in. Review (both of the
> patch itself but also of the test coverage) catches a lot of issues,
> and in many cases not the same
Cool... I'd like to see if Ouping and Mengmeng can work together to get
power & power numbers across a bunch of workloads for these policies.
Ouping & Mengmeng, can you run your usual battery of stuff against each
of these settings and report back the results?
Thanks,
Jesse
On Fri, 26 Jul 2013 2
As a complement to the suggestions put forward by Jesse in
drm/i915: "Scotty, I need more power!"
(1372436290-3297-1-git-send-email-jbar...@virtuousgeek.org)
and
drm/i915: boost GPU and CPU freq when leaving idle
(1372438472-3233-1-git-send-email-jbar...@virtuousgeek.org)
we also have the abili
On Fri, Jul 26, 2013 at 03:42:57PM -0300, Rodrigo Vivi wrote:
> Although I had those 2 doubts and aren't 100% sure this wont cause any
> regression I'm confortable in give my rv-b to full series.
I've added my answers to both questions to the commit messages.
>
> So,
>
> Reviewed-by: Rodrigo Viv
On Fri, Jul 26, 2013 at 02:48:32PM -0700, Ben Widawsky wrote:
> On Tue, Jul 23, 2013 at 06:54:43PM +0200, Daniel Vetter wrote:
> > On Sun, Jul 21, 2013 at 07:08:13PM -0700, Ben Widawsky wrote:
> > > Building on the last patch which created the new function pointers in
> > > the VM for bind/unbind,
On Tue, Jul 23, 2013 at 06:48:09PM +0200, Daniel Vetter wrote:
> On Sun, Jul 21, 2013 at 07:08:11PM -0700, Ben Widawsky wrote:
> > Even though we want to be able to track active by VMA, the rest of the
> > code is still using objects for most internal APIs. To solve this,
> > create an object_is_ac
On Tue, Jul 23, 2013 at 06:54:43PM +0200, Daniel Vetter wrote:
> On Sun, Jul 21, 2013 at 07:08:13PM -0700, Ben Widawsky wrote:
> > Building on the last patch which created the new function pointers in
> > the VM for bind/unbind, here we actually put those new function pointers
> > to use.
> >
> >
Hi Linus,
Please pull from the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
pm+acpi-3.11-rc3
to receive ACPI and power management fixes for v3.11-rc3 with
top-most commit 8e5c2b776ae4c35f54547c017e0a943429f5748a
Revert "ACPI / video / i915: No ACPI ba
On Fri, Jul 26, 2013 at 10:28 PM, H. Peter Anvin wrote:
> On 07/26/2013 01:24 PM, Ingo Molnar wrote:
>>
>> Am I being too pedantic in expecting that we still mark it
>> e820-reserved?
>>
>> This area really isnt an ordinary PCI resource such as a
>> BAR or an MMIO region. It's truly system RAM (wh
On Fri, Jul 26, 2013 at 10:15 PM, Ben Widawsky wrote:
> I think the subthread Jesse started had a bunch of good points, but
> concisely I see 3 problems with our current process (and these were
> addressed in my original mail, but I guess you didn't want to air my
> dirty laundry :p):
I've cut ou
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
v4: fix up PCI match structure init for easier use by userspace (Chris)
Signed-off-by: Jesse Barnes
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not always marked in the E820 as
reserved or as RAM, and so is subject to overlap from E820 manipulation
later in the boot process. On some systems, MMIO space is allocated on
top, despite the
These address the comments I've received so far, but omit the new E820
type for this mem.
Chris's patches could go on top if desired; they add a new type and
resource reservation function for looking up regions by name. That
allows us to remove some duplicate code in the driver for finding stolen
On 07/26/2013 01:24 PM, Ingo Molnar wrote:
>
> Am I being too pedantic in expecting that we still mark it
> e820-reserved?
>
> This area really isnt an ordinary PCI resource such as a
> BAR or an MMIO region. It's truly system RAM (which cannot
> be moved/reallocated), used by graphics hardwar
On Fri, Jul 26, 2013 at 11:51:00AM +0200, Daniel Vetter wrote:
> HI all,
>
> So Ben&I had a bit a private discussion and one thing I've explained a bit
> more in detail is what kind of review I'm doing as maintainer. I've
> figured this is generally useful. We've also discussed a bit that for
> de
Hi all,
New feature tree pushed, hightlights:
- proper eLLC support for HSW from Ben
- more interrupt refactoring
- add w/a tags where we implement them already (Damien)
- hangcheck fixes (Chris) + hangcheck stats (Mika)
- flesh out the new vm structs for ppgtt and ggtt (Ben)
- PSR for Haswell, st
On Fri, Jul 26, 2013 at 07:54:22PM +0200, Daniel Vetter wrote:
> On Fri, Jul 26, 2013 at 01:21:48PM +0300, Jani Nikula wrote:
> > On Fri, 26 Jul 2013, Daniel Vetter wrote:
> > > Apparently Bspec is wrong in this case here even for gm45. Note that
> > > Bspec is horribly misguided on i965g/gm, so w
On Fri, Jul 26, 2013 at 03:40:52PM -0300, Rodrigo Vivi wrote:
> On Sun, Jul 21, 2013 at 4:37 PM, Daniel Vetter wrote:
> > In the old days of the crtc helpers we've only had the encoder and
> > crtc ->mode_fixup callbacks. So when the lvds connector wanted to
> > adjust the crtc timings it had to s
On Fri, Jul 26, 2013 at 03:39:51PM -0300, Rodrigo Vivi wrote:
> On Sun, Jul 21, 2013 at 4:36 PM, Daniel Vetter wrote:
> > This is the last encoder ->mode_fixup callback we have left, so
> > convert it.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_dvo.c | 14 +++
Otherwise we get flooded by the kernel warning us that we are doing
long sequences of IO without serialisation. For example,
WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40
vlv_sideband_rw+0x48/0x1ef()
Modules linked in:
CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G
Although I had those 2 doubts and aren't 100% sure this wont cause any
regression I'm confortable in give my rv-b to full series.
So,
Reviewed-by: Rodrigo Vivi
On Sun, Jul 21, 2013 at 4:36 PM, Daniel Vetter wrote:
> Hi all,
>
> I've figured it's time that we rip out our legacy modeset encode
On Sun, Jul 21, 2013 at 4:37 PM, Daniel Vetter wrote:
> In the old days of the crtc helpers we've only had the encoder and
> crtc ->mode_fixup callbacks. So when the lvds connector wanted to
> adjust the crtc timings it had to set a driver-private mode flag to
> tell the crtc mode fixup code to no
On Sun, Jul 21, 2013 at 4:36 PM, Daniel Vetter wrote:
> This is the last encoder ->mode_fixup callback we have left, so
> convert it.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dvo.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/
On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf Förster wrote:
> Realized this today while booting a ThinkPad T420 with integrated intel
> graphic :
Can you please retest with latest upstream git from Linus' tree?
commit 35c95375f69ceec721fea67a0532bc17ceb5cf64
Author: Daniel Vetter
Date: We
On Fri, Jul 26, 2013 at 11:18:21AM +0300, Jani Nikula wrote:
> On Fri, 26 Jul 2013, Daniel Vetter wrote:
> > We need the correct clock to accurately assess whether we need to
> > enable the double wide pipe mode or not.
> >
> > Cc: Chris Wilson
> > Cc: Stéphane Marchesin
> > Cc: Stuart Abercromb
On Fri, Jul 26, 2013 at 01:21:48PM +0300, Jani Nikula wrote:
> On Fri, 26 Jul 2013, Daniel Vetter wrote:
> > Apparently Bspec is wrong in this case here even for gm45. Note that
> > Bspec is horribly misguided on i965g/gm, so we don't have any other
> > data points besides that it seems to make ma
On Thu, Jul 25, 2013 at 05:48:42PM -0700, H. Peter Anvin wrote:
> On 07/25/2013 05:31 PM, Linus Torvalds wrote:
> > On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> >> So the bootloader is just as likely to step on things... what happens
> >> when/if it does?
> >
> > This isn't a new pro
On Sun, Jul 21, 2013 at 05:23:11PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx m
On Fri, Jul 26, 2013 at 02:40:01PM +0300, Jani Nikula wrote:
> On Sun, 21 Jul 2013, Chris Wilson wrote:
> > The w/a db makes the recommendation to both use a non-default value for
> > the initial clock and then to retry with an alternative clock for
> > Haswell with the Lakeport PCH.
> >
> > "On L
On Fri, Jul 26, 2013 at 03:23:54PM +0300, Jani Nikula wrote:
> On Fri, 26 Jul 2013, Egbert Eich wrote:
> > For HPD storm detection we now mask out individual interrupt source
> > bits. We have already seen a case where HPD interrupt enable bits
> > were assigned to the wrong pins. To track these c
On Fri, Jul 26, 2013 at 7:11 PM, Chris Wilson wrote:
>> The problem here is that Jesse was lazy and grabs the lock in
>> vlv_crtc_enable, so I think your code here will deadlock. But I agree
>> that grabbing the lock where we actually frob the sideband is what we
>> want ...
>
> Looks like vlv_crt
On 07/25/2013 09:37 AM, Jesse Barnes wrote:
> Systems with Intel graphics controllers set aside memory exclusively for
> + /*
> + * Almost universally we can find the Graphics Base of Stolen Memory
> + * at offset 0x5c in the igfx configuration space. On a few (desktop)
> + * mac
Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote:
> > > > Linus, do you want me to send a p
On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> To clarify: it'll either be marked reserved or not listed at all in e820,
> which is why I did this early, before any other e820 stuff like the "RAM
> buffer" are allocated, and before we could use the iomem resource (or maybe
> we could even early p
On 25.07.2013 21:47, Rafael J. Wysocki wrote:
Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.
Before reverting the patch /sys/class/backlight was empty and backlight
brightness was set to max, now it
On 07/25/2013 04:17 PM, Jesse Barnes wrote:
> Well, it's ok if the boot loader writes to this memory, the worst
> that'll happen is you'll see garbage on the screen. If the boot loader
> tries to do MMIO mapping on top it'll get into trouble... but why would
> it do that?
>
> Jesse
Much worse: i
On 07/25/2013 05:31 PM, Linus Torvalds wrote:
> On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
>> So the bootloader is just as likely to step on things... what happens
>> when/if it does?
>
> This isn't a new problem. We've had this "firmware tables don't show
> all devices" issue before
Hi Daniel,
Am 25.07.2013 11:58, schrieb Daniel Vetter:
Can you pls try the below
patch (on top of Egbert's debug stuff)?
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 6caa748..2d4c884 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/
So the bootloader is just as likely to step on things... what happens when/if
it does?
Ingo Molnar wrote:
>
>* Jesse Barnes wrote:
>
>> Patch 2/2 has the description, but suffice it to say I'm
>> not really pleased with this, though it does solve a
>> problem we have. On some machines, we ge
2013/7/25 Rafael J. Wysocki :
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote:
>> > >
>> > > Linus, do you want me to send a pull request reverting 8c5bd7a an
2013/7/25 Jörg Otte :
> 2013/7/25 Rafael J. Wysocki :
>> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote:
>>> > >
>>> > > Linus, do you want me to send a pull
On 25 July 2013 14:00, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote:
>> > >
>> > > Linus, do you want me to send a pull request r
Hi Egbert,
Am 23.07.2013 13:26, schrieb Egbert Eich:
I've looked at the logs a bit more. Here's a patch adding some more
debug information. Would you please apply this to your 3.10 kernel
and generate a log file the same way as you did before.
The driver will be even more chatty - but I don't ex
On Fri, Jul 26, 2013 at 09:59:42AM -0700, Jesse Barnes wrote:
> On Fri, 26 Jul 2013 11:51:00 +0200
> Daniel Vetter wrote:
>
> > HI all,
> >
> > So Ben&I had a bit a private discussion and one thing I've explained a bit
> > more in detail is what kind of review I'm doing as maintainer. I've
> > f
On Fri, 26 Jul 2013 18:08:48 +0100
Chris Wilson wrote:
> On Fri, Jul 26, 2013 at 09:59:42AM -0700, Jesse Barnes wrote:
> > 4) review comments should be concrete and actionable, and ideally not
> > leave the author hanging with hints about problems the reviewer
> > has spotted, leaving
On Fri, 26 Jul 2013 09:58:45 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 09:37 AM, Jesse Barnes wrote:
> > Systems with Intel graphics controllers set aside memory exclusively for
> > + /*
> > +* Almost universally we can find the Graphics Base of Stolen Memory
> > +* at offset 0x5c i
On Fri, Jul 26, 2013 at 06:46:43PM +0200, Daniel Vetter wrote:
> On Fri, Jul 26, 2013 at 6:17 PM, Chris Wilson
> wrote:
> > Otherwise we get flooded by the kernel warning us that we are doing
> > long sequences of IO without serialisation. For example,
> >
> > WARNING: CPU: 0 PID: 11136 at drive
On Fri, Jul 26, 2013 at 09:59:42AM -0700, Jesse Barnes wrote:
> 4) review comments should be concrete and actionable, and ideally not
> leave the author hanging with hints about problems the reviewer
> has spotted, leaving the author looking for easter eggs
Where am I going to find my
On Fri, 26 Jul 2013 11:51:00 +0200
Daniel Vetter wrote:
> HI all,
>
> So Ben&I had a bit a private discussion and one thing I've explained a bit
> more in detail is what kind of review I'm doing as maintainer. I've
> figured this is generally useful. We've also discussed a bit that for
> develop
On Fri, Jul 26, 2013 at 6:17 PM, Chris Wilson wrote:
> Otherwise we get flooded by the kernel warning us that we are doing
> long sequences of IO without serialisation. For example,
>
> WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40
> vlv_sideband_rw+0x48/0x1ef()
> Modul
Otherwise we get flooded by the kernel warning us that we are doing
long sequences of IO without serialisation. For example,
WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40
vlv_sideband_rw+0x48/0x1ef()
Modules linked in:
CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G
On Thu, 25 Jul 2013 17:31:29 -0700
Linus Torvalds wrote:
> On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> > So the bootloader is just as likely to step on things... what happens
> > when/if it does?
>
> This isn't a new problem. We've had this "firmware tables don't show
> all device
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > To clarify: it'll either be marked reserved or not listed at all in e820,
> > which is why I did this early, before any other e820 stuff like the "RAM
> > buffer" are allocated, and befo
[distribution massively reduced]
On Sat, 20 Jul 2013, Felipe Contreras wrote:
> I tried this patch series and it's as I expected, it's the same as
> acpi_backlight=vendor, and the intel backlight driver doesn't work
> correctly in this machine. If you are actually serious about the
> mantra of "
On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote:
> Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > On Mon, Jul 22, 2013 at 6:02
On Fri, 26 Jul 2013, Egbert Eich wrote:
> For HPD storm detection we now mask out individual interrupt source
> bits. We have already seen a case where HPD interrupt enable bits
> were assigned to the wrong pins. To track these conditions more
> easily add some debugging messages.
>
> v2: Spelling
For HPD storm detection we now mask out individual interrupt source
bits. We have already seen a case where HPD interrupt enable bits
were assigned to the wrong pins. To track these conditions more
easily add some debugging messages.
v2: Spelling fixes as suggested by Jani Nikula
Signed-off-by:
Chris Wilson writes:
> On Fri, Jul 26, 2013 at 12:31:30PM +0200, Egbert Eich wrote:
> > Add posting read to make sure PORT_HOTPLUG_EN is written in
> > i915_hpd_irq_setup().
>
> It's not vital that the write be flushed here. On the deferred reenable
> path a further delay in rearming is not
On Fri, Jul 26, 2013 at 12:31:30PM +0200, Egbert Eich wrote:
> Add posting read to make sure PORT_HOTPLUG_EN is written in
> i915_hpd_irq_setup().
It's not vital that the write be flushed here. On the deferred reenable
path a further delay in rearming is not significant, and inside the irq
handler
On Sun, 21 Jul 2013, Chris Wilson wrote:
> The w/a db makes the recommendation to both use a non-default value for
> the initial clock and then to retry with an alternative clock for
> Haswell with the Lakeport PCH.
>
> "On LPT:H, use a divider value of 63 decimal (03Fh). If there is a
> failure,
On Fri, 26 Jul 2013, Egbert Eich wrote:
> For HPD storm detection we now mask out individual interrupt source
> bits. We have already seen a case where HPD interrupt enable bits
> were assigned to the wrong pins. To track these conditions more
> easily add some debugging messages.
The code seems
On Thu, 2013-07-25 at 21:47 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
> > On 25 July 2013 14:00, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds
On Fri, Jul 26, 2013 at 11:32 AM, Sedat Dilek wrote:
> On Fri, Jul 26, 2013 at 11:16 AM, Daniel Vetter
> wrote:
>> On Fri, Jul 26, 2013 at 11:11 AM, Sedat Dilek wrote:
>>
>>> I have compared next-20130725 VS. next-20130726:
>>>
>>> $ head -23
Add posting read to make sure PORT_HOTPLUG_EN is written in
i915_hpd_irq_setup().
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/i915/i915_irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1f3a971..a38372b 100644
---
For HPD storm detection we now mask out individual interrupt source
bits. We have already seen a case where HPD interrupt enable bits
were assigned to the wrong pins. To track these conditions more
easily add some debugging messages.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/i915/i915_irq.c
On Fri, 26 Jul 2013, Daniel Vetter wrote:
> Apparently Bspec is wrong in this case here even for gm45. Note that
> Bspec is horribly misguided on i965g/gm, so we don't have any other
> data points besides that it seems to make machines work better.
>
> With this changes all the bits in PORT_HOTPLU
On Fri, Jul 26, 2013 at 11:16 AM, Daniel Vetter wrote:
> On Fri, Jul 26, 2013 at 11:11 AM, Sedat Dilek wrote:
>
>> I have compared next-20130725 VS. next-20130726:
>>
>> $ head -2313 next-20130725-VS-next-20130726.diff | grep ^+ | grep i915
>> + drm/i915: Colo
Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.
With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same wa
On Fri, Jul 26, 2013 at 11:11 AM, Sedat Dilek wrote:
> I have compared next-20130725 VS. next-20130726:
>
> $ head -2313 next-20130725-VS-next-20130726.diff | grep ^+ | grep i915
> + drm/i915: Colocate all GT access routines in the same file
> + drm/i915: Use a privat
t; >
>>>>
>>>> Now, really w/ promised attachment.
>>>
>>> Yes, same failure (GTT mmaps) but at a later point, and UXA has no
>>> fallback plan.
>>
>> I'm running igt on my machines here to prep a new -next test cycle,
>>
t at a later point, and UXA has no
>> fallback plan.
>
> I'm running igt on my machines here to prep a new -next test cycle,
> and gtt mmaps seem to fail across the board :( Currently I'd wager
> that the vma offset manager is the culprit, since I've only recently
>
On Fri, Jul 26, 2013 at 10:50 AM, Chris Wilson wrote:
> On Fri, Jul 26, 2013 at 10:27:03AM +0200, Sedat Dilek wrote:
>> On Fri, Jul 26, 2013 at 10:25 AM, Sedat Dilek wrote:
>> > ...
>> > ... but does not start as well, so it seems to be a kernel-issue as
>> > assumed (2nd confirmation).
>> >
>> >
On Fri, Jul 26, 2013 at 10:27:03AM +0200, Sedat Dilek wrote:
> On Fri, Jul 26, 2013 at 10:25 AM, Sedat Dilek wrote:
> > ...
> > ... but does not start as well, so it seems to be a kernel-issue as
> > assumed (2nd confirmation).
> >
> > X.log attached.
> >
>
> Now, really w/ promised attachment.
nd yes,
> this means we do require a kernel bisect - or some passing inspiron.
First confirmation...
OK, next-20130726 shows the same symptoms!
I tried diverse intel-ddx release and went back to v2.21.9... and
searched for a version like v2.20.0 which has no checking for map
failures...
On Fri, 26 Jul 2013, Daniel Vetter wrote:
> We need the correct clock to accurately assess whether we need to
> enable the double wide pipe mode or not.
>
> Cc: Chris Wilson
> Cc: Stéphane Marchesin
> Cc: Stuart Abercrombie
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_reg.
On Thu, Jul 25, 2013 at 09:37:49AM -0700, Jesse Barnes wrote:
> Systems with Intel graphics controllers set aside memory exclusively for
> gfx driver use. This memory is not marked in the E820 as reserved or as
> RAM, and so is subject to overlap from E820 manipulation later in the
> boot process.
On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki wrote:
> > > >
> > > > Linus, do you want me to send a
On Fri, Jul 26, 2013 at 08:35:41AM +0200, Daniel Vetter wrote:
> According to configdb the same register as for gen4 also exists on
> pnv. Try to use it.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
I think I also remember it dying terminally afterwards (some missing
reinit), but it's be
On Fri, Jul 26, 2013 at 09:15:14AM +0200, Sedat Dilek wrote:
> For example: I could start my X with even doing ugly hacks like this...
>
> [ intel-ddx (git) ]
> ...
> Bool intel_uxa_create_screen_resources(ScreenPtr screen)
> ...
> #if 0
> if (drm_intel_gem_bo_map_gtt(bo))
> re
On Fri, Jul 26, 2013 at 08:35:42AM +0200, Daniel Vetter wrote:
> We need the correct clock to accurately assess whether we need to
> enable the double wide pipe mode or not.
>
> Cc: Chris Wilson
> Cc: Stéphane Marchesin
> Cc: Stuart Abercrombie
> Signed-off-by: Daniel Vetter
I have not found
t;> > intel_set_pixmap_bo(pixmap, bo);
>> >
>> > which is most likely to report EINVAL (22)?
>>
>> Yupp, this shows me...
>>
>> [28.542] (II) GLX: Initialized DRI2 GL provider for screen 0
>> [28.543] intel_uxa_create_screen_resources
82 matches
Mail list logo
