[PATCH] drm/amd/powerplay: don't give up if DPM is already running

2016-10-15 Thread Grazvydas Ignotas
Hi,

On Thu, Oct 13, 2016 at 10:45 AM, Zhu, Rex  wrote:
>
> The attached patches were also for this issue.
> Disable dpm when rmmod amdgpu.

It works for modprobe-rmmod-modprobe test, thanks.

However with GPU passthrough (giving control of the GPU to a Windows
virtual machine using iommu, then shutting down the VM and loading
amdgpu) the problem is still there, same backtrace as in my commit
message. It seems the Windows driver leaves DPM enabled on shutdown.
With my patch the crash goes away.

It would be nice to have GPU passthrough working, this is the only
issue that breaks it. Windows can drive the GPU after amdgpu fine
already, only amdgpu has problems to run after Windows.

Gražvydas


[PATCH 2/2] ARM: dts: da850: add a node for the LCD controller

2016-10-15 Thread Bartosz Golaszewski
2016-10-15 19:42 GMT+02:00 Sekhar Nori :
> On Wednesday 05 October 2016 06:35 PM, Bartosz Golaszewski wrote:
>> From: Karl Beldan 
>>
>> Add pins used by the LCD controller and a disabled LCDC node to be
>> reused in device trees including da850.dtsi.
>>
>> Signed-off-by: Karl Beldan 
>> [Bartosz:
>>   - added the commit description
>>   - changed the dt node name to a generic one
>>   - added a da850-specific compatible string
>>   - removed the tilcdc,panel node
>>   - moved the pins definitions to da850.dtsi as suggested by
>> Sekhar Nori (was in: da850-lcdk.dts)]
>> Signed-off-by: Bartosz Golaszewski 
>> ---
>>  arch/arm/boot/dts/da850.dtsi | 29 +
>>  1 file changed, 29 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b9..32908ae 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>
>> @@ -399,6 +420,14 @@
>>   < 0 1>;
>>   dma-names = "tx", "rx";
>>   };
>> +
>> + display: display at 213000 {
>> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>
> This should instead be:
>
> compatible = "ti,da850-tilcdc", "ti,am33xx-tilcdc";
>
> as the closest match should appear first in the list.
>
>> + reg = <0x213000 0x1000>;
>> + interrupt-parent = <>
>
> No need of specifying the interrupt-parent as it is assumed to be that
> from the parent node (soc) if left unspecified.
>
> I made these two fixes locally and pushed the two patches in this series
> to v4.10/dt branch of my tree (for URL see MAINTAINERS). Can you take a
> look and make sure I did not mess anything up?
>

Looks good, thanks!

Bartosz Golaszewski


[PATCH] drm/msm/mdp5: handle non-fullscreen base plane case

2016-10-15 Thread Archit Taneja


On 10/15/2016 6:38 PM, Rob Clark wrote:
> On Sat, Oct 15, 2016 at 8:57 AM, Archit Taneja  
> wrote:
>>
>>
>> On 10/15/2016 5:02 PM, Rob Clark wrote:
>>>
>>> On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja 
>>> wrote:


 On 10/13/2016 10:18 PM, Rob Clark wrote:
>
>
> If the bottom-most layer is not fullscreen, we need to use the BASE
> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
> blend_setup() code pretty much handled this already, we just had to
> figure this out in _atomic_check() and assign the stages appropriately.
>
> Signed-off-by: Rob Clark 
> ---
> TODO mdp4 might need similar treatment?
>
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 44
> 
>  1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index fa2be7c..e42f62d 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -223,11 +223,6 @@ static void blend_setup(struct drm_crtc *crtc)
> plane_cnt++;
> }
>
> -   /*
> -   * If there is no base layer, enable border color.
> -   * Although it's not possbile in current blend logic,
> -   * put it here as a reminder.
> -   */
> if (!pstates[STAGE_BASE] && plane_cnt) {
> ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
> DBG("Border Color is enabled");
> @@ -365,6 +360,15 @@ static int pstate_cmp(const void *a, const void *b)
> return pa->state->zpos - pb->state->zpos;
>  }
>
> +/* is there a helper for this? */
> +static bool is_fullscreen(struct drm_crtc_state *cstate,
> +   struct drm_plane_state *pstate)
> +{
> +   return (pstate->crtc_x == 0) && (pstate->crtc_y == 0) &&
> +   (pstate->crtc_w == cstate->mode.hdisplay) &&
> +   (pstate->crtc_h == cstate->mode.vdisplay);
> +}
> +
>  static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
>  {
> @@ -375,21 +379,11 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
> *crtc,
> struct plane_state pstates[STAGE_MAX + 1];
> const struct mdp5_cfg_hw *hw_cfg;
> const struct drm_plane_state *pstate;
> -   int cnt = 0, i;
> +   int cnt = 0, base = 0, i;
>
> DBG("%s: check", mdp5_crtc->name);
>
> -   /* verify that there are not too many planes attached to crtc
> -* and that we don't have conflicting mixer stages:
> -*/
> -   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
> drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state)
> {
> -   if (cnt >= (hw_cfg->lm.nb_stages)) {
> -   dev_err(dev->dev, "too many planes!\n");
> -   return -EINVAL;
> -   }
> -
> -
> pstates[cnt].plane = plane;
> pstates[cnt].state = to_mdp5_plane_state(pstate);
>
> @@ -399,8 +393,24 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
> *crtc,
> /* assign a stage based on sorted zpos property */
> sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
>
> +   /* if the bottom-most layer is not fullscreen, we need to use
> +* it for solid-color:
> +*/
> +   if (!is_fullscreen(state, [0].state->base))
> +   base++;
> +



 I get a crash here when fbcon is enabled and there are no connectors
 connected. We're trying to refer pstates[0] when there is no plane
 connected to the crtc. I guess we could bail out much earlier if cnt
 is 0.
>>>
>>>
>>> yeah, I hit that last night with no fbcon and killing the UI.. I've
>>> already fixed it up locally with an 'if (pstates[0].state &&
>>> !is_fullscreen())'
>>
>>
>> Okay, I guess we should probably memset pstates array to 0 in case the
>> stack memory has some older non NULL stuff in it.
>
> hmm, yeah, you are right.. I wonder how that wasn't already a
> problem..  I guess we at least always have an outgoing plane?  I guess
> changing the check to '(cnt > 0)' instead of 'pstates[0].state' would
> do the trick..
>
> fwiw, I pushed current version of this and the other patches to:
>
> https://github.com/freedreno/kernel-msm/commits/integration-linux-qcomlt-fences-2

thanks! I'll start using these patches too.

Archit

>
> BR,
> -R
>
>> Thanks,
>> Archit
>>
>>
>>>
>>> BR,
>>> -R
>>>
 Archit

> +   /* verify that there are not too many planes attached to crtc
> +* and that we don't have conflicting mixer stages:
> +

[PATCH] drm/msm/mdp5: handle non-fullscreen base plane case

2016-10-15 Thread Archit Taneja


On 10/15/2016 5:02 PM, Rob Clark wrote:
> On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja  
> wrote:
>>
>> On 10/13/2016 10:18 PM, Rob Clark wrote:
>>>
>>> If the bottom-most layer is not fullscreen, we need to use the BASE
>>> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
>>> blend_setup() code pretty much handled this already, we just had to
>>> figure this out in _atomic_check() and assign the stages appropriately.
>>>
>>> Signed-off-by: Rob Clark 
>>> ---
>>> TODO mdp4 might need similar treatment?
>>>
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 44
>>> 
>>>  1 file changed, 27 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>>> index fa2be7c..e42f62d 100644
>>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>>> @@ -223,11 +223,6 @@ static void blend_setup(struct drm_crtc *crtc)
>>> plane_cnt++;
>>> }
>>>
>>> -   /*
>>> -   * If there is no base layer, enable border color.
>>> -   * Although it's not possbile in current blend logic,
>>> -   * put it here as a reminder.
>>> -   */
>>> if (!pstates[STAGE_BASE] && plane_cnt) {
>>> ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
>>> DBG("Border Color is enabled");
>>> @@ -365,6 +360,15 @@ static int pstate_cmp(const void *a, const void *b)
>>> return pa->state->zpos - pb->state->zpos;
>>>  }
>>>
>>> +/* is there a helper for this? */
>>> +static bool is_fullscreen(struct drm_crtc_state *cstate,
>>> +   struct drm_plane_state *pstate)
>>> +{
>>> +   return (pstate->crtc_x == 0) && (pstate->crtc_y == 0) &&
>>> +   (pstate->crtc_w == cstate->mode.hdisplay) &&
>>> +   (pstate->crtc_h == cstate->mode.vdisplay);
>>> +}
>>> +
>>>  static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>>> struct drm_crtc_state *state)
>>>  {
>>> @@ -375,21 +379,11 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
>>> *crtc,
>>> struct plane_state pstates[STAGE_MAX + 1];
>>> const struct mdp5_cfg_hw *hw_cfg;
>>> const struct drm_plane_state *pstate;
>>> -   int cnt = 0, i;
>>> +   int cnt = 0, base = 0, i;
>>>
>>> DBG("%s: check", mdp5_crtc->name);
>>>
>>> -   /* verify that there are not too many planes attached to crtc
>>> -* and that we don't have conflicting mixer stages:
>>> -*/
>>> -   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>>> drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
>>> -   if (cnt >= (hw_cfg->lm.nb_stages)) {
>>> -   dev_err(dev->dev, "too many planes!\n");
>>> -   return -EINVAL;
>>> -   }
>>> -
>>> -
>>> pstates[cnt].plane = plane;
>>> pstates[cnt].state = to_mdp5_plane_state(pstate);
>>>
>>> @@ -399,8 +393,24 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
>>> *crtc,
>>> /* assign a stage based on sorted zpos property */
>>> sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
>>>
>>> +   /* if the bottom-most layer is not fullscreen, we need to use
>>> +* it for solid-color:
>>> +*/
>>> +   if (!is_fullscreen(state, [0].state->base))
>>> +   base++;
>>> +
>>
>>
>> I get a crash here when fbcon is enabled and there are no connectors
>> connected. We're trying to refer pstates[0] when there is no plane
>> connected to the crtc. I guess we could bail out much earlier if cnt
>> is 0.
>
> yeah, I hit that last night with no fbcon and killing the UI.. I've
> already fixed it up locally with an 'if (pstates[0].state &&
> !is_fullscreen())'

Okay, I guess we should probably memset pstates array to 0 in case the
stack memory has some older non NULL stuff in it.

Thanks,
Archit

>
> BR,
> -R
>
>> Archit
>>
>>> +   /* verify that there are not too many planes attached to crtc
>>> +* and that we don't have conflicting mixer stages:
>>> +*/
>>> +   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>>> +
>>> +   if ((cnt + base) >= hw_cfg->lm.nb_stages) {
>>> +   dev_err(dev->dev, "too many planes!\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> for (i = 0; i < cnt; i++) {
>>> -   pstates[i].state->stage = STAGE_BASE + i;
>>> +   pstates[i].state->stage = STAGE_BASE + i + base;
>>> DBG("%s: assign pipe %s on stage=%d", mdp5_crtc->name,
>>>
>>> pipe2name(mdp5_plane_pipe(pstates[i].plane)),
>>> pstates[i].state->stage);
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux 

[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

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

--- Comment #4 from Médéric Boquien  ---
It seems that I was running Wayland by accident. It works under X.org. Though
as I assume that things should keep working with Wayland too, I leave the bug
open for now. Feel free to close it otherwise.

-- 
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/20161015/e018f2ef/attachment.html>


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

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

--- Comment #34 from Micael Bergeron  ---
Created attachment 127319
  --> https://bugs.freedesktop.org/attachment.cgi?id=127319=edit
Shaders output folfer

MESA_SHADER_CAPTURE_PATH output folder.

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


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

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

--- Comment #33 from Marek Olšák  ---
The traces don't work. Let's assume it's an apitrace bug.

Running the traces can be done with: glretrace --benchmark [trace file]
glretrace is part of apitrace.

We can at least profile the compiler:
- please create an empty directory
- point this environment variable to it:
MESA_SHADER_CAPTURE_PATH=[path]
- play the game for a while... after that, the directory should contain a lot
of shader files
- please pack the directory and attach it

Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161015/070aa8c2/attachment.html>


[PATCH] drm/msm/mdp5: handle non-fullscreen base plane case

2016-10-15 Thread Archit Taneja

On 10/13/2016 10:18 PM, Rob Clark wrote:
> If the bottom-most layer is not fullscreen, we need to use the BASE
> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
> blend_setup() code pretty much handled this already, we just had to
> figure this out in _atomic_check() and assign the stages appropriately.
>
> Signed-off-by: Rob Clark 
> ---
> TODO mdp4 might need similar treatment?
>
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 44 
> 
>  1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index fa2be7c..e42f62d 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -223,11 +223,6 @@ static void blend_setup(struct drm_crtc *crtc)
>   plane_cnt++;
>   }
>
> - /*
> - * If there is no base layer, enable border color.
> - * Although it's not possbile in current blend logic,
> - * put it here as a reminder.
> - */
>   if (!pstates[STAGE_BASE] && plane_cnt) {
>   ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
>   DBG("Border Color is enabled");
> @@ -365,6 +360,15 @@ static int pstate_cmp(const void *a, const void *b)
>   return pa->state->zpos - pb->state->zpos;
>  }
>
> +/* is there a helper for this? */
> +static bool is_fullscreen(struct drm_crtc_state *cstate,
> + struct drm_plane_state *pstate)
> +{
> + return (pstate->crtc_x == 0) && (pstate->crtc_y == 0) &&
> + (pstate->crtc_w == cstate->mode.hdisplay) &&
> + (pstate->crtc_h == cstate->mode.vdisplay);
> +}
> +
>  static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>   struct drm_crtc_state *state)
>  {
> @@ -375,21 +379,11 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>   struct plane_state pstates[STAGE_MAX + 1];
>   const struct mdp5_cfg_hw *hw_cfg;
>   const struct drm_plane_state *pstate;
> - int cnt = 0, i;
> + int cnt = 0, base = 0, i;
>
>   DBG("%s: check", mdp5_crtc->name);
>
> - /* verify that there are not too many planes attached to crtc
> -  * and that we don't have conflicting mixer stages:
> -  */
> - hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>   drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> - if (cnt >= (hw_cfg->lm.nb_stages)) {
> - dev_err(dev->dev, "too many planes!\n");
> - return -EINVAL;
> - }
> -
> -
>   pstates[cnt].plane = plane;
>   pstates[cnt].state = to_mdp5_plane_state(pstate);
>
> @@ -399,8 +393,24 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>   /* assign a stage based on sorted zpos property */
>   sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
>
> + /* if the bottom-most layer is not fullscreen, we need to use
> +  * it for solid-color:
> +  */
> + if (!is_fullscreen(state, [0].state->base))
> + base++;
> +

I get a crash here when fbcon is enabled and there are no connectors
connected. We're trying to refer pstates[0] when there is no plane
connected to the crtc. I guess we could bail out much earlier if cnt
is 0.

Archit

> + /* verify that there are not too many planes attached to crtc
> +  * and that we don't have conflicting mixer stages:
> +  */
> + hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
> +
> + if ((cnt + base) >= hw_cfg->lm.nb_stages) {
> + dev_err(dev->dev, "too many planes!\n");
> + return -EINVAL;
> + }
> +
>   for (i = 0; i < cnt; i++) {
> - pstates[i].state->stage = STAGE_BASE + i;
> + pstates[i].state->stage = STAGE_BASE + i + base;
>   DBG("%s: assign pipe %s on stage=%d", mdp5_crtc->name,
>   pipe2name(mdp5_plane_pipe(pstates[i].plane)),
>   pstates[i].state->stage);
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

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

--- Comment #32 from Micael Bergeron  ---
(In reply to Marek Olšák from comment #31)

> Please create apitrace while this environment variable is set:
> MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage -GL_AMD_pinned_memory"
> 
> Then check that the apitrace replays correctly. If it does, please attach
> it. Thanks.

Here is my attempt to provide the needed apitrace. As they are large files,
even compressed, I uploaded them to an external service. 

*Files will be deleted in 30 days.*

I made 2 apitrace, 

1) when you click on the Option menu and "High Quality" shaders are on. You can
reproduce this by setting the "High Quality" shaders on then clicking again on
Options.

2) when you enter a game, there is a long delay in the game loading, it hangs
for multiples seconds at a time, multiple times until it settles. From my PoV,
it seems to have something to do with the HUD.

I haven't been able to replay the apitrace, as I'm not too familiar with this
tool, maybe someone can fix the traces or something. I guess it's better than
having nothing.

Hit me up if you need anything else, thanks for your time.

1) https://ufile.io/2a49
2) https://ufile.io/0cf6

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


[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

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

--- Comment #3 from Médéric Boquien  ---
After further investigation, I have found:
1. The games will start correctly if the launcher is bypassed
2. The games will start correctly only if the "multi_sampling" option is set to
0 in the respective settings.txt files.

I suspect that the launcher ignores settings.txt and sets multi-sampling
anyway.

-- 
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/20161015/e8d00293/attachment.html>


[PATCH] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

2016-10-15 Thread Archit Taneja
Hi,

On 10/14/2016 6:57 PM, Eugeniy Paltsev wrote:
> ARC PGU driver starts crashing on initialization after
> 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
> This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
> of "drm_i2c_encoder_driver" structure, which doesn't exist after
> adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
> So, when we call "encoder_init" function from this structure driver
> crashes.
>

The conversion doesn't seem entirely correct. Some comments below.


> Bootlog:
> ->8
> [drm] Initialized drm 1.1.0 20060810
> arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> arcpgu e0017000.pgu: assigned reserved memory node frame_buffer at 9e00
> Path: (null)
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-1-gb5642252fa01-dirty #8
> task: 9a058000 task.stack: 9a032000
>
> [ECR   ]: 0x00220100 => Invalid Read @ 0x0004 by insn @ 0x803934e8
> [EFA   ]: 0x0004
> [BLINK ]: drm_atomic_helper_connector_dpms+0xa6/0x230
> [ERET  ]: drm_atomic_helper_connector_dpms+0xa4/0x230
> [STAT32]: 0x0846 : K DE   E2 E1
> BTA: 0x8016d949  SP: 0x9a033e34  FP: 0x
> LPS: 0x8036f6fc LPE: 0x8036f700 LPC: 0x
> r00: 0x8063c118 r01: 0x805b98ac r02: 0x0b11
> r03: 0x r04: 0x9a010f54 r05: 0x
> r06: 0x0001 r07: 0x r08: 0x0028
> r09: 0x0001 r10: 0x0007 r11: 0x0054
> r12: 0x720a3033
>
> Stack Trace:
>   drm_atomic_helper_connector_dpms+0xa4/0x230
>   arcpgu_drm_hdmi_init+0xbc/0x228
>   arcpgu_probe+0x168/0x244
>   platform_drv_probe+0x26/0x64
>   really_probe+0x1f0/0x32c
>   __driver_attach+0xa8/0xd0
>   bus_for_each_dev+0x3c/0x74
>   bus_add_driver+0xc2/0x184
>   driver_register+0x50/0xec
>   do_one_initcall+0x3a/0x120
>   kernel_init_freeable+0x108/0x1a0
> ->8
>
> Fix ARC PGU driver to be able work with drm bridge hdmi encoder
> interface. The hdmi connector code isn't needed anymore as we expect
> the adv7511 bridge driver to create/manage the connector.
>
> Signed-off-by: Eugeniy Paltsev 
> ---
>  drivers/gpu/drm/arc/arcpgu_hdmi.c | 144 
> +-
>  1 file changed, 35 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c 
> b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> index b7a8b2a..48a6c63 100644
> --- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
> +++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
> @@ -14,104 +14,54 @@
>   *
>   */
>
> +#include 
>  #include 
>  #include 
>  #include 
>
>  #include "arcpgu.h"
>
> -struct arcpgu_drm_connector {
> - struct drm_connector connector;
> - struct drm_encoder_slave *encoder_slave;
> -};
> -
> -static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
> +static void arcpgu_drm_i2c_encoder_mode_set(struct drm_encoder *encoder,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
>  {
> - const struct drm_encoder_slave_funcs *sfuncs;
> - struct drm_encoder_slave *slave;
> - struct arcpgu_drm_connector *con =
> - container_of(connector, struct arcpgu_drm_connector, connector);
> -
> - slave = con->encoder_slave;
> - if (slave == NULL) {
> - dev_err(connector->dev->dev,
> - "connector_get_modes: cannot find slave encoder for 
> connector\n");
> - return 0;
> - }
> -
> - sfuncs = slave->slave_funcs;
> - if (sfuncs->get_modes == NULL)
> - return 0;
> -
> - return sfuncs->get_modes(>base, connector);
> -}
> -
> -static enum drm_connector_status
> -arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
> -{
> - enum drm_connector_status status = connector_status_unknown;
> - const struct drm_encoder_slave_funcs *sfuncs;
> - struct drm_encoder_slave *slave;
> -
> - struct arcpgu_drm_connector *con =
> - container_of(connector, struct arcpgu_drm_connector, connector);
> -
> - slave = con->encoder_slave;
> - if (slave == NULL) {
> - dev_err(connector->dev->dev,
> - "connector_detect: cannot find slave encoder for 
> connector\n");
> - return status;
> - }
> + struct drm_bridge *bridge = encoder->bridge;
>
> - sfuncs = slave->slave_funcs;
> - if (sfuncs && sfuncs->detect)
> - return sfuncs->detect(>base, connector);
> -
> - dev_err(connector->dev->dev, "connector_detect: could not detect slave 
> funcs\n");
> - return status;
> + bridge->funcs->mode_set(bridge, mode, adjusted_mode);

The bridge functions shouldn't really be called by the kms driver.
They're called automatically by the drm core for the bridge attached
to the encoder. See mode_fixup in drivers/gpu/drm/drm_atomic_helper.c

>  }
>
> -static void 

[radeon-alex:amd-staging-4.7 2/14] drivers/gpu/drm/amd/amdgpu/../dal/amdgpu_dm/amdgpu_dm.c:139:24: warning: unused variable 'adev'

2016-10-15 Thread kbuild test robot
nd 2015-11-25   76   * @param
5508d4f4 Harry Wentland 2015-11-25   77   * struct amdgpu_device *adev - [in] 
desired amdgpu device
5508d4f4 Harry Wentland 2015-11-25   78   * int disp_idx - [in] which CRTC to 
get the counter from
5508d4f4 Harry Wentland 2015-11-25   79   *
5508d4f4 Harry Wentland 2015-11-25   80   * @return
5508d4f4 Harry Wentland 2015-11-25   81   * Counter for vertical blanks
5508d4f4 Harry Wentland 2015-11-25   82   */
5508d4f4 Harry Wentland 2015-11-25   83  static u32 
dm_vblank_get_counter(struct amdgpu_device *adev, int crtc)
5508d4f4 Harry Wentland 2015-11-25   84  {
5508d4f4 Harry Wentland 2015-11-25   85 if (crtc >= 
adev->mode_info.num_crtc)
5508d4f4 Harry Wentland 2015-11-25   86 return 0;
5508d4f4 Harry Wentland 2015-11-25   87 else {
5508d4f4 Harry Wentland 2015-11-25   88 struct amdgpu_crtc 
*acrtc = adev->mode_info.crtcs[crtc];
5508d4f4 Harry Wentland 2015-11-25   89  
5508d4f4 Harry Wentland 2015-11-25   90 if (NULL == 
acrtc->target) {
5508d4f4 Harry Wentland 2015-11-25   91 
DRM_ERROR("dc_target is NULL for crtc '%d'!\n", crtc);
5508d4f4 Harry Wentland 2015-11-25   92 return 0;
5508d4f4 Harry Wentland 2015-11-25   93 }
5508d4f4 Harry Wentland 2015-11-25   94  
5508d4f4 Harry Wentland 2015-11-25   95 return 
dc_target_get_vblank_counter(acrtc->target);
5508d4f4 Harry Wentland 2015-11-25   96 }
5508d4f4 Harry Wentland 2015-11-25   97  }
5508d4f4 Harry Wentland 2015-11-25   98  
5508d4f4 Harry Wentland 2015-11-25   99  static int 
dm_crtc_get_scanoutpos(struct amdgpu_device *adev, int crtc,
5508d4f4 Harry Wentland 2015-11-25  100 
u32 *vbl, u32 *position)
5508d4f4 Harry Wentland 2015-11-25  101  {
5508d4f4 Harry Wentland 2015-11-25  102 if ((crtc < 0) || (crtc >= 
adev->mode_info.num_crtc))
5508d4f4 Harry Wentland 2015-11-25  103 return -EINVAL;
dafdecfa Jordan Lazare  2016-03-22  104 else {
dafdecfa Jordan Lazare  2016-03-22  105 struct amdgpu_crtc 
*acrtc = adev->mode_info.crtcs[crtc];
dafdecfa Jordan Lazare  2016-03-22  106  
dafdecfa Jordan Lazare  2016-03-22  107 if (NULL == 
acrtc->target) {
dafdecfa Jordan Lazare  2016-03-22  108 
DRM_ERROR("dc_target is NULL for crtc '%d'!\n", crtc);
dafdecfa Jordan Lazare  2016-03-22  109 return 0;
dafdecfa Jordan Lazare  2016-03-22  110 }
dafdecfa Jordan Lazare  2016-03-22  111  
dafdecfa Jordan Lazare  2016-03-22  112 return 
dc_target_get_scanoutpos(acrtc->target, vbl, position);
dafdecfa Jordan Lazare  2016-03-22  113 }
5508d4f4 Harry Wentland 2015-11-25  114  
5508d4f4 Harry Wentland 2015-11-25  115 return 0;
5508d4f4 Harry Wentland 2015-11-25  116  }
5508d4f4 Harry Wentland 2015-11-25  117  
5508d4f4 Harry Wentland 2015-11-25  118  static bool dm_is_idle(void *handle)
5508d4f4 Harry Wentland 2015-11-25  119  {
5508d4f4 Harry Wentland 2015-11-25  120 /* XXX todo */
5508d4f4 Harry Wentland 2015-11-25  121 return true;
5508d4f4 Harry Wentland 2015-11-25  122  }
5508d4f4 Harry Wentland 2015-11-25  123  
5508d4f4 Harry Wentland 2015-11-25  124  static int dm_wait_for_idle(void 
*handle)
5508d4f4 Harry Wentland 2015-11-25  125  {
5508d4f4 Harry Wentland 2015-11-25  126 /* XXX todo */
5508d4f4 Harry Wentland 2015-11-25  127 return 0;
5508d4f4 Harry Wentland 2015-11-25  128  }
5508d4f4 Harry Wentland 2015-11-25  129  
01981324 Alex Deucher   2016-10-13  130  static bool dm_check_soft_reset(void 
*handle)
d86ac4aa Chunming Zhou  2016-07-20  131  {
d86ac4aa Chunming Zhou  2016-07-20  132 struct amdgpu_device *adev = 
(struct amdgpu_device *)handle;
d86ac4aa Chunming Zhou  2016-07-20  133  
01981324 Alex Deucher   2016-10-13  134 return 
amdgpu_display_is_display_hung(adev);
d86ac4aa Chunming Zhou  2016-07-20  135  }
d86ac4aa Chunming Zhou  2016-07-20  136  
5508d4f4 Harry Wentland 2015-11-25  137  static int dm_soft_reset(void *handle)
5508d4f4 Harry Wentland 2015-11-25  138  {
d86ac4aa Chunming Zhou  2016-07-20 @139 struct amdgpu_device *adev = 
(struct amdgpu_device *)handle;
d86ac4aa Chunming Zhou  2016-07-20  140  
8721a530 Alex Deucher   2016-04-21  141 /* XXX todo */
5508d4f4 Harry Wentland 2015-11-25  142 return 0;

:: The code at line 139 was first introduced by commit
:: d86ac4aaabf05f7866fb1241e41075022c1c08c3 drm/amdgpu: add dm 
check_soft_reset

:: TO: Chunming Zhou 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55094 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161015/5613c1a9/attachment-0001.gz>


[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

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

--- Comment #2 from Médéric Boquien  ---
For reference, I compiled Mesa git and the issue remains unchanged.

-- 
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/20161015/9e0c7ff6/attachment.html>


[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

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

--- Comment #1 from Médéric Boquien  ---
To be more precise, the games actually start (music is playing) and do not
crash, but nother is ever displayed. If I set LIBGL_DEBUG=verbose, I get the
following:

libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/radeonsi_dri.so
libGL: Using DRI3 for screen 0
Setting breakpad minidump AppID = 236850
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198007143817 [API loaded no]
function is no-op
function is no-op
function is no-op
function is no-op
function is no-op
function is no-op

The last lines repeat endlessly.

-- 
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/20161015/8784ef2c/attachment.html>


[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to display anything

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

Médéric Boquien  changed:

   What|Removed |Added

Summary|Europa Universalis IV,  |Europa Universalis IV,
   |Hearts of Iron IV, and  |Hearts of Iron IV, and
   |Stellaris fail to start |Stellaris fail to display
   ||anything

-- 
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/20161015/2d90d81f/attachment.html>


[Bug 98272] Europa Universalis IV, Hearts of Iron IV, and Stellaris fail to start

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

Bug ID: 98272
   Summary: Europa Universalis IV, Hearts of Iron IV, and
Stellaris fail to start
   Product: Mesa
   Version: 12.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: mboquien at free.fr
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 127318
  --> https://bugs.freedesktop.org/attachment.cgi?id=127318=edit
Trace of Europa Universalis IV

Europa Universalis IV, Hearts of Iron IV, and Stellaris (all games from the
same team) fail to start with a radeon rx480 with radeonsi+amdgpu. Using the
intel IGP works. This is using Mesa 12.0.3 with Linux 4.8.1.

The attached trace appears to show that there is no current context. Contexts
are created and destroyed several times before that. Please let me know what I
can do to provide more information.

-- 
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/20161015/909c5ed4/attachment.html>


[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

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

--- Comment #31 from Marek Olšák  ---
Please create apitrace while this environment variable is set:
MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage -GL_AMD_pinned_memory"

Then check that the apitrace replays correctly. If it does, please attach it.
Thanks.

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


[Bug 60879] [radeonsi] Tahiti LE: GFX block is not functional, CP is okay

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

--- Comment #159 from madmalkav  ---
(In reply to Michel Dänzer from comment #158)
> Double-check that you're really building current Git master, and that your
> self-built radeonsi_dri.so is getting picked up.

You are probably right, but for personal reasons I won't continue testing
things for this bug. I hope some of other affected users step up and continue
the tests.

I will remain subscribed to the bug so I can grant the bounty if someone gets
to fix it.

-- 
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/20161015/6137a837/attachment.html>


[PATCH] drm/msm/mdp5: handle non-fullscreen base plane case

2016-10-15 Thread Rob Clark
On Sat, Oct 15, 2016 at 8:57 AM, Archit Taneja  
wrote:
>
>
> On 10/15/2016 5:02 PM, Rob Clark wrote:
>>
>> On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja 
>> wrote:
>>>
>>>
>>> On 10/13/2016 10:18 PM, Rob Clark wrote:


 If the bottom-most layer is not fullscreen, we need to use the BASE
 mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
 blend_setup() code pretty much handled this already, we just had to
 figure this out in _atomic_check() and assign the stages appropriately.

 Signed-off-by: Rob Clark 
 ---
 TODO mdp4 might need similar treatment?

  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 44
 
  1 file changed, 27 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
 b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
 index fa2be7c..e42f62d 100644
 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
 +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
 @@ -223,11 +223,6 @@ static void blend_setup(struct drm_crtc *crtc)
 plane_cnt++;
 }

 -   /*
 -   * If there is no base layer, enable border color.
 -   * Although it's not possbile in current blend logic,
 -   * put it here as a reminder.
 -   */
 if (!pstates[STAGE_BASE] && plane_cnt) {
 ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
 DBG("Border Color is enabled");
 @@ -365,6 +360,15 @@ static int pstate_cmp(const void *a, const void *b)
 return pa->state->zpos - pb->state->zpos;
  }

 +/* is there a helper for this? */
 +static bool is_fullscreen(struct drm_crtc_state *cstate,
 +   struct drm_plane_state *pstate)
 +{
 +   return (pstate->crtc_x == 0) && (pstate->crtc_y == 0) &&
 +   (pstate->crtc_w == cstate->mode.hdisplay) &&
 +   (pstate->crtc_h == cstate->mode.vdisplay);
 +}
 +
  static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_crtc_state *state)
  {
 @@ -375,21 +379,11 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
 *crtc,
 struct plane_state pstates[STAGE_MAX + 1];
 const struct mdp5_cfg_hw *hw_cfg;
 const struct drm_plane_state *pstate;
 -   int cnt = 0, i;
 +   int cnt = 0, base = 0, i;

 DBG("%s: check", mdp5_crtc->name);

 -   /* verify that there are not too many planes attached to crtc
 -* and that we don't have conflicting mixer stages:
 -*/
 -   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
 drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state)
 {
 -   if (cnt >= (hw_cfg->lm.nb_stages)) {
 -   dev_err(dev->dev, "too many planes!\n");
 -   return -EINVAL;
 -   }
 -
 -
 pstates[cnt].plane = plane;
 pstates[cnt].state = to_mdp5_plane_state(pstate);

 @@ -399,8 +393,24 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
 *crtc,
 /* assign a stage based on sorted zpos property */
 sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);

 +   /* if the bottom-most layer is not fullscreen, we need to use
 +* it for solid-color:
 +*/
 +   if (!is_fullscreen(state, [0].state->base))
 +   base++;
 +
>>>
>>>
>>>
>>> I get a crash here when fbcon is enabled and there are no connectors
>>> connected. We're trying to refer pstates[0] when there is no plane
>>> connected to the crtc. I guess we could bail out much earlier if cnt
>>> is 0.
>>
>>
>> yeah, I hit that last night with no fbcon and killing the UI.. I've
>> already fixed it up locally with an 'if (pstates[0].state &&
>> !is_fullscreen())'
>
>
> Okay, I guess we should probably memset pstates array to 0 in case the
> stack memory has some older non NULL stuff in it.

hmm, yeah, you are right.. I wonder how that wasn't already a
problem..  I guess we at least always have an outgoing plane?  I guess
changing the check to '(cnt > 0)' instead of 'pstates[0].state' would
do the trick..

fwiw, I pushed current version of this and the other patches to:

https://github.com/freedreno/kernel-msm/commits/integration-linux-qcomlt-fences-2

BR,
-R

> Thanks,
> Archit
>
>
>>
>> BR,
>> -R
>>
>>> Archit
>>>
 +   /* verify that there are not too many planes attached to crtc
 +* and that we don't have conflicting mixer stages:
 +*/
 +   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
 +
 +   if ((cnt + base) >= hw_cfg->lm.nb_stages) {
 +   dev_err(dev->dev, "too many planes!\n");
 +   return -EINVAL;
 +   }

[radeon-alex:amd-staging-4.7 1641/1662] drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:294:21: warning: unused variable 'ctx'

2016-10-15 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.7
head:   091705fb62afea9598c29e600bcb211f44e86cec
commit: b73f7c9f9e12db516db97aaf2c5dc5002ade2e1b [1641/1662] drm/amd/dal: Link 
Encoder Refactor part 2.
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout b73f7c9f9e12db516db97aaf2c5dc5002ade2e1b
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c: In 
function 'set_dp_phy_pattern_symbol_error':
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:303:3: 
warning: ISO C90 forbids mixed declarations and code 
[-Wdeclaration-after-statement]
  uint32_t value = 0x0;
  ^~~~
>> drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:294:21: 
>> warning: unused variable 'ctx' [-Wunused-variable]
 struct dc_context *ctx = enc110->base.ctx;
^~~
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c: In 
function 'link_encoder_disable':
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:790:21: 
warning: unused variable 'ctx' [-Wunused-variable]
 struct dc_context *ctx = enc110->base.ctx;
^~~
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c: In 
function 'dce110_link_encoder_init_dmcu_backlight_settings':
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:1805:21: 
warning: unused variable 'ctx' [-Wunused-variable]
 struct dc_context *ctx = enc110->base.ctx;
^~~
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c: In 
function 'dce110_link_encoder_connect_dig_be_to_fe':
   drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c:2134:21: 
warning: unused variable 'ctx' [-Wunused-variable]
 struct dc_context *ctx = enc110->base.ctx;
^~~

vim +/ctx +294 drivers/gpu/drm/amd/amdgpu/../dal/dc/dce110/dce110_link_encoder.c

471b9fe0 Harry Wentland 2015-11-25  288  }
471b9fe0 Harry Wentland 2015-11-25  289  
471b9fe0 Harry Wentland 2015-11-25  290  static void 
set_dp_phy_pattern_symbol_error(
c5454461 Chris Park 2015-11-30  291 struct dce110_link_encoder 
*enc110)
471b9fe0 Harry Wentland 2015-11-25  292  {
471b9fe0 Harry Wentland 2015-11-25  293 /* Disable PHY Bypass mode to 
setup the test pattern */
c5454461 Chris Park 2015-11-30 @294 struct dc_context *ctx = 
enc110->base.ctx;
471b9fe0 Harry Wentland 2015-11-25  295  
c5454461 Chris Park 2015-11-30  296 enable_phy_bypass_mode(enc110, 
false);
471b9fe0 Harry Wentland 2015-11-25  297  
471b9fe0 Harry Wentland 2015-11-25  298 /* program correct panel mode*/
471b9fe0 Harry Wentland 2015-11-25  299 {
b73f7c9f Zeyu Fan   2016-10-06  300 
ASSERT(REG(DP_DPHY_INTERNAL_CTRL));
b73f7c9f Zeyu Fan   2016-10-06  301 /*DCE 120 does not have 
this reg*/
b73f7c9f Zeyu Fan   2016-10-06  302  
471b9fe0 Harry Wentland 2015-11-25 @303 uint32_t value = 0x0;
b73f7c9f Zeyu Fan   2016-10-06  304 
REG_WRITE(DP_DPHY_INTERNAL_CTRL, value);
471b9fe0 Harry Wentland 2015-11-25  305 }
471b9fe0 Harry Wentland 2015-11-25  306  

:: The code at line 294 was first introduced by commit
:: c5454461cd2d25ebddf0a2a2e7360bb3ad5d6eea drm/amd/dal: Register offset 
cleanup on Link and Stream Encoder

:: TO: Chris Park 
:: CC: Alex Deucher 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 55094 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161015/9a50d438/attachment-0001.gz>


[PATCH] drm/msm/mdp5: handle non-fullscreen base plane case

2016-10-15 Thread Rob Clark
On Sat, Oct 15, 2016 at 5:39 AM, Archit Taneja  
wrote:
>
> On 10/13/2016 10:18 PM, Rob Clark wrote:
>>
>> If the bottom-most layer is not fullscreen, we need to use the BASE
>> mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
>> blend_setup() code pretty much handled this already, we just had to
>> figure this out in _atomic_check() and assign the stages appropriately.
>>
>> Signed-off-by: Rob Clark 
>> ---
>> TODO mdp4 might need similar treatment?
>>
>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 44
>> 
>>  1 file changed, 27 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> index fa2be7c..e42f62d 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> @@ -223,11 +223,6 @@ static void blend_setup(struct drm_crtc *crtc)
>> plane_cnt++;
>> }
>>
>> -   /*
>> -   * If there is no base layer, enable border color.
>> -   * Although it's not possbile in current blend logic,
>> -   * put it here as a reminder.
>> -   */
>> if (!pstates[STAGE_BASE] && plane_cnt) {
>> ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
>> DBG("Border Color is enabled");
>> @@ -365,6 +360,15 @@ static int pstate_cmp(const void *a, const void *b)
>> return pa->state->zpos - pb->state->zpos;
>>  }
>>
>> +/* is there a helper for this? */
>> +static bool is_fullscreen(struct drm_crtc_state *cstate,
>> +   struct drm_plane_state *pstate)
>> +{
>> +   return (pstate->crtc_x == 0) && (pstate->crtc_y == 0) &&
>> +   (pstate->crtc_w == cstate->mode.hdisplay) &&
>> +   (pstate->crtc_h == cstate->mode.vdisplay);
>> +}
>> +
>>  static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
>> struct drm_crtc_state *state)
>>  {
>> @@ -375,21 +379,11 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
>> *crtc,
>> struct plane_state pstates[STAGE_MAX + 1];
>> const struct mdp5_cfg_hw *hw_cfg;
>> const struct drm_plane_state *pstate;
>> -   int cnt = 0, i;
>> +   int cnt = 0, base = 0, i;
>>
>> DBG("%s: check", mdp5_crtc->name);
>>
>> -   /* verify that there are not too many planes attached to crtc
>> -* and that we don't have conflicting mixer stages:
>> -*/
>> -   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>> drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
>> -   if (cnt >= (hw_cfg->lm.nb_stages)) {
>> -   dev_err(dev->dev, "too many planes!\n");
>> -   return -EINVAL;
>> -   }
>> -
>> -
>> pstates[cnt].plane = plane;
>> pstates[cnt].state = to_mdp5_plane_state(pstate);
>>
>> @@ -399,8 +393,24 @@ static int mdp5_crtc_atomic_check(struct drm_crtc
>> *crtc,
>> /* assign a stage based on sorted zpos property */
>> sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
>>
>> +   /* if the bottom-most layer is not fullscreen, we need to use
>> +* it for solid-color:
>> +*/
>> +   if (!is_fullscreen(state, [0].state->base))
>> +   base++;
>> +
>
>
> I get a crash here when fbcon is enabled and there are no connectors
> connected. We're trying to refer pstates[0] when there is no plane
> connected to the crtc. I guess we could bail out much earlier if cnt
> is 0.

yeah, I hit that last night with no fbcon and killing the UI.. I've
already fixed it up locally with an 'if (pstates[0].state &&
!is_fullscreen())'

BR,
-R

> Archit
>
>> +   /* verify that there are not too many planes attached to crtc
>> +* and that we don't have conflicting mixer stages:
>> +*/
>> +   hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>> +
>> +   if ((cnt + base) >= hw_cfg->lm.nb_stages) {
>> +   dev_err(dev->dev, "too many planes!\n");
>> +   return -EINVAL;
>> +   }
>> +
>> for (i = 0; i < cnt; i++) {
>> -   pstates[i].state->stage = STAGE_BASE + i;
>> +   pstates[i].state->stage = STAGE_BASE + i + base;
>> DBG("%s: assign pipe %s on stage=%d", mdp5_crtc->name,
>>
>> pipe2name(mdp5_plane_pipe(pstates[i].plane)),
>> pstates[i].state->stage);
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project


[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

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

--- Comment #34 from Pavel Bordukov  ---
Checked at vanilla 4.4.24, flickering exists. Gentoo unstable, R9 290X.

-- 
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/20161015/0b0d934e/attachment.html>


[PATCH v3 1/9] drm/hisilicon/hibmc: Add hisilicon hibmc drm master driver

2016-10-15 Thread Rongrong Zou
Benjamin Gaignard 於 2016/10/14 22:33 寫道:
> Just by curiosity, why using "old" TTM instead of GEM ? any particular 
> reasons ?

Do you mean i can manage the video memory visiable to pci without TTM,
i found all the other simple gpu chips(eg: AST, mgag200) use TTM, so i 
chose TTM.

>
> 2016-10-14 16:44 GMT+02:00 Rongrong Zou :
>> Hi Benjamin,
>>
>> Thanks for reviewing!
>>
>> Benjamin Gaignard 於 2016/10/14 16:29 寫道:
>>>
>>> [snip]
>>>
 --- /dev/null
 +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
 @@ -0,0 +1,15 @@
 +config DRM_HISI_HIBMC
 +   tristate "DRM Support for Hisilicon Hibmc"
 +   depends on DRM && PCI
 +   select DRM_KMS_HELPER
 +   select DRM_KMS_FB_HELPER
 +   select DRM_GEM_CMA_HELPER
 +   select DRM_KMS_CMA_HELPER
>>>
>>>
>>> since you use TTM I don't think that selecting DRM_GEM_CMA_HELPER and
>>> DRM_KMS_CMA_HELPER
>>> help you lot here.
>>> You could add configuration flags step by step in following patches
>>> that will make you needs more clear (that also true for #include)
>>
>>
>> will delete them, thanks.
>>
>>
>>>
 +   select FB_SYS_FILLRECT
 +   select FB_SYS_COPYAREA
 +   select FB_SYS_IMAGEBLIT
 +   select DRM_TTM
 +
 +   help
 + Choose this option if you have a Hisilicon Hibmc soc chipset.
 + If M is selected the module will be called hibmc-drm.
 diff --git a/drivers/gpu/drm/hisilicon/hibmc/Makefile
 b/drivers/gpu/drm/hisilicon/hibmc/Makefile
 new file mode 100644
 index 000..97cf4a0
 --- /dev/null
 +++ b/drivers/gpu/drm/hisilicon/hibmc/Makefile
 @@ -0,0 +1,5 @@
 +ccflags-y := -Iinclude/drm
 +hibmc-drm-y := hibmc_drm_drv.o hibmc_drm_power.o
 +
 +obj-$(CONFIG_DRM_HISI_HIBMC)   +=hibmc-drm.o
 +#obj-y += hibmc-drm.o
 diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
 b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
 new file mode 100644
 index 000..52c9353
 --- /dev/null
 +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
 @@ -0,0 +1,288 @@
 +/* Hisilicon Hibmc SoC drm driver
 + *
 + * Based on the bochs drm driver.
 + *
 + * Copyright (c) 2016 Huawei Limited.
 + *
 + * Author:
 + * Rongrong Zou 
>>>
>>>
>>> ".com" is missing in you email address (same typo in all other files)
>>
>>
>> will fix it in next version, thanks. :)
>>
>>>
 + * Rongrong Zou 
 + * Jianhua Li 
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
>>>
>>>
>>> cma_helpers look useless since you use TTM, no ?
>>
>>
>> I add TTM just in this version, and forgot to clean these
>> cma relevant code, will fix in next version. Thanks.
>>
>>>
 +#include 
 +
 +#include "hibmc_drm_drv.h"
 +#include "hibmc_drm_regs.h"
 +#include "hibmc_drm_power.h"
 +
>>
>>
>> Regards,
>> Rongrong
>
>
>


[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

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

--- Comment #13 from Ernst Sjöstrand  ---
I was running the Ubuntu firmware from Xenial, the firmware bundled in Wily
fixed it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 



[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

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

--- Comment #12 from Ernst Sjöstrand  ---
Couldn't get anything after modprobe, the computer really dies.
However updating the firmware fixed it.

Should there be some kind of check or do you consider this fixed?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: