[Bug 98276] Kernel Panic on shutdown caused by "drm/amdgpu: always apply pci shutdown callbacks"

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98276

--- Comment #8 from Johannes Hirte  ---
Created attachment 127488
  --> https://bugs.freedesktop.org/attachment.cgi?id=127488=edit
dmesg output after unloading amdgpu.ko

I've retried removing the module via ssh session and the second time I was
successful. The dmesg output is attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/fb5679dc/attachment.html>


[Bug 98398] [Nouveau] Vgaswitcharoo fails to turn off GPU properly

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98398

Ilia Mirkin  changed:

   What|Removed |Added

 QA Contact||xorg-team at lists.x.org
  Component|DRM/other   |Driver/nouveau
Version|XOrg git|unspecified
Product|DRI |xorg
   Assignee|dri-devel at lists.freedesktop |nouveau at 
lists.freedesktop.o
   |.org|rg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/eede3ffa/attachment.html>


[Bug 98398] [Nouveau] Vgaswitcharoo fails to turn off GPU properly

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98398

--- Comment #2 from rick.2889 at gmail.com ---
Created attachment 127485
  --> https://bugs.freedesktop.org/attachment.cgi?id=127485=edit
lspci -tnnv output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/d0cd7210/attachment.html>


[Bug 98398] [Nouveau] Vgaswitcharoo fails to turn off GPU properly

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98398

--- Comment #1 from rick.2889 at gmail.com ---
Created attachment 127484
  --> https://bugs.freedesktop.org/attachment.cgi?id=127484=edit
acpidump output

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/900ba147/attachment.html>


[Bug 98398] [Nouveau] Vgaswitcharoo fails to turn off GPU properly

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98398

Bug ID: 98398
   Summary: [Nouveau] Vgaswitcharoo fails to turn off GPU properly
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: rick.2889 at gmail.com

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

Using Arch Linux and kernel 4.8.3, I am observing much higher power usage in
powertop when using Nouveau with vgaswitcharoo (~13W) opposed to
NVIDIA/Bumblebee with BBSwitch (~7.5 W).

I initially started noticing this because the battery drained much faster and
the fans started to spin while they otherwise stayed idle.

Attached is my dmesg log.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/1919fc64/attachment.html>


[Bug 98146] DRI_PRIME=1 and fullscreen issues

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98146

--- Comment #18 from Darek Deoniziak  ---
Tried using DRI3 for single GPU with hopes that some issues won't appear.

First made only intel use DRI3 and radeon DRI2 - that felt like when I set both
GPUs to use DRI3 (same issues).

Second time I tried DRI3 for radeon and DRI2 for intel (running it currently).
It feels like when using DRI2 for both, but closing or minimizing fullscreen
application running on radeon doesn't freeze desktop graphics (4), hope it is
not temporary. Guess I will stick with that for more because it has no vsync
issues at all:
[ 4.598] (**) intel(0): Option "DRI" "2"
[ 4.752] (**) RADEON(G0): Option "DRI" "3"
[ 4.844] (II) glamor: EGL version 1.4 (DRI2):
[ 4.849] (II) RADEON(G0): [DRI2] Setup complete
[ 4.850] (II) RADEON(G0): [DRI2]   DRI driver: radeonsi
[ 4.850] (II) RADEON(G0): [DRI2]   VDPAU driver: radeonsi
[ 4.850] (**) RADEON(G0): DRI3 enabled
[ 4.968] (II) intel(0): [DRI2] Setup complete
[ 4.968] (II) intel(0): [DRI2]   DRI driver: i965
[ 4.968] (II) intel(0): [DRI2]   VDPAU driver: va_gl
[ 4.968] (II) intel(0): direct rendering: DRI2 enabled
[ 4.983] (II) GLX: Initialized DRI2 GL provider for screen 0

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/7560496e/attachment-0001.html>


[PATCH 1/3] drm/amdgpu: change function declarations and add missing header dependencies

2016-10-22 Thread Edward O'Callaghan
u_connectors.h"
> +#include "dce_v8_0.h"
>  
>  #include "dce/dce_8_0_d.h"
>  #include "dce/dce_8_0_sh_mask.h"
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> index 1944d28..f5e8fda 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> @@ -25,6 +25,7 @@
>  #include "linux/delay.h"
>  #include "hwmgr.h"
>  #include "amd_acpi.h"
> +#include "pp_acpi.h"
>  
>  bool acpi_atcs_functions_supported(void *device, uint32_t index)
>  {
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h 
> b/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
> index 3df5de2..8fe8ba9 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
> @@ -21,9 +21,6 @@
>   *
>   */
>  
> -extern bool acpi_atcs_functions_supported(void *device,
> -     uint32_t index);
> -extern int acpi_pcie_perf_request(void *device,
> - uint8_t perf_req,
> - bool advertise);
> -extern bool acpi_atcs_notify_pcie_device_ready(void *device);
> +bool acpi_atcs_functions_supported(void *device, uint32_t index);
> +int acpi_pcie_perf_request(void *device, uint8_t perf_req, bool advertise);
> +bool acpi_atcs_notify_pcie_device_ready(void *device);
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/41b66f2e/attachment-0001.sig>


[PATCH] drm/amd/powerplay: mark symbols static where possible

2016-10-22 Thread Edward O'Callaghan
gr *hwmgr)
>  {
>   struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
>  
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> index 02fe1df..b86e48f 100755
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c
> @@ -159,7 +159,7 @@ static int fiji_start_smu_in_non_protection_mode(struct 
> pp_smumgr *smumgr)
>   return result;
>  }
>  
> -int fiji_setup_pwr_virus(struct pp_smumgr *smumgr)
> +static int fiji_setup_pwr_virus(struct pp_smumgr *smumgr)
>  {
>   int i, result = -1;
>   uint32_t reg, data;
> @@ -224,7 +224,7 @@ static int fiji_start_avfs_btc(struct pp_smumgr *smumgr)
>   return result;
>  }
>  
> -int fiji_setup_pm_fuse_for_avfs(struct pp_smumgr *smumgr)
> +static int fiji_setup_pm_fuse_for_avfs(struct pp_smumgr *smumgr)
>  {
>   int result = 0;
>   uint32_t table_start;
> @@ -260,7 +260,7 @@ int fiji_setup_pm_fuse_for_avfs(struct pp_smumgr *smumgr)
>   return result;
>  }
>  
> -int fiji_setup_graphics_level_structure(struct pp_smumgr *smumgr)
> +static int fiji_setup_graphics_level_structure(struct pp_smumgr *smumgr)
>  {
>   int32_t vr_config;
>   uint32_t table_start;
> @@ -299,7 +299,7 @@ int fiji_setup_graphics_level_structure(struct pp_smumgr 
> *smumgr)
>  }
>  
>  /* Work in Progress */
> -int fiji_restore_vft_table(struct pp_smumgr *smumgr)
> +static int fiji_restore_vft_table(struct pp_smumgr *smumgr)
>  {
>   struct fiji_smumgr *priv = (struct fiji_smumgr *)(smumgr->backend);
>  
> @@ -311,7 +311,7 @@ int fiji_restore_vft_table(struct pp_smumgr *smumgr)
>  }
>  
>  /* Work in Progress */
> -int fiji_save_vft_table(struct pp_smumgr *smumgr)
> +static int fiji_save_vft_table(struct pp_smumgr *smumgr)
>  {
>   struct fiji_smumgr *priv = (struct fiji_smumgr *)(smumgr->backend);
>  
> @@ -322,7 +322,7 @@ int fiji_save_vft_table(struct pp_smumgr *smumgr)
>   return -EINVAL;
>  }
>  
> -int fiji_avfs_event_mgr(struct pp_smumgr *smumgr, bool smu_started)
> +static int fiji_avfs_event_mgr(struct pp_smumgr *smumgr, bool smu_started)
>  {
>   struct fiji_smumgr *priv = (struct fiji_smumgr *)(smumgr->backend);
>  
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> index 5c3598a..f38a687 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
> @@ -118,7 +118,7 @@ static int polaris10_perform_btc(struct pp_smumgr *smumgr)
>  }
>  
>  
> -int polaris10_setup_graphics_level_structure(struct pp_smumgr *smumgr)
> +static int polaris10_setup_graphics_level_structure(struct pp_smumgr *smumgr)
>  {
>   uint32_t vr_config;
>   uint32_t dpm_table_start;
> @@ -172,7 +172,8 @@ int polaris10_setup_graphics_level_structure(struct 
> pp_smumgr *smumgr)
>   return 0;
>  }
>  
> -int polaris10_avfs_event_mgr(struct pp_smumgr *smumgr, bool SMU_VFT_INTACT)
> +static int
> +polaris10_avfs_event_mgr(struct pp_smumgr *smumgr, bool SMU_VFT_INTACT)
>  {
>   struct polaris10_smumgr *smu_data = (struct polaris10_smumgr 
> *)(smumgr->backend);
>  
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/600fe203/attachment-0001.sig>


[Nouveau] [PATCH 01/17] drm/nouveau/core: add missing header dependencies

2016-10-22 Thread Karol Herbst
I think it would be better to squash those commits:
1. for the includes
2. for static declerations

2016-10-22 11:41 GMT+02:00 Baoyou Xie :
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous 
> prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
> drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous 
> prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
>
> In fact, these functions are declared in
> drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h.
> So this patch adds missing header dependencies.
>
> Signed-off-by: Baoyou Xie 
> ---
>  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
> b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> index 34ecd4a..058ff46 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
> @@ -20,6 +20,7 @@
>   * DEALINGS IN THE SOFTWARE.
>   */
>  #include 
> +#include 
>
>  /**
>   * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory
> --
> 2.7.4
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


[PATCH 1/3] x86/pat: export io memory reserve/free api.

2016-10-22 Thread Shawn Starr
For the series, no regressions in my testing, no stalls, no issues noted.

Tested by: Shawn Starr 

Thanks,
Shawn

On Tuesday, October 18, 2016 4:13:11 PM EDT Dave Airlie wrote:
> From: Dave Airlie 
> 
> These functions are needed for gpu/ttm drivers to reserve the
> VRAM area as write combined. In a lot of places we don't ioremap
> but still need to insert pfn from it into a VMA using vm_insert_mixed,
> but a recent change in mixed insertion means we need to reserve
> VRAM as WC upfront, so we need these APIs exported.
> 
> Signed-off-by: Dave Airlie 
> ---
>  arch/x86/mm/pat.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 170cc4f..5ce2fbb 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -719,6 +719,7 @@ out_free:
>  out_err:
>   return ret;
>  }
> +EXPORT_SYMBOL(io_reserve_memtype);
> 
>  /**
>   * io_free_memtype - Release a memory type mapping for a region of memory
> @@ -729,6 +730,7 @@ void io_free_memtype(resource_size_t start,
> resource_size_t end) {
>   free_memtype(start, end);
>  }
> +EXPORT_SYMBOL(io_free_memtype);
> 
>  pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
>   unsigned long size, pgprot_t vma_prot)




[Bug 98390] server down

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98390

Bug ID: 98390
   Summary: server down
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: General
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: ambhore.roshan11 at gmail.com

server crashed !!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/4b1b27c3/attachment.html>


[Bug 98357] [amdgpu] Topaz fails to boot with error in powerplay initialization

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98357

--- Comment #4 from Nayan Deshmukh  ---
My system hangs when I try to load the amdgpu module. It, however, loads
initially during startup. I was planning to do a git bisect on Sunday. I will
keep updating this bug with my findings.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/334172ec/attachment.html>


[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

2016-10-22 Thread Ville Syrjälä
On Sat, Oct 22, 2016 at 04:01:14PM +0200, Daniel Vetter wrote:
> On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> > > This function provides a way for the driver to redo a
> > > modeset on the current mode and retry the link training
> > > at a lower link rate/lane count/bpp. This will get called
> > > incase the link training fails during the current modeset.
> > > 
> > > Cc: dri-devel at lists.freedesktop.org
> > > Cc: Jani Nikula 
> > > Cc: Daniel Vetter 
> > > Cc: Ville Syrjala 
> > > Signed-off-by: Manasi Navare 
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > > +
> > >  include/drm/drm_atomic_helper.h |  1 +
> > >  2 files changed, 59 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index f936276..0c1614e 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > > drm_connector *connector,
> > >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> > >  
> > >  /**
> > > + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> > > + * @connector: DRM connector
> > > + *
> > > + * Provides a way to redo a modeset with the current mode so that it can
> > > + * drop the bpp, link rate/lane count and retry the link training.
> > > + *
> > > + * Returns:
> > > + * Returns 0 on success, negative errno numbers on failure.
> > > + */
> > > +int
> > > +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> > > +{
> > > + struct drm_device *dev = connector->dev;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + struct drm_atomic_state *state;
> > > + struct drm_connector_state *connector_state;
> > > + struct drm_crtc_state *crtc_state;
> > > + int ret = 0;
> > > +
> > > + drm_modeset_acquire_init(, 0);
> > > + state = drm_atomic_state_alloc(dev);
> > > + if (!state) {
> > > + ret = -ENOMEM;
> > > + goto fail;
> > > + }
> > > + state->acquire_ctx = 
> > > +retry:
> > > + ret = 0;
> > > + connector_state = drm_atomic_get_connector_state(state, connector);
> > > + if (IS_ERR(connector_state)) {
> > > + ret = PTR_ERR(connector_state);
> > > + goto fail;
> > > + }
> > > + if (!connector_state->crtc)
> > > + goto fail;
> > > +
> > > + crtc_state = drm_atomic_get_existing_crtc_state(state,
> > > + connector_state->crtc);
> > > + crtc_state->connectors_changed = true;
> > 
> > This line here only works if the driver uses the helpers for checking and
> > commit, and when it doesn't overwrite connectors_changed. I think the
> > kerneldoc should mention this.
> > 
> > The other issue: You cannot call this from modeset code itself because of
> > recursion. I think this also must be mentioned.
> 
> And if this indeed does a modeset then we have again the same issue as
> with upfront link training when the pipe is supposed to be on: Userspace
> can observe the kernel playing tricks because the vblank support will be
> temporarily disabled.
> 
> Not sure how to best fix this, but might be good to grab the crtc->mutex
> in the vblank code for stuff like this.

We're going to have the same problem with async modeset as well.

-- 
Ville Syrjälä
Intel OTC


[PATCH 17/17] drm/nouveau: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nouveau_display.c:96:1: warning: no previous prototype 
for 'nouveau_display_scanoutpos_head' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nv10_fence.c:70:1: warning: no previous prototype for 
'nv10_fence_context_new' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 drivers/gpu/drm/nouveau/nv10_fence.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index afbf557..b60ee21 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -92,7 +92,7 @@ calc(int blanks, int blanke, int total, int line)
return line;
 }

-int
+static int
 nouveau_display_scanoutpos_head(struct drm_crtc *crtc, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime)
 {
diff --git a/drivers/gpu/drm/nouveau/nv10_fence.c 
b/drivers/gpu/drm/nouveau/nv10_fence.c
index 4e3de34..619f79d 100644
--- a/drivers/gpu/drm/nouveau/nv10_fence.c
+++ b/drivers/gpu/drm/nouveau/nv10_fence.c
@@ -66,7 +66,7 @@ nv10_fence_context_del(struct nouveau_channel *chan)
nouveau_fence_context_free(>base);
 }

-int
+static int
 nv10_fence_context_new(struct nouveau_channel *chan)
 {
struct nv10_fence_chan *fctx;
-- 
2.7.4



[PATCH 16/17] drm/nouveau/dispnv04: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/dispnv04/overlay.c:496:1: warning: no previous 
prototype for 'nouveau_overlay_init' [-Wmissing-prototypes]

In fact, this function is declared in
drivers/gpu/drm/nouveau/dispnv04/disp.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c 
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index ec444ea..a79514d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -33,7 +33,7 @@
 #include "nouveau_connector.h"
 #include "nouveau_display.h"
 #include "nvreg.h"
-
+#include "disp.h"

 struct nouveau_plane {
struct drm_plane base;
-- 
2.7.4



[PATCH 15/17] drm/nouveau/pm: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:75:1: warning: no previous 
prototype for 'nvkm_perfsig_find' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c:703:1: warning: no previous 
prototype for 'nvkm_perfsrc_new' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
index 8616636..dde89a4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c
@@ -71,7 +71,7 @@ nvkm_perfdom_find(struct nvkm_pm *pm, int di)
return NULL;
 }

-struct nvkm_perfsig *
+static struct nvkm_perfsig *
 nvkm_perfsig_find(struct nvkm_pm *pm, u8 di, u8 si, struct nvkm_perfdom **pdom)
 {
struct nvkm_perfdom *dom = *pdom;
@@ -699,7 +699,7 @@ nvkm_pm_oclass_get(struct nvkm_oclass *oclass, int index,
return 1;
 }

-int
+static int
 nvkm_perfsrc_new(struct nvkm_pm *pm, struct nvkm_perfsig *sig,
 const struct nvkm_specsrc *spec)
 {
-- 
2.7.4



[PATCH 14/17] drm/nouveau/gr: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 5 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1388:1: warning: no previous 
prototype for 'gf100_gr_init_fw' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:1705:1: warning: no previous 
prototype for 'gf100_gr_init_' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c:312:1: warning: no previous 
prototype for 'gm107_gr_init' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous 
prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c:937:1: warning: no previous 
prototype for 'gm107_grctx_generate_tpcid' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 2 +-
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c| 4 ++--
 drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
index c925ade..74a64e3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c
@@ -218,7 +218,7 @@ gf117_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gf117_grctx_generate_main(struct gf100_gr *gr, struct gf100_grctx *info)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
index 6d3c501..4c4b5ab 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c
@@ -933,7 +933,7 @@ gm107_grctx_generate_attrib(struct gf100_grctx *info)
}
 }

-void
+static void
 gm107_grctx_generate_tpcid(struct gf100_gr *gr)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
index 157919c..eccdee0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c
@@ -1384,7 +1384,7 @@ gf100_gr_intr(struct nvkm_gr *base)
nvkm_fifo_chan_put(device->fifo, flags, );
 }

-void
+static void
 gf100_gr_init_fw(struct gf100_gr *gr, u32 fuc_base,
 struct gf100_gr_fuc *code, struct gf100_gr_fuc *data)
 {
@@ -1701,7 +1701,7 @@ gf100_gr_oneinit(struct nvkm_gr *base)
return 0;
 }

-int
+static int
 gf100_gr_init_(struct nvkm_gr *base)
 {
struct gf100_gr *gr = gf100_gr(base);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
index 45f965f..2c67fac 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.c
@@ -308,7 +308,7 @@ gm107_gr_init_bios(struct gf100_gr *gr)
}
 }

-int
+static int
 gm107_gr_init(struct gf100_gr *gr)
 {
struct nvkm_device *device = gr->base.engine.subdev.device;
-- 
2.7.4



[PATCH 13/17] drm/nouveau/gr: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous 
prototype for 'nv50_grctx_fill' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1: warning: no previous 
prototype for 'nv50_grctx_init' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
index 1e13278..c8bb919 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c
@@ -106,6 +106,7 @@
 #define CP_SEEK_2  0x00c800ff

 #include "ctxnv40.h"
+#include "nv50.h"

 #include 

-- 
2.7.4



[PATCH 12/17] drm/nouveau/fifo: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c:133:1: warning: no previous 
prototype for 'g84_fifo_chan_engine_init' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c:174:1: warning: no previous 
prototype for 'g84_fifo_chan_object_ctor' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
index aeb3387..15a992b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.c
@@ -129,7 +129,7 @@ g84_fifo_chan_engine_fini(struct nvkm_fifo_chan *base,
 }


-int
+static int
 g84_fifo_chan_engine_init(struct nvkm_fifo_chan *base,
  struct nvkm_engine *engine)
 {
@@ -170,7 +170,7 @@ g84_fifo_chan_engine_ctor(struct nvkm_fifo_chan *base,
return nvkm_object_bind(object, NULL, 0, >engn[engn]);
 }

-int
+static int
 g84_fifo_chan_object_ctor(struct nvkm_fifo_chan *base,
  struct nvkm_object *object)
 {
-- 
2.7.4



[PATCH 11/17] drm/nouveau/disp: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 5 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c:70:1: warning: no previous 
prototype for 'nv50_disp_root_mthd_' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:157:1: warning: no previous 
prototype for 'nv50_disp_chan_rd32' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:167:1: warning: no previous 
prototype for 'nv50_disp_chan_wr32' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:177:1: warning: no previous 
prototype for 'nv50_disp_chan_ntfy' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:193:1: warning: no previous 
prototype for 'nv50_disp_chan_map' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 8 
 drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index dd2953b..26990d4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -153,7 +153,7 @@ nv50_disp_chan_uevent = {
.fini = nv50_disp_chan_uevent_fini,
 };

-int
+static int
 nv50_disp_chan_rd32(struct nvkm_object *object, u64 addr, u32 *data)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
@@ -163,7 +163,7 @@ nv50_disp_chan_rd32(struct nvkm_object *object, u64 addr, 
u32 *data)
return 0;
 }

-int
+static int
 nv50_disp_chan_wr32(struct nvkm_object *object, u64 addr, u32 data)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
@@ -173,7 +173,7 @@ nv50_disp_chan_wr32(struct nvkm_object *object, u64 addr, 
u32 data)
return 0;
 }

-int
+static int
 nv50_disp_chan_ntfy(struct nvkm_object *object, u32 type,
struct nvkm_event **pevent)
 {
@@ -189,7 +189,7 @@ nv50_disp_chan_ntfy(struct nvkm_object *object, u32 type,
return -EINVAL;
 }

-int
+static int
 nv50_disp_chan_map(struct nvkm_object *object, u64 *addr, u32 *size)
 {
struct nv50_disp_chan *chan = nv50_disp_chan(object);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
index 2f9cecd..6424b39 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/rootnv50.c
@@ -66,7 +66,7 @@ nv50_disp_root_scanoutpos(NV50_DISP_MTHD_V0)
return 0;
 }

-int
+static int
 nv50_disp_root_mthd_(struct nvkm_object *object, u32 mthd, void *data, u32 
size)
 {
union {
-- 
2.7.4



[PATCH 10/17] drm/nouveau/device: mark symbol static where possible

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/device/user.c:330:1: warning: no previous 
prototype for 'nvkm_udevice_new' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
index 79a8f71..513ee6b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/user.c
@@ -326,7 +326,7 @@ nvkm_udevice = {
.sclass = nvkm_udevice_child_get,
 };

-int
+static int
 nvkm_udevice_new(const struct nvkm_oclass *oclass, void *data, u32 size,
 struct nvkm_object **pobject)
 {
-- 
2.7.4



[PATCH 09/17] drm/nouveau/volt: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c:38:1: warning: no previous 
prototype for 'gk104_volt_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c:51:1: warning: no previous 
prototype for 'gk104_volt_set' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c
index 420bd84..1527d12 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk104.c
@@ -34,7 +34,7 @@ struct gk104_volt {
struct nvbios_volt bios;
 };

-int
+static int
 gk104_volt_get(struct nvkm_volt *base)
 {
struct nvbios_volt *bios = _volt(base)->bios;
@@ -47,7 +47,7 @@ gk104_volt_get(struct nvkm_volt *base)
return bios->base + bios->pwm_range * duty / div;
 }

-int
+static int
 gk104_volt_set(struct nvkm_volt *base, u32 uv)
 {
struct nvbios_volt *bios = _volt(base)->bios;
-- 
2.7.4



[PATCH 08/17] drm/nouveau/volt: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 3 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c:35:1: warning: no previous 
prototype for 'nvkm_voltgpio_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c:54:1: warning: no previous 
prototype for 'nvkm_voltgpio_set' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c:71:1: warning: no previous 
prototype for 'nvkm_voltgpio_init' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
index d2bac1d..443c031 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include "priv.h"

 static const u8 tags[] = {
DCB_GPIO_VID0, DCB_GPIO_VID1, DCB_GPIO_VID2, DCB_GPIO_VID3,
-- 
2.7.4



[PATCH 07/17] drm/nouveau/secboot: mark symbol static where possible

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c:1368:1: warning: no 
previous prototype for 'gm200_secboot_fini' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c
index f1e2dc9..ec48e4a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.c
@@ -1364,7 +1364,7 @@ gm200_secboot_init(struct nvkm_secboot *sb)
return 0;
 }

-int
+static int
 gm200_secboot_fini(struct nvkm_secboot *sb, bool suspend)
 {
struct gm200_secboot *gsb = gm200_secboot(sb);
-- 
2.7.4



[PATCH 06/17] drm/nouveau/gpio: mark symbol static where possible

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c:41:1: warning: no previous 
prototype for 'gk104_gpio_intr_mask' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c
index 3f45afd1..2ead515 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gpio/gk104.c
@@ -37,7 +37,7 @@ gk104_gpio_intr_stat(struct nvkm_gpio *gpio, u32 *hi, u32 *lo)
nvkm_wr32(device, 0x00dc80, intr1);
 }

-void
+static void
 gk104_gpio_intr_mask(struct nvkm_gpio *gpio, u32 type, u32 mask, u32 data)
 {
struct nvkm_device *device = gpio->subdev.device;
-- 
2.7.4



[PATCH 05/17] drm/nouveau/fb: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous 
prototype for 'gt215_link_train_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous 
prototype for 'gt215_link_train' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous 
prototype for 'gt215_link_train_init' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:337:1: warning: no previous 
prototype for 'gt215_link_train_fini' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c
index d15ea88..f106643 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c
@@ -95,7 +95,7 @@ struct gt215_ram {
struct gt215_ltrain ltrain;
 };

-void
+static void
 gt215_link_train_calc(u32 *vals, struct gt215_ltrain *train)
 {
int i, lo, hi;
@@ -149,7 +149,7 @@ gt215_link_train_calc(u32 *vals, struct gt215_ltrain *train)
 /*
  * Link training for (at least) DDR3
  */
-int
+static int
 gt215_link_train(struct gt215_ram *ram)
 {
struct gt215_ltrain *train = >ltrain;
@@ -267,7 +267,7 @@ gt215_link_train(struct gt215_ram *ram)
return ret;
 }

-int
+static int
 gt215_link_train_init(struct gt215_ram *ram)
 {
static const u32 pattern[16] = {
@@ -333,7 +333,7 @@ gt215_link_train_init(struct gt215_ram *ram)
return 0;
 }

-void
+static void
 gt215_link_train_fini(struct gt215_ram *ram)
 {
if (ram->ltrain.mem)
-- 
2.7.4



[PATCH 04/17] drm/nouveau/fb: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous 
prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous 
prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c | 1 +
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
index b9f1ffd..4dcd874 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c
@@ -23,6 +23,7 @@
  *  Ben Skeggs
  */
 #include "priv.h"
+#include "ram.h"

 struct ramxlat {
int id;
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
index 2690033..eca8a44 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c
@@ -23,6 +23,7 @@
  * Roy Spliet 
  */
 #include "priv.h"
+#include "ram.h"

 struct ramxlat {
int id;
-- 
2.7.4



[PATCH 03/17] drm/nouveau/clk: mark symbol static where possible

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous 
prototype for 'gt215_clk_info' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
index 056702e..96e0941 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c
@@ -180,7 +180,7 @@ gt215_clk_read(struct nvkm_clk *base, enum nv_clk_src src)
return 0;
 }

-int
+static int
 gt215_clk_info(struct nvkm_clk *base, int idx, u32 khz,
   struct gt215_clk_info *info)
 {
-- 
2.7.4



[PATCH 02/17] drm/nouveau/bios: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous 
prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous 
prototype for 'nvbios_fan_entry' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c
index 80fed7e..e290581 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c
@@ -25,7 +25,7 @@
 #include 
 #include 

-u16
+static u16
 nvbios_fan_table(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8 *cnt, u8 *len)
 {
struct bit_entry bit_P;
@@ -52,7 +52,7 @@ nvbios_fan_table(struct nvkm_bios *bios, u8 *ver, u8 *hdr, u8 
*cnt, u8 *len)
return 0x;
 }

-u16
+static u16
 nvbios_fan_entry(struct nvkm_bios *bios, int idx, u8 *ver, u8 *hdr,
 u8 *cnt, u8 *len)
 {
-- 
2.7.4



[PATCH 01/17] drm/nouveau/core: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous 
prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous 
prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index 34ecd4a..058ff46 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -20,6 +20,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 #include 
+#include 

 /**
  * nvkm_firmware_get - load firmware from the official nvidia/chip/ directory
-- 
2.7.4



[Bug 98146] DRI_PRIME=1 and fullscreen issues

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98146

--- Comment #17 from Darek Deoniziak  ---
Regarding new issue in 2 problem with DRI3. The frame problem is vsync related,
after removing Option "SwapBuffersWait" "0" and enabling vsync in Half Life 2
issue is no more, picture is also clear.

Unfortunately in Serious Sam 3 regardless of value of vsync in game options the
frames still have issues. In DRI2 Serious Sam 3 has no issues except screen
cutted.

What else can I try?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/9d9ab2d8/attachment.html>


[Bug 98357] [amdgpu] Topaz fails to boot with error in powerplay initialization

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98357

--- Comment #3 from Christian König  ---
This is a regression, isn't it? So the first step should probably be to bisect
which patch broke it.

Try to google for "git bisect" on how to do this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/e7d445d7/attachment.html>


[PATCH 1/2] drm/msm: add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/msm/msm_debugfs.c:141:5: warning: no previous prototype for 
'msm_debugfs_init' [-Wmissing-prototypes]
drivers/gpu/drm/msm/msm_debugfs.c:158:6: warning: no previous prototype for 
'msm_debugfs_cleanup' [-Wmissing-prototypes]

In fact, these functions are declared in
drivers/gpu/drm/msm/msm_debugfs.h.
So this patch adds missing header dependencies.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/msm/msm_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_debugfs.c 
b/drivers/gpu/drm/msm/msm_debugfs.c
index 663f2b6..3c85373 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -18,6 +18,7 @@
 #ifdef CONFIG_DEBUG_FS
 #include "msm_drv.h"
 #include "msm_gpu.h"
+#include "msm_debugfs.h"

 static int msm_gpu_show(struct drm_device *dev, struct seq_file *m)
 {
-- 
2.7.4



[PATCH 2/2] drm/msm/adreno: move function declarations to header file

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/msm/adreno/a3xx_gpu.c:535:17: warning: no previous prototype 
for 'a3xx_gpu_init' [-Wmissing-prototypes]
drivers/gpu/drm/msm/adreno/a4xx_gpu.c:624:17: warning: no previous prototype 
for 'a4xx_gpu_init' [-Wmissing-prototypes]

In fact, both functions are declared in
drivers/gpu/drm/msm/adreno/adreno_device.c, but should be declared
in a header file. So this patch moves both function declarations to
drivers/gpu/drm/msm/adreno/adreno_gpu.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 3 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h| 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 5127b75..7250ffc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -25,9 +25,6 @@ bool hang_debug = false;
 MODULE_PARM_DESC(hang_debug, "Dump registers when hang is detected (can be 
slow!)");
 module_param_named(hang_debug, hang_debug, bool, 0600);

-struct msm_gpu *a3xx_gpu_init(struct drm_device *dev);
-struct msm_gpu *a4xx_gpu_init(struct drm_device *dev);
-
 static const struct adreno_info gpulist[] = {
{
.rev   = ADRENO_REV(3, 0, 5, ANY_ID),
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index a54f6e0..07d99bd 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -311,4 +311,7 @@ static inline void adreno_gpu_write(struct adreno_gpu *gpu,
gpu_write(>base, reg - 1, data);
 }

+struct msm_gpu *a3xx_gpu_init(struct drm_device *dev);
+struct msm_gpu *a4xx_gpu_init(struct drm_device *dev);
+
 #endif /* __ADRENO_GPU_H__ */
-- 
2.7.4



[PATCH] drm/i2c/tda998x: mark symbol static where possible

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for 
'tda998x_audio_digital_mute' [-Wmissing-prototypes]

In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9798d40..af8683e 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1289,7 +1289,8 @@ static void tda998x_audio_shutdown(struct device *dev, 
void *data)
mutex_unlock(>audio_mutex);
 }

-int tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+tda998x_audio_digital_mute(struct device *dev, void *data, bool enable)
 {
struct tda998x_priv *priv = dev_get_drvdata(dev);

-- 
2.7.4



[PATCH] drm/arm: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/arm/malidp_planes.c:49:25: warning: no previous prototype for 
'malidp_duplicate_plane_state' [-Wmissing-prototypes]
drivers/gpu/drm/arm/malidp_planes.c:66:6: warning: no previous prototype for 
'malidp_destroy_plane_state' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/arm/malidp_planes.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 82c193e..5339e87 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -46,7 +46,8 @@ static void malidp_de_plane_destroy(struct drm_plane *plane)
devm_kfree(plane->dev->dev, mp);
 }

-struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
+static struct
+drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
 {
struct malidp_plane_state *state, *m_state;

@@ -63,7 +64,7 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
drm_plane *plane)
return >base;
 }

-void malidp_destroy_plane_state(struct drm_plane *plane,
+static void malidp_destroy_plane_state(struct drm_plane *plane,
struct drm_plane_state *state)
 {
struct malidp_plane_state *m_state = to_malidp_plane_state(state);
-- 
2.7.4



[PATCH] drm/arm: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/arm/malidp_planes.c:49:25: warning: no previous prototype for 
'malidp_duplicate_plane_state' [-Wmissing-prototypes]
drivers/gpu/drm/arm/malidp_planes.c:66:6: warning: no previous prototype for 
'malidp_destroy_plane_state' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/arm/malidp_planes.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 82c193e..5339e87 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -46,7 +46,8 @@ static void malidp_de_plane_destroy(struct drm_plane *plane)
devm_kfree(plane->dev->dev, mp);
 }

-struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
+static struct
+drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane)
 {
struct malidp_plane_state *state, *m_state;

@@ -63,7 +64,7 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct 
drm_plane *plane)
return >base;
 }

-void malidp_destroy_plane_state(struct drm_plane *plane,
+static void malidp_destroy_plane_state(struct drm_plane *plane,
struct drm_plane_state *state)
 {
struct malidp_plane_state *m_state = to_malidp_plane_state(state);
-- 
2.7.4



[PATCH] drm/armada: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/armada/armada_gem.c:215:27: warning: no previous prototype for 
'armada_gem_alloc_object' [-Wmissing-prototypes]
drivers/gpu/drm/armada/armada_gem.c:423:1: warning: no previous prototype for 
'armada_gem_prime_map_dma_buf' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/armada/armada_gem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 8067918..63c3a14 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -212,7 +212,7 @@ armada_gem_alloc_private_object(struct drm_device *dev, 
size_t size)
return obj;
 }

-struct armada_gem_object *armada_gem_alloc_object(struct drm_device *dev,
+static struct armada_gem_object *armada_gem_alloc_object(struct drm_device 
*dev,
size_t size)
 {
struct armada_gem_object *obj;
@@ -419,7 +419,7 @@ int armada_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
 }

 /* Prime support */
-struct sg_table *
+static struct sg_table *
 armada_gem_prime_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
 {
-- 
2.7.4



[PATCH] drm/amd/powerplay: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5: warning: no 
previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.c:2052:5: warning: no 
previous prototype for 'fiji_program_mem_timing_parameters' 
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/polaris10_smumgr.c:175:5: 
warning: no previous prototype for 'polaris10_avfs_event_mgr' 
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1020:5: warning: no 
previous prototype for 'cz_tf_reset_acp_boot_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:92:26: warning: no 
previous prototype for 'cast_phw_smu7_power_state' [-Wmissing-prototypes]


In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  |  6 ++-
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 12 +++---
 .../amd/powerplay/hwmgr/process_pptables_v1_0.c|  6 +--
 .../gpu/drm/amd/powerplay/hwmgr/processpptables.c  |  4 +-
 .../amd/powerplay/hwmgr/smu7_clockpowergating.c| 10 ++---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 49 --
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 12 +++---
 .../drm/amd/powerplay/smumgr/polaris10_smumgr.c|  5 ++-
 9 files changed, 57 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 7174f7a..eecfbc5 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -436,7 +436,9 @@ static enum PP_StateUILabel power_state_convert(enum 
amd_pm_state_type  state)
}
 }

-int pp_dpm_dispatch_tasks(void *handle, enum amd_pp_event event_id, void 
*input, void *output)
+static int
+pp_dpm_dispatch_tasks(void *handle, enum amd_pp_event event_id, void *input,
+ void *output)
 {
int ret = 0;
struct pp_instance *pp_handle;
@@ -475,7 +477,7 @@ int pp_dpm_dispatch_tasks(void *handle, enum amd_pp_event 
event_id, void *input,
return ret;
 }

-enum amd_pm_state_type pp_dpm_get_current_power_state(void *handle)
+static enum amd_pm_state_type pp_dpm_get_current_power_state(void *handle)
 {
struct pp_hwmgr *hwmgr;
struct pp_power_state *state;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index 9604249..4b14f25 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -66,7 +66,7 @@ static const struct cz_power_state 
*cast_const_PhwCzPowerState(
return (struct cz_power_state *)hw_ps;
 }

-uint32_t cz_get_eclk_level(struct pp_hwmgr *hwmgr,
+static uint32_t cz_get_eclk_level(struct pp_hwmgr *hwmgr,
uint32_t clock, uint32_t msg)
 {
int i = 0;
@@ -1017,7 +1017,7 @@ static int cz_tf_program_bootup_state(struct pp_hwmgr 
*hwmgr, void *input,
return 0;
 }

-int cz_tf_reset_acp_boot_level(struct pp_hwmgr *hwmgr, void *input,
+static int cz_tf_reset_acp_boot_level(struct pp_hwmgr *hwmgr, void *input,
void *output, void *storage, int result)
 {
struct cz_hwmgr *cz_hwmgr = (struct cz_hwmgr *)(hwmgr->backend);
@@ -1225,7 +1225,7 @@ static int cz_hwmgr_backend_fini(struct pp_hwmgr *hwmgr)
return 0;
 }

-int cz_phm_force_dpm_highest(struct pp_hwmgr *hwmgr)
+static int cz_phm_force_dpm_highest(struct pp_hwmgr *hwmgr)
 {
struct cz_hwmgr *cz_hwmgr = (struct cz_hwmgr *)(hwmgr->backend);

@@ -1239,7 +1239,7 @@ int cz_phm_force_dpm_highest(struct pp_hwmgr *hwmgr)
return 0;
 }

-int cz_phm_unforce_dpm_levels(struct pp_hwmgr *hwmgr)
+static int cz_phm_unforce_dpm_levels(struct pp_hwmgr *hwmgr)
 {
struct cz_hwmgr *cz_hwmgr = (struct cz_hwmgr *)(hwmgr->backend);
struct phm_clock_voltage_dependency_table *table =
@@ -1277,7 +1277,7 @@ int cz_phm_unforce_dpm_levels(struct pp_hwmgr *hwmgr)
return 0;
 }

-int cz_phm_force_dpm_lowest(struct pp_hwmgr *hwmgr)
+static int cz_phm_force_dpm_lowest(struct pp_hwmgr *hwmgr)
 {
struct cz_hwmgr *cz_hwmgr = (struct cz_hwmgr *)(hwmgr->backend);

@@ -1533,7 +1533,7 @@ static int cz_dpm_get_pp_table_entry(struct pp_hwmgr 
*hwmgr,
return result;
 }

-int cz_get_power_state_size(struct pp_hwmgr *hwmgr)
+static int cz_get_power_state_size(struct pp_hwmgr *hwmgr)
 {
return sizeof(struct cz_power_state);
 }
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 

[Bug 84771] nouveau MMIO read write FAULT HUB_INIT timed out errors

2016-10-22 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=84771

christtchin at gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[PATCH 3/3] drm/amdgpu: move function declaration to header file

2016-10-22 Thread Baoyou Xie
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:37:6: warning: no previous prototype for 
'amdgpu_pm_acpi_event_handler' [-Wmissing-prototypes]

In fact, this function is defined in
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c, but should be declared
in a header file. So this patch moves the function declaration
to drivers/gpu/drm/amd/amdgpu/amdgpu.h.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 039b57e..c0bc42b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -2145,6 +2145,8 @@ void amdgpu_io_wreg(struct amdgpu_device *adev, u32 reg, 
u32 v);
 u32 amdgpu_mm_rdoorbell(struct amdgpu_device *adev, u32 index);
 void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 index, u32 v);

+void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);
+
 /*
  * Registers read & write functions.
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 5796539..d77d630 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -33,7 +33,6 @@
 #include "amd_acpi.h"
 #include "atom.h"

-extern void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev);
 /* Call the ATIF method
  */
 /**
-- 
2.7.4



[PATCH 2/3] drm/amdgpu: mark symbols static where possible

2016-10-22 Thread Baoyou Xie
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/si.c:908:5: warning: no previous prototype for 
'si_pciep_rreg' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/si.c:921:6: warning: no previous prototype for 
'si_pciep_wreg' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/si.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index dc9511c..bacdff8 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -905,7 +905,7 @@ static void si_pcie_wreg(struct amdgpu_device *adev, u32 
reg, u32 v)
spin_unlock_irqrestore(>pcie_idx_lock, flags);
 }

-u32 si_pciep_rreg(struct amdgpu_device *adev, u32 reg)
+static u32 si_pciep_rreg(struct amdgpu_device *adev, u32 reg)
 {
unsigned long flags;
u32 r;
@@ -918,7 +918,7 @@ u32 si_pciep_rreg(struct amdgpu_device *adev, u32 reg)
return r;
 }

-void si_pciep_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
+static void si_pciep_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
 {
unsigned long flags;

-- 
2.7.4



[PATCH 1/3] drm/amdgpu: change function declarations and add missing header dependencies

2016-10-22 Thread Baoyou Xie
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/amd/amdgpu/atombios_crtc.c:38:6: warning: no previous prototype 
for 'amdgpu_atombios_crtc_overscan_setup' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/dce_v8_0.c:661:6: warning: no previous prototype for 
'dce_v8_0_disable_dce' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:40:5: warning: no previous prototype 
for 'amdgpu_gfx_scratch_get' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:62:6: warning: no previous prototype 
for 'amdgpu_gfx_scratch_free' [-Wmissing-prototypes]


In fact, these functions are declared in
drivers/gpu/drm/amd/amdgpu/atombios_crtc.h
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
drivers/gpu/drm/amd/amdgpu/dce_v8_0.h
drivers/gpu/drm/amd/amdgpu/dce_v10_0.h
drivers/gpu/drm/amd/amdgpu/dce_v11_0.h
drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h.
So this patch adds missing header dependencies.

By the way, this patch changes declaration of amdgpu_gfx_parse_disable_cu()
to subject to its implement, and clean three function declarations
in pp_acpi.h up.

Signed-off-by: Baoyou Xie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c   | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h   | 3 ++-
 drivers/gpu/drm/amd/amdgpu/atombios_crtc.c| 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 1 +
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 1 +
 drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 1 +
 drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h   | 9 +++--
 8 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index a074edd..01a42b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -24,6 +24,7 @@
  */
 #include 
 #include "amdgpu.h"
+#include "amdgpu_gfx.h"

 /*
  * GPU scratch registers helpers function.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
index 51321e1..abd9432 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
@@ -27,6 +27,7 @@
 int amdgpu_gfx_scratch_get(struct amdgpu_device *adev, uint32_t *reg);
 void amdgpu_gfx_scratch_free(struct amdgpu_device *adev, uint32_t reg);

-unsigned amdgpu_gfx_parse_disable_cu(unsigned *mask, unsigned max_se, unsigned 
max_sh);
+void amdgpu_gfx_parse_disable_cu(unsigned int *mask, unsigned int max_se,
+   unsigned int max_sh);

 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
index f7d236f..8c9bc75 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
@@ -31,6 +31,7 @@
 #include "atom.h"
 #include "atom-bits.h"
 #include "atombios_encoders.h"
+#include "atombios_crtc.h"
 #include "amdgpu_atombios.h"
 #include "amdgpu_pll.h"
 #include "amdgpu_connectors.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index 4108c68..443b35f 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -31,6 +31,7 @@
 #include "atombios_encoders.h"
 #include "amdgpu_pll.h"
 #include "amdgpu_connectors.h"
+#include "dce_v10_0.h"

 #include "dce/dce_10_0_d.h"
 #include "dce/dce_10_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index f264b8f..d58638c 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -31,6 +31,7 @@
 #include "atombios_encoders.h"
 #include "amdgpu_pll.h"
 #include "amdgpu_connectors.h"
+#include "dce_v11_0.h"

 #include "dce/dce_11_0_d.h"
 #include "dce/dce_11_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 5966166..dd5838c 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -31,6 +31,7 @@
 #include "atombios_encoders.h"
 #include "amdgpu_pll.h"
 #include "amdgpu_connectors.h"
+#include "dce_v8_0.h"

 #include "dce/dce_8_0_d.h"
 #include "dce/dce_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index 1944d28..f5e8fda 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -25,6 +25,7 @@
 #include "linux/delay.h"
 #include "hwmgr.h"
 #include "amd_acpi.h"
+#include "pp_acpi.h"

 bool acpi_atcs_functions_supported(void *device, uint32_t index)
 {
diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h 
b/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
index 3df5de2..8fe8ba9 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/pp_acpi.h
@@ -21,9 +21,6 @@
  *
  */

-extern bool acpi_atcs_functions_supported(void *device,
-   

[Bug 95551] Firewatch: Missing elements in menu

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95551

--- Comment #5 from Sven Arvidsson  ---
(In reply to Marek Olšák from comment #4)
> Does it still occur with current Mesa git?

In native resolution it actually seems fine on both 12.0.3 and current git
(also fine on i965 with 12.0.3). 

The problem with clipping in non native resolution persists, but it seems to be
either a game bug or something more general to Mesa.

I'm fine with calling this FIXED.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/4a594a93/attachment-0001.html>


[Bug 84771] nouveau MMIO read write FAULT HUB_INIT timed out errors

2016-10-22 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=84771

Bruno Pagani  changed:

   What|Removed |Added

 CC||bruno.n.pagani at gmail.com

--- Comment #4 from Bruno Pagani  ---
Yes, this must be https://bugzilla.freedesktop.org/show_bug.cgi?id=70354 and
should be fixed now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 85791] nouveau: errors on boot, can't use discrete gpu

2016-10-22 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=85791

Bruno Pagani  changed:

   What|Removed |Added

 CC||bruno.n.pagani at gmail.com

--- Comment #5 from Bruno Pagani  ---
Yes, this was probably https://bugzilla.freedesktop.org/show_bug.cgi?id=70354
and should be fixed now.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 98146] DRI_PRIME=1 and fullscreen issues

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98146

--- Comment #16 from Darek Deoniziak  ---
Did some more testing with DRI3 and DRI_PRIME=1 to run programs using radeon.
1. is solved with DRI3 as I did mention in last comment
2. Found big new isse about that, screen is not only cutted to half in some
fullscreen games (issue happens while playing Serious Sam 3), but it feels like
gpu plays few frames for few milliseconds then it plays these frames again
(everything feels worse than small fps). It happens not only in fullscreen
applications, if I run genymotion (emulator for Android devices) then the same
thing happens. Changing vsync doesn't help. Dota 2 works fine.
3. flickering still happens and additionaly this flashes from time to time,
usually when window is not focused: http://i.imgur.com/D0XniPL.png The image
also shows cutted screen to half which happens quite often.
4. solved with DRI3, no freezing after closing fullscreen programs
5. solved with DRI3, no issues with external monitor.

What options I could try to solve above issues? 2nd is now the biggest one.
Tried for both radeon and intel:
Option "SwapBuffersWait" "0"
Option "TearFree" "true" (also tried "on", is there any difference?)

Noone did help radeon, intel is working fine for both DRI2 and DRI3 (all above
issues are related radeon).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/aaa238d8/attachment.html>


[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

2016-10-22 Thread Daniel Vetter
On Sat, Oct 22, 2016 at 10:47:25AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> > This function provides a way for the driver to redo a
> > modeset on the current mode and retry the link training
> > at a lower link rate/lane count/bpp. This will get called
> > incase the link training fails during the current modeset.
> > 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 58 
> > +
> >  include/drm/drm_atomic_helper.h |  1 +
> >  2 files changed, 59 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index f936276..0c1614e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> > drm_connector *connector,
> >  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
> >  
> >  /**
> > + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> > + * @connector: DRM connector
> > + *
> > + * Provides a way to redo a modeset with the current mode so that it can
> > + * drop the bpp, link rate/lane count and retry the link training.
> > + *
> > + * Returns:
> > + * Returns 0 on success, negative errno numbers on failure.
> > + */
> > +int
> > +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +   struct drm_modeset_acquire_ctx ctx;
> > +   struct drm_atomic_state *state;
> > +   struct drm_connector_state *connector_state;
> > +   struct drm_crtc_state *crtc_state;
> > +   int ret = 0;
> > +
> > +   drm_modeset_acquire_init(, 0);
> > +   state = drm_atomic_state_alloc(dev);
> > +   if (!state) {
> > +   ret = -ENOMEM;
> > +   goto fail;
> > +   }
> > +   state->acquire_ctx = 
> > +retry:
> > +   ret = 0;
> > +   connector_state = drm_atomic_get_connector_state(state, connector);
> > +   if (IS_ERR(connector_state)) {
> > +   ret = PTR_ERR(connector_state);
> > +   goto fail;
> > +   }
> > +   if (!connector_state->crtc)
> > +   goto fail;
> > +
> > +   crtc_state = drm_atomic_get_existing_crtc_state(state,
> > +   connector_state->crtc);
> > +   crtc_state->connectors_changed = true;
> 
> This line here only works if the driver uses the helpers for checking and
> commit, and when it doesn't overwrite connectors_changed. I think the
> kerneldoc should mention this.
> 
> The other issue: You cannot call this from modeset code itself because of
> recursion. I think this also must be mentioned.

And if this indeed does a modeset then we have again the same issue as
with upfront link training when the pipe is supposed to be on: Userspace
can observe the kernel playing tricks because the vblank support will be
temporarily disabled.

Not sure how to best fix this, but might be good to grab the crtc->mutex
in the vblank code for stuff like this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Bug 177041] When browsing Google Map's Satellite view in Chrome or Firefox the screen freezes and goes black, occasionally control is returned to user

2016-10-22 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=177041

--- Comment #2 from Kyle Gottfried  ---
This is resolved with upgrading to Ubuntu 16.10 (uses kernel 4.8), will follow
a backport request with Ubuntu. If anyone knows the commit that resolves this
issue please post.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video

2016-10-22 Thread Jean-Francois Moine
This patchset series adds HDMI audio and video support to the Allwinner
sun8i SoCs which include the display engine 2 (DE2).

A first submission in January for video on the H3 could not enter into
the mainline kernel due to the lack of license headers in Allwinner's
sources.

Recently, an announce about Tina OS for the R series
https://www.youtube.com/watch?v=h7KD-6HblAU
was followed by the upload of a new linux-3.4 source tree
https://github.com/tinalinux/linux-3.4
with files containing GPL headers.

Well, I don't know if these sources are really from Allwinner, but
anyway, this is the opportunity to propose a new version of my DRM
HDMI driver.

v5:
- add overlay plane
- add audio support
- add support for the A83T
- add back the HDMI driver
- many bug fixes
v4: 
- drivers/clk/sunxi/Makefile was missing (Emil Velikov)
v3:
- add the hardware cursor
- simplify and fix the DE2 init sequences
- generation for all SUNXI SoCs (Andre Przywara)
v2:
- remove the HDMI driver
- remarks from Chen-Yu Tsai and Russell King
- DT documentation added

Jean-Francois Moine (7):
  drm: sunxi: Add a basic DRM driver for Allwinner DE2
  ASoC: sunxi: Add a simple HDMI CODEC
  drm: sunxi: add DE2 HDMI support
  ASoC: sunxi: Add sun8i I2S driver
  ARM: dts: sun8i-h3: add HDMI audio and video nodes
  ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+
  ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2

 .../devicetree/bindings/display/sunxi/hdmi.txt |  52 ++
 .../bindings/display/sunxi/sunxi-de2.txt   |  83 ++
 .../devicetree/bindings/sound/sun4i-i2s.txt|  38 +-
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  17 +
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  17 +
 arch/arm/boot/dts/sun8i-h3.dtsi|  67 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/sunxi/Kconfig  |  29 +
 drivers/gpu/drm/sunxi/Makefile |   9 +
 drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +++
 drivers/gpu/drm/sunxi/de2_crtc.h   |  63 ++
 drivers/gpu/drm/sunxi/de2_de.c | 591 +
 drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
 drivers/gpu/drm/sunxi/de2_drv.c| 378 +
 drivers/gpu/drm/sunxi/de2_hdmi.c   | 396 +
 drivers/gpu/drm/sunxi/de2_hdmi.h   |  40 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.c| 927 +
 drivers/gpu/drm/sunxi/de2_hdmi_io.h|  25 +
 drivers/gpu/drm/sunxi/de2_plane.c  | 119 +++
 include/sound/sunxi_hdmi.h |  23 +
 sound/soc/codecs/Kconfig   |   9 +
 sound/soc/codecs/Makefile  |   2 +
 sound/soc/codecs/sunxi-hdmi.c  | 106 +++
 sound/soc/sunxi/Kconfig|   8 +
 sound/soc/sunxi/Makefile   |   3 +
 sound/soc/sunxi/sun8i-i2s.c| 700 
 27 files changed, 4222 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_io.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c
 create mode 100644 include/sound/sunxi_hdmi.h
 create mode 100644 sound/soc/codecs/sunxi-hdmi.c
 create mode 100644 sound/soc/sunxi/sun8i-i2s.c

-- 
2.10.1



[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

2016-10-22 Thread Russell King - ARM Linux
On Wed, Oct 19, 2016 at 10:46:48AM +0100, Brian Starkey wrote:
> Hi Jyri,
> 
> I believe this will break mali-dp and hdlcd, unless something changed
> while I wasn't looking. Please see this previous thread where I did
> the same thing and then had to have it reverted: [1]
> 
> Before removing this, we need to refactor (at least) mali-dp and hdlcd
> to move drm_dev_register() to the end of their ->bind() callback.
> 
> That could be done without moving drm_dev_unregister() to the start
> of ->unbind() if you really want to nuke the drm_connector_register()
> call, but to maintain symmetry (and introduce correctness) I was
> putting it off until I had a chance to remove drm_vblank_cleanup()
> from drm_dev_unregister() (because [2]).

So what is the status of this - when is it going to happen?  Without
this happening, I can't de-midlayer armada-drm, and I can't apply
these TDA998x patches.

As armada-drm stands at the moment, it can cope with the TDA998x
driver having the drm_connector_register(), or with it eliminated.
When armada-drm is de-midlayered without changing TDA998x, the
drm_connector_register() call in TDA998x produces a warning:

WARNING: CPU: 0 PID: 13 at lib/kobject.c:244 kobject_add_internal+0xfc/0x2d8
kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)

I suspect that you will end up with the same problem when you move
the drm_dev_register() call after component_bind_all() - and I think
the answer is... you shouldn't have de-midlayered until TDA998x had
been updated to cope with de-midlayering, iow having had the
drm_connector_register() call removed.

Given that, I don't think we can avoid breaking mali-dp and hdlcd,
except by combining the change into a single patch, changing all three
drivers simultaneously (and any other driver which uses TDA998x which
has also been de-midlayered.)

So, what I would like to see is a single patch against Linus' 4.8.0
commit fixing mali-dp, hdlcd and any other driver, together with
removing drm_connector_register() from TDA998x.  This is so the patch
can be shared between all interested parties without forcing everyone
to 4.9-rc1.  Looking at the diff between 4.8 and 4.9-rc1 for
drivers/gpu/drm/arm, that shouldn't result in any merge conflicts -
and if you want to follow on from that with 4.9-rc1 development, you
can always merge 4.9-rc1 on top of that commit.

I'm happy to take such a patch and publish it via my git tree as part
of the TDA998x development if that helps - but either way we need it
shared between all parties.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

2016-10-22 Thread Laurent Pinchart
Hi Jean-François,

On Friday 21 Oct 2016 19:28:47 Jean-Francois Moine wrote:
> On Thu, 20 Oct 2016 16:56:44 +0530 Archit Taneja wrote:
> >> Please show _technically_ how this would work.  I want to see code or
> >> pseudo-code illustrating how a "foreign" DRM encoder could be used with
> >> either dw-hdmi or tda998x, because right now I can't see any way that
> >> could work.
> > 
> > This is something we already do with the adv7511 bridge driver on msm,
> > rcar and arc (for 4.9) drivers.
> > 
> > I've shared pseudo code on the kms driver and encoder chip's driver
> > side. I've also shared a diff that converts the tda998x driver to use
> > drm_bridge(uncompiled/untested).
> > 
> > 1) Kms driver side:
> > 
> > /*
> > 
> >   * Create an encoder instance. Depending on the hardware represented
> >   * by the KMS driver, the encoder can ops can either have some
> >   * functionality, or be nops. In the case of tilcdc, the encoder
> >   * funcs would be mostly nops.
> >   */
> > 
> > drm_encoder_helper_add(_priv->encoder, _encoder_helper_funcs);
> > drm_encoder_init(kms_pirv->drm, _priv->encoder, _encoder_funcs,
> > 
> >  type, NULL);
> 
> Then, how does this 'kms_priv' know the type of the encoder, this one
> being tied to the connector type at the end of the bridge chain?

"[PATCH 4/8] drm: Add encoder_type field to the drm_bridge structure"

:-)

-- 
Regards,

Laurent Pinchart



[PATCH 2/2] drm/i915/gvt: fix compilation

2016-10-22 Thread Zhenyu Wang
On 2016.10.21 17:25:50 +0200, Arnd Bergmann wrote:
> Two functions in the newly added gvt render code are obviously
> broken, as they reference a variable without initialization and
> don't reference another variable at all:
> 
> drivers/gpu/drm/i915/gvt/render.c: In function 
> ???intel_gvt_load_render_mmio???:
> drivers/gpu/drm/i915/gvt/render.c:148:13: error: ???offset.reg??? may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> drivers/gpu/drm/i915/gvt/render.c: In function 
> ???intel_gvt_restore_render_mmio???:
> drivers/gpu/drm/i915/gvt/render.c:185:13: error: ???offset.reg??? may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This is probably not a correct fix, but it gets us a clean build
> by removing the unused arrays and initializing the offset variable
> to something that potentially might be correct.
> 
> Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch")
> Signed-off-by: Arnd Bergmann 
> ---

I think the correct fix is like

diff --git a/drivers/gpu/drm/i915/gvt/render.c 
b/drivers/gpu/drm/i915/gvt/render.c
index feebb65..cc23c3f 100644
--- a/drivers/gpu/drm/i915/gvt/render.c
+++ b/drivers/gpu/drm/i915/gvt/render.c
@@ -162,6 +162,7 @@ static void load_mocs(struct intel_vgpu *vgpu, int ring_id)
if (!IS_SKYLAKE(dev_priv))
return;

+   offset.reg = regs[ring_id];
for (i = 0; i < 64; i++) {
gen9_render_mocs[ring_id][i] = I915_READ(offset);
I915_WRITE(offset, vgpu_vreg(vgpu, offset));
@@ -199,6 +200,7 @@ static void restore_mocs(struct intel_vgpu *vgpu, int 
ring_id)
if (!IS_SKYLAKE(dev_priv))
return;

+   offset.reg = regs[ring_id];
for (i = 0; i < 64; i++) {
vgpu_vreg(vgpu, offset) = I915_READ(offset);
I915_WRITE(offset, gen9_render_mocs[ring_id][i]);

Thanks for pointing this out, it's a mistake during our code preparation for 
upstream.
I'll queue this up.

>  drivers/gpu/drm/i915/gvt/render.c | 25 +++--
>  1 file changed, 3 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> b/drivers/gpu/drm/i915/gvt/render.c
> index feebb65ba641..79e112288065 100644
> --- a/drivers/gpu/drm/i915/gvt/render.c
> +++ b/drivers/gpu/drm/i915/gvt/render.c
> @@ -147,29 +147,20 @@ static void load_mocs(struct intel_vgpu *vgpu, int 
> ring_id)
>  {
>   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>   i915_reg_t offset, l3_offset;
> - u32 regs[] = {
> - [RCS] = 0xc800,
> - [VCS] = 0xc900,
> - [VCS2] = 0xca00,
> - [BCS] = 0xcc00,
> - [VECS] = 0xcb00,
> - };
>   int i;
>  
> - if (WARN_ON(ring_id >= ARRAY_SIZE(regs)))
> - return;
> -
>   if (!IS_SKYLAKE(dev_priv))
>   return;
>  
>   for (i = 0; i < 64; i++) {
> + offset.reg = i * 4;
>   gen9_render_mocs[ring_id][i] = I915_READ(offset);
>   I915_WRITE(offset, vgpu_vreg(vgpu, offset));
>   POSTING_READ(offset);
> - offset.reg += 4;
>   }
>  
>   if (ring_id == RCS) {
> + offset.reg = 64 * 4;
>   l3_offset.reg = 0xb020;
>   for (i = 0; i < 32; i++) {
>   gen9_render_mocs_L3[i] = I915_READ(l3_offset);
> @@ -184,26 +175,16 @@ static void restore_mocs(struct intel_vgpu *vgpu, int 
> ring_id)
>  {
>   struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>   i915_reg_t offset, l3_offset;
> - u32 regs[] = {
> - [RCS] = 0xc800,
> - [VCS] = 0xc900,
> - [VCS2] = 0xca00,
> - [BCS] = 0xcc00,
> - [VECS] = 0xcb00,
> - };
>   int i;
>  
> - if (WARN_ON(ring_id >= ARRAY_SIZE(regs)))
> - return;
> -
>   if (!IS_SKYLAKE(dev_priv))
>   return;
>  
>   for (i = 0; i < 64; i++) {
> + offset.reg = i * 4;
>   vgpu_vreg(vgpu, offset) = I915_READ(offset);
>   I915_WRITE(offset, gen9_render_mocs[ring_id][i]);
>   POSTING_READ(offset);
> - offset.reg += 4;
>   }
>  
>   if (ring_id == RCS) {
> -- 
> 2.9.0
> 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/9d8bdb17/attachment.sig>


[PATCH v5 7/7] ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2

2016-10-22 Thread Jean-Francois Moine
Signed-off-by: Jean-Francois Moine 
---
The same patch may be applied to other H3 based boards (Orange PI xx).
---
 arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
index e5bcaba..799ceb9 100644
--- a/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/boot/dts/sun8i-h3-orangepi-2.dts
@@ -56,6 +56,7 @@
serial0 = 
/* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
ethernet1 = 
+   lcd0 = 
};

chosen {
@@ -105,16 +106,32 @@
};
 };

+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };

+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };

+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.1



[PATCH 1/2] drm/i915/gvt: add ACPI and 64BIT dependencies

2016-10-22 Thread Zhenyu Wang
On 2016.10.21 17:25:49 +0200, Arnd Bergmann wrote:
> The newly added gvt code produces lots of serious warnings and errors
> when either built on 32-bit x86, or built with ACPI disabled, e.g.
> 
> drivers/gpu/drm/i915/gvt/gtt.c: In function ???read_pte64???:
> drivers/gpu/drm/i915/gvt/gtt.c:277:2: error: left shift count >= width of 
> type [-Werror]
> drivers/gpu/drm/i915/gvt/gtt.c: In function ???gen8_gtt_get_pfn???:
> drivers/gpu/drm/i915/gvt/gtt.c:360:3: error: left shift count >= width of 
> type [-Werror]
> drivers/gpu/drm/i915/gvt/opregion.c: In function 
> ???intel_gvt_init_opregion???:
> drivers/gpu/drm/i915/gvt/opregion.c:183:2: error: implicit declaration of 
> function ???acpi_os_ioremap??? [-Werror=implicit-function-declaration]
> 
> This avoids the problems by simply disallowing those configurations
> in Kconfig. I'm sure it's possible to make the code more portable
> and support building GVT without those options, but it might not be
> useful to do so.
> 
> Fixes: 4d60c5fd3f87 ("drm/i915/gvt: vGPU PCI configuration space 
> virtualization")
> Signed-off-by: Arnd Bergmann 
> ---
> If the code is meant to work on 32-bit and non-ACPI kernels, please
> treat this as a bug report and disregard the patch.
> ---

Thanks, Arnd. We have to depend on 64bit now and not require for ACPI,
as we used one acpi function for opregion mem map which is not necessary,
so I queued one 64bit dependence and another to remove acpi dependence for 
Daniel.

>  drivers/gpu/drm/i915/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 6d4194288d11..1b9308284dde 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -84,6 +84,7 @@ config DRM_I915_USERPTR
>  config DRM_I915_GVT
>  bool "Enable Intel GVT-g graphics virtualization host support"
>  depends on DRM_I915
> + depends on 64BIT && ACPI
>  default n
>  help
> Choose this option if you want to enable Intel GVT-g graphics
> -- 
> 2.9.0
> 

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/6e7ecd5a/attachment.sig>


[PATCH v5 6/7] ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+

2016-10-22 Thread Jean-Francois Moine
Signed-off-by: Jean-Francois Moine 
---
The patch for the Banana Pi M3 (A83T) is the same as this one.
---
 arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
index 06fddaa..2e81de8 100644
--- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
@@ -55,6 +55,7 @@
aliases {
serial0 = 
serial1 = 
+   lcd0 = 
};

chosen {
@@ -93,6 +94,10 @@
};
 };

+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
@@ -101,12 +106,24 @@
status = "okay";
 };

+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
status = "okay";
 };

+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin>;
-- 
2.10.1



[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95017

--- Comment #16 from erhard_f at mailbox.org ---
linux-4.8.3-gentoo # dmesg | grep -i agp
[0.00] Found U3-AGP PCI host bridge.  Firmware bus number: 240->255
[   79.271669] Linux agpgart interface v0.103
[   79.286888] agpgart-uninorth :f0:0b.0: Apple U3H chipset
[   79.300467] agpgart-uninorth :f0:0b.0: configuring for size idx: 64
[   79.308235] agpgart-uninorth :f0:0b.0: AGP aperture is 256M @ 0x0
[   82.883029] agpgart-uninorth :f0:0b.0: putting AGP V3 device into 8x
mode
[   82.883040] radeon :f0:10.0: putting AGP V3 device into 8x mode

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/1f7655f1/attachment-0001.html>


[Bug 95017] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95017

--- Comment #15 from erhard_f at mailbox.org ---
Played around a bit with xorg and kernel options on my G5 and worked out that I
can drive the Radeon 9650 at AGP x8 if I disable DRI completely via Option
"NoAccel" "true" in /etc/xorg.conf.

I had no GPU-lockups since then and xorg is much more responsive despite
lacking DRI hardware acceleration (radeon.agpmode=-1 with DRI enabled).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/1ca11886/attachment.html>


[Bug 98162] gpu hangs with unigine heaven on drm-next-4.9-wip

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=98162

--- Comment #5 from Christoph Haag  ---
unigine heaven and csgo work fine with amdgpu-staging-4.7
f9c58ccc03147e652284f06053b089eca957e1e1

with drm-next-4.10 (with 87744ab3832b83ba71b931f86f9cfdb000d07da5) reverted for
performance, unigine heaven works (I think), but csgo causes gpu hangs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/6c6f253f/attachment.html>


[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

2016-10-22 Thread Russell King - ARM Linux
On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
>  On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
>   (sorry, I lost your original mail)
> > >>> DRM bridges indeed don't create encoders. That task is left to the 
> > >>> display
> > >>> driver. The reason is the same as above: bridges can be chained 
> > >>> (including
> > >>> with an internal encoder that is not modelled as a bridge, and that's a 
> > >>> case
> > >>> we have today), while the KMS model exposes a single encoder to 
> > >>> userspace.
> > >>> Exposing DRM encoder objects as part of the KMS UABI was probably a 
> > >>> mistake.
> > >>> Better solutions would have been to expose no encoder at all or all 
> > >>> encoders
> > >>> in the chain. We are however stuck with this model as we can't break 
> > >>> the UABI.
> > >>> For that reason a DRM encoder object doesn't represent an encoder but a 
> > >>> chain
> > >>> of encoders. As a DRM bridge models a single encoder, the DRM encoder 
> > >>> object
> > >>> must be created at a higher level, in the display driver.
> 
> I wonder why you created 'bridge's instead of simply adding links to
> the encoders? (that's what ASoC did: the audio CODECs are linked)
> This way, in simple cases (most cases), there would have been
>   crtc -> (encoder -> connector)
> instead of
>   crtc -> (bridge + encoder) -> (bridge + connector) 
> without any changes in the actual (encoder + connector)s.

Looking at drm_bridge_disable() and drm_bridge_enable(), the control
model appears to be:

crtc -> encoder -> connector
 `-> bridge
 `-> bridge
 `-> bridge

Bridges are always attached to an encoder, and there can be multiple
bridges attached to one encoder.  Bridges can't be attached to the
connector.

So, in the case of TDA998x, we end up with the TDA998x providing a
connector, because it has connector functionality, and providing a
bridge.  The encoder is left to the KMS driver, which adds additional
complexity (100+ lines) to each and every KMS driver, requiring the
KMS driver to have much more knowledge of what's attached to the
"CRTC", so it can create these encoders itself.  I still think this
is a backwards step - maybe one step forwards, two backwards.

Even if we were to provide helpers to create a dummy encoder to
work around the DRM bridge model short-comings, much of the 100+
lines is to do with working out whether or not we need to create an
encoder, and parsing the information we need to create that in a way
that existing DT doesn't break.

Then there's the fact that the bridge approach breaks non-DT at the
moment, because DRM bridge fundamentally requires DT.  This makes
DRM bridge useless for architectures which aren't DT aware, such as
x86.  So, converting drivers to be a DRM bridge effectively denies
their use on other architectures.  See drm_bridge.c, and look for
the references to bridge_list, noting that there are two: one which
adds to the bridge list, and one under #ifdef CONFIG_OF which looks
up a DT reference to a bridge.

There's another issue with TDA998x - we now have audio support in
TDA998x, and converting TDA998x to be a DRM bridge introduces some
fundamental (and as yet unsolved) races between the ASoC code and
the attachment of the DRM bridge to the DRM encoder, and the detachment
when the DRM bridge/connector gets cleaned up.  Right now, there's no
bridge callback when the encoder or drm_device goes away, so doing
stuff like:

static int tda998x_audio_get_eld(struct device *dev, void *data,
 uint8_t *buf, size_t len)
{
struct tda998x_priv *priv = dev_get_drvdata(dev);
struct drm_mode_config *config;
struct drm_connector *connector;
int ret = -ENODEV;

/* FIXME: This is racy */
if (!priv->bridge.encoder || !priv->bridge.encoder->dev)
return ret;

config = >bridge.encoder->dev->mode_config;

mutex_lock(>mutex);
list_for_each_entry(connector, >connector_list, head) {
if (priv->bridge.encoder == connector->encoder) {
memcpy(buf, connector->eld,
   min(sizeof(connector->eld), len));
ret = 0;
}
}
mutex_unlock(>mutex);

feels very unsafe - nothing really guarantees the validity of the
priv->bridge.encoder or priv->bridge.encoder->dev pointers.  The
config->mutex lock does nothing to solve this.  The same problem
also exists in tda998x_audio_hw_params().

Anyway, the whole bridge conversion thing is moot until every user
of the TDA998x code has been updated to cope with the lack of
drm_connector_register() inside TDA998x - see Brian Starkey's
response to this patch set.  It's also moot if it breaks armada-drm.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 

[Bug 93649] [radeonsi] Graphics lockup while playing tf2

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93649

--- Comment #47 from Amarildo  ---
In all honesty, this is one of the most interesting bugs I know. Within all the
people that have it, there are variations to which causes it in the first
place.

What works for me (Debian Jessie with Mesa/libc6 from Backports, for example)
might still cause the crash for some people.

What I do know is that it's not caused by faulty hardware. It could be for
some, but seriously doubt it it's the cause for 99.99% of people experiencing
the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/e026b1a9/attachment.html>


[Intel-gfx] [PATCH 2/5] drm: Define a work struct for scheduling a uevent for modeset retry

2016-10-22 Thread Daniel Vetter
On Fri, Oct 21, 2016 at 04:45:40PM -0700, Manasi Navare wrote:
> This work struct will be used to schedule a uevent on a separate
> thread. This will be scheduled after a link train failure during modeset
> to indicate a modeset retry request. It will get executed after the
> current modeset is complete and all locks are released. This was
> required to avoid deadlock.
> 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_connector.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ac9d7d8..fcf6b97 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -682,6 +682,11 @@ struct drm_connector {
>   uint8_t num_h_tile, num_v_tile;
>   uint8_t tile_h_loc, tile_v_loc;
>   uint16_t tile_h_size, tile_v_size;
> +
> + /* Work struct to schedule a uevent on link train failure for
> +  * DisplayPort.
> +  */
> + struct work_struct i915_modeset_retry_work;

You cannot put i915 stuff into core structs.
-Daniel

>  };
>  
>  #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

2016-10-22 Thread Daniel Vetter
On Fri, Oct 21, 2016 at 04:45:39PM -0700, Manasi Navare wrote:
> This function provides a way for the driver to redo a
> modeset on the current mode and retry the link training
> at a lower link rate/lane count/bpp. This will get called
> incase the link training fails during the current modeset.
> 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 58 
> +
>  include/drm/drm_atomic_helper.h |  1 +
>  2 files changed, 59 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f936276..0c1614e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2895,6 +2895,64 @@ int drm_atomic_helper_connector_dpms(struct 
> drm_connector *connector,
>  EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
>  
>  /**
> + * drm_atomic_helper_connector_modeset - Force a modeset on a connector
> + * @connector: DRM connector
> + *
> + * Provides a way to redo a modeset with the current mode so that it can
> + * drop the bpp, link rate/lane count and retry the link training.
> + *
> + * Returns:
> + * Returns 0 on success, negative errno numbers on failure.
> + */
> +int
> +drm_atomic_helper_connector_modeset(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_modeset_acquire_ctx ctx;
> + struct drm_atomic_state *state;
> + struct drm_connector_state *connector_state;
> + struct drm_crtc_state *crtc_state;
> + int ret = 0;
> +
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> + state->acquire_ctx = 
> +retry:
> + ret = 0;
> + connector_state = drm_atomic_get_connector_state(state, connector);
> + if (IS_ERR(connector_state)) {
> + ret = PTR_ERR(connector_state);
> + goto fail;
> + }
> + if (!connector_state->crtc)
> + goto fail;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + connector_state->crtc);
> + crtc_state->connectors_changed = true;

This line here only works if the driver uses the helpers for checking and
commit, and when it doesn't overwrite connectors_changed. I think the
kerneldoc should mention this.

The other issue: You cannot call this from modeset code itself because of
recursion. I think this also must be mentioned.
-Daniel

> + ret = drm_atomic_commit(state);
> +fail:
> + if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + if (state)
> + drm_atomic_state_put(state);
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_modeset);
> +
> +/**
>   * drm_atomic_helper_best_encoder - Helper for _connector_helper_funcs
>   *  ->best_encoder callback
>   * @connector: Connector control structure
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index 7ff92b0..8de24dc 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -126,6 +126,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   uint32_t flags);
>  int drm_atomic_helper_connector_dpms(struct drm_connector *connector,
>int mode);
> +int drm_atomic_helper_connector_modeset(struct drm_connector *connector);
>  struct drm_encoder *
>  drm_atomic_helper_best_encoder(struct drm_connector *connector);
>  
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH v2 3/6] drm: RIP mode_config->rotation_property

2016-10-22 Thread Daniel Vetter
On Fri, Oct 21, 2016 at 10:22:45PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> Now that all drivers have been converted over to the per-plane rotation
> property, we can just nuke the global rotation property.
> 
> v2: Rebase due to BIT(),__builtin_ffs() & co.
> Deal with superfluous code shuffling
> 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Joonas Lahtinen 

Merged up to this patch. I think it's better to land the follow-up i915
patches through drm-intel. I'll do backmerges next week anyway, you won't
need to wait long.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_atomic.c|  6 ++
>  drivers/gpu/drm/drm_blend.c | 32 
>  drivers/gpu/drm/drm_fb_helper.c |  7 +--
>  include/drm/drm_blend.h |  2 --
>  include/drm/drm_crtc.h  |  5 -
>  5 files changed, 7 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f81706387889..1b5a32df9a9a 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -705,8 +705,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_ROTATE_MASK))
>   return -EINVAL;
>   state->rotation = val;
> @@ -766,8 +765,7 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
>   *val = state->zpos;
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index e52aece30900..1f2412c7ccfd 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -89,7 +89,7 @@
>   * On top of this basic transformation additional properties can be exposed 
> by
>   * the driver:
>   *
> - * - Rotation is set up with drm_mode_create_rotation_property(). It adds a
> + * - Rotation is set up with drm_plane_create_rotation_property(). It adds a
>   *   rotation and reflection step between the source and destination 
> rectangles.
>   *   Without this property the rectangle is only scaled, but not rotated or
>   *   reflected.
> @@ -105,18 +105,12 @@
>   */
>  
>  /**
> - * drm_mode_create_rotation_property - create a new rotation property
> - * @dev: DRM device
> + * drm_plane_create_rotation_property - create a new rotation property
> + * @plane: drm plane
> + * @rotation: initial value of the rotation property
>   * @supported_rotations: bitmask of supported rotations and reflections
>   *
>   * This creates a new property with the selected support for transformations.
> - * The resulting property should be stored in @rotation_property in
> - * _mode_config. It then must be attached to each plane which supports
> - * rotations using drm_object_attach_property().
> - *
> - * FIXME: Probably better if the rotation property is created on each plane,
> - * like the zpos property. Otherwise it's not possible to allow different
> - * rotation modes on different planes.
>   *
>   * Since a rotation by 180° degress is the same as reflecting both along 
> the x
>   * and the y axis the rotation property is somewhat redundant. Drivers can 
> use
> @@ -144,24 +138,6 @@
>   * rotation. After reflection, the rotation is applied to the image sampled 
> from
>   * the source rectangle, before scaling it to fit the destination rectangle.
>   */
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device 
> *dev,
> -unsigned int 
> supported_rotations)
> -{
> - static const struct drm_prop_enum_list props[] = {
> - { __builtin_ffs(DRM_ROTATE_0) - 1,   "rotate-0" },
> - { __builtin_ffs(DRM_ROTATE_90) - 1,  "rotate-90" },
> - { __builtin_ffs(DRM_ROTATE_180) - 1, "rotate-180" },
> - { __builtin_ffs(DRM_ROTATE_270) - 1, "rotate-270" },
> - { __builtin_ffs(DRM_REFLECT_X) - 1,  "reflect-x" },
> - { __builtin_ffs(DRM_REFLECT_Y) - 1,  "reflect-y" },
> - };
> -
> - return drm_property_create_bitmask(dev, 0, "rotation",
> -props, ARRAY_SIZE(props),
> -supported_rotations);
> -}
> -EXPORT_SYMBOL(drm_mode_create_rotation_property);
> -
>  int drm_plane_create_rotation_property(struct 

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

2016-10-22 Thread Daniel Vetter
On Fri, Oct 21, 2016 at 09:02:27PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 08:19:03PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote:
> > > I think of a use for sending an empty clip: where you don't want to
> > > push any new pixel data, but you do want to be sure that the pipeline
> > > has been flushed.
> > 
> > What exactly should an empty rectangle flush out? It's a bit unclear, but
> > for speed I guess drivers should be allowed to make dirty async ...
> 
> No idea! I'm just speculating that I can see a use for a dirtyfb barrier
> even with an empty cliprect. Empty clips are a useful distinction
> elsewhere that I would suggest not forbidding them outright but defining
> their behaviour.

In general I prefer clarifying unused and undefined cases to "reject
them". We can always add a cap later on when we want to give them some
real meaning.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[Bug 178281] wine-staging apps freezes the machine with RX460

2016-10-22 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=178281

--- Comment #10 from fin4478 at hotmail.com ---
Inspired by  internet discussions of the amdgpu driver, I played Team Fortress
2 native version from Steam and the game hangs my machine in the practice mode
in couple of minutes. I need to reboot like I need to with TR2013 windows game.
Amd should increase the stability of this driver.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


[Bug 93649] [radeonsi] Graphics lockup while playing tf2

2016-10-22 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93649

--- Comment #46 from hofmann.zachary at gmail.com ---
(In reply to Amarildo from comment #45)
> Faulty hardware doesn't make any sense, because:
> 
> - It only happens on Linux;
> - It only happens with specific combinations of Mesa/LLVM/Kernel/Firmware/etc
> - It doesn't happen with the proprietary drivers

It's probably not the exact same crash, but FWIW I also get crashes with the
proprietary driver and TF2 when I tested it last. I just don't want people to
get their hopes up only to have them let down.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161022/a9830f41/attachment-0001.html>