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
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, 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
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ä
>
> 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
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
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
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
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
(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
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
== 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:
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
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,
> +
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 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
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
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
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
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: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
> >
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.
== 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
> 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.
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
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
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
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
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 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
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 -
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
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
== 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 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
_
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
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
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
== 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 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
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
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
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 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
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
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
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
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
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
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,
> >>
> >>
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
== 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:
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
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
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
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 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[
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
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
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
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
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
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..
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
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
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 ++---
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
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
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
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
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 +++--
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 ->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 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
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 ==
> >
== 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 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
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 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 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ä
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 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
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
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
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
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
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, 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
97 matches
Mail list logo