On 24/02/17 06:33, Oscar Mateo wrote:
While trying to get up to speed with the GuC, the thing that bothers me the
most is that we have so many things called "context" in the driver, that when
I talk with someone about it we invariably end up sounding like The Smurfs
(update the context ID in th
== Series Details ==
Series: drm/i915/guc: Smurf the GuC context
URL : https://patchwork.freedesktop.org/series/20232/
State : success
== Summary ==
Series 20232v1 drm/i915/guc: Smurf the GuC context
https://patchwork.freedesktop.org/api/1.0/series/20232/revisions/1/mbox/
fi-bdw-5557u tot
When advancing onto the next 4th level page table entry, we need to
reset our indices to 0. Currently we restart from the original address
which means we start with an offset into the next PML table.
Fixes: 894ccebee2b0 ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()")
Reported-by: Matthew
While trying to get up to speed with the GuC, the thing that bothers me the
most is that we have so many things called "context" in the driver, that when
I talk with someone about it we invariably end up sounding like The Smurfs
(update the context ID in the GuC context so that the HW context gets
This vma contains much more than just the additional data struct (ads)
and since we were already using the word "addon" as an object in
guc_addon_create, make it the preffered one. No need for the vma suffix
either, as that dependency is given by the type.
while at it, add an explanation of what t
Starting with intel_guc_loader, down to intel_guc_submission
and finally to intel_guc_log.
v2:
- Null execbuf client outside guc_client_free (Daniele)
- Assert if things try to get allocated twice (Daniele/Joonas)
- Null guc->log.buf_addr when destroyed (Daniele)
- Newline between returnin
They have been discussed in various threads, but I am putting them together
as a series for clarity. These go on top of Joonas' "Sanitize GuC client
initialization", so they cannot be merged until that patch goes thru (at
that point, it is probably better if Joonas resends these as well).
Oscar Ma
The GuC descriptor is big in size. If we use a local definition of
guc_desc we have a chance to overflow stack, so avoid it.
Also, Chris abhors scatterlists :)
v2: Rebased, helper function to retrieve the context descriptor,
s/ctx_pool_vma/ctx_pool/
v3: Zero out guc_context_desc before initializ
When initializing the GuC log struct, there is an object we need to
allocate always, since the GuC needs its address at fw load time.
The rest are "extras", in the sense that we only need them if we
actually enable GuC logging. Make that distinction explicit by
subdividing further the intel_guc_log
== Series Details ==
Series: series starting with [1/2] drm/i915: Assert all sg are initialised in
fake_dma_object for selftests
URL : https://patchwork.freedesktop.org/series/20228/
State : success
== Summary ==
Series 20228v1 Series without cover letter
https://patchwork.freedesktop.org/api
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Capture dmc firmware
information before reset
URL : https://patchwork.freedesktop.org/series/20227/
State : success
== Summary ==
Series 20227v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20
We rely on the VMA being allocated inside the drm_mm and for its alloted
node being large enough to accommodate all the vma->pages.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_vma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_v
On Fri, Feb 24, 2017 at 06:03:09PM -0300, Paulo Zanoni wrote:
> Em Qua, 2017-02-08 às 15:12 +0200, Joonas Lahtinen escreveu:
> > "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> > We already have GENMASK for generating the mask, use it!
> >
> > v2: Majestic off by one spotted (
Em Qua, 2017-02-08 às 15:12 +0200, Joonas Lahtinen escreveu:
> "BIT(max) - 1" will overflow when max = 32, and GCC will complain.
> We already have GENMASK for generating the mask, use it!
>
> v2: Majestic off by one spotted (Chris)
>
> Signed-off-by: Joonas Lahtinen
> Cc: Chris Wilson
> ---
>
== Series Details ==
Series: drm/i915: Timeout lowlevel_hole GTT selftest early
URL : https://patchwork.freedesktop.org/series/20226/
State : warning
== Summary ==
Series 20226v1 drm/i915: Timeout lowlevel_hole GTT selftest early
https://patchwork.freedesktop.org/api/1.0/series/20226/revisions
Hi Kyle,
Please pull these fixed guc versions from my repo.
Thanks in advance,
Rodrigo.
The following changes since commit
432444c510eb29446af6e5f21e68aab06b9d6a22:
Revert "amdgpu: update VI gfx/sdma firmware" (2017-02-23 11:02:48
-0500)
are available in the git repository at:
git://peopl
For some reason these 2 files got corrupted
when propagating the release to this repository.
i915 firmware got first release at:
https://01.org/linuxgraphics/downloads/firmware
then propagated to linux-firmware.git.
The version on 01.org are the right ones.
This issue has been identified by Jaso
== Series Details ==
Series: drm/i915/bdw: Do not write the replay bit of the ring mode register
URL : https://patchwork.freedesktop.org/series/20221/
State : success
== Summary ==
Series 20221v1 drm/i915/bdw: Do not write the replay bit of the ring mode
register
https://patchwork.freedesktop
Before looking up the page directory entry, check we are still within
bounds.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i91
Double check that we allocated the right amount of scatterlist elements
for our obj->size.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/driver
On 24 February 2017 at 19:33, Chris Wilson wrote:
> Check for a timeout in the lowlevel_hole GTT before we allocate state
> for that pass, as our cleanup phase stops on the iteration before the
> timeout.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=99947
> Signed-off-by: Chris Wil
The firmware may change between the hang and cat /sys/class/drm/card0/error
v2: if version is 0, the fw was not loaded.
Cc: Chris Wilson
Reviewed-by: Michal Wajdeczko
Reviewed-by: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i
HuC depends on GuC, so be it.
v2: if version is 0, the fw was not loaded.
Suggested-by: Michal Wajdeczko
Reviewed-by: Michal Wajdeczko
Reviewed-by: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 9 +
There was no way to check if the platform is running the latest
firmware.
v2: use HAS_GUC and intel_guc* (Michal)
capture before reset (Chris)
v3: if version is 0, the fw was not loaded.
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Cc: Arkadiusz Hiler
Reviewed-by: Michal Wajde
== Series Details ==
Series: series starting with [1/3] drm/i915: Capture dmc firmware information
before reset
URL : https://patchwork.freedesktop.org/series/20220/
State : success
== Summary ==
Series 20220v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/20220
Reviewed-by: Daniele Ceraolo Spurio
On 24/02/17 11:15, Kelvin Gardiner wrote:
The replay bit of the ring mode register is not a valid bit for Gen8+. Do not
write to this bit.
Signed-off-by: Kelvin Gardiner
Cc: Joonas Lahtinen
Cc: Ceraolo Spurio, Daniele
---
drivers/gpu/drm/i915/intel_lrc.c
On 2/24/2017 11:34 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:25:29AM -0800, Michel Thierry wrote:
On 2/24/2017 11:22 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote:
The firmware may change between the hang and cat /sys/class/drm/card0/error
Cc:
On Fri, Feb 24, 2017 at 11:25:29AM -0800, Michel Thierry wrote:
> On 2/24/2017 11:22 AM, Chris Wilson wrote:
> >On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote:
> >>The firmware may change between the hang and cat /sys/class/drm/card0/error
> >>
> >>Cc: Chris Wilson
> >>Signed-off-b
Check for a timeout in the lowlevel_hole GTT before we allocate state
for that pass, as our cleanup phase stops on the iteration before the
timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i91
On Fri, Feb 24, 2017 at 11:05:30AM -0800, Michel Thierry wrote:
> HuC depends on GuC, so be it.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++
> 2 files changed,
On 2/24/2017 11:22 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote:
The firmware may change between the hang and cat /sys/class/drm/card0/error
Cc: Chris Wilson
Signed-off-by: Michel Thierry
Looks sane...
---
drivers/gpu/drm/i915/i915_drv.h |
On Fri, Feb 24, 2017 at 11:05:30AM -0800, Michel Thierry wrote:
> HuC depends on GuC, so be it.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++
> 2 files changed,
On Fri, Feb 24, 2017 at 11:05:29AM -0800, Michel Thierry wrote:
> There was no way to check if the platform is running the latest
> firmware.
>
> v2: use HAS_GUC and intel_guc* (Michal)
> capture before reset (Chris)
>
> Cc: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Tvrtko Ursulin
> Cc: Ar
On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote:
> The firmware may change between the hang and cat /sys/class/drm/card0/error
>
> Cc: Chris Wilson
> Signed-off-by: Michel Thierry
Looks sane...
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4
> drivers/gpu/drm/i915/i915
On Fri, Feb 24, 2017 at 03:52:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)
> URL : https://patchwork.freedesktop.org/series/19961/
> State : success
>
> == Summary ==
>
> Series 19961v2 drm/i915/gen9: Increase PCO
The replay bit of the ring mode register is not a valid bit for Gen8+. Do not
write to this bit.
Signed-off-by: Kelvin Gardiner
Cc: Joonas Lahtinen
Cc: Ceraolo Spurio, Daniele
---
drivers/gpu/drm/i915/intel_lrc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc
On Fri, Feb 24, 2017 at 11:05:28AM -0800, Michel Thierry wrote:
> The firmware may change between the hang and cat /sys/class/drm/card0/error
>
> Cc: Chris Wilson
> Signed-off-by: Michel Thierry
> ---
Reviewed-by: Michal Wajdeczko
-Michal
___
Intel-
There was no way to check if the platform is running the latest
firmware.
v2: use HAS_GUC and intel_guc* (Michal)
capture before reset (Chris)
Cc: Chris Wilson
Cc: Michal Wajdeczko
Cc: Tvrtko Ursulin
Cc: Arkadiusz Hiler
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h
The firmware may change between the hang and cat /sys/class/drm/card0/error
Cc: Chris Wilson
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gpu_error.c | 22 --
2 files changed, 20 insertions(+), 6 deletions(-)
d
HuC depends on GuC, so be it.
Suggested-by: Michal Wajdeczko
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm
== Series Details ==
Series: series starting with [v3,1/5] drm/i915: Report both waiters and success
from intel_engine_wakeup()
URL : https://patchwork.freedesktop.org/series/20218/
State : warning
== Summary ==
Series 20218v1 Series without cover letter
https://patchwork.freedesktop.org/api/
On Fri, Feb 24, 2017 at 04:40:04PM +0100, Arkadiusz Hiler wrote:
> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>
> Using the parameter disabled version checks and loads desired firmware
> instead of the default one.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: M
On Fri, Feb 24, 2017 at 04:40:03PM +0100, Arkadiusz Hiler wrote:
> intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> preparation (fetch + initial parsing).
>
> This change separates out select steps, so those can be called by
> the sanitize_options().
>
> Then, during the in
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in th
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt du
Now the only use of the return value is ask whether or not we actually
woke a process up. With a single condition to report, we can go back to
using a boolean.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 13 +
driv
On Wed, Feb 15, 2017 at 01:34:46AM -0800, Kenneth Graunke wrote:
> This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
> (indicating the optional feature is not supported), and makes execbuf
> always return -EINVAL if the flags are used.
>
> Apparently, no userspace ever shipped w
On Fri, Feb 24, 2017 at 04:40:02PM +0100, Arkadiusz Hiler wrote:
> Currently fw->path values can represent one of three possible states:
>
> 1) NULL - device without the uC
> 2) '\0' - device with the uC but have no firmware
> 3) else - device with the uC and we have firmware
>
> Second case i
On 2/24/2017 9:15 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 08:30:43AM -0800, Michel Thierry wrote:
On 2/24/2017 2:49 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote:
On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote:
On Fri, Feb 24,
On Fri, Feb 24, 2017 at 04:40:01PM +0100, Arkadiusz Hiler wrote:
> Current version of intel_guc_init_hw() does a lot:
> - cares about submission
> - loads huc
> - implement WA
>
> This change offloads some of the logic to intel_uc_init_hw(), which now
> cares about the above.
>
> v2: rename gu
On Fri, Feb 24, 2017 at 08:30:43AM -0800, Michel Thierry wrote:
> On 2/24/2017 2:49 AM, Chris Wilson wrote:
> >On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote:
> >>On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote:
> >>>On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, S
On Mon, 20 Feb 2017 15:08:45 +0100
Hans de Goede wrote:
> 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 +++
On Mon, 20 Feb 2017 15:08:44 +0100
Hans de Goede wrote:
> 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
> --
On Mon, 20 Feb 2017 15:08:43 +0100
Hans de Goede wrote:
> For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
> MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
Isn't this only for command mode? Or is there conflicting information
on this?
>
> Signed-off-by: Hans de Goede
> ---
> driver
On Mon, 20 Feb 2017 15:08:42 +0100
Hans de Goede wrote:
> 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 commen
On Mon, 20 Feb 2017 15:08:38 +0100
Hans de Goede wrote:
> 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
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 10 --
> 1 fil
On Mon, 20 Feb 2017 15:08:35 +0100
Hans de Goede wrote:
> 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
> Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 68
> +++
On Mon, 20 Feb 2017 15:08:37 +0100
Hans de Goede wrote:
> 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_DEA
On Mon, 20 Feb 2017 15:08:40 +0100
Hans de Goede wrote:
> 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 |
On Mon, 20 Feb 2017 15:08:39 +0100
Hans de Goede wrote:
> 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 in
On Mon, 20 Feb 2017 15:08:41 +0100
Hans de Goede wrote:
> 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
I'm not sure that the added comments are necessary. Ma
On Mon, 20 Feb 2017 15:08:36 +0100
Hans de Goede wrote:
> 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/disab
On Mon, 20 Feb 2017 15:08:34 +0100
Hans de Goede wrote:
> 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 midd
On Mon, 20 Feb 2017 15:08:32 +0100
Hans de Goede wrote:
> 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 functional changes.
>
> The main advantage of this cha
On Mon, 20 Feb 2017 15:08:33 +0100
Hans de Goede wrote:
> The enable path has an intel_dsi_prepare() helper which prepares various
> registers for the mode-set. Move the code undoing this to a new
> intel_dsi_unprepare() helper function for better symmetry between the
> enable and disable paths.
On Mon, 20 Feb 2017 15:08:31 +0100
Hans de Goede wrote:
> 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
On Fri, Feb 24, 2017 at 04:40:00PM +0100, Arkadiusz Hiler wrote:
> Let intel_guc_init_fw() focus on determining and fetching the correct
> firmware.
>
> This patch introduces intel_uc_sanitize_options() that is called from
> intel_sanitize_options().
>
> Then, if we have GuC, we can call intel_gu
On Fri, Feb 24, 2017 at 04:39:59PM +0100, Arkadiusz Hiler wrote:
> Instead of calling intel_guc_init() and intel_huc_init() one by one this
> patch introduces intel_uc_init_fw() function that calls them both.
>
> Called functions are renamed accordingly.
>
> Trying to have subject_verb_object ord
On 2/24/2017 2:49 AM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote:
On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote:
Reviewed-by: Sagar Arun Kamble [1]
On 2/24/2017 4:41
On Fri, Feb 24, 2017 at 04:39:58PM +0100, Arkadiusz Hiler wrote:
> The file fits better.
>
> Additionally rename it to intel_uc_prepare_fw(), as the function does
> more than simple fetch.
Hmm, new function does not contain "fetch" verb and "prepare" alone is
not much meaningful
>
> Signed-off
On 2/24/2017 8:15 AM, Michel Thierry wrote:
On 2/24/2017 2:40 AM, Michal Wajdeczko wrote:
On Thu, Feb 23, 2017 at 03:11:37PM -0800, Michel Thierry wrote:
There was no way to check if the platform is running the latest
firmware.
Can we also add similar patch for the HuC ?
Please don't tel
On 2/24/2017 2:40 AM, Michal Wajdeczko wrote:
On Thu, Feb 23, 2017 at 03:11:37PM -0800, Michel Thierry wrote:
There was no way to check if the platform is running the latest firmware.
Can we also add similar patch for the HuC ?
Please don't tell me the HuC can hang the gpu too.
Cc: Tvr
== Series Details ==
Series: GuC Scrub vol. 1 (rev5)
URL : https://patchwork.freedesktop.org/series/16856/
State : failure
== Summary ==
CC [M] drivers/gpu/drm/i915/gvt/gtt.o
LD drivers/thermal/thermal_sys.o
CC [M] drivers/gpu/drm/i915/gvt/cfg_space.o
LD kernel/sched/built-
== Series Details ==
Series: drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2)
URL : https://patchwork.freedesktop.org/series/19961/
State : success
== Summary ==
Series 19961v2 drm/i915/gen9: Increase PCODE request timeout to 100ms
https://patchwork.freedesktop.org/api/1.0/series/
On 2/24/2017 4:19 PM, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 11:43:32AM +0100, Michal Wajdeczko wrote:
On Fri, Feb 24, 2017 at 09:13:29AM +, Chris Wilson wrote:
On Fri, Feb 24, 2017 at 09:13:05AM +0530, Kamble, Sagar A wrote:
Reviewed-by: Sagar Arun Kamble [1]
On 2/24/2017
intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
preparation (fetch + initial parsing).
This change separates out select steps, so those can be called by
the sanitize_options().
Then, during the init_fw() we prepare the firmware if the firmware was
selected.
Cc: Michal Winia
`guc_firmware_path` and `huc_firmware_path` module parameters are added.
Using the parameter disabled version checks and loads desired firmware
instead of the default one.
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/i915_p
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_init_hw(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
v4: rem
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later stage.
We can WARN right away and merge cases 1
Instead of calling intel_guc_init() and intel_huc_init() one by one this
patch introduces intel_uc_init_fw() function that calls them both.
Called functions are renamed accordingly.
Trying to have subject_verb_object ordering and more descriptive names,
the intel_huc_init() and intel_guc_init() f
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
Signed-off-by: Arkadiusz Hiler
---
drivers/gpu/drm/i915/intel_guc_loader.c | 137 +---
drivers/gpu/drm/i915/intel_huc.c| 2 +-
drivers/gpu/dr
Used to obtain "dev_priv" from huc struct pointer.
We already have similar thing for guc.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv
Externs are implicit and we generally try to avoid them.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drive
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_intel_fw() conditionally and
we do not have to do the internal checks.
v2: f
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
This commit renames intel_guc_setup() and intel_huc_load() to
*uc_init_hw() as they called from the i915_gem_init_hw().
The aim is to be consistent in that entry points called du
General GuC/HuC cleanup simplifying logic, and moving chunks around as the area
got pretty rusty.
A lot of logic were extracted from intel_guc_load() to other functions - it did
not only handle the actual loading but had WA implementations and the code
that enabled submission baked into it.
This
On Fri, Feb 24, 2017 at 04:18:45PM +0200, Ander Conselvan de Oliveira wrote:
> Don't allow conversion from arbitraty encoder types to a digital port.
> Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
> but certain paths of the ddi code may be called with hasell's analog
> enc
== Series Details ==
Series: Fix Geminilake DDI power well enable timeouts (rev6)
URL : https://patchwork.freedesktop.org/series/19451/
State : success
== Summary ==
Series 19451v6 Fix Geminilake DDI power well enable timeouts
https://patchwork.freedesktop.org/api/1.0/series/19451/revisions/6/
After
commit 2c7d0602c815277f7cb7c932b091288710d8aba7
Author: Imre Deak
Date: Mon Dec 5 18:27:37 2016 +0200
drm/i915/gen9: Fix PCODE polling during CDCLK change notification
there is still one report of the CDCLK-change request timing out on a
KBL machine, see the Reference link. On that m
On Fri, Feb 24, 2017 at 02:53:07PM +0100, Michał Winiarski wrote:
> On Thu, Feb 23, 2017 at 04:18:27PM +, Chris Wilson wrote:
> > This simply hides the EAGAIN caused by userptr when userspace causes
> > resource contention. However, it is quite beneficial with highly
> > contended userptr users
According to bspec, the DDI IO power domains should be enabled after
enabling the DPLL and mapping it to the DDI. The current order doesn't
seem to create problems with Skylake and Kabylake, but causes enable
timeouts in Geminilake.
v2: Rebase.
- Take power domain references before sanitizing en
Don't allow conversion from arbitraty encoder types to a digital port.
Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
but certain paths of the ddi code may be called with hasell's analog
encoder and the conversion is wrong for DP mst encoders too, so safe
guard against it.
Don't allow conversion from arbitraty encoder types to a digital port.
Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
but certain paths of the ddi code may be called with hasell's analog
encoder and the conversion is wrong for DP mst encoders too, so safe
guard against it.
On Wed, Feb 22, 2017 at 05:52:19PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/lspcon: Switch back to PCON mode after output replug (rev2)
> URL : https://patchwork.freedesktop.org/series/20072/
> State : success
I pushed the patch to -dinq, thanks for the report/testing
On Thu, Feb 23, 2017 at 04:18:27PM +, Chris Wilson wrote:
> This simply hides the EAGAIN caused by userptr when userspace causes
> resource contention. However, it is quite beneficial with highly
> contended userptr users as we avoid repeating the setup costs and
> kernel-user context switches.
== Series Details ==
Series: drm/915/glk: Enable pooled EUs for Geminilake
URL : https://patchwork.freedesktop.org/series/20212/
State : success
== Summary ==
Series 20212v1 drm/915/glk: Enable pooled EUs for Geminilake
https://patchwork.freedesktop.org/api/1.0/series/20212/revisions/1/mbox/
On Wed, Feb 22, 2017 at 08:34:31AM +0200, Ander Conselvan de Oliveira wrote:
> According to bspec, the DDI IO power domains should be enabled after
> enabling the DPLL and mapping it to the DDI. The current order doesn't
> seem to create problems with Skylake and Kabylake, but causes enable
> timeo
On Wed, Feb 22, 2017 at 08:34:28AM +0200, Ander Conselvan de Oliveira wrote:
> Don't allow conversion from arbitraty encoder types to a digital port.
> Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
> but certain paths of the ddi code may be called with hasell's analog
> enc
1 - 100 of 151 matches
Mail list logo
