commit 6033637a040eeb8ae0f31bdbca8d9c988582f99d
Author: GuoYejun mailto:yejun@intel.com>>
Date: Fri Sep 27 16:26:18 2013 +0800
drm/i915: Export the eLLC size from KMD via IOCTL
The usermode driver needs the eLLC information in order to
make decisions which can result in signific
I'm using Ubuntu 13.10
sudo apt-get install libpciaccess-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
libpciaccess-dev
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 23,6 kB
On Tue, Oct 08, 2013 at 10:50:50PM +0100, Chris Wilson wrote:
> On Wed, Oct 09, 2013 at 12:09:51AM +0300, Abdiel Janulgue wrote:
> > Ensures that the batch buffer is executed by the resource streamer.
> >
> > Signed-off-by: Abdiel Janulgue
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c |
For future platforms we'll need to initialize our MMIO function pointers
even earlier. Specifically, we'll need to be able to have register
reads/writes at GTT initialization. Similarly, these platforms also have
MMIO differences based on the PCH id, so while moving stuff around, also
move the PCH
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> README | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/README b/README
> index 653bfcd..a04c987 100644
> --- a/README
> +++ b/README
> @@ -96,3 +96,15 @@ debugger/
> i
Hi
2013/9/24 :
> From: Mukesh
>
> The code defines a new function intel_disable_audio() to implement the
> entire audio codec disable sequence, called by intel_disable_ddi() in
> DDI port disablement. This audio codec disbale sequence is implemented
> as per the recommendation of the Bspec.
>
>
On Tue, Oct 08, 2013 at 10:56:41PM +0200, Thomas Richter wrote:
> Hi Daniel, dear kernel developers,
>
> just tried the 3.12.rc3+ from the intel-drm git. This version
> *worked* again, pretty much the same way the 3.10.10 "worked".
>
> Side effects are, however, quite the same when you connect an
On Tue, Oct 08, 2013 at 06:02:30PM -0300, Paulo Zanoni wrote:
> 2013/9/20 Daniel Vetter :
> > On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote:
> >> 2013/9/20 Daniel Vetter :
> >> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote:
> >> >> On Thu, Sep 19, 2013 at 05:03:06PM
On Wed, Oct 09, 2013 at 12:09:51AM +0300, Abdiel Janulgue wrote:
> Ensures that the batch buffer is executed by the resource streamer.
>
> Signed-off-by: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
> include/uapi/drm/i915_drm.h|5 +
> 2 f
2013/10/1 Ville Syrjälä :
> On Thu, Sep 26, 2013 at 08:06:00PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> The consoles who need to do something when unbinding or binding can
>> optionally implement these functions.
>>
>> The current problem I'm trying to solve is that when i915+fbcon i
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_ringbuffer.c |7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c246727..f3c9103 1006
Ensures that the batch buffer is executed by the resource streamer.
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 ++
include/uapi/drm/i915_drm.h|5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_execb
v2 of drm-i915 part of resource streamer enabling. Re-submitted
finally now that the Mesa portions are starting to take shape.
I also addressed some of the comments from Daniel and Chris from
the previous implementation.
Cc: Daniel Vetter
Cc: Chris Wilson
Abdiel Janulgue (2):
drm/i915/hsw
2013/9/20 Daniel Vetter :
> On Fri, Sep 20, 2013 at 12:18:29PM -0300, Paulo Zanoni wrote:
>> 2013/9/20 Daniel Vetter :
>> > On Thu, Sep 19, 2013 at 09:24:33PM +0100, Chris Wilson wrote:
>> >> On Thu, Sep 19, 2013 at 05:03:06PM -0300, Paulo Zanoni wrote:
>> >> > From: Paulo Zanoni
>> >> >
>> >> > A
Hi Daniel, dear kernel developers,
just tried the 3.12.rc3+ from the intel-drm git. This version *worked*
again, pretty much the same way the 3.10.10 "worked".
Side effects are, however, quite the same when you connect an external
monitor:
If connected while the gdm login screen is on, the
On Tue, Oct 8, 2013 at 6:08 PM, Roland Dreier wrote:
> On Mon, Oct 7, 2013 at 11:10 PM, Daniel Vetter wrote:
>> Can you please boot with drm.debug=0xe, reproduce the issue and then
>> attach the dmesg. The additional debug spam should shed some light on how
>> we managed to get into this peculiar
On 2013-10-08 00:06 (GMT-0400) Felix Miata composed:
Still broken:
Linux gx110 3.11.3-3.gac1d7be-default #1 SMP Fri Oct 4 12:14:40 UTC 2013
(ac1d7be) i686 i686 i386 GNU/Linux
glamor-0.5.1-39.2.i586
intel-gpu-tools-1.3-20.10.i586
libdrm_intel1-2.4.46-121.1.i586
libdrm2-2.4.46-121.1.i586
vaapi-int
On Sat, 5 Oct 2013 13:04:08 +0200
Daniel Vetter wrote:
> On Fri, Oct 4, 2013 at 9:42 PM, Jesse Barnes wrote:
> > On VLV/BYT, backlight controls a per-pipe, so when adjusting the
> > backlight we need to pass the correct info. So make the externally
> > visible backlight functions take a connect
Signed-off-by: Jani Nikula
---
README | 12
1 file changed, 12 insertions(+)
diff --git a/README b/README
index 653bfcd..a04c987 100644
--- a/README
+++ b/README
@@ -96,3 +96,15 @@ debugger/
initiating connections with debug clients..
The debugger must be run as
Signed-off-by: Jani Nikula
---
tools/intel_opregion_decode.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
index e5f79df..8a9ef20 100644
--- a/tools/intel_opregion_decode.c
+++ b/tools/intel_opre
Finally a tool to decode opregion a bit. This is initially just a
structural dump, no real interpretation of the values. But helps
immensely.
BR,
Jani.
Jani Nikula (2):
intel_opregion_decode: new tool for decoding graphics opregion
intel_opregion_decode: decipher bclm table
tools/Makefile
Signed-off-by: Jani Nikula
---
tools/Makefile.am |1 +
tools/intel_opregion_decode.c | 438 +
2 files changed, 439 insertions(+)
create mode 100644 tools/intel_opregion_decode.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 198
We still need to dump some of the known sections explicitly due to
dependencies on information extracted, such as LFP data pointers and
panel_type.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/in
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 165 +
1 file changed, 93 insertions(+), 72 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index e906efd..19b0fd9 100644
--- a/tools/intel_bios_reader.c
+++ b/
Dump sections through a table based on the section id.
Hex dump the section. This works also for unknown sections.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 342 +
1 file changed, 160 insertions(+), 182 deletions(-)
diff --git a/too
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 46 +++--
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 493fb63..d30026e 100644
--- a/tools/intel_bios_reader.c
+++ b/
Add some verbosity to the bios reader, and hex dump also the sections we
currently don't parse.
BR,
Jani.
Jani Nikula (4):
intel_bios_reader: add size temp variable as a shorthand for
finfo.st_size
intel_bios_reader: prepare for dumping all sections
intel_bios_reader: dump all sections
On Tue, Oct 08, 2013 at 02:45:33PM -0300, Paulo Zanoni wrote:
> 2013/10/8 Daniel Vetter :
> > Something already got misplaced (although it's from a patch from
> > before Paulo's cleanup). Move it to the right spot.
> >
> > Reported-by: Paulo Zanoni
> > Cc: Paulo Zanoni
> > Signed-off-by: Daniel V
Something already got misplaced (although it's from a patch from
before Paulo's cleanup). Move it to the right spot.
Reported-by: Paulo Zanoni
Cc: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
2013/10/8 Daniel Vetter :
> Something already got misplaced (although it's from a patch from
> before Paulo's cleanup). Move it to the right spot.
>
> Reported-by: Paulo Zanoni
> Cc: Paulo Zanoni
> Signed-off-by: Daniel Vetter
We could argue about that new blank line (I removed them all and no
On 08.10.2013 10:39, Daniel Vetter wrote:
On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote:
I guess step one is to bisect the regression in 3.11. Fixing things on
top of 3.10 is imo pointless if later kernels break things harder ...
btw the two SNA patches I've just submitted should improve
On Tue, 2013-10-08 at 17:29 +0100, Chris Wilson wrote:
> On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote:
> > On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote:
> > > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote:
> > > > Adding drm/i915 into the vga arbiter chai
On 10/08/2013 06:47 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:1
On Tue, Oct 8, 2013 at 11:44 AM, Daniel Vetter wrote:
> For drivers which might want to disable fbdev legacy support.
>
> Select the new option in all drivers for now, so this shouldn't result
> in any change. Drivers need some work anyway to make fbdev support
> optional (if they have it implemen
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
> On 10/08/2013 04:55 PM, Jerome Glisse wrote:
> >On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
> >>Am 08.10.2013 16:33, schrieb Jerome Glisse:
> >>>On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote
On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This preve
On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote:
> On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote:
> > On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote:
> > > Adding drm/i915 into the vga arbiter chain means that X (in a piece of
> > > well-meant paranoia) will d
On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote:
> On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote:
> > Adding drm/i915 into the vga arbiter chain means that X (in a piece of
> > well-meant paranoia) will do a get/put on the vga decoding around
> > _every_ accel call down into t
On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote:
> Adding drm/i915 into the vga arbiter chain means that X (in a piece of
> well-meant paranoia) will do a get/put on the vga decoding around
> _every_ accel call down into the ddx. Which results in some nice
> performance disasters [1].
On Tue, Oct 08, 2013 at 05:44:46PM +0200, Daniel Vetter wrote:
> Hi all,
>
> By popular demand (our embedded guys kept asking for this) I've resurrected my
> fbdev less patches. Now Rob's msm driver can be completely completely without
> CONFIG_FB stuff at all when disabling the fbdev helper suppo
This file is all about the legacy fbdev support. If we want to extract
framebuffer functions, we better put those into a separate file.
Also rename functions accordingly, only two have used the intel_fb_
prefix anyway.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile| 2
Boots Just Fine (tm)!
The only glitch seems to be that at least on Fedora the boot splash
gets confused and doesn't display much at all.
And since there's no ugly console flickering anymore in between, the
flicker while switching between X servers (VT support is still enabled)
is even more jarrin
For drivers which might want to disable fbdev legacy support.
Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by addin
Hi all,
By popular demand (our embedded guys kept asking for this) I've resurrected my
fbdev less patches. Now Rob's msm driver can be completely completely without
CONFIG_FB stuff at all when disabling the fbdev helper support.
Review highly welcome.
Cheers, Daniel
Daniel Vetter (3):
drm: Ad
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get/put on the vga decoding around
_every_ accel call down into the ddx. Which results in some nice
performance disasters [1].
Ville tried to come up with a Great Hack to fiddle the required VGA
I
On Tue, Oct 08, 2013 at 02:38:22PM +0100, Damien Lespiau wrote:
> On Fri, Oct 04, 2013 at 09:22:49PM -0700, Ben Widawsky wrote:
> > For upcoming patches which will have GEN specific MMIO functions, we'll
> > need to initialize the uncore data structure earlier than we do today.
> >
> > If we do no
On Tue, Oct 8, 2013 at 10:45 AM, Maarten Lankhorst <
maarten.lankho...@canonical.com> wrote:
> op 08-10-13 16:33, Jerome Glisse schreef:
> > On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> >> Allocate and copy all kernel memory before doing reservations. This
> prevents a lock
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
> Am 08.10.2013 16:33, schrieb Jerome Glisse:
> >On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> >>Allocate and copy all kernel memory before doing reservations. This
> >>prevents a locking
> >>inversion between
op 08-10-13 16:33, Jerome Glisse schreef:
> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
>> Allocate and copy all kernel memory before doing reservations. This prevents
>> a locking
>> inversion between mmap_sem and reservation_class, and allows us to drop the
>> trylocking
Thanks Paulo.
Thanks for the suggestion Ben, will do this on next round!
On Tue, Oct 8, 2013 at 10:57 AM, Paulo Zanoni wrote:
> 2013/10/7 Rodrigo Vivi :
>>
>> This is another drm-intel-collector push for review:
>> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
>>
>> H
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
> Allocate and copy all kernel memory before doing reservations. This prevents
> a locking
> inversion between mmap_sem and reservation_class, and allows us to drop the
> trylocking
> in ttm_bo_vm_fault without upsetting lockdep.
Allocate and copy all kernel memory before doing reservations. This prevents a
locking
inversion between mmap_sem and reservation_class, and allows us to drop the
trylocking
in ttm_bo_vm_fault without upsetting lockdep.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/radeon/r6
2013/10/7 Rodrigo Vivi :
>
> This is another drm-intel-collector push for review:
> http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
>
> Here goes the list in order for better reviewers assignment:
>
> Patch drm/i915: check that the i965g/gm 4G limit is really obeyed -
On Fri, Oct 04, 2013 at 09:22:49PM -0700, Ben Widawsky wrote:
> For upcoming patches which will have GEN specific MMIO functions, we'll
> need to initialize the uncore data structure earlier than we do today.
>
> If we do not do this, the following will be problematic:
>
> intel_uncore_sanitize
>
On Tue, Oct 08, 2013 at 11:29:41AM +0100, Chris Wilson wrote:
> On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote:
> > At least on my i830M here it reliably results in hard system hangs
> > nowadays. This is much worse than falling back to software rendering,
> > so I think we should si
On Tue, Oct 08, 2013 at 12:25:42PM +0200, Daniel Vetter wrote:
> The ns2501 controller seems to need the dpll and dvo port to accept
> the timing update commands. Quick testing on my x30 here seems to
> indicate that other dvo controllers don't mind. So let's move the
> ->mode_set callback to a pla
On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote:
> At least on my i830M here it reliably results in hard system hangs
> nowadays. This is much worse than falling back to software rendering,
> so I think we should simply rip this out.
>
> After all we don't have any gpu reset for gen3
On Tue, Oct 08, 2013 at 12:06:24PM +0100, Damien Lespiau wrote:
> On Mon, Oct 07, 2013 at 05:15:45PM -0300, Rodrigo Vivi wrote:
> > From: Daniel Vetter
> >
> > In truly crazy circumstances shmem might give us the wrong type of
> > page. So be a bit paranoid and double check this.
> >
> > Reviewe
On Tue, Oct 08, 2013 at 11:16:59AM +0100, Chris Wilson wrote:
> The PIPEA quirk is specifically for the issue with the PIPEB PLL on
> 830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
> running. i845 doesn't even have the second PLL or pipe, and enabling
> the quirk results in
On Mon, Oct 07, 2013 at 05:15:45PM -0300, Rodrigo Vivi wrote:
> From: Daniel Vetter
>
> In truly crazy circumstances shmem might give us the wrong type of
> page. So be a bit paranoid and double check this.
>
> Reviewer: Damien Lespiau
> Cc: Rob Clark
> References: http://lkml.org/lkml/2011/7/
The PIPEA quirk is specifically for the issue with the PIPEB PLL on
830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA
running. i845 doesn't even have the second PLL or pipe, and enabling
the quirk results in a blank DVO LVDS.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
The ns2501 controller seems to need the dpll and dvo port to accept
the timing update commands. Quick testing on my x30 here seems to
indicate that other dvo controllers don't mind. So let's move the
->mode_set callback to a place where we have the port up and running
already.
Signed-off-by: Danie
With the change in the modeset sequence this shouldn't be required
any more since the ->mode_set callback now gets called when the dvo
port is fully up and running.
Also limit the retry loop to 10 tries to avoid hanging the machine
while holding important modeset locks.
Cc: Thomas Richter
Signed
At least on my i830M here it reliably results in hard system hangs
nowadays. This is much worse than falling back to software rendering,
so I think we should simply rip this out.
After all we don't have any gpu reset for gen3 either, and there are a
lot more of those still around.
Cc: Chris Wilso
On Tue, Oct 08, 2013 at 10:39:02AM +0200, Daniel Vetter wrote:
> On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote:
> > I guess step one is to bisect the regression in 3.11. Fixing things on
> > top of 3.10 is imo pointless if later kernels break things harder ...
>
> btw the two SNA patches I'
On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetter wrote:
> I guess step one is to bisect the regression in 3.11. Fixing things on
> top of 3.10 is imo pointless if later kernels break things harder ...
btw the two SNA patches I've just submitted should improve things
quite a bit. If that gets rid of
The drm/i915 driver wants to adjust it's own power policies using the
cpu policies as a guideline (we can implicitly boost the cpus through
the gpus on some platforms). To avoid a dreaded select (since a
depends will leave users wondering where where their driver has gone
too) add dummy functions.
In my quick testing both 16 and 15 bit rendering seems to result a lot
of non-rendering in the xfce login manager (and some apparent
stride-mismatches at 16 bit thrown in for added fun).
Until that works better simply opt out the lower-bit modes by default.
Cc: Chris Wilson
Signed-off-by: Daniel
In
commit c7f7dd61fd07dbf938fc6ba711de07986d35ce1f
Author: Chris Wilson
Date: Wed Dec 12 19:43:19 2012 +
sna: Pin some batches to avoid CS incoherence on 830/845
the in-kernel w/a of pinning batches was duplicated for older
kernels.
Unfortunately the userspace w/a isn't as good as th
On Mon, Oct 7, 2013 at 11:58 PM, Thomas Richter wrote:
>
> Actually, I was testing with the 3.10.10 kernel here. Unfortunately, I need
> to tell you that 3.11.4 and 3.12.0-rc.4 does *not work at all*. All I get on
> these kernel releases is a blank screen, though with a working mouse cursor.
> App
70 matches
Mail list logo
