On Tue, Nov 05, 2013 at 09:23:46AM +0200, Jani Nikula wrote:
> On Mon, 04 Nov 2013, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > While we can now call drm_sysfs_connector_remove() even if
> > drm_connector_sysfs_add() failed, it would seem better for
> > the user to know th
On Mon, 04 Nov 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> While we can now call drm_sysfs_connector_remove() even if
> drm_connector_sysfs_add() failed, it would seem better for
> the user to know that something went wrong. So instead of
> ignoring drm_sysfs_connector_add
On Mon, 04 Nov 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently if drm_connector_sysfs_add() fails, it can leave connector->kdev
> populated with an ERR_PTR value, or pointing to an already freed device.
> Use a temporarary kdev pointer during drm_connector_sysfs_add(
Cc: Art Runyan
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_dp.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6e4246f..dc216e7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/dr
On Tue, Nov 05, 2013 at 12:20:58AM +0100, Thomas Richter wrote:
> Hi Daniel, dear intel experts,
>
> the following is a "solution" for the flicker on i830 panning. To
> remind you, when panning is enabled on an i830,
> the display shows an annoying 30Hz flicker on some "forbidden"
> positions. On
On Mon, 04 Nov 2013, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_connector_sysfs_add() explicitly checks if connector->kdev
> is already populated and returns success. So it clearly now allows
> being called multiple times. Remove some stale comments to the contrary.
>
> Sig
Hi Ville,
Thanks for the information. Here MI_LOAD_REGISTER_IMM is used and not
MI_LOAD_REGISTER_MEM. Is SRM needed after MI_LOAD_REGISTER_IMM? BSpec for
MI_LOAD_REGISTER_IMM does not mention any thing about using SRM, but it is
there for MI_LOAD_REGISTER_MEM.
Regards,
Sandeep
-Original
On Tue, Nov 05, 2013 at 05:48:20AM +, Lin, Mengdong wrote:
> Hi Daniel,
>
> Could you help review this v4 patch?
Oops, I wanted to merge it but forgot it. Merged to 3.13-fixes branch,
thanks for the patch.
> I'm sorry again this patch does not in-reply-to the previous review thread.
> I didn
On Tue, Nov 05, 2013 at 05:34:18AM +, Lin, Mengdong wrote:
> Hi Daniel,
>
> Thanks for your clarification! Could you share more info ...
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Saturday, November 02, 20
From: Ben Widawsky
BDW-A workaround
BDW Bug #1899532
v2: WARN on when not using preliminary HW support
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_r
Broadwell PSR support is a superset of Haswell. With this simple
register base calculation, everything that worked on HSW for eDP PSR
should work on BDW.
Note that Broadwell provides additional PSR support. This is not
addressed at this time.
v2: Make the HAS_PSR include BDW
v3: Use the correct
Legacy PPGTT on GEN8 requires programming 4 PDP registers per ring.
Since all rings are using the same address space with the current code
the logic is simply to program all the tables we've setup for the PPGTT.
v2: Turn on PPGTT in GFX_MODE
v3: v2 was the wrong patch
v4: Resolve conflicts due t
Hi Daniel,
Could you help review this v4 patch?
I'm sorry again this patch does not in-reply-to the previous review thread.
I didn't generate a message id for my previous v2 patch by 'git format-patch'.
So I took the message id generated by 'git send-email' from the my Outlook
inbox, and genera
Hi Daniel,
Thanks for your clarification! Could you share more info ...
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Saturday, November 02, 2013 12:03 AM
> To: Lin, Mengdong
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.o
The upcoming clear and insert routines will expect that PDEs all point
to valid Page Directories. Doing that lazily doesn't really buy us
anything.
The page allocation is done regardless earlier in init so it shouldn't
hurt set the PDEs.
v2: Squash in patches to implement fixed PDE write function
Aside from the potential size increase of the PPGTT, the primary
difference from previous hardware is the Page Directories are no longer
carved out of the Global GTT.
Note that the PDE allocation is done as a 8MB contiguous allocation,
this needs to be eventually fixed (since driver reloading will
BDW caching works differently than the previous generations. Instead of
having bits in the PTE which directly control how the page is cached,
the 3 PTE bits PWT PCD and PAT provide an index into a PAT defined by
register 0x40e0. This style of caching is functionally equivalent to how
it works on HS
From: Ben Widawsky
We've done insufficient testing on them thus far, so keep them disabled
until we do test.
v2: Use WARN when not enabling preliminary HW support as this should
only be disabled for that case.
Cc: Jesse Barnes
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c |
Probing gen8 is similar to gen6. To make the code cleaner and more
maintainable however we can use the probe functions to split it out.
v2: Rebased on top of update gtt probe infrastructure.
v3: Rebased on top of Kenneth' Graunke's ->pte_encode refactoring.
V4: Resolve conflicts with Ben's lates
On Mon, Nov 04, 2013 at 02:28:55PM +, Chris Wilson wrote:
> On Sat, Nov 02, 2013 at 09:07:14PM -0700, Ben Widawsky wrote:
> > All the gen8 debugfs stuff I wasn't too lazy to update. We'll need more
> > later, I am certain.
>
> Looks like this could be squashed into patch 2 as they both attach
On Sat, Nov 02, 2013 at 09:07:45PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> Use the eDP values on platforms where port D is eDP. This doesn't
> affect Haswell since it uses the same DDI buffer values for eDP and
> DP.
>
> Reviewed-by: Art Runyan
> Signed-off-by: Paulo Zanoni
> ---
>
On Sat, Nov 02, 2013 at 09:07:43PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> They're not the same as the Haswell ones.
>
> Reviewed-by: Art Runyan
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 11 +
> drivers/gpu/drm/i915/intel_dp.c | 55
>
Either the docs were wrong or the values have changed since the old days
before we had wheels.
Reported-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_pm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
On Sat, Nov 02, 2013 at 09:07:42PM -0700, Ben Widawsky wrote:
> From: Paulo Zanoni
>
> Broadwell has different DDI buffer translations for eDP and DP, so add
> support for the missing eDP and keep Haswell the same.
>
> A future patch addresses the suggestion from Art to check for eDP on
> port D
It's possible that the CCK clock could run at a different rate than the
DDR clock, so use the same method to get CCK as the GMBUS code does when
calculating the new CDclk divider in the VLV display code.
Reported-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_displ
On Tue, 5 Nov 2013 00:49:57 +0200
Ville Syrjälä wrote:
> On Mon, Nov 04, 2013 at 11:52:45AM -0800, Jesse Barnes wrote:
> > We don't want it delayed with the RPS work.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 31 ++-
> > 1 fil
On Sat, Nov 02, 2013 at 09:07:41PM -0700, Ben Widawsky wrote:
> From: Art Runyan
>
> Many of the DDI buffer translation values have changed for BDW.
> Add new translation tables and selection between HSW and BDW.
>
> v2: s/BUG/WARN/ to avoid breaking future GENs.
>
> v3: Rebase on top of the hd
Hi Daniel, dear intel experts,
the following is a "solution" for the flicker on i830 panning. To remind
you, when panning is enabled on an i830,
the display shows an annoying 30Hz flicker on some "forbidden"
positions. On such positions, half of the frames
is black, and the other half shows a s
On Mon, Nov 04, 2013 at 11:52:45AM -0800, Jesse Barnes wrote:
> We don't want it delayed with the RPS work.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_pm.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/
On Mon, Nov 04, 2013 at 01:48:12PM -0800, Jesse Barnes wrote:
> On VLV/BYT, we can adjust the CDclk frequency up or down based on the
> max pixel clock we need to drive. Lowering it can save power, while
> raising it is necessary to support high resolution.
>
> Add a new callback in modeset_affec
On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote:
> With the PTE clarifications, the bind and clear functions can now be
> added for gen8.
>
> v2: Use for_each_sg_pages in gen8_ggtt_insert_entries.
>
> v3: Drop dev argument to pte encode functions, upstream lost it. Also
> rebase on top of t
Chen Gang wrote:
> For "include/uapi/*", excluding "linux/" sub-directory, let all files'
> macro prefix match the standard format, and give related stand comments
> for their macro suffix.
>
> The related standard format is:
>
> "_SUBDIRNAME_SUBDIRNAME[_SUBDIRNAME]_FILENAME" (1st _SUBDIRNAME
On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote:
> With gen6 PTE type in place, pave the way for the new gen8 type.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --gi
On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote:
> Probing gen8 is similar to gen6. To make the code cleaner and more
> maintainable however we can use the probe functions to split it out.
>
> v2: Rebased on top of update gtt probe infrastructure.
>
> v3: Rebased on top of Kenneth' Graunke'
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjust
On Mon, Oct 28, 2013 at 10:20:56AM -0200, Paulo Zanoni wrote:
> 2013/10/27 Daniel Vetter :
> > On Fri, Oct 25, 2013 at 11:44:05AM -0200, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> This test is based on pc8.c. It copies most of the tests from pc8.c,
> >> but it depends on runtime PM stat
On Mon, Oct 28, 2013 at 03:27:39PM +0200, Imre Deak wrote:
> On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > And leave it off by default. We have way too many driver entry points,
> > we can't assume this will work without regressions without tons of
> > test
On Mon, Nov 04, 2013 at 11:22:03PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 04, 2013 at 12:54:24PM -0800, Jesse Barnes wrote:
> > On VLV/BYT, we can adjust the CDclk frequency up or down based on the
> > max pixel clock we need to drive. Lowering it can save power, while
> > raising it is necessa
On Mon, 4 Nov 2013 23:22:03 +0200
Ville Syrjälä wrote:
> So now the problem is now that we have to calculate max_pixclk before
> intel_crtc->config has been update for modeset_pipes.
>
> If we make intel_mode_max_pixclk() and valleyview_modeset_global_pipes() like
> so:
>
> static int intel_mod
On Mon, Nov 04, 2013 at 12:54:24PM -0800, Jesse Barnes wrote:
> On VLV/BYT, we can adjust the CDclk frequency up or down based on the
> max pixel clock we need to drive. Lowering it can save power, while
> raising it is necessary to support high resolution.
>
> Add a new callback in modeset_affec
On Sat, 2 Nov 2013 21:07:52 -0700
Ben Widawsky wrote:
> This is mostly what we have for HSW with the exceptions of:
> no writes:
> GEN6_RC1_WAKE_RATE_LIMIT
> GEN6_RC6pp_WAKE_RATE_LIMIT
> GEN6_RC1e_THRESHOLD
> GEN6_RC6p_THRESHOLD
> GEN6_RC6pp_THRESHOLD
>
> GEN6_RP_DOWN_TIMEOUT - use 1s
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjust
On Mon, Nov 04, 2013 at 11:52:46AM -0800, Jesse Barnes wrote:
> On VLV/BYT, we can adjust the CDclk frequency up or down based on the
> max pixel clock we need to drive. Lowering it can save power, while
> raising it is necessary to support high resolution.
>
> Add a new callback in modeset_affec
On Mon, Nov 04, 2013 at 07:32:58PM +, Cristian Rodríguez wrote:
> El 04/11/13 18:54, Cristian Rodríguez escribió:
> > El 04/11/13 18:40, Daniel Vetter escribió:
> >
> >> It hangs on a scanline wait. Are you already on the latest version of
> >> xfree86-video-intel and if not can you please chec
For modifying self-refresh exit latency.
Reviewed-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_sideband.c | 16
3 files changed, 19 insertions(+)
diff -
On Mon, 4 Nov 2013 19:27:31 +
"Chilukuri, Harita" wrote:
> Hi All,
>
> I am running Aquarium workload (WebGL) on Chromium OS. From the powertop
> data, I do see 277.9 overall GPU ops/second and 166.6 ops/sec from
> gen6_pm_rps_work.
>
> Are the above ops/sec in normal range? Can someone l
On VLV/BYT, we can adjust the CDclk frequency up or down based on the
max pixel clock we need to drive. Lowering it can save power, while
raising it is necessary to support high resolution.
Add a new callback in modeset_affected_pipes and a
modeset_global_resources function to perform this adjust
We don't want it delayed with the RPS work.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_pm.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a0c907f..2e707
Hi All,
I am running Aquarium workload (WebGL) on Chromium OS. From the powertop data,
I do see 277.9 overall GPU ops/second and 166.6 ops/sec from gen6_pm_rps_work.
Are the above ops/sec in normal range? Can someone let me know what the primary
purpose of this function is and how I can reduce
From: Ville Syrjälä
Currently if drm_connector_sysfs_add() fails, it can leave connector->kdev
populated with an ERR_PTR value, or pointing to an already freed device.
Use a temporarary kdev pointer during drm_connector_sysfs_add(), and
only set connector->kdev if the function succeeds. This avoi
From: Ville Syrjälä
While we can now call drm_sysfs_connector_remove() even if
drm_connector_sysfs_add() failed, it would seem better for
the user to know that something went wrong. So instead of
ignoring drm_sysfs_connector_add() return value, checl it
and fail the whole connector registration.
Most drivers don't appear to bother with checking drm_connector_sysfs_add()
return value. That means the recent changes to drm_connector_sysfs_add()
have left most drivers susceptible to oopsing on cleanup if
drm_connector_sysfs_add() somehow failed.
This series makes drm_connector_sysfs_remove()
From: Ville Syrjälä
drm_connector_sysfs_add() explicitly checks if connector->kdev
is already populated and returns success. So it clearly now allows
being called multiple times. Remove some stale comments to the contrary.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_sysfs.c | 6 --
El 04/11/13 18:40, Daniel Vetter escribió:
It hangs on a scanline wait. Are you already on the latest version of
xfree86-video-intel and if not can you please check whether it works
on the latest?
I am in version 2.99.905 , it does not appear to be a newer snapshot
release.. do you want me t
On Sat, Nov 02, 2013 at 01:04:31PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Spurred by the ongoing discussions about improving our tests I've started to
> document some of the naming patterns a bit. I've also added a few new ones and
> renamed a bunch of tests.
>
> The idea is that developers ca
On Mon, Nov 4, 2013 at 7:30 PM, Cristian Rodríguez
wrote:
> El 04/11/13 15:30, Cristian Rodríguez escribió:
>
>
>> Ok, got it to hang again today after a few days with no problem.. wow,
>> weird misbehavior! with latest drm-intel-nightly merged, attached is the
>> dmesg output plus the saved error
El 04/11/13 15:30, Cristian Rodríguez escribió:
Ok, got it to hang again today after a few days with no problem.. wow,
weird misbehavior! with latest drm-intel-nightly merged, attached is the
dmesg output plus the saved error log from /sys/class/drm/card0/error
A key detail that might be of in
On Sat, 2 Nov 2013 21:07:53 -0700
Ben Widawsky wrote:
> From: Ben Widawsky
>
> We've done insufficient testing on them thus far, so keep them disabled
> until we do test.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 ++
> 1 file changed, 6 insertions(+)
>
On Mon, Nov 4, 2013 at 6:26 PM, Mateo Lozano, Oscar
wrote:
>> > IMHO, gem_quiescent_gpu() does need the drop cache call, otherwise it
>> doesn´t really do what it advertises. However, calling gem_quiescent_gpu()
>> inside get_object_count() is probably overkill, and could potentially mask
>> somet
On Mon, Nov 4, 2013 at 6:22 PM, Mateo Lozano, Oscar
wrote:
> Well, I left the return value so that the user could decide whether or not to
> assert (e.g. gem_reloc_vs_gpu probably wants to assert, but if we end up
> adding a call to igt_drop_caches_set() inside gem_quiescent_gpu() and we
> asse
On Fri, 1 Nov 2013 21:52:44 +0200
Ville Syrjälä wrote:
> On Fri, Nov 01, 2013 at 12:28:16PM -0700, Jesse Barnes wrote:
> > On VLV/BYT, we can adjust the CDclk frequency up or down based on the
> > max pixel clock we need to drive. Lowering it can save power, while
> > raising it is necessary to
> > IMHO, gem_quiescent_gpu() does need the drop cache call, otherwise it
> doesn´t really do what it advertises. However, calling gem_quiescent_gpu()
> inside get_object_count() is probably overkill, and could potentially mask
> something going wrong (not so much when called at the beginning of a
> > This is basically a "drop cache" interface to the igt_debugfs
> > facilities. Also, update existing users.
> >
> > Signed-off-by: Oscar Mateo
> > Cc: Damien Lespiau
> > ---
> > lib/igt_debugfs.c | 28
> > lib/igt_debugfs.h | 15 +++
On Mon, Nov 4, 2013 at 5:45 PM, Mateo Lozano, Oscar
wrote:
> IMHO, gem_quiescent_gpu() does need the drop cache call, otherwise it doesn´t
> really do what it advertises. However, calling gem_quiescent_gpu() inside
> get_object_count() is probably overkill, and could potentially mask something
On Mon, Nov 04, 2013 at 04:30:48PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> We don't want a previously used object to be freed in the middle of a
> before/after object counting operation (or we would get a "-1 objects
> leaked" message). We have seen this happening, e.g., when
On Mon, Nov 04, 2013 at 04:30:47PM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> This is basically a "drop cache" interface to the igt_debugfs
> facilities. Also, update existing users.
>
> Signed-off-by: Oscar Mateo
> Cc: Damien Lespiau
> ---
> lib/igt_debugfs.c |
On Mon, Nov 04, 2013 at 05:34:41PM +0100, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 06:02:24PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 04, 2013 at 08:13:45AM +0100, Daniel Vetter wrote:
> > > Apparently they need the same treatment as primary planes. This fixes
> > > modesetting failures b
On Mon, Nov 04, 2013 at 02:49:21PM +, Chris Wilson wrote:
> On Sun, Nov 03, 2013 at 04:36:58PM -0800, Ben Widawsky wrote:
> > v2: Squash in "drm/i915/bdw: Add BDW to the HAS_DDI check" as
> > suggested by Damien.
> >
> > v3: Squash in VEBOX enabling from Zhao Yakui
> >
> > v4: Rebase on top
Ok, I have sent a series of four patches that address Ben´s and Damien´s
comments, plus a fix for a typo I found in gem_*_reloc. I have left out the
igt_drop_caches_set() call inside gem_quiescent_gpu() because it is still being
disputed, but I could easily include this patch as well.
IMHO, gem
From: Oscar Mateo
This is basically a "drop cache" interface to the igt_debugfs
facilities. Also, update existing users.
Signed-off-by: Oscar Mateo
Cc: Damien Lespiau
---
lib/igt_debugfs.c | 28
lib/igt_debugfs.h | 15 +++
t
From: Oscar Mateo
A typo in the relocation tests made both sub-tests perform the
same action: drop *all* caches.
Signed-off-by: Oscar Mateo
---
tests/gem_persistent_relocs.c |2 +-
tests/gem_reloc_vs_gpu.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests
From: Oscar Mateo
Same thing that was done for prime_self_import.
Signed-off-by: Oscar Mateo
---
tests/gem_flink_race.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/gem_flink_race.c b/tests/gem_flink_race.c
index b81007e..9b25d9a 100644
--- a/tests/gem_flin
From: Oscar Mateo
We don't want a previously used object to be freed in the middle of a
before/after object counting operation (or we would get a "-1 objects
leaked" message). We have seen this happening, e.g., when a context
from a previous run dies, but its backing object is alive waiting for
a
On Mon, Nov 04, 2013 at 06:02:24PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 04, 2013 at 08:13:45AM +0100, Daniel Vetter wrote:
> > Apparently they need the same treatment as primary planes. This fixes
> > modesetting failures because of stuck cursors (!) on Thomas' i830M
> > machine.
>
> What tre
On Mon, Nov 04, 2013 at 02:08:19PM -0200, Paulo Zanoni wrote:
> 2013/11/1 :
> > From: Ville Syrjälä
> >
> > All the bits in the VBT child device type have some speciifc meaning,
> > so looking for an exact match isn't always the right thing. On some
> > VLVs for example the device type for eDP pa
2013/11/1 Imre Deak :
> This way the code is simpler and can also be used for other platforms
> where the audio power domain->power well mapping is different.
>
> Signed-off-by: Imre Deak
Good idea!
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i9
2013/11/1 :
> From: Ville Syrjälä
>
> All the bits in the VBT child device type have some speciifc meaning,
> so looking for an exact match isn't always the right thing. On some
> VLVs for example the device type for eDP panels is 0x1806.
>
> If we mask out the bits that could concievably change
On Mon, Nov 04, 2013 at 05:48:16PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 04, 2013 at 04:15:09PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> > > Hi Daniel,
> > > >>I also tried a lot with the two-monitor case and again went deeply into
> > >
On Mon, Nov 04, 2013 at 04:49:54PM +0100, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 02:49:21PM +, Chris Wilson wrote:
> > On Sun, Nov 03, 2013 at 04:36:58PM -0800, Ben Widawsky wrote:
> > > v2: Squash in "drm/i915/bdw: Add BDW to the HAS_DDI check" as
> > > suggested by Damien.
> > >
> >
On Mon, Nov 04, 2013 at 08:13:45AM +0100, Daniel Vetter wrote:
> Apparently they need the same treatment as primary planes. This fixes
> modesetting failures because of stuck cursors (!) on Thomas' i830M
> machine.
What treatment? Primary planes don't need any extra posting reads AFAIK.
>
> I've
2013/11/1 :
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
I guess you can blame Paulo for being lazy here...
Reviewed-by: Paulo Zanoni
On a future patch, you might also want to do something about the
definition of bits below the comment "/* Add the device class for LFP,
TV, HDMI */"
On Mon, Nov 04, 2013 at 02:49:21PM +, Chris Wilson wrote:
> On Sun, Nov 03, 2013 at 04:36:58PM -0800, Ben Widawsky wrote:
> > v2: Squash in "drm/i915/bdw: Add BDW to the HAS_DDI check" as
> > suggested by Damien.
> >
> > v3: Squash in VEBOX enabling from Zhao Yakui
> >
> > v4: Rebase on top
On Mon, Nov 04, 2013 at 04:15:09PM +0100, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> > Hi Daniel,
> > >>I also tried a lot with the two-monitor case and again went deeply into
> > >>the
> > >>DPLL setup logic.
> > >>The differences I observed before ar
On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> Hi Daniel,
> >>I also tried a lot with the two-monitor case and again went deeply into the
> >>DPLL setup logic.
> >>The differences I observed before are simply due to the initial resolution
> >>(800x600), in the final
> >>resolutio
On Sun, Nov 03, 2013 at 01:47:27PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Like on HSW, trickle feed should always be enabled on BDW.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Damien Lespiau
--
Damien
> ---
> Not sure this applies directly, I just put it t
On Sun, Nov 03, 2013 at 09:45:49AM +0100, Daniel Vetter wrote:
> Damien: Patches 24-29
Patches were reviewed, had a glance at them to try to spot anything a
rebase could have done to them with two small improvements that can be
addressed with 2 patches on top if we want to merge things in the next
On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote:
> Aside from the potential size increase of the PPGTT, the primary
> difference from previous hardware is the Page Directories are no longer
> carved out of the Global GTT.
>
> Note that the PDE allocation is done as a 8MB contiguous allocatio
On Sat, Nov 02, 2013 at 09:07:25PM -0700, Ben Widawsky wrote:
> Legacy PPGTT on GEN8 requires programming 4 PDP registers per ring.
> Since all rings are using the same address space with the current code
> the logic is simply to program all the tables we've setup for the PPGTT.
>
> v2: Turn on PP
On Sun, Nov 03, 2013 at 04:36:58PM -0800, Ben Widawsky wrote:
> v2: Squash in "drm/i915/bdw: Add BDW to the HAS_DDI check" as
> suggested by Damien.
>
> v3: Squash in VEBOX enabling from Zhao Yakui
>
> v4: Rebase on top of Jesse's patch to extract all pci ids to
> include/drm/i915_pciids.h.
>
On Sat, Nov 02, 2013 at 09:07:01PM -0700, Ben Widawsky wrote:
> From: Daniel Vetter
>
> This will be changed once the gen8 code is fully implemented.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers
On Sat, Nov 02, 2013 at 09:07:19PM -0700, Ben Widawsky wrote:
> +static void gen8_setup_private_ppat(struct drm_i915_private *dev_priv)
> +{
> +#define GEN8_PPAT_UC (0<<0)
> +#define GEN8_PPAT_WC (1<<0)
> +#define GEN8_PPAT_WT (2<<0)
> +#define GEN8_PPAT_WB (3<<0)
>
On Sat, Nov 02, 2013 at 09:07:17PM -0700, Ben Widawsky wrote:
> With gen6 PTE type in place, pave the way for the new gen8 type.
Wouldn't this patch make more sense before patch 18, so that we always
use sizeof(gen8_gtt_pte_t) rather than 8?
-Chris
--
Chris Wilson, Intel Open Source Technology C
On Sat, Nov 02, 2013 at 09:07:14PM -0700, Ben Widawsky wrote:
> All the gen8 debugfs stuff I wasn't too lazy to update. We'll need more
> later, I am certain.
Looks like this could be squashed into patch 2 as they both attach the
same infrastructure (swizzling).
-Chris
--
Chris Wilson, Intel Ope
On Sun, Nov 03, 2013 at 09:44:56AM -0800, Ben Widawsky wrote:
> On Sun, Nov 03, 2013 at 01:07:58PM +0200, Ville Syrjälä wrote:
> > On Sat, Nov 02, 2013 at 09:07:40PM -0700, Ben Widawsky wrote:
> > > GEN8 also needs this workaround.
> >
> > Not according to the w/a database.
> >
> > But the regist
On Sat, Nov 02, 2013 at 09:07:00PM -0700, Ben Widawsky wrote:
> +static bool is_gen8_optimized(struct drm_i915_private *dev_priv, u32 reg)
> +{
> + int i;
> + for (i = 0; i < ARRAY_SIZE(gen8_optimized_regs); i++)
> + if (reg == gen8_optimized_regs[i])
> + ret
On Sun, 03 Nov 2013, Daniel Vetter wrote:
> On Sat, Nov 02, 2013 at 09:06:58PM -0700, Ben Widawsky wrote:
>> It is my honor and privilege to submit basic Broadwell support on behalf
>> of Intel.
>>
>> The patch series includes support for Broadwell which should bring it up
>> to feature parity wi
On Sat, Nov 02, 2013 at 09:07:22PM -0700, Ben Widawsky wrote:
> The upcoming clear and insert routines will expect that PDEs all point
> to valid Page Directories. Doing that lazily doesn't really buy us
> anything.
>
> The page allocation is done regardless earlier in init so it shouldn't
> hurt
On Mon, Nov 04, 2013 at 11:39:56AM +0200, Jani Nikula wrote:
> On Sun, 03 Nov 2013, Ben Widawsky wrote:
> > From: Ville Syrjälä
> >
> > Broadwell has bigger display FIFOs than Haswell. Otherwise the
> > two are very similar.
> >
> > v2: Fix FBC WM_LP shift for BDW
> >
> > v3: Rebase on top of the
On Sun, 03 Nov 2013, Ben Widawsky wrote:
> It's no longer a required workaround on BDW.
>
> Signed-off-by: Ben Widawsky
> [danvet: Move compile fix from a later patch to this one.]
> Signed-off-by: Daniel Vetter
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 ++-
>
On Sun, 03 Nov 2013, Ben Widawsky wrote:
> From: Damien Lespiau
>
> Just like HSW.
>
> This means we can scan out a mode with a 300Mhz pixel clock with a depth
> of 24 bits, but only a 200Mhz one with a 36bits depth.
>
> Signed-off-by: Damien Lespiau
> Reviewed-by: Ben Widawsky
Reviewed-by: Ja
1 - 100 of 108 matches
Mail list logo
