date:20180220

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

2018-02-20 Thread Bjorn Helgaas

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> 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).

I guess this GPU wakeup happens *if* the path accessing the HDA
controller calls pm_runtime_get_sync() or similar, right?  We do have
that in the sysfs config accessors via pci_config_pm_runtime_get(),
but not in the sysfs mmap paths.  I think that's a latent PCI core
defect independent of this series.

We also don't have that in PCI core config accessors.  That maybe
doesn't matter because the core probably shouldn't be touching devices
after enumeration (although there might be holes there for things like
ASPM where a sysfs file can cause reconfiguration of several devices).

> 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

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

2018-02-20 Thread Bjorn Helgaas

On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> PCI devices not bound to a driver are supposed to stay in D0 during
> runtime suspend.

Doesn't "runtime suspend" mean an individual device is suspended while
the rest of the system remains active?

If so, maybe it would be more direct to say "PCI devices not bound to
a driver cannot be runtime suspended"?

(It's a separate question not relevant to this patch, but I'm not
convinced that "PCI devices without a driver cannot be suspended"
should be accepted as a rule.  If it is a rule, we should be able to
deduce it from the specs.)

> 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.

Why would we not do a full-blown restore?  With this patch, I think
some configuration done during enumeration, e.g., ASPM and MPS, will
be lost.  "lspci -vv" of the HDA before and after the suspend may show
different things, which seems counter-intuitive.

I wouldn't think of a full-blown restore as "inflating the code"; I
would think of it as "having fewer special cases", i.e., we always use
the same restore path instead of having the main one plus a special
one for unbound devices.

> 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);

If we do decide not to do a full-blown restore, how do we decide
whether to use pci_restore_bars() or pci_restore_config_space()?

I'm not sure why we have both.  The pci_restore_bars() path looks a
little smarter in that it is more careful when updating 64-bit BARs
that can't be updated atomically.

>   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)
>  {
> -- 
>

[Nouveau] [Bug 105174] [GF108][Regression] Unable to handle NULL pointer dereference in nouveau_mem_host since kernel 4.15.3

2018-02-20 Thread bugzilla-daemon

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

--- Comment #4 from Dominik 'Rathann' Mierzejewski  ---
It happens on every login. My user display configuration is such that it
switches the HDMI output on and internal LCD off, while the login screen
(lightdm) uses the internal LCD only. Immediately after logging in, I get the
display freeze when it tries to drive the HDMI output. The mouse cursor is
still moving.

Apparently the nternal LCD is driven by i915 directly while the HDMI output
goes via nouveau.

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

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

2018-02-20 Thread kbuild test robot

Hi Ville,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-nouveau-Replace-the-iturbt_709-prop-with-the-standarad-COLOR_ENCODNIG-prop/20180220-230332
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:56:26: error: field 
>> 'color_encoding' has incomplete type
 enum drm_color_encoding color_encoding;
 ^~
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_update_plane':
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:168:34: error: 
>> 'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function)
 if (nv_plane->color_encoding == DRM_COLOR_YCBCR_BT709)
 ^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:168:34: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_set_params':
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:231:32: error: 
'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function)
  if (plane->color_encoding == DRM_COLOR_YCBCR_BT709)
   ^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv_set_property':
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:260:38: error: 'struct drm_plane' 
>> has no member named 'color_encoding_property'; did you mean 
>> 'rotation_property'?
 else if (property == nv_plane->base.color_encoding_property)
 ^~~
 rotation_property
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_overlay_init':
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:342:26: error: 
>> 'DRM_COLOR_YCBCR_BT601' undeclared (first use in this function)
 plane->color_encoding = DRM_COLOR_YCBCR_BT601;
 ^
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:343:2: error: implicit 
>> declaration of function 'drm_plane_create_color_properties'; did you mean 
>> 'drm_plane_create_zpos_property'? [-Werror=implicit-function-declaration]
 drm_plane_create_color_properties(>base,
 ^
 drm_plane_create_zpos_property
   In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/nouveau/dispnv04/overlay.c:26:
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:345:12: error: 
>> 'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function); did you 
>> mean 'DRM_COLOR_YCBCR_BT601'?
   BIT(DRM_COLOR_YCBCR_BT709),
   ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:346:12: error: 
>> 'DRM_COLOR_YCBCR_LIMITED_RANGE' undeclared (first use in this function); did 
>> you mean 'DRM_COLOR_YCBCR_BT709'?
   BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
   ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^~
   cc1: some warnings being treated as errors

vim +/color_encoding +56 drivers/gpu/drm/nouveau/dispnv04/overlay.c

  > 26  #include 
27  #include 
28  #include 
29  
30  #include "nouveau_drv.h"
31  
32  #include "nouveau_bo.h"
33  #include "nouveau_connector.h"
34  #include "nouveau_display.h"
35  #include "nvreg.h"
36  #include "disp.h"
37  
38  struct nouveau_plane {
39  struct drm_plane base;
40  bool flip;
41  struct nouveau_bo *cur;
42  
43  struct {
44  struct drm_property *colorkey;
45  struct drm_property *contrast;
46  struct drm_property *brightness;
47  struct drm_property *hue;
48  struct drm_property *saturation;
49  } props;
50  
51  int colorkey;
52  int contrast;
53  int brightness;
54  int h

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

2018-02-20 Thread kbuild test robot

Hi Ville,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc2 next-20180220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-nouveau-Replace-the-iturbt_709-prop-with-the-standarad-COLOR_ENCODNIG-prop/20180220-230332
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-randconfig-a1-201807 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/nouveau/dispnv04/overlay.c:56:26: error: field 
'color_encoding' has incomplete type
 enum drm_color_encoding color_encoding;
 ^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_update_plane':
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:168:34: error: 
'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function)
 if (nv_plane->color_encoding == DRM_COLOR_YCBCR_BT709)
 ^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:168:34: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_set_params':
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:231:32: error: 
'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function)
  if (plane->color_encoding == DRM_COLOR_YCBCR_BT709)
   ^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv_set_property':
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:260:37: error: 'struct drm_plane' 
>> has no member named 'color_encoding_property'
 else if (property == nv_plane->base.color_encoding_property)
^
   drivers/gpu/drm/nouveau/dispnv04/overlay.c: In function 'nv10_overlay_init':
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:342:26: error: 
'DRM_COLOR_YCBCR_BT601' undeclared (first use in this function)
 plane->color_encoding = DRM_COLOR_YCBCR_BT601;
 ^
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:343:2: error: implicit 
>> declaration of function 'drm_plane_create_color_properties' 
>> [-Werror=implicit-function-declaration]
 drm_plane_create_color_properties(>base,
 ^
   In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from include/linux/agp_backend.h:33,
from include/drm/drmP.h:35,
from drivers/gpu/drm/nouveau/dispnv04/overlay.c:26:
   drivers/gpu/drm/nouveau/dispnv04/overlay.c:345:12: error: 
'DRM_COLOR_YCBCR_BT709' undeclared (first use in this function)
   BIT(DRM_COLOR_YCBCR_BT709),
   ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^
>> drivers/gpu/drm/nouveau/dispnv04/overlay.c:346:12: error: 
>> 'DRM_COLOR_YCBCR_LIMITED_RANGE' undeclared (first use in this function)
   BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
   ^
   include/linux/bitops.h:7:28: note: in definition of macro 'BIT'
#define BIT(nr)   (1UL << (nr))
   ^
   cc1: some warnings being treated as errors

vim +260 drivers/gpu/drm/nouveau/dispnv04/overlay.c

   111  
   112  static int
   113  nv10_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
   114struct drm_framebuffer *fb, int crtc_x, int crtc_y,
   115unsigned int crtc_w, unsigned int crtc_h,
   116uint32_t src_x, uint32_t src_y,
   117uint32_t src_w, uint32_t src_h,
   118struct drm_modeset_acquire_ctx *ctx)
   119  {
   120  struct nouveau_drm *drm = nouveau_drm(plane->dev);
   121  struct nvif_object *dev = >client.device.object;
   122  struct nouveau_plane *nv_plane =
   123  container_of(plane, struct nouveau_plane, base);
   124  struct nouveau_framebuffer *nv_fb = nouveau_framebuffer(fb);
   125  struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
   126  struct nouveau_bo *cur = nv_plane->cur;
   127  bool flip = nv_plane->flip;
   128  int soff = NV_PCRTC0_SIZE * nv_crtc->index;
   129  int soff2 = NV_PCRTC0_SIZE * !nv_crtc->index;
   130  unsigned shift = drm->client.device.info.chipset >= 0x30 ? 1 : 
3;
   131  unsigned format = 0;
   132  int ret;
   133  
   134  /* Source parameters given in 16.16 fixed point, ignore 
fractional. */
   135  src_x >>= 16;
   136  src_y >>= 16;
   137  src_w &g

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

2018-02-20 Thread Ilia Mirkin

On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Replace the ad-hoc iturbt_709 property with the new standard
> COLOR_ENCODING property. Compiles, but not tested.
>
> Cc: Daniel Vetter 
> Cc: nouveau@lists.freedesktop.org
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
> Signed-off-by: Ville Syrjälä 

s/standarad/standard/ in subject

I'd like the opportunity to test this out on real hardware, but I
don't have any pre-NV41 boards plugged in right now. I should be able
to attend to it within 7 days. If you don't hear back from me by then,
I'd appreciate a ping, as I do let things (hopefully occasionally)
slip through.

> ---
>  drivers/gpu/drm/nouveau/dispnv04/overlay.c | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
> b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> index c8c2333f24ee..df4358e31075 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
> @@ -46,7 +46,6 @@ struct nouveau_plane {
> struct drm_property *brightness;
> struct drm_property *hue;
> struct drm_property *saturation;
> -   struct drm_property *iturbt_709;
> } props;
>
> int colorkey;
> @@ -54,7 +53,7 @@ struct nouveau_plane {
> int brightness;
> int hue;
> int saturation;
> -   int iturbt_709;
> +   enum drm_color_encoding color_encoding;
>
> void (*set_params)(struct nouveau_plane *);
>  };
> @@ -166,7 +165,7 @@ nv10_update_plane(struct drm_plane *plane, struct 
> drm_crtc *crtc,
> if (fb->format->format == DRM_FORMAT_NV12 ||
> fb->format->format == DRM_FORMAT_NV21)
> format |= NV_PVIDEO_FORMAT_PLANAR;
> -   if (nv_plane->iturbt_709)
> +   if (nv_plane->color_encoding == DRM_COLOR_YCBCR_BT709)
> format |= NV_PVIDEO_FORMAT_MATRIX_ITURBT709;
> if (nv_plane->colorkey & (1 << 24))
> format |= NV_PVIDEO_FORMAT_DISPLAY_COLOR_KEY;
> @@ -229,7 +228,7 @@ nv10_set_params(struct nouveau_plane *plane)
> nvif_wr32(dev, NV_PVIDEO_COLOR_KEY, plane->colorkey & 0xff);
>
> if (plane->cur) {
> -   if (plane->iturbt_709)
> +   if (plane->color_encoding == DRM_COLOR_YCBCR_BT709)
> format |= NV_PVIDEO_FORMAT_MATRIX_ITURBT709;
> if (plane->colorkey & (1 << 24))
> format |= NV_PVIDEO_FORMAT_DISPLAY_COLOR_KEY;
> @@ -258,8 +257,8 @@ nv_set_property(struct drm_plane *plane,
> nv_plane->hue = value;
> else if (property == nv_plane->props.saturation)
> nv_plane->saturation = value;
> -   else if (property == nv_plane->props.iturbt_709)
> -   nv_plane->iturbt_709 = value;
> +   else if (property == nv_plane->base.color_encoding_property)
> +   nv_plane->color_encoding = value;
> else
> return -EINVAL;
>
> @@ -313,14 +312,11 @@ nv10_overlay_init(struct drm_device *device)
> device, 0, "hue", 0, 359);
> plane->props.saturation = drm_property_create_range(
> device, 0, "saturation", 0, 8192 - 1);
> -   plane->props.iturbt_709 = drm_property_create_range(
> -   device, 0, "iturbt_709", 0, 1);
> if (!plane->props.colorkey ||
> !plane->props.contrast ||
> !plane->props.brightness ||
> !plane->props.hue ||
> -   !plane->props.saturation ||
> -   !plane->props.iturbt_709)
> +   !plane->props.saturation)
> goto cleanup;
>
> plane->colorkey = 0;
> @@ -343,9 +339,13 @@ nv10_overlay_init(struct drm_device *device)
> drm_object_attach_property(>base.base,
>plane->props.saturation, 
> plane->saturation);
>
> -   plane->iturbt_709 = 0;
> -   drm_object_attach_property(>base.base,
> -  plane->props.iturbt_709, 
> plane->iturbt_709);
> +   plane->color_encoding = DRM_COLOR_YCBCR_BT601;
> +   drm_plane_create_color_properties(>base,
> + BIT(DRM_COLOR_YCBCR_BT601) |
> + BIT(DRM_COLOR_YCBCR_BT709),
> + BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
> + DRM_COLOR_YCBCR_BT601,
> + DRM_COLOR_YCBCR_LIMITED_RANGE);
>
> plane->set_params = nv10_set_params;
> nv10_set_params(plane);
> --
> 2.13.6
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org

[Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

2018-02-20 Thread Ville Syrjala

From: Ville Syrjälä 

Replace the ad-hoc iturbt_709 property with the new standard
COLOR_ENCODING property. Compiles, but not tested.

Cc: Daniel Vetter 
Cc: nouveau@lists.freedesktop.org
Cc: Ben Skeggs 
Cc: Ilia Mirkin 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index c8c2333f24ee..df4358e31075 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -46,7 +46,6 @@ struct nouveau_plane {
struct drm_property *brightness;
struct drm_property *hue;
struct drm_property *saturation;
-   struct drm_property *iturbt_709;
} props;
 
int colorkey;
@@ -54,7 +53,7 @@ struct nouveau_plane {
int brightness;
int hue;
int saturation;
-   int iturbt_709;
+   enum drm_color_encoding color_encoding;
 
void (*set_params)(struct nouveau_plane *);
 };
@@ -166,7 +165,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
if (fb->format->format == DRM_FORMAT_NV12 ||
fb->format->format == DRM_FORMAT_NV21)
format |= NV_PVIDEO_FORMAT_PLANAR;
-   if (nv_plane->iturbt_709)
+   if (nv_plane->color_encoding == DRM_COLOR_YCBCR_BT709)
format |= NV_PVIDEO_FORMAT_MATRIX_ITURBT709;
if (nv_plane->colorkey & (1 << 24))
format |= NV_PVIDEO_FORMAT_DISPLAY_COLOR_KEY;
@@ -229,7 +228,7 @@ nv10_set_params(struct nouveau_plane *plane)
nvif_wr32(dev, NV_PVIDEO_COLOR_KEY, plane->colorkey & 0xff);
 
if (plane->cur) {
-   if (plane->iturbt_709)
+   if (plane->color_encoding == DRM_COLOR_YCBCR_BT709)
format |= NV_PVIDEO_FORMAT_MATRIX_ITURBT709;
if (plane->colorkey & (1 << 24))
format |= NV_PVIDEO_FORMAT_DISPLAY_COLOR_KEY;
@@ -258,8 +257,8 @@ nv_set_property(struct drm_plane *plane,
nv_plane->hue = value;
else if (property == nv_plane->props.saturation)
nv_plane->saturation = value;
-   else if (property == nv_plane->props.iturbt_709)
-   nv_plane->iturbt_709 = value;
+   else if (property == nv_plane->base.color_encoding_property)
+   nv_plane->color_encoding = value;
else
return -EINVAL;
 
@@ -313,14 +312,11 @@ nv10_overlay_init(struct drm_device *device)
device, 0, "hue", 0, 359);
plane->props.saturation = drm_property_create_range(
device, 0, "saturation", 0, 8192 - 1);
-   plane->props.iturbt_709 = drm_property_create_range(
-   device, 0, "iturbt_709", 0, 1);
if (!plane->props.colorkey ||
!plane->props.contrast ||
!plane->props.brightness ||
!plane->props.hue ||
-   !plane->props.saturation ||
-   !plane->props.iturbt_709)
+   !plane->props.saturation)
goto cleanup;
 
plane->colorkey = 0;
@@ -343,9 +339,13 @@ nv10_overlay_init(struct drm_device *device)
drm_object_attach_property(>base.base,
   plane->props.saturation, plane->saturation);
 
-   plane->iturbt_709 = 0;
-   drm_object_attach_property(>base.base,
-  plane->props.iturbt_709, plane->iturbt_709);
+   plane->color_encoding = DRM_COLOR_YCBCR_BT601;
+   drm_plane_create_color_properties(>base,
+ BIT(DRM_COLOR_YCBCR_BT601) |
+ BIT(DRM_COLOR_YCBCR_BT709),
+ BIT(DRM_COLOR_YCBCR_LIMITED_RANGE),
+ DRM_COLOR_YCBCR_BT601,
+ DRM_COLOR_YCBCR_LIMITED_RANGE);
 
plane->set_params = nv10_set_params;
nv10_set_params(plane);
-- 
2.13.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 104835] MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

2018-02-20 Thread bugzilla-daemon

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

--- Comment #2 from Tom D  ---
Hardware: Lenovo P50
Symptoms:
This problem did not happen until I dist-upgraded from Fedora 26 to 27.

If the laptop is connected to the dock during boot, I get the logs below and
nothing further. I cannot shift desktops, log in, etc. Due to the
configuration, I cannot remotely SSH in without changing the FW after logging
in so I'm unsure about that behavior.

If I boot the system off of the doc and then place it into the doc before
logging in as a user, all seems to work well. I can then remove and re-seat the
laptop without issue.

If I boot the system, log in and then place it on the doc, sometimes (I do not
understand the pattern), the second screen attached to the dock is not seen at
all (does not show under displays). 

Same symptoms on numerous docs. 

I am concerned that the nouveau errors seen are unrelated to the actual
problems encountered.

Log snip
[2.425868] nouveau :01:00.0: bus: MMIO read of  FAULT at 022554
[ IBUS ]
[2.427462] nouveau :01:00.0: bus: MMIO read of  FAULT at 10ac08
[ IBUS ]

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

[Nouveau] [Bug 104835] MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

2018-02-20 Thread bugzilla-daemon

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

--- Comment #1 from Tom D  ---
Created attachment 137467
  --> https://bugs.freedesktop.org/attachment.cgi?id=137467=edit
dmesg

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

[Nouveau] [Bug 105174] [GF108][Regression] Unable to handle NULL pointer dereference in nouveau_mem_host since kernel 4.15.3

2018-02-20 Thread bugzilla-daemon

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

Pierre Moreau  changed:

   What|Removed |Added

Summary|[regression] BUG unable to  |[GF108][Regression] Unable
   |handle kernel NULL pointer  |to handle NULL pointer
   |dereference in kernel   |dereference in
   |4.15.3  |nouveau_mem_host since
   ||kernel 4.15.3
 Status|NEW |NEEDINFO

--- Comment #3 from Pierre Moreau  ---
Thank you for the bug report.
Is this easily reproducible (and if yes, how)? Otherwise, what were you doing
when this happened?

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

[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15

2018-02-20 Thread bugzilla-daemon

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

Pierre Moreau  changed:

   What|Removed |Added

Summary|[MCP79][Regression] |[MCP79][Regression]
   |Unhandled NULL pointer  |Unhandled NULL pointer
   |dereference since kernel|dereference in
   |4.15|nvkm_object_unmap since
   ||kernel 4.15

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

[Nouveau] [Bug 105174] [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

2018-02-20 Thread bugzilla-daemon

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

--- Comment #2 from Dominik 'Rathann' Mierzejewski  ---
4.14.18-300.fc27.x86_64 is the last working Fedora kernel.

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

[Nouveau] [Bug 105174] [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

2018-02-20 Thread bugzilla-daemon

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

--- Comment #1 from Dominik 'Rathann' Mierzejewski  ---
After logging in I get no output on the second screen attached to HDMI port and
the Xorg session doesn't start fully. I can only see the wallpaper on the
built-in display. Mouse cursor moves, but doesn't respond to clicks. Machine
remains accessible via ssh. There are no errors or warnings in Xorg log.

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

[Nouveau] [Bug 105174] New: [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

2018-02-20 Thread bugzilla-daemon

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

Bug ID: 105174
   Summary: [regression] BUG unable to handle kernel NULL pointer
dereference in kernel 4.15.3
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: domi...@greysector.net
QA Contact: xorg-t...@lists.x.org

Created attachment 137463
  --> https://bugs.freedesktop.org/attachment.cgi?id=137463=edit
full dmesg

After updating to Fedora kernel 4.15.3-300.fc27.x86_64, I got:
BUG: unable to handle kernel NULL pointer dereference at 0040
IP: nouveau_mem_host+0x47/0x1b0 [nouveau]

Full dmesg attached. The hardware is Dell XPS 15 with Intel and nVidia GPU in
Optimus configuration.

Note: this looks different from bug 105173.

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

[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference since kernel 4.15

2018-02-20 Thread bugzilla-daemon

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

Pierre Moreau  changed:

   What|Removed |Added

Summary|With kernel >=4.15 nouveau  |[MCP79][Regression]
   |- artefacts and freezes |Unhandled NULL pointer
   ||dereference since kernel
   ||4.15
 Status|NEW |ASSIGNED

--- Comment #3 from Pierre Moreau  ---
Thanks for the report. I’ll try to reproduce the issue on my laptop and if that
works, bisect the kernel to figure out which change introduce the issue.

Looking at the logs, it seems like there is some out-of-memory error

> [   56.900580] nouveau :03:00.0: imem: OOM: 0004b000  -28

followed by a NULL pointer dereference when trying to unmap an object

> [   56.900593] BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> [   56.900747] IP: nvkm_object_unmap+0x5/0x20 [nouveau]
> [   56.900754] PGD 0 P4D 0 
> [   56.900761] Oops:  [#1] SMP PTI
> [   56.900767] Modules linked in: fuse xt_CHECKSUM ipt_MASQUERADE 
> nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast 
> xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink 
> ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 
> nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security 
> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
> iptable_mangle iptable_raw iptable_security ebtable_filter ebtables 
> ip6table_filter ip6_tables sunrpc snd_hda_codec_hdmi xfs libcrc32c 
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec 
> snd_hda_core snd_hwdep snd_seq coretemp snd_seq_device snd_pcm wmi_bmof 
> shpchp snd_timer snd soundcore nv_tco i2c_nforce2 acpi_cpufreq binfmt_misc 
> nouveau i2c_algo_bit
> [   56.900857]  mxm_wmi drm_kms_helper ttm drm serio_raw forcedeth video wmi
> [   56.900870] CPU: 1 PID: 2856 Comm: supertuxkart Not tainted 
> 4.16.0-0.rc2.git0.1.fc28.x86_64 #1
> [   56.900876] Hardware name: NVIDIA MCP7A/MCP7A, BIOS 6.00 PG 04/22/2009
> [   56.900910] RIP: 0010:nvkm_object_unmap+0x5/0x20 [nouveau]
> [   56.900916] RSP: 0018:ae3c4188bca0 EFLAGS: 00010282
> [   56.900922] RAX: c0592400 RBX: 9c81cb2cf198 RCX: 
> 0018
> [   56.900928] RDX: c04ac1b0 RSI: 9c81cb2cf1b8 RDI: 
> 
> [   56.900934] RBP: 9c81cb2cf188 R08: 000250c0 R09: 
> c04a9b63
> [   56.900941] R10: d07b4280a8c0 R11: 959711ed R12: 
> 9c81cb2cf1b8
> [   56.900947] R13: 000d4fb70488 R14: 9c8200180020 R15: 
> 0006
> [   56.900955] FS:  7fad6be37840() GS:9c822fc8() 
> knlGS:
> [   56.900961] CS:  0010 DS:  ES:  CR0: 80050033
> [   56.900967] CR2:  CR3: 86db2000 CR4: 
> 000406e0
> [   56.900974] Call Trace:
> [   56.901012]  nvkm_object_dtor+0x96/0x100 [nouveau]
> [   56.901046]  ? nvkm_object_del+0x24/0xa0 [nouveau]
> [   56.901075]  ? nvkm_ioctl_new+0x1ee/0x220 [nouveau]
> [   56.901116]  ? nvkm_fifo_chan_dtor+0xf0/0xf0 [nouveau]
> [   56.901148]  ? nvkm_object_new_+0x60/0x60 [nouveau]
> [   56.901180]  ? nvkm_ioctl+0xd8/0x170 [nouveau]
> [   56.901222]  ? usif_ioctl+0x6b1/0x730 [nouveau]
> [   56.901262]  ? nouveau_drm_ioctl+0xad/0xc0 [nouveau]
> [   56.901271]  ? do_vfs_ioctl+0xa4/0x610
> [   56.901277]  ? SyS_ioctl+0x74/0x80
> [   56.901285]  ? do_syscall_64+0x74/0x180
> [   56.901295]  ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [   56.901301] Code: ff c3 0f 1f 40 00 66 66 66 66 90 48 8b 07 48 8b 40 28 48 
> 85 c0 74 05 e9 0a 76 75 d4 b8 ed ff ff ff c3 0f 1f 40 00 66 66 66 66 90 <48> 
> 8b 07 48 8b 40 30 48 85 c0 74 05 e9 ea 75 75 d4 b8 ed ff ff 
> [   56.901373] RIP: nvkm_object_unmap+0x5/0x20 [nouveau] RSP: ae3c4188bca0
> [   56.901380] CR2: 
> [   56.910903] ---[ end trace bde3a9a90b3fc089 ]---

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

[Nouveau] [Bug 105173] With kernel >=4.15 nouveau - artefacts and freezes

2018-02-20 Thread bugzilla-daemon

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

Nick Lee  changed:

   What|Removed |Added

 QA Contact||xorg-t...@lists.x.org
  Component|General |Driver/nouveau
Version|XOrg git|unspecified
   Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
   |.org|rg
Product|DRI |xorg

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

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

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

[Nouveau] [Bug 105174] [GF108][Regression] Unable to handle NULL pointer dereference in nouveau_mem_host since kernel 4.15.3

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

Re: [Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

[Nouveau] [PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop

[Nouveau] [Bug 104835] MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

[Nouveau] [Bug 104835] MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]

[Nouveau] [Bug 105174] [GF108][Regression] Unable to handle NULL pointer dereference in nouveau_mem_host since kernel 4.15.3

[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15

[Nouveau] [Bug 105174] [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

[Nouveau] [Bug 105174] [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

[Nouveau] [Bug 105174] New: [regression] BUG unable to handle kernel NULL pointer dereference in kernel 4.15.3

[Nouveau] [Bug 105173] [MCP79][Regression] Unhandled NULL pointer dereference since kernel 4.15

[Nouveau] [Bug 105173] With kernel >=4.15 nouveau - artefacts and freezes

16 matches

Site Navigation

Mail list logo

Footer information