In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
reads. Due to the nature of the registers we try to read in this manner,
they may increment between the two instruction (e.g. a timestamp
counter). To keep the result accurate, we repeat the read if we detect
an overflow (i.e. th
Just for the record: I still get these quite often on resuming from
suspend-to-ram. But I can't reliably provoke them for some reason, so
the exact trigger mechanism is unknown. Related to timing issues caused
by other devices, maybe? Or some odd Lenovo firmware thingy?
Does of course not matte
On Tue, Sep 08, 2015 at 08:24:19AM +0100, Chris Wilson wrote:
> In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
> reads. Due to the nature of the registers we try to read in this manner,
> they may increment between the two instruction (e.g. a timestamp
> counter). To keep the
On 02/09/15 23:52, yu@intel.com wrote:
From: Alex Dai
Bit 16 of GuC status indicates resuming from RC6. The LAPIC_DONE
status is a reliable readiness flag only when resuming from RC6.
This fix a racing issue that allocation of doorbell fails whilst
GuC init is not finished.
Signed-off-by:
On Tue, Sep 08, 2015 at 06:48:34AM +0200, Maarten Lankhorst wrote:
> Op 08-09-15 om 01:42 schreef Stephen Rothwell:
> > Hi all,
> >
> > On Thu, 3 Sep 2015 10:49:19 +1000 Stephen Rothwell
> > wrote:
> >> After merging the drm-misc tree, today's linux-next build (arm
> >> multi_v7_defconfig) failed
Op 08-09-15 om 09:31 schreef Bjørn Mork:
> Just for the record: I still get these quite often on resuming from
> suspend-to-ram. But I can't reliably provoke them for some reason, so
> the exact trigger mechanism is unknown. Related to timing issues caused
> by other devices, maybe? Or some odd
Maarten Lankhorst writes:
> Op 08-09-15 om 09:31 schreef Bjørn Mork:
>> Just for the record: I still get these quite often on resuming from
>> suspend-to-ram. But I can't reliably provoke them for some reason, so
>> the exact trigger mechanism is unknown. Related to timing issues caused
>> by o
On Tue, Sep 08, 2015 at 08:51:50AM +0100, Chris Wilson wrote:
> On Tue, Sep 08, 2015 at 08:24:19AM +0100, Chris Wilson wrote:
> > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
> > reads. Due to the nature of the registers we try to read in this manner,
> > they may increment
From: Robert Beckett
WaDisableSTUnitPowerOptimization:skl,bxt
Signed-off-by: Robert Beckett
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i9
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 84ed9ab..2c719b0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
As per spec this is applicable to 3x6 SKUs only, add condition to
check the same.
Cc: Nick Hoath
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i9
Apply in common gen9_init_clock_gating() fn and add revid check for bxt.
Cc: Nick Hoath
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_pm.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d2e0b3b..0e1ed0b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/
From: Nick Hoath
Signed-off-by: Nick Hoath
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 5eafd31..e0601cc 100644
--- a/
With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.
Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set
This is applicable to SKL GT3 and GT4.
Can you add that check as well?
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Arun Siluvery
Sent: Tuesday, September 8, 2015 3:02 PM
To: intel-gfx@lists.freedesktop.org
Cc: Kuoppala, Mika
Subject: [
Ignore the comment. I thought about CPG.
Sorry.
-Original Message-
From: Kamble, Sagar A
Sent: Tuesday, September 8, 2015 3:44 PM
To: 'Arun Siluvery' ;
intel-gfx@lists.freedesktop.org
Cc: Kuoppala, Mika
Subject: RE: [Intel-gfx] [PATCH 6/6] drm/i915/gen9: Add
WaDisableMinuteIaClockGatin
Disable -Wcast-qual temporarily to allow memchr_inv to return non-const
data (similar to memchr), without causing a compiler warning.
Cc: Ville Syrjälä
Signed-off-by: Thomas Wood
---
tests/gem_pwrite_snooped.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/gem_pwrite_snooped.c b/t
From: Ville Syrjälä
Maarten pointed out that we still look at the non-crtc_ timings from
adjusted_mode in many places. While that is only strictly required with
HDMI due to stereo doubling I think it's better to be consistent about
it and always use the crtc_ timings. So this series aims to do ju
From: Ville Syrjälä
Make adjusted_mode const whereever we don't have to modify it. This only
covers cases when we have a local adjusted_mode variable, and doesn't
make any difference for cases where we just dereference
pipe_config->adjusted_mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
From: Ville Syrjälä
Always name any variable pointing at the adjusted mode as
'adjustead_mode'. This will make it much easier to identify
when we should use the crtc_ timings and when we shoudln't.
Conversion was performed with coccinelle:
@@
expression E;
identifier I;
@@
- struct drm_display_m
From: Ville Syrjälä
The adjustead_mode crtc_ timings are what we will program into the hardware,
so it's those timings we should be looking practically everywhere.
The normal and crtc_ timings should differ only when stere doubling is
used. In that case the normal timings are the orignal non-dou
From: Ville Syrjälä
Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel
stuff. Now all connectors that have a fixed mode use intel_panel.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dvo.c | 49 ++--
1 file changed, 22 inserti
From: Ville Syrjälä
We shouldn't frob adjusted_mode after .compute_config(), so move the
infoframe aspect ratio setup to .compute_config() from
intel_hdmi_set_avi_infoframe().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 dele
From: Ville Syrjälä
Handle the HDMI aspect ratio propert the same way in the SDVO code
as we handle it in the HDMI code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 9 -
drivers/gpu/drm/i915/intel_modes.c | 9 ++
From: Ville Syrjälä
Rename the function argument to 'adjusted_mode' whenever the function
only ever gets passed the adjusted_mode.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_audio.c | 17 +
drivers/gpu/drm/i915/inte
From: Ville Syrjälä
Handle the HDMI aspect ratio property the same way in the SDVO code
as we handle it in the HDMI code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 9 -
drivers/gpu/drm/i915/intel_modes.c | 9 +
On Tue, Sep 08, 2015 at 01:40:50PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Handle the HDMI aspect ratio propert the same way in the SDVO code
> as we handle it in the HDMI code.
>
> Signed-off-by: Ville Syrjälä
Please, ignore this one. I corrected the typos in the
On Thu, 2015-08-06 at 22:08 +0530, Shashank Sharma wrote:
> This patch set adds Color Manager implementation in DRM layer. Color
> Manager is
> an extension in DRM framework to support color
> correction/enhancement. Various
> Hardware platforms can support several color correction capabilities.
>
On 4 September 2015 at 19:22, Micah Fedke wrote:
> This patchset removes the code that looks up a pipe number from a crtc ID.
> The
> pipe number is equivalent to the index of the crtc in the array of crtcs
> returned by the kernel for a drmModeGetResources() call. This may not have
> been the
On 4 September 2015 at 19:22, Micah Fedke wrote:
> the crtc id is now always equivalent to its index in the array of crtcs
> returned by the kernel
>
> ---
> overlay/Makefile.am | 4 ++--
> overlay/kms/kms-overlay.c | 7 ++-
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --
Hey Rob,
My comments inline.
Regards
Shashank
On 9/8/2015 4:19 PM, Rob Bradford wrote:
On Thu, 2015-08-06 at 22:08 +0530, Shashank Sharma wrote:
This patch set adds Color Manager implementation in DRM layer. Color
Manager is
an extension in DRM framework to support color
correction/enhancement.
On Tue, Sep 08, 2015 at 12:02:07PM +0200, Daniel Vetter wrote:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers already add all planes on a crtc whe
Hi Daniel,
Thank you for the patch.
On Tuesday 08 September 2015 12:02:07 Daniel Vetter wrote:
> With drivers supporting runtime pm it's generally not a good idea to
> touch the hardware when it's off. Add an option to the commit_planes
> helper to support this case.
>
> Note that the helpers al
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, September 2, 2015 16:03
> To: Daniluk, Lukasz
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice
> and
> EU count for BDW
>
> On
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status us up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors
On 9/8/2015 10:12 AM, Jindal, Sonika wrote:
On 9/7/2015 9:56 PM, Daniel Vetter wrote:
On Mon, Sep 07, 2015 at 10:34:34AM +0530, Sonika Jindal wrote:
If the same port is enumerated as hdmi as well as DP, this will call
hot_plug hook for DP as well which is not required here.
This splitting o
On Tue, Sep 08, 2015 at 01:10:58PM +0200, Thierry Reding wrote:
> On Tue, Sep 08, 2015 at 12:02:07PM +0200, Daniel Vetter wrote:
> > With drivers supporting runtime pm it's generally not a good idea to
> > touch the hardware when it's off. Add an option to the commit_planes
> > helper to support th
Makes it really hard to reason about these since there are dependency
loops. Also if you touch them and don't know what you're doing you get
to keep all the pieces.
v2: Move marking debug module options as _unsafe into a separate patch,
as requested by Jani.
Cc: Jani Nikula
Signed-off-by: Daniel
Hi all,
Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODESET (i.e. modern
drivers) since all of them have their own locking. Besides that a few random
things that kind where in the same area/files.
Of course kerneldoc is updated too.
Feedback highly welcome.
Cheers, Daniel
Daniel
From: Tvrtko Ursulin
Comment disagrees with the code which has changed a lot since
it was documented.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index
We already express the drm/agp depencies correctly in Kconfig, so we
can rip this remnant from the shared drm core days.
Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
if ttm would provide dummy functions. I'm not going to volunteer for
that though.
v2: Use IS_ENABLED(CONFIG
And use it in radeon to replace all the ioctls no longer valid in kms
mode. I plan to also use this later on when nuking the ums support for
i915.
Note that setting the function pointer in the ioctl table to NULL
would amount to the same, but that results in some debug output from
the drm_ioctl()
We don't want random people to touch these.
Especially true since we've just screwed up SKL by holding it way too
long under the preliminary flag because of some ABI issues. And now
there's howtos all over the internets about how to set this. Same
pretty much for anything else.
Cc: Jani Nikula
S
With kms all the data getparam looks at is actually invariant, and
certainly not protected by the global kms mutex. With ums all the
setup code is already racy as hell, so this won't make things any
worse.
I've done this change so that all ioctl still used by kms drivers
are marked as DRM_UNLOCKED
This was only used for the ums+gem combo, so ripe for removal now that
we only have kms code left.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 31 +--
1 file changed, 1 insertion(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
drm core enforces now for DRIVER_MODESET that all ioctls are unlocked.
And all the old nasty ones from drm core aren't allowed for modern
drivers any more. Hence this is no longer needed.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8
1 file changed, 8 deletio
With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare th
As usual pull it into the drm docbook template, too. And again as
usual I've decided to only document stuff exported to drivers, so all
the old leftover markup from the shared drm repo days lost the magic
** signature.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 1 +
drive
They're only used in the drm ioctl table, and there they're excluded
when AGP support is disabled. So this is just dead code ripe for
removal.
Signed-off-by: Daniel Vetter
---
include/drm/drm_agpsupport.h | 48
1 file changed, 48 deletions(-)
diff --
Just one special case (since i915 lost its ums code, yay):
- radeon: Has slots for the old ums ioctls which don't have
DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
everywhere.
Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
they should.
v2: admgpu h
Hi,
There's been some discussion on improving our link training code, with
one of the ideas being a complete rewrite of the state machine. However,
a concern was raised over the risk of regressions. The code we have has
seen a lot of real world testing, and it would take a long time for any
new co
Split the register write with the new link training pattern out of
intel_dp_set_link_train(), so that the i915 specific code is in a
separate function.
---
drivers/gpu/drm/i915/intel_dp.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
Separate the bit that writes to DP register in its own function and move
the update of the train_set based on the adjust request to the sink out.
The objective is to split the generic link training logic from the i915
specific part.
---
drivers/gpu/drm/i915/intel_dp.c | 21 ++---
1
Instead of calling intel_dp_set_signal_levels(), which writes the
desired signal levels mask to a variable, just call the new function
intel_dp_update_signal_levels(). The effect should be the same, except
for an extra register write, but this creates a better split between the
generic link trainin
The link training functions had confusing names. The start function
actually does the clock recovery phase of the link training, and the
complete function does the channel equalization. So call them that
instead. Also, every call to intel_dp_start_link_train() was followed
by a call to intel_dp_com
This adds a test that compiles the link training code from i915 into a
separate executable and uses it to train a fake sink device. The test
also uses device information from i915 to exercise the different code
paths for different hardwdare generations.
In order to get the code to compile a lot of
So link training tests can use real hardware limits.
---
drivers/gpu/drm/i915/intel_dp.c | 99 ---
drivers/gpu/drm/i915/intel_dp_link_training.c | 92 +
drivers/gpu/drm/i915/intel_drv.h | 11 +--
3 files changed, 99 inserti
No functional changes, just moving code around.
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_dp.c | 328 +
drivers/gpu/drm/i915/intel_dp_link_training.c | 336 ++
drivers/gpu/drm/i915/intel_drv.h
It just makes the code more confusing, so just reference intel_dp_>DP
directly. The old behavior is preserved by saving the previous value of
DP in the stack and restoring the old value in case of failure.
--
I'm not sure the old behavior is correct, but to err in the side of
caution I tried not
Put all device information related stuff in separate files to that it is
easy to pull them for the link training tests in i-g-t.
---
drivers/gpu/drm/i915/i915_drv.c | 395 +-
drivers/gpu/drm/i915/i915_drv.h | 286 +-
drivers/gpu/drm/i
On Tue, 08 Sep 2015, Daniel Kasak wrote:
> Hi all. I've got an Intel(R) Iris(TM) Pro Graphics 5200 ( in a Macbook ),
> and I'm running a 4.1.5-rt5 kernel, libdrm-2.4.64 and mesa-11.0.0_rc1. I
> use Enlightenment ( from git ), and on this particular system only, I get a
> couple of graphics-only fr
On 9/3/2015 5:13 PM, daniele.ceraolospu...@intel.com wrote:
From: Daniele Ceraolo Spurio
2 subparts of gem_bad_reloc check that the reloc address is below the
global gtt boundary. However, when executing from ppgtt the reloc
address can be greater than that and still be a valid address.
To be
On Tue, 08 Sep 2015, Chris Wilson wrote:
> In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
> reads. Due to the nature of the registers we try to read in this manner,
> they may increment between the two instruction (e.g. a timestamp
> counter). To keep the result accurate, we
> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Wednesday, September 2, 2015 17:08
> To: Daniluk, Lukasz; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subslice
> and
> EU count for BDW
>
> On
Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König
.
That should be everything touching radeon/amdgpu if I missed something
leave me a note.
Regards,
Christian.
On 08.09.2015 13:56, Daniel Vetter wrote:
Hi all,
Big thing for sure is deprecating DRM_UNLOCKED for DRIVER_MODESET
On Tue, Sep 08, 2015 at 03:27:58PM +0300, Ander Conselvan de Oliveira wrote:
> So link training tests can use real hardware limits.
These need to be kept in sync with the _signal_levels() functions, so
moving them to a separate file is a bit questionable.
I suggest that we should attempt to restr
On Tue, Sep 08, 2015 at 03:36:32PM +0300, Jani Nikula wrote:
> On Tue, 08 Sep 2015, Chris Wilson wrote:
> > In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
> > reads. Due to the nature of the registers we try to read in this manner,
> > they may increment between the two inst
On Tue, Sep 08, 2015 at 03:28:00PM +0300, Ander Conselvan de Oliveira wrote:
> This adds a test that compiles the link training code from i915 into a
> separate executable and uses it to train a fake sink device. The test
> also uses device information from i915 to exercise the different code
> pat
In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
reads. Due to the nature of the registers we try to read in this manner,
they may increment between the two instruction (e.g. a timestamp
counter). To keep the result accurate, we repeat the read if we detect
an overflow (i.e. th
Requested by Laurent.
Note that this uses the new markdown support which will only land in
kernel 4.4 (for the code snippet).
v2: A few spelling fixes I spotted myself.
v3: Big reword for commit_planes() kerneldoc based on a text from
Laurent.
Cc: Laurent Pinchart
Reviewed-by: Thierry Reding
On Tue, 2015-09-08 at 16:11 +0300, Ville Syrjälä wrote:
> On Tue, Sep 08, 2015 at 03:28:00PM +0300, Ander Conselvan de Oliveira wrote:
> > This adds a test that compiles the link training code from i915 into a
> > separate executable and uses it to train a fake sink device. The test
> > also uses d
From: Ville Syrjälä
The docs are unclear as usual, so it's not clear whether LRC should be
bypassed, performed normally or GRC code should be used as the LRC code.
Some old docs stated that LRC bypass ought to be used, more recent ones
no longer say that. Some docs indicated that we could use GRC
From: Ville Syrjälä
The BIOS can leave the CHV display PHY in some odd state where
some of the LDOs/lanes won't power down fully when unused. This
will trigger a host of asserts that were added in:
30142273a3e83936fd7b45aa5339311a9295ca51 drm/i915: Add CHV PHY LDO power sanity
checks
6669e39f95b
On 08/09/2015 13:53, Daniluk, Lukasz wrote:
-Original Message-
From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
Sent: Wednesday, September 2, 2015 17:08
To: Daniluk, Lukasz; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Check for slice, subsli
What's the difference if double-buffered with armed attribute?
William
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Sunday, September 06, 2015 7:50 PM
To: Wang, Zhi A
Cc: Xie, William; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Water m
Hi,
Using Linux 4.2 on a new Skylake laptop, I frequently see the internal
display go momentarily black, with a coinciding message in the logs:
[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun
Testing linus master, the problem is gone. Does anyone know what
commit might
Toralf Förster gmx.de> writes:
>
> On 09/02/2015 10:31 PM, Konduru, Chandra wrote:
> > It is due to ips_enabled mismatch in crtc_state.
> > I can't think how below patch is triggering mismatch in ips_enabled.
>
> tested it 2 times in a row, the bad commits fails, the commit before works
fine.
>
BACKGROUND
Under Intel GVT-g environment, HW interrupts are shared among different VMs.
Because of the sharing, to enable or disable a HW interrupt becomes a bit
complicated. Considered that a virtual machine may request to disable a
interrupt which may be using by other virtual machines. The GEN
We mark ppgtt dirty when vm area grows. As one needs
to allocate atleast one batchbuffer object before running
anything in vm space, this was considered adequate. However in
init, we run batch which doesn't need to allocate anything. This
is the render state initialization batch, part of context in
On 9/8/2015 5:20 PM, Mika Kuoppala wrote:
We mark ppgtt dirty when vm area grows. As one needs
to allocate atleast one batchbuffer object before running
anything in vm space, this was considered adequate. However in
init, we run batch which doesn't need to allocate anything. This
is the render st
A gcc extension allows void pointer arithmetic by treating the size of
void as 1, but this generates a warning when -Wpointer-arith is used.
Signed-off-by: Thomas Wood
---
tools/aubdump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/aubdump.c b/tools/aubdump.c
in
The data is not modified by the function and is often declared const.
Signed-off-by: Thomas Wood
---
tools/null_state_gen/intel_batchbuffer.c | 6 +++---
tools/null_state_gen/intel_batchbuffer.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/null_state_gen/intel_bat
From: Ville Syrjälä
If one disables DDR DVFS in the BIOS, Punit will apparently ignores
all DDR DVFS request. Currently we assume that DDR DVFS is always
operational, which leads to errors in dmesg when the DDR DVFS requests
time out.
Fix the problem by gently prodding Punit during driver load t
On Thu, Aug 27, 2015 at 05:23:30PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
> supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
> when we continue to poll for the completion of t
Hi Daniel,
2015-09-08 Daniel Vetter :
> With the prep patches for i915 all kms drivers either have
> DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
> with an invariant return value when in modeset mode. But that's only
> the case for i915 and radeon. The drm core ioctls ar
Hi Daniel,
2015-09-08 Daniel Vetter :
> Just one special case (since i915 lost its ums code, yay):
> - radeon: Has slots for the old ums ioctls which don't have
> DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
> everywhere.
>
> Every other kms driver just has DRM_UNLOCKED
On Tue, Sep 08, 2015 at 02:17:13PM +0100, Chris Wilson wrote:
> In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit
> reads. Due to the nature of the registers we try to read in this manner,
> they may increment between the two instruction (e.g. a timestamp
> counter). To keep the
On Tue, Sep 08, 2015 at 09:05:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> If one disables DDR DVFS in the BIOS, Punit will apparently ignores
> all DDR DVFS request. Currently we assume that DDR DVFS is always
> operational, which leads to errors in dmesg when the D
On Tue, Sep 08, 2015 at 04:03:02PM +, Wang, Zhi A wrote:
> BACKGROUND
>
> Under Intel GVT-g environment, HW interrupts are shared among different VMs.
>
> Because of the sharing, to enable or disable a HW interrupt becomes a bit
> complicated. Considered that a virtual machine may request to
On 09/08/2015 11:05 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
If one disables DDR DVFS in the BIOS, Punit will apparently ignores
all DDR DVFS request. Currently we assume that DDR DVFS is always
operational, which leads to errors in dmesg when the DDR DVFS requests
time out.
On 09/07/2015 09:35 AM, Daniel Vetter wrote:
> On Sat, Sep 05, 2015 at 01:12:50AM +0530, Vandana Kannan wrote:
>> This patch includes enabling render decompression after checking all the
>> requirements (format, tiling, rotation etc.). Along with this, the WAs
>> mentioned in BSpec Workaround page
On Mon, Aug 24, 2015 at 02:42:50PM +0200, Patrik Jakobsson wrote:
> First batch of drm / kms ioctls.
Several comments in addition to issues similar to 4/5 patch.
> +static int drm_mode_rm_fb(struct tcb *tcp, const unsigned int code, long arg)
> +{
> + unsigned int handle;
> +
> +
> + if (
> > > > + if (fb->pixel_format == DRM_FORMAT_NV12) {
> > > > + int height_in_mem =
> > > > (fb->offsets[1]/fb->pitches[0]);
> > > > + /*
> > > > +* If UV starts from middle of a page, then UV
> > > > start
> > > sho
> > > > +static void skl_wa_clkgate(struct drm_i915_private *dev_priv,
> > > > + int pipe, int enable)
> > > > +{
> > > > + if (pipe == PIPE_A || pipe == PIPE_B) {
> > > > + if (enable)
> > > > + I915_WRITE(CLKGATE_DIS_PSL(pipe),
> > > > +
Hi Daniel,
As Takashi has already accepted the first 3 patches for
sync_audio_rate() and the patches are not merged
into -nightly branch. If I make a kerneldoc patch
based on currently -nightly branch, there will
be conflict when you are merging Takashi's branch.
What do you think if I make the
96 matches
Mail list logo
