Eric Anholt writes:
> Keith Packard writes:
>
>> I spent the day just cleaning up this patch series and testing. I
>> think it's ready for others to use and review. I've been running it on
>> two machines for a couple of days now and it's been solid.
>
> Patches 2, 4 are:
>
> Reviewed-by: Eric A
On Wed, Jul 30, 2014 at 09:41:59PM +0200, Daniel Vetter wrote:
> This essentially unbreaks non-ppgtt operation where we'd scribble over
> random memory.
>
> While at it give the vm_to_ppgtt function a proper prefix and make it
> a bit more paranoid.
Wrong direction. If you make ggtt/ppgtt more si
On Wed, Jul 30, 2014 at 09:42:01PM +0200, Daniel Vetter wrote:
> We already needs this just as a safety check in case the preallocation
> reservation dance fails. But we definitely need this to be able to
> move tha aliasing ppgtt setup back out of the context code to this
> place, where it belongs
Eric Anholt writes:
> Keith Packard writes:
>
>> I spent the day just cleaning up this patch series and testing. I
>> think it's ready for others to use and review. I've been running it on
>> two machines for a couple of days now and it's been solid.
>
> Patches 2, 4 are:
>
> Reviewed-by: Eric A
Eric Anholt writes:
> Keith Packard writes:
>
>> This adds glamor support back into the driver, but instad of going
>> through UXA, this uses it directly instead.
>
> This is hard to read with the conditionalizing all of the UXA code in
> the same commit as adding the glamor code. Then there ar
Eric Anholt writes:
> Keith Packard writes:
>
>> Make sure the pitch and tiling are correct.
>> Make sure there's a BO we can get at.
>
> I thought we couldn't change these parameters, but now I can't find what
> prevents them from changing. Can you cite sources?
Looks like we *can* change til
On Wed, Jul 30, 2014 at 10:47:46AM -0700, Rodrigo Vivi wrote:
> WA to skip the first page of stolen memory due to sporadic HW write on *CS
> Idle
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>
Eric Anholt writes:
> Keith Packard writes:
>
>> This eliminates the stubs in intel_glamor.h and replaces them with
>> ifdefs instead.
>
> I don't feel strongly about this either way -- ifdefs are more
> traditional userland style, while stubs are more kernel style.
Right, just trying to keep t
Eric Anholt writes:
> Something weird happened in this commit.
>
> uxa-glamor.h is removed from the repo, but the makefile only drops
> intel_glamor.h, which keeps getting used. I suspect make distcheck is
> broken.
Yeah, almost certainly. In fact, after this patch, the driver does *not*
build
Eric Anholt writes:
> This change appears to be unrelated, and possibly harmful (if X has
> dropped the last ref to the BO, but it's still the scanout buffer, a new
> allocation would now reuse the BO and scribble on scanout until the next
> modeset happens).
Yeah, it's unrelated. intel_allocate
Eric Anholt writes:
> Keith Packard writes:
>
> I don't see anything indicating that this code path is only used by
> glamor.
True. It's a fix for DRI3 for either UXA or "none". Mesa allocates a
single page for a 1x1 texture, but this code thinks that should take two
pages causing a texture-to-
On 7/29/2014 4:00 PM, Daniel Vetter wrote:
On Tue, Jul 29, 2014 at 12:40:29PM +0300, Ville Syrjälä wrote:
On Mon, Jul 28, 2014 at 08:47:22PM +0200, Daniel Vetter wrote:
On Mon, Jul 28, 2014 at 06:29:41PM +0300, Ville Syrjälä wrote:
On Tue, Jul 15, 2014 at 05:43:37PM +0530, sonika.jin...@inte
On Wed, Jul 30, 2014 at 09:26:17AM -0700, Rodrigo Vivi wrote:
> With this bit enabled, HW changes the color when compressing frames for
> debug purposes.
>
> ALthough the simple way to enable a single bit is over intel_reg_write,
> this value is overwriten on next update_fbc so depending on the wo
On Wed, Jul 30, 2014 at 10:47:46AM -0700, Rodrigo Vivi wrote:
> WA to skip the first page of stolen memory due to sporadic HW write on *CS
> Idle
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
>
On Wed, Jul 30, 2014 at 08:47:03PM -0700, Ben Widawsky wrote:
> On Wed, Jul 30, 2014 at 08:46:11PM -0700, Ben Widawsky wrote:
> > <1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com>
>
> and
>
> <1386367941-7131-81-git-send-email-benjamin.widaw...@intel.com>
Oops, was looking at the w
On Wed, Jul 30, 2014 at 08:46:11PM -0700, Ben Widawsky wrote:
> <1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com>
and
<1386367941-7131-81-git-send-email-benjamin.widaw...@intel.com>
>
> On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
> > Stuffing this into the conte
<1386367941-7131-76-git-send-email-benjamin.widaw...@intel.com>
On Wed, Jul 30, 2014 at 09:42:02PM +0200, Daniel Vetter wrote:
> Stuffing this into the context setup code doesn't make a lot of sense.
> Also reusing the real ppgtt setup code makes even less sense since the
> aliasing ppgtt isn't a
From: Jeff McGee
Cherryview can have different SSEU configurations within a given PCI
ID, so we collect the info from the fuse register.
I don't currently have access to a CHV, much less one with an interesting
fuse config. So I have compile-checked this only!
Signed-off-by: Jeff McGee
---
dr
From: Jeff McGee
Define a struct to capture information on the device's Slice/Subslice/EU
(SSEU) configuration. Add this struct to the main device info struct.
Define a packed bitfield form for the SSEU info and share it with
userspace via a new GETPARAM option.
Starting with Cherryview, devices
On 31.07.2014 00:21, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
>> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
>>> On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
> On W
WA to skip the first page of stolen memory due to sporadic HW write on *CS Idle
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_
>
> ->hpd_pulse() is called from a workqueue via an interrupt so it happens
> asynchronously with modesets. Grab the connection_mutex in
> intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with
> parallel hpd processing.
Nope, not right, we need to lock just not that amount of stuff, sin
According to spec FBC on BDW and HSW are identical without any gaps.
So let's copy the nuke and let FBC really start compressing stuff.
Without this patch we can verify with false color that nothing is being
compressed. With the nuke in place and false color it is possible
to see false color debug
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this
On Wed, Jul 30, 2014 at 09:42:03PM +0200, Daniel Vetter wrote:
> There's a bit a confusion since we track the global gtt,
> the aliasing and real ppgtt in the ctx->vm pointer. And not
> all callers really bother to check for the different cases and just
> presume that it points to a real ppgtt.
>
There's a bit a confusion since we track the global gtt,
the aliasing and real ppgtt in the ctx->vm pointer. And not
all callers really bother to check for the different cases and just
presume that it points to a real ppgtt.
Now looking closely we don't actually need ->vm to always point at an
add
Hardware contexts reference a ppgtt, not the other way round. And the
only user of this (in debugfs) actually only cares about which file
the ppgtt is associated with. So give it what it wants.
While at it give the ppgtt create function a proper name&place.
Signed-off-by: Daniel Vetter
---
driv
Stuffing this into the context setup code doesn't make a lot of sense.
Also reusing the real ppgtt setup code makes even less sense since the
aliasing ppgtt isn't a real address space. Leaving all that stuff
unitialized will make sure that we catch any abusers promptly.
This is also a prep work to
Stuff in headers really aught to have this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
This essentially unbreaks non-ppgtt operation where we'd scribble over
random memory.
While at it give the vm_to_ppgtt function a proper prefix and make it
a bit more paranoid.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/i915_gem.c
Now that all the flow is streamlined the rule is simple: We create
a new ppgtt for a new context when we have full ppgtt enabled.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/d
We already needs this just as a safety check in case the preallocation
reservation dance fails. But we definitely need this to be able to
move tha aliasing ppgtt setup back out of the context code to this
place, where it belongs.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c
On Wed, Jul 30, 2014 at 04:59:33PM +, Mcaulay, Alistair wrote:
> Hi Daniel,
>
> could you please be clearer on the change you mean. I think you mean
> something functionally equivalent to the code below, but done in a less hacky
> way.
> (This slight change has made no change to test result
2014-06-27 20:04 GMT-03:00 :
> From: Ville Syrjälä
>
> The VLV/CHV DDL registers are uniform, and neatly enough the register
> offsets are sane so we can easily unify them to a single set of defines
> and just pass the pipe as the parameter to compute the register offset.
What the commit message
On Wed, Jul 30, 2014 at 08:34:57PM +0530, Shobhit Kumar wrote:
> v2: Updated the error log as suggested by Imre
>
> Signed-off-by: Shobhit Kumar
> Reviewed-by: Imre Deak
Remaining patches merged, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_bios.h | 3 ++-
> drivers/gpu/drm/i9
I'm not really that insisting on checkpath compliance, but ragged
function paramter alignment does get me. Please adjust your editor to
just do this for you.
Cc: Shobhit Kumar
Cc: Imre Deak
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dsi.c | 24
dri
On Tue, Jul 29, 2014 at 08:01:53PM +0200, Daniel Vetter wrote:
> On Tue, Jul 29, 2014 at 09:59:53AM -0700, Jesse Barnes wrote:
> > On Sat, 28 Jun 2014 02:04:20 +0300
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Kenneth Graunke
> > >
> > > We'll want to reuse this for a workaround.
>
0) A ThinkPad X220 I use prints these messages at every boot and at
every resume:
[drm] Wrong MCH_SSKPD value: 0x16040307
[drm] This can cause pipe underruns and display issues.
[drm] Please upgrade your BIOS to fix this.
These messages can be seen for every kernel that's still in the
2014-07-30 15:20 GMT-03:00 Rodrigo Vivi :
>
>
>
> On Wed, Jul 30, 2014 at 11:09 AM, Paulo Zanoni wrote:
>>
>> 2014-07-28 12:19 GMT-03:00 Rodrigo Vivi :
>> > BDW has many other Display Engine interrupts and GT interrupts
>> > registers.
>> > Collecting it properly on gpu_error_state.
>> >
>> > On d
On Wed, Jul 30, 2014 at 11:09 AM, Paulo Zanoni wrote:
> 2014-07-28 12:19 GMT-03:00 Rodrigo Vivi :
> > BDW has many other Display Engine interrupts and GT interrupts registers.
> > Collecting it properly on gpu_error_state.
> >
> > On debugfs all was properly listed already but besides we were als
On Wed, Jul 30, 2014 at 10:53 AM, Paulo Zanoni wrote:
> 2014-07-28 12:19 GMT-03:00 Rodrigo Vivi :
> > GTIER and DEIER doesn't have same interface on HSW so this "or" operation
> > makes the information provided useless.
> >
> > Cc: Paulo Zanoni
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drive
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi :
> BDW has many other Display Engine interrupts and GT interrupts registers.
> Collecting it properly on gpu_error_state.
>
> On debugfs all was properly listed already but besides we were also listing
> old
> DEIER and GTIER that doesn't exist on BDW anymo
2014-07-28 12:19 GMT-03:00 Rodrigo Vivi :
> GTIER and DEIER doesn't have same interface on HSW so this "or" operation
> makes the information provided useless.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_gpu
Am 30.07.2014 11:33, schrieb Daniel Vetter:
On Wed, Jul 30, 2014 at 12:01:38AM +0200, Jan Niggemann wrote:
Am 29.07.2014 23:35, schrieb Daniel Vetter:
>On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote:
>>Am 18.07.2014 18:25, schrieb Daniel Vetter:
>>>
>>>On Fri, Jul 18, 2014 at 4:49 PM, Ja
Hi Daniel,
could you please be clearer on the change you mean. I think you mean something
functionally equivalent to the code below, but done in a less hacky way.
(This slight change has made no change to test results)
Or is the idea to return at a different point to this?
I couldn't find " dev_
On Wed, 2014-07-30 at 20:32 +0530, Shobhit Kumar wrote:
> Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
> It will not be enabled for DSI and avoid dpio read WARN dumps.
>
> Absence of ->get_config was causing other WARN dumps as well. Update
> dpll_hw_state as well corre
On Wed, Jul 30, 2014 at 08:56:07AM -0700, Matt Roper wrote:
> On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
> > In the fbdev code we want to do trylocks only to avoid deadlocks and
> > other ugly issues. Thus far we've only grabbed the overall modeset
> > lock, but that already fai
On Tue, Jul 29, 2014 at 11:32:20PM +0200, Daniel Vetter wrote:
> In the fbdev code we want to do trylocks only to avoid deadlocks and
> other ugly issues. Thus far we've only grabbed the overall modeset
> lock, but that already failed to exclude a pile of potential
> concurrent operations. With pro
On Wed, Jul 30, 2014 at 03:21:54PM +0100, Michel Thierry wrote:
> After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
> it was created for.
>
> - Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
> longer referenced.
> - Updated per_file_stats to cope with this c
From: Ville Syrjälä
->hpd_pulse() is called from a workqueue via an interrupt so it happens
asynchronously with modesets. Grab the connection_mutex in
intel_dp_hpd_pulse() to avoid disturbing on angoing modeset with
parallel hpd processing.
On my IVB turning off the port during a modeset could r
On Wed, Jul 30, 2014 at 11:07:34AM -0300, Paulo Zanoni wrote:
> 2014-07-14 16:10 GMT-03:00 Todd Previte :
> > Link training for Displayport can fail in many ways and at multiple
> > different points
> > during the training process. Previously, errors were logged but no
> > additional action
> > w
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> > On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> > > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Miche
From: Wei Yongjun
Remove duplicated include.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 47c7584..1439516 100644
--- a
On ven, 2014-07-25 at 16:31 +0800, Jike Song wrote:
> The new source codes are available at the updated github repos:
>
> Linux: https://github.com/01org/XenGT-Preview-kernel.git
> Xen: https://github.com/01org/XenGT-Preview-xen.git
> Qemu: https://github.com/01org/XenGT-Preview
On Wed, Jul 30, 2014 at 05:06:38PM +0200, Daniel Vetter wrote:
> On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote:
> > On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
> > [...]
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > [...]
> > > + re
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> > On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> > > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Miche
On Wed, Jul 30, 2014 at 04:24:06PM +0200, Thierry Reding wrote:
> On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
> [...]
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> [...]
> > + ret = wait_event_timeout(dev->vblank[crtc].queue,
> > +
v2: Updated the error log as suggested by Imre
Signed-off-by: Shobhit Kumar
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_bios.h | 3 ++-
drivers/gpu/drm/i915/intel_dsi.c | 22 ++---
drivers/gpu/drm/i915/intel_dsi.h | 2 ++
drivers/gpu/drm/i915
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of ->get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is
2014-07-14 16:10 GMT-03:00 Todd Previte :
> Add the skeleton framework for supporting automation for Displayport
> compliance testing. This patch
> adds the necessary framework for the source device to appropriately responded
> to test automation
> requests from a sink device.
>
> Signed-off-by:
2014-07-15 12:34 GMT-03:00 Todd Previte :
>
> Daniel Vetter
> Tuesday, July 15, 2014 12:46 AM
>
> On Mon, Jul 14, 2014 at 12:10:47PM -0700, Todd Previte wrote:
>
> The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
> specifies that
> repeated AUX transactions after a fail
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
> > >> On 30.07.2014 06:32, Daniel Vetter wrote:
> > >>
2014-07-14 16:10 GMT-03:00 Todd Previte :
> Move the DPCD read to the top and check for an interrupt from the sink to
> catch
> Displayport automated testing requests necessary to support Displayport
> compliance
> testing. The checks for active connectors and link status are moved below the
> ch
On Tue, Jul 29, 2014 at 11:32:22PM +0200, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
[...]
> + ret = wait_event_timeout(dev->vblank[crtc].queue,
> + C, msecs_to_jiffies(100));
100 milliseconds looks like a very a
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
v2: Get the right context for this ppgtt.
Cc: Daniel Vetter
Signed-
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, July 30, 2014 12:59 PM
> To: Thierry, Michel
> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Remove context pointer
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> On 30.07.2014 17:22, Daniel Vetter wrote:
> > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
> >> On 30.07.2014 06:32, Daniel Vetter wrote:
> >>> + * due to lack of driver support or because the crtc is off.
> >>> + */
2014-07-14 16:10 GMT-03:00 Todd Previte :
> Link training for Displayport can fail in many ways and at multiple different
> points
> during the training process. Previously, errors were logged but no additional
> action
> was taken based on them. Consequently, training attempts could continue eve
On Wed, Jul 30, 2014 at 03:57:31PM +0300, Imre Deak wrote:
> This will be needed by an upcoming patch too that needs to sanitize the
> VDD state during resume. The additional async disabling is only needed
> for the resume path, here it doesn't make a difference since we enable
> VDD right after th
On Wed, Jul 30, 2014 at 03:57:32PM +0300, Imre Deak wrote:
> Just like during booting the BIOS can leave the VDD bit enabled after
> system resume. So apply the same state sanitization there too. This
> fixes a problem where after resume the port power domain refcount gets
> unbalanced.
>
> Report
Bunch of small leftovers spotted by looking at the make htmldocs output.
I've left out dp mst, there's too much amiss there.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +++--
drivers/gpu/drm/drm_edid.c | 2 +-
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
3 fil
This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.
v2:
- don't set intel_dp ptr for non-eDP encoders
Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.
Reported-and-tested-by: Jarkko Nikula
Signed-off-by: Imre Deak
Reviewed-by:
On Wed, Jul 30, 2014 at 12:35:49PM +, Barbalho, Rafael wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of ville.syrj...@linux.intel.com
> > Sent: Saturday, June 28, 2014 12:04 AM
> > To: intel-gfx@lists.freedesktop.o
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Saturday, June 28, 2014 12:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 31/40] drm/i916: Init chv workarounds at render
I would also like a better ctx identifier than its pointer. Using the
pointer for tracking objects makes it more difficult to read traces
(although it is easy for scripts).
I use the VM pointer to track the ppgtt; that pointer is also printed by
several other traces, including the ppgtt init/rel
On Sat, 2014-07-12 at 17:17 +0530, Shobhit Kumar wrote:
> Signed-off-by: Shobhit Kumar
> ---
> drivers/gpu/drm/i915/intel_bios.h | 3 ++-
> drivers/gpu/drm/i915/intel_dsi.c | 22 ++---
> drivers/gpu/drm/i915/intel_dsi.h | 2 ++
> drivers/gpu/drm/i915/int
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Saturday, June 28, 2014 12:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 33/40] drm/i915: Polish the chv cmnlane resrt
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Saturday, June 28, 2014 12:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 32/40] drm/i915: Hack to tie both common lanes
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear th
On Wed, Jul 30, 2014 at 12:25:20PM +0100, Michel Thierry wrote:
> After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
> it was created for.
>
> - Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
> longer referenced.
> - Updated per_file_stats to cope with this c
After new vma/ppgtt lifetime rules, the ppgtt can outlive the context
it was created for.
- Renamed create_vm_for_ctx to i915_ppgtt_create as ctx/ppgtt are no
longer referenced.
- Updated per_file_stats to cope with this change.
Cc: Daniel Vetter
Signed-off-by: Michel Thierry
---
drivers/gpu/d
On Fri, Jul 11, 2014 at 02:09:40PM +, Barbalho, Rafael wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of ville.syrj...@linux.intel.com
> > Sent: Saturday, June 28, 2014 12:04 AM
> > To: intel-gfx@lists.freedesktop.o
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear th
On Wed, Jul 30, 2014 at 12:44:05PM +0200, Daniel Vetter wrote:
> So when reviewing Michel's patch I've noticed a few things and cleaned
> them up:
> - The early checks in ppgtt_release are now redundant: The inactive
> list should always be empty now, so we can ditch these checks. Even
> for th
On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated
> to 1440. The current driver reports 1440 pixel to the OS and does not set
> pixel replicated modes.
Please wrap l
On Wed, Jul 30, 2014 at 10:43:48AM +0800, libin.y...@intel.com wrote:
> From: Libin Yang
>
> call the intel_hdmi_prepare() in chv_hdmi_pre_enable() for
> hdmi audio.
>
> Signed-off-by: Libin Yang
I've just merged a similar patch from Ville, please check that it works.
-Daniel
> ---
> drivers
So when reviewing Michel's patch I've noticed a few things and cleaned
them up:
- The early checks in ppgtt_release are now redundant: The inactive
list should always be empty now, so we can ditch these checks. Even
for the aliasing ppgtt (though that's a different confusion) since
we tear th
Include depency hell ftw! So need to move this into a real function.
Also fix up the header include order in i915_drv.h: The rule is to
always include core headers first, then local stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
drivers/gpu/drm/i915/i91
On 30.07.2014 18:25, Daniel Vetter wrote:
> As usual in both a crtc index and a struct drm_crtc * version.
>
> The function assumes that no one drivers their display below 10Hz, and
> it will complain if the vblank wait takes longer than that.
>
> v2: Also check dev->max_vblank_counter since some
On 07/29/2014 06:09 PM, Dario Faggioli wrote:
Perhaps the info is available somewhere already (in which case, sorry),
but what's the (if any) upstreaming plan/status/ETA?
I think this info could well be part of these updates. :-)
Thanks for your opinion :-)
We plan to start the upstreaming wo
On Tue, Jul 29, 2014 at 11:27:55PM +0100, Siluvery, Arun wrote:
> On 28/07/2014 18:26, Ville Syrjälä wrote:
> > On Mon, Jul 28, 2014 at 05:31:45PM +0100, arun.siluv...@linux.intel.com
> > wrote:
> >> From: Arun Siluvery
> >>
> >> This patch moves BDW workarounds from init_clock_gating() to render
On Wed, Jul 30, 2014 at 12:01:38AM +0200, Jan Niggemann wrote:
> Am 29.07.2014 23:35, schrieb Daniel Vetter:
> >On Tue, Jul 29, 2014 at 11:09 PM, Jan Niggemann wrote:
> >>Am 18.07.2014 18:25, schrieb Daniel Vetter:
> >>>
> >>>On Fri, Jul 18, 2014 at 4:49 PM, Jan Niggemann wrote:
> >>>
>
> >>
On Tue, Jul 29, 2014 at 06:53:57PM -0300, Paulo Zanoni wrote:
> 2014-07-22 18:11 GMT-03:00 Jesse Barnes :
> > On Tue, 22 Jul 2014 22:53:44 +0200
> > Daniel Vetter wrote:
> >
> >> On Tue, Jul 22, 2014 at 10:48 PM, Jesse Barnes
> >> wrote:
> >> > Are you saying
> >> > you'll reject this approach e
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
v2: Adjust to the new names.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i9
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then i
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those path
On 30.07.2014 17:22, Daniel Vetter wrote:
> On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
>> On 30.07.2014 06:32, Daniel Vetter wrote:
>>> + * due to lack of driver support or because the crtc is off.
>>> + */
>>> +void drm_crtc_vblank_wait(struct drm_crtc *crtc)
>>> +{
>>> + drm
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add
1 - 100 of 103 matches
Mail list logo
