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.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 2
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
---
drivers/gpu/drm/i915/intel_uncore.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncor
On Thu, Jul 25, 2013 at 11:01 PM, Daniel Vetter wrote:
> On Tue, Jun 25, 2013 at 1:28 AM, Stuart Abercrombie
> wrote:
>> This is with the patch.
>
> Hm, nothing really interesting bug I've finally gotten around to some
> doc reading and they seem to insist pretty hard that double wide mode
> on p
On Tue, Jun 25, 2013 at 1:28 AM, Stuart Abercrombie
wrote:
> This is with the patch.
Hm, nothing really interesting bug I've finally gotten around to some
doc reading and they seem to insist pretty hard that double wide mode
on pipe A only works if we have pipe A linked up with cursor/plane A.
Bu
Jan Niggemann writes:
> 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
> > --
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 14c5cec5d0cd ("drm/i915:
initialize gt_lock early with other spin locks") from the drm-intel-fixes
tree and commit 907b28c56ea4 ("drm/i915: Colocate all GT access routines
in the
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 per Linus? I'll check).
Jesse
--
Jesse Barnes, In
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.
The only odd thing about this one is how the quirk in
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> >> What means the bang line?
> >>
> >> [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> >> [
On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
>> What means the bang line?
>>
>> [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
>> [54.565] bang: 1159
>> [54.565]
>> Fatal server error:
>> [54.565]
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson wrote:
> Hmm, interesting licence block in i915_pciids.h - our claim to
> grant licence but TG disclaims liability.
Oops my manual search & replace obviously failed. Will fix up.
--
Jesse Barnes, Intel Open Source Technology Center
_
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
On Thu, 25 Jul 2013 15:42:25 -0700
"H. Peter Anvin" wrote:
> So the
On Thu, Jul 25, 2013 at 09:37:48AM -0700, Jesse Barnes wrote:
> 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)
One last comment!
> +#defin
Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/
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.
By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.
v2: Also need to add the string to a sec
As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code to
This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.
v2: We need to recurse through the resource tree as the named region we
are looking for may be a grandchild of the root node.
Signed-off-by: Chris Wilson
Cc: Jesse Barnes
---
include/linux/ioport.h | 2
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c..4a118c3 100644
--- a/d
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37 +
> Generally I think checking our current sw state instead of reading hw
> registers would be safer, e.g. in case we start to queue up more than
> one pageflip. For async pageflips in benchmark mode "flip as fast as
> you can queue" would be a sensible mode.
Ok, I've moved the tiling checks to the
On Thu, Jul 25, 2013 at 01:16:48PM -0700, Jesse Barnes wrote:
> On Thu, 25 Jul 2013 22:05:51 +0200
> Ingo Molnar wrote:
> > > Chris has some patches on top to add a new E820 type so
> > > we can look up the region later, which removes some
> > > redundant code in the i915 driver at least.
> > >
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
> What means the bang line?
>
> [54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
> [54.565] bang: 1159
> [54.565]
> Fatal server error:
> [54.565] failed to create screen resources
That means between the kern
On Thu, 25 Jul 2013 22:05:51 +0200
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 get MMIO space
> > allocated on top of this hidd
On Thu, Jul 25, 2013 at 9:32 PM, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 9:22 PM, Chris Wilson
> wrote:
>> On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
>>> New -3 dmesg.
>>
>> That puts the ball back in the ddx's court. Next debugging patch:
>>
>> diff --git a/src/intel_driv
Hi Dave,
Brown-paper-bag pull request here. The snb rc6 fix from the last pull
broke forcewake BIOS dirt cleanup, which with fixed. But that fix broke
the spinlock init sequence, which results in an ugly BUG when spinlock
debugging is enabled :( So I get to throw another patch at cc: stable to
fix
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 wrote:
> >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki w
On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
> New -3 dmesg.
That puts the ball back in the ddx's court. Next debugging patch:
diff --git a/src/intel_driver.c b/src/intel_driver.c
index f4d76bb..1f4f299 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -170,6 +170,7 @@ s
On Thu, Jul 25, 2013 at 08:50:59PM +0200, Sedat Dilek wrote:
> Against what tree is this applicable? It is definitely not drm-intel-nightly.
Applied cleanly to nightly here, but just in case here's a rebased version:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
i
On Thu, Jul 25, 2013 at 8:45 PM, Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
>> On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek wrote:
>> > F*ck. Wrong patch refreshed.
>> >
>>
>> New dmesg attached.
>
> Hmm, not seeing any difference, so let's add a couple mor
On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek wrote:
> > F*ck. Wrong patch refreshed.
> >
>
> New dmesg attached.
Hmm, not seeing any difference, so let's add a couple more lines just to
be sure:
(apologies I didn't stash the previou
On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson
> wrote:
> > On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> >> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> >> wrote:
> >> > Basically boils down to either an object a
On Thu, Jul 25, 2013 at 7:52 PM, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson
> wrote:
>> On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
>>> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
>>> wrote:
>>> > Basically boils down to either an object allocation fa
On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
>> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
>> wrote:
>> > Basically boils down to either an object allocation failure or mmaping
>> > failure. I think dmesg with drm.debug=7
On Thu, Jul 25, 2013 at 7:27 PM, Jesse Barnes wrote:
> On Thu, 25 Jul 2013 18:17:59 +0100
> Chris Wilson wrote:
>
>> On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
>> > Art confirms that this should work fine. Since most panels are 18bpp
>> > with dithering from 24bpp, the existin
On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
> > Art confirms that this should work fine. Since most panels are 18bpp
> > with dithering from 24bpp, the existing code wouldn't be enabled in most
> > cases.
> >
> > Signed-
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
> On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson
> wrote:
> > Basically boils down to either an object allocation failure or mmaping
> > failure. I think dmesg with drm.debug=7 is the next step.
>
> Attached! Thanks for taking care.
Hm
On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
> Art confirms that this should work fine. Since most panels are 18bpp
> with dithering from 24bpp, the existing code wouldn't be enabled in most
> cases.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_display.c |
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
VT switch
> >> [ 40.396] ddxSigGiveUp: Closing log
> >> [40.398] Server terminated with error (1). Closing log file.
> >
> > Please attach the full Xorg.0.log so that I can make a few guesses.
>
> Linux-kernel: This happens with drm-intel-nightly pulled into
On 07/24/2013 05:04 PM, Jesse Barnes wrote:
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)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i9
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 some systems, MMIO space is allocated on top, despite
the efforts
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)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 164 +++
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 get MMIO space allocated on top of this hidden memory,
which can cause problems. I'm not sure if there are similar problems
for other hunks of the ad
On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
> Might be OT, but I cannot use my X graphics stack containing
> libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
> v2.21.11).
> Switching back to the one from Ubuntu/precise lets my X start.
>
>
> [40.379] (II) AIGLX
nges since 20130724:
>>>>> >> >>>>>>
>>>>> >> >>>>>> Removed tree:
>>>>> >> >>>>>> arm-dt (at maintainer's request)
>>>>> >> >>>>>>
>>>>> >> >>>>>> The wireless-next tree lost its build failure and gained a
&
uest)
>>>> >> >>>>>>
>>>> >> >>>>>> The wireless-next tree lost its build failure and gained a
>>>> >> >>>>>> conflict
>>>> >> >>>>>> against Linus' tree.
>>>> >
t;
>>> >> >>>>>> Removed tree:
>>> >> >>>>>> arm-dt (at maintainer's request)
>>> >> >>>>>>
>>> >> >>>>>> The wireless-next tree lost its build failure and gained a
>&
ed tree:
>> >> >>>>>> arm-dt (at maintainer's request)
>> >> >>>>>>
>> >> >>>>>> The wireless-next tree lost its build failure and gained a conflict
>> >> >>>>>> against Linus' tree.
>> >> >>>>>>
>> >> >&
On Thu, 2013-07-25 at 16:46 +0200, Daniel Vetter wrote:
> On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
> > 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 L
On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
> 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, Ra
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
lure and gained a conflict
> >> >>>>>> against Linus' tree.
> >> >>>>>>
> >> >>>>>> The tty tree lost its build failure.
> >> >>>>>>
> >> >>>>>> The staging tree gained
ainer's request)
>> >>>>>>
>> >>>>>> The wireless-next tree lost its build failure and gained a conflict
>> >>>>>> against Linus' tree.
>> >>>>>>
>> >>>>>> The
On Thu, Jul 25, 2013 at 9:00 PM, 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
On Thu, Jul 25, 2013 at 02:45:05PM +0100, Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
> > This fixes a typo which set the wrong vsync and possibly also hsync
> > polarity for any modes with positive vsync polarity.
>
> Note that this typo exists in the very fir
On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
> This fixes a typo which set the wrong vsync and possibly also hsync
> polarity for any modes with positive vsync polarity.
Note that this typo exists in the very first import of KMS:
commit 79e539453b34e35f39299a899d263b0a1f1670bd
Author
gt;>
> >>>>>> The wireless-next tree lost its build failure and gained a conflict
> >>>>>> against Linus' tree.
> >>>>>>
> >>>>>> The tty tree lost its build failure.
> >>>>>>
> >>>>>> The staging tree gained a build failure for which
This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/dvo_ch7xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/dvo_ch7xxx.c
b/drivers
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 and
> > > efaa14c?
> >
> > Yes, but
On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> > On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> >> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> >> > Well, I wonder what about the appended (untested) patch?
> >>
> >>
On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
>> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
>> > Well, I wonder what about the appended (untested) patch?
>>
>> Rafael, before going there, I've been trying to wrap my (poor, rusty
On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> > On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
> >> On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter
> >> wrote:
> >> >
> >> > I think a i915 module option should be doabl
On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since
commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel Vetter
Date: Thu Jul 26 19:21:47 2012 +0200
drm/i915: disable all crtcs at suspend time
br
Daniel Vetter writes:
>
> I've checked the docs again for gm45 and we seem to have the right
> values. But on early gen4 (i.e. i965g/gm) the Bspec has been wrong
> about these, so I wouldn't be surprised at all if they're wrong for
> the digital ports on gm45, too.
>
> Iirc we've already h
ext tree lost its build failure and gained a conflict
>>>>> against Linus' tree.
>>>>>
>>>>> The tty tree lost its build failure.
>>>>>
>>>>> The staging tree gained a build failure for which I disabled a driver
As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code to
This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.
Signed-off-by: Chris Wilson
---
include/linux/ioport.h | 2 ++
kernel/resource.c | 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.
Signed-off-by: Chris Wilson
---
arch/x
On Thu, Jul 25, 2013 at 9:50 AM, Egbert Eich wrote:
> > I applied this patch (but not the one you sent on Monday), recompiled
> > and logged:
> > uncompressed (8,2M) http://files.hz6.de/kern_20130724.log
> > bz2 (288 KB) http://files.hz6.de/kern_20130724.log.bz2
>
> These logs show clearly tha
On Wed, Jul 24, 2013 at 11:01:08PM +0100, Chris Wilson wrote:
> On Wed, Jul 24, 2013 at 10:40:23PM +0200, Daniel Vetter wrote:
> > Just use a spinlock to protect them.
> >
> > v2: Rebase onto the new object create refcount fix patch.
> >
> > v3: Don't kill dev_priv->mm.object_memory as requested
On Fri, Jul 19, 2013 at 08:36:56PM +0100, Chris Wilson wrote:
> The TRACE_EVENT_CONDITION is supposed to generate more efficient code
> than if (cond) trace(), which is what we are currently using inside the
> register access functions.
>
> v2: Rebase onto uncore
>
> Signed-off-by: Chris Wilson
On Thu, Jul 25, 2013 at 09:34:05AM +0100, Chris Wilson wrote:
> On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
> > Two bikesheds:
> > - Can't we give the thing a better name like "Intel Graphics Stolen"?
>
> Using a
On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
> On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
> Two bikesheds:
> - Can't we give the thing a better name like "Intel Graphics Stolen"?
Using a custom type and name seems simple enough and naturally leads it
to ending
On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote:
> On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
>> On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter
>> wrote:
>> >
>> > I think a i915 module option should be doable, otoh people seem to have a
>> > viable workaround by setting a diff
Hi Jan!
Jan Niggemann writes:
> Hi Egbert,
[...]
Thanks for generating the logs! Hope you had a nice birthday dinner :)
>
> I applied this patch (but not the one you sent on Monday), recompiled
> and logged:
> uncompressed (8,2M) http://files.hz6.de/kern_20130724.log
> bz2 (288 KB) htt
On Wed, Jul 24, 2013 at 05:04:43PM -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.
78 matches
Mail list logo
