On Thu, Dec 01, 2016 at 01:44:16PM +0530, swati.dhin...@intel.com wrote:
> From: Swati Dhingra
>
> During drm module initialization, drm_core_init initializes the drmfs
> filesystem and register this with kernel. A driver specific directory is
> created
> inside drmfs root, and dentry of this di
On Tue, 2016-11-29 at 13:48 +0200, Ander Conselvan de Oliveira wrote:
> In commit c39055b072f8 ("drm/i915: Pass dev_priv to
> intel_setup_outputs()"), I forgot to update the kerneldoc for
> intel_psr_init() init, leading to warnings when building the
> documentation:
>
> drivers/gpu/drm/i915/i
On Thu, Dec 01, 2016 at 01:44:15PM +0530, swati.dhin...@intel.com wrote:
> From: Swati Dhingra
>
> The patch introduces a new pseudo filesystem type, named 'drmfs' which is
> intended to house the files for the data generated by drm subsystem that
> cannot be accommodated by any of the existing f
On Thu, Dec 01, 2016 at 01:44:14PM +0530, swati.dhin...@intel.com wrote:
> From: Swati Dhingra
>
> Currently, for the purpose of providing output debug/loggging/crc and various
> other kinds of data from DRM layer to userspace, we don't have a standard
> filesystem, which would suffice for all th
Any comments? Thanks.
Regards,
Libin
>-Original Message-
>From: Yang, Libin
>Sent: Thursday, December 1, 2016 1:17 PM
>To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com;
>ville.syrj...@linux.intel.com; Vetter, Daniel ;
>Pandiyan, Dhinakaran ; ti...@suse.de
>Cc: Yang, Libin
== Series Details ==
Series: drm/i915: Calculate common rates and max lane count in Long pulse
handler
URL : https://patchwork.freedesktop.org/series/16250/
State : warning
== Summary ==
Series 16250v1 drm/i915: Calculate common rates and max lane count in Long
pulse handler
https://patchwor
Supported link rate common to source and sink as well as the
maximum supported lane count based on source and sink capabilities should
be set only once on hotplug and then used anytime they are requested.
This patch creates and array of common rates and max lane count as the
intel_dp member. It get
A reviewed backwards because I was willing to check if all ifs were in place.
I missed the ones from i915_drv.c
*** i915_drv.c:
i915_drm_suspend_late[1500]fw_csr = !IS_GEN9_LP(dev_priv) &&
i915_drm_suspend_late[1513]if (IS_GEN9_LP(dev_priv))
i915_drm_resume_early[1721]if (IS_GEN9_LP(d
This could also be squashed or reviewed-by you...
either works for me, I just cannot review the patch that I'm listed as author ;)
On Thu, Nov 10, 2016 at 05:23:11PM +0200, Ander Conselvan de Oliveira wrote:
> From: Rodrigo Vivi
>
> As for BXT, GLK doesn't support port detection through SFUSE_S
This could be squashed to the other bit patch with s/broxton/gen9_lp...
but anyway
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:12PM +0200, Ander Conselvan de Oliveira wrote:
> Geminilake uses the same lane latency optimization masks and registers
> as Broxton, so reuse the code wi
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:13PM +0200, Ander Conselvan de Oliveira wrote:
> Geminilake has power wells are similar to SKL, but with the misc IO well
> being split into separate AUX IO wells.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/dr
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:16PM +0200, Ander Conselvan de Oliveira wrote:
> From: Madhav Chauhan
>
> Add steps for enabling and disabling Port PLL as per bspec.
>
> Signed-off-by: Madhav Chauhan
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/g
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:17PM +0200, Ander Conselvan de Oliveira wrote:
> Geminilake has the same register layout, reference clock and programming
> sequence as broxton. The difference is that it doesn't support the 1.5
> divider and has different ratios, but a lo
== Series Details ==
Series: drm/i915: Provide a hook for selftests
URL : https://patchwork.freedesktop.org/series/16246/
State : success
== Summary ==
Series 16246v1 drm/i915: Provide a hook for selftests
https://patchwork.freedesktop.org/api/1.0/series/16246/revisions/1/mbox/
Test kms_force
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:18PM +0200, Ander Conselvan de Oliveira wrote:
> Geminilake has double wide pipes so it can output two pixels per CD
> clock.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:19PM +0200, Ander Conselvan de Oliveira wrote:
> The sequence is pretty much the same as broxton, except that bspec
> requires the AUX domains to be enabled. But since those can't be enabled
> before the phys are initialized, we just use t
Reviewed-by: Rodrigo Vivi
On Thu, Nov 10, 2016 at 05:23:20PM +0200, Ander Conselvan de Oliveira wrote:
> Geminilake has 4 planes (3 sprites) per pipe.
>
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 5 -
> 1 file changed, 4 insertions(
On Thu, Dec 01, 2016 at 11:32:44PM +, Chris Wilson wrote:
> To facilitate integration with igt, any parameter beginning with
> i915.subtest__ is interpreted as a selftest subtest executable
> independently via igt/drv_selftest.
>
> +#define selftest(name, func) \
> +module_param_named(subtest_
On Thu, Dec 01, 2016 at 02:23:54PM +0200, Marius Vlad wrote:
> Latest changes include addressing comments from previous version and include
> some notes about driver loading/unloading when using in combination to
> drm_open_driver().
Pushed the first 2 since I had an ulterior motive in writing a i
Some pieces of code are independent of hardware but are very tricky to
exercise through the normal userspace ABI or via debugfs hooks. Being
able to create mock unit tests and execute them through CI is vital.
Start by adding a central point where we can execute unit tests from and
a parameter to e
Hi Stephen,
On 1 December 2016 at 20:45, Stephen Rothwell wrote:
> On Thu, 01 Dec 2016 11:02:26 + Daniel Stone wrote:
>> Sorry about this, it is quite bad. I think having mirrors for the key DRM
>> trees on GitHub is a good idea though, and I can get to setting that up.
>> Stephen, you need
Hi Daniel,
On Thu, 01 Dec 2016 11:02:26 + Daniel Stone wrote:
>
> On Nov 30 2016, at 10:49 pm, Rob Clark wrote:
>
> > yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
> git urls for folks who have push access work fine).. although it has
> worked for me a coupl
On Thu, Dec 01, 2016 at 06:08:25PM +, Tvrtko Ursulin wrote:
> Merged to dinq. Thanks for the review! (And for spotting all the
> places where it is needed.) :)
Oops, better run make htmldocs and catch the important information that
intel_guc_fini() takes dev_priv.
-Chris
--
Chris Wilson, Int
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drive
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goede
---
drivers/gpu/dr
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1 file changed, 2 insertio
For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --gi
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier to follow the init sequ
On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(),
make intel_dsi_disable() also directly call intel_disable_dsi_pll(),
rather then hiding the call in intel_dsi_clear_device_ready(),
no functional changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 4 ++-
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 64
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/i915
MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons:
1) The reset should already be asserted before intel_dsi_pre_enable()
gets called
2) Most (some?) VBTs will ensure reset was asserted in their
MIPI_SEQ_DEASSERT_RESET themselves
Signed-off-by: Hans de Goede
---
drivers/g
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers
The enable path has an intel_dsi_prepare() helper which prepares various
registers for the mode-set. Move the function undoing this to a new
intel_dsi_unprepare() helper for better symmetry between the enable and
disable paths. No functional changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/
intel_dsi_disable/enable only have one caller, merge them into their
respective callers.
Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy,
otherwise no funtional changes.
The main advantage of this change is that it makes it easier to
follow all the steps of the panel enabl
Move the intel_dsi_clear_device_ready() function to higher up in
intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs
intel_dsi_*enable* with intel_dsi_*disable without
intel_dsi_clear_device_ready() sitting in the middle of them.
This commit purely moves code around, it does not mak
The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
not fine grained enough to abstract all the different steps we need to
take (and VBT sequences we need to exec) properly. So simply remove the
panel _enable/disable and prepare/unprepare callbacks and instead
export intel_dsi_ex
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio.
Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV")
Cc: sta...@vger.kernel.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Hans de Goede
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ds
Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling
a drm_panel_foo helper which calls VBT sequences, move it to the VBT
mipi_exec_send_packet helper, which is the one VBT instruction which
actually puts data in the fifo.
This results in a nice cleanup making it clearer what
Looking at the ADF code from the Android kernel sources for a
cherrytrail tablet I noticed that it is calling the
MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook.
Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences
in panel prepare/unprepare hooks") the mainline i
Hi All,
So while trying to fix my cherrytrail tablet's screen sometimes not
initializing properly (*) I started working on this series to cleanup /
(minor) refactor the dsi enable / disable code, with as goal to then
change it to match the enable / disable sequences which Ville Syrjälä
recently du
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 192aa18142b28fdcb63b12984e02466ced382a54
commit: bf9e8429ab9747f584e692bad52a7a9f1787a4da [3/10] drm/i915: Make various
init functions take dev_priv
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
m
On Thu, Dec 1, 2016 at 1:58 PM, Manasi Navare wrote:
> Sean, could you please review this patch, I have tried to address
> all the comments from you.
>
Comments look good to me.
Reviewed-by: Sean Paul
Sean
> Regards
> Manasi
>
> On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
>
Sean, could you please review this patch, I have tried to address
all the comments from you.
Regards
Manasi
On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> At the time userspace does setcrtc, we've already promised the mode
> would work. The promise is based on the theoretical ca
>-Original Message-
>From: Hiler, Arkadiusz
>Sent: Thursday, December 1, 2016 4:23 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Mcgee, Jeff ;
>Kamble, Sagar A
>Subject: Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct
>for
>GuC and HuC
>
>On Wed, No
== Series Details ==
Series: drm/i915/perf: use DRM_DEBUG for userspace issues
URL : https://patchwork.freedesktop.org/series/16236/
State : success
== Summary ==
Series 16236v1 drm/i915/perf: use DRM_DEBUG for userspace issues
https://patchwork.freedesktop.org/api/1.0/series/16236/revisions/1
On 01/12/2016 14:45, Patchwork wrote:
== Series Details ==
Series: GEM object create and driver init dev_priv cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/16162/
State : warning
== Summary ==
Series 16162v2 GEM object create and driver init dev_priv cleanups
https://patchw
== Series Details ==
Series: drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
URL : https://patchwork.freedesktop.org/series/16235/
State : success
== Summary ==
Series 16235v1 drm: Enable dynamic debug for DRM_[DEV]_DEBUG*
https://patchwork.freedesktop.org/api/1.0/series/16235/revisions/1/mbox/
On Thu, Dec 01, 2016 at 02:16:40PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> dev_priv is more appropriate for these so converting saves
> some lines of source.
>
> v2: Commit message and keep the pdev local variable. (Joonas Lahtinen)
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-
On Thu, Dec 01, 2016 at 02:16:37PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Makes all GEM object constructors consistent.
>
> v2: Fix compilation in GVT code.
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Chris Wilson (v1)
> Reviewed-by: Joonas Lahtinen (v1)
Still lgtm to
Avoid using DRM_ERROR for conditions userspace can trigger with a bad
config when opening a stream or from not reading data in a timely
fashion (whereby the OA buffer fills up). These conditions are tested
by i-g-t which treats error messages as failures if using the test
runner. This wasn't an iss
I'm currently considering the use of DRM_ERROR in i915 perf for steam
config validation errors (i.e. userspace misconfigurations) that should
be changed so that i-g-t tests aren't treated as failures when
triggering these.
I initially proposed changing these to DRM_INFO messages and
intentionally
>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Thursday, December 1, 2016 5:24 AM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support
>
>Hi,
>
>On 30/11/2016 23:
== Series Details ==
Series: GEN-9 Arbitrated Bandwidth WM WA's & IPC (rev3)
URL : https://patchwork.freedesktop.org/series/15562/
State : success
== Summary ==
Series 15562v3 GEN-9 Arbitrated Bandwidth WM WA's & IPC
https://patchwork.freedesktop.org/api/1.0/series/15562/revisions/3/mbox/
fi
This patch Adds a function to extract intel_crtc_state from the
atomic_state, if not available it returns NULL.
Signed-off-by: Mahesh Kumar
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/int
This patch implemnets Workariunds related to display arbitrated memory
bandwidth. These WA are applicabe for all gen-9 based platforms.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Address review comments
- Rebase/rework as per other patch changes in series
Chan
Display Workarounds #1141
IPC (Isoch Priority Control) may cause underflows.
KBL WA: When IPC is enabled, watermark latency values must be increased
by 4us across all levels. This brings level 0 up to 6us.
Changes since V1:
- Add Workaround number in commit & code
Signed-off-by: Mahesh Kumar
R
Display Workarounds #1135
If IPC is enabled in BXT, display underruns are observed.
WA: The Line Time programmed in the WM_LINETIME register should be
half of the actual calculated Line Time.
Programmed Line Time = 1/2*Calculated Line Time
Changes since V1:
- Add Workaround number in commit & co
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.
Changes from v1:
- Address comments from Paulo
- implement decode function for SKL/KBL also
Changes from v2:
- Rewrite the code as per HW team
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep is disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controles the memory read priority of Display.
When IPC is enabled, plane read
This series implements following set of functionality
Implement IPC WA's for Broxton/KBL
Enable IPC in supported platforms
Convert WM calculation to fixed point calculation
Calculation of System memory Bandwidth for SKL/KBL/BXT
Implementation of Arbitrated me
This patch adds variable to check for X_tiled & y_tiled planes, instead
of always checking against framebuffer-modifiers.
Changes:
- Created separate patch as per Paulo's comment
- Added x_tiled variable as well
Changes since V2:
- Incorporate Paulo's comments
- Rebase
Signed-off-by: Mahesh K
This patch changes Watermak calculation to fixed point calculation.
Problem with current calculation is during plane_blocks_per_line
calculation we divide intermediate blocks with min_scanlines and
takes floor of the result because of integer operation.
hence we end-up assigning less blocks than re
On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
Once the i915 driver has successfully loaded, the panel can be disabled /
enabled without hitting this issue.
The getting stuck is caused by vlv_init_d
On Wed, Nov 16, Olaf Hering wrote:
> During boot into a current openSUSE Tumbleweed 20161108 this laptop
> starts to hang sometimes with 4.8.x. Today I was able to catch this
> crash in __wake_up_common caused by i915 or drm or whatever:
>
> ...
> [ 69.851635] BUG: unable to handle kernel NULL
Hi,
On 29-11-16 14:06, Hans de Goede wrote:
p.s.
I'm also trying to come up with some patches which properly
integrate pwm-lpss with the i915 driver instead of it
throwing a "Failed to own the pwm chip" error. But as soon
as I hook up things so that pwm_get() returns the pwm-lpss
pwm0 I hit:
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> Rather than accessing crtc->config in vlv_compute_wm_level() let's
> pass in the crtc state explicitly. One step closer to atomic.
>
> Signed-off-by: Ville Syrjälä
Yay. All users of intel_crtc->config have to di
== Series Details ==
Series: GEM object create and driver init dev_priv cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/16162/
State : warning
== Summary ==
Series 16162v2 GEM object create and driver init dev_priv cleanups
https://patchwork.freedesktop.org/api/1.0/series/16162/
Op 01-12-16 om 14:13 schreef Ville Syrjälä:
> On Thu, Dec 01, 2016 at 12:56:16PM +0100, Maarten Lankhorst wrote:
>> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
>>> From: Ville Syrjälä
>>>
>>> Each DSPARB register can house bits for two separate pipes, hence
>>> we must protect the
Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> On VLV/CHV some of the watermark values are split across two registers:
> low order bits in one, and high order bits in another. So we may not be
> able to update a single watermark value atomically, and thus we
From: Tvrtko Ursulin
dev_priv is more appropriate since it is used much more in these.
v2: Commit message and keep the local pdev variable. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++-
From: Tvrtko Ursulin
dev_priv is more appropriate for these so converting saves
some lines of source.
v2: Commit message and keep the pdev local variable. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i91
From: Tvrtko Ursulin
Function actually wants dev_priv so give it to it.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gp
From: Tvrtko Ursulin
Since it does not need dev at all.
Also change the stored pointer in struct i915_error_state_file_priv
to i915.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
drivers/gpu/drm/i
From: Tvrtko Ursulin
They are only used in i915_drv.c so a forward declaration is enough.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 5 -
drivers/gpu/drm/i915/i915_drv.h | 3 ---
2 files changed, 4 insertions
From: Tvrtko Ursulin
Like GEM init, GUC init, MOCS init and context creation.
Enables them to lose dev_priv locals.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c| 31 ++--
drivers/
From: Tvrtko Ursulin
Simplifies the code to pass the right parameter in.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 8
drivers/gpu/drm/i915/i915_drv.h
From: Tvrtko Ursulin
Simplify the code by passing the right argument in.
v2: Commit message. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
From: Tvrtko Ursulin
Makes all GEM object constructors consistent.
v2: Fix compilation in GVT code.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson (v1)
Reviewed-by: Joonas Lahtinen (v1)
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h
From: Tvrtko Ursulin
Where it is more appropriate and also to be consistent with
the direction of the driver.
v2: Leave out object alloc/free inlining. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
From: Tvrtko Ursulin
Autumn of churn continues. :)
This series tidies GEM object construction to take dev_priv instead of dev
in all cases and also does a bit of random tidy in the driver load/init code.
Basically functions which only need dev_priv are changed to take dev_priv
instead of dev. T
On Thu, Dec 01, 2016 at 03:31:45PM +0200, Mika Kuoppala wrote:
> Client will get banned from creating new context
> if it has managed to get > 3 context banned.
I'm not thrilled about baking that magic number into an ABI requirement.
Just make it N bans, test timing out after say 120s of happines
On Thu, Dec 01, 2016 at 03:31:44PM +0200, Mika Kuoppala wrote:
> If seqno is not incrementing but head is moving,
> we declare hang but much slower. Add test to check
> that this mechanism is working properly.
>
> Signed-off-by: Mika Kuoppala
> ---
> tests/gem_reset_stats.c | 75
> +
How about a patch 0 to enable hang testing contexts on all rings now?
Then exploration of how one ring affects another...
You will want to use busy batches to load the engines without hanging,
that will be tricky...
On Thu, Dec 01, 2016 at 03:31:43PM +0200, Mika Kuoppala wrote:
> Now that we repl
On ti, 2016-11-29 at 21:53 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/lspcon: Enable AUX interrupts for resume time initialization
> (rev2)
> URL : https://patchwork.freedesktop.org/series/16106/
> State : success
>
> == Summary ==
>
> Series 16106v2 drm/i915/lspcon:
Now that we replay the non guilty contexts and always replay
the default ctx, even when guilty, the assumptions of how many
active and pending batches there was in the time of reset has
changed.
Driver doesn't increment pending counts for contexts that it
considered unaffected by reset. Because it
Client will get banned from creating new context
if it has managed to get > 3 context banned.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 47 ++-
1 file changed, 42 insertions(+), 5 deletions(-)
diff --git a/tests/gem_reset_stats.c b/te
If seqno is not incrementing but head is moving,
we declare hang but much slower. Add test to check
that this mechanism is working properly.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 75 +
1 file changed, 75 insertions(+)
diff --g
Hi,
On 30/11/2016 23:31, Anusha Srivatsa wrote:
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
r
On Tue, Nov 29, 2016 at 09:40:29PM +0200, Imre Deak wrote:
> For LSPCON initialization during system resume we need AUX
> functionality, but we call the corresponding encoder reset hook with all
> interrupts disabled. Without interrupts we'll do a poll-wait for AUX
> transfer completions, which add
== Series Details ==
Series: drm/i915: introduce platform enum (rev2)
URL : https://patchwork.freedesktop.org/series/16170/
State : success
== Summary ==
Series 16170v2 drm/i915: introduce platform enum
https://patchwork.freedesktop.org/api/1.0/series/16170/revisions/2/mbox/
Test gem_exec_flu
On Thu, Dec 01, 2016 at 12:56:16PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 18:37 schreef ville.syrj...@linux.intel.com:
> > From: Ville Syrjälä
> >
> > Each DSPARB register can house bits for two separate pipes, hence
> > we must protect the registers during reprogramming so that parallel
On Tue, 2016-11-15 at 14:08 +0200, Jani Nikula wrote:
> Request the GPIO by index through the consumer API. For now, use a
> quick
> hack to store the already requested ones, simply because I have no
> idea
> whether this actually works or not, and I have no way to test it.
>
> Cc: Mika Kahola
>
On 30/11/2016 23:31, Anusha Srivatsa wrote:
This patch adds the HuC Loading for the BXT by using
the updated file construction.
Version 1.7 of the HuC firmware.
v2: rebased.
v3: rebased on top of drm-tip
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jeff McGee
---
drivers/gpu
On Wed, Nov 30, 2016 at 03:31:34PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You
On Wed, Nov 30, 2016 at 03:31:33PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: r
On Thu, Dec 01, 2016 at 12:45:18PM +, Tvrtko Ursulin wrote:
>
> On 01/12/2016 11:18, Chris Wilson wrote:
> >On Thu, Dec 01, 2016 at 10:45:51AM +, Tvrtko Ursulin wrote:
> >>
> >>On 14/11/2016 08:57, Chris Wilson wrote:
> >>>+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
> >>>
The platform flags in device info are (mostly) mutually
exclusive. Replace the flags with an enum. Add the platform enum also
for platforms that previously didn't have a flag, and give them codename
logging in dmesg.
Pineview remains an exception, the platform being G33 for that.
v2: Sort enum by
On 01/12/2016 11:18, Chris Wilson wrote:
On Thu, Dec 01, 2016 at 10:45:51AM +, Tvrtko Ursulin wrote:
On 14/11/2016 08:57, Chris Wilson wrote:
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
req
1 - 100 of 154 matches
Mail list logo
