[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

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

--- Comment #32 from Timo Aaltonen  ---
forwarding a comment from an engineer:

"During viewing the source code of radeon module, I found there is a bug [1]
related to the dpm and clocks. So I decided to do some experiments.
Tried to set different max_sclk and max_mclk to see if the issue is gone.
1. max_sclk: 7, max_mclk: 75000 --> have the same issue
2. max_sclk: 5, max_mclk: 6 --> pass multi-run test (more than 50 runs)

[1] https://bugs.freedesktop.org/show_bug.cgi?id=76490
"

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

Re: [PATCH] drm: don't link DP aux i2c adapter to the hardware device node

[Daniel Vetter]

On Tue, Nov 14, 2017 at 03:34:19PM +0100, Andrzej Hajda wrote:
> On 05.04.2017 14:04, Thierry Reding wrote:
> > On Wed, Apr 05, 2017 at 10:52:32AM +0200, Lucas Stach wrote:
> >> Hi Rob,
> >>
> >> Am Mittwoch, den 29.03.2017, 08:56 -0500 schrieb Rob Herring:
> >>> On Mon, Jan 23, 2017 at 10:33 AM, Thierry Reding
> >>>  wrote:
>  On Fri, Jan 13, 2017 at 06:36:30PM +0100, Lucas Stach wrote:
> > The i2c adapter on DP AUX is purely a software construct. Linking
> > it to the device node of the parent device is wrong, as it leads to
> > 2 devices sharing the same device node, which is bad practice, as
>  Who says that two devices can't share the same device node? It's done
>  all the time.
> >>> It's done *some of the time* and I would not consider it best practice.
> >>>
> > well as the i2c trying to populate children of the i2c adapter by
> > looking at the child device nodes of the parent device.
>  A set of patches landed in v4.9 to work around this issue in a better
>  way. See:
> 
>  98b00488459e dt-bindings: i2c: Add support for 'i2c-bus' subnode
>  7e4c224abfe8 i2c: core: Add support for 'i2c-bus' subnode
> >>> What does this buy us? I don't see why this needs to be in DT either.
> >>> Contrary to popular belief, DT is not the only way to instantiate
> >>> devices, C code can still do it.
> >>>
> >>> Also, if this one line removal has no side effects, then how was it
> >>> even needed? We can always add it back if there's some argument for
> >>> why it is needed.
> >> Okay, so I take this as you mostly agreeing with the rationale of this
> >> patch.
> > For some general background on this: I was originally using this for DP
> > support on Tegra (though that ended up never getting merged because of a
> > particularily frustrating episode of trying to get better link training
> > support into the core helpers) and use it as a means to obtain the I2C
> > controller used for DDC. On Tegra, and I suspect other devices as well,
> > the DP AUX controller is separate from the encoder, so the idea was to
> > link them together using a standard ddc-i2c-bus phandle.
> >
> > I ended up not needing that because the encoder and DP AUX controller
> > are so tightly linked on Tegra that I need direct access to the DP AUX
> > anyway and can therefore directly get the I2C controller from that.
> >
> > If there aren't any other users of this, I suppose we could simply
> > remove the line. Should someone turn up in the future and require the
> > I2C controller to be looked up from a phandle we could add it again,
> > at which point we'd have to investigate again how to get rid of the
> > errors.
> >
> > Acked-by: Thierry Reding 
> 
> It looks like the patch has been accepted but not merged. Who can pick
> it up? or is it OK if I put it int drm-misc?

I don't have the patch itself, but sounds good. Just go ahead and push.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda]

On 18.11.2017 02:16, Eric Anholt wrote:
> Andrzej Hajda  writes:
>
>> On 16.11.2017 21:27, Eric Anholt wrote:
>>> Andrzej Hajda  writes:
>>>
 On 15.11.2017 21:26, Eric Anholt wrote:
> I'm happy to have the DSI panel finally working on VC4 (just waiting on
> https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
> but now I've got another problem to solve.  It would be great if I could
> include the DSI panel in our upstream DT, so that it automatically
> worked when you plugged one in.  However, right now we return
> -EPROBE_DEFER during bind unless the panel has actually shown up.  This
> means that if you don't have the panel actually connected, you get this
> sequence at startup:
>
> [   10.719929] [drm] Initialized
> [   10.829510] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi 
> mapping ok
> [   10.844043] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> [vc4])
> [   10.848626] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
> [   10.850214] vc4-drm soc:gpu: failed to bind 3f70.dsi (ops 
> vc4_dsi_ops [vc4]): -517
> [   10.856559] vc4-drm soc:gpu: master bind failed: -517
>
> [...]
>
> [   10.967718] rpi_touchscreen 3-0045: Atmel I2C read failed: -6
>
> Once the panel driver fails to probe, we never get asked to re-bind vc4,
> and drm_of_find_panel_or_bridge looks like it would just give us
> -EPROBE_DEFER again since the panel still wasn't registered.
>
> Does anyone have any suggestions for handling this?
 I guess you should call component_add only when all required resources
 are present(including panel), I suppose moving it to vc4_dsi_host_attach
 should help.
>>> How can I decide when the panel driver has tried to probe and failed,
>>> versus not tried to probe yet?  find_panel_or_bridge gives me
>>> -EPROBE_DEFER either way.
>>>
 On the other side I am curious why EPROBE_DEFER from bind does not fail
 probing of some component (the last one probed), with proper error
 propagation it should cause defer_probing of one of the components or
 master, and probe/bind should be retried after panel's probe.
>>> The panel probe failed, though, so there's no trigger to re-probe other
>>> drivers.
>> OK, I misunderstood your problem. And after 2nd read I am not sure what
>> do you want to achieve exactly?
>>
>> Do you want to 'hotplug' DSI panel? Or just make it working with and
>> without the panel. In 2nd case other paths (HDMI) should still work, I
>> guess.
> Yeah, the second thing.  I would like to use a single DT to describe a
> platform where the panel may or may not be present, so the panel driver
> (panel-raspberrypi-touchscreen.c) will throw an error from the I2C part
> of the probe or not instead of creating the DSI device and attaching the
> panel.
>
>> Lets assume that you are interested in the latter case. There could be
>> multiple solutions more or less hacky:
>>
>> 1. Use connector's HPD infrastructure to signal presence of the panel,
>> ie. in mipi_dsi::host_(attach|detach) callback you grab the panel and
>> change connector status to connected|disconnected and calls
>> drm_kms_helper_hotplug_event, it is done this way in exynos_dsi_host_attach.
> This is basically what I had before all the review reworks, and the
> regression from this state is keeping me from merging the current driver
> downstream.
>
> This option is unfortunate because we'll have forced *some* output on at
> boot time, and then when the panel driver shows up later we don't resize
> the fbcon to the panel's size.

This issue can be solved using deffered fbdev registration, ie fbdev is
registered after some  connector(or specific one, up to you) becomes
connected.


>
>> 2. Check for presence of the panel's driver before registering the bus,
>> if not present defer probing (but I am not sure if driver's registration
>> will trigger deferred probing, should be checked).
>>
>> This way if the panel's driver is present during mipi bus registration
>> and after that panel should be bound to the drivers, otherwise  it means
>> probe failed. This solutions requires discovering panels compatible in
>> DSI driver. Quite complicated and very hacky.
> Restating to see if I understand: Defer all of VC4, including its MIPI
> host registration, until we see the panel driver loaded (how would one
> do that?). 
>  Then once we get reprobed with the MIPI driver present
> (would that even happen?), register our MIPI bus and continue on to
> component bind.  In component bind, don't defer if we don't find the
> panel, because we know the panel driver had a chance to probe and attach
> right away when our bus showed up.

Yes this is the rough idea. I have assumed you have panel on DSI bus,
but from your response it seems you have panel controlled via i2c bus
and having DSI data bus.
I am not sure if 

Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values

[Daniel Vetter]

On Mon, Nov 13, 2017 at 09:56:19PM +0100, Thierry Reding wrote:
> On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> > > will automatically calculate the normalized zpos values, but it won't
> > > currently do so. Modify the atomic helpers to behave as documented.
> > 
> > NAK
> > 
> > See commit  38d868e41c4b ("drm: Don't force all planes to be added to
> > the state due to zpos")
> 
> Thanks, that's interesting background. It's a little unfortunate that
> I'll have to go and add a custom ->atomic_check() just because of this.

I'm behind on mails still, but is there a patch to fix the misleading
kerneldoc?
-Daniel

> 
> This is something in general that's been bugging me. How are we supposed
> to keep all of the custom ->atomic_check() implementations in sync with
> the atomic helpers? It looks to me like most drivers will at some point
> copy the atomic helper to their driver and then make driver-specific
> changes to them. But then when one of the helpers gets updated, the same
> changes are usually not propagated to the drivers that originally copied
> from the helpers.
> 
> One way I've seen used (and have used myself) occasionally is for the
> driver-specific implementations to "subclass" the helpers by calling the
> helper first and then calling the driver-specific bits. That helps a lot
> but will obviously not work if ordering is important.
> 
> Any ideas on how we can improve that? Other than periodically checking
> the git log for the helpers and updating drivers? I suppose if one were
> to closely follow the mailing list one might notice early on, and maybe
> speak up and have the changes applied to the drivers in the same patch
> as the helpers. But I don't think that's going to work for every driver.
> 
> Thierry



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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Daniel Vetter]

On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> For personal reasons, Mark Yao will leave rockchip,
> can not continue maintain drm/rockchip, Sandy Huang
> will take over the drm/rockchip.
> 
> Cc: Sandy Huang 
> Cc: Heiko Stuebner 
> 
> Signed-off-by: Mark Yao 

Since rockchip is in drm-misc that means we need a new maintainer who also
has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
the new maintainer we need to fix that.

Also, Heiko, are you interested in becoming co-maintainer? With commit
rights and all.
-Daniel

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d77f22..31bf080 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4627,7 +4627,7 @@ F:  
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
>  F:   Documentation/devicetree/bindings/display/renesas,du.txt
>  
>  DRM DRIVERS FOR ROCKCHIP
> -M:   Mark Yao 
> +M:   Sandy Huang 
>  L:   dri-devel@lists.freedesktop.org
>  S:   Maintained
>  F:   drivers/gpu/drm/rockchip/
> -- 
> 2.7.4
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: manual merge of the devicetree tree with the drm tree

[Daniel Vetter]

On Mon, Nov 13, 2017 at 09:51:29PM +0200, Jyri Sarha wrote:
> On 11/13/17 20:43, Frank Rowand wrote:
> > Hi Jyri,
> > 
> > On 11/13/17 07:40, Jyri Sarha wrote:
> >> On 11/13/17 07:58, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown  wrote:
>  Today's linux-next merge of the devicetree tree got a conflict in:
> 
>    drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
> 
>  between commit:
> 
>    44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag 
>  setting")
> 
>  from the drm tree and commit:
> 
>    f948d6d8b792bb ("of: overlay: avoid race condition between applying 
>  multiple overlays")
> 
>  from the devicetree tree.
> 
>  I fixed it up (see below) and can carry the fix as necessary. This
>  is now fixed as far as linux-next is concerned, but any non trivial
>  conflicts should be mentioned to your upstream maintainer when your tree
>  is submitted for merging.  You may also want to consider cooperating
>  with the maintainer of the conflicting tree to minimise any particularly
>  complex conflicts.
> 
>  diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  index 482299a6f3b0,54025af534d4..
>  --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>  @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc
>   return NULL;
>   }
>    
>  -ret = of_resolve_phandles(overlay);
>  -if (ret) {
>  -pr_err("%s: Failed to resolve phandles: %d\n", 
>  __func__, ret);
>  -return NULL;
>  -}
>   -   of_node_set_flag(overlay, OF_DETACHED);
>  --
>   return overlay;
>    }
>    
> >>> Just a reminder that this conflict still exists.
> >>>
> >> After some consideration, I think we can drop the dts backward
> >> compatibility code from drm/tilcdc. It seems that it is causing a lot of
> >> trouble and I do not even know if anybody uses it anymore. Here is a
> >> patch for dropping it:
> >>
> >> https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html
> >>
> >> I did not plan to merge it before v4.16, but if this is a bigger problem
> >> I can push is right now for v4.15.
> >>
> >> Best regards,
> >> Jyri
> >>
> > The dropping patch is much appreciated.
> > 
> > It would make life easier for me if the patch gets into v4.15-rc.
> 
> Dave, Daniel? Would you take this late addition to v4.15 still, if I
> would send a pull request now?
> 
> The patch is pretty much orthogonal to the rest of drm as it is only
> dealing with device tree stuff.

Seems like a reasonable thing to include in the merge window -fixes pull
Dave usually does, just make sure all the acks are recorded.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

[Daniel Vetter]

On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote:
> > Sorry this took so long.
> 
> No worries.
> 
> > 
> > The vmwgfx part:  Reviewed-by: Sinclair Yeh 
> > 
> > I've done some testing and the vmwgfx part looks good.  Has Daniel
> > already taken these or should I put them in my next request?
> 
> You can take them, or I can push them to drm-misc-next. Whatever
> works best for you.
> 
> And I'll want to revisit this topic soonish and move the clip
> handling into the helper as discussed with Daniel. But that can
> wait a bit until we get this round merged somewhere.

Because we're still in the merge window I think it's probably best if we
push the entire series in through drm-misc. Tree-coordination in the merge
window is always a bit a pain.
-Daniel

> 
> > 
> > Sinclair
> > 
> > On Wed, Nov 01, 2017 at 08:29:15PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > While trawling the tree I spotted some issues with the way vmwgfx
> > > uses drm_plane_helper_check_state(). Here's my attempt at fixing it.
> > > Do note that I haven't actually tested the resulting code at all,
> > > but it does build at least.
> > > 
> > > And while touching that general area I took up Daniel's suggestion from
> > > long ago that drm_plane_helper_check_state() should be renamed and
> > > relocated to better reflect its status.
> > > 
> > > Here's a branch with the entire series:
> > > git://github.com/vsyrjala/linux.git atomic_helper_plane_stuff
> > > 
> > > Cc: VMware Graphics 
> > > Cc: Sinclair Yeh 
> > > Cc: Thomas Hellstrom 
> > > Cc: Daniel Vetter 
> > > 
> > > Ville Syrjälä (5):
> > >   drm/vmwgfx: Remove bogus crtc coords vs fb size check
> > >   drm/vmwgfx: Use drm_plane_helper_check_state()
> > >   drm/vmwgfx: Try to fix plane clipping
> > >   drm: Check crtc_state->enable rather than crtc->enabled in
> > > drm_plane_helper_check_state()
> > >   drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
> > > 
> > >  drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +-
> > >  drivers/gpu/drm/arm/malidp_planes.c |   3 +-
> > >  drivers/gpu/drm/drm_atomic_helper.c |  95 
> > > 
> > >  drivers/gpu/drm/drm_plane_helper.c  | 111 
> > > +++-
> > >  drivers/gpu/drm/drm_simple_kms_helper.c |   9 ++-
> > >  drivers/gpu/drm/i915/intel_display.c|  20 ++---
> > >  drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +-
> > >  drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +-
> > >  drivers/gpu/drm/meson/meson_plane.c |   8 +-
> > >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
> > >  drivers/gpu/drm/nouveau/nv50_display.c  |  18 +++--
> > >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
> > >  drivers/gpu/drm/tegra/dc.c  |   4 +-
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  40 --
> > >  drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
> > >  include/drm/drm_atomic_helper.h |   7 ++
> > >  include/drm/drm_plane_helper.h  |   5 --
> > >  17 files changed, 187 insertions(+), 183 deletions(-)
> > > 
> > > -- 
> > > 2.13.6
> > > 
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] exynos-drm-next

[Daniel Vetter]

On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
> Hi Dave,
> 
> 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
> > On 26 October 2017 at 11:37, Inki Dae  wrote:
> >> Hi Dave,
> >>
> >>Improving Exynos DRM HDMI and Mixer drivers and also adding
> >>HDMI audio support.
> >>
> >>Please kindly let me know if there is any problem.
> >>
> >>Ps. we are reviewing IPP v2 driver[1] which controls post processor 
> >> devices
> >>such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to 
> >> request
> >>git pull one more time after review.
> > 
> > Hi Inki,
> > 
> > I dropped the ball a bit here, I do think the second pull with IPP is
> > probably a bit late,
> > I think I'd like more assurance that the UAPI for IPP is to be used in
> > some upstream
> > shipping project (forks of mpv not withstanding, unless this fork
> > ships in some distro
> > or product).
> 
> I also commented same thing internally to author - Marek - of IPP v2 but I 
> thought existing one is really ugly thing so may be better to change it as 
> soon as possible before other users use this one.
> Anyway, we will merge user space for IPP v2 to libdrm first, and then Linux 
> platform. I hope IPPv2 would be merged as soon as possible in next turn.

Beyond what Daniel said we unfortunately don't have time machines, so
fixing bad uapi isn't really possible. The problem is that even if you
create ippv2, then people can still use ippv1, and it needs to keep
working (almost) forever. So once a bad uapi is in, it's in, and there's
no good reason to add more uapi (since in 2 years you might again realize
it's not a good idea) to "fix" that. You can't fix bad uapi.

That's why we have all these rules to make sure as little bad uapi as
possible lands, since the cost is so bad.

So yeah unless you have new hw that needs it, or there's another clear
need (performance, features), you're stuck with ippv1. "It's cleaner" is
not a good reason to rev uapi, since our experience with all the uapi in
drm clearly shows we can't predict the future :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Operation context for TTM

[Dieter Nützel]

For the series:

Tested-by: Dieter Nützel 

on RX580
amd-staging-drm-next 85d09ce5e5039644487e9508d6359f9f4cf64427

with glmark2, DiRT Rally and F1 2017 (radv)

Dieter

Am 17.11.2017 11:49, schrieb Christian König:

Hi everyone,

Michel already reviewed this back in April, but I didn't found time to
actually fully test it before now.

So sending this one out once more because it's an interface change
which affects all driver using TTM.

Please review and/or comment.

Regards,
Christian.

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

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

Re: [PATCH 8/8] drm/amdgpu: use the new TTM bytes moved counter v2

[Chunming Zhou]

 Reviewed-by: Chunming Zhou  for the series.


btw: any new patch based on this for enabling eviction and swapout for 
per-vm-bo?


Regards,
David Zhou
On 2017年11月17日 18:49, Christian König wrote:

Instead of the global statistics use the per context bytes moved counter.

v2: rebased

Signed-off-by: Christian König 
Reviewed-by: Michel Dänzer 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  9 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 +++---
  2 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 41994b87c76e..bea5bc64bf7b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -344,7 +344,6 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
struct ttm_operation_ctx ctx = { true, false };
-   u64 initial_bytes_moved, bytes_moved;
uint32_t domain;
int r;
  
@@ -374,15 +373,13 @@ static int amdgpu_cs_bo_validate(struct amdgpu_cs_parser *p,
  
  retry:

amdgpu_ttm_placement_from_domain(bo, domain);
-   initial_bytes_moved = atomic64_read(>num_bytes_moved);
r = ttm_bo_validate(>tbo, >placement, );
-   bytes_moved = atomic64_read(>num_bytes_moved) -
- initial_bytes_moved;
-   p->bytes_moved += bytes_moved;
+
+   p->bytes_moved += ctx.bytes_moved;
if (adev->mc.visible_vram_size < adev->mc.real_vram_size &&
bo->tbo.mem.mem_type == TTM_PL_VRAM &&
bo->tbo.mem.start < adev->mc.visible_vram_size >> PAGE_SHIFT)
-   p->bytes_moved_vis += bytes_moved;
+   p->bytes_moved_vis += ctx.bytes_moved;
  
  	if (unlikely(r == -ENOMEM) && domain != bo->allowed_domains) {

domain = bo->allowed_domains;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 15027f751e07..dc0a8be98043 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -331,7 +331,6 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
struct amdgpu_bo *bo;
enum ttm_bo_type type;
unsigned long page_align;
-   u64 initial_bytes_moved, bytes_moved;
size_t acc_size;
int r;
  
@@ -406,22 +405,19 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,

bo->tbo.bdev = >mman.bdev;
amdgpu_ttm_placement_from_domain(bo, domain);
  
-	initial_bytes_moved = atomic64_read(>num_bytes_moved);

-   /* Kernel allocation are uninterruptible */
r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
 >placement, page_align, , NULL,
 acc_size, sg, resv, _ttm_bo_destroy);
if (unlikely(r != 0))
return r;
  
-	bytes_moved = atomic64_read(>num_bytes_moved) -

- initial_bytes_moved;
if (adev->mc.visible_vram_size < adev->mc.real_vram_size &&
bo->tbo.mem.mem_type == TTM_PL_VRAM &&
bo->tbo.mem.start < adev->mc.visible_vram_size >> PAGE_SHIFT)
-   amdgpu_cs_report_moved_bytes(adev, bytes_moved, bytes_moved);
+   amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved,
+ctx.bytes_moved);
else
-   amdgpu_cs_report_moved_bytes(adev, bytes_moved, 0);
+   amdgpu_cs_report_moved_bytes(adev, ctx.bytes_moved, 0);
  
  	if (kernel)

bo->tbo.priority = 1;


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

[PATCH v2 4/4] drm/tinydrm: add driver for ILI9225 panels

[David Lechner]

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See .

Signed-off-by: David Lechner 
---

v2 changes:
* use exported mipi_dbi_* functions from patch 3/4
* new ili9225_command function

 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c | 468 ++
 4 files changed, 485 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR ILITEK ILI9225 PANELS
+M: David Lechner 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
 config TINYDRM_MIPI_DBI
tristate
 
+config TINYDRM_ILI9225
+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
 obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
 
 # Displays
+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..3b766a2
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,468 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner 
+ *
+ * Some code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * 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 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_50x54
+#define ILI9225_GAMMA_CONTROL_60x55
+#define ILI9225_GAMMA_CONTROL_70x56
+#define ILI9225_GAMMA_CONTROL_80x57

[PATCH v2 1/4] dt-bindings: Add vendor prefix for ilitek

[David Lechner]

This adds the vendor prefix ilitek for ILI Technology Corporation (ILITEK).

This prefix is already used several places and I will be adding more.

Signed-off-by: David Lechner 
---

v2 changes:
* New patch in v2

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6cf1dc5..cf41a33 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -150,6 +150,7 @@ i2seI2SE GmbH
 ibmInternational Business Machines (IBM)
 idtIntegrated Device Technologies, Inc.
 ifiIngenieurburo Fur Ic-Technologie (I/F/I)
+ilitek ILI Technology Corporation (ILITEK)
 imgImagination Technologies Ltd.
 infineon Infineon Technologies
 inforceInforce Computing
-- 
2.7.4

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

[PATCH v2 0/4] DRM driver for ILI9225 display panels

[David Lechner]

This is a new driver for ILI9225 based display panels.

v2 changes:
* New patch for ilitek vendor prefix.
* Use "ilitek" instead of "generic" in dt-bindings
* New patch to export 2 mipi_dbi_* functions
* Clean up ILI9225 driver based on feedback

David Lechner (4):
  dt-bindings: Add vendor prefix for ilitek
  dt-bindings: Add binding for Ilitek ILI9225 display panels
  drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed
  drm/tinydrm: add driver for ILI9225 panels

 .../devicetree/bindings/display/ilitek,ili9225.txt |  25 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c  | 468 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c |  24 +-
 include/drm/tinydrm/mipi-dbi.h |   4 +-
 8 files changed, 534 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

-- 
2.7.4

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

[PATCH v2 3/4] drm/tinydrm: export mipi_dbi_buf_copy and mipi_dbi_spi_cmd_max_speed

[David Lechner]

This exports the mipi_dbi_buf_copy() and mipi_dbi_spi_cmd_max_speed()
functions so that they can be shared with other drivers.

Signed-off-by: David Lechner 
---

v2 changes:
* new patch in v2

 drivers/gpu/drm/tinydrm/mipi-dbi.c | 24 
 include/drm/tinydrm/mipi-dbi.h |  4 +++-
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 347f9b2..aa6b6ce 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -154,8 +154,18 @@ int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 
*data, size_t len)
 }
 EXPORT_SYMBOL(mipi_dbi_command_buf);
 
-static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip, bool swap)
+/**
+ * mipi_dbi_buf_copy - Copy a framebuffer, transforming it if necessary
+ * @dst: The destination buffer
+ * @fb: The source framebuffer
+ * @clip: Clipping rectangle of the area to be copied
+ * @swap: When true, swap MSB/LSB of 16-bit values
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap)
 {
struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
@@ -192,6 +202,7 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,
 DMA_FROM_DEVICE);
return ret;
 }
+EXPORT_SYMBOL(mipi_dbi_buf_copy);
 
 static int mipi_dbi_fb_dirty(struct drm_framebuffer *fb,
 struct drm_file *file_priv,
@@ -444,18 +455,23 @@ EXPORT_SYMBOL(mipi_dbi_display_is_on);
 
 #if IS_ENABLED(CONFIG_SPI)
 
-/*
+/**
+ * mipi_dbi_spi_cmd_max_speed - get the maximum SPI bus speed
+ * @spi: SPI device
+ * @len: The transfer buffer length.
+ *
  * Many controllers have a max speed of 10MHz, but can be pushed way beyond
  * that. Increase reliability by running pixel data at max speed and the rest
  * at 10MHz, preventing transfer glitches from messing up the init settings.
  */
-static u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len)
 {
if (len > 64)
return 0; /* use default */
 
return min_t(u32, 1000, spi->max_speed_hz);
 }
+EXPORT_SYMBOL(mipi_dbi_spi_cmd_max_speed);
 
 /*
  * MIPI DBI Type C Option 1
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index 83346dd..5d0e82b 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -72,10 +72,12 @@ void mipi_dbi_pipe_enable(struct drm_simple_display_pipe 
*pipe,
 void mipi_dbi_pipe_disable(struct drm_simple_display_pipe *pipe);
 void mipi_dbi_hw_reset(struct mipi_dbi *mipi);
 bool mipi_dbi_display_is_on(struct mipi_dbi *mipi);
+u32 mipi_dbi_spi_cmd_max_speed(struct spi_device *spi, size_t len);
 
 int mipi_dbi_command_read(struct mipi_dbi *mipi, u8 cmd, u8 *val);
 int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 *data, size_t len);
-
+int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip, bool swap);
 /**
  * mipi_dbi_command - MIPI DCS command with optional parameter(s)
  * @mipi: MIPI structure
-- 
2.7.4

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

[PATCH v2 2/4] dt-bindings: Add binding for Ilitek ILI9225 display panels

[David Lechner]

This adds a new binding for display panels that use an Ilitek ILI9225
controller.

The "ilitek,ili9225-2.2in-176x220" device listed has no identification
markings whatsoever and an hour of googling turned up nothing, hence the use
of the size and resolution in the name instead of a model name.

An example of this nameless device can be found at:
https://github.com/Nkawu/TFT_22_ILI9225

Signed-off-by: David Lechner 
---

v2 changes:
* renamed compatible string based on feedback

 .../devicetree/bindings/display/ilitek,ili9225.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
new file mode 100644
index 000..21607a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
@@ -0,0 +1,25 @@
+Ilitek ILI9225 display panels
+
+This binding is for display panels using an Ilitek ILI9225 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "ilitek,ili9225-2.2in-176x220"
+- rs-gpios:Register select signal
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "ilitek,ili9225-2.2in-176x220";
+   reg = <0>;
+   spi-max-frequency = <1200>;
+   rs-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   };
-- 
2.7.4

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

[Bug 103817] [bisected] Heavy flickering in Wine

[bugzilla-daemon]

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

--- Comment #1 from bartos.p...@gmail.com ---
Created attachment 135588
  --> https://bugs.freedesktop.org/attachment.cgi?id=135588=edit
Jerricho before commit 4b0dc09

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

[Bug 103817] [bisected] Heavy flickering in Wine

[bugzilla-daemon]

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

Bug ID: 103817
   Summary: [bisected] Heavy flickering in Wine
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bartos.p...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135587
  --> https://bugs.freedesktop.org/attachment.cgi?id=135587=edit
Flickering in Jerricho

Hi,
since commit 4b0dc098b2561c07c59f7dab2813640a25789bf1 there is heavy flickering
in games played via Wine (I've found problems in Jerricho (worst), Mafia 2 and
Far Cry 2). I did not find any problems in native games which I have installed.

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #82 from mirh  ---
Guess it make sense. 
A thread per "actual issue to fix". 

Even though, it should take nothing to just change component from mesa to DRI
:p

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

--- Comment #81 from Józef Kucia  ---
(In reply to mirh from comment #80)
> I also agree with Fabian. 
> Application going crazy with its own business is totally not a "problem of
> the driver".. 
> But compromising system stability definitively is.
If you want to make this bug about unreliable/unimplemented GPU resets in
amdgpu.ko, then it is filed against the wrong component. AFAIK there is nothing
to fix in Mesa. Other than that, the bug is full of comments about the source
of GPU hang. It may be better to file a new bug for implementing/fixing GPU
resets in amdgpu.

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

[Bug 197925] New: [amdgpu_dc][carrizo] multiple monitor handling errors

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=197925

Bug ID: 197925
   Summary: [amdgpu_dc][carrizo] multiple monitor handling errors
   Product: Drivers
   Version: 2.5
Kernel Version: 4.14+ (4.15 - git)
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: kwka...@gmx.com
Regression: No

Created attachment 260721
  --> https://bugzilla.kernel.org/attachment.cgi?id=260721=edit
pertinent dmesg output

Not necessarily a bug, since I am running experimental features, but figured I
would get the ball rolling.

Running current kernel (commit 1deab8ce2c91e3b16563b7a7ea150f82334262ec)
compiled with the following configuration flags:

CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_PRE_VEGA=y
CONFIG_DRM_AMD_DC_FBC=y
CONFIG_HSA_AMD=m

On the following hardware: Toshiba L55D-C with AMD A10-8700P

With: Fedora 27 Workstation on top

This generates a dmesg error on boot:

[5.350313] [drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed
to blank crtc!

It also has multiple non-desirable behaviors (which may be gnome- or
Fedora-related...)

1) Fails to turn off backlight upon internal monitor shut-off.
2) Fails to turn on external monitor upon resume from idle. This can be
remedied by forcing the monitor back on via twiddling of other settings.
3) Fails to turn on either external or internal monitor upon resume from sleep
- this one isn't easily remedied, due to no visual feedback.

I am attaching pertinent dmesg lines (dmesg | grep -e amdgpu -e drm -e kfd) >
dmesg.txt)

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

[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!

[bugzilla-daemon]

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

--- Comment #1 from dwagner  ---
Sadly, not only did this bug not attract any attention, it also still occurs,
and seemingly even more frequent than before, on current bleeding-edge kernels
from amd-staging-drm-next, and also with the now current Firefox 57 and the now
current versions of Xorg, Mesa etc. from Arch Linux.

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

mirh  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NOTOURBUG   |---

--- Comment #80 from mirh  ---
I also agree with Fabian. 
Application going crazy with its own business is totally not a "problem of the
driver".. 
But compromising system stability definitively is.

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

--- Comment #79 from Fabian Maurer  ---
Nice to hear the bug is fixed in wine, but the mesa bug still exists, so the
resolution is wrong. It's simply not acceptable for a driver to freeze the
system if an application misbehaves.

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

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Greg KH]

On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
> > On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
> >> Greg KH wrote:
> >>> On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
>  Greg KH wrote:
> > On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
> >> Hi!
> >>
> >> Hopefully the right addressee.
> >>
> >> Encountered two bad backports which cause screen-flicker.
> >> dmesg shows:
> >>
> >> ...
> >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO 
> >> underrun
> >> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
> >> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
> >> underrun
> >> ...
> >>
> >> CPU: Intel Core i3 (Clarkdale/Ironlake)
> >>
> >> The backports are:
> >>
> >> - diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index 49de476..277a802 100644
> >> - diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index a19ec06..3ce9ba3 100644
> >>
> >> After reversing them the flicker is gone, no more messages in dmesg. 
> >> All
> >> else OK so far.
> >
> > So which commit was the one that caused the problem?  I will be glad to
> > revert it.
> >
> > thanks,
> >
> > greg k-h
> >
> >
> 
>  I started by reverting the more complex one first ("index
>  49de476..277a802100644"). But the kernel wouldn't compile then.
> >>>
> >>> What git commit id is that?  I don't see those ids in the 4.9-stable
> >>> tree.
> >>>
>  So I also reverted "index a19ec06..3ce9ba3 100644". After that the
>  kernel compiled just fine and the problems were gone (still are).
> >>>
> >>> Same here, what git commit id was this?
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>
> >> OK, no mistake. IIRC, I took the patches (and the IDs) from the
> >> changelog for patch-4.9.62. I've attached both, so you can check yourself.
> >>
> >> I've also applied a freshly downloaded patch-4.9.62 to a freshly
> >> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
> >> reverted the two patches but I'm confident that after having done so the
> >> flicker will be gone. If not I'll let you know.
> >>
> >> As a good news: 4.14 is *not* affected. So to me it seems those two
> >> patches are part of sort of a package and can not be backported alone.
> >>
> >> So long!
> >> Rainer Fiebig
> > 
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index 49de476..277a802 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -27,6 +27,7 @@
> >>  
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "i915_drv.h"
> >>  #include "intel_drv.h"
> >>  #include "../../../platform/x86/intel_ips.h"
> >> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
> >> drm_i915_private *dev_priv,
> >> const struct intel_crtc *intel_crtc,
> >> int level,
> >> struct intel_crtc_state *cstate,
> >> -   struct intel_plane_state *pristate,
> >> -   struct intel_plane_state *sprstate,
> >> -   struct intel_plane_state *curstate,
> >> +   const struct intel_plane_state *pristate,
> >> +   const struct intel_plane_state *sprstate,
> >> +   const struct intel_plane_state *curstate,
> >> struct intel_wm_level *result)
> >>  {
> >>uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> >> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
> >> intel_crtc_state *cstate)
> >>struct intel_pipe_wm *pipe_wm;
> >>struct drm_device *dev = state->dev;
> >>const struct drm_i915_private *dev_priv = to_i915(dev);
> >> -  struct intel_plane *intel_plane;
> >> -  struct intel_plane_state *pristate = NULL;
> >> -  struct intel_plane_state *sprstate = NULL;
> >> -  struct intel_plane_state *curstate = NULL;
> >> +  struct drm_plane *plane;
> >> +  const struct drm_plane_state *plane_state;
> >> +  const struct intel_plane_state *pristate = NULL;
> >> +  const struct intel_plane_state *sprstate = NULL;
> >> +  const struct intel_plane_state *curstate = NULL;
> >>int level, max_level = ilk_wm_max_level(dev), usable_level;
> >>struct ilk_wm_maximums max;
> >>  
> >>pipe_wm = >wm.ilk.optimal;
> >>  
> >> -  for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> >> -  struct intel_plane_state *ps;
> >> +  drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, 
> >> >base) {
> >> +  const struct 

[Bug 103814] incorrect dust rendering in hl2ep1 with mesa 17.2 and above

[bugzilla-daemon]

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

Hleb Valoshka <375...@gmail.com> changed:

   What|Removed |Added

Summary|incorrect dust rendering in |incorrect dust rendering in
   |hl2ep1  |hl2ep1 with mesa 17.2 and
   ||above

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

[Bug 103814] incorrect dust rendering in hl2ep1

[bugzilla-daemon]

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

Bug ID: 103814
   Summary: incorrect dust rendering in hl2ep1
   Product: Mesa
   Version: 17.2
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: 375...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135585
  --> https://bugs.freedesktop.org/attachment.cgi?id=135585=edit
example of incorrect rendering

Hi,

Mesa 17.2 and above incorrectly renders dust in hl2ep1, it looks like the
screen is divided into four parts and only one or two of them are filled with
the dust.

I've checked 17.3.0~rc3, 17.2.5, they have this issue. 17.1.5 doesn't have it.

I use Radeon 7750.

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

FOSDEM 2018: Graphics DevRoom: Call for speaker.

[Luc Verhaegen]

Hi,

At FOSDEM on saturday the 3rd of february 2018, there will be another 
graphics DevRoom. URL: https://fosdem.org/2018/

The focus of this DevRoom is of course the same as the previous 
editions, namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel 
or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management, low level toolkit stuff, and other areas which 
i might have overlooked above are accepted.

Slots will be handed out on a first come, first serve basis. The best 
slots will go to those who apply the earliest. We have the devroom from 
10:30 til 19:00, giving us 8h30, so eight 50 minute talkes and one 20 
minute talk are available.

Talk Submission:


Like the last few years, the pentabarf system will be used for talk 
submission.

https://penta.fosdem.org/submission/FOSDEM18

Remember that FOSDEM is not like XDC, it's not some 50 odd people 
meeting with a sliding schedule which only gets filled out on the last 
day. Upwards of 1 people are visiting this event, and most of them 
get a printed booklet or use the schedule on the FOSDEM website or an 
app for their phone to figure out what to watch or participate in next. 
So please put some effort in your talk submission and details.

Since this an open source community event, please refrain from turning 
in a talk that is a pure corporate or product commercial. Also, if you 
are unsure on whether you can come or not (this is FOSDEM, why are you 
not there anyway?), please wait with submitting your talk. Submitting a 
talk and then not turning up because you could not be bothered is a 
sure-fire way to get larted and then to never be allowed to talk again.

When in pentabarf, please give the abstract and description, for both 
the event and the speaker, some thought. The abstract should be a 
shortened description, and the event abstract will sometimes even be 
printed directly in the booklet. BUT, on the website the abstract is 
immediately followed by the full description. If your abstract is fully 
descriptive, while terse, you might get away with just the abstract.

All talks will be recorded, and will be streamed out live, and will 
later be made available as CC-BY after a few days.

As for deadlines, the fosdem organizers want to have a finished schedule 
by the 15th of december. Don't count on this deadline: first come first 
serve! The worst slots will be assigned to those who come last, which 
could be pretty dire given that there is the traditional FOSDEM beer 
event the night before ;)

Please try to re-use your accounts from the previous years, i hope that 
this year you can actually recycle your data. If you have forgotten your 
password, then you can reset it here: 
https://penta.fosdem.org/user/forgot_password If there are any issues, 
just poke me here or on IRC.

Necessary information:
--

Below is a list of what i need to see filled in in pentabarf when you 
apply for a devroom before i consider it a valid submission. Remember: 
first come, first serve. The best slots (which are on saturday 
afternoon) are for the earliest submissions.

On your personal page:
* General:
  * First and last name
  * Nickname
  * Image
* Contact:
  * email address
  * mobile number (this is a very hard requirement as there will be no
   other reliable form of emergency communication on the day)
* Description:
  * Abstract
  * Description

Create an event:
* On the General page:
  * Event title
  * Event subtitle.
  * Track: Graphics Devroom
  * Event type: Lecture (talk) or Meeting (BoF)
* Persons:
  * Add yourself as speaker.
* Description:
  * Abstract:
  * Full Description
* Links:
  * Add relevant links.

Everything else can be ignored or will be filled in by me or the FOSDEM 
organizers. Remember, i will only schedule your talk after the basics 
are somewhat filled in (you still can change them until december 15th).

I will be keeping a keen eye on your submissions and will come back with 
further questions or make small fixes as needed. Feel free to poke me 
with any questions or anything, both on irc (libv@freenode) and on 
email.

That's about it. Hope to see you all at FOSDEM :)

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

[Bug 101731] System freeze with AMDGPU when playing The Witcher 3 (GOG GOTY)

[bugzilla-daemon]

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

Józef Kucia  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #78 from Józef Kucia  ---
Fixed in Wine 2.21

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

Re: 4.9.62: intermittent flicker after upgrade from 4.9.61

[Greg KH]

On Sun, Nov 19, 2017 at 12:56:26PM +0100, Rainer Fiebig wrote:
> Greg KH wrote:
> > On Sat, Nov 18, 2017 at 05:08:20PM +0100, Rainer Fiebig wrote:
> >> Greg KH wrote:
> >>> On Sat, Nov 18, 2017 at 01:47:32PM +0100, Rainer Fiebig wrote:
>  Hi!
> 
>  Hopefully the right addressee.
> 
>  Encountered two bad backports which cause screen-flicker.
>  dmesg shows:
> 
>  ...
>  [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
>  [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun
>  ...
> 
>  CPU: Intel Core i3 (Clarkdale/Ironlake)
> 
>  The backports are:
> 
>  - diff --git a/drivers/gpu/drm/i915/intel_pm.c
>  b/drivers/gpu/drm/i915/intel_pm.c
>  index 49de476..277a802 100644
>  - diff --git a/drivers/gpu/drm/i915/intel_drv.h
>  b/drivers/gpu/drm/i915/intel_drv.h
>  index a19ec06..3ce9ba3 100644
> 
>  After reversing them the flicker is gone, no more messages in dmesg. All
>  else OK so far.
> >>>
> >>> So which commit was the one that caused the problem?  I will be glad to
> >>> revert it.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>>
> >>>
> >>
> >> I started by reverting the more complex one first ("index
> >> 49de476..277a802100644"). But the kernel wouldn't compile then.
> > 
> > What git commit id is that?  I don't see those ids in the 4.9-stable
> > tree.
> > 
> >> So I also reverted "index a19ec06..3ce9ba3 100644". After that the
> >> kernel compiled just fine and the problems were gone (still are).
> > 
> > Same here, what git commit id was this?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> OK, no mistake. IIRC, I took the patches (and the IDs) from the
> changelog for patch-4.9.62. I've attached both, so you can check yourself.
> 
> I've also applied a freshly downloaded patch-4.9.62 to a freshly
> expanded 4.9 and re-compiled. The flicker is there. I haven't yet
> reverted the two patches but I'm confident that after having done so the
> flicker will be gone. If not I'll let you know.
> 
> As a good news: 4.14 is *not* affected. So to me it seems those two
> patches are part of sort of a package and can not be backported alone.
> 
> So long!
> Rainer Fiebig

> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 49de476..277a802 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  #include "../../../platform/x86/intel_ips.h"
> @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const struct 
> drm_i915_private *dev_priv,
>const struct intel_crtc *intel_crtc,
>int level,
>struct intel_crtc_state *cstate,
> -  struct intel_plane_state *pristate,
> -  struct intel_plane_state *sprstate,
> -  struct intel_plane_state *curstate,
> +  const struct intel_plane_state *pristate,
> +  const struct intel_plane_state *sprstate,
> +  const struct intel_plane_state *curstate,
>struct intel_wm_level *result)
>  {
>   uint16_t pri_latency = dev_priv->wm.pri_latency[level];
> @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct 
> intel_crtc_state *cstate)
>   struct intel_pipe_wm *pipe_wm;
>   struct drm_device *dev = state->dev;
>   const struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_plane *intel_plane;
> - struct intel_plane_state *pristate = NULL;
> - struct intel_plane_state *sprstate = NULL;
> - struct intel_plane_state *curstate = NULL;
> + struct drm_plane *plane;
> + const struct drm_plane_state *plane_state;
> + const struct intel_plane_state *pristate = NULL;
> + const struct intel_plane_state *sprstate = NULL;
> + const struct intel_plane_state *curstate = NULL;
>   int level, max_level = ilk_wm_max_level(dev), usable_level;
>   struct ilk_wm_maximums max;
>  
>   pipe_wm = >wm.ilk.optimal;
>  
> - for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> - struct intel_plane_state *ps;
> + drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, 
> >base) {
> + const struct intel_plane_state *ps = 
> to_intel_plane_state(plane_state);
>  
> - ps = intel_atomic_get_existing_plane_state(state,
> -intel_plane);
> - if (!ps)
> - continue;
> -
> - if (intel_plane->base.type == 

[PATCH libdrm 2/2] tests/modeprint: Print details for IN_FORMATS blob

[Wladimir J. van der Laan]

Pretty-print formats and modifiers in IN_FORMATS blob.

Signed-off-by: Wladimir J. van der Laan 
---
 tests/modeprint/modeprint.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 42c0a1b..ce84279 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -93,6 +93,28 @@ static int printMode(struct drm_mode_modeinfo *mode)
return 0;
 }
 
+static int printBlob(const char *name, void *data, uint32_t length)
+{
+   if (!strcmp(name, "IN_FORMATS")) {
+   struct drm_format_modifier_blob *m = data;
+   uint32_t *fmts = (uint32_t *)(((char *)data) + 
m->formats_offset);
+   struct drm_format_modifier *mod = (struct drm_format_modifier 
*)(((char *)data) + m->modifiers_offset);
+   int i,j,k;
+   printf("\tmodifiers:\n");
+   for (j = 0; j < (int)m->count_modifiers; j++) {
+   printf("\t\t0x%016" PRIx64, mod[j].modifier);
+   for (i = 0; i < 64 && (i + mod[j].offset) < 
(int)m->count_formats; i++) {
+   if (mod[j].formats & (1<> 24, 
fmts[k] >> 16, fmts[k] >> 8, fmts[k] >> 0);
+   }
+   }
+   printf("\n");
+   }
+   }
+   return 0;
+}
+
 static int printProperty(int fd, drmModePropertyPtr props, uint64_t value)
 {
const char *name = NULL;
@@ -120,6 +142,7 @@ static int printProperty(int fd, drmModePropertyPtr props, 
uint64_t value)
blob = drmModeGetPropertyBlob(fd, value);
if (blob) {
printf("blob is %d length, %08X\n", blob->length, 
*(uint32_t *)blob->data);
+   printBlob(props->name, blob->data, blob->length);
drmModeFreePropertyBlob(blob);
} else {
printf("error getting blob %" PRIu64 "\n", value);
-- 
2.7.4

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

[PATCH libdrm 0/2] Print plane modifiers in modeprint

[Wladimir J. van der Laan]

This patch series adds support for printing the properties of all DRM mode
objects. This is subsequently used to parse the IN_FORMATS blob to be able to
print the available modifiers and their formats.

Wladimir J. van der Laan (2):
  tests/modeprint: Print plane and other object properties
  tests/modeprint: Print details for IN_FORMATS blob

 tests/modeprint/modeprint.c | 122 ++--
 1 file changed, 118 insertions(+), 4 deletions(-)

-- 
2.7.4

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

[PATCH libdrm 1/2] tests/modeprint: Print plane and other object properties

[Wladimir J. van der Laan]

Make it possible to print plane properties, and the properties of other
DRM mode objects, if available.

Signed-off-by: Wladimir J. van der Laan 
---
 tests/modeprint/modeprint.c | 100 ++--
 1 file changed, 96 insertions(+), 4 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 0d85410..42c0a1b 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -52,6 +52,7 @@ int full_modes;
 int encoders;
 int crtcs;
 int fbs;
+int planes;
 char *module_name;
 
 static const char* getConnectionText(drmModeConnection conn)
@@ -92,7 +93,7 @@ static int printMode(struct drm_mode_modeinfo *mode)
return 0;
 }
 
-static int printProperty(int fd, drmModeResPtr res, drmModePropertyPtr props, 
uint64_t value)
+static int printProperty(int fd, drmModePropertyPtr props, uint64_t value)
 {
const char *name = NULL;
int j;
@@ -141,6 +142,25 @@ static int printProperty(int fd, drmModeResPtr res, 
drmModePropertyPtr props, ui
return 0;
 }
 
+static int printObjectProps(int fd, uint32_t object_id, uint32_t object_type)
+{
+   uint32_t i;
+
+   drmModeObjectPropertiesPtr props = drmModeObjectGetProperties(fd, 
object_id, object_type);
+   if (props) {
+   for (i = 0; i < props->count_props; i++) {
+   drmModePropertyPtr prop = drmModeGetProperty(fd, 
props->props[i]);
+   if (prop) {
+   printProperty(fd, prop, props->prop_values[i]);
+   drmModeFreeProperty(prop);
+   }
+   }
+   drmModeFreeObjectProperties(props);
+   }
+
+   return 0;
+}
+
 static const char * const output_names[] = { "None",
 "VGA",
 "DVI-I",
@@ -204,7 +224,7 @@ static int printConnector(int fd, drmModeResPtr res, 
drmModeConnectorPtr connect
for (i = 0; i < connector->count_props; i++) {
props = drmModeGetProperty(fd, connector->props[i]);
if (props) {
-   printProperty(fd, res, props, 
connector->prop_values[i]);
+   printProperty(fd, props, 
connector->prop_values[i]);
drmModeFreeProperty(props);
}
}
@@ -221,6 +241,11 @@ static int printEncoder(int fd, drmModeResPtr res, 
drmModeEncoderPtr encoder, ui
printf("\ttype   :%d\n", encoder->encoder_type);
printf("\tpossible_crtcs  :0x%x\n", encoder->possible_crtcs);
printf("\tpossible_clones :0x%x\n", encoder->possible_clones);
+
+   if (full_props) {
+   printObjectProps(fd, encoder->crtc_id, DRM_MODE_OBJECT_ENCODER);
+   }
+
return 0;
 }
 
@@ -235,6 +260,10 @@ static int printCrtc(int fd, drmModeResPtr res, 
drmModeCrtcPtr crtc, uint32_t id
printf("\tmode   : %p\n", >mode);
printf("\tgamma size : %d\n", crtc->gamma_size);
 
+   if (full_props) {
+   printObjectProps(fd, crtc->crtc_id, DRM_MODE_OBJECT_CRTC);
+   }
+
return 0;
 }
 
@@ -249,16 +278,50 @@ static int printFrameBuffer(int fd, drmModeResPtr res, 
drmModeFBPtr fb)
printf("\tdepth : %i\n", fb->depth);
printf("\tbuffer_id : %i\n", fb->handle);
 
+   if (full_props) {
+   printObjectProps(fd, fb->fb_id, DRM_MODE_OBJECT_FB);
+   }
+
+   return 0;
+}
+
+static int printPlane(int fd, drmModePlanePtr plane)
+{
+   uint32_t i;
+
+   printf("Plane\n");
+   printf("\tcount_formats  : %i\n", plane->count_formats);
+   if (plane->count_formats) {
+   printf("\tformats:");
+   for (i = 0; i < plane->count_formats; i++)
+   printf(" %c%c%c%c", plane->formats[i] >> 24, 
plane->formats[i] >> 16, plane->formats[i] >> 8, plane->formats[i] >> 0);
+   printf("\n");
+   }
+   printf("\tplane_id   : %i\n", plane->plane_id);
+   printf("\tcrtc_id: %i\n", plane->crtc_id);
+   printf("\tfb_id  : %i\n", plane->fb_id);;
+   printf("\tcrtc_x : %i\n", plane->crtc_x);
+   printf("\tcrtc_y : %i\n", plane->crtc_y);
+   printf("\tx  : %i\n", plane->x);
+   printf("\ty  : %i\n", plane->y);
+   printf("\tpossible_crtcs : 0x%x\n", plane->possible_crtcs);
+   printf("\tgamma_size : %i\n", plane->gamma_size);
+
+   if (full_props) {
+   printObjectProps(fd, plane->plane_id, DRM_MODE_OBJECT_PLANE);
+   }
+
return 0;
 }
 
-static int printRes(int fd, drmModeResPtr res)
+static int printRes(int fd, drmModeResPtr res, drmModePlaneResPtr pres)
 {
int i;
drmModeFBPtr fb;
drmModeCrtcPtr crtc;
drmModeEncoderPtr encoder;
 

Re: [PATCH 1/1] drm/amdkfd: Do not ignore requested queue size during allocation

[Oded Gabbay]

On Thu, Nov 16, 2017 at 11:36 PM, Jan Vesely  wrote:
> Signed-off-by: Jan Vesely 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
> index f1d48281e322..b3bee39661ab 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
> @@ -37,15 +37,16 @@ static bool initialize_vi(struct kernel_queue *kq, struct 
> kfd_dev *dev,
> enum kfd_queue_type type, unsigned int queue_size)
>  {
> int retval;
> +   unsigned int size = ALIGN(queue_size, PAGE_SIZE);
>
> -   retval = kfd_gtt_sa_allocate(dev, PAGE_SIZE, >eop_mem);
> +   retval = kfd_gtt_sa_allocate(dev, size, >eop_mem);
> if (retval != 0)
> return false;
>
> kq->eop_gpu_addr = kq->eop_mem->gpu_addr;
> kq->eop_kernel_addr = kq->eop_mem->cpu_ptr;
>
> -   memset(kq->eop_kernel_addr, 0, PAGE_SIZE);
> +   memset(kq->eop_kernel_addr, 0, size);
>
> return true;
>  }
> --
> 2.13.6
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Thanks!
Applied to -next tree
Oded
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] amdkfd next 4.15 (fixes)

[Oded Gabbay]

Hi Dave,
Did you pick this pull request ?
If not, please disregard it and I'll send you a new one for -rc1 with
two additional fixes (total of 5 commits).

Thanks,
Oded

On Thu, Nov 9, 2017 at 9:38 AM, Oded Gabbay  wrote:
> Hi Dave,
>
> Three small fixes to the CIK SDMA code in amdkfd
>
> Thanks,
> Oded
>
> The following changes since commit d65d31388a23b14df9494135ad6c6549a59a3caa:
>
>   Merge tag 'drm-misc-next-fixes-2017-11-07' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-08 05:22:49 
> +1000)
>
> are available in the git repository at:
>
>   git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2017-11-09
>
> for you to fetch changes up to 5d21e8142512612ebc6a381f6db7aaa10cdf0e19:
>
>   drm/amdkfd: Fix SDMA oversubsription handling (2017-11-01 19:21:57 -0400)
>
> 
> Felix Kuehling (2):
>   drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode
>   drm/amdkfd: Fix SDMA oversubsription handling
>
> shaoyunl (1):
>   drm/amdkfd: Fix SDMA ring buffer size calculation
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c  | 47 
> --
>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c   |  4 +-
>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +
>  3 files changed, 54 insertions(+), 15 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel