From: Jani Nikula
Signed-off-by: Jani Nikula
Signed-off-by: Mengdong Lin
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a90fdbd..21170e5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6256,6 +6256,27 @@ int i915_rele
use mm.h definition
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Fabian Frederick
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
2 files changed, 6 insertions(+)
On Thu, 26 Jun 2014 18:24:09 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added a DRM debug facility for use by the scheduler.
> ---
> include/drm/drmP.h |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 76cca
On Thu, 26 Jun 2014 18:24:08 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler decouples the submission of batch buffers to the driver with
> their
> submission to the hardware. This basically means splitting the execbuffer()
> function in half. This change rearrang
On Thu, 26 Jun 2014 18:24:07 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler needs to explicitly allocate a seqno to track each submitted
> batch
> buffer. This must happen a long time before any commands are actually written
> to
> the ring.
> ---
> drivers/gpu
On Thu, 26 Jun 2014 18:24:05 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> This is required by user land validation programs that need to know whether
> the
> scheduler is available for testing or not.
> ---
> drivers/gpu/drm/i915/i915_dma.c |3 +++
> include/uapi/drm/i9
On Thu, 26 Jun 2014 18:24:04 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler decouples the submission of batch buffers to the driver with
> submission of batch buffers to the hardware. Thus it is possible for an
> application to submit work, then close the DRM hand
Thank you so much for your reply
Ying
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Wednesday, July 02, 2014 3:04 AM
To: Liu, Ying2
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] how to build intel-gpu-tools without cairo
On 1 July 2014 19:49, L
On Thu, 26 Jun 2014 18:24:03 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Hardware sempahores require seqno values to be continuously incrementing.
> However, the scheduler's reordering of batch buffers means that the seqno
> values
> going through the hardware could be out
On Thu, 26 Jun 2014 18:24:02 +0100
john.c.harri...@intel.com wrote:
> +bool i915_scheduler_is_seqno_in_flight(struct intel_engine_cs *ring,
> + uint32_t seqno, bool *completed);
> +
In what cases might the return value not match the completed value? I
guess I'll see i
On Thu, 26 Jun 2014 18:24:01 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A major point of the GPU scheduler is that it re-orders batch buffers after
> they
> have been submitted to the driver. Rather than attempting to re-assign seqno
> values, it is much simpler to have ea
On Wed, Jul 02, 2014 at 12:05:27PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > > Il 01/
On Thu, 26 Jun 2014 18:24:00 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Created GPU scheduler source files with only a basic init function.
> ---
> drivers/gpu/drm/i915/Makefile |1 +
> drivers/gpu/drm/i915/i915_drv.h |4 +++
> drivers/gpu/drm/i915/i9
On Thu, 26 Jun 2014 18:23:58 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There is a workaround for a hardware bug when reading the seqno from the
> status
> page. The bug does not exist on VLV however, the workaround was still being
> applied.
> ---
> drivers/gpu/drm/i915/
On Thu, 26 Jun 2014 18:23:57 +0100
john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The previous code was not correctly masking the value of the GTFIFOCTL
> register,
> leading to overruns and the message "MMIO read or write has been dropped". In
> addition, the checks were repeated i
On Thu, 26 Jun 2014 18:23:56 +0100
john.c.harri...@intel.com wrote:
> + * Premption-related registers
> + */
> +#define RING_UHPTR(base) ((base)+0x134)
> +#define UHPTR_GFX_ADDR_ALIGN (0x7)
> +#define UHPTR_VALID(0x1)
> +#define RING_PREEMPT_ADDR0x
On Wed, Jul 02, 2014 at 10:31:45AM +, Madajczak, Tomasz wrote:
> Ad>Tomasz: is the intention to only measure within a batch? My impression is
> that you wanted to maintain the OABUFFER programmed and then collect
> performance reports for a period of time (probably for several
> batchbuffers).
2014-06-25 16:01 GMT-03:00 Imre Deak :
> From: Daniel Vetter
>
> This way only the dynamic WRPLL selection for hdmi ddi mode is
> done in intel_ddi_pll_select.
>
> v2: Don't clobber the precomputed values when selecting clocks fro
> hdmi encoders.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers
On Wed, Jul 02, 2014 at 12:23:37PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> > Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> > >With this long thread I lost a bit context about the challenges
> > >that exists. But let me try su
On Wed, Jul 02, 2014 at 06:29:23PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 17:27, Michael S. Tsirkin ha scritto:
> > At some level, maybe Paolo is right. Ignore existing drivers and ask
> > intel developers to update their drivers to do something sane on
> > hypervisors, even if they do ugly t
Hi Daniel,
Is it possible to get this patch on the review board? I've been on vacation a
couple of weeks and haven't been around to push it.
Thanks,
Armin
-Original Message-
From: Reese, Armin C
Sent: Thursday, June 12, 2014 2:19 PM
To: intel-gfx@lists.freedesktop.org
Cc: Reese, Armin
Il 02/07/2014 18:23, Konrad Rzeszutek Wilk ha scritto:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 651e65e..03f2829 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -433,6 +433,8 @@ void intel_detect_pch(struct drm_devi
On Wed, Jul 02, 2014 at 04:50:15PM +0200, Paolo Bonzini wrote:
> Il 02/07/2014 16:00, Konrad Rzeszutek Wilk ha scritto:
> >With this long thread I lost a bit context about the challenges
> >that exists. But let me try summarizing it here - which will hopefully
> >get some consensus.
> >
> >1). Fix
Am Montag, den 30.06.2014, 11:09 +0100 schrieb Chris Wilson:
> On Mon, Jun 30, 2014 at 12:02:20PM +0200, Pavel Machek wrote:
> > On Tue 2014-06-24 13:27:37, Chris Wilson wrote:
> > > On Tue, Jun 24, 2014 at 02:24:30PM +0200, Thomas Meyer wrote:
> > > > Am Dienstag, den 24.06.2014, 12:57 +0100 schri
On Wed, Jul 02, 2014 at 05:08:43PM +0300, Michael S. Tsirkin wrote:
> On Wed, Jul 02, 2014 at 10:00:33AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jul 02, 2014 at 01:33:09PM +0200, Paolo Bonzini wrote:
> > > Il 01/07/2014 19:39, Ross Philipson ha scritto:
> > > >
> > > >We do IGD pass-through
2014-07-02 5:35 GMT-03:00 Jani Nikula :
> From: Clint Taylor
>
> The panel power sequencer on vlv doesn't appear to accept changes to its
> T12 power down duration during warm reboots. This change forces a delay
> for warm reboots to the T12 panel timing as defined in the VBT table for
> the conne
Hi
> Chris alludes to the fact that if there's a way for one application to gather
> data about other applications (whatever kind of data), that's an automatic
> security concern.
We have a few use cases for OA buffer and "one application to gather data about
other applications" is basically a d
On Wed, Jul 02, 2014 at 02:12:08PM +0100, Damien Lespiau wrote:
> On Wed, Jul 02, 2014 at 03:57:08PM +0300, Jani Nikula wrote:
> > On Wed, 02 Jul 2014, Chris Wilson wrote:
> > > Adapt the macro so that we can pass either the struct drm_device or the
> > > struct drm_i915_private pointers and get t
On Wed, Jul 02, 2014 at 02:21:52PM +0530, Jindal, Sonika wrote:
> Hi,
>
> Did anybody get a chance to review these patches?
Ok, now those patches are all over the place. It's pretty much
impossible to have the big picture again with the latest changes (the
rotation on drm_plane) nor the limit of
On Wed, Jul 02, 2014 at 03:57:08PM +0300, Jani Nikula wrote:
> On Wed, 02 Jul 2014, Chris Wilson wrote:
> > Adapt the macro so that we can pass either the struct drm_device or the
> > struct drm_i915_private pointers and get the answer we want.
>
> Polymorphism?! :o
>
> >textdata bss
On Wed, 02 Jul 2014, Chris Wilson wrote:
> Adapt the macro so that we can pass either the struct drm_device or the
> struct drm_i915_private pointers and get the answer we want.
Polymorphism?! :o
>textdata bss dec hex filename
> 8138307 1234176 679936 10052419 996343
Adapt the macro so that we can pass either the struct drm_device or the
struct drm_i915_private pointers and get the answer we want.
textdata bss dec hex filename
8138307 1234176 679936 10052419 996343 vmlinux.before
8137591 1234176 679936 10051703 996077 vmlin
On Tue, 01 Jul 2014, Fabian Frederick wrote:
> use mm.h definition
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Fabian Frederick
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
>
On Fri, 27 Jun 2014, Ville Syrjälä wrote:
> On Sat, Jun 28, 2014 at 11:26:11AM +0530, deepa...@linux.intel.com wrote:
>> From: Deepak S
>>
>> Workaround fixed in Latest VLV revision. Forcing Gfx clk up not needed, and
>> Requesting the
>> min freq should bring bring the voltage Vnn.
>>
>> v2:
bo_pin had so far root privileges - they were sufficient and it would be
enough to get bo_pin back the same way. This also implies that root can only
start the OA buffer measurements.
-Tomasz
-Original Message-
From: Lespiau, Damien
Sent: Wednesday, July 02, 2014 12:49 PM
To: Madajczak,
On Tue, 01 Jul 2014, "O'Rourke, Tom" wrote:
>>>From: Ben Widawsky [mailto:b...@bwidawsk.net]
>>>Sent: Friday, June 20, 2014 9:43 AM
>>>On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
Higher RC6 residency is observed using timeout mode instead of EI
mode. This applies to Br
On Wed, Jun 25, 2014 at 11:08:06AM +0530, sonika.jin...@intel.com wrote:
> From: Sagar Kamble
>
> Cc: damien.lesp...@intel.com
> Cc: daniel.vet...@ffwll.ch
> Cc: ville.syrj...@linux.intel.com
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Sagar Kamble
Revie
On Wed, Jun 25, 2014 at 11:08:05AM +0530, sonika.jin...@intel.com wrote:
> From: Sagar Kamble
>
> These property descriptions were kept as placeholder. Removing them for
> simplicity.
>
> Cc: damien.lesp...@intel.com
> Cc: daniel.vet...@ffwll.ch
> Cc: ville.syrj...@linux.intel.com
> Cc: linux-.
Hi,
Could you explain more why you can't use cairo in your environment?
Don't you want the display tests at all (that's where cairo is used)?
There's a way to not use cairo with the android build system, but not
currently with the autotools one. We'd rather have a good reason to add
some maintena
On Wed, Jul 02, 2014 at 10:31:45AM +, Madajczak, Tomasz wrote:
> There isn't any secret or privacy in that OA buffer data - just
> results of performance counters, shown by tools such as GPA/ Vtune.
Chris alludes to the fact that if there's a way for one application to
gather data about other
Ad>Tomasz: is the intention to only measure within a batch? My impression is
that you wanted to maintain the OABUFFER programmed and then collect
performance reports for a period of time (probably for several
batchbuffers). If that´s the case, the relocation approach is not possible.
I confirm tha
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Thomas Wood
> Sent: Wednesday, July 02, 2014 11:04 AM
> To: Liu, Ying2
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] how to build intel-gpu-tools without cairo
>
> On 1
On 1 July 2014 19:49, Liu, Ying2 wrote:
> The latest intel-gpu-tools has dependency on cairo. We don’t use cairo.
>
> Is there any way to build intel-gpu-tools without cairo?
Cairo has been a required dependency since version 1.2. It is used by
various tests and tools and therefore there isn't a
On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote:
> This does not ring any bells to me (but that doesn't prove anything). A
> bisect result would be awesome.
Too bad.
Unless someone else has a better idea I hope to start bisecting one of
these days (that might take quite some time, especially
Hi,
Did anybody get a chance to review these patches?
Thanks,
Sonika
On 6/24/2014 5:38 PM, sonika.jin...@intel.com wrote:
From: Sonika Jindal
As suggested by Daniel and Damien, moved rotation_property to drm_plane.
Also moved resetting of rotation_property to restore_fbdev_mode which will be
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wed
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.
Ver2: removed redundant pr_crit(), com
On 2014/7/2 14:21, Michael S. Tsirkin wrote:
On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
Originally the reason to probe ISA bridge instead of Dev31:Fun0
is to make graphics device passthrough work easy for VMM, that
only need to expose ISA bridge to let driver know the real
hard
On Tue, 03 Jun 2014, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> The panel power sequencer on vlv doesn't appear to accept changes to its
> T12 power down duration during warm reboots. This change forces a delay
> for warm reboots to the T12 panel timing as defined in the VBT table
On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This is a requirement f
50 matches
Mail list logo
