On Thu, 2016-03-03 at 15:08 +0100, Maarten Lankhorst wrote:
> Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira:
> > The function intel_get_shared_dpll() had a more or less generic
> > implementation with some platform specific checks to handle smaller
> > differences between platforms. Howe
From: Libin Yang
To make sure audio_ptr is set before intel_audio_codec_enable()
or intel_audio_codec_disable() calling pin_eld_notify(),
this patch adds wmb barrier to prevent optimizing.
Signed-off-by: Libin Yang
---
sound/pci/hda/patch_hdmi.c | 5 +
1 file changed, 5 insertions(+)
diff
On Thu, 2016-03-03 at 15:08 +0100, Maarten Lankhorst wrote:
> Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira:
> > The function intel_get_shared_dpll() had a more or less generic
> > implementation with some platform specific checks to handle smaller
> > differences between platforms. Howe
Agreed, it does look messy.
As for the watermarks, we have verified that this patch works on Chrome OS with
the kernel version 3.18. We have not seen any regressions yet. However, it
requires the patch "drm/i915: Workaround CHV pipe C cursor fail" to be
reverted. I will send out another version
On Thu, Mar 03, 2016 at 03:50:23PM +, Lionel Landwerlin wrote:
> Hi Matt,
>
> On 11/02/16 02:32, Matt Roper wrote:
> >Gen9 platforms allow CRTC's to be programmed with a background/canvas
> >color below the programmable planes. Let's expose this as a property to
> >allow userspace to program
If all pipes are off, then we may have entered runtime suspend and
writing these registers will have no effect anyway. When a pipe is
re-enabled, it's crtc_enable will take care of programming appropriate
watermark values.
Cc: arun.siluv...@linux.intel.com
Cc: ville.syrj...@linux.intel.com
Bugzil
As of commit d81f04c5ef ("drm/i915: Allow preservation of watermarks, v2.")
it's now possible to have non-zero values for watermark levels that are
disabled (e.g., in the higher LP levels that can only be used when the sprite
is disabled). Stop WARN()'ing when we see these non-zero sprite values i
On Thu, Mar 03, 2016 at 05:47:14PM +, Tvrtko Ursulin wrote:
>
> On 03/03/16 11:02, Patchwork wrote:
> >== Series Details ==
> >
> >Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)
> >URL : https://patchwork.freedesktop.org/series/3973/
> >State : warning
> >
> >== Summa
On 02/03/16 18:08, Morton, Derek J wrote:
The CMD parser blacklists the TIMESTAMP register on gen 7.5 so I will leave
this as requiring gen8+
//Derek
You might still be able to store its value (to memory or the PPHWSP?)
using a PIPE_CONTROL or MI_FLUSH_DW instruction rather than accessing
Hi Damien, Hi Daniel,
I've submitted the patch below for the third time now in an attempt
to get CI to test it, again to no avail. This time I didn't set the
In-Reply-To header and only submitted it as a single patch instead
of as a series because I expected this might confuse CI.
Nevertheless CI
On Wed, 2016-03-02 at 17:22 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we assume that hrawclk is 200MHz on VLV/CHV. That should
> be true always, but just to avoid such asumptions we can read out the
> actual frequency from CCK.
>
> Signed-off-by: Ville Syrjä
On Thu, Mar 3, 2016 at 8:53 AM, Bjorn Helgaas wrote:
> The purpose of this series is to:
> [ .. ]
The patches look ok to me and seem to make sense.
Of course, let's see what they break. Hopefully nothing, but any time
the PCI resource code changes I get a bit worried. PTSD, I guess.
On 03/03/16 11:02, Patchwork wrote:
== Series Details ==
Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)
URL : https://patchwork.freedesktop.org/series/3973/
State : warning
== Summary ==
Series 3973v2 drm/i915: Move CSB MMIO reads out of the execlists lock
http://pat
On 03/03/16 17:20, Chris Wilson wrote:
On Thu, Mar 03, 2016 at 05:01:15PM +, Tvrtko Ursulin wrote:
On 03/03/16 15:03, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915: Add wait_for_us
URL : https://patchwork.freedesktop.org/series/4059/
State : failure
== Series Details ==
Series: series starting with [1/5] drm/i915: Add wait_for_us (rev2)
URL : https://patchwork.freedesktop.org/series/4059/
State : warning
== Summary ==
Series 4059v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/2/mbox/
Test gem
On Thu, Mar 03, 2016 at 05:01:15PM +, Tvrtko Ursulin wrote:
>
> On 03/03/16 15:03, Patchwork wrote:
> >== Series Details ==
> >
> >Series: series starting with [1/5] drm/i915: Add wait_for_us
> >URL : https://patchwork.freedesktop.org/series/4059/
> >State : failure
> >
> >== Summary ==
> >
On 3/3/2016 9:16 PM, Chris Wilson wrote:
On Thu, Mar 03, 2016 at 09:08:25PM +0530, Goel, Akash wrote:
Before we destroy the context (or exit), how about a query_trtt().
We should also query after create to ensure that the defaults are set.
Just thinking that is better doing the query after sev
The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.
We might likewise receive hotplug events or be suspended before
we've had a chance to fully set up the fbdev.
Fix by waiting for the asynchronous threa
On 03/03/16 15:03, Patchwork wrote:
== Series Details ==
Series: series starting with [1/5] drm/i915: Add wait_for_us
URL : https://patchwork.freedesktop.org/series/4059/
State : failure
== Summary ==
Series 4059v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/
The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute. Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.c | 13 +++--
Loongson 3 used the IORESOURCE_ROM_COPY flag for its ROM resource. There
are two problems with this:
- When IORESOURCE_ROM_COPY is set, pci_map_rom() assumes the resource
contains virtual addresses, so it doesn't ioremap the resource. This
implies loongson_sysconf.vgabios_addr is a vir
Use a temporary struct resource pointer to avoid needless repetition of
"pdev->resource[PCI_ROM_RESOURCE]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/m
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused.
Remove them and code that depends on them.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h |2 --
3 files changed, 1 i
Depositing __IA64_UNCACHED_OFFSET in the upper address bits is essentially
equivalent to ioremap(): it converts a CPU physical address to a virtual
address using the ia64 uncacheable identity map.
Call ioremap() instead of doing the phys-to-virt conversion manually with
__IA64_UNCACHED_OFFSET.
No
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io_init.c | 39
2 fi
A struct resource contains CPU physical addresses, not virtual addresses.
But sn_acpi_slot_fixup() and sn_io_slot_fixup() stored the virtual address
of a shadow ROM copy in the resource. To compensate, pci_map_rom() had a
special case that returned the resource address directly rather than
calling
Remove unnecessary indentation in pci_map_rom(). This is logically part of
the previous patch; I split it out to make the critical changes in that
patch more obvious. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 37 ++---
IORESOURCE_ROM_SHADOW means there is a copy of a device's option ROM in
RAM. The existence of such a copy and its location are arch-specific.
Previously the IORESOURCE_ROM_SHADOW flag was set in arch code, but the
0xC-0xD location was hard-coded into the PCI core.
If we're using a shadow
A shadow copy of an option ROM is placed by the BIOS as a fixed address.
Set IORESOURCE_PCI_FIXED to indicate that we can't move the shadow copy.
This prevents warnings like the following when we assign resources:
BAR 6: [??? 0x flags 0x2] has bogus alignment
This warning is emitted by
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
touch the ROM BAR enable bit.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
index 9eaca39..
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
The purpose of this series is to:
- Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
messages reported by Linus [1], Andy [2], and others.
- Move arch-specific shadow ROM location knowledge, e.g.,
0xC-0xD, from PCI core to arch code.
- Fix the ia64 and MIPS L
Check in dim_checkpatch if the committer's Signed-off-by line and a
Reviewed-by line exists in the commit message. If no Reviewed-by line
exists also accept two distinct Signed-off-by lines instead.
v2: (Jani)
- move the check from dim_push_branch to dim_checkpatch
- remove the check for the autho
From: Tvrtko Ursulin
Currently the wait_for_atomic_us only allows for a jiffie
timeout granularity which is not nice towards callers
requesting small micro-second timeouts.
Re-implement it so micro-second timeout granularity is really
supported and not just in the name of the macro.
This has an
On Thu, Mar 03, 2016 at 03:43:49PM +, Tvrtko Ursulin wrote:
>
> On 03/03/16 15:11, Chris Wilson wrote:
> >On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Currently the wait_for_atomic_us only allows for a millisecond
> >>granularity which is n
On Mon, Feb 29, 2016 at 02:26:52PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
> URL : https://patchwork.freedesktop.org/series/3916/
> State : failure
>
> == Summary ==
>
> Series 3916v1 drm/i915: Fix bogus dig_port_map[
Hi Matt,
On 11/02/16 02:32, Matt Roper wrote:
Gen9 platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this as a property to
allow userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru; unfort
On Thu, Mar 03, 2016 at 09:08:25PM +0530, Goel, Akash wrote:
> >Before we destroy the context (or exit), how about a query_trtt().
> >We should also query after create to ensure that the defaults are set.
> >Just thinking that is better doing the query after several steps (i.e.
> >the execbuf) rath
On 03/03/16 15:11, Chris Wilson wrote:
On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently the wait_for_atomic_us only allows for a millisecond
granularity which is not nice towards callers requesting small
micro-second waits.
Hmm, by granularity I
Thanks for the review.
On 3/3/2016 3:34 PM, Chris Wilson wrote:
On Thu, Mar 03, 2016 at 10:25:59AM +0530, akash.g...@intel.com wrote:
+static bool uses_full_ppgtt(int fd, int min)
gem_gtt_type()
fine will change like this,
gem_gtt_type(fd) > 2
+static bool has_softpin_support(int
== Series Details ==
Series: series starting with [1/5] drm/i915: Add wait_for_us
URL : https://patchwork.freedesktop.org/series/4059/
State : failure
== Summary ==
Series 4059v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4059/revisions/1/mbox/
Test gem_sync:
On Thu, Mar 03, 2016 at 02:36:44PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Currently the wait_for_atomic_us only allows for a millisecond
> granularity which is not nice towards callers requesting small
> micro-second waits.
Hmm, by granularity I think of the interval between CON
On Mon, 29 Feb 2016 15:39:53 +0100,
Jani Nikula wrote:
>
> On Mon, 29 Feb 2016, Martin Kepplinger wrote:
> > Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
> >> Sorry, Cc to Jani was missing mistakenly.
> >>
> >> Please check this. It's a regression in 4.5-rc.
> >>
> >>
> >> thanks,
> >>
> >>
From: Tvrtko Ursulin
This is for callers who want micro-second precision but are not
waiting from the atomic context.
v2:
* Fix atomic waits. (Dave Gordon)
* Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu
From: Tvrtko Ursulin
Looks like this code does not need to wait atomically since it
otherwise takes the mutex.
Signed-off-by: Tvrtko Ursulin
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
di
From: Tvrtko Ursulin
Currently the wait_for_atomic_us only allows for a millisecond
granularity which is not nice towards callers requesting small
micro-second waits.
Re-implement it so micro-second granularity is really supported
and not just in the name of the macro.
This has another benefici
From: Tvrtko Ursulin
I do not see that this needs to be done atomically and up to
one second is quite a long time to busy loop.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.
From: Tvrtko Ursulin
v2: Added a submenu based on an idea by Chris Wilson.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/Kconfig | 6 ++
drivers/gpu/drm/i915/Kconfig.debug | 12
2 files changed, 18 insertions(+)
create mode 1
Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira:
> The function intel_get_shared_dpll() had a more or less generic
> implementation with some platform specific checks to handle smaller
> differences between platforms. However, the minimalist approach forces
> bigger differences between pla
Op 03-03-16 om 14:40 schreef Ander Conselvan De Oliveira:
> On Thu, 2016-03-03 at 14:33 +0100, Maarten Lankhorst wrote:
>> Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira:
>>> Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
>>> enabled because of it driving CDCLK, i
On Thu, 2016-03-03 at 14:33 +0100, Maarten Lankhorst wrote:
> Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira:
> > Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
> > enabled because of it driving CDCLK, it is better to special case that
> > inside the DPLL code tha
Op 03-03-16 om 12:32 schreef Ander Conselvan De Oliveira:
> Hi Maarten,
>
> Thanks for reviewing. Comments below.
>
> On Wed, 2016-03-02 at 16:30 +0100, Maarten Lankhorst wrote:
>> Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira:
>>> Use a table to store the per-platform shared dpll inform
Op 29-02-16 om 10:08 schreef Ander Conselvan de Oliveira:
> Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
> enabled because of it driving CDCLK, it is better to special case that
> inside the DPLL code than in the higher level.
>
> v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander
On Thu, 2016-03-03 at 12:02 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll
> code to a new file
> URL : https://patchwork.freedesktop.org/series/4055/
> State : failure
>
> == Summary ==
>
> Series 4055v1 Series wi
== Series Details ==
Series: drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep
URL : https://patchwork.freedesktop.org/series/4056/
State : failure
== Summary ==
Series 4056v1 drm: Taint mm->mmap_sem with dev->struct_mutex for lockdep
http://patchwork.freedesktop.org/api/1.0/series/40
On Fri, 26 Feb 2016, Ramalingam C wrote:
> On Thursday 18 February 2016 02:00 AM, Jani Nikula wrote:
>> On Mon, 15 Feb 2016, Deepak M wrote:
>>> The MIPI clock calculations for the addtional clock
>>> are revised from B0 stepping onwards, the bit definitions
>>> have changed compared to old stepp
The DRM core depends on mm->mmap_sem being the outer lock in order to
setup/teardown and utilize fault handlers. If we taint the mm->mmap_sem
as soon as we open the device for a process, we can define this proper
ordering for lockdep and so it will report any violations early.
Signed-off-by: Chris
Hi Dave, a couple of Intel fixes for v4.5.
BR,
Jani.
The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:
Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-03-03
for
On Tue, 01 Mar 2016, Jani Nikula wrote:
> intel_reg.rst was the first man page written in reStructuredText. Follow
> suit with the rest of the man pages.
Marius, Daniel, any comments before I go ahead and push?
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_
== Series Details ==
Series: series starting with [RESEND,FOR,CI,1/6] drm/i915: Move shared dpll
code to a new file
URL : https://patchwork.freedesktop.org/series/4055/
State : failure
== Summary ==
Series 4055v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4055
On Thu, 03 Mar 2016, Imre Deak wrote:
> On Thu, 2016-03-03 at 10:11 +0200, Jani Nikula wrote:
>> On Wed, 02 Mar 2016, Imre Deak wrote:
>> > Check if the committer's and author's Signed-off-by line and at
>> > least
>> > one Reviewed-by line exists in each commit to be pushed.
>> >
>> > Signed-of
Change the type of intel_crtc_state->shared_dpll to be a pointer to a
shared dpll. With this there is no need to first convert the id stored
in the crtc state to a pointer in order to use it. It does introduce a
bit of hassle on doing the opposite.
The long term objective is to hide details about
Create the new file intel_dpll_mgr.c and move the shared dpll code to
it. Follow up patches that reorganize pll handling will move more code
there and tweak the interface.
No functional changes.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915
Move shared dpll function prototype together with other shared dpll
definitions.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dpll_mgr.h | 30 ++
drivers/gpu/drm/i915/intel_drv.h | 28 -
No functional changes.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_ddi.c | 472 --
drivers/gpu/drm/i915/intel_dpll_mgr.c | 472 ++
drivers/gpu/drm/i915/intel_drv.h
Move the declarations related to shared dplls from i915_drv.h to their
own header file.
The code that became the shared dpll infrastructre was first introcude
in commit ee7b9f93fd96 ("drm/i915: manage PCH PLLs separately from
pipes"), hence the 2012-2016 copyright years in the new header file.
Si
Make the code neater by splitting the code for platforms with fixed PLL
to their own functions and splitting the logic for finding a shareable
or unused pll from the logic for setting it up.
Signed-off-by: Ander Conselvan de Oliveira
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/inte
On Thu, Mar 03, 2016 at 11:27:47AM +, Auld, Matthew wrote:
> > Handle overflow?
>
> Okay, good idea.
>
> > Why do it here and not at creation?
>
> We could, given that we currently only exercise partial views in the gem
> fault handler code, but as Joonas mentioned we are expecting further
Hi Maarten,
Thanks for reviewing. Comments below.
On Wed, 2016-03-02 at 16:30 +0100, Maarten Lankhorst wrote:
> Op 26-02-16 om 14:54 schreef Ander Conselvan de Oliveira:
> > Use a table to store the per-platform shared dpll information in one
> > place. This way, there is no need for platform spe
> Handle overflow?
Okay, good idea.
> Why do it here and not at creation?
We could, given that we currently only exercise partial views in the gem fault
handler code, but as Joonas mentioned we are expecting further use of partial
views, so it makes sense to have the check in only one place.
== Series Details ==
Series: drm/i915: Move CSB MMIO reads out of the execlists lock (rev2)
URL : https://patchwork.freedesktop.org/series/3973/
State : warning
== Summary ==
Series 3973v2 drm/i915: Move CSB MMIO reads out of the execlists lock
http://patchwork.freedesktop.org/api/1.0/series/3
Patchwork writes:
> == Series Details ==
>
> Series: drm/i915/hangcheck: Prevent long walks across full-ppgtt
> URL : https://patchwork.freedesktop.org/series/4023/
> State : warning
>
> == Summary ==
>
> Series 4023v1 drm/i915/hangcheck: Prevent long walks across full-ppgtt
> http://patchwork.
On Thu, Mar 03, 2016 at 10:51:23AM +0200, Jani Nikula wrote:
> On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we assume that hrawclk is 200MHz on VLV/CHV. That should
> > be true always, but just to avoid such asumptions we can read out the
> >
On Thu, Mar 03, 2016 at 10:47:38AM +0200, Jani Nikula wrote:
> On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Generalize rawclk handling by storing it in dev_priv.
> >
> > Presumably our hrawclk readout works at least for CTG and ELK
> > since we've been
On Thu, Mar 03, 2016 at 10:25:06AM +0200, Jani Nikula wrote:
> On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Supposedly we would want to get the PWM output as close as possible to
> > the target, so let's round to closest.
> >
> > Cc: Jani Nikula
> > Su
Arun Siluvery writes:
> On 02/03/2016 15:56, Patchwork wrote:
>> == Series Details ==
>>
>> Series: drm/i915: Generalise common GPU engine reset request/unrequest code
>> URL : https://patchwork.freedesktop.org/series/4021/
>> State : warning
>>
>> == Summary ==
>>
>> Series 4021v1 drm/i915: Ge
From: Tvrtko Ursulin
By reading the CSB (slow MMIO accesses) into a temporary local
buffer we can decrease the duration of holding the execlist
lock.
Main advantage is that during heavy batch buffer submission we
reduce the execlist lock contention, which should decrease the
latency and CPU usag
On Wed, Mar 02, 2016 at 07:13:07PM +0200, Imre Deak wrote:
> On Fri, 2016-02-26 at 10:02 -0800, Rodrigo Vivi wrote:
> > [...]
> > Well, I have this tree:
> > https://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=rpm-domains-psr-vblank-counter-full
> > with mainly:
> > 1 - vblank domain on pre-enab
On Thu, 2016-03-03 at 10:11 +0200, Jani Nikula wrote:
> On Wed, 02 Mar 2016, Imre Deak wrote:
> > Check if the committer's and author's Signed-off-by line and at
> > least
> > one Reviewed-by line exists in each commit to be pushed.
> >
> > Signed-off-by: Imre Deak
> > ---
> > dim | 32
On Thu, Mar 03, 2016 at 10:25:59AM +0530, akash.g...@intel.com wrote:
> +static bool uses_full_ppgtt(int fd, int min)
gem_gtt_type()
> +static bool has_softpin_support(int fd)
gem_has_softpin()
> +static int emit_store_dword(int fd, uint32_t *cmd_buf, uint32_t dw_offset,
> +
Dear i915 developers,
Here I have one topic hoping to get your comments and suggestions.
Basically it is about graphics virtualization(igvt-g), for the purpose
of host system to get virtual machine's framebuffer. We would like to
hear your opinions about some design opens. Below is the
patch and s
== Series Details ==
Series: drm/atomic: Fix encoder stealing, v3.
URL : https://patchwork.freedesktop.org/series/4045/
State : failure
== Summary ==
Series 4045v1 drm/atomic: Fix encoder stealing, v3.
http://patchwork.freedesktop.org/api/1.0/series/4045/revisions/1/mbox/
Test kms_flip:
Hi Maarten,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20160303]
[cannot apply to v4.5-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Maarten-Lankhorst
(Cc'ing Sivakumar, as he might have some ideas on this)
On Fri, 2016-02-26 at 12:54 +0200, Mika Kuoppala wrote:
> If the panel don't give us the information how long to wait
> before starting a new link training phase, it is not productive
> to poke it at 100us or 400us intervals and then give up
Instead of failing with -EINVAL when conflicting encoders are found,
the legacy set_config will disable other connectors when encoders
conflict.
With the previous commit this becomes a lot easier to implement.
set_config only adds connectors to the state that are modified,
and because of the previ
There's no need to have a separate function to get the crtc
which is stolen, this can already be found when actually
stealing the encoder.
drm_for_each_connector already checks for connection_mutex, so
use that macro now.
Changes since v1:
- Do not check for NULL crtc in connector_state,
this m
With the addition of crtc_state->connector_mask other connectors from
different crtc's aren't needed any more, so only call
add_affected_connectors on the target crtc. This allows a cleanup
to first remove all current connectors, then add all set->connectors
to the target crtc.
Signed-off-by: Maar
Now that only encoders can be stolen that are part of the state
steal_encoder no longer needs to inspect all connectors,
just those that are part of the atomic state.
Changes since v1:
- Change return value to void, can no longer fail.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_at
The current check doesn't handle the case where we don't steal an
encoder, but keep it on the current connector. If we repurpose
disable_conflicting_encoders to do the checking, we just have
to reject the ones that conflict.
Changes since v1:
- Return early with empty encoder_mask, drm_for_each_co
Minor cleanup, connector and connector_state are always non-NULL here.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/
connector_state->crtc can no longer be unset by accident,
so that check can be removed. The other code open-codes
drm_atomic_get_existing_crtc_state, so use that.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 17 -
1 file changed, 4 insertions(+), 13
This is a resend of "drm/atomic: Fix encoder stealing" with updated patches.
Maarten Lankhorst (7):
drm/atomic: Clean up update_output_state.
drm/atomic: Pass connector and state to update_connector_routing.
drm/atomic: Always call steal_encoder, v2.
drm/atomic: Handle encoder stealing fro
On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we assume that hrawclk is 200MHz on VLV/CHV. That should
> be true always, but just to avoid such asumptions we can read out the
> actual frequency from CCK.
Okay, so I don't want to spend forever lookin
On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Generalize rawclk handling by storing it in dev_priv.
>
> Presumably our hrawclk readout works at least for CTG and ELK
> since we've been using it for DP AUX on those platforms. There
> are no real docs anymore af
On Wed, 02 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Supposedly we would want to get the PWM output as close as possible to
> the target, so let's round to closest.
>
> Cc: Jani Nikula
> Suggested-by: Jani Nikula
I have zero recollection of asking this change, but
Op 02-03-16 om 22:08 schreef Zanoni, Paulo R:
> Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu:
>> On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote:
>>> Only planes that are part of the state should be used for
>>> recalculating
>>> watermarks. For planes not part of the st
On Wed, 02 Mar 2016, Imre Deak wrote:
> Check if the committer's and author's Signed-off-by line and at least
> one Reviewed-by line exists in each commit to be pushed.
>
> Signed-off-by: Imre Deak
> ---
> dim | 32
> 1 file changed, 32 insertions(+)
>
> diff --g
97 matches
Mail list logo
