On Mon, Aug 03, 2015 at 09:28:01AM -0700, Kristian Høgsberg wrote:
> On Sat, Aug 1, 2015 at 2:06 AM, Chris Wilson wrote:
> > On Fri, Jul 31, 2015 at 10:53:26AM -0700, k...@bitplanet.net wrote:
> >> From: Kristian Høgsberg Kristensen
> >>
> >> We now have a separate tool for this in intel-gpu-tool
Op 03-08-15 om 22:09 schreef Jesse Barnes:
> Looks like
>
> commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
> Author: Maarten Lankhorst
> Date: Mon Jun 15 12:33:53 2015 +0200
> drm/i915: Update less state during modeset.
>
> introduced the unconditional calling of disable_shared_dpll, but di
On Mon, Aug 03, 2015 at 05:24:10PM +0200, Daniel Vetter wrote:
> Apparently been in there since forever and fairly easy to hit when
> hotplugging really fast. I can do that since my mst hub has a manual
> button to flick the hpd line for reprobing. The resulting WARNING spam
> isn't pretty.
>
> Cc
On Mon, Aug 03, 2015 at 05:24:08PM +0200, Daniel Vetter wrote:
> With legacy helpers all the routing was already set up when calling
> best_encoder and so could be inspected. But with atomic it's staged,
> hence we need a new atomic compliant callback for drivers which need
> to inspect the request
For the series:
Reviewed-by: Ander Conselvan de Oliveira
On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> We've had a few issues with atomic where subtle bugs in the encoder
> picking logic lead to accidental self-stealing of the encoder,
> resulting in a NULL connector_state->crtc in
Bump.
Can this be merged? It only affects android and addresses an issue causing igt
to fail to build at all on android.
//Derek
-Original Message-
From: Morton, Derek J
Sent: Monday, July 27, 2015 11:31 AM
To: intel-gfx@lists.freedesktop.org
Cc: Wood, Thomas; Gore, Tim; Morton, Derek
On Mon, Aug 03, 2015 at 05:24:11PM +0200, Daniel Vetter wrote:
> We've had a few issues with atomic where subtle bugs in the encoder
> picking logic lead to accidental self-stealing of the encoder,
> resulting in a NULL connector_state->crtc in update_connector_routing
> and subsequent.
>
> Linus
Ben Widawsky writes:
> On Mon, Aug 03, 2015 at 08:24:56PM +0100, Arun Siluvery wrote:
>> Cc: Ben Widawsky
>> Cc: Joonas Lahtinen
>> Signed-off-by: Arun Siluvery
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 3 +++
>> drivers/gpu/drm/i915/intel_pm.c | 6 ++
>> 2 files changed, 9 insertions(+
On 04/08/2015 09:58, Mika Kuoppala wrote:
Ben Widawsky writes:
On Mon, Aug 03, 2015 at 08:24:56PM +0100, Arun Siluvery wrote:
Cc: Ben Widawsky
Cc: Joonas Lahtinen
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 fil
On Fri, Jul 31, 2015 at 06:06:45PM -0300, Danilo Cesar Lemes de Paula wrote:
> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
>
> Keeping the arguments list inside the str
On Tue, Aug 04, 2015 at 11:56:08AM +0300, Ander Conselvan De Oliveira wrote:
> For the series:
>
> Reviewed-by: Ander Conselvan de Oliveira
Thanks for the review.
-Daniel
>
>
> On Mon, 2015-08-03 at 17:24 +0200, Daniel Vetter wrote:
> > We've had a few issues with atomic where subtle bugs in t
On 04/08/2015 00:21, Ben Widawsky wrote:
On Mon, Aug 03, 2015 at 08:24:57PM +0100, Arun Siluvery wrote:
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
Cc: Ben Widawsky
Cc: Joonas Lah
This WA is implemented in init_context as well as WA batch init.
There are also some dependent bits need to be set in other registers
for this to be complete.
v2: behaviour of disable gather at set shader bit can be specified by
two different registers, use a better option (Ben).
Cc: Ben Widawsky
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
Signed-off-by: Vathsala Nagaraju
---
drive
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
This patch contains the changes to remove the byte
swapping logic introduced with old dmc firmware.
While debugging PC10 entry issue for skylake found
with latest dmc firmware version 1.18 without byte
swapping dmc is working fine and able t
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
Mmio register access after dc6/dc5 entry is not allowed when
DC6 power states are enabled according to bspec (bspec-id 0527),
so enabling dc6 as the last call in suspend flow.
v1: Initial version.
v2: commit message updated based on commen
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
While display engine entering into low power state no need to disable
cdclk pll as CSR firmware of dmc will take care. If pll is already
enabled firmware execution sequence will be blocked. This is one
of the criteria for dmc to work properl
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
Another interesting criteria to work dmc as expected is pw1 to be
enabled by driver and dmc will shut it off in its execution
sequence. If already disabled by driver dmc will get confuse and
behave differently than expected found during pc10
On Tuesday 04 August 2015 12:17 AM, Zanoni, Paulo R wrote:
Em Seg, 2015-08-03 às 21:55 +0530, Animesh Manna escreveu:
The following patches helps to solve PC10 entry issue for SKL.
Detailed description about the changes done to solve the issue
is mentioned in commit message of each patch.
All t
On 8/4/2015 4:50 PM, Sunil Kamath wrote:
On Monday 03 August 2015 09:55 PM, Animesh Manna wrote:
As csr firmware is taking care of loading the firmware,
so no need for driver to load again.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
S
Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
"drm/atomic: Cleanup on error properly in the atomic ioctl."
cleaned up some error paths, but didn't fix the TEST_ONLY path.
In the check only case plane->fb shouldn't be updated, and
the vblank events should be cleared as on failure.
Signed-off-by:
Describing arguments at top of a struct definition works fine
for small/medium size structs, but it definitely doesn't work well
for struct with a huge list of elements.
Keeping the arguments list inside the struct body makes it easier
to maintain the documentation.
ie:
/**
* struct my_struct - s
On 08/02/2015 09:43 AM, Pavel Machek wrote:
> Any chance to bisect it?
Did it.
FWIW: the mentioned commit was introduced between 3.18 and 3.19.
But my system (hardened 64 bit Gentoo) did not suffer from it till version
4.0.8.
The hardened kernel 4.1.x was the first where the bug was visible at my
Em Ter, 2015-08-04 às 17:01 +0530, Sunil Kamath escreveu:
> On Tuesday 04 August 2015 12:17 AM, Zanoni, Paulo R wrote:
> > Em Seg, 2015-08-03 às 21:55 +0530, Animesh Manna escreveu:
> > > The following patches helps to solve PC10 entry issue for SKL.
> > > Detailed description about the changes don
VBT version 196 increased the size of common_child_dev_config. The parser
code assumed that the size of this structure would not change.
The modified code now copies the amount needed based on the VBT version,
and emits a debug message if the VBT version is unknown (too new);
since the struct conf
Arun Siluvery writes:
> A programming restriction exists for this instruction, atleast one component
> of one valid vertex element must be enabled.
>
> Cc: Ben Widawsky
> Cc: Chris Wilson
> Signed-off-by: Arun Siluvery
Reviewed-by: Mika Kuoppala
> ---
> tools/null_state_gen/intel_rendersta
"Siluvery, Arun" writes:
> On 16/07/2015 16:19, Arun Siluvery wrote:
>> MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really
>> variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects
>> (reg, addr) pairs so use fixed length for these instructions.
>>
>> Cc: D
Hi Linus,
Special pull request for mst fixes since most of the patches touch code
outside of i915 proper. DRM parts have also been reviewed by Thierry
(nvidia) since Dave's enjoying vacations.
Cheers, Daniel
The following changes since commit 74d33293e467df61de1b1d8b2fbe29e550dec33b:
Linux 4
This patch series has the changes done to redesign the dmc firmware
loading flow. This is continuation of the below patch series after
addressing review comments from Daniel.
http://lists.freedesktop.org/archives/intel-gfx/2015-July/072331.html
Few patches from the above patch series are seperated
As skl is fully dependent on dmc to go to low power state (dc5/dc6)
which requires a trigger from rpm and to ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference acquire when starting the
firmware loader work.
So moved the intel
From: Daniel Vetter
If we really want to we can be more verbose here, but we really don't
need an entire function for this.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Daniel Vetter
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 20
From: Daniel Vetter
The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.
Also restrict the forced big-edian casting to just one
From: Daniel Vetter
As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Daniel Vetter
Signed-off-by: Animesh Manna
-
During driver unload to ensure we dont have any pending task,
flush_work added to complete firmware loading task.
v1: Initial version.
v2: As per review comments from Daniel,
Removed flush_work from skl_set_power_well. As we have taken
power well refernece and rpm count during firmware loading
by
From: Daniel Vetter
Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
which is a notch more obvious what it does than having a special
completion.
The next patch will properly synchronize against the async loader in
th
From: Daniel Vetter
We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Daniel Vetter
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_csr.c | 3 +++
1 file changed, 3 ins
From: Daniel Vetter
Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.
Apply this across the entire file since it was sticking out a bit too
much.
Also align register definitions while at it.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sun
Note that for bxt without dmc, display engine can go to lowest
possible state (dc9), so releasing the rpm reference.
Cc: Daniel Vetter
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_csr.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Daniel Vetter
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_program.
Instead ordering should be ensured
From: Daniel Vetter
Avoids non-static functions since all the callers are in intel_rpm.c.
Only thing we need for that is to move the register definitions into
i915_reg.h.
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Daniel Vetter
Signed-off-by: Animesh Manna
---
drivers
MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really
variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects
(reg, addr) pairs so use fixed length for these instructions.
v2: rebase
Cc: Dave Gordon
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_
From: Daniel Vetter
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).
Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display pow
On Mon, Aug 3, 2015 at 4:36 PM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 31-07-15 om 15:04 schreef Patrik Jakobsson:
>> When reading out hw state for planes we disable inactive planes which in
>> turn triggers an update of the watermarks. The update depends on the
>> crtc_clock being set which is do
On Mon, Aug 03, 2015 at 12:25:11PM -0400, Theodore Ts'o wrote:
> On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
> >
> > Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> > fix it. Plus a patch to convert Linus' hack into something we can keep
> > plus a driv
This patches will extend the support for broxton.
Earlier these patches are sent part of "Redesign of dmc firmware loading"
patch series.
http://lists.freedesktop.org/archives/intel-gfx/2015-July/072331.html
To make it simple, bxt specific patches are seperated out and based on
review comments fr
Modified HAS_CSR macro defination which earlier only supported
for skl, now added support for BXT.
v1: Initial version.
v2: Instaed of skylake/broxton check added gen9 check alone based
on review comment from Sunil.
Cc: Vetter, Daniel
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-
Broxton also has dmc to manage low-power display engine state.
Path of the firmware added in intel_csr.c.
Naming convention followed as _dmc_.bin
v1: Initial version.
v2: Commit description added based on review comment from Sunil.
Cc: Damien Lespiau
Cc: Rodrigo Vivi
Cc: Sunil Kamath
Signed-
Added stepping info in intel_csr.c which is required to extract
specific firmware from packaged dmc firmware.
Stepping info is aligned with current bspec info.
Cc: Vetter, Daniel
Cc: Damien Lespiau
Cc: Imre Deak
Cc: Sunil Kamath
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/intel_cs
Reviewed-by: Rodrigo Vivi
On Tue, 2015-08-04 at 22:02 +0530, Animesh Manna wrote:
> Broxton also has dmc to manage low-power display engine state.
> Path of the firmware added in intel_csr.c.
>
> Naming convention followed as _dmc_.bin
>
> v1: Initial version.
>
> v2: Commit description added
tree: git://anongit.freedesktop.org/drm-intel topic/kerneldoc
head: 86fea2bafc9b25f0915dd46039305ec3bfb0aaf4
commit: 86fea2bafc9b25f0915dd46039305ec3bfb0aaf4 [5/5] scripts/kernel-doc Allow
struct arguments documentation in struct body
reproduce: make htmldocs
All warnings (new ones prefixed b
If the Kernel is too old, getparam will return -EINVAL. Just SKIP on
this case.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89739
Cc: Chris Wilson
Signed-off-by: Paulo Zanoni
---
tests/gem_mmap_wc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/gem_mma
On Tue, Aug 04, 2015 at 11:21:53AM +0100, Arun Siluvery wrote:
> This WA is implemented in init_context as well as WA batch init.
> There are also some dependent bits need to be set in other registers
> for this to be complete.
>
> v2: behaviour of disable gather at set shader bit can be specified
I started digging this when I noticed that the BDW code was just
reserving 1mb by coincidence since it was reading reserved fields.
Then I noticed we didn't have any values set for SNB and earlier, and
that the HSW sizes were wrong. After that, I noticed that the reserved
area has a specific start,
On 07/31/2015 06:02 PM, Chris Wilson wrote:
The first problem is that llc does not guarrantee that the buffer is
cache coherent with all aspects of the GPU. For scanout and similar
writes need to be WC.
if (obj->has_framebuffer_references) would at least catch where the fb
is made before the mm
On Fri, Jul 31, 2015 at 04:27:07PM +0100, Arun Siluvery wrote:
> A programming restriction exists for this instruction, atleast one component
> of one valid vertex element must be enabled.
>
> Cc: Ben Widawsky
> Cc: Chris Wilson
> Signed-off-by: Arun Siluvery
> ---
> tools/null_state_gen/intel
On Fri, Jul 31, 2015 at 04:28:45PM +0100, Arun Siluvery wrote:
> Atleast one component of one valid vertex element must be enabled.
>
> Cc: Ben Widawsky
> Cc: Chris Wilson
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/intel_renderstate_gen9.c | 2 +-
> 1 file changed, 1 insertion
From: Sourab Gupta
The periodic reports and the RCS based reports are collected in two
separate buffers. While forwarding to userspace, these have to be sent to
single perf event ringbuffer. From a userspace perspective, it is good to
have the reports in the single buffer in order to their timest
From: Sourab Gupta
This is the updated patch series(v3 - changes listed at end), which adds
support for capturing OA counter snapshots for multiple contexts, by inserting
MI_REPORT_PERF_COUNT commands into CS, and forwarding these snapshots to
userspace using perf interface.
This work is based o
From: Sourab Gupta
The current context user handles are specific to drm file instance.
There are some usecases, which may require a global id for the contexts.
For e.g. a system level GPU profiler tool may lean upon the global context
ids to associate the performance snapshots with individual con
From: Sourab Gupta
This patch introduces a mode of capturing OA counter reports belonging to
multiple contexts, which can be mapped back to individual contexts. The OA
reports captured in this way are synchronized with Render command stream.
There may be usecases wherein we need more than period
From: Sourab Gupta
This patch adds the mechanism for forwarding the CS based OA snapshots
through the perf event interface.
The OA snapshots will be captured in a gem buffer object. The metadata
information (ctx global id, as of now) pertaining to snapshot is maintained
in a list, which has offs
From: Sourab Gupta
This patch adds the routines which insert commands for capturing OA
snapshots into the ringbuffer of RCS engine.
The command MI_REPORT_PERF_COUNT can be used to capture snapshots of OA
counters, which is inserted at BB boundaries.
While inserting the commands, we keep a refere
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with the
OA reports generated through the RCS commands.
When the userspace expresses its interest in listening to the pid through
an oa_attr field during event init, the OA reports generated would have an
addit
From: Sourab Gupta
In the periodic OA sampling mode, the event stop would stop forwarding
samples to userspace, and disables OA synchronously. The buffer is
destroyed eventually in event destroy callback. But when we have in flight
RPC commands scheduled on GPU (like in this case), the handling o
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An ab
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with the
timestamp samples and forwarding them through perf.
When the userspace expresses its interest in listening to the pid through a
gen pmu attr field during event init, the samples generated would have an
From: Sourab Gupta
The current perf PMU driver is specific for collection of OA counter
statistics (which may be done in a periodic or asynchronous way). Since
this enables us (and limits us) to render ring, we have no means for
collection of data pertaining to other rings.
To overcome this limi
From: Sourab Gupta
This is an updated patch set (v3 - changes list at end), which builds upon the
multi context OA patch set introduced earlier at:
http://lists.freedesktop.org/archives/intel-gfx/2015-August/072949.html
The OA unit, as such, is specific to render ring and can't cater to perform
From: Sourab Gupta
This patch handles the event stop and destroy callbacks taking into account
the fact that there may be commands scheduled on GPU which may utilize the
destination buffer.
The event stop would just set the event state, and stop forwarding data to
userspace. From userspace persp
From: Sourab Gupta
This patch adds the routines through which one can insert commands in the
ringbuf for capturing timestamps, which are used to insert these commands
around the batchbuffer.
While inserting the commands, we keep a reference of associated request.
This will be released when we ar
From: Sourab Gupta
This patch adds the mechanism for forwarding the timestamp data to
userspace using the Gen PMU perf event interface.
The timestamps will be captured in a gem buffer object. The metadata
information (ctx global id right now) pertaining to snapshot is maintained
in a list, whose
From: Sourab Gupta
This patch introduces flags and adds support for having ring id output with
the timestamp samples and forwarding them through perf.
When the userspace expresses its interest in listening to the ring id
through a gen pmu attr field during event init, the samples generated would
From: Sourab Gupta
This patch adds support for retrieving MMIO register values alongwith
timestamps and forwarding them to userspace through perf.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of upto 8 MMIO registers can be passed through perf attr
config. The
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to timestamps samples, to help
associate samples with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspectiv
74 matches
Mail list logo
