Test indirect addressing, such as "g[a0.8]"
---
test/Makefile.am |4 +++-
test/indirect-address.expected |1 +
test/indirect-address.g4a |1 +
test/run-test.sh |1 +
4 files changed, 6 insertions(+), 1 deletion(-)
create mode 100644 test/indirect-a
before we change it, disassembler output:
(+f0) cmp.l(8) null g12<8,8,1>D g2.2<0,1,0>D { align1 };
this is wrong.
even the command is "cmp.l.f1.1", disassembler still output "cmp.l"
after we change it, it is correct:
(+f0) cmp.l.f1.1(8) null g12<8,8,1>D g2.2<0,1,0>D { align1 };
---
src/disa
If horizontal stride of a dest operand is four,
before we fix it, the disassembler outputs wrong
mov(8) g20<3>UB g18<8,8,1>F;
after we fix it, the output is correct.
mov(8) g20<4>UB g18<8,8,1>F;
---
src/disasm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/disa
Before fix this bug, "-128:f" is interpreted as a very large integer.
After fix this bug,
add (1) g0<1>:f g0<1,1,1>:f -128.0:f;
add (1) g0<1>:f g0<1,1,1>:f -128:f;
both generate correct binary code
---
src/gram.y |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gram.y b/
add (1) g0<1>:f g0<1,1,1>:f -128.0:f;
add (1) g0<1>:f g0<1,1,1>:f -128:f;
should generate same binary code
---
src/gram.y |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gram.y b/src/gram.y
index bd55052..5e009da 100644
--- a/src/gram.y
+++ b/src/gram.y
@@ -1743,7 +1743,
On Fri, 22 Feb 2013, Daniel Vetter wrote:
> We'ev had our fair share of woes already which showed that we can't
^^
> rely on the bpc limits in the EDID for eDP panels without risking
> black screens. So now we limit the depth by what the BIOS recommends
> in the VBT:
>
> commit 2f4f649a69a9e
Don't try to be smart. Just poke all forcewake bits if it seems we need
it.
Signed-off-by: Ben Widawsky
---
tools/quick_dump/chipset.i | 2 ++
tools/quick_dump/reg_access.py | 23 +++
2 files changed, 25 insertions(+)
diff --git a/tools/quick_dump/chipset.i b/tools/quic
Signed-off-by: Ben Widawsky
---
lib/intel_mmio.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/intel_mmio.c b/lib/intel_mmio.c
index 3933080..2f0d74a 100644
--- a/lib/intel_mmio.c
+++ b/lib/intel_mmio.c
@@ -228,6 +228,12 @@ intel_register_access_fini(void)
mmio_data.inited
Since there is no command line support, just do a pure integer version
Signed-off-by: Ben Widawsky
---
tools/quick_dump/chipset.i | 2 ++
tools/quick_dump/reg_access.py | 3 +++
2 files changed, 5 insertions(+)
diff --git a/tools/quick_dump/chipset.i b/tools/quick_dump/chipset.i
index 2f4f5
With the introduction of the forcewake dance:
commit cac8f8b52621f246a7cff412f340a7db28cb1b99
Author: Ben Widawsky
Date: Thu Jul 28 13:40:19 2011 -0700
forcewake: Add mmio code to do proper forcewake stuff for gen6
We lost the ability to do register access when either debugfs isn't
mounte
Signed-off-by: Ben Widawsky
---
tools/quick_dump/quick_dump.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
index c2f5cd9..dd64710 100755
--- a/tools/quick_dump/quick_dump.py
+++ b/tools/quick_dump/quick_dump.py
@@ -26,6 +26,7
With linux 3.8, I experienced a SNB GPU lockup an hour into a gnome-3 session.
If interested, I've put the captured state at:
http://quora.org/i915_error_state
and
http://quora.org/Xorg.0.log
xserver-xorg-core is 1.13.0-0ubuntu6.1 and xserver-xorg-video-intel is
2.20.9-0ubuntu2.
Thanks,
Daniel
Summary
We finished a new round of kernel testing. Generally, in this circle, 2 new
bugs are filed, 22 bugs are still opened, 5 bugs are closed.
Test Environment
Kernel: (drm-intel-testing) b4950816cb3b1e10d8d0db3cd112e432b6c244cf
Author: Chris Wilson mailto:ch...@chris-wilson.co.uk>>
Date:
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports comp
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!
v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertio
This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.
v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in intel_crt_mode_valid.
Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers
Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1 file changed, 34 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i91
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8f5b7da..c75d429 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu
We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
dithering down a bit.
Just search&replace in this patch, no functional change at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i9
Hi all,
So these patches finally use the new pipe_config infrastructure to beat our fdi
link handling on ivb (especially for 3 pipe configs) really into shape.
This also adds hw state readout support so that fastboot handles this all
correctly, too.
Unfortunately there's no 6bpc support for the
The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 1bd09a7..27c2b8
Totally untested due to lack of screens supporting more than 8bpc. But
now we should have closed all holes in our bpp handling, so this
should be safe. The last missing piece was 10bpc support for g4x/vlv,
since we directly use the pipe bpp to feed the display link (and
anyway, only the cpt has any
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 97 +---
drivers/
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to pch
They can get at the adjusted mode through intel_crtc->config.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
inde
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To f
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Prep-patch to improve the bpc handling in a next patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 120 +++
1 file changed, 65 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/in
We'ev had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145
Author: Jani Nikula
Date: Mon No
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to ad
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 37 +++-
1 file c
Prevents black screens when using 30bpp framebuffers on my
HDMI screens here. The DP input on the same screen though reports a
1.4 EDID with the correct 8bpc limit set.
v2: Actually check for the right thing!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 f
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
p
We need to multiply the hdmi port dotclock by 1.5x since it's not
really a dotclock, but the 10/8 encoding bitclock divided by 10.
Also add correct limit checks for the dotclock and reject modes which
don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
unfortunately :(
Somehow I
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
We need the dpll/fp/fp2 values only when we need a pch pll. So move
them together with the code to acquire such a pll.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
Up to now we've relied on the bios to get this right for us. Let's try
out whether our code has improved a bit, since we should dither
always when the output bpp doesn't match the plane bpp.
- gen5+ should be fine, since we only use the bios hint as an upgrade.
- gen4 changes, since here dithering
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cp
Hi all,
To actually be able to implement fdi link bpc dithering we need to have working
plane/pipe bpp handling. The current code doesn't manage that - I've had way too
many black screens and other funny issues.
Note that I currently lack a high-color-depth screen, so I couldn't test
anything wit
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 97 +---
drivers/
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To f
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to ad
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 37 +++-
1 file c
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
p
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cp
Hi all,
This here is a bit a grab-bag of changes, all around the clock handling in our
code. Originally I've wanted to push this further so that we can compute the
desired dpll settings in the pipe_config computation stage. We need that to
properly figure out pll sharing for atomic modeset. But it
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force th
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pi
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the enco
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
v2: Rebased on top of the added Haswell limited color range support.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm
This is used way too often in the enable/disable paths. And will
be even more useful in the future.
Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set
Completely unused by now. Separate patch in case I've missed a
place somewhere which dereferences the helper vtable but actually
shouldn't do so.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
Used by SDVO (and hopefully, eventually HDMI, if we ever get around
to fixing up the low dotclock CEA modes ...).
This required adding a new encoder->mode_set callback to be able to
pass around the intel_crtc_config.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 80 +++
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handled by moving all the pipe_bpc computation around.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
drivers/gpu/drm/i
To make decent modeset state checking possible (e.g. for the check
mode with atomic modesetting) we want to have the full pipe
configuration and state checks done before we touch the hw.
To ensure that all the little bits&pieces that are now moved to the
pipe_config handle this correctly, move its
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very simp
Hi all,
This adds the basic pipe_config infrastructure and coverts over the various mode
flags plus the pipe bpp handling. On top of that 2 patches to clean up the bpp
handling mess a bit and make the code stricter in enforcing its own rules with a
few BUGs.
Compared to the original submission I'
So ditch that if clause from the i8xx pll update code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe9dae..b52119
This reverts
commit 8ec22b214d76773c9d89f4040505ce10f677ed9a
Author: Chris Wilson
Date: Fri May 11 18:01:34 2012 +0100
drm/i915/hdmi: Query the live connector status bit for G4x
and
commit b0ea7d37a8f63eeec5ae80b4a6403cfba01da02f
Author: Damien Lespiau
Date: Thu Dec 13 16:09:00 2012 +
Hi all,
So Paulo asked me to split my patchbomb into smaller pieces. Let's start with
two easy and totally unrelated fixups ;-)
Cheers, Daniel
Daniel Vetter (2):
drm/i915: Revert hdmp HDP pin checks
drm/i915: gen2 has no tv out support
drivers/gpu/drm/i915/intel_display.c | 6 +-
driv
From: Ville Syrjälä
struct drm_region represents a two dimensional region. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (inst
From: Ville Syrjälä
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are don
From: Ville Syrjälä
Add a debug function to print the region in a human readable format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_region.c | 22 ++
include/drm/drm_region.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_region.c
From: Ville Syrjälä
These functions calculcate the scaling factor based on the source and
destination regions.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions that will adjust the src/dst region
This series adds a bunch of scaling and clipping related utility stuff to
drm core, and then implementes real clipping for intel sprite planes.
Most of this stuff was in my drm_atomic branch already for quite a while,
but I did do some minor changes here and there.
My glplane test app [1] can now
On Thu, Feb 21, 2013 at 10:17:37PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 21, 2013 at 08:04:31PM +, Chris Wilson wrote:
> > We trim the fb to fit the CRTC by computing the offset of that CRTC to
> > its nearest tile_row origin. This allows us to use framebuffers that are
> > larger than the
On Thu, Feb 21, 2013 at 08:04:31PM +, Chris Wilson wrote:
> We trim the fb to fit the CRTC by computing the offset of that CRTC to
> its nearest tile_row origin. This allows us to use framebuffers that are
> larger than the CRTC limits without additional work.
>
> However, we failed to compute
We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.
However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advan
On Thu, Feb 21, 2013 at 09:54:41PM +0200, Ville Syrjälä wrote:
> Hmm, actually it seems I'm complaining about a non-issue. The
> max horizontal size seems to be 13 bits, which means 8k, and the
> max x offset from this functions is 2k. Given that displays are
> probably limited to 4k, that would st
On Thu, Feb 21, 2013 at 07:05:51PM +, Chris Wilson wrote:
> We trim the fb to fit the CRTC by computing the offset of that CRTC to
> its nearest tile_row origin. This allows us to use framebuffers that are
> larger than the CRTC limits without additional work.
>
> However, we failed to compute
We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.
However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advan
On Thu, Feb 21, 2013 at 02:45:26PM +, Chris Wilson wrote:
> We trim the fb to fit the CRTC by computing the offset of that CRTC to
> its nearest tile_row origin. This allows us to use framebuffers that are
> larger than the CRTC limits without additional work.
>
> However, we failed to compute
You have to modify the kernel to make the change Stephane suggested,
then measure the energy consumption across your workloads. I'd expect
the residency to change, but I'm ultimately concerned with the energy
used.
Jesse
On Thu, 21 Feb 2013 05:08:10 +
"Zhang, Ouping" wrote:
> Hi Jesse,
>
We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.
However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advan
On Thu, Feb 21, 2013 at 3:49 PM, Ville Syrjälä
wrote:
>> + if (fb->depth > 24 && !HAS_PCH_SPLIT(dev)) {
>> + DRM_DEBUG_KMS("high depth not supported on gmch platforms\n");
>> + return -EINVAL;
>> + }
>
> AFAIK Gen4 does support 2:10:10:10 formats. This would fail th
On Thu, Feb 21, 2013 at 01:49:59AM +0100, Daniel Vetter wrote:
> The procedure has now 3 steps:
>
> 1. Compute the bpp that the plane will output, this is done in
>pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
>this function clamps the pipe_bpp to whatever limit the EDID
On Thu, Feb 21, 2013 at 01:49:53AM +0100, Daniel Vetter wrote:
> Currently only containing the requested and the adjusted mode. And
> only crtc callbacks are converted somewhat to it, encoders will be
> done on a as-needed basis (simply too much churn in one patch
> otherwise).
>
> Future patches
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!
v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertio
On Thu, Feb 21, 2013 at 10:34:54AM +0200, Jani Nikula wrote:
> On Wed, 20 Feb 2013, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Caching the PIPESTAT enable bits has been deemed pointless. Just
> > read them from the register itself.
>
> Reviewed-by: Jani Nikula
Queued f
On Thu, Feb 21, 2013 at 01:50:25AM +0100, Daniel Vetter wrote:
> This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
> running on pipe C. Yay!
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 16 +++-
> 1 file changed, 11 insertions(+), 5
Hello.
I'm a user of Intel graphics driver and looking for information about
the output of "intel_gpu_top" command.
I hope I can ask this kind of question on this ML.
If I shouldn't, I deeply apologize you for my posting.
Before posting this message, I tried to read the description
about this ML
On Wed, 20 Feb 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Caching the PIPESTAT enable bits has been deemed pointless. Just
> read them from the register itself.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
> ---
> Again one of those things for which I don
86 matches
Mail list logo
