date:20180218

https://bugs.freedesktop.org/show_bug.cgi?id=105145

--- Comment #4 from Christian König  ---
(In reply to k.philipp from comment #2)
> Since we can do weaving on the Kodi side anyway (for VDPAU), would it be
> enough to add flags, say VA_EXPORT_SURFACE_TOP_FIELD and
> VA_EXPORT_SURFACE_BOTTOM_FIELD, to vaExportSurfaceHandle? Would that then be
> roughly equivalent to what we get with VDPAURegisterVideoSurfaceNV?

Yes, exactly that's what's needed.

(In reply to k.philipp from comment #3)
> Here's what we'll do instead (in case someone comes here looking for a
> workaround):
> - For 2K video or less: Always do VAAPI postprocessing. If the content turns
> out to be progressive, we do an unnecessary copy (as the driver has to
> weave). But it enables us to switch deinterlacing on and off on a per-frame
> basis - needed not only for toggling deinterlacing on user wish, but also
> for mixed progressive/interlaced video. If you're very sure there are no
> interlaced frames anywhere in the video, postprocessing could also be turned
> off (we're usually not).
> - For more than 2K video: Start with no VAAPI postprocessing for best
> performance. If interlaced frames are encountered, activate VAAPI
> postprocessing and reinitialize decoding with fresh surfaces. This means
> we'll drop frames and lag around for a bit, but should be OK-ish since >2K
> interlaced content is very rare.

Sounds like a good plan to me as well.

> Also, that VAAPI has to weave the first few textures before they've been
> exported once is not very nice. Is there some kind of hint we could give the
> driver that we want to have progressive surfaces?

Not that I know of, but feel free to suggest something. General problem with
VA-API seems to be that suggestions made by AMD seems to be mostly ignored.

Also don't call it interlaced/progressive (that was just me trying to make
sense of what the hardware is doing).

Instead call it something in the line of FIELD and FRAME, that is the more
common terminology at least in the different MPEG standards.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105076] [CI] results file indicate incomplete run.log say other result

https://bugs.freedesktop.org/show_bug.cgi?id=105076

--- Comment #7 from Marta Löfstedt  ---
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3785/shard-glkb1/igt@kms_atomic_interrupti...@legacy-pageflip.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3786/shard-glkb1/igt@kms_vbl...@pipe-c-query-forked-busy-hang.html
these are also potentially before disc update.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100919] [DC] "Out of range" on a display connected to a DVI-D output of RX460 card via DVI-D<=>HDMI-A cable

https://bugs.freedesktop.org/show_bug.cgi?id=100919

Thomas R.  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #12 from Thomas R.  ---
I finally came around to testing vanilla 4.15.4, and the problem is in there,
still. Also I'm having trouble translating the patch by Harry to the refactored
code - I guess it should go into display/dc/core/dc_link.c somewhere, but I
don't know where exactly, as there is no update_stream_signal() in there
anymore. The closest place I found is in dc_link_detect(), but I'm uncertain if
I should make the SINGLE or DUAL_LINK decision in there?

Harry, can you look at this or do you need more info from me?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105076] [CI] results file indicate incomplete run.log say other result

https://bugs.freedesktop.org/show_bug.cgi?id=105076

--- Comment #6 from Marta Löfstedt  ---
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4262/shard-glkb1/igt@pm_backli...@fade.html

Above is before disk change

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353

--- Comment #34 from Bong Cosca  ---
@Michel, are there any impediments in getting this patch merged with mesa-git?
I tried this with both 17.3.3 and 17.3.4 without any side effects.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105156] kdg2kfd_probe failed

https://bugs.freedesktop.org/show_bug.cgi?id=105156

Bug ID: 105156
   Summary: kdg2kfd_probe failed
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/amdkfd
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sendion23...@yahoo.com

For some unknown reason, I started to get the "kgd2kfd_probe failed" message
after the update of Fedora-27 (limited to security advisories).  Here is dmesg
output:
  Console:  switching to colour frame buffer device 240x67
  radeon :01:05.0: fb0: radeondrmfb frame buffer device
  kfd kfd: DID 9710 is missing in supported_devices
  kfd kfd: kgd2kfd_probe failed
  [drm] Initialized radeon  2.50.0 20080528 for :01:05.0 on minor 0
from kernel version: 4.14.16-300.fc27.x86_64

Compare with the dmesg output:
  Console:  switching to colour frame buffer device 240x67
  radeon :01:05.0: fb0: radeondrmfb frame buffer device
  [drm] Initialized radeon  2.50.0 20080528 for :01:05.0 on minor 0
from the kernel version 4.13.9-300.fc27.x86_64



Q1. Is this failure expected?  Note that this system doesn't support IOMMU.
Q2. What to do if such failure is not expected?

  Thank you,
  - Sen Dion


  P.S. 

This is my first submission to the list.  Kindly forgive me if I missed to
adhere to the list posting guildelines.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/24] dt-bindings: display: add HPD gpio to DVI connector

2018-02-18 Thread Rob Herring

On Mon, Feb 12, 2018 at 11:44:34AM +0200, Tomi Valkeinen wrote:
> Add hpd-gpios property to dvi-connector.txt.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: devicet...@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/display/connector/dvi-connector.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] Add support for in-line nested struct comments

2018-02-18 Thread Jonathan Corbet

On Fri, 16 Feb 2018 11:48:14 -0200
Mauro Carvalho Chehab  wrote:

> his series fix two bugs at kernel-doc.rst examples and add support
> for in-line nested struct comments.
> 
> It also converts one documentation at intel_dpio_phy to use it,
> in order to give a practical example about how to use it.

OK, I've applied everything but the last patch, which I assume will go
through the DRM tree.

Thanks,

jon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 4/8] dt-bindings: panel: common: document orientation property

2018-02-18 Thread Rob Herring

On Thu, Feb 08, 2018 at 07:30:31PM +0100, Sebastian Reichel wrote:
> Introduce new "orientation" property for describing in which
> orientation a panel has been mounted to the device. This can
> be used by the operating system to automatically rotate the
> display correctly.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  .../devicetree/bindings/display/panel/panel-common.txt | 12 
>  include/dt-bindings/display/common.h   | 14 
> ++
>  2 files changed, 26 insertions(+)
>  create mode 100644 include/dt-bindings/display/common.h
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.txt 
> b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> index 557fa765adcb..c646b8908458 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.txt
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.txt
> @@ -18,6 +18,18 @@ Descriptive Properties
>physical area where images are displayed. These properties are expressed in
>millimeters and rounded to the closest unit.
>  
> +- orientation: The orientation property specifies the panel orientation
> +  in relation to the device's casing. The following values are possible:
> +
> +   * 0 = The top side of the panel matches the top side of the device's
> + casing.
> +   * 1 = The top side of the panel matches the bottom side of the device's
> + casing. In other words the panel is mounted upside-down.
> +   * 2 = The left side of the panel matches the top side of the device's
> + casing.
> +   * 3 = The right side of the panel matches the top side of the device's
> + casing.


The rotation property in panel.txt already handles this, right?

> +
>  - label: The label property specifies a symbolic name for the panel as a
>string suitable for use by humans. It typically contains a name inscribed 
> on
>the system (e.g. as an affixed label) or specified in the system's
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] dt-bindings/display/panel: Add support for Raydium rm68200 dsi panel

2018-02-18 Thread Rob Herring

On Thu, Feb 08, 2018 at 03:30:25PM +0100, Philippe Cornu wrote:
> The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
> TFT LCD panel connected using a MIPI-DSI video interface.
> 
> Signed-off-by: Philippe Cornu 
> ---
>  .../bindings/display/panel/raydium,rm68200.txt | 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt

Reviewed-by: Rob Herring 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: build warning after merge of the drm tree

2018-02-18 Thread Stephen Rothwell

Hi all,

After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

In file included from include/linux/list.h:9:0,
 from include/linux/wait.h:7,
 from include/linux/wait_bit.h:8,
 from include/linux/fs.h:6,
 from include/linux/highmem.h:5,
 from drivers/gpu/drm/drm_memory.c:36:
drivers/gpu/drm/drm_memory.c: In function 'drm_get_max_iomem':
include/linux/kernel.h:808:16: warning: comparison of distinct pointer types 
lacks a cast
  (void) ( == );   \
^
include/linux/kernel.h:817:2: note: in expansion of macro '__max'
  __max(typeof(x), typeof(y),   \
  ^
drivers/gpu/drm/drm_memory.c:159:15: note: in expansion of macro 'max'
   max_iomem = max(max_iomem,  tmp->end);
   ^~~

Introduced by commit

  82626363a217 ("drm: add func to get max iomem address v2")

tmp->end is a resource_size_t ...

-- 
Cheers,
Stephen Rothwell


pgptfdP26MPf3.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with Linus' tree

2018-02-18 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_breadcrumbs.c

between commit:

  117172c8f9d4 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers")

from Linus' tree and commit:

  b7a3f33bd5ab ("drm/i915/breadcrumbs: Drop request reference for the signaler 
thread")

from the drm tree.

These are basically identical for the conflicting section except that
the former added a line:

GEM_BUG_ON(!i915_gem_request_completed(request));

which I left in.

I fixed it up (see above) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpFGXl3DBKbP.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with Linus' tree

2018-02-18 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/i915_pmu.h

between commit:

  4c83f0a788cc ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")

from Linus' tree and commit:

  109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_pmu.h
index bb62df15afa4,5a2e013a56bb..
--- a/drivers/gpu/drm/i915/i915_pmu.h
+++ b/drivers/gpu/drm/i915/i915_pmu.h
@@@ -96,10 -94,14 +96,18 @@@ struct i915_pmu 
 * struct intel_engine_cs.
 */
struct i915_pmu_sample sample[__I915_NUM_PMU_SAMPLERS];
 +  /**
 +   * @suspended_jiffies_last: Cached suspend time from PM core.
 +   */
 +  unsigned long suspended_jiffies_last;
+   /**
+* @i915_attr: Memory block holding device attributes.
+*/
+   void *i915_attr;
+   /**
+* @pmu_attr: Memory block holding device attributes.
+*/
+   void *pmu_attr;
  };
  
  #ifdef CONFIG_PERF_EVENTS


pgpQ1z2PC6qsg.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=104520

--- Comment #10 from Amy  ---
Additonally: Mesa version is

OpenGL version string: 3.0 Mesa 17.3.4

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=104520

Amy  changed:

   What|Removed |Added

   Severity|normal  |major

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=104520

--- Comment #9 from Amy  ---
Still happening on:

Linux Playful-Plankton 4.15.4-1-ARCH #1 SMP PREEMPT Sat Feb 17 16:01:38 UTC
2018 x86_64 GNU/Linux

version number:11.0
X.Org version: 1.19.6

xf86-video-intel 1:2.99.917+812+g75795523-1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Question about lima kernel MM implementation

2018-02-18 Thread Qiang Yu

>
>
> >
> > Current MM:
> > 1. drm_gem_cma_object, only support contiguous memory
>
> Please note that drm_gem_cma_object only looks at memory after the MMU
> has done the mapping. If you have a good IOMMU driver that registers
> correctly the dma_ops then you can allocate memory from anywhere and
> still import it into the lima driver via drm_gem_cma_prime_import_sg_
> table()
> hook attached to the gem_prime_import_sg_table.
>
Thanks, good to know this. But some Mali400/450 SoC doesn't have IOMMU
at all, so I can't rely on it.

Regards,
Qiang


>
> > 3. buffer is not really allocated when GEM_CREATE, but in CPU
> > page fault handler and task submit buffer validation which make
> > sure no GPU page fault
> > 4. in shrinker handler, free un-used page in the pool, if still not
> > enough, swap some idle buffer to disk
> >
> > 3&4 apply to both dma_alloc buffer and alloc_page buffer.
> >
> > Thanks,
> > Qiang
>
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
>  /`\
> / : |
>_.._ | '/
>  /`\| /
> |  .-._ '-"` (
> |_/   /   o  o\
>   |  == () ==
>\   -- /   __
> 
>/ ---<_  |
> |___
>   |  \\ \   |  I would like to fix the world but
>  |  /
>   | | \\__   \  |   no one gives me the source code.
>  | /
>   / ; |.__)  /  |__|
>\
>  (_/.-.   ; /__)
> (_\
> { `|   \_/
>  '-\   / |
> | /  |
>/  \  '-.
>\__|-'
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

2018-02-18 Thread Kai-Heng Feng

Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.

Hence, use 6 bpc quirk for this panel.

Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp 
when sink capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd537914575..d9c8d718e261 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -113,6 +113,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
 
+   /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */
+   { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fix double ;;s in code

2018-02-18 Thread Christophe LEROY




Le 17/02/2018 à 22:19, Pavel Machek a écrit :


Fix double ;;'s in code.

Signed-off-by: Pavel Machek 


A summary of the files modified on top of the patch would help 
understand the impact.


A maybe there should be one patch by area, eg one for each arch specific 
modif and one for drivers/ and one for block/ ?


Christophe



diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
  {
struct cpuinfo_arc *cpu = _arc700[smp_processor_id()];
int saved = 0, present = 0;
-   char *opt_nm = NULL;;
+   char *opt_nm = NULL;
  
  	if (!cpu->extn.timer0)

panic("Timer0 is not present!\n");
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 333daab..183391d 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -366,7 +366,7 @@ static void init_unwind_hdr(struct unwind_table *table,
return;
  
  ret_err:

-   panic("Attention !!! Dwarf FDE parsing errors\n");;
+   panic("Attention !!! Dwarf FDE parsing errors\n");
  }
  
  #ifdef CONFIG_MODULES

diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 629f8e9..cf2701c 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -83,7 +83,7 @@ static void dummy_clock_access(struct timespec64 *ts)
  }
  
  static clock_access_fn __read_persistent_clock = dummy_clock_access;

-static clock_access_fn __read_boot_clock = dummy_clock_access;;
+static clock_access_fn __read_boot_clock = dummy_clock_access;
  
  void read_persistent_clock64(struct timespec64 *ts)

  {
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6618036..9ae31f7 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1419,7 +1419,7 @@ static int compat_ptrace_hbp_get(unsigned int note_type,
u64 addr = 0;
u32 ctrl = 0;
  
-	int err, idx = compat_ptrace_hbp_num_to_idx(num);;

+   int err, idx = compat_ptrace_hbp_num_to_idx(num);
  
  	if (num & 1) {

err = ptrace_hbp_get_addr(note_type, tsk, idx, );
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index f0f5cd4..f9818d7 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -188,7 +188,7 @@ static int xive_provision_queue(struct kvm_vcpu *vcpu, u8 
prio)
if (!qpage) {
pr_err("Failed to allocate queue %d for VCPU %d\n",
   prio, xc->server_num);
-   return -ENOMEM;;
+   return -ENOMEM;
}
memset(qpage, 0, 1 << xive->q_order);
  
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c

index 496e476..a6c92c7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1854,7 +1854,7 @@ static int pnv_pci_ioda_dma_set_mask(struct pci_dev 
*pdev, u64 dma_mask)
s64 rc;
  
  	if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))

-   return -ENODEV;;
+   return -ENODEV;
  
  	pe = >ioda.pe_array[pdn->pe_number];

if (pe->tce_bypass_enabled) {
diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index 353e20c..886a911 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 
*width, u32 *height)
struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
-   u32 *handles = (u32 *)uga_handle;;
+   u32 *handles = (u32 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
  
@@ -484,7 +484,7 @@ setup_uga64(void **uga_handle, unsigned long size, u32 *width, u32 *height)

struct efi_uga_draw_protocol *uga = NULL, *first_uga;
efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
unsigned long nr_ugas;
-   u64 *handles = (u64 *)uga_handle;;
+   u64 *handles = (u64 *)uga_handle;
efi_status_t status = EFI_INVALID_PARAMETER;
int i;
  
diff --git a/block/sed-opal.c b/block/sed-opal.c

index 9ed51d0c..e4929ee 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -490,7 +490,7 @@ static int opal_discovery0_end(struct opal_dev *dev)
  
  	if (!found_com_id) {

pr_debug("Could not find OPAL comid for device. Returning 
early\n");
-   return -EOPNOTSUPP;;
+   return -EOPNOTSUPP;
}
  
  	dev->comid = comid;

diff --git a/drivers/clocksource/mips-gic-timer.c 
b/drivers/clocksource/mips-gic-timer.c
index a04808a..65e18c8 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -205,12 +205,12 @@ static int __init gic_clocksource_of_init(struct 
device_node *node)
} else

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

https://bugs.freedesktop.org/show_bug.cgi?id=105145

--- Comment #3 from k.phil...@gmail.com ---
OK, scratch that. Our VAAPI weave implementation uses legacy GL features, and
we're not very keen to accommodate for fields in separate textures in our
general shaders.

Here's what we'll do instead (in case someone comes here looking for a
workaround):
- For 2K video or less: Always do VAAPI postprocessing. If the content turns
out to be progressive, we do an unnecessary copy (as the driver has to weave).
But it enables us to switch deinterlacing on and off on a per-frame basis -
needed not only for toggling deinterlacing on user wish, but also for mixed
progressive/interlaced video. If you're very sure there are no interlaced
frames anywhere in the video, postprocessing could also be turned off (we're
usually not).
- For more than 2K video: Start with no VAAPI postprocessing for best
performance. If interlaced frames are encountered, activate VAAPI
postprocessing and reinitialize decoding with fresh surfaces. This means we'll
drop frames and lag around for a bit, but should be OK-ish since >2K interlaced
content is very rare.

Also, that VAAPI has to weave the first few textures before they've been
exported once is not very nice. Is there some kind of hint we could give the
driver that we want to have progressive surfaces?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105152] Display artifacts related to DCC on radeonsi

https://bugs.freedesktop.org/show_bug.cgi?id=105152

Bug ID: 105152
Summary: Display artifacts related to DCC on radeonsi
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/radeonsi
Assignee: dri-devel@lists.freedesktop.org
Reporter: mario.klei...@tuebingen.mpg.de
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137424
--> https://bugs.freedesktop.org/attachment.cgi?id=137424=edit
apitrace exposing the problem in realtime replay

This i observe on radeonsi with a Volcanic Islands R9 380 TONGA with one
specific demo in my toolkit.

What the demo does is it renders between 1 and 5 textured quads on top of each
other, each quad with the same texture, but different texture coordinates and
"zoom". It uses alpha-blending with GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA to
blend the layers together. All in an endless animation that creates an
interesting "infinite zoom" effect.

Attached an apitrace of a few seconds of execution of the animation loop.

If the demo doesn't draw about more than 3 such quads per animation frame on
top of each other, the animation looks correct. With 5 quads i get some weird
dynamic noise in some parts of the displayed content, as if parts of the pixels
would somehow overflow and wrap around.

If one steps through the apitrace, looking up state at swapbuffers, each
rendered frame looks correct, but if one replays the trace in real-time, the
visual artifacts show up, so it doesn't seem to be a rendering problem, but
some kind of interaction with DCC?

If i set R600_DEBUG=nodccfb then all artifacts disappear.
Running on older Evergreen hw under r600 instead of radeonsi doesn't cause
these artifacts.

The problem was already present in some earlier Mesa version (17.2 as shipping
in Ubuntu 17.10), and is present in master.

Another way to reproduce is running the demo on a Debian/Ubuntu system via:

1. apt install octave-psychtoolbox-3
2. octave --eval ShepardZoomDemo

Source code of the demo under:

https://github.com/Psychtoolbox-3/Psychtoolbox-3/blob/master/Psychtoolbox/PsychDemos/OpenGL4MatlabDemos/ShepardZoomDemo.m

--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] meson: do not use cairo/valgrind if disabled

2018-02-18 Thread Igor Gnatenko

-Dcairo-tests=false currently results into enabling cairo support if it
was found. Same for valgrind.

Signed-off-by: Igor Gnatenko 
---
 meson.build | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/meson.build b/meson.build
index 166559e8..695f89b3 100644
--- a/meson.build
+++ b/meson.build
@@ -226,8 +226,20 @@ endforeach
 
 dep_pciaccess = dependency('pciaccess', version : '>= 0.10', required : 
with_intel)
 dep_cunit = dependency('cunit', version : '>= 2.1', required : false)
-dep_cairo = dependency('cairo', required : with_cairo_tests == 'true')
-dep_valgrind = dependency('valgrind', required : with_valgrind == 'true')
+if with_cairo_tests != 'false'
+  dep_cairo = dependency('cairo', required : with_cairo_tests == 'true')
+  with_cairo_tests = dep_cairo.found()
+else
+  dep_cairo = declare_dependency()
+  with_cairo_tests = false
+endif
+if with_valgrind != 'false'
+  dep_valgrind = dependency('valgrind', required : with_valgrind == 'true')
+  with_valgrind = dep_valgrind.found()
+else
+  dep_valgrind = declare_dependency()
+  with_valgrind = false
+endif
 
 with_man_pages = get_option('man-pages')
 prog_xslt = find_program('xsltproc', required : with_man_pages == 'true')
@@ -259,8 +271,8 @@ foreach t : [
  [with_radeon, 'RADEON'],
  [with_vc4, 'VC4'],
  [with_vmwgfx, 'VMWGFX'],
- [dep_cairo.found(), 'CAIRO'],
- [dep_valgrind.found(), 'VALGRIND'],
+ [with_cairo_tests, 'CAIRO'],
+ [with_valgrind, 'VALGRIND'],
 ]
   config.set10('HAVE_@0@'.format(t[1]), t[0])
 endforeach
-- 
2.16.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA

2018-02-18 Thread Mario Kleiner


On 02/18/2018 09:53 AM, Kai-Heng Feng wrote:

Similar to commit e10aec652f31 ("drm/edid: Add 6 bpc quirk for display
AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
6bpc instead of 8 bpc.

Hence, use 6 bpc quirk for this panel.

Fixes: 196f954e2509 ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink 
capability is unknown"")
BugLink: https://bugs.launchpad.net/bugs/1749420
Signed-off-by: Kai-Heng Feng 
---
  drivers/gpu/drm/drm_edid.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ddd537914575..d9c8d718e261 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -113,6 +113,9 @@ static const struct edid_quirk {
/* AEO model 0 reports 8 bpc, but is a 6 bpc panel */
{ "AEO", 0, EDID_QUIRK_FORCE_6BPC },
  
+	/* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */

+   { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC },
+
/* Belinea 10 15 55 */
{ "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
{ "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },



Reviewed-by: Mario Kleiner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL FOR v4.17] R-Car DU changes

2018-02-18 Thread Laurent Pinchart

Hi Dave,

The following changes since commit 94fc27ac487a80daf42f97b1a0503d029f3c1325:

  Merge tag 'drm-intel-next-fixes-2018-02-07' of git://
anongit.freedesktop.org/drm/drm-intel into drm-next (2018-02-08 08:21:37 
+1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/media.git drm/next/du

for you to fetch changes up to 871dfe7b48bdc56877826d6cf669e9eef0cf671b:

  drm: rcar-du: lvds: Refactor LVDS startup (2018-02-15 02:06:21 +0200)


Kuninori Morimoto (2):
  drm: rcar-du: Use 1000 to avoid misunderstanding in 
rcar_du_dpll_divider()
  drm: rcar-du: Calculate DPLLCR to be more small jitter

Laurent Pinchart (3):
  drm: rcar-du: Remove zpos field from rcar_du_vsp_plane_state structure
  drm: rcar-du: Enable VSP compositor by default on Gen3
  drm: rcar-du: lvds: Fix LVDS clock frequency range

Sergei Shtylyov (4):
  drm: rcar-du: lvds: Fix LVDCR1 for R-Car gen3
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen2
  drm: rcar-du: lvds: Fix LVDS startup on R-Car Gen3
  drm: rcar-du: lvds: Refactor LVDS startup

 drivers/gpu/drm/rcar-du/Kconfig   |   3 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  51 --
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 140 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h |   2 -
 drivers/gpu/drm/rcar-du/rcar_lvds_regs.h  |   6 +-
 5 files changed, 103 insertions(+), 99 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 03/43] drm/rockchip: Respect page offset for PRIME mmap calls

Am Dienstag, 30. Januar 2018, 21:28:33 CET schrieb Thierry Escande:
> From: Ørjan Eide 
> 
> When mapping external DMA-bufs through the PRIME mmap call, we might be
> given an offset which has to be respected. However for the internal DRM
> GEM mmap path, we have to ignore the fake mmap offset used to identify
> the buffer only. Currently the code always zeroes out vma->vm_pgoff,
> which breaks the former.
> 
> This patch fixes the problem by moving the vm_pgoff assignment to a
> function that is used only for GEM mmap path, so that the PRIME path
> retains the original offset.
> 
> Cc: Daniel Kurtz 
> Signed-off-by: Ørjan Eide 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Tested-by: Heiko Stuebner 

applied to drm-misc.

So I've picked up the "easy" patches that I have read somewhat often
and also tested myself using the lima driver on some Rockchip socs
(rk3036 + mali400 and rk3328 + mali450).

I'll try to also look at the rest but no guarantees on timing as they
look a lot more involved in real graphics-related stuff :-)


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 02/43] drm/rockchip: support prime import sg table

Am Dienstag, 30. Januar 2018, 21:28:32 CET schrieb Thierry Escande:
> From: Haixia Shi 
> 
> The prime fd to handle ioctl was not used with rockchip before. Support
> was added in order to pass graphics_Gbm and to support potential uses
> within Chrome OS (e.g. zero-copy video decode, camera).
> 
> Signed-off-by: Haixia Shi 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Tested-by: Heiko Stuebner 

applied to drm-misc


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 01/43] drm/rockchip: Get rid of unnecessary struct fields

Am Dienstag, 30. Januar 2018, 21:28:31 CET schrieb Thierry Escande:
> From: Tomasz Figa 
> 
> This patch removes unused fields from vop structure.
> 
> Signed-off-by: Tomasz Figa 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 

applied to drm-misc


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103769] Unity based games do not start

https://bugs.freedesktop.org/show_bug.cgi?id=103769

--- Comment #12 from letha...@gmail.com ---
bug still present with versions:
mesa-filesystem-18.1.0-0.2.gita5053ba.fc27.x86_64
llvm-libs-7.0.0-0.1.r323994.fc27.x86_64
clang-7.0.0-0.1.r324055.fc27.x86_64

always segfaulting.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/rockchip: dsi: Remove unnecessary platform_get_resource() error check

Am Montag, 18. Dezember 2017, 14:02:26 CET schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> devm_ioremap_resource() already checks if the resource is NULL, so
> remove the unnecessary platform_get_resource() error check.
> 
> Cc: Heiko Stübner 
> Signed-off-by: Fabio Estevam 

applied to drm-misc


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/7] drm/rockchip: inno_hdmi: Remove unnecessary platform_get_resource() error check

Am Montag, 18. Dezember 2017, 14:02:27 CET schrieb Fabio Estevam:
> From: Fabio Estevam 
> 
> devm_ioremap_resource() already checks if the resource is NULL, so
> remove the unnecessary platform_get_resource() error check.
> 
> Cc: Heiko Stübner 
> Signed-off-by: Fabio Estevam 

applied to drm-misc


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/rockchip: Add device links for master and components

Hi,

Am Mittwoch, 7. Februar 2018, 18:53:09 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen 
> 
> Since we are trying to access components' resources in the master's
> suspend/resume PM callbacks(e.g. panel), add device links to correct
> the suspend/resume and shutdown ordering.
> 
> Signed-off-by: Jeffy Chen 
> Signed-off-by: Enric Balletbo i Serra 

looks good to me right now. So if anybody else wants to apply it,
Reviewed-by: Heiko Stuebner 

@Sean: does this address the issue you saw with the previous version?
It looks like it, but I'd like to make sure before I apply it to drm-misc
myself :-)


Thanks
Heiko

> ---
> Hi,
> 
> This is an attempt to revive a patch [1] that was sent last October. Sean
> Paul requested some changes but I think that never was send a v5 version.
> The patch fixes and issue where backlight panel is not correctly recoved
> after a resume. This was tested on top of current linux-next plus the
> latest series of Thierry's patches [2]
> 
> [1] https://patchwork.kernel.org/patch/10011595/
> [2] https://lkml.org/lkml/2018/1/30/621
> 
> Changes in v5:
> Address the comments from Sean.
> - Create a helper to do the cleanup.
> - Call the helper in rockchip_drm_match_add and where needed.
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> Use device link to correct the suspend/resume and shutdown ordering,
> instead of converting rockchip spi's suspend/resume PM callbacks to
> late suspend/resume PM callbacks.
> 
> Thanks,
>  Enric
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 0609113d6a71..f814d37b1db2 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -314,6 +314,14 @@ static int compare_dev(struct device *dev, void *data)
>   return dev == (struct device *)data;
>  }
>  
> +static void rockchip_drm_match_remove(struct device *dev)
> +{
> + struct device_link *link;
> +
> + list_for_each_entry(link, >links.consumers, s_node)
> + device_link_del(link);
> +}
> +
>  static struct component_match *rockchip_drm_match_add(struct device *dev)
>  {
>   struct component_match *match = NULL;
> @@ -331,10 +339,15 @@ static struct component_match 
> *rockchip_drm_match_add(struct device *dev)
>  
>   if (!d)
>   break;
> +
> + device_link_add(dev, d, DL_FLAG_STATELESS);
>   component_match_add(dev, , compare_dev, d);
>   } while (true);
>   }
>  
> + if (IS_ERR(match))
> + rockchip_drm_match_remove(dev);
> +
>   return match ?: ERR_PTR(-ENODEV);
>  }
>  
> @@ -411,13 +424,21 @@ static int rockchip_drm_platform_probe(struct 
> platform_device *pdev)
>   if (IS_ERR(match))
>   return PTR_ERR(match);
>  
> - return component_master_add_with_match(dev, _drm_ops, match);
> + ret = component_master_add_with_match(dev, _drm_ops, match);
> + if (ret < 0) {
> + rockchip_drm_match_remove(dev);
> + return ret;
> + }
> +
> + return 0;
>  }
>  
>  static int rockchip_drm_platform_remove(struct platform_device *pdev)
>  {
>   component_master_del(>dev, _drm_ops);
>  
> + rockchip_drm_match_remove(>dev);
> +
>   return 0;
>  }
>  
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105042] [LLVM Regression] Shadow of Mordor stucks at intro video

https://bugs.freedesktop.org/show_bug.cgi?id=105042

--- Comment #5 from Gregor Münch  ---
The crash with nir in the beginning is gone. It has now exactly the same
behavior and freezes right after the intro video is finished (or you press a
button to skip).
I think this bug is the same like the one Andy already created. So I wait till
a fix appears and retest again. Unlike someone has a link to a arch LLVM git
package...

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/nouveau: Runtime suspend despite HDA being unbound

Commit 5addcf0a5f0f ("nouveau: add runtime PM support (v0.9)") prevents
runtime suspend of the GPU if its integrated HDA controller is not bound
to a driver.  The rationale appears to be that probing the HDA fails if
the GPU is in D3cold.

However we now use a device link to ensure that the GPU is runtime
resumed while the HDA controller is probed, rendering this safety
measure obsolete.  Remove it.

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Takashi Iwai 
Cc: Peter Wu 
Cc: Alex Deucher 
Cc: Rafael J. Wysocki 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 44 ---
 drivers/gpu/drm/nouveau/nouveau_drv.h |  1 -
 2 files changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 6959951d45d6..bbbf353682e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -510,37 +510,6 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
return 0;
 }
 
-#define PCI_CLASS_MULTIMEDIA_HD_AUDIO 0x0403
-
-static void
-nouveau_get_hdmi_dev(struct nouveau_drm *drm)
-{
-   struct pci_dev *pdev = drm->dev->pdev;
-
-   if (!pdev) {
-   NV_DEBUG(drm, "not a PCI device; no HDMI\n");
-   drm->hdmi_device = NULL;
-   return;
-   }
-
-   /* subfunction one is a hdmi audio device? */
-   drm->hdmi_device = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus),
-   (unsigned int)pdev->bus->number,
-   
PCI_DEVFN(PCI_SLOT(pdev->devfn), 1));
-
-   if (!drm->hdmi_device) {
-   NV_DEBUG(drm, "hdmi device not found %d %d %d\n", 
pdev->bus->number, PCI_SLOT(pdev->devfn), 1);
-   return;
-   }
-
-   if ((drm->hdmi_device->class >> 8) != PCI_CLASS_MULTIMEDIA_HD_AUDIO) {
-   NV_DEBUG(drm, "possible hdmi device not audio %d\n", 
drm->hdmi_device->class);
-   pci_dev_put(drm->hdmi_device);
-   drm->hdmi_device = NULL;
-   return;
-   }
-}
-
 static int
 nouveau_drm_load(struct drm_device *dev, unsigned long flags)
 {
@@ -568,8 +537,6 @@ nouveau_drm_load(struct drm_device *dev, unsigned long 
flags)
INIT_LIST_HEAD(>clients);
spin_lock_init(>tile.lock);
 
-   nouveau_get_hdmi_dev(drm);
-
/* workaround an odd issue on nvc1 by disabling the device's
 * nosnoop capability.  hopefully won't cause issues until a
 * better fix is found - assuming there is one...
@@ -655,8 +622,6 @@ nouveau_drm_unload(struct drm_device *dev)
nouveau_ttm_fini(drm);
nouveau_vga_fini(drm);
 
-   if (drm->hdmi_device)
-   pci_dev_put(drm->hdmi_device);
nouveau_cli_fini(>client);
nouveau_cli_fini(>master);
kfree(drm);
@@ -911,15 +876,6 @@ nouveau_pmops_runtime_idle(struct device *dev)
return -EBUSY;
}
 
-   /* if we have a hdmi audio device - make sure it has a driver loaded */
-   if (drm->hdmi_device) {
-   if (!drm->hdmi_device->driver) {
-   DRM_DEBUG_DRIVER("failing to power off - no HDMI audio 
driver loaded\n");
-   pm_runtime_mark_last_busy(dev);
-   return -EBUSY;
-   }
-   }
-
list_for_each_entry(crtc, >dev->mode_config.crtc_list, head) {
if (crtc->enabled) {
DRM_DEBUG_DRIVER("failing to power off - crtc 
active\n");
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 96f6bd8aee5d..881b44b89a01 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -208,7 +208,6 @@ struct nouveau_drm {
bool have_disp_power_ref;
 
struct dev_pm_domain vga_pm_domain;
-   struct pci_dev *hdmi_device;
 };
 
 static inline struct nouveau_drm *
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] vga_switcheroo: Use device link for HDA controller

Back in 2013, runtime PM for GPUs with integrated HDA controller was
introduced with commits 0d69704ae348 ("gpu/vga_switcheroo: add driver
control power feature. (v3)") and 246efa4a072f ("snd/hda: add runtime
suspend/resume on optimus support (v4)").

Briefly, the idea was that the HDA controller is forced on and off in
unison with the GPU.

The original code is mostly still in place even though it was never a
100% perfect solution:  E.g. on access to the HDA controller, the GPU
is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there
are no provisions to keep it resumed until access to the HDA controller
has ceased:  The GPU autosuspends after 5 seconds, rendering the HDA
controller inaccessible.

Additionally, a kludge is required when hda_intel.c probes:  It has to
check whether the GPU is powered down (check_hdmi_disabled()) and defer
probing if so.

However in the meantime (in v4.10) the driver core has gained a feature
called device links which promises to solve such issues in a clean way:
It allows us to declare a dependency from the HDA controller (consumer)
to the GPU (supplier).  The PM core then automagically ensures that the
GPU is runtime resumed as long as the HDA controller's ->probe hook is
executed and whenever the HDA controller is accessed.

By default, the HDA controller has a dependency on its parent, a PCIe
Root Port.  Adding a device link creates another dependency on its
sibling:

PCIe Root Port
 ^  ^
 |  |
 |  |
HDA  ===>  GPU

The device link is not only used for runtime PM, it also guarantees that
on system sleep, the HDA controller suspends before the GPU and resumes
after the GPU, and on system shutdown the HDA controller's ->shutdown
hook is executed before the one of the GPU.  It is a complete solution.

Using this functionality is as simple as calling device_link_add(),
which results in a dmesg entry like this:

pci :01:00.1: Linked as a consumer to :01:00.0

The code for the GPU-governed audio power management can thus be removed
(except where it's still needed for legacy manual power control).

The device link is added in a PCI quirk rather than in hda_intel.c.
It is therefore legal for the GPU to runtime suspend to D3cold even if
the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
is not enabled, for accesses to the HDA controller will cause the GPU to
wake up regardless if they're occurring outside of hda_intel.c (think
config space readout via sysfs).

Contrary to the previous implementation, the HDA controller's power
state is now self-governed, rather than GPU-governed, whereas the GPU's
power state is no longer fully self-governed.  (The HDA controller needs
to runtime suspend before the GPU can.)

It is thus crucial that runtime PM is always activated on the HDA
controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which
is the default), lest the GPU stays awake.  This is achieved by setting
the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME
flag on the HDA controller.

A side effect is that power consumption might be reduced if the GPU is
in use but the HDA controller is not, because the HDA controller is now
allowed to go to D3hot.  Before, it was forced to stay in D0 as long as
the GPU was in use.  (There is no reduction in power consumption on my
Nvidia GK107, but there might be on other chips.)

The code paths for legacy manual power control are adjusted such that
runtime PM is disabled during power off, thereby preventing the PM core
from resuming the HDA controller.

Note that the device link is not only added on vga_switcheroo capable
systems, but for *any* GPU with integrated HDA controller.  The idea is
that the HDA controller streams audio via connectors located on the GPU,
so the GPU needs to be on for the HDA controller to do anything useful.

This commit implicitly fixes an unbalanced runtime PM ref upon unbind of
hda_intel.c:  On ->probe, a runtime PM ref was previously released under
the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but
on ->remove a runtime PM ref was only acquired under the first of those
conditions.  Thus, binding and unbinding the driver twice on a
vga_switcheroo capable system caused the runtime PM refcount to drop
below zero.  The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
is now always set if use_vga_switcheroo is true.

For more information on device links please refer to:
https://www.kernel.org/doc/html/latest/driver-api/device_link.html
Documentation/driver-api/device_link.rst

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Takashi Iwai 
Cc: Peter Wu 
Cc: Alex Deucher 
Cc: Bjorn Helgaas 
Cc: Rafael J. Wysocki

[PATCH 6/7] vga_switcheroo: Let HDA autosuspend on mux change

When switching the display on muxed machines, we currently force the HDA
controller into runtime suspend on the previously used GPU and into
runtime active state on the newly used GPU.

That's unnecessary if the GPU uses driver power control, we can just let
the audio device autosuspend or autoresume as it sees fit.

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Takashi Iwai 
Cc: Peter Wu 
Cc: Alex Deucher 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 4ee0ed642386..fc4adf3d34e8 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -686,7 +686,9 @@ static int vga_switchto_stage2(struct vga_switcheroo_client 
*new_client)
 
active->active = false;
 
-   set_audio_state(active->id, VGA_SWITCHEROO_OFF);
+   /* let HDA controller autosuspend if GPU uses driver power control */
+   if (!active->driver_power_control)
+   set_audio_state(active->id, VGA_SWITCHEROO_OFF);
 
if (new_client->fb_info) {
struct fb_event event;
@@ -709,7 +711,9 @@ static int vga_switchto_stage2(struct vga_switcheroo_client 
*new_client)
if (vga_switcheroo_pwr_state(active) == VGA_SWITCHEROO_ON)
vga_switchoff(active);
 
-   set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
+   /* let HDA controller autoresume if GPU uses driver power control */
+   if (!new_client->driver_power_control)
+   set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
 
new_client->active = true;
return 0;
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] vga_switcheroo: Deduplicate power state tracking

If DRM drivers use runtime PM, they currently notify vga_switcheroo
whenever they ->runtime_suspend or ->runtime_resume to update
vga_switcheroo's internal power state tracking.

That's essentially a duplication of a functionality performed by the
PM core as it already tracks the GPU's power state and vga_switcheroo
can always query it.

Introduce a new internal helper vga_switcheroo_pwr_state() which does
just that if runtime PM is used, or falls back to vga_switcheroo's
internal power state tracking if manual power control is used.
Drop a redundant power state check in set_audio_state() while at it.

This removes one of the two purposes of the notification mechanism
implemented by vga_switcheroo_set_dynamic_switch().  The other one is
power management of the audio device and we'll remove that next.

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Takashi Iwai 
Cc: Peter Wu 
Cc: Alex Deucher 
Cc: Rafael J. Wysocki 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 09dd40dd1dbe..2488af797020 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -92,7 +92,8 @@
  * struct vga_switcheroo_client - registered client
  * @pdev: client pci device
  * @fb_info: framebuffer to which console is remapped on switching
- * @pwr_state: current power state
+ * @pwr_state: current power state if manual power control is used.
+ * For driver power control, call vga_switcheroo_pwr_state().
  * @ops: client callbacks
  * @id: client identifier. Determining the id requires the handler,
  * so gpus are initially assigned VGA_SWITCHEROO_UNKNOWN_ID
@@ -406,6 +407,19 @@ bool vga_switcheroo_client_probe_defer(struct pci_dev 
*pdev)
 }
 EXPORT_SYMBOL(vga_switcheroo_client_probe_defer);
 
+static enum vga_switcheroo_state
+vga_switcheroo_pwr_state(struct vga_switcheroo_client *client)
+{
+   if (client->driver_power_control)
+   if (pm_runtime_enabled(>pdev->dev) &&
+   pm_runtime_active(>pdev->dev))
+   return VGA_SWITCHEROO_ON;
+   else
+   return VGA_SWITCHEROO_OFF;
+   else
+   return client->pwr_state;
+}
+
 /**
  * vga_switcheroo_get_client_state() - obtain power state of a given client
  * @pdev: client pci device
@@ -425,7 +439,7 @@ enum vga_switcheroo_state 
vga_switcheroo_get_client_state(struct pci_dev *pdev)
if (!client)
ret = VGA_SWITCHEROO_NOT_FOUND;
else
-   ret = client->pwr_state;
+   ret = vga_switcheroo_pwr_state(client);
mutex_unlock(_mutex);
return ret;
 }
@@ -598,7 +612,7 @@ static int vga_switcheroo_show(struct seq_file *m, void *v)
   client_is_vga(client) ? "" : "-Audio",
   client->active ? '+' : ' ',
   client->driver_power_control ? "Dyn" : "",
-  client->pwr_state ? "Pwr" : "Off",
+  vga_switcheroo_pwr_state(client) ? "Pwr" : "Off",
   pci_name(client->pdev));
i++;
}
@@ -641,7 +655,7 @@ static void set_audio_state(enum vga_switcheroo_client_id 
id,
struct vga_switcheroo_client *client;
 
client = find_client_from_id(_priv.clients, id | ID_BIT_AUDIO);
-   if (client && client->pwr_state != state) {
+   if (client) {
client->ops->set_gpu_state(client->pdev, state);
client->pwr_state = state;
}
@@ -656,7 +670,7 @@ static int vga_switchto_stage1(struct vga_switcheroo_client 
*new_client)
if (!active)
return 0;
 
-   if (new_client->pwr_state == VGA_SWITCHEROO_OFF)
+   if (vga_switcheroo_pwr_state(new_client) == VGA_SWITCHEROO_OFF)
vga_switchon(new_client);
 
vga_set_default_device(new_client->pdev);
@@ -695,7 +709,7 @@ static int vga_switchto_stage2(struct vga_switcheroo_client 
*new_client)
if (new_client->ops->reprobe)
new_client->ops->reprobe(new_client->pdev);
 
-   if (active->pwr_state == VGA_SWITCHEROO_ON)
+   if (vga_switcheroo_pwr_state(active) == VGA_SWITCHEROO_ON)
vga_switchoff(active);
 
set_audio_state(new_client->id, VGA_SWITCHEROO_ON);
@@ -940,8 +954,7 @@ EXPORT_SYMBOL(vga_switcheroo_process_delayed_switch);
  * command line disables it.
  *
  * When the driver decides to power up or down, it notifies vga_switcheroo
- * thereof so that it can (a) power the audio device on the GPU up or down,
- * and (b) update its internal power state representation for the device.
+ * thereof so that it can power the audio device on

[PATCH 3/7] vga_switcheroo: Update PCI current_state on power change

When cutting power to a GPU and its integrated HDA controller, their
cached current_state should be updated to D3cold to reflect reality.

We currently rely on the DRM and HDA drivers to do that, however:

- The HDA driver updates the current_state in azx_vs_set_state(), which
  will no longer be called with driver power control once we migrate to
  device links.  (It will still be called with manual power control.)

- If the HDA device is not bound, its current_state remains at D0 even
  though the GPU driver may decide to go to D3cold.

- The DRM drivers update the current_state using pci_set_power_state()
  which can't put the device into a deeper power state than D3hot if the
  GPU is not deemed power-manageable by the platform (even though it
  *is* power-manageable by some nonstandard means, such as a _DSM).

Centralize updating the current_state of the GPU and HDA controller in
vga_switcheroo's ->runtime_suspend hook to overcome these deficiencies.

The GPU and HDA controller are two functions of the same PCI device
(VGA class device on function 0 and audio device on function 1) and
no other PCI devices reside on the same bus since this is a PCIe
point-to-point link, so we can just walk the bus and update the
current_state of all devices.

On ->runtime_resume, the HDA controller is in D0uninitialized state.
Resume to D0active and then let it autosuspend as it sees fit.

Note that vga_switcheroo_init_domain_pm_ops() is not supposed to be
called by hybrid graphics laptops which power down the GPU via its root
port's _PR3 resources and consequently vga_switcheroo_runtime_suspend()
is not used.  On those laptops, the root port is power-manageable by the
platform (instead of by a nonstandard means) and the current_state is
therefore updated by the PCI core through the following call chain:

  pci_set_power_state()
__pci_complete_power_transition()
  pci_bus_set_current_state()

Resuming to D0active happens through:

  pci_set_power_state()
__pci_start_power_transition()
  pci_wakeup_bus()

Cc: Dave Airlie 
Cc: Ben Skeggs 
Cc: Takashi Iwai 
Cc: Peter Wu 
Cc: Alex Deucher 
Cc: Bjorn Helgaas 
Cc: Rafael J. Wysocki 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 3cd153c6d271..09dd40dd1dbe 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -1022,6 +1022,7 @@ static int vga_switcheroo_runtime_suspend(struct device 
*dev)
vgasr_priv.handler->switchto(VGA_SWITCHEROO_IGD);
mutex_unlock(_priv.mux_hw_lock);
}
+   pci_bus_set_current_state(pdev->bus, PCI_D3cold);
vga_switcheroo_power_switch(pdev, VGA_SWITCHEROO_OFF);
mutex_unlock(_mutex);
return 0;
@@ -1035,6 +1036,7 @@ static int vga_switcheroo_runtime_resume(struct device 
*dev)
mutex_lock(_mutex);
vga_switcheroo_power_switch(pdev, VGA_SWITCHEROO_ON);
mutex_unlock(_mutex);
+   pci_wakeup_bus(pdev->bus);
ret = dev->bus->pm->runtime_resume(dev);
if (ret)
return ret;
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] PCI: Restore BARs on runtime resume despite being unbound

PCI devices not bound to a driver are supposed to stay in D0 during
runtime suspend.  But they may have a parent which is bound and can be
transitioned to D3cold at runtime.  Once the parent goes to D3cold, the
unbound child may go to D3cold as well.  When the child comes out of
D3cold, its BARs are uninitialized and thus inaccessible when a driver
tries to probe.

One example are recent hybrid graphics laptops which cut power to the
discrete GPU when the root port above it goes to ACPI power state D3.
Users may provoke this by unbinding the GPU driver and allowing runtime
PM on the GPU via sysfs:  The PM core will then treat the GPU as
"suspended", which in turn allows the root port to runtime suspend,
causing the power resources listed in its _PR3 object to be powered off.
The GPU's BARs will be uninitialized when a driver later probes it.

Another example are hybrid graphics laptops where the GPU itself (rather
than the root port) is capable of runtime suspending to D3cold.  If the
GPU's integrated HDA controller is not bound and the GPU's driver
decides to runtime suspend to D3cold, the HDA controller's BARs will be
uninitialized when a driver later probes it.

Fix by restoring the BARs on runtime resume if the device is not bound.
This is sufficient to fix the above-mentioned use cases.  Other use
cases might require a full-blown pci_save_state() / pci_restore_state()
or execution of fixups.  We can add that once use cases materialize,
let's not inflate the code unnecessarily.

Cc: Bjorn Helgaas 
Cc: Rafael J. Wysocki 
Signed-off-by: Lukas Wunner 
---
 drivers/pci/pci-driver.c | 8 ++--
 drivers/pci/pci.c| 2 +-
 drivers/pci/pci.h| 1 +
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 3bed6beda051..51b11cbd48f6 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1277,10 +1277,14 @@ static int pci_pm_runtime_resume(struct device *dev)
 
/*
 * If pci_dev->driver is not set (unbound), the device should
-* always remain in D0 regardless of the runtime PM status
+* always remain in D0 regardless of the runtime PM status.
+* But if its parent can go to D3cold, this device may have
+* been in D3cold as well and require restoration of its BARs.
 */
-   if (!pci_dev->driver)
+   if (!pci_dev->driver) {
+   pci_restore_bars(pci_dev);
return 0;
+   }
 
if (!pm || !pm->runtime_resume)
return -ENOSYS;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..f694650235f2 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -563,7 +563,7 @@ int pci_wait_for_pending(struct pci_dev *dev, int pos, u16 
mask)
  * Restore the BAR values for a given device, so as to make it
  * accessible by its driver.
  */
-static void pci_restore_bars(struct pci_dev *dev)
+void pci_restore_bars(struct pci_dev *dev)
 {
int i;
 
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index fcd81911b127..29dc15bbe3bf 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -83,6 +83,7 @@ void pci_allocate_cap_save_buffers(struct pci_dev *dev);
 void pci_free_cap_save_buffers(struct pci_dev *dev);
 bool pci_bridge_d3_possible(struct pci_dev *dev);
 void pci_bridge_d3_update(struct pci_dev *dev);
+void pci_restore_bars(struct pci_dev *dev);
 
 static inline void pci_wakeup_event(struct pci_dev *dev)
 {
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public

There are PCI devices which are power-manageable by a nonstandard means,
such as a custom ACPI method.  One example are discrete GPUs in hybrid
graphics laptops, another are Thunderbolt controllers in Macs.

Such devices can't be put into D3cold with pci_set_power_state() because
pci_platform_power_transition() fails with -ENODEV.  Instead they're put
into D3hot by pci_set_power_state() and subsequently into D3cold by
invoking the nonstandard means.  However as a consequence the cached
current_state is incorrectly left at D3hot.

What we need to do is walk the hierarchy below such a PCI device on
powerdown and update the current_state to D3cold.  On powerup the PCI
device itself and the hierarchy below it is in D0uninitialized, so we
need to walk the hierarchy again and wake all devices, causing them to
be put into D0active and then letting them autosuspend as they see fit.

To this end make pci_wakeup_bus() & pci_bus_set_current_state() public
so PCI drivers don't have to reinvent the wheel.

Cc: Bjorn Helgaas 
Cc: Rafael J. Wysocki 
Signed-off-by: Lukas Wunner 
---
 drivers/pci/pci.c   | 8 
 include/linux/pci.h | 2 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f694650235f2..6e6e322a5a7d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -800,7 +800,7 @@ static int pci_wakeup(struct pci_dev *pci_dev, void *ign)
  * pci_wakeup_bus - Walk given bus and wake up devices on it
  * @bus: Top bus of the subtree to walk.
  */
-static void pci_wakeup_bus(struct pci_bus *bus)
+void pci_wakeup_bus(struct pci_bus *bus)
 {
if (bus)
pci_walk_bus(bus, pci_wakeup, NULL);
@@ -850,11 +850,11 @@ static int __pci_dev_set_current_state(struct pci_dev 
*dev, void *data)
 }
 
 /**
- * __pci_bus_set_current_state - Walk given bus and set current state of 
devices
+ * pci_bus_set_current_state - Walk given bus and set current state of devices
  * @bus: Top bus of the subtree to walk.
  * @state: state to be set
  */
-static void __pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state)
+void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state)
 {
if (bus)
pci_walk_bus(bus, __pci_dev_set_current_state, );
@@ -876,7 +876,7 @@ int __pci_complete_power_transition(struct pci_dev *dev, 
pci_power_t state)
ret = pci_platform_power_transition(dev, state);
/* Power off the bridge may power off the whole hierarchy */
if (!ret && state == PCI_D3cold)
-   __pci_bus_set_current_state(dev->subordinate, PCI_D3cold);
+   pci_bus_set_current_state(dev->subordinate, PCI_D3cold);
return ret;
 }
 EXPORT_SYMBOL_GPL(__pci_complete_power_transition);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 024a1beda008..ae42289662df 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1147,6 +1147,8 @@ void pci_pme_wakeup_bus(struct pci_bus *bus);
 void pci_d3cold_enable(struct pci_dev *dev);
 void pci_d3cold_disable(struct pci_dev *dev);
 bool pcie_relaxed_ordering_enabled(struct pci_dev *dev);
+void pci_wakeup_bus(struct pci_bus *bus);
+void pci_bus_set_current_state(struct pci_bus *bus, pci_power_t state);
 
 /* PCI Virtual Channel */
 int pci_save_vc_state(struct pci_dev *dev);
-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] Modernize vga_switcheroo by using device link for HDA

Modernize vga_switcheroo by using a "device link" to enforce a runtime PM
dependency from an HDA controller to the GPU it's integrated into.
Remove thereby obsoleted code and fix a bunch of bugs.
Device links were introduced in v4.10.

Users might see a small power saving if the discrete GPU is in use and
its HDA controller is not, because the HDA controller is now allowed
to runtime suspend to D3hot.  Probing and accessing the HDA controller
while the GPU is in D3cold should be very robust, unlike before.
Under the hood things become quite a bit leaner.

Also, this series gets us one step closer to supporting runtime PM on
muxed laptops such as the MacBook Pro because it fixes a deadlock
occurring when runtime resuming the discrete GPU on switching the mux.
(The deadlock occurs in vga_switcheroo_set_dynamic_switch() and that
function is obsoleted and removed by this series.)

The meat of the series is in patch [5/7], read its commit message for
details.  The other patches contain prep and cleanup work.

Patches [1/7], [2/7] and [5/7] require an ack from Bjorn (and Rafael?),
patch [5/7] requires an ack from Takashi.
Additionally I'd appreciate a Tested-by and/or Acked-by from Peter Wu,
the resident Nvidia Optimus expert, and from Alex for AMD PowerXpress
because my own testing only covers the MacBook Pro.
Testing and comments from anyone else are most welcome of course.

The series is based on 4.16-rc1.  To test it on 4.15, you need to
cherry-pick 7506dc798993 and 2fa6d6cdaf28.  For your convenience
I've pushed a 4.15-based branch to:
https://github.com/l1k/linux/commits/switcheroo_devlink_v1

Minimal test procedure for non-Macs:

- Note well: Recent Optimus require that a Mini-DP or HDMI cable is
  plugged in on boot for the HDA device to be present.

- Check that HDA, GPU and root port autosuspend when not in use:
  cat /sys/bus/pci/devices/:01:00.1/power/runtime_status  # HDA
  cat /sys/bus/pci/devices/:01:00.0/power/runtime_status  # GPU
  cat /sys/bus/pci/devices/:00:01.0/power/runtime_status  # Root Port

- Check that all three autoresume when accessing the HDA:
  hdajacksensetest -c 1

- Unbind the HDA controller:
  echo :01:00.1 > /sys/bus/pci/drivers/snd_hda_intel/unbind
  Wait for GPU to power off, then rebind the HDA controller:
  echo :01:00.1 > /sys/bus/pci/drivers/snd_hda_intel/bind
  Check dmesg for errors, try accessing HDA with hdajacksensetest.

- If your laptop uses the root port's _PR3 to cut power to the GPU:
  Unbind the GPU:
  echo :01:00.0 > /sys/bus/pci/drivers/{nouveau,amdgpu,radeon}/unbind
  Allow runtime PM on the GPU:
  echo auto > /sys/bus/pci/devices/:01:00.0/power/control
  Wait for GPU to power off, then rebind it:
  echo :01:00.0 > /sys/bus/pci/drivers/{nouveau,amdgpu,radeon}/bind
  Check dmesg for errors.  If you see any then we may need to perform
  further actions in pci_pm_runtime_resume(), see patch [1/7].

Thanks,

Lukas

Lukas Wunner (7):
  PCI: Restore BARs on runtime resume despite being unbound
  PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public
  vga_switcheroo: Update PCI current_state on power change
  vga_switcheroo: Deduplicate power state tracking
  vga_switcheroo: Use device link for HDA controller
  vga_switcheroo: Let HDA autosuspend on mux change
  drm/nouveau: Runtime suspend despite HDA being unbound

 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |   2 -
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  46 --
 drivers/gpu/drm/nouveau/nouveau_drv.h   |   1 -
 drivers/gpu/drm/radeon/radeon_drv.c |   2 -
 drivers/gpu/vga/vga_switcheroo.c| 152 
 drivers/pci/pci-driver.c|   8 +-
 drivers/pci/pci.c   |  10 +--
 drivers/pci/pci.h   |   1 +
 drivers/pci/quirks.c|  39 
 include/linux/pci.h |   2 +
 include/linux/pci_ids.h |   1 +
 include/linux/vga_switcheroo.h  |   6 --
 include/sound/hdaudio.h |   3 -
 sound/pci/hda/hda_intel.c   |  36 +---
 sound/pci/hda/hda_intel.h   |   3 -
 15 files changed, 114 insertions(+), 198 deletions(-)

-- 
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically