[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #21 from Richard Thier  ---
Hi!

I have applied this "possible fix" patch to the (nearly) latest 19.x from git
and I get an assertion error there.

glxinfo: ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:1023:
radeon_winsys_bo_create: Assertion `heap >= 0 && heap <
RADEON_MAX_CACHED_HEAPS' failed.

-- 
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 203779] booting with kernel version 5.1.6 on RX 580 hangs

2019-06-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=203779

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #20 from Marek Olšák  ---
GEM_CREATE just creates a buffer, you should always see them, but a lot less.

-- 
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 110674] Crashes / Resets From AMDGPU / Radeon VII

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110674

--- Comment #36 from sehell...@gmail.com ---
Created attachment 144438
  --> https://bugs.freedesktop.org/attachment.cgi?id=144438=edit
dmesg.log vega20 crash after idle

-- 
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 110674] Crashes / Resets From AMDGPU / Radeon VII

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110674

--- Comment #35 from sehell...@gmail.com ---
Vega20 affected to these or similar bugs, too. On are kernels 5.0.x the primary
monitor falls. Starting with version 5.1.x, hangs and resets gpu already after
login to x-session or after workiing dpms. This is not fixed in version 5.2-rc2
yet. But yesterday I successfully boot and work with two monitors. Problems
appeared only after idle time.
https://bugzilla.kernel.org/show_bug.cgi?id=203781

-- 
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 108973] The game Evil Twin segfaults when loading saved state.

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108973

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Timothy Arceri  ---
Does the game still have the same issue with recent Mesa/Wine releases?

-- 
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 108628] Middle-Earth: Shadow of Mordor: artifacts in benchmark mode

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108628

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Timothy Arceri  ---
Support of 18.2 stopped in December 2018. The issues don't seem to be present
in newer version of Mesa so closing.

-- 
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 1/7] video: add HDMI state notifier support

2019-06-03 Thread Cheng-yi Chiang
On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter  wrote:
>
> On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > From: Hans Verkuil 
> > >
> > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > information from HDMI drivers to their CEC and audio counterparts.
> > >
> > > Based on an earlier version from Russell King:
> > >
> > > https://patchwork.kernel.org/patch/9277043/
> > >
> > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > of an HDMI device.
> > >
> > > When a new notifier is registered the current state will be reported to
> > > that notifier at registration time.
> > >
> > > Based on Hans Verkuil's patch:
> > >
> > > https://patchwork.kernel.org/patch/9472521/
> >
> > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > found in drivers/media/cec/cec-notifier.c?
> >
> > I don't think it makes sense to have two notifier implementations in the 
> > kernel.
> > The original intention was to have the notifier deal with both CEC and ASoC
> > notifications, but there was not enough interest for the ASoC bits at the 
> > time
> > and it was dropped.
> >
> > I am planning changes to the cec-notifier API, I hope to work on that this
> > week. I'll CC you when I post those. Those might be a good starting point
> > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> >
> > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's 
> > been
> > working on some nice cec-notifier improvements as well.
>
> We also have some interfaces for drm/alsa interactions around hdmi
> already in drm/drm_audio_component.h, but it's not used by anything
> outside of i915. Imo we should extend that, not reinvent a new wheel.
>
Hi Daniel,
Thank you for the pointer. Looking at the ops, it seems that it is
specific to HDA.
I am not familiar with drm and HDA. I am not sure how applicable it
would be to report jack status to ASoC.
There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
should be possible.

> Another note: notifiers considered evil, imo. Gets the job done for one
> case, as soon as you have multiple devices and need to make sure you get
> the update for the right one it all comes crashing down. Please create an
> api which registers for updates from a specific device only, plus
> something that has real callbacks (like the drm_audio_component.h thing we
> started already).

To clarify a bit, this hdmi-notifier indeed supports updating from a
specific device only.
hdmi_notifier_get takes a device and return the notifier.

It seems that a major difference between drm_audio_components and
hdmi-notifier is that
drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
On the other hand, hdmi-notifier passes different events using an enum
like HDMI_CONNECTED and let listener handle different events.
In this regard I agree with you that drm_audio_component is cleaner.
Anyway, I will look into it a bit more and see how it works.

Thanks again!

> -Daniel
>
> >
> > Regards,
> >
> >   Hans
> >
> > >
> > > Modified by Cheng-Yi Chiang:
> > >  - Add a section in MAINTAINER.
> > >  - Changes connected and has_eld to bitfield of unsigned int.
> > >  - Other minor fixes to pass checkpatch.pl --strict checks.
> > >
> > > Signed-off-by: Hans Verkuil 
> > > Acked-by: Philipp Zabel 
> > > Signed-off-by: Cheng-Yi Chiang 
> > > ---
> > > The original patch is at
> > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverk...@xs4all.nl
> > >
> > >  MAINTAINERS   |   6 ++
> > >  drivers/video/Kconfig |   3 +
> > >  drivers/video/Makefile|   1 +
> > >  drivers/video/hdmi-notifier.c | 145 ++
> > >  include/linux/hdmi-notifier.h | 112 ++
> > >  5 files changed, 267 insertions(+)
> > >  create mode 100644 drivers/video/hdmi-notifier.c
> > >  create mode 100644 include/linux/hdmi-notifier.h
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 5cfbea4ce575..ffb7376f9509 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > >  S: Maintained
> > >  F: drivers/media/platform/vicodec/*
> > >
> > > +VIDEO FRAMEWORK
> > > +M: Hans Verkuil 
> > > +L: linux-me...@vger.kernel.org
> > > +F: drivers/video/hdmi-notifier.*
> > > +S: Maintained
> > > +
> > >  VIDEO MULTIPLEXER DRIVER
> > >  M: Philipp Zabel 
> > >  L: linux-me...@vger.kernel.org
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > >  config HDMI
> > > bool
> > >
> > > +config HDMI_NOTIFIERS
> > > +   bool
> > > +
> > >  endif # HAS_IOMEM
> > >
> > >  if VT
> > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> 

Re: [PATCH v4] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()

2019-06-03 Thread CK Hu
Hi, Hsin-Yi:

On Thu, 2019-05-30 at 17:18 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which 
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
> irq, it will timeout with this message: "vblank wait timed out on crtc 0". 
> This
> happens sometimes when turning off the screen.
> 
> In drm_atomic_helper.c#disable_outputs(),
> the calling sequence when turning off the screen is:
> 
> 1. mtk_dsi_encoder_disable()
>  --> mtk_output_dsi_disable()
>--> mtk_dsi_stop();  // sometimes make vblank timeout in atomic_disable
>--> mtk_dsi_poweroff();
> 2. mtk_drm_crtc_atomic_disable()
>  --> drm_crtc_wait_one_vblank();
>  ...
>--> mtk_dsi_ddp_stop()
>  --> mtk_dsi_poweroff();
> 
> mtk_dsi_poweroff() has reference count design, change to make mtk_dsi_stop()
> called in mtk_dsi_poweroff() when refcount is 0.

Applied to mediatek-drm-fixes-5.2 [1], thanks.

[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.2

Regards,
CK

> 
> Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending 
> commands to panel")
> Signed-off-by: Hsin-Yi Wang 
> ---
> change log v3->v4:
> * add comment in code.
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..730594a91440 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -630,6 +630,15 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> + /* 
> +  * mtk_dsi_stop() and mtk_dsi_start() is asymmetric, since
> +  * mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(),
> +  * which needs irq for vblank, and mtk_dsi_stop() will disable irq.
> +  * mtk_dsi_start() needs to be called in mtk_output_dsi_enable(),
> +  * after dsi is fully set.
> +  */
> + mtk_dsi_stop(dsi);
> +
>   if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
>   if (dsi->panel) {
>   if (drm_panel_unprepare(dsi->panel)) {
> @@ -696,7 +705,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>   }
>   }
>  
> - mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  
>   dsi->enabled = false;




Re: [PATCH 1/7] video: add HDMI state notifier support

2019-06-03 Thread Cheng-yi Chiang
On Mon, Jun 3, 2019 at 3:46 PM Hans Verkuil  wrote:
>
> On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > From: Hans Verkuil 
> >
> > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > information from HDMI drivers to their CEC and audio counterparts.
> >
> > Based on an earlier version from Russell King:
> >
> > https://patchwork.kernel.org/patch/9277043/
> >
> > The hdmi_notifier is a reference counted object containing the HDMI state
> > of an HDMI device.
> >
> > When a new notifier is registered the current state will be reported to
> > that notifier at registration time.
> >
> > Based on Hans Verkuil's patch:
> >
> > https://patchwork.kernel.org/patch/9472521/
>
> Erm, you are aware that this patch morphed into a CEC-specific notifier
> found in drivers/media/cec/cec-notifier.c?
>
> I don't think it makes sense to have two notifier implementations in the 
> kernel.
> The original intention was to have the notifier deal with both CEC and ASoC
> notifications, but there was not enough interest for the ASoC bits at the time
> and it was dropped.
>
> I am planning changes to the cec-notifier API, I hope to work on that this
> week. I'll CC you when I post those. Those might be a good starting point
> to convert the cec-notifier to an hdmi-notifier as was originally intended.
>
> I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> working on some nice cec-notifier improvements as well.

Hi Hans, thank you for quick reply.
I am not aware of the history of cec-notifier and hdmi-notifier.
The reason I took this patch is because its different versions were
used extensively in rockchip tree and chromium tree for years.
And hdmi-notifier patch posted at
https://patchwork.kernel.org/patch/9472521/ did not get objection at
that time.
If you think jack reporting should be supported on cec-notifier
instead, I can look into it after you post the new changes on
cec-notifier.
Thanks!

>
> Regards,
>
> Hans
>
> >
> > Modified by Cheng-Yi Chiang:
> >  - Add a section in MAINTAINER.
> >  - Changes connected and has_eld to bitfield of unsigned int.
> >  - Other minor fixes to pass checkpatch.pl --strict checks.
> >
> > Signed-off-by: Hans Verkuil 
> > Acked-by: Philipp Zabel 
> > Signed-off-by: Cheng-Yi Chiang 
> > ---
> > The original patch is at
> > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverk...@xs4all.nl
> >
> >  MAINTAINERS   |   6 ++
> >  drivers/video/Kconfig |   3 +
> >  drivers/video/Makefile|   1 +
> >  drivers/video/hdmi-notifier.c | 145 ++
> >  include/linux/hdmi-notifier.h | 112 ++
> >  5 files changed, 267 insertions(+)
> >  create mode 100644 drivers/video/hdmi-notifier.c
> >  create mode 100644 include/linux/hdmi-notifier.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5cfbea4ce575..ffb7376f9509 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16676,6 +16676,12 @@ W:   https://linuxtv.org
> >  S:   Maintained
> >  F:   drivers/media/platform/vicodec/*
> >
> > +VIDEO FRAMEWORK
> > +M:   Hans Verkuil 
> > +L:   linux-me...@vger.kernel.org
> > +F:   drivers/video/hdmi-notifier.*
> > +S:   Maintained
> > +
> >  VIDEO MULTIPLEXER DRIVER
> >  M:   Philipp Zabel 
> >  L:   linux-me...@vger.kernel.org
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 83d3d271ca15..000ba9bc0ae7 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> >  config HDMI
> >   bool
> >
> > +config HDMI_NOTIFIERS
> > + bool
> > +
> >  endif # HAS_IOMEM
> >
> >  if VT
> > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > index df7650adede9..eff4736102ca 100644
> > --- a/drivers/video/Makefile
> > +++ b/drivers/video/Makefile
> > @@ -1,6 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_VGASTATE)+= vgastate.o
> >  obj-$(CONFIG_HDMI)+= hdmi.o
> > +obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o
> >
> >  obj-$(CONFIG_VT)   += console/
> >  obj-$(CONFIG_FB_STI)   += console/
> > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > new file mode 100644
> > index ..d1eedf661648
> > --- /dev/null
> > +++ b/drivers/video/hdmi-notifier.c
> > @@ -0,0 +1,145 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > + * events
> > + *
> > + * Copyright 2016 Russell King 
> > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > + * All rights reserved.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static LIST_HEAD(hdmi_notifiers);
> > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > +
> > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > +{
> > + struct hdmi_notifier *n;
> > +
> > + 

Re: [PATCH v2 0/4] fix mediatek drm, dis, and disp-* unbind/bind

2019-06-03 Thread CK Hu
Hi, Hsin-Yi:

On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> There are some errors when unbinding and rebinding mediatek drm, dsi,
> and disp-* drivers. This series is to fix those errors and warnings.
> 
> Hsin-Yi Wang (4):
>   drm: mediatek: fix unbind functions
>   drm: mediatek: unbind components in mtk_drm_unbind()
>   drm: mediatek: call drm_atomic_helper_shutdown() when unbinding driver
>   drm: mediatek: clear num_pipes when unbind driver

For this series with some title modification, applied to
mediatek-drm-fixes-5.2 [1], thanks.

[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.2

Regards,
CK

> 
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++-
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 


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

[Bug 110422] AMD_DEBUG=forcedma will crash OpenGL aps with SIGFAULT on VegaM 8706G

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110422

--- Comment #2 from Dieter Nützel  ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #1)
> Should be fixed on master by
> https://gitlab.freedesktop.org/mesa/mesa/commit/
> 4583f09caa5aef719a1eec282f24a86c789cbba6.
> 
> Can you test and confirm?

Hello Pierre-Eric,

I can confirm with Polaris 20 (RX580) running Unigine_Heaven-4.0 with

SOURCE/Unigine_Heaven-4.0> echo $AMD_DEBUG 
sisched,nir,forcedma
SOURCE/Unigine_Heaven-4.0> echo $R600_DEBUG 
sisched,nir,forcedma

sigfaulted for me before, too.
Could be closed after Dimitar confirmed, too.

BTW Are you one of the 'new' AMD OSS guys?

-- 
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: [v4 6/7] drm/mediatek: change the dsi phytiming calculate method

2019-06-03 Thread Nicolas Boichat
On Sat, Jun 1, 2019 at 5:26 PM Jitao Shi  wrote:
>
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> else
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
>
> Note:
> //(2: 1 for sync, 1 for phy idle)
> data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
>
> bpp: bit per pixel
>
> Signed-off-by: Jitao Shi 
> Tested-by: Ryan Case 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 122 -
>  1 file changed, 83 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index abf6ddec5db6..558727c60ba3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -144,12 +144,6 @@
>  #define DATA_0 (0xff << 16)
>  #define DATA_1 (0xff << 24)
>
> -#define T_LPX  5
> -#define T_HS_PREP  6
> -#define T_HS_TRAIL 8
> -#define T_HS_EXIT  7
> -#define T_HS_ZERO  10
> -
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>
>  #define MTK_DSI_HOST_IS_READ(type) \
> @@ -158,6 +152,25 @@
> (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> (type == MIPI_DSI_DCS_READ))
>
> +struct mtk_phy_timing {
> +   u32 lpx;
> +   u32 da_hs_prepare;
> +   u32 da_hs_zero;
> +   u32 da_hs_trail;
> +
> +   u32 ta_go;
> +   u32 ta_sure;
> +   u32 ta_get;
> +   u32 da_hs_exit;
> +
> +   u32 clk_hs_zero;
> +   u32 clk_hs_trail;
> +
> +   u32 clk_hs_prepare;
> +   u32 clk_hs_post;
> +   u32 clk_hs_exit;
> +};
> +
>  struct phy;
>
>  struct mtk_dsi_driver_data {
> @@ -182,12 +195,13 @@ struct mtk_dsi {
> struct clk *digital_clk;
> struct clk *hs_clk;
>
> -   u32 data_rate;
> +   u64 data_rate;

As highlighted in
https://patchwork.kernel.org/patch/10949323/#22673829, this change
causes issues on 32-bit platforms.

>
> unsigned long mode_flags;
> enum mipi_dsi_pixel_format format;
> unsigned int lanes;
> struct videomode vm;
> +   struct mtk_phy_timing phy_timing;
> int refcount;
> bool enabled;
> u32 irq_data;
> @@ -221,17 +235,36 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
> u32 timcon0, timcon1, timcon2, timcon3;
> u32 ui, cycle_time;
> +   struct mtk_phy_timing *timing = >phy_timing;
> +
> +   ui = 10 / dsi->data_rate;
> +   cycle_time = 80 / dsi->data_rate;
> +
> +   timing->lpx = NS_TO_CYCLE(60, cycle_time);
> +   timing->da_hs_prepare = NS_TO_CYCLE(40 + 5 * ui, cycle_time);
> +   timing->da_hs_zero = NS_TO_CYCLE(110 + 6 * ui, cycle_time);
> +   timing->da_hs_trail = NS_TO_CYCLE(80 + 4 * ui, cycle_time);
>
> -   ui = 1000 / dsi->data_rate + 0x01;
> -   cycle_time = 8000 / dsi->data_rate + 0x01;
> +   timing->ta_go = 4 * timing->lpx;
> +   timing->ta_sure = 3 * timing->lpx / 2;
> +   timing->ta_get = 5 * timing->lpx;
> +   timing->da_hs_exit = 2 * timing->lpx;
>
> -   timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> -   timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> - T_HS_EXIT << 24;
> -   timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> -   timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> - NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> +   timing->clk_hs_zero = NS_TO_CYCLE(336, cycle_time);
> +   timing->clk_hs_trail = NS_TO_CYCLE(100, cycle_time) + 10;
> +
> +   timing->clk_hs_prepare = NS_TO_CYCLE(64, cycle_time);
> +   timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> +   timing->clk_hs_exit = 2 * timing->lpx;
> +
> +   timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> + timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> +   timcon1 = timing->ta_go | timing->ta_sure << 8 |
> + timing->ta_get << 16 | timing->da_hs_exit << 24;
> +   timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> + timing->clk_hs_trail << 24;
> +   timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> + timing->clk_hs_exit << 16;
>
> writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -418,7 +451,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> -   u32 dsi_tmp_buf_bpp;
> +   u32 dsi_tmp_buf_bpp, data_phy_cycles;
> +   struct 

[Bug 110822] booting with kernel version 5.1.0 or higher on RX 580 hangs

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110822

--- Comment #2 from Matt Coffin  ---
I'm experiencing the same problem, but with an XFX RX 590 FATBOY.

Strangely enough, I am also running crappy, kinda slow DDR3 RAM at 1600 mhz.

I've read so much on this issue today that I don't know where I read it, but I
read somewhere that crappy RAM can cause these kinds of hangs with these cards.

Is there some issue with running the GPU mclk faster than your system's RAM?

My issue does not happen on boot, and does not happen until the GPU is under
load, but occasionally (seemingly non-deterministically), I see the powerplay
errors on startup, but amdgpu continues to load (seemingly OK) until I put it
under heavy load.

Do you have a mobo/cpu/ram setup with faster memory that you might be able to
test with? I don't know too much about amdgpu internals but given what I read
it seems odd that we are both running what would be considered "slow" RAM these
days.

My specs:

* Kernel 5.1.3-arch2-1-ARCH
* LLVM 8.0.0
* Mesa 19.0.4
* Card XFX Radeon RX 590 OC+ FATBOY
* CPU: i7 990x extreme edition

Interestingly, I had to set up fancontrol to get the fans to spin up past their
minimum values at all, but I suspect that could be due to the usage of the
"stealth" RX 590 VBIOS. Unfortunately, i don't have access to a windows machine
to flash to "performance" bios on to my card, or even to check which version is
in use currently.

Let me know if I can help out with any logs/debugging information.

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

[RESEND PATCH v2] drm/vmwgfx: fix a warning due to missing dma_parms

2019-06-03 Thread Qian Cai
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().

DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
 vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
 vmw_bo_map_dma+0x25/0x30 [vmwgfx]
 vmw_otables_setup+0x2a8/0x750 [vmwgfx]
 vmw_request_device_late+0x78/0xc0 [vmwgfx]
 vmw_request_device+0xee/0x4e0 [vmwgfx]
 vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
 drm_dev_register+0x1ff/0x340 [drm]
 drm_get_pci_dev+0x110/0x290 [drm]
 vmw_probe+0x15/0x20 [vmwgfx]
 local_pci_probe+0x7a/0xc0
 pci_device_probe+0x1b9/0x290
 really_probe+0x1b5/0x630
 driver_probe_device+0xa3/0x1a0
 device_driver_attach+0x94/0xa0
 __driver_attach+0xdd/0x1c0
 bus_for_each_dev+0xfe/0x150
 driver_attach+0x2d/0x40
 bus_add_driver+0x290/0x350
 driver_register+0xdc/0x1d0
 __pci_register_driver+0xda/0xf0
 vmwgfx_init+0x34/0x1000 [vmwgfx]
 do_one_initcall+0xe5/0x40a
 do_init_module+0x10f/0x3a0
 load_module+0x16a5/0x1a40
 __se_sys_finit_module+0x183/0x1c0
 __x64_sys_finit_module+0x43/0x50
 do_syscall_64+0xc8/0x606
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Suggested-by: Thomas Hellstrom 
Signed-off-by: Qian Cai 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4ff11a0077e1..5f690429eb89 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -747,6 +747,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
if (unlikely(ret != 0))
goto out_err0;
 
+   dma_set_max_seg_size(dev->dev, U32_MAX);
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
 (unsigned)dev_priv->max_gmr_ids);
-- 
1.8.3.1



Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Add hook for resume

2019-06-03 Thread Doug Anderson
Laurent,

On Thu, May 16, 2019 at 2:40 PM Douglas Anderson  wrote:
>
> On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> cycle:
>
> 1. You lose the ability to detect an HDMI device being plugged in.
>
> 2. If you're using the i2c bus built in to dw_hdmi then it stops
> working.
>
> Let's add a hook to the core dw-hdmi driver so that we can call it in
> dw_hdmi-rockchip in the next commit.
>
> NOTE: the exact set of steps I've done here in resume come from
> looking at the normal dw_hdmi init sequence in upstream Linux plus the
> sequence that we did in downstream Chrome OS 3.14.  Testing show that
> it seems to work, but if an extra step is needed or something here is
> not needed we could improve it.
>
> As part of this change we'll refactor the hardware init bits of
> dw-hdmi to happen all in one function and all at the same time.  Since
> we need to init the interrupt mutes before we request the IRQ, this
> means moving the hardware init earlier in the function, but there
> should be no problems with that.  Also as part of this we now
> unconditionally init the "i2c" parts of dw-hdmi, but again that ought
> to be fine.
>
> Signed-off-by: Douglas Anderson 
> ---
>
> Changes in v2:
> - No empty stub for suspend (Laurent)
> - Refactor to use the same code in probe and resume (Laurent)
> - Unconditionally init i2c (seems OK + needed before hdmi->i2c init)
> - Combine "init" of i2c and "setup" of i2c (no reason to split)

Are you happy with this now?  Even if you feel like you don't want to
give it a full Reviewed-by, it'd good if you could confirm that I
handled your suggestions properly.

Thanks!  :-)

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

Re: [PATCH libdrm 00/10] Add C8, 30bpp and FP16 support to modetest

2019-06-03 Thread Ilia Mirkin
On Sun, Jun 2, 2019 at 8:40 PM Ilia Mirkin  wrote:
>
> This series improves the pattern generation logic to support additional
> formats, as well as a new "gradient" pattern (see patch comments on why
> I found it useful).
>
> Furthermore, these formats are piped through to modetest, including the
> ability to set a gamma table, which is necessary for the C8 indexed
> format.
>
> This was tested on nouveau, and used for bring-up of the C8, XB30, and
> FP16 formats on the NVIDIA hardware that supports these.

Just to follow up, I've successfully tested on an Intel SKL with C8
and XB30/XR30 as well (and confirmed that the GAMMA_LUT gets unset in
a sequence of C8 followed by XB30). FP16 was not available on the
kernel I am currently using (and perhaps not the HW?)

  -ilia

>
> Ilia Mirkin (10):
>   util: add C8 format, support it with SMPTE pattern
>   util: fix MAKE_RGBA macro for 10bpp modes
>   util: add gradient pattern
>   util: add fp16 format support
>   util: add cairo drawing for 30bpp formats when available
>   modetest: don't pretend that atomic mode includes a format
>   modetest: add an add_property_optional variant that does not print
> errors
>   modetest: add C8 support to generate SMPTE pattern
>   modetest: add the ability to specify fill patterns on the commandline
>   modetest: add FP16 format support
>
>  tests/modetest/buffers.c  |  13 ++
>  tests/modetest/modetest.c | 109 --
>  tests/util/format.c   |   7 +
>  tests/util/pattern.c  | 432 +-
>  tests/util/pattern.h  |   7 +
>  5 files changed, 543 insertions(+), 25 deletions(-)
>
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #19 from Richard Thier  ---
Hmmm... I have tried the possible fix and Extreme Tux Racer became fast again
however I still see a lot of "DRM_IOCTL_RADEON_GEM_CREATE" if I do an

strace -T -e ioctl glxgears 2>&1 | vim -

So things are fast now, but I still see these logged out. Is this normal in any
ways? I am happy with the performance of course just I don't understand this. 

Maybe I made some mistake...

-- 
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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #18 from Richard Thier  ---
Will try that supposed patch as soon as possible. It seems reasonable to me as
far as I understand it. So you basically set the flag for r300. I was searching
a lot to see where to add these, but I was too noob for telling where I am
supposed to put these in to only affect/fix my old card range...

Sorry for answering only now. I was in wine garden ;-)

-- 
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 v4 2/5] drm/amd: fix fb references in async update

2019-06-03 Thread Helen Koike


On 6/3/19 1:56 PM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
> 
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken care by
> drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
> 
> Suggested-by: Boris Brezillon 
> Signed-off-by: Helen Koike 
> Reviewed-by: Nicholas Kazlauskas 

Cc:  # v4.20+
Fixes: 674e78acae0d ("drm/amd/display: Add fast path for cursor plane
updates")


> 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - added reviewed-by tag
> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 443b13ec268d..40624b2c630e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4347,8 +4347,7 @@ static void dm_plane_atomic_async_update(struct 
> drm_plane *plane,
>   struct drm_plane_state *old_state =
>   drm_atomic_get_old_plane_state(new_state->state, plane);
>  
> - if (plane->state->fb != new_state->fb)
> - drm_atomic_set_fb_for_plane(plane->state, new_state->fb);
> + swap(plane->state->fb, new_state->fb);
>  
>   plane->state->src_x = new_state->src_x;
>   plane->state->src_y = new_state->src_y;
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/5] drm/rockchip: fix fb references in async update

2019-06-03 Thread Helen Koike


On 6/3/19 1:56 PM, Helen Koike wrote:
> In the case of async update, modifications are done in place, i.e. in the
> current plane state, so the new_state is prepared and the new_state is
> cleaned up (instead of the old_state, unlike what happens in a
> normal sync update).
> To cleanup the old_fb properly, it needs to be placed in the new_state
> in the end of async_update, so cleanup call will unreference the old_fb
> correctly.
> 
> Also, the previous code had a:
> 
>   plane_state = plane->funcs->atomic_duplicate_state(plane);
>   ...
>   swap(plane_state, plane->state);
> 
>   if (plane->state->fb && plane->state->fb != new_state->fb) {
>   ...
>   }
> 
> Which was wrong, as the fb were just assigned to be equal, so this if
> statement nevers evaluates to true.
> 
> Another details is that the function drm_crtc_vblank_get() can only be
> called when vop->is_enabled is true, otherwise it has no effect and
> trows a WARN_ON().
> 
> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> fb and pus the old fb) is not required, as it is taken care by
> drm_mode_cursor_universal() when calling
> drm_atomic_helper_update_plane().
> 
> Signed-off-by: Helen Koike 

Cc:  # v4.20+
Fixes: 15609559a834 ("drm/rockchip: update cursors asynchronously
through atomic.")

> 
> ---
> Hello,
> 
> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> kms_cursor_legacy and I didn't see any regressions.
> 
> Changes in v4: None
> Changes in v3:
> - use swap() to swap old and new framebuffers in async_update
> - get the reference to old_fb and set the worker after 
> vop_plane_atomic_update()
> - add a FIXME tag for when we have multiple fbs to be released when
> vblank happens.
> - update commit message
> 
> Changes in v2: None
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 +++--
>  1 file changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 4189ca17f381..b7c47d1153c6 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -919,29 +919,17 @@ static void vop_plane_atomic_async_update(struct 
> drm_plane *plane,
> struct drm_plane_state *new_state)
>  {
>   struct vop *vop = to_vop(plane->state->crtc);
> - struct drm_plane_state *plane_state;
> -
> - plane_state = plane->funcs->atomic_duplicate_state(plane);
> - plane_state->crtc_x = new_state->crtc_x;
> - plane_state->crtc_y = new_state->crtc_y;
> - plane_state->crtc_h = new_state->crtc_h;
> - plane_state->crtc_w = new_state->crtc_w;
> - plane_state->src_x = new_state->src_x;
> - plane_state->src_y = new_state->src_y;
> - plane_state->src_h = new_state->src_h;
> - plane_state->src_w = new_state->src_w;
> -
> - if (plane_state->fb != new_state->fb)
> - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> -
> - swap(plane_state, plane->state);
> -
> - if (plane->state->fb && plane->state->fb != new_state->fb) {
> - drm_framebuffer_get(plane->state->fb);
> - WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
> - drm_flip_work_queue(>fb_unref_work, plane->state->fb);
> - set_bit(VOP_PENDING_FB_UNREF, >pending);
> - }
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + plane->state->crtc_h = new_state->crtc_h;
> + plane->state->crtc_w = new_state->crtc_w;
> + plane->state->src_x = new_state->src_x;
> + plane->state->src_y = new_state->src_y;
> + plane->state->src_h = new_state->src_h;
> + plane->state->src_w = new_state->src_w;
> + swap(plane->state->fb, new_state->fb);
>  
>   if (vop->is_enabled) {
>   rockchip_drm_psr_inhibit_get_state(new_state->state);
> @@ -950,9 +938,22 @@ static void vop_plane_atomic_async_update(struct 
> drm_plane *plane,
>   vop_cfg_done(vop);
>   spin_unlock(>reg_lock);
>   rockchip_drm_psr_inhibit_put_state(new_state->state);
> - }
>  
> - plane->funcs->atomic_destroy_state(plane, plane_state);
> + /*
> +  * A scanout can still be occurring, so we can't drop the
> +  * reference to the old framebuffer. To solve this we get a
> +  * reference to old_fb and set a worker to release it later.
> +  * FIXME: if we perform 500 async_update calls before the
> +  * vblank, then we can have 500 different framebuffers waiting
> +  * to be released.
> +  */
> + if (old_fb && plane->state->fb != old_fb) {
> + drm_framebuffer_get(old_fb);
> + WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
> +

[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109955

--- Comment #26 from Matt Coffin  ---
For reproducability, here's what I've been using. (I can reproduce this crash
on both the RADV and AMDVLK Vulkan implementations, and can reproduce it both
on top of sway 1.1 (wayland), and xfce4 (X11)).

* 5.1.3-arch2-1-ARCH
* LLVM 8.0.0
* mesa/vulkan-radeon: 19.0.4
* AMDVLK: (dev branch from nighttime Mountain time 20190602)
* DXVK: winelib version - release 1.2.1

I run "House Flipper" from Steam with DXVK_FILTER_DEVICE_NAME=590.

On 1080p@60Hz with v-sync, it runs quite well and stable (for hours). If I
disable v-sync and framerate limiting, the crash occurs within a minute
usually.

At 2560x1440 resolution, no refresh rate works in a stable mannner, but I have
tried both 60Hz and 144Hz.

With the game rendering 1080p but scaling up to a 2560x1440 display, I saw it
crash once, but was unable to duplicate it again.

I'm new to low-level development, and would like to help. If I can provide any
information since I can reliably reproduce the issue, I'd love to. Let me know
what would be useful and I'd be happy to get it out to you.

I've also seen the bugs listed in my other comment on the other bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=102322#c82

-- 
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 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=102322

--- Comment #82 from Matt Coffin  ---
I am also experiencing this issue.

* Kernel: 5.1.3-arch2-1-ARCH
* LLVM 8.0.0
* AMDVLK (dev branch pulled 20190602)
* Mesa 19.0.4
* Card: XFX Radeon RX 590

I've seen this error, bug 105733, bug 105152, bug 107536, and bug 109955 all
repeatable (which one each time appears to be non-deterministic) with the same
process.

I just launch "House Flipper" from Steam (DX11 title), with DXVK 1.2.1, on
either the mesa RADV or AMDVLK vulkan implementations.

At 2560x1440 resolution (both 60Hz and 144Hz refresh rates), the crash(es)
occur. At 1080p@60Hz, I get no crashes, but they come back if I disable v-sync
and framerate limiting.

I logged power consumption with `sensors | egrep '^power' | awk '{ print $1 " "
$2; }'`, and found that the crash often occurs soon after the card hits its
maximum power draw at around 190W.

I don't have much experience debugging or developing software at the
kernel/driver level, but I'm happy to help with providing information as I go
through the learning process here. I'll compile the amd-staging-drm-next kernel
later tonight and post some results and logs.

Please let me know if there's more information I could provide that may be of
use here. Thanks for your hard work!

-- 
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/panfrost: make devfreq optional again

2019-06-03 Thread Ezequiel Garcia
On Fri, 2019-05-31 at 14:37 +0200, Neil Armstrong wrote:
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missin the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ is selected by default.
> 
> Fixes: f3617b449d ("drm/panfrost: Select devfreq")
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c 
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 29fcffdf2d57..dc75f99ad53b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -140,7 +140,9 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
>   return 0;
>  
>   ret = dev_pm_opp_of_add_table(>pdev->dev);
> - if (ret)
> + if (ret == -ENODEV) /* Optional, continue without devfreq */
> + return 0;
> + else
>   return ret;
>  

This looks incorrect, should be:

   else if (ret)
return ret;

Otherwise, if ret == 0, we are bailing out.

Thanks,
Eze

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

[Bug 107536] gfx_v8_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107536

--- Comment #6 from Matt Coffin  ---
I also tried to reproduce with amdgpu.vm_update_mode=3, but I can't get Xorg to
launch with that setting (KERNEL (not gpu) fails on a page request with that
setting on, but that might be due to a lower amt of RAM, and the fact that I'm
running an RX 590 w/ 8GB of GDDR5, so it might just be trying to allocate too
much memory?).

The failures do NOT occur if I disable dynamic power management with
amdgpu.dpm=0, but obviously, performance sucks with those low clock speeds.
Game gets about 14fps.

Manual power management fared no better, but some quick debugging showed that
it might be getting overridden by DXVK's DXGI implementation.

I also logged `sensors` output, which showed that the failures often occur
quickly after the card reaches its maximum power draw at a little over 190W. I
thought about increasing that, but I didn't want to fry my hardware since I
don't have much experience mucking around with overclocking/overvolting GPUs.

-- 
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 107536] gfx_v8_0_priv_reg_irq [amdgpu]] *ERROR* Illegal register access in command stream

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107536

--- Comment #5 from Matt Coffin  ---
I can reproduce this in a very very specific way (discovered while reproducing
bug 102322).

With the amdgpu driver, and RADV vulkan implementation, with DXVK 1.2.1,
running "House Flipper" from Steam (wine-staging 4.8), on 2560x1440 144Hz
display (DisplayPort). It crashes with the AMDVLK implementation as well, but
with a different message.

Usually happens withing 2 minutes of firing up the game. It's notable that this
*does not* occur if I render the game in 1080p and blow it up for the screen.

* 5.1.3-arch2-1-ARCH
* LLVM 8.0.0
* vulkan-radeon/mesa 19.0.4

The register that it is not liking the access to flips between TC1 and TC2
seemingly nondeterministically.

I'm sorry for the poor information, but I'm not used to developing/debugging
software at the kernel level. Let me know what information I can provide to be
helpful, and I'd be happy to fish it out for you. Thanks in advance for your
work and the help.

-- 
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 2/7] drm/dp_mst: Register AUX devices for MST ports

2019-06-03 Thread Lyude Paul
On Mon, 2019-06-03 at 15:25 -0400, Lyude Paul wrote:
> On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote:
> > Hey, sorry for my late response!
> > 
> > On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> > 
> > > >if (old_pdt != port->pdt && !port->input) {
> > > > @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct
> > > > drm_dp_mst_branch
> > > > *mstb,
> > > >drm_connector_set_tile_property(port-
> > > > >connector);
> > > >}
> > > >(*mstb->mgr->cbs->register_connector)(port->connector);
> > > This is wrong: we always want to setup everything in the connector first
> > > before trying to register it, not after. Otherwise, things explode like
> > > so:
> > 
> > **snip**
> > 
> > > [  452.424461] [ cut here ]
> > > [  452.424464] sysfs group 'power' not found for kobject 'drm_dp_aux5'
> > > [  452.424471] WARNING: CPU: 3 PID: 1887 at fs/sysfs/group.c:256
> > > sysfs_remove_group+0x76/0x80
> > > [  452.424473] Modules linked in: vfat fat elan_i2c i915(O) intel_rapl
> > > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm
> > > mei_wdt irqbypass iTCO_vendor_support crct10dif_pclmul wmi_bmof
> > > intel_wmi_thunderbolt crc32_pclmul i2c_algo_bit ghash_clmulni_intel
> > > intel_cstate drm_kms_helper(O) intel_uncore intel_rapl_perf btusb btrtl
> > > btbcm syscopyarea btintel sysfillrect sysimgblt fb_sys_fops bluetooth
> > > drm(O) joydev mei_me idma64 ucsi_acpi thunderbolt ecdh_generic i2c_i801
> > > intel_xhci_usb_role_switch processor_thermal_device typec_ucsi
> > > intel_lpss_pci intel_soc_dts_iosf mei roles intel_lpss typec
> > > intel_pch_thermal wmi thinkpad_acpi ledtrig_audio rfkill int3403_thermal
> > > int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad video
> > > pcc_cpufreq crc32c_intel nvme serio_raw uas e1000e nvme_core usb_storage
> > > i2c_dev
> > > [  452.424492] CPU: 3 PID: 1887 Comm: unloadgpumod Tainted:
> > > G   O  5.1.0Lyude-Test+ #1
> > > [  452.424494] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS
> > > N22ET35W
> > > (1.12 ) 04/09/2018
> > > [  452.424496] RIP: 0010:sysfs_remove_group+0x76/0x80
> > > [  452.424498] Code: 48 89 df 5b 5d 41 5c e9 f8 bc ff ff 48 89 df e8 d0
> > > bc
> > > ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 08 a5 0c aa e8 44 00 d6 ff
> > > <0f> 0b 5b 5d 41 5c c3 0f 1f 00 0f 1f 44 00 00 48 85 f6 74 31 41 54
> > > [  452.424500] RSP: 0018:a8bb81b5fb28 EFLAGS: 00010282
> > > [  452.424501] RAX:  RBX:  RCX:
> > > 0006
> > > [  452.424502] RDX: 0007 RSI: 0086 RDI:
> > > 981fde2d5a00
> > > [  452.424503] RBP: a9ea12e0 R08: 0792 R09:
> > > 0046
> > > [  452.424504] R10: 0727 R11: a8bb81b5f9d0 R12:
> > > 981fd5f77010
> > > [  452.424505] R13: 981fd6ebbedc R14: dead0200 R15:
> > > dead0100
> > > [  452.424507] FS:  7f8cc1d8c740() GS:981fde2c()
> > > knlGS:
> > > [  452.424508] CS:  0010 DS:  ES:  CR0: 80050033
> > > [  452.424509] CR2: 55b19d079a08 CR3: 00043b2a0002 CR4:
> > > 003606e0
> > > [  452.424510] DR0:  DR1:  DR2:
> > > 
> > > [  452.424511] DR3:  DR6: fffe0ff0 DR7:
> > > 0400
> > > [  452.424512] Call Trace:
> > > [  452.424516]  device_del+0x75/0x360
> > > [  452.424518]  ? class_find_device+0x96/0xf0
> > > [  452.424520]  device_unregister+0x16/0x60
> > > [  452.424521]  device_destroy+0x3a/0x40
> > > [  452.424525]  drm_dp_aux_unregister_devnode+0xea/0x180
> > > [drm_kms_helper]
> > > [  452.424534]  ? drm_dbg+0x87/0x90 [drm]
> > > [  452.424538]  drm_dp_mst_topology_put_port+0x5b/0x110 [drm_kms_helper]
> > > [  452.424543]  drm_dp_mst_topology_put_mstb+0xb6/0x180 [drm_kms_helper]
> > > [  452.424547]  drm_dp_mst_topology_mgr_set_mst+0x233/0x2b0
> > > [drm_kms_helper]
> > > [  452.424551]  drm_dp_mst_topology_mgr_destroy+0x18/0xa0
> > > [drm_kms_helper]
> > > [  452.424571]  intel_dp_encoder_flush_work+0x32/0xb0 [i915]
> > > [  452.424592]  intel_ddi_encoder_destroy+0x32/0x70 [i915]
> > > [  452.424600]  drm_mode_config_cleanup+0x51/0x2e0 [drm]
> > > [  452.424621]  intel_modeset_cleanup+0xc8/0x140 [i915]
> > > [  452.424633]  i915_driver_unload+0xa8/0x130 [i915]
> > > [  452.424645]  i915_pci_remove+0x1e/0x40 [i915]
> > > [  452.424647]  pci_device_remove+0x3b/0xc0
> > > [  452.424649]  device_release_driver_internal+0xe4/0x1d0
> > > [  452.424651]  pci_stop_bus_device+0x69/0x90
> > > [  452.424653]  pci_stop_and_remove_bus_device_locked+0x16/0x30
> > > [  452.424655]  remove_store+0x75/0x90
> > > [  452.424656]  kernfs_fop_write+0x116/0x190
> > > [  452.424658]  vfs_write+0xa5/0x1a0
> > > [  452.424660]  ksys_write+0x57/0xd0
> > > [  452.424663]  do_syscall_64+0x55/0x150
> > > [  452.424665]  

Re: [PATCH 2/7] drm/dp_mst: Register AUX devices for MST ports

2019-06-03 Thread Lyude Paul
On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote:
> Hey, sorry for my late response!
> 
> On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> 
> > >if (old_pdt != port->pdt && !port->input) {
> > > @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct
> > > drm_dp_mst_branch
> > > *mstb,
> > >drm_connector_set_tile_property(port->connector);
> > >}
> > >(*mstb->mgr->cbs->register_connector)(port->connector);
> > This is wrong: we always want to setup everything in the connector first
> > before trying to register it, not after. Otherwise, things explode like
> > so:
> 
> **snip**
> 
> > [  452.424461] [ cut here ]
> > [  452.424464] sysfs group 'power' not found for kobject 'drm_dp_aux5'
> > [  452.424471] WARNING: CPU: 3 PID: 1887 at fs/sysfs/group.c:256
> > sysfs_remove_group+0x76/0x80
> > [  452.424473] Modules linked in: vfat fat elan_i2c i915(O) intel_rapl
> > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm
> > mei_wdt irqbypass iTCO_vendor_support crct10dif_pclmul wmi_bmof
> > intel_wmi_thunderbolt crc32_pclmul i2c_algo_bit ghash_clmulni_intel
> > intel_cstate drm_kms_helper(O) intel_uncore intel_rapl_perf btusb btrtl
> > btbcm syscopyarea btintel sysfillrect sysimgblt fb_sys_fops bluetooth
> > drm(O) joydev mei_me idma64 ucsi_acpi thunderbolt ecdh_generic i2c_i801
> > intel_xhci_usb_role_switch processor_thermal_device typec_ucsi
> > intel_lpss_pci intel_soc_dts_iosf mei roles intel_lpss typec
> > intel_pch_thermal wmi thinkpad_acpi ledtrig_audio rfkill int3403_thermal
> > int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad video
> > pcc_cpufreq crc32c_intel nvme serio_raw uas e1000e nvme_core usb_storage
> > i2c_dev
> > [  452.424492] CPU: 3 PID: 1887 Comm: unloadgpumod Tainted:
> > G   O  5.1.0Lyude-Test+ #1
> > [  452.424494] Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W
> > (1.12 ) 04/09/2018
> > [  452.424496] RIP: 0010:sysfs_remove_group+0x76/0x80
> > [  452.424498] Code: 48 89 df 5b 5d 41 5c e9 f8 bc ff ff 48 89 df e8 d0 bc
> > ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 08 a5 0c aa e8 44 00 d6 ff
> > <0f> 0b 5b 5d 41 5c c3 0f 1f 00 0f 1f 44 00 00 48 85 f6 74 31 41 54
> > [  452.424500] RSP: 0018:a8bb81b5fb28 EFLAGS: 00010282
> > [  452.424501] RAX:  RBX:  RCX:
> > 0006
> > [  452.424502] RDX: 0007 RSI: 0086 RDI:
> > 981fde2d5a00
> > [  452.424503] RBP: a9ea12e0 R08: 0792 R09:
> > 0046
> > [  452.424504] R10: 0727 R11: a8bb81b5f9d0 R12:
> > 981fd5f77010
> > [  452.424505] R13: 981fd6ebbedc R14: dead0200 R15:
> > dead0100
> > [  452.424507] FS:  7f8cc1d8c740() GS:981fde2c()
> > knlGS:
> > [  452.424508] CS:  0010 DS:  ES:  CR0: 80050033
> > [  452.424509] CR2: 55b19d079a08 CR3: 00043b2a0002 CR4:
> > 003606e0
> > [  452.424510] DR0:  DR1:  DR2:
> > 
> > [  452.424511] DR3:  DR6: fffe0ff0 DR7:
> > 0400
> > [  452.424512] Call Trace:
> > [  452.424516]  device_del+0x75/0x360
> > [  452.424518]  ? class_find_device+0x96/0xf0
> > [  452.424520]  device_unregister+0x16/0x60
> > [  452.424521]  device_destroy+0x3a/0x40
> > [  452.424525]  drm_dp_aux_unregister_devnode+0xea/0x180 [drm_kms_helper]
> > [  452.424534]  ? drm_dbg+0x87/0x90 [drm]
> > [  452.424538]  drm_dp_mst_topology_put_port+0x5b/0x110 [drm_kms_helper]
> > [  452.424543]  drm_dp_mst_topology_put_mstb+0xb6/0x180 [drm_kms_helper]
> > [  452.424547]  drm_dp_mst_topology_mgr_set_mst+0x233/0x2b0
> > [drm_kms_helper]
> > [  452.424551]  drm_dp_mst_topology_mgr_destroy+0x18/0xa0 [drm_kms_helper]
> > [  452.424571]  intel_dp_encoder_flush_work+0x32/0xb0 [i915]
> > [  452.424592]  intel_ddi_encoder_destroy+0x32/0x70 [i915]
> > [  452.424600]  drm_mode_config_cleanup+0x51/0x2e0 [drm]
> > [  452.424621]  intel_modeset_cleanup+0xc8/0x140 [i915]
> > [  452.424633]  i915_driver_unload+0xa8/0x130 [i915]
> > [  452.424645]  i915_pci_remove+0x1e/0x40 [i915]
> > [  452.424647]  pci_device_remove+0x3b/0xc0
> > [  452.424649]  device_release_driver_internal+0xe4/0x1d0
> > [  452.424651]  pci_stop_bus_device+0x69/0x90
> > [  452.424653]  pci_stop_and_remove_bus_device_locked+0x16/0x30
> > [  452.424655]  remove_store+0x75/0x90
> > [  452.424656]  kernfs_fop_write+0x116/0x190
> > [  452.424658]  vfs_write+0xa5/0x1a0
> > [  452.424660]  ksys_write+0x57/0xd0
> > [  452.424663]  do_syscall_64+0x55/0x150
> > [  452.424665]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [  452.424667] RIP: 0033:0x7f8cc1e7d038
> > [  452.424668] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00
> > f3 0f 1e fa 48 8d 05 e5 76 0d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05
> > <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 

[Bug 110777] Kernel 5.1-5.2 MCLK stuck at 167MHz Vega 10 (56)

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110777

--- Comment #4 from Anton Herzfeld  ---
Is there anything else I can provide to support getting this fixed?

-- 
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 110422] AMD_DEBUG=forcedma will crash OpenGL aps with SIGFAULT on VegaM 8706G

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110422

--- Comment #1 from Pierre-Eric Pelloux-Prayer 
 ---
Should be fixed on master by
https://gitlab.freedesktop.org/mesa/mesa/commit/4583f09caa5aef719a1eec282f24a86c789cbba6.

Can you test and confirm?

-- 
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 110777] Kernel 5.1-5.2 MCLK stuck at 167MHz Vega 10 (56)

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110777

--- Comment #3 from ant...@gmx.de ---
reverting the following two patches fixes the boost in memory clocks but it
seems once mem clock has ramped up it's not going down again.

1.
Revert "drm/amd/powerplay: update soc boot and max level on vega10"   
This reverts commit 373e87fc91527124cb8ec21465a6d070a65c56af.

2.
Revert "drm/amd/powerplay: support Vega10 SOCclk and DCEFclk dpm level
settings"
This reverts commit bb05821b13fa0c0b97760cb292b30d3105d65954.

Evan Quan 
Alex Deucher 

-- 
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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #17 from Marek Olšák  ---
Created attachment 144431
  --> https://bugs.freedesktop.org/attachment.cgi?id=144431=edit
possible fix

Hey fellas, can you test this patch? Thanks.

-- 
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 110777] Kernel 5.1-5.2 MCLK stuck at 167MHz Vega 10 (56)

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110777

--- Comment #2 from ant...@gmx.de ---
The issue is fully fixed on kernel master (currently I am using commit
460b48a0fefce25beb0fc0139e721c5691d65d7f) when reverting
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c back to the state it was
around kernel 5.0.13.

https://git.archlinux.org/linux.git/tree/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c?h=v5.0.13-arch1

I will start bisecting soon to figure out the exact commit that has caused the
issue.

-- 
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 110831] [AMD TAHITI XT][amd-staging-drm-next][bisected] broken since 5.2-rc1 rebase

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110831

Sylvain BERTRAND  changed:

   What|Removed |Added

Summary|[AMD TAHITI |[AMD TAHITI
   |XT][amd-staging-drm-next]   |XT][amd-staging-drm-next][b
   |broken since 5.2-rc1 rebase |isected] broken since
   ||5.2-rc1 rebase

-- 
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 110831] [AMD TAHITI XT][amd-staging-drm-next] broken since 5.2-rc1 rebase

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110831

--- Comment #3 from Sylvain BERTRAND  ---
Created attachment 144430
  --> https://bugs.freedesktop.org/attachment.cgi?id=144430=edit
xorg

-- 
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 110831] [AMD TAHITI XT][amd-staging-drm-next] broken since 5.2-rc1 rebase

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110831

--- Comment #2 from Sylvain BERTRAND  ---
Created attachment 144429
  --> https://bugs.freedesktop.org/attachment.cgi?id=144429=edit
dmesg

-- 
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 110831] [AMD TAHITI XT][amd-staging-drm-next] broken since 5.2-rc1 rebase

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110831

--- Comment #1 from Sylvain BERTRAND  ---
The guilty commit is following. I reverted this commit on top of the current
amd-staging-drm-next (40cc64619a2580b26f924bcabdefd555e7831a14), my system is
then booting ok. It seems to do some specific programming for vega10+ parts
which is not correct for previous families/versions parts.

commit 43ee614432d841184b158af27fda66a0929fe252 (refs/bisect/bad)
Author: Emily Deng 
Date:   Tue May 28 10:17:04 2019 +0800

drm/amdgpu: Need to set the baco cap before baco reset

For passthrough, after rebooted the VM, driver will do
a baco reset before doing other driver initialization during loading
 driver. For doing the baco reset, it will first
check the baco reset capability. So first need to set the
cap from the vbios information or baco reset won't be
enabled.

Signed-off-by: Emily Deng 
Reviewed-by: Evan Quan 

-- 
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: [linux-sunxi] [PATCH v6 0/6] Add support for Orange Pi 3

2019-06-03 Thread Maxime Ripard
On Fri, May 31, 2019 at 02:52:46PM +0200, Ondřej Jirman wrote:
> Hello,
>
> On Mon, May 27, 2019 at 06:22:31PM +0200, megous via linux-sunxi wrote:
> > From: Ondrej Jirman 
> >
> > This series implements support for Xunlong Orange Pi 3 board.
> >
> > Unfortunately, this board needs some small driver patches, so I have
> > split the boards DT patch into chunks that require patches for drivers
> > in various subsystems.
> >
> > Suggested merging plan/dependencies:
> >
> > - stmmac patches are needed for ethernet support (patches 1-3)
> >   - these should be ready now
> > - HDMI support (patches 4-6)
> >   - should be ready
>
> If there are no futher comments, can all these patches please be merged?

I'm waiting for some feedback on the stmmac and the DW-HDMI
developpers to merge the rest

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [v3 6/7] drm/mediatek: change the dsi phytiming calculate method

2019-06-03 Thread Guenter Roeck
On Sun, May 19, 2019 at 05:25:36PM +0800, Jitao Shi wrote:
> Change the method of frame rate calc which can get more accurate
> frame rate.
> 
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
> 
> if MIPI_DSI_MODE_VIDEO_BURST
>   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> else
>   hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
> 
> Note:
> //(2: 1 for sync, 1 for phy idle)
> data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
> 
> bpp: bit per pixel
> 
> Signed-off-by: Jitao Shi 
> Tested-by: Ryan Case 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 119 +
>  1 file changed, 86 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 1165ff944889..3f51b2000c68 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -158,6 +158,25 @@
>   (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
>   (type == MIPI_DSI_DCS_READ))
>  
> +struct mtk_phy_timing {
> + u32 lpx;
> + u32 da_hs_prepare;
> + u32 da_hs_zero;
> + u32 da_hs_trail;
> +
> + u32 ta_go;
> + u32 ta_sure;
> + u32 ta_get;
> + u32 da_hs_exit;
> +
> + u32 clk_hs_zero;
> + u32 clk_hs_trail;
> +
> + u32 clk_hs_prepare;
> + u32 clk_hs_post;
> + u32 clk_hs_exit;
> +};
> +
>  struct phy;
>  
>  struct mtk_dsi_driver_data {
> @@ -182,12 +201,13 @@ struct mtk_dsi {
>   struct clk *digital_clk;
>   struct clk *hs_clk;
>  
> - u32 data_rate;
> + u64 data_rate;

This results in 64-bit divide operations and thus build failures
with 32-bit builds. More on that below.

>  
>   unsigned long mode_flags;
>   enum mipi_dsi_pixel_format format;
>   unsigned int lanes;
>   struct videomode vm;
> + struct mtk_phy_timing phy_timing;
>   int refcount;
>   bool enabled;
>   u32 irq_data;
> @@ -221,17 +241,39 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
>   u32 timcon0, timcon1, timcon2, timcon3;
>   u32 ui, cycle_time;
> + struct mtk_phy_timing *timing = >phy_timing;
> +
> + ui = 10 / dsi->data_rate;
> + cycle_time = 80 / dsi->data_rate;

This results in 64-bit divide operations. On top of that, 80
is larger than 0x, resulting in an integer overflow on 32-bit
systems; it should be provided as 80ULL. 

> +
> + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> + timing->da_hs_prepare = NS_TO_CYCLE((40 + 5 * ui), cycle_time);
> + timing->da_hs_zero = NS_TO_CYCLE((110 + 6 * ui), cycle_time);
> + timing->da_hs_trail = NS_TO_CYCLE(((0x4 * ui) + 80), cycle_time);
> +
> + if (timing->da_hs_zero > timing->da_hs_prepare)
> + timing->da_hs_zero -= timing->da_hs_prepare;
> +
> + timing->ta_go = 4 * timing->lpx;
> + timing->ta_sure = 3 * timing->lpx / 2;
> + timing->ta_get = 5 * timing->lpx;
> + timing->da_hs_exit = 2 * timing->lpx;
> +
> + timing->clk_hs_zero = NS_TO_CYCLE(0x150, cycle_time);
> + timing->clk_hs_trail = NS_TO_CYCLE(0x64, cycle_time) + 0xa;
>  
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> + timing->clk_hs_prepare = NS_TO_CYCLE(0x40, cycle_time);
> + timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> + timing->clk_hs_exit = 2 * timing->lpx;
>  
> - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> -   T_HS_EXIT << 24;
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> -   (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> -   NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> + timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> +   timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> + timcon1 = timing->ta_go | timing->ta_sure << 8 |
> +   timing->ta_get << 16 | timing->da_hs_exit << 24;
> + timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> +   timing->clk_hs_trail << 24;
> + timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> +   timing->clk_hs_exit << 16;
>  
>   writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
>   writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -418,7 +460,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>   u32 horizontal_sync_active_byte;
>   u32 horizontal_backporch_byte;
>   u32 horizontal_frontporch_byte;
> - u32 dsi_tmp_buf_bpp;
> + u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + struct mtk_phy_timing *timing = >phy_timing;
>  
>   struct videomode *vm = >vm;
>  
> @@ -433,7 +476,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
>   writel(vm->vactive, dsi->regs 

Re: [PATCH v6 0/6] Allwinner H6 Mali GPU support

2019-06-03 Thread Clément Péron
Hi Maxime, Joerg,

On Wed, 22 May 2019 at 21:27, Rob Herring  wrote:
>
> On Tue, May 21, 2019 at 11:11 AM Clément Péron  wrote:
> >
> > Hi,
> >
> > The Allwinner H6 has a Mali-T720 MP2 which should be supported by
> > the new panfrost driver. This series fix two issues and introduce the
> > dt-bindings but a simple benchmark show that it's still NOT WORKING.
> >
> > I'm pushing it in case someone want to continue the work.
> >
> > This has been tested with Mesa3D 19.1.0-RC2 and a GPU bitness patch[1].
> >
> > One patch is from Icenowy Zheng where I changed the order as required
> > by Rob Herring[2].
> >
> > Thanks,
> > Clement
> >
> > [1] https://gitlab.freedesktop.org/kszaq/mesa/tree/panfrost_64_32
> > [2] https://patchwork.kernel.org/patch/10699829/
> >
> >
> > [  345.204813] panfrost 180.gpu: mmu irq status=1
> > [  345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> > 0x02400400
> > [  345.209617] Reason: TODO
> > [  345.209617] raw fault status: 0x82C1
> > [  345.209617] decoded fault status: SLAVE FAULT
> > [  345.209617] exception type 0xC1: TRANSLATION_FAULT_LEVEL1
> > [  345.209617] access type 0x2: READ
> > [  345.209617] source id 0x8000
> > [  345.729957] panfrost 180.gpu: gpu sched timeout, js=0,
> > status=0x8, head=0x2400400, tail=0x2400400, sched_job=9e204de9
> > [  346.055876] panfrost 180.gpu: mmu irq status=1
> > [  346.060680] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> > 0x02C00A00
> > [  346.060680] Reason: TODO
> > [  346.060680] raw fault status: 0x810002C1
> > [  346.060680] decoded fault status: SLAVE FAULT
> > [  346.060680] exception type 0xC1: TRANSLATION_FAULT_LEVEL1
> > [  346.060680] access type 0x2: READ
> > [  346.060680] source id 0x8100
> > [  346.561955] panfrost 180.gpu: gpu sched timeout, js=1,
> > status=0x8, head=0x2c00a00, tail=0x2c00a00, sched_job=b55a9a85
> > [  346.573913] panfrost 180.gpu: mmu irq status=1
> > [  346.578707] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> > 0x02C00B80
> >
> > Change in v5:
> >  - Remove fix indent
> >
> > Changes in v4:
> >  - Add bus_clock probe
> >  - Fix sanity check in io-pgtable
> >  - Add vramp-delay
> >  - Merge all boards into one patch
> >  - Remove upstreamed Neil A. patch
> >
> > Change in v3 (Thanks to Maxime Ripard):
> >  - Reauthor Icenowy for her path
> >
> > Changes in v2 (Thanks to Maxime Ripard):
> >  - Drop GPU OPP Table
> >  - Add clocks and clock-names in required
> >
> > Clément Péron (5):
> >   drm: panfrost: add optional bus_clock
> >   iommu: io-pgtable: fix sanity check for non 48-bit mali iommu
> >   dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible
> >   arm64: dts: allwinner: Add ARM Mali GPU node for H6
> >   arm64: dts: allwinner: Add mali GPU supply for H6 boards
> >
> > Icenowy Zheng (1):
> >   dt-bindings: gpu: add bus clock for Mali Midgard GPUs
>
> I've applied patches 1 and 3 to drm-misc. I was going to do patch 4
> too, but it doesn't apply.
>
> Patch 2 can go in via the iommu tree and the rest via the allwinner tree.

Is this OK for you to pick up this series?

Thanks,
Clément

>
> Rob


[PATCH v4 3/5] drm/msm: fix fb references in async update

2019-06-03 Thread Helen Koike
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Cc:  # v4.14+
Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Acked-by: Rob Clark 

---
Hello,

This was tested on the dragonboard 410c using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.

Changes in v4:
- add acked by tag

Changes in v3: None
Changes in v2:
- update CC stable and Fixes tag

 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index 9d9fb6c5fd68..1105c2433f14 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
 static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
   struct drm_plane_state *new_state)
 {
+   struct drm_framebuffer *old_fb = plane->state->fb;
+
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
plane->state->crtc_x = new_state->crtc_x;
@@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_update(struct drm_plane 
*plane,
 
*to_mdp5_plane_state(plane->state) =
*to_mdp5_plane_state(new_state);
+
+   new_state->fb = old_fb;
 }
 
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
-- 
2.20.1

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

[PATCH v4 4/5] drm/vc4: fix fb references in async update

2019-06-03 Thread Helen Koike
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Cc:  # v4.19+
Fixes: 539c320bfa97 ("drm/vc4: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Reviewed-by: Boris Brezillon 

---
Hello,

I tested on a Raspberry Pi model B rev2 with igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.

Changes in v4: None
Changes in v3: None
Changes in v2:
- Added reviewed-by tag
- updated CC stable and Fixes tag

 drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index be2274924b34..441e06d45c89 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -1020,7 +1020,7 @@ static void vc4_plane_atomic_async_update(struct 
drm_plane *plane,
 {
struct vc4_plane_state *vc4_state, *new_vc4_state;
 
-   drm_atomic_set_fb_for_plane(plane->state, state->fb);
+   swap(plane->state->fb, state->fb);
plane->state->crtc_x = state->crtc_x;
plane->state->crtc_y = state->crtc_y;
plane->state->crtc_w = state->crtc_w;
-- 
2.20.1

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

[PATCH v4 2/5] drm/amd: fix fb references in async update

2019-06-03 Thread Helen Koike
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Reviewed-by: Nicholas Kazlauskas 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- added reviewed-by tag

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 443b13ec268d..40624b2c630e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4347,8 +4347,7 @@ static void dm_plane_atomic_async_update(struct drm_plane 
*plane,
struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(new_state->state, plane);
 
-   if (plane->state->fb != new_state->fb)
-   drm_atomic_set_fb_for_plane(plane->state, new_state->fb);
+   swap(plane->state->fb, new_state->fb);
 
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
-- 
2.20.1

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

[PATCH v4 5/5] drm: don't block fb changes for async plane updates

2019-06-03 Thread Helen Koike
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.

In the case of async updates, the preparation is also done in the
new_state but the cleanups are done in the new_state (because updates
are performed in place, i.e. in the current state).

The current code blocks async udpates when the fb is changed, turning
async updates into sync updates, slowing down cursor updates and
introducing regressions in igt tests with errors of type:

"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"

Fb changes in async updates were prevented to avoid the following scenario:

- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
Where we have a single call to prepare fb2 but double cleanup call to fb2.

To solve the above problems, instead of blocking async fb changes, we
place the old framebuffer in the new_state object, so when the code
performs cleanups in the new_state it will cleanup the old_fb and we
will have the following scenario instead:

- Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2

Where calls to prepare/cleanup are balanced.

Cc:  # v4.14+
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 
Reviewed-by: Boris Brezillon 
Reviewed-by: Nicholas Kazlauskas 

---

Changes in v4:
- update docs in atomic_async_update callback

Changes in v3:
- Add Reviewed-by tags
- Add TODO in drm_atomic_helper_async_commit()

Changes in v2:
- Change the order of the patch in the series, add this as the last one.
- Add documentation
- s/ballanced/balanced

 drivers/gpu/drm/drm_atomic_helper.c  | 22 --
 include/drm/drm_modeset_helper_vtables.h |  8 
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index acf993cb8e52..ac81d8440b40 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1610,15 +1610,6 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
 
-   /*
-* FIXME: Since prepare_fb and cleanup_fb are always called on
-* the new_plane_state for async updates we need to block framebuffer
-* changes. This prevents use of a fb that's been cleaned up and
-* double cleanups from occuring.
-*/
-   if (old_plane_state->fb != new_plane_state->fb)
-   return -EINVAL;
-
funcs = plane->helper_private;
if (!funcs->atomic_async_update)
return -EINVAL;
@@ -1649,6 +1640,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_check);
  * drm_atomic_async_check() succeeds. Async commits are not supposed to swap
  * the states like normal sync commits, but just do in-place changes on the
  * current state.
+ *
+ * TODO: Implement full swap instead of doing in-place changes.
  */
 void drm_atomic_helper_async_commit(struct drm_device *dev,
struct drm_atomic_state *state)
@@ -1659,6 +1652,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
*dev,
int i;
 
for_each_new_plane_in_state(state, plane, plane_state, i) {
+   struct drm_framebuffer *new_fb = plane_state->fb;
+   struct drm_framebuffer *old_fb = plane->state->fb;
+
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
 
@@ -1667,11 +1663,17 @@ void drm_atomic_helper_async_commit(struct drm_device 
*dev,
 * plane->state in-place, make sure at least common
 * properties have been properly updated.
 */
-   WARN_ON_ONCE(plane->state->fb != plane_state->fb);
+   WARN_ON_ONCE(plane->state->fb != new_fb);
WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
+
+   /*
+* Make sure the FBs have been swapped so that cleanups in the
+* new_state performs a cleanup in the old FB.
+*/
+   WARN_ON_ONCE(plane_state->fb != old_fb);
}
 }
 

[PATCH v4 0/5] drm: Fix fb changes for async updates

2019-06-03 Thread Helen Koike
Hello,

I'm re-sending this series with the acked by in the msm patch and
updating the docs in the last patch, the rest is the same.

v3 link: https://patchwork.kernel.org/project/dri-devel/list/?series=91353

Thanks!
Helen

Changes in v4:
- add acked by tag
- update docs in atomic_async_update callback

Changes in v3:
- use swap() to swap old and new framebuffers in async_update
- get the reference to old_fb and set the worker after vop_plane_atomic_update()
- add a FIXME tag for when we have multiple fbs to be released when
vblank happens.
- update commit message
- Add Reviewed-by tags
- Add TODO in drm_atomic_helper_async_commit()

Changes in v2:
- added reviewed-by tag
- update CC stable and Fixes tag
- Added reviewed-by tag
- updated CC stable and Fixes tag
- Change the order of the patch in the series, add this as the last one.
- Add documentation
- s/ballanced/balanced

Helen Koike (5):
  drm/rockchip: fix fb references in async update
  drm/amd: fix fb references in async update
  drm/msm: fix fb references in async update
  drm/vc4: fix fb references in async update
  drm: don't block fb changes for async plane updates

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
 drivers/gpu/drm/drm_atomic_helper.c   | 22 
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  4 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 51 ++-
 drivers/gpu/drm/vc4/vc4_plane.c   |  2 +-
 include/drm/drm_modeset_helper_vtables.h  |  8 +++
 6 files changed, 52 insertions(+), 38 deletions(-)

-- 
2.20.1

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

[PATCH v4 1/5] drm/rockchip: fix fb references in async update

2019-06-03 Thread Helen Koike
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleaned up (instead of the old_state, unlike what happens in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
in the end of async_update, so cleanup call will unreference the old_fb
correctly.

Also, the previous code had a:

plane_state = plane->funcs->atomic_duplicate_state(plane);
...
swap(plane_state, plane->state);

if (plane->state->fb && plane->state->fb != new_state->fb) {
...
}

Which was wrong, as the fb were just assigned to be equal, so this if
statement nevers evaluates to true.

Another details is that the function drm_crtc_vblank_get() can only be
called when vop->is_enabled is true, otherwise it has no effect and
trows a WARN_ON().

Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
fb and pus the old fb) is not required, as it is taken care by
drm_mode_cursor_universal() when calling
drm_atomic_helper_update_plane().

Signed-off-by: Helen Koike 

---
Hello,

I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.

Changes in v4: None
Changes in v3:
- use swap() to swap old and new framebuffers in async_update
- get the reference to old_fb and set the worker after vop_plane_atomic_update()
- add a FIXME tag for when we have multiple fbs to be released when
vblank happens.
- update commit message

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 +++--
 1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 4189ca17f381..b7c47d1153c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -919,29 +919,17 @@ static void vop_plane_atomic_async_update(struct 
drm_plane *plane,
  struct drm_plane_state *new_state)
 {
struct vop *vop = to_vop(plane->state->crtc);
-   struct drm_plane_state *plane_state;
-
-   plane_state = plane->funcs->atomic_duplicate_state(plane);
-   plane_state->crtc_x = new_state->crtc_x;
-   plane_state->crtc_y = new_state->crtc_y;
-   plane_state->crtc_h = new_state->crtc_h;
-   plane_state->crtc_w = new_state->crtc_w;
-   plane_state->src_x = new_state->src_x;
-   plane_state->src_y = new_state->src_y;
-   plane_state->src_h = new_state->src_h;
-   plane_state->src_w = new_state->src_w;
-
-   if (plane_state->fb != new_state->fb)
-   drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
-
-   swap(plane_state, plane->state);
-
-   if (plane->state->fb && plane->state->fb != new_state->fb) {
-   drm_framebuffer_get(plane->state->fb);
-   WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
-   drm_flip_work_queue(>fb_unref_work, plane->state->fb);
-   set_bit(VOP_PENDING_FB_UNREF, >pending);
-   }
+   struct drm_framebuffer *old_fb = plane->state->fb;
+
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->crtc_h = new_state->crtc_h;
+   plane->state->crtc_w = new_state->crtc_w;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->src_h = new_state->src_h;
+   plane->state->src_w = new_state->src_w;
+   swap(plane->state->fb, new_state->fb);
 
if (vop->is_enabled) {
rockchip_drm_psr_inhibit_get_state(new_state->state);
@@ -950,9 +938,22 @@ static void vop_plane_atomic_async_update(struct drm_plane 
*plane,
vop_cfg_done(vop);
spin_unlock(>reg_lock);
rockchip_drm_psr_inhibit_put_state(new_state->state);
-   }
 
-   plane->funcs->atomic_destroy_state(plane, plane_state);
+   /*
+* A scanout can still be occurring, so we can't drop the
+* reference to the old framebuffer. To solve this we get a
+* reference to old_fb and set a worker to release it later.
+* FIXME: if we perform 500 async_update calls before the
+* vblank, then we can have 500 different framebuffers waiting
+* to be released.
+*/
+   if (old_fb && plane->state->fb != old_fb) {
+   drm_framebuffer_get(old_fb);
+   WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
+   drm_flip_work_queue(>fb_unref_work, old_fb);
+   set_bit(VOP_PENDING_FB_UNREF, >pending);
+   }
+   }
 }
 
 static const struct drm_plane_helper_funcs plane_helper_funcs = {
-- 
2.20.1


Re: [PATCH v3 5/5] drm: don't block fb changes for async plane updates

2019-06-03 Thread Helen Koike


On 5/7/19 5:18 PM, Sean Paul wrote:
> On Wed, Mar 13, 2019 at 09:20:26PM -0300, Helen Koike wrote:
>> In the case of a normal sync update, the preparation of framebuffers (be
>> it calling drm_atomic_helper_prepare_planes() or doing setups with
>> drm_framebuffer_get()) are performed in the new_state and the respective
>> cleanups are performed in the old_state.
>>
>> In the case of async updates, the preparation is also done in the
>> new_state but the cleanups are done in the new_state (because updates
>> are performed in place, i.e. in the current state).
>>
>> The current code blocks async udpates when the fb is changed, turning
>> async updates into sync updates, slowing down cursor updates and
>> introducing regressions in igt tests with errors of type:
>>
>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
>> expect to complete approximately 15360 updates, with the threshold set
>> at 7680"
>>
>> Fb changes in async updates were prevented to avoid the following scenario:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 
>> (wrong)
>> Where we have a single call to prepare fb2 but double cleanup call to fb2.
>>
>> To solve the above problems, instead of blocking async fb changes, we
>> place the old framebuffer in the new_state object, so when the code
>> performs cleanups in the new_state it will cleanup the old_fb and we
>> will have the following scenario instead:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>>
>> Where calls to prepare/cleanup are balanced.
>>
>> Cc:  # v4.14+
> 
> I'm not convinced this should be cc: stable, seems more in the improvement
> category than a bug fix.

I'm cc'ing to stable because the commit mentioned below inserted a
regression regarding the speed that cursors can be updated.

> 
>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
>> Suggested-by: Boris Brezillon 
>> Signed-off-by: Helen Koike 
>> Reviewed-by: Boris Brezillon 
>> Reviewed-by: Nicholas Kazlauskas 
>>
>> ---
>> Hello,
>>
>> I added a TODO in drm_atomic_helper_async_commit() regarding doing a
>> full state swap(), Boris and Nicholas, let me know if this is ok and if
>> I can keep your Reviewed-by tags)
>>
>> As mentioned in the cover letter, I tested in almost all platforms with
>> igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
>> regressions. But I couldn't test on MSM and AMD because I don't have
>> the hardware I would appreciate if anyone could help me testing those.
>>
>> Thanks!
>> Helen
>>
>> Changes in v3:
>> - Add Reviewed-by tags
>> - Add TODO in drm_atomic_helper_async_commit()
>>
>> Changes in v2:
>> - Change the order of the patch in the series, add this as the last one.
>> - Add documentation
>> - s/ballanced/balanced
>>
>>  drivers/gpu/drm/drm_atomic_helper.c  | 22 --
>>  include/drm/drm_modeset_helper_vtables.h |  5 +
>>  2 files changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 2453678d1186..de5812c362b5 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device 
>> *dev,
>>  old_plane_state->crtc != new_plane_state->crtc)
>>  return -EINVAL;
>>  
>> -/*
>> - * FIXME: Since prepare_fb and cleanup_fb are always called on
>> - * the new_plane_state for async updates we need to block framebuffer
>> - * changes. This prevents use of a fb that's been cleaned up and
>> - * double cleanups from occuring.
>> - */
>> -if (old_plane_state->fb != new_plane_state->fb)
>> -return -EINVAL;
>> -
>>  funcs = plane->helper_private;
>>  if (!funcs->atomic_async_update)
>>  return -EINVAL;
>> @@ -1647,6 +1638,8 @@ EXPORT_SYMBOL(drm_atomic_helper_async_check);
>>   * drm_atomic_async_check() succeeds. Async commits are not supposed to swap
>>   * the states like normal sync commits, but just do in-place changes on the
>>   * current state.
>> + *
>> + * TODO: Implement full swap instead of doing in-place changes.
>>   */
>>  void drm_atomic_helper_async_commit(struct drm_device *dev,
>>  struct drm_atomic_state *state)
>> @@ -1657,6 +1650,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
>> *dev,
>>  int i;
>>  
>>  for_each_new_plane_in_state(state, plane, plane_state, i) {
>> +struct drm_framebuffer *new_fb = plane_state->fb;
>> +struct drm_framebuffer *old_fb = plane->state->fb;
>> +
>>  funcs = 

[Bug 110831] [AMD TAHITI XT][amd-staging-drm-next] broken since 5.2-rc1 rebase

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110831

Bug ID: 110831
   Summary: [AMD TAHITI XT][amd-staging-drm-next] broken since
5.2-rc1 rebase
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: highest
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sylvain.bertr...@gmail.com

xorg amdgpu driver initing hangs the system with 5.2-rc1 rebased
amd-staging-drm-next linux kernel.

Yes I can bisect. Stay tuned.

-- 
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][next] drm/bridge: sii902x: fix comparision of u32 with less than zero

2019-06-03 Thread Jyri Sarha
On 03/06/2019 17:21, Colin King wrote:
> From: Colin Ian King 
> 
> The less than check for the variable num_lanes is always going to be
> false because the variable is a u32.  Fix this by making num_lanes an
> int and also make loop index i an int too.
> 
> Addresses-Coverity: ("Unsigned compared against 0")
> Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
> Signed-off-by: Colin Ian King 

Oh, one of these slipped trough after all.

Acked-by: Jyri Sarha 

> ---
>  drivers/gpu/drm/bridge/sii902x.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index d6f98d388ac2..21a947603c88 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -719,7 +719,7 @@ static int sii902x_audio_codec_init(struct sii902x 
> *sii902x,
>   .max_i2s_channels = 0,
>   };
>   u8 lanes[4];
> - u32 num_lanes, i;
> + int num_lanes, i;
>  
>   if (!of_property_read_bool(dev->of_node, "#sound-dai-cells")) {
>   dev_dbg(dev, "%s: No \"#sound-dai-cells\", no audio\n",
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr

2019-06-03 Thread Daniel Vetter
On Mon, Jun 3, 2019 at 5:43 PM Eric Anholt  wrote:
>
> Daniel Vetter  writes:
>
> > On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote:
> >> Boris Brezillon  writes:
> >>
> >> > Right now, the BO is mapped as a cached region when ->vmap() is called
> >> > and the underlying object is not a dmabuf.
> >> > Doing that makes cache management a bit more complicated (you'd need
> >> > to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
> >> > to be passed to the GPU/CPU), so let's map the BO with writecombine
> >> > attributes instead (as done in most drivers).
> >> >
> >> > Signed-off-by: Boris Brezillon 
> >> > ---
> >> > Found this issue while working on panfrost perfcnt where the GPU dumps
> >> > perf counter values in memory and the CPU reads them back in
> >> > kernel-space. This patch seems to solve the unpredictable behavior I
> >> > had.
> >> >
> >> > I can also go for the other option (call dma_map/unmap/_sg() when
> >> > needed) if you think that's more appropriate.
> >>
> >> writecombined was the intent, and this makes kernel vmap match the
> >> userspace mmap path.
> >
> > Since I missed that obviously: Where do the shmem helpers set write
> > combined mode for userspace mmap?
>
> That was the trick when I asked the question, too.  drm_gem.c is what
> sets WC by default.

TIL. And looks like this has been the case forever, it laned in

commit a2c0a97b784f837300f7b0869c82ab712c600952
Author: Jesse Barnes 
Date:   Wed Nov 5 10:31:53 2008 -0800

drm: GEM mmap support

I'll retract my concern, making this wc everywhere is the right thing to do.

Reviewed-by: Daniel Vetter 

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/gem_shmem: Use a writecombine mapping for ->vaddr

2019-06-03 Thread Eric Anholt
Daniel Vetter  writes:

> On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote:
>> Boris Brezillon  writes:
>> 
>> > Right now, the BO is mapped as a cached region when ->vmap() is called
>> > and the underlying object is not a dmabuf.
>> > Doing that makes cache management a bit more complicated (you'd need
>> > to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
>> > to be passed to the GPU/CPU), so let's map the BO with writecombine
>> > attributes instead (as done in most drivers).
>> >
>> > Signed-off-by: Boris Brezillon 
>> > ---
>> > Found this issue while working on panfrost perfcnt where the GPU dumps
>> > perf counter values in memory and the CPU reads them back in
>> > kernel-space. This patch seems to solve the unpredictable behavior I
>> > had.
>> >
>> > I can also go for the other option (call dma_map/unmap/_sg() when
>> > needed) if you think that's more appropriate.
>> 
>> writecombined was the intent, and this makes kernel vmap match the
>> userspace mmap path.
>
> Since I missed that obviously: Where do the shmem helpers set write
> combined mode for userspace mmap?

That was the trick when I asked the question, too.  drm_gem.c is what
sets WC by default.


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

Re: [pull] amdgpu, amdkfd drm-next-5.3

2019-06-03 Thread Daniel Vetter
On Thu, May 30, 2019 at 12:09 AM Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.3:
> - Add new thermal sensors for vega asics
> - Various RAS fixes
> - Add sysfs interface for memory interface utilization
> - Use HMM rather than mmu notifier for user pages
> - Expose xgmi topology via kfd
> - SR-IOV fixes
> - Fixes for manual driver reload
> - Add unique identifier for vega asics
> - Clean up user fence handling with UVD/VCE/VCN blocks
> - Convert DC to use core bpc attribute rather than a custom one
> - Add GWS support for KFD
> - Vega powerplay improvements
> - Add CRC support for DCE 12
> - SR-IOV support for new security policy
> - Various cleanups

> Chunming Zhou (1):
>   drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu

This unconditionally enables timeline syncobj support, Which I thought
we've decided to hold back behind some module_param_named_unsafe or
experimental Kconfig, at least until KHR ratifies the extensions and
everyone can publish the mesa patches. This is kinda uapi without
userspace as-is ... also not on your summary, or I'm blind.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] dt-bindings: display: Add GiantPlus GPM940B0 panel documentation

2019-06-03 Thread Paul Cercueil
The GPM940B0 is a 3.0" 320x240 24-bit TFT LCD panel.

Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
---

Notes:
v2: New patch

v3: Add Rob's ack

v4: No change

 .../bindings/display/panel/giantplus,gpm940b0.txt| 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt 
b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt
new file mode 100644
index ..3dab52f92c26
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt
@@ -0,0 +1,12 @@
+GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel
+
+Required properties:
+- compatible: should be "giantplus,gpm940b0"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.21.0.593.g511ec345e18



[PATCH v4 2/3] media: uapi: Add RGB bus format for the GiantPlus GPM940B0 panel

2019-06-03 Thread Paul Cercueil
The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components
are transferred sequentially on a 8-bit bus.

Signed-off-by: Paul Cercueil 
---

Notes:
v2: New patch

v3: No change

v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about
endianness

 include/uapi/linux/media-bus-format.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 2a6b253cfb05..16c1fa2d89a4 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101c */
+/* RGB - next is   0x101d */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -55,6 +55,7 @@
 #define MEDIA_BUS_FMT_RGB888_1X24  0x100a
 #define MEDIA_BUS_FMT_RGB888_2X12_BE   0x100b
 #define MEDIA_BUS_FMT_RGB888_2X12_LE   0x100c
+#define MEDIA_BUS_FMT_RGB888_3X8   0x101c
 #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
-- 
2.21.0.593.g511ec345e18



[PATCH v4 3/3] drm/panel: simple: Add GiantPlus GPM940B0 panel support

2019-06-03 Thread Paul Cercueil
The GiantPlus GPM940B0 is a simple 3.0" 320x240 24-bit TFT panel.

Signed-off-by: Paul Cercueil 
Tested-by: Artur Rojek 
---

Notes:
v2: Change bus format to MEDIA_BUS_FMT_RGB888_3X8_BE

v3: No change

v4: Change bus format to MEDIA_BUS_FMT_RGB888_3X8

 drivers/gpu/drm/panel/panel-simple.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4edf1e4..eec9a9efcc73 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1335,6 +1335,31 @@ static const struct panel_desc giantplus_gpg482739qs5 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct display_timing giantplus_gpm940b0_timing = {
+   .pixelclock = { 1350, 2700, 2750 },
+   .hactive = { 320, 320, 320 },
+   .hfront_porch = { 14, 686, 718 },
+   .hback_porch = { 50, 70, 255 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 240, 240, 240 },
+   .vfront_porch = { 1, 1, 179 },
+   .vback_porch = { 1, 21, 31 },
+   .vsync_len = { 1, 1, 6 },
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc giantplus_gpm940b0 = {
+   .timings = _gpm940b0_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 60,
+   .height = 45,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_3X8,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
 static const struct display_timing hannstar_hsd070pww1_timing = {
.pixelclock = { 6430, 7110, 8200 },
.hactive = { 1280, 1280, 1280 },
@@ -2882,6 +2907,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
+   }, {
+   .compatible = "giantplus,gpm940b0",
+   .data = _gpm940b0,
}, {
.compatible = "hannstar,hsd070pww1",
.data = _hsd070pww1,
-- 
2.21.0.593.g511ec345e18



[PATCH v4 1/3] dt-bindings: display: Add Sharp LS020B1DD01D panel documentation

2019-06-03 Thread Paul Cercueil
The LS020B1DD01D is a 2.0" 240x160 16-bit TFT LCD panel.

Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
---

Notes:
v2: New patch

v3: Add Rob's Reviewed-by

v4: Rebase on drm-misc-next (b232d4ed92ea)

 .../bindings/display/panel/sharp,ls020b1dd01d.txt| 12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt
new file mode 100644
index ..e45edbc565a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt
@@ -0,0 +1,12 @@
+Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls020b1dd01d"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.21.0.593.g511ec345e18



[PATCH v4 3/3] drm/panel: simple: Add Sharp LS020B1DD01D panel support

2019-06-03 Thread Paul Cercueil
The Sharp LS020B1DD01D is a simple 2.0" 240x160 16-bit TFT panel.

Signed-off-by: Paul Cercueil 
Tested-by: Artur Rojek 
---

Notes:
v2: No change

v3: Add DRM_BUS_FLAG_SHARP_SIGNALS to the bus flags

v4: Rebase on drm-misc-next (b232d4ed92ea)

 drivers/gpu/drm/panel/panel-simple.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5a93c4edf1e4..5049f0099fdd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2454,6 +2454,33 @@ static const struct panel_desc sharp_lq150x1lg11 = {
.bus_format = MEDIA_BUS_FMT_RGB565_1X16,
 };
 
+static const struct display_timing sharp_ls020b1dd01d_timing = {
+   .pixelclock = { 200, 420, 500 },
+   .hactive = { 240, 240, 240 },
+   .hfront_porch = { 66, 66, 66 },
+   .hback_porch = { 1, 1, 1 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 160, 160, 160 },
+   .vfront_porch = { 52, 52, 52 },
+   .vback_porch = { 6, 6, 6 },
+   .vsync_len = { 10, 10, 10 },
+   .flags = DISPLAY_FLAGS_HSYNC_HIGH | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc sharp_ls020b1dd01d = {
+   .timings = _ls020b1dd01d_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 42,
+   .height = 28,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH
+  | DRM_BUS_FLAG_PIXDATA_NEGEDGE
+  | DRM_BUS_FLAG_SHARP_SIGNALS,
+};
+
 static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
.clock = 33300,
.hdisplay = 800,
@@ -3014,6 +3041,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "sharp,lq150x1lg11",
.data = _lq150x1lg11,
+   }, {
+   .compatible = "sharp,ls020b1dd01d",
+   .data = _ls020b1dd01d,
}, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
-- 
2.21.0.593.g511ec345e18



[PATCH v4 2/3] drm: Add bus flag for Sharp-specific signals

2019-06-03 Thread Paul Cercueil
Add the DRM_BUS_FLAG_SHARP_SIGNALS to the drm_bus_flags enum.

This flags can be used when the display must be driven with the
Sharp-specific signals SPL, CLS, REV, PS.

Signed-off-by: Paul Cercueil 
---

Notes:
v3: New patch

v4: Rebase on drm-misc-next (b232d4ed92ea)

 include/drm/drm_connector.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 547656173c74..5861367f7339 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -323,6 +323,8 @@ enum drm_panel_orientation {
  * edge of the pixel clock
  * @DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE:  Sync signals are sampled on the falling
  * edge of the pixel clock
+ * @DRM_BUS_FLAG_SHARP_SIGNALS:Set if the Sharp-specific 
signals
+ * (SPL, CLS, PS, REV) must be used
  */
 enum drm_bus_flags {
DRM_BUS_FLAG_DE_LOW = BIT(0),
@@ -341,6 +343,7 @@ enum drm_bus_flags {
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE = DRM_BUS_FLAG_SYNC_NEGEDGE,
DRM_BUS_FLAG_SYNC_SAMPLE_POSEDGE = DRM_BUS_FLAG_SYNC_NEGEDGE,
DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE = DRM_BUS_FLAG_SYNC_POSEDGE,
+   DRM_BUS_FLAG_SHARP_SIGNALS = BIT(8),
 };
 
 /**
-- 
2.21.0.593.g511ec345e18



[PATCH v2 2/2] drm/panel: Add Novatek NT39016 panel support

2019-06-03 Thread Paul Cercueil
Add support for display panels built around the Novatek NT39016 display
controller, as found on e.g. the King Display KD035G6-54NT 24-bit
320x240 3.5" LCD panel which equips the GCW Zero open-source handheld
gaming console.

Signed-off-by: Paul Cercueil 
Signed-off-by: Maarten ter Huurne 
---

Notes:
v2: - Don't cleanup backlight, as we use devm function to create it
- Use backlight_enable / backlight_disable
- Reorder includes
- Use %d instead of %i to match other panel drivers
- Bit 2 of NT39016_REG_SYSTEM register is 'reserved' and setting
  it doesn't seem to have any effect, so we don't set it anymore
- Use macros for bits 0 and 1 of NT39016_REG_SYSTEM
- Avoid 150ms sleep in nt39016_enable() if there is no backlight
  device
- Include  instead of
  
- use /* sentinel */ in the last entry of the of_device_id table

 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-novatek-nt39016.c | 359 ++
 3 files changed, 369 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt39016.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d9d931aa6e26..17959876621f 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -111,6 +111,15 @@ config DRM_PANEL_LG_LG4573
  Say Y here if you want to enable support for LG4573 RGB panel.
  To compile this driver as a module, choose M here.
 
+config DRM_PANEL_NOVATEK_NT39016
+   tristate "Novatek NT39016 RGB/SPI panel"
+   depends on OF && SPI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select REGMAP_SPI
+   help
+ Say Y here if you want to enable support for the panels built
+ around the Novatek NT39016 display controller.
+
 config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index fb0cb3aaa9e6..f8709d280d61 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += 
panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_KINGDISPLAY_KD097D04) += panel-kingdisplay-kd097d04.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
 obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
 obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c 
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
new file mode 100644
index ..4a1c172b57c3
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
@@ -0,0 +1,359 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Novatek NT39016 TFT LCD panel driver
+ *
+ * Copyright (C) 2017, Maarten ter Huurne 
+ * Copyright (C) 2019, Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+
+enum nt39016_regs {
+   NT39016_REG_SYSTEM,
+   NT39016_REG_TIMING,
+   NT39016_REG_OP,
+   NT39016_REG_DATA_IN,
+   NT39016_REG_SRC_TIMING_DELAY,
+   NT39016_REG_GATE_TIMING_DELAY,
+   NT39016_REG_RESERVED,
+   NT39016_REG_INITIAL_FUNC,
+   NT39016_REG_CONTRAST,
+   NT39016_REG_BRIGHTNESS,
+   NT39016_REG_HUE_SATURATION,
+   NT39016_REG_RB_SUBCONTRAST,
+   NT39016_REG_R_SUBBRIGHTNESS,
+   NT39016_REG_B_SUBBRIGHTNESS,
+   NT39016_REG_VCOMDC,
+   NT39016_REG_VCOMAC,
+   NT39016_REG_VGAM2,
+   NT39016_REG_VGAM34,
+   NT39016_REG_VGAM56,
+   NT39016_REG_VCOMDC_TRIM = 0x1e,
+   NT39016_REG_DISPLAY_MODE = 0x20,
+};
+
+#define NT39016_SYSTEM_RESET_N BIT(0)
+#define NT39016_SYSTEM_STANDBY BIT(1)
+
+struct nt39016_panel_info {
+   struct drm_display_mode display_mode;
+   u16 width_mm, height_mm;
+   u32 bus_format, bus_flags;
+};
+
+struct nt39016 {
+   struct drm_panel drm_panel;
+   struct device *dev;
+   struct regmap *map;
+   struct regulator *supply;
+   const struct nt39016_panel_info *panel_info;
+
+   struct gpio_desc *reset_gpio;
+
+   struct backlight_device *backlight;
+};
+
+static inline struct nt39016 *to_nt39016(struct drm_panel *panel)
+{
+   return container_of(panel, struct nt39016, drm_panel);
+}
+
+#define RV(REG, VAL) { .reg = (REG), .def = (VAL), .delay_us = 2 }
+static const struct reg_sequence nt39016_panel_regs[] = {
+   RV(NT39016_REG_SYSTEM, 0x00),
+   RV(NT39016_REG_TIMING, 0x00),
+   RV(NT39016_REG_OP, 0x03),
+   RV(NT39016_REG_DATA_IN, 0xCC),
+   

[PATCH v2 1/2] dt-bindings: display: Add King Display KD035G6-54NT panel documentation

2019-06-03 Thread Paul Cercueil
The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.

Signed-off-by: Paul Cercueil 
---

Notes:
v2: - Add an address to the panel node
- Add information about SPI properties
- Add information about the 'port' sub-node

 .../panel/kingdisplay,kd035g6-54nt.txt| 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt 
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
new file mode 100644
index ..fa9596082e44
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.txt
@@ -0,0 +1,42 @@
+King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel
+
+Required properties:
+- compatible: should be "kingdisplay,kd035g6-54nt"
+- power-supply: See panel-common.txt
+- reset-gpios: See panel-common.txt
+
+Optional properties:
+- backlight: see panel-common.txt
+
+The generic bindings for the SPI slaves documented in [1] also apply.
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/spi/spi-bus.txt
+[2]: Documentation/devicetree/bindings/graph.txt
+
+Example:
+
+ {
+   panel@0 {
+   compatible = "kingdisplay,kd035g6-54nt";
+   reg = <0>;
+
+   spi-max-frequency = <3125000>;
+   spi-3wire;
+   spi-cs-high;
+
+   reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+
+   backlight = <>;
+   power-supply = <>;
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+   };
+};
-- 
2.21.0.593.g511ec345e18



[PATCH v5 2/2] DRM: Add KMS driver for the Ingenic JZ47xx SoCs

2019-06-03 Thread Paul Cercueil
Add a KMS driver for the Ingenic JZ47xx family of SoCs.
This driver is meant to replace the aging jz4740-fb driver.

This driver does not make use of the simple pipe helper, for the reason
that it will soon be updated to support more advanced features like
multiple planes, IPU integration for colorspace conversion and up/down
scaling, support for DSI displays, and TV-out and HDMI outputs.

Signed-off-by: Paul Cercueil 
Tested-by: Artur Rojek 
---

Notes:
v2: - Remove custom handling of panel. The panel is now discovered using
  the standard API.
- Lots of small tweaks suggested by upstream

v3: - Use devm_drm_dev_init()
- Update compatible strings to -lcd instead of -drm
- Add destroy() callbacks to plane and crtc
- The ingenic,lcd-mode is now read from the bridge's DT node

v4: Remove ingenic,lcd-mode property completely. The various modes are now
deduced from the connector type, the pixel format or the bus flags.

v5: - Fix framebuffer size incorrectly calculated for 24bpp framebuffers
- Use 32bpp framebuffer instead of 16bpp, as it'll work with both
  16-bit and 24-bit panel
- Get rid of drm_format_plane_cpp() which has been dropped upstream
- Avoid using drm_format_info->depth, which is deprecated.

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/ingenic/Kconfig   |  16 +
 drivers/gpu/drm/ingenic/Makefile  |   1 +
 drivers/gpu/drm/ingenic/ingenic-drm.c | 818 ++
 5 files changed, 838 insertions(+)
 create mode 100644 drivers/gpu/drm/ingenic/Kconfig
 create mode 100644 drivers/gpu/drm/ingenic/Makefile
 create mode 100644 drivers/gpu/drm/ingenic/ingenic-drm.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 6b34949416b1..b9362b4f6353 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -316,6 +316,8 @@ source "drivers/gpu/drm/sti/Kconfig"
 
 source "drivers/gpu/drm/imx/Kconfig"
 
+source "drivers/gpu/drm/ingenic/Kconfig"
+
 source "drivers/gpu/drm/v3d/Kconfig"
 
 source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a63c1fcf389..73538dde47d9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STM) += stm/
 obj-$(CONFIG_DRM_STI) += sti/
 obj-$(CONFIG_DRM_IMX) += imx/
+obj-$(CONFIG_DRM_INGENIC) += ingenic/
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
 obj-$(CONFIG_DRM_MESON)+= meson/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
new file mode 100644
index ..d82c3d37ec9c
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -0,0 +1,16 @@
+config DRM_INGENIC
+   tristate "DRM Support for Ingenic SoCs"
+   depends on MIPS || COMPILE_TEST
+   depends on DRM
+   depends on CMA
+   depends on OF
+   select DRM_BRIDGE
+   select DRM_PANEL_BRIDGE
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   help
+ Choose this option for DRM support for the Ingenic SoCs.
+
+ If M is selected the module will be called ingenic-drm.
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
new file mode 100644
index ..11cac42ce0bb
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c 
b/drivers/gpu/drm/ingenic/ingenic-drm.c
new file mode 100644
index ..006ce6b012f5
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
@@ -0,0 +1,818 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Ingenic JZ47xx KMS driver
+//
+// Copyright (C) 2019, Paul Cercueil 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define JZ_REG_LCD_CFG 0x00
+#define JZ_REG_LCD_VSYNC   0x04
+#define JZ_REG_LCD_HSYNC   0x08
+#define JZ_REG_LCD_VAT 0x0C
+#define JZ_REG_LCD_DAH 0x10
+#define JZ_REG_LCD_DAV 0x14
+#define JZ_REG_LCD_PS  0x18
+#define JZ_REG_LCD_CLS 0x1C
+#define JZ_REG_LCD_SPL 0x20
+#define JZ_REG_LCD_REV 0x24
+#define JZ_REG_LCD_CTRL0x30
+#define JZ_REG_LCD_STATE   0x34
+#define JZ_REG_LCD_IID 0x38
+#define JZ_REG_LCD_DA0 0x40
+#define JZ_REG_LCD_SA0  

[PATCH v5 1/2] dt-bindings: Add doc for the Ingenic JZ47xx LCD controller driver

2019-06-03 Thread Paul Cercueil
Add documentation for the devicetree bindings of the LCD controller present in
the JZ47xx family of SoCs from Ingenic.

Signed-off-by: Paul Cercueil 
Tested-by: Artur Rojek 
---

Notes:
v2: Remove ingenic,panel property.

v3: - Rename compatible strings from ingenic,jz47XX-drm to 
ingenic,jz47XX-lcd
- The ingenic,lcd-mode property is now read from the panel node instead
  of from the driver node

v4: Remove ingenic,lcd-mode property completely.

v5: No change

 .../bindings/display/ingenic,lcd.txt  | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ingenic,lcd.txt

diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt 
b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
new file mode 100644
index ..7b536c8c6dde
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
@@ -0,0 +1,44 @@
+Ingenic JZ47xx LCD driver
+
+Required properties:
+- compatible: one of:
+  * ingenic,jz4740-lcd
+  * ingenic,jz4725b-lcd
+- reg: LCD registers location and length
+- clocks: LCD pixclock and device clock specifiers.
+  The device clock is only required on the JZ4740.
+- clock-names: "lcd_pclk" and "lcd"
+- interrupts: Specifies the interrupt line the LCD controller is connected to.
+
+Example:
+
+panel {
+   compatible = "sharp,ls020b1dd01d";
+
+   backlight = <>;
+   power-supply = <>;
+
+   port {
+   panel_input: endpoint {
+   remote-endpoint = <_output>;
+   };
+   };
+};
+
+
+lcd: lcd-controller@1305 {
+   compatible = "ingenic,jz4725b-lcd";
+   reg = <0x1305 0x1000>;
+
+   interrupt-parent = <>;
+   interrupts = <31>;
+
+   clocks = < JZ4725B_CLK_LCD>;
+   clock-names = "lcd";
+
+   port {
+   panel_output: endpoint {
+   remote-endpoint = <_input>;
+   };
+   };
+};
-- 
2.21.0.593.g511ec345e18



Re: [PATCH v7 09/11] drm: uevent for connector status change

2019-06-03 Thread Ser, Simon
On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:
> On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> > On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen  
> > > wrote:
> > > > On Mon, 20 May 2019 18:11:07 +0200
> > > > Daniel Vetter  wrote:
> > > > 
> > > > > There's also a fairly easy fix for that -modesetting issue: We don't
> > > > > expose atomic if the compositor has a process name of "Xserver". 
> > > > > Brutal,
> > > > > but gets the job done. Once X is fixed, we can give a new "I'm not 
> > > > > totally
> > > > > broken anymore" interface to get back at atomic.
> > > > 
> > > > You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> > > > check against the process issuing ioctl by ioctl, or the process that
> > > > opened the device? Which would be logind? What about DRM leasing? ...
> > > 
> > > In the Get/SetCaps ioctl we can do the check, which is called from X,
> > > not logind. We just need some way to tell -modesetting apart from
> > > everything else, and luckily there's not any other atomic X drivers.
> > 
> > Not yet...
> > 
> > As for a "I'm not totally broken anymore" interface, we did something
> > like that (though kind of in the other direction) with
> > RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
> > be added, because the former claimed acceleration was "working" in cases
> > where it really wasn't... That kind of thing could become ugly in the
> > long run if other Xorg driver start using atomic, and they'll inevitably
> > be broken in different ways.
> 
> It's definitely a very suboptimal situation. Not sure there's a good way
> out. The trouble here is that i915 ended up configuring crtc/connectors
> differently than -modesetting (to allow fastboot, which I think is still
> i915 exclusive). This then highlighted that modesetting can't do atomic
> modesets if you try to reassign connectors.
> 
> One idea I have is that vgms would help compositors to play out a bunch of

Just so people aren't confused: I think Daniel meant "vkms" here :P

> standard scenarios, even automated. But that's not there yet, and every
> compositor project needs to care beyond "boots on my laptop, ship it". No
> idea that's even possible.

Having documentation for userspace is also important IMHO.

Regarding automated compositor testing, it's probably not possible to
have a single place where all compositors are tested: vkms should
probably be included as part of their CI. Thoughts?

Anyway, we could start a discussion to see if compositor people are
interested. Or have you already talked to some compositor maintainers?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/docs: More links for implicit/explicit fencing.

2019-06-03 Thread Daniel Vetter
On Mon, Jun 03, 2019 at 05:34:11PM +0300, Pekka Paalanen wrote:
> On Mon,  3 Jun 2019 16:28:48 +0200
> Daniel Vetter  wrote:
> 
> > drm_atomic_set_fence_for_plane() contains the main discussion from a
> > driver pov, link to that from more places.
> > 
> > Cc: Pekka Paalanen 
> > Signed-off-by: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++
> >  include/drm/drm_plane.h  | 2 +-
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > index 6fd48efe288c..6791245963c3 100644
> > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > @@ -284,6 +284,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
> >   * There is no need for _plane_helper_funcs.cleanup_fb hook for simple
> >   * gem based framebuffer drivers which have their buffers always pinned in
> >   * memory.
> > + *
> > + * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
> > + * explicit fencing in atomic modeset updates.
> >   */
> >  int drm_gem_fb_prepare_fb(struct drm_plane *plane,
> >   struct drm_plane_state *state)
> > @@ -314,6 +317,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
> >   * _buf attached, extracts the exclusive fence and attaches it to plane
> >   * state for the atomic helper to wait on. Drivers can use this as their
> >   * _simple_display_pipe_funcs.prepare_fb callback.
> > + *
> > + * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
> > + * explicit fencing in atomic modeset updates.
> >   */
> >  int drm_gem_fb_simple_display_pipe_prepare_fb(struct 
> > drm_simple_display_pipe *pipe,
> >   struct drm_plane_state 
> > *plane_state)
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 6078c700d9ba..cd5903ad33f7 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -69,7 +69,7 @@ struct drm_plane_state {
> >  *
> >  * Optional fence to wait for before scanning out @fb. The core atomic
> >  * code will set this when userspace is using explicit fencing. Do not
> > -* write this directly for a driver's implicit fence, use
> > +* write this field directly for a driver's implicit fence, use
> >  * drm_atomic_set_fence_for_plane() to ensure that an explicit fence is
> >  * preserved.
> >  *
> 
> Reviewed-by: Pekka Paalanen 
> FWIW

And applied, thanks for taking a look.
-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 v7 09/11] drm: uevent for connector status change

2019-06-03 Thread Daniel Vetter
On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen  wrote:
> >> On Mon, 20 May 2019 18:11:07 +0200
> >> Daniel Vetter  wrote:
> >>
> >>> There's also a fairly easy fix for that -modesetting issue: We don't
> >>> expose atomic if the compositor has a process name of "Xserver". Brutal,
> >>> but gets the job done. Once X is fixed, we can give a new "I'm not totally
> >>> broken anymore" interface to get back at atomic.
> >>
> >> You mean "Xorg". Or maybe "X". Or maybe the setuid helper? Wait, do you
> >> check against the process issuing ioctl by ioctl, or the process that
> >> opened the device? Which would be logind? What about DRM leasing? ...
> > 
> > In the Get/SetCaps ioctl we can do the check, which is called from X,
> > not logind. We just need some way to tell -modesetting apart from
> > everything else, and luckily there's not any other atomic X drivers.
> 
> Not yet...
> 
> As for a "I'm not totally broken anymore" interface, we did something
> like that (though kind of in the other direction) with
> RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
> be added, because the former claimed acceleration was "working" in cases
> where it really wasn't... That kind of thing could become ugly in the
> long run if other Xorg driver start using atomic, and they'll inevitably
> be broken in different ways.

It's definitely a very suboptimal situation. Not sure there's a good way
out. The trouble here is that i915 ended up configuring crtc/connectors
differently than -modesetting (to allow fastboot, which I think is still
i915 exclusive). This then highlighted that modesetting can't do atomic
modesets if you try to reassign connectors.

One idea I have is that vgms would help compositors to play out a bunch of
standard scenarios, even automated. But that's not there yet, and every
compositor project needs to care beyond "boots on my laptop, ship it". No
idea that's even possible.
-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

[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110674

--- Comment #34 from ant...@gmx.de ---
I think this is not just affecting Vega 20 but also Vega 10 is now stuck on
memclock pstate 0 (167MHz) since kernel 5.1.

I assume this is related to fclk and defclk

-- 
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: [Freedreno] [PATCH] drm/msm/adreno: Ensure that the zap shader region is big enough

2019-06-03 Thread Jeffrey Hugo
On Fri, May 31, 2019 at 4:09 PM Jordan Crouse  wrote:
>
> Before loading the zap shader we should ensure that the reserved memory
> region is big enough to hold the loaded file.
>
> Signed-off-by: Jordan Crouse 

Reviewed-by: Jeffrey Hugo 

> ---
>
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 6f7f411..3db8e49 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -67,7 +67,6 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
> return ret;
>
> mem_phys = r.start;
> -   mem_size = resource_size();
>
> /* Request the MDT file for the firmware */
> fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> @@ -83,6 +82,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const 
> char *fwname,
> goto out;
> }
>
> +   if (mem_size > resource_size()) {
> +   DRM_DEV_ERROR(dev,
> +   "memory region is too small to load the MDT\n");
> +   ret = -E2BIG;
> +   goto out;
> +   }
> +
> /* Allocate memory for the firmware image */
> mem_region = memremap(mem_phys, mem_size,  MEMREMAP_WC);
> if (!mem_region) {
> --
> 2.7.4
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno


Re: [PATCH v3 2/6] drm/msm: add support for per-CRTC max_vblank_count on mdp5

2019-06-03 Thread Jeffrey Hugo
On Fri, May 31, 2019 at 3:46 AM Brian Masney  wrote:
>
> The mdp5 drm/kms driver currently does not work on command-mode DSI
> panels due to 'vblank wait timed out' errors. This causes a latency
> of seconds, or tens of seconds in some cases, before content is shown
> on the panel. This hardware does not have the something that we can use
> as a frame counter available when running in command mode, so we need to
> fall back to using timestamps by setting the max_vblank_count to zero.
> This can be done on a per-CRTC basis, so the convert mdp5 to use
> drm_crtc_set_max_vblank_count().
>
> This change was tested on a LG Nexus 5 (hammerhead) phone.
>
> Signed-off-by: Brian Masney 
> Suggested-by: Jeffrey Hugo 

Reviewed-by: Jeffrey Hugo 

> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 16 +++-
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  2 +-
>  2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> index c3751c95b452..6fde1097844f 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
> @@ -450,6 +450,18 @@ static void mdp5_crtc_atomic_disable(struct drm_crtc 
> *crtc,
> mdp5_crtc->enabled = false;
>  }
>
> +static void mdp5_crtc_vblank_on(struct drm_crtc *crtc)
> +{
> +   struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
> +   struct mdp5_interface *intf = mdp5_cstate->pipeline.intf;
> +   u32 count;
> +
> +   count = intf->mode == MDP5_INTF_DSI_MODE_COMMAND ? 0 : 0x;
> +   drm_crtc_set_max_vblank_count(crtc, count);
> +
> +   drm_crtc_vblank_on(crtc);
> +}
> +
>  static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
> struct drm_crtc_state *old_state)
>  {
> @@ -486,7 +498,7 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
> }
>
> /* Restore vblank irq handling after power is enabled */
> -   drm_crtc_vblank_on(crtc);
> +   mdp5_crtc_vblank_on(crtc);
>
> mdp5_crtc_mode_set_nofb(crtc);
>
> @@ -1039,6 +1051,8 @@ static void mdp5_crtc_reset(struct drm_crtc *crtc)
> mdp5_crtc_destroy_state(crtc, crtc->state);
>
> __drm_atomic_helper_crtc_reset(crtc, _cstate->base);
> +
> +   drm_crtc_vblank_reset(crtc);
>  }
>
>  static const struct drm_crtc_funcs mdp5_crtc_funcs = {
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 97179bec8902..fcb0b0455abe 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -750,7 +750,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> dev->driver->get_vblank_timestamp = 
> drm_calc_vbltimestamp_from_scanoutpos;
> dev->driver->get_scanout_position = mdp5_get_scanoutpos;
> dev->driver->get_vblank_counter = mdp5_get_vblank_counter;
> -   dev->max_vblank_count = 0x;
> +   dev->max_vblank_count = 0; /* max_vblank_count is set on each CRTC */
> dev->vblank_disable_immediate = true;
>
> return kms;
> --
> 2.20.1
>


Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Jordan Crouse
> It shouldn't be a problem to hook something else up to the IOMMU
> subsystem. Hopefully it's something that people are going to standardize
> on.
> 
> > 3) The automatic attach of DMA domain is also causing a different
> >problem for us on the GPU side, preventing us from supporting per-
> >context pagetables (since we end up with a disagreement about
> >which context bank is used between arm-smmu and the firmware).
> 
> I'm not sure I understand this issue. Is the context bank hard-coded in
> the firmware somehow? Or is it possible to rewrite which one is going to
> be used at runtime? Do you switch out the actual page tables rather than
> the IOMMU domains for context switching?
 
We have a rather long history on this but the tl;dr is that the GPU microcode
switches the pagetables by rewriting TTBR0 on the fly (since this is
arm-smmu-v2 we have no better option) and yes, unfortunately it is hard coded
to use context bank 0. [1] is the current patchset to support all this,
including my own take on avoiding the dma-domain (all the cool kids have one).

Jordan

[1] https://patchwork.freedesktop.org/series/57441/

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: unable to fetch the drm-intel-fixes tree

2019-06-03 Thread Stephen Rothwell
Hi Daniel,

On Mon, 3 Jun 2019 19:50:18 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 3 Jun 2019 09:31:03 +0200 Daniel Vetter  wrote:
> >
> > drm.git too I guess?  
> 
> No, I fetch that from git://git.freedesktop.org/ which seems to answer.
> 
> > But yeah fd.o anongit keeled over over the w/e :-( Admins not yet awake,
> > so can't tell you what's up.  
> 
> No worries, I will just keep using what I have previously fetched.

And they all look good now.

-- 
Cheers,
Stephen Rothwell


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

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 07:20:14AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding  
> wrote:
> >
> > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy  wrote:
> > > >
> > > > On 03/06/2019 11:47, Rob Clark wrote:
> > > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa  
> > > > > wrote:
> > > > >>
> > > > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark  wrote:
> > > > >>>
> > > > >>> So, another case I've come across, on the display side.. I'm working
> > > > >>> on handling the case where bootloader enables display (and takes 
> > > > >>> iommu
> > > > >>> out of reset).. as soon as DMA domain gets attached we get iommu
> > > > >>> faults, because bootloader has already configured display for 
> > > > >>> scanout.
> > > > >>> Unfortunately this all happens before actual driver is probed and 
> > > > >>> has
> > > > >>> a chance to intervene.
> > > > >>>
> > > > >>> It's rather unfortunate that we tried to be clever rather than just
> > > > >>> making drivers call some function to opt-in to the hookup of dma 
> > > > >>> iommu
> > > > >>> ops :-(
> > > > >>
> > > > >> I think it still works for the 90% of cases and if 10% needs some
> > > > >> explicit work in the drivers, that's better than requiring 100% of 
> > > > >> the
> > > > >> drivers to do things manually.
> > > >
> > > > Right, it's not about "being clever", it's about not adding opt-in code
> > > > to the hundreds and hundreds and hundreds of drivers which *might* ever
> > > > find themselves used on a system where they would need the IOMMU's help
> > > > for DMA.
> > >
> > > Well, I mean, at one point we didn't do the automatic iommu hookup, we
> > > could have just stuck with that and added a helper so drivers could
> > > request the hookup.  Things wouldn't have been any more broken than
> > > before, and when people bring up systems where iommu is required, they
> > > could have added the necessary dma_iommu_configure() call.  But that
> > > is water under the bridge now.
> > >
> > > > >> Adding Marek who had the same problem on Exynos.
> > > > >
> > > > > I do wonder how many drivers need to iommu_map in their ->probe()?
> > > > > I'm thinking moving the auto-hookup to after a successful probe(),
> > > > > with some function a driver could call if they need mapping in probe,
> > > > > might be a way to eventually get rid of the blacklist.  But I've no
> > > > > idea how to find the subset of drivers that would be broken without a
> > > > > dma_setup_iommu_stuff() call in their probe.
> > > >
> > > > Wouldn't help much. That particular issue is nothing to do with DMA ops
> > > > really, it's about IOMMU initialisation. On something like SMMUv3 there
> > > > is literally no way to turn the thing on without blocking unknown
> > > > traffic - it *has* to have stream table entries programmed before it can
> > > > even allow stuff to bypass.
> > >
> > > fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and
> > > db845c) the SMMU (v2) is taken out of bypass by the bootloader.  Bjorn
> > > has some patches for arm-smmu to read-back the state at boot.
> > >
> > > (Although older devices were booting with display enabled but SMMU in 
> > > bypass.)
> > >
> > > > The answer is either to either pay attention to the "Quiesce all DMA
> > > > capable devices" part of the boot protocol (which has been there since
> > > > pretty much forever), or to come up with some robust way of
> > > > communicating "live" boot-time mappings to IOMMU drivers so that they
> > > > can program themselves appropriately during probe.
> > >
> > > Unfortunately display lit up by bootloader is basically ubiquitous.
> > > Every single android phone does it.  All of the windows-arm laptops do
> > > it.  Basically 99.9% of things that have a display do it.  It's a
> > > tough problem to solve involving clks, gdsc, regulators, etc, in
> > > addition to the display driver.. and sadly now smmu.  And devices
> > > where we can make changes to and update the firmware are rather rare.
> > > So there is really no option to ignore this problem.
> >
> > I think this is going to require at least some degree of cooperation
> > from the bootloader. See my other thread on that. Unfortunately I think
> > this is an area where everyone has kind of been doing their own thing
> > even if standard bindings for this have been around for quite a while
> > (actually 5 years by now). I suspect that most bootloaders that run
> > today are not that old, but as always downstream doesn't follow closely
> > where upstream is guiding.
> >
> > > I guess if we had some early-quirks mechanism like x86 does, we could
> > > mash the display off early in boot.  That would be an easy solution.
> > > Although I'd prefer a proper solution so that android phones aren't
> > > carrying around enormous stacks of hack patches to achieve a smooth
> > > flicker-free boot.
> >
> > The proper solution, I think, is for bootloader and 

Re: [PATCH] drm/sched: Fix make htmldocs warnings.

2019-06-03 Thread Grodzovsky, Andrey

On 6/3/19 3:24 AM, Daniel Vetter wrote:
> On Thu, May 30, 2019 at 05:04:20PM +0200, Christian König wrote:
>> Am 29.05.19 um 21:36 schrieb Daniel Vetter:
>>> On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote:
 I don't, sorry.
>>> Should we fix that? Seems like you do plenty of scheduler stuff, so would
>>> make sense I guess ...
>> Reviewed-by: Christian König  for the patch.
>>
>> And +1 for giving Andrey commit rights to drm-misc-next.
> If Andrey is on board too, pls file an issue with the legacy ssh account
> requests template here:
> https://gitlab.freedesktop.org/freedesktop/freedesktop/
>
> And then ping on irc or here so drm-misc folks can ack
> -Daniel

Here is the ticket 
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/152

Andrey


>
>> Christian.
>>
>>> -Daniel
>>>
 Andrey

 On 5/29/19 12:42 PM, Alex Deucher wrote:
> On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky
>  wrote:
>> Signed-off-by: Andrey Grodzovsky 
> Reviewed-by: Alex Deucher 
>
> I'll push it to drm-misc in a minute unless you have commit rights.
>
> Alex
>
>> ---
>> drivers/gpu/drm/scheduler/sched_main.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index 49e7d07..c1058ee 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -353,6 +353,7 @@ EXPORT_SYMBOL(drm_sched_increase_karma);
>>  * drm_sched_stop - stop the scheduler
>>  *
>>  * @sched: scheduler instance
>> + * @bad: job which caused the time out
>>  *
>>  * Stop the scheduler and also removes and frees all completed jobs.
>>  * Note: bad job will not be freed as it might be used later and so 
>> it's
>> @@ -422,6 +423,7 @@ EXPORT_SYMBOL(drm_sched_stop);
>>  * drm_sched_job_recovery - recover jobs after a reset
>>  *
>>  * @sched: scheduler instance
>> + * @full_recovery: proceed with complete sched restart
>>  *
>>  */
>> void drm_sched_start(struct drm_gpu_scheduler *sched, bool 
>> full_recovery)
>> --
>> 2.7.4
>>
>> ___
>> 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] drm/docs: More links for implicit/explicit fencing.

2019-06-03 Thread Pekka Paalanen
On Mon,  3 Jun 2019 16:28:48 +0200
Daniel Vetter  wrote:

> drm_atomic_set_fence_for_plane() contains the main discussion from a
> driver pov, link to that from more places.
> 
> Cc: Pekka Paalanen 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++
>  include/drm/drm_plane.h  | 2 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 6fd48efe288c..6791245963c3 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -284,6 +284,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
>   * There is no need for _plane_helper_funcs.cleanup_fb hook for simple
>   * gem based framebuffer drivers which have their buffers always pinned in
>   * memory.
> + *
> + * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
> + * explicit fencing in atomic modeset updates.
>   */
>  int drm_gem_fb_prepare_fb(struct drm_plane *plane,
> struct drm_plane_state *state)
> @@ -314,6 +317,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
>   * _buf attached, extracts the exclusive fence and attaches it to plane
>   * state for the atomic helper to wait on. Drivers can use this as their
>   * _simple_display_pipe_funcs.prepare_fb callback.
> + *
> + * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
> + * explicit fencing in atomic modeset updates.
>   */
>  int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe 
> *pipe,
> struct drm_plane_state 
> *plane_state)
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 6078c700d9ba..cd5903ad33f7 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -69,7 +69,7 @@ struct drm_plane_state {
>*
>* Optional fence to wait for before scanning out @fb. The core atomic
>* code will set this when userspace is using explicit fencing. Do not
> -  * write this directly for a driver's implicit fence, use
> +  * write this field directly for a driver's implicit fence, use
>* drm_atomic_set_fence_for_plane() to ensure that an explicit fence is
>* preserved.
>*

Reviewed-by: Pekka Paalanen 
FWIW

Thanks!
pq


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

[PATCH] drm/docs: More links for implicit/explicit fencing.

2019-06-03 Thread Daniel Vetter
drm_atomic_set_fence_for_plane() contains the main discussion from a
driver pov, link to that from more places.

Cc: Pekka Paalanen 
Signed-off-by: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++
 include/drm/drm_plane.h  | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 6fd48efe288c..6791245963c3 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -284,6 +284,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
  * There is no need for _plane_helper_funcs.cleanup_fb hook for simple
  * gem based framebuffer drivers which have their buffers always pinned in
  * memory.
+ *
+ * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
+ * explicit fencing in atomic modeset updates.
  */
 int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state)
@@ -314,6 +317,9 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
  * _buf attached, extracts the exclusive fence and attaches it to plane
  * state for the atomic helper to wait on. Drivers can use this as their
  * _simple_display_pipe_funcs.prepare_fb callback.
+ *
+ * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
+ * explicit fencing in atomic modeset updates.
  */
 int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe 
*pipe,
  struct drm_plane_state 
*plane_state)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 6078c700d9ba..cd5903ad33f7 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -69,7 +69,7 @@ struct drm_plane_state {
 *
 * Optional fence to wait for before scanning out @fb. The core atomic
 * code will set this when userspace is using explicit fencing. Do not
-* write this directly for a driver's implicit fence, use
+* write this field directly for a driver's implicit fence, use
 * drm_atomic_set_fence_for_plane() to ensure that an explicit fence is
 * preserved.
 *
-- 
2.20.1

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

[Bug 109835] [865G] [drm] GPU HANG: ecode 2:0:0x75f4003e, in europa.exe [1323], reason: hang on rcs0, action: reset

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109835

rtent...@yandex.ru changed:

   What|Removed |Added

Version|unspecified |19.1

--- Comment #4 from rtent...@yandex.ru ---
Still here in 19.0.5 and 19.1.0-rc4.

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

[PATCH][next] drm/bridge: sii902x: fix comparision of u32 with less than zero

2019-06-03 Thread Colin King
From: Colin Ian King 

The less than check for the variable num_lanes is always going to be
false because the variable is a u32.  Fix this by making num_lanes an
int and also make loop index i an int too.

Addresses-Coverity: ("Unsigned compared against 0")
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/bridge/sii902x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index d6f98d388ac2..21a947603c88 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -719,7 +719,7 @@ static int sii902x_audio_codec_init(struct sii902x *sii902x,
.max_i2s_channels = 0,
};
u8 lanes[4];
-   u32 num_lanes, i;
+   int num_lanes, i;
 
if (!of_property_read_bool(dev->of_node, "#sound-dai-cells")) {
dev_dbg(dev, "%s: No \"#sound-dai-cells\", no audio\n",
-- 
2.20.1

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

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding  wrote:
>
> On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy  wrote:
> > >
> > > On 03/06/2019 11:47, Rob Clark wrote:
> > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa  wrote:
> > > >>
> > > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark  wrote:
> > > >>>
> > > >>> So, another case I've come across, on the display side.. I'm working
> > > >>> on handling the case where bootloader enables display (and takes iommu
> > > >>> out of reset).. as soon as DMA domain gets attached we get iommu
> > > >>> faults, because bootloader has already configured display for scanout.
> > > >>> Unfortunately this all happens before actual driver is probed and has
> > > >>> a chance to intervene.
> > > >>>
> > > >>> It's rather unfortunate that we tried to be clever rather than just
> > > >>> making drivers call some function to opt-in to the hookup of dma iommu
> > > >>> ops :-(
> > > >>
> > > >> I think it still works for the 90% of cases and if 10% needs some
> > > >> explicit work in the drivers, that's better than requiring 100% of the
> > > >> drivers to do things manually.
> > >
> > > Right, it's not about "being clever", it's about not adding opt-in code
> > > to the hundreds and hundreds and hundreds of drivers which *might* ever
> > > find themselves used on a system where they would need the IOMMU's help
> > > for DMA.
> >
> > Well, I mean, at one point we didn't do the automatic iommu hookup, we
> > could have just stuck with that and added a helper so drivers could
> > request the hookup.  Things wouldn't have been any more broken than
> > before, and when people bring up systems where iommu is required, they
> > could have added the necessary dma_iommu_configure() call.  But that
> > is water under the bridge now.
> >
> > > >> Adding Marek who had the same problem on Exynos.
> > > >
> > > > I do wonder how many drivers need to iommu_map in their ->probe()?
> > > > I'm thinking moving the auto-hookup to after a successful probe(),
> > > > with some function a driver could call if they need mapping in probe,
> > > > might be a way to eventually get rid of the blacklist.  But I've no
> > > > idea how to find the subset of drivers that would be broken without a
> > > > dma_setup_iommu_stuff() call in their probe.
> > >
> > > Wouldn't help much. That particular issue is nothing to do with DMA ops
> > > really, it's about IOMMU initialisation. On something like SMMUv3 there
> > > is literally no way to turn the thing on without blocking unknown
> > > traffic - it *has* to have stream table entries programmed before it can
> > > even allow stuff to bypass.
> >
> > fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and
> > db845c) the SMMU (v2) is taken out of bypass by the bootloader.  Bjorn
> > has some patches for arm-smmu to read-back the state at boot.
> >
> > (Although older devices were booting with display enabled but SMMU in 
> > bypass.)
> >
> > > The answer is either to either pay attention to the "Quiesce all DMA
> > > capable devices" part of the boot protocol (which has been there since
> > > pretty much forever), or to come up with some robust way of
> > > communicating "live" boot-time mappings to IOMMU drivers so that they
> > > can program themselves appropriately during probe.
> >
> > Unfortunately display lit up by bootloader is basically ubiquitous.
> > Every single android phone does it.  All of the windows-arm laptops do
> > it.  Basically 99.9% of things that have a display do it.  It's a
> > tough problem to solve involving clks, gdsc, regulators, etc, in
> > addition to the display driver.. and sadly now smmu.  And devices
> > where we can make changes to and update the firmware are rather rare.
> > So there is really no option to ignore this problem.
>
> I think this is going to require at least some degree of cooperation
> from the bootloader. See my other thread on that. Unfortunately I think
> this is an area where everyone has kind of been doing their own thing
> even if standard bindings for this have been around for quite a while
> (actually 5 years by now). I suspect that most bootloaders that run
> today are not that old, but as always downstream doesn't follow closely
> where upstream is guiding.
>
> > I guess if we had some early-quirks mechanism like x86 does, we could
> > mash the display off early in boot.  That would be an easy solution.
> > Although I'd prefer a proper solution so that android phones aren't
> > carrying around enormous stacks of hack patches to achieve a smooth
> > flicker-free boot.
>
> The proper solution, I think, is for bootloader and kernel to work
> together. Unfortunately that means we'll just have to bite the bullet
> and get things fixed across the stack. I think this is just the latest
> manifestation of the catch-up that upstream has been playing. Only now
> that we're starting to enable all of these features upstream are we
> running 

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy  wrote:
> >
> > On 03/06/2019 11:47, Rob Clark wrote:
> > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa  wrote:
> > >>
> > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark  wrote:
> > >>>
> > >>> So, another case I've come across, on the display side.. I'm working
> > >>> on handling the case where bootloader enables display (and takes iommu
> > >>> out of reset).. as soon as DMA domain gets attached we get iommu
> > >>> faults, because bootloader has already configured display for scanout.
> > >>> Unfortunately this all happens before actual driver is probed and has
> > >>> a chance to intervene.
> > >>>
> > >>> It's rather unfortunate that we tried to be clever rather than just
> > >>> making drivers call some function to opt-in to the hookup of dma iommu
> > >>> ops :-(
> > >>
> > >> I think it still works for the 90% of cases and if 10% needs some
> > >> explicit work in the drivers, that's better than requiring 100% of the
> > >> drivers to do things manually.
> >
> > Right, it's not about "being clever", it's about not adding opt-in code
> > to the hundreds and hundreds and hundreds of drivers which *might* ever
> > find themselves used on a system where they would need the IOMMU's help
> > for DMA.
> 
> Well, I mean, at one point we didn't do the automatic iommu hookup, we
> could have just stuck with that and added a helper so drivers could
> request the hookup.  Things wouldn't have been any more broken than
> before, and when people bring up systems where iommu is required, they
> could have added the necessary dma_iommu_configure() call.  But that
> is water under the bridge now.
> 
> > >> Adding Marek who had the same problem on Exynos.
> > >
> > > I do wonder how many drivers need to iommu_map in their ->probe()?
> > > I'm thinking moving the auto-hookup to after a successful probe(),
> > > with some function a driver could call if they need mapping in probe,
> > > might be a way to eventually get rid of the blacklist.  But I've no
> > > idea how to find the subset of drivers that would be broken without a
> > > dma_setup_iommu_stuff() call in their probe.
> >
> > Wouldn't help much. That particular issue is nothing to do with DMA ops
> > really, it's about IOMMU initialisation. On something like SMMUv3 there
> > is literally no way to turn the thing on without blocking unknown
> > traffic - it *has* to have stream table entries programmed before it can
> > even allow stuff to bypass.
> 
> fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and
> db845c) the SMMU (v2) is taken out of bypass by the bootloader.  Bjorn
> has some patches for arm-smmu to read-back the state at boot.
> 
> (Although older devices were booting with display enabled but SMMU in bypass.)
> 
> > The answer is either to either pay attention to the "Quiesce all DMA
> > capable devices" part of the boot protocol (which has been there since
> > pretty much forever), or to come up with some robust way of
> > communicating "live" boot-time mappings to IOMMU drivers so that they
> > can program themselves appropriately during probe.
> 
> Unfortunately display lit up by bootloader is basically ubiquitous.
> Every single android phone does it.  All of the windows-arm laptops do
> it.  Basically 99.9% of things that have a display do it.  It's a
> tough problem to solve involving clks, gdsc, regulators, etc, in
> addition to the display driver.. and sadly now smmu.  And devices
> where we can make changes to and update the firmware are rather rare.
> So there is really no option to ignore this problem.

I think this is going to require at least some degree of cooperation
from the bootloader. See my other thread on that. Unfortunately I think
this is an area where everyone has kind of been doing their own thing
even if standard bindings for this have been around for quite a while
(actually 5 years by now). I suspect that most bootloaders that run
today are not that old, but as always downstream doesn't follow closely
where upstream is guiding.

> I guess if we had some early-quirks mechanism like x86 does, we could
> mash the display off early in boot.  That would be an easy solution.
> Although I'd prefer a proper solution so that android phones aren't
> carrying around enormous stacks of hack patches to achieve a smooth
> flicker-free boot.

The proper solution, I think, is for bootloader and kernel to work
together. Unfortunately that means we'll just have to bite the bullet
and get things fixed across the stack. I think this is just the latest
manifestation of the catch-up that upstream has been playing. Only now
that we're starting to enable all of these features upstream are we
running into interoperability issues.

If upstream had been further along we would've caught these issues way
ahead of time and could've influenced the designs of bootloader much
earlier. Now, unless we get all the vendors to go back and 

Re: [PATCH v10 09/11] drm/sun4i: sun6i_mipi_dsi: Add VCC-DSI regulator support

2019-06-03 Thread Maxime Ripard
On Mon, May 20, 2019 at 02:33:16PM +0530, Jagan Teki wrote:
> Allwinner MIPI DSI controllers are supplied with SoC
> DSI power rails via VCC-DSI pin.
>
> Add support for this supply pin by adding voltage
> regulator handling code to MIPI DSI driver.
>
> Tested-by: Merlijn Wajer 
> Signed-off-by: Jagan Teki 

This creates a lot of warnings at boot time on my board this is
missing vcc-dsi-supply.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: drm_gem_dumb_map_offset patch

2019-06-03 Thread Daniel Vetter
On Mon, Jun 3, 2019 at 2:25 PM Pierre Yves MORDRET
 wrote:
>
> Hi all,
>
> Many thanks for your valuable support and answers.
>
> Since Dumb mmap is for buffer created using dumb_create ioctl we won't use it
> anymore. In place a mmap/ummap is called with DMA Buf FD.
> After some tests it seems working in our side.

Please note that with dma-buf you need to call the begin/end cpu
access ioctl, or depending upon driver/platform the mmap access might
be incoherent.
-Daniel

>
> Many thanks again.
> Regards.
>
> On 5/31/19 1:36 PM, Daniel Vetter wrote:
> > On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes  wrote:
> >>
> >> Hi,
> >>
> >> [add Daniel Vetter]
> >> [cc dri-devel]
> >>
> >> Den 29.05.2019 15.09, skrev Pierre Yves MORDRET:
> >>> Hello Noralf,
> >>>
> >>> Sorry for bothering you with question but I need to better understand the
> >>> rational about a patch you did in DRM/GEM.
> >>>
> >>> First of all, let me introduce myself.
> >>> I'm currently employee to STMicroelectronics company and in charge of GPU
> >>> integration within STM32 MPU (Cortex A7 + Cortex M4)
> >>>
> >>> On Cortex A7 is running a Linux Kernel 4.19 as for today.
> >>>
> >>> We came across some trouble when we switch from Kernel 4.14 to 4.19 for 
> >>> GPU
> >>> stack. On august you submit this commit :
> >>>
> >>>   90378e58919285637aa0f063c04ba0c6449d98b1
> >>>   drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
> >>>
> >>>   Reject mapping an imported dma-buf since is's an invalid 
> >>> use-case.
> >>>
> >>> In Userland GPU stack we have such statements :
> >>>bo_map_fd
> >>>DRM_IOCTL_MODE_MAP_DUMB
> >>>mmap (offset)
> >>>
> >>> With the patch above, ioctl returns an error EINVAL and prevents the nmap.
> >>> As for today we revert this patch and it works fine in our end.
> >
> > Link to source code would be good.
> >
> >>> Thus the questions are :
> >>>  - what is the rational behind this fix ?
> >>>  - What we doing wrong this situation ?
> >>>  - What do we need in such situation ?
> >>>
> >>
> >> I need to pass those on to Daniel Vetter (DRM maintainer) since he
> >> wanted the change. The details were never clear to me.
> >> Some of the discussion is here:
> >> https://patchwork.freedesktop.org/patch/172242/
> >
> > Dumb mmap is for buffer created using dumb_create ioctl, and nothing
> > else. Anything else really has at best undefined behaviour. E.g. for
> > dma-buf you really need to call the begin/end_cpu_access ioctl, and
> > dumb buffers simply have no provision for that. Hence why we can't
> > support this in general.
> >
> > Thanks, Daniel
> >



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Thierry Reding
On Mon, Jun 03, 2019 at 12:14:27PM +0100, Robin Murphy wrote:
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa  wrote:
> > > 
> > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark  wrote:
> > > > 
> > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark  wrote:
> > > > > 
> > > > > On Tue, Dec 4, 2018 at 2:29 PM Rob Herring  wrote:
> > > > > > 
> > > > > > On Sat, Dec 1, 2018 at 10:54 AM Rob Clark  
> > > > > > wrote:
> > > > > > > 
> > > > > > > This solves a problem we see with drm/msm, caused by getting
> > > > > > > iommu_dma_ops while we attach our own domain and manage it 
> > > > > > > directly at
> > > > > > > the iommu API level:
> > > > > > > 
> > > > > > >[0038] user address but active_mm is swapper
> > > > > > >Internal error: Oops: 9605 [#1] PREEMPT SMP
> > > > > > >Modules linked in:
> > > > > > >CPU: 7 PID: 70 Comm: kworker/7:1 Tainted: GW 
> > > > > > > 4.19.3 #90
> > > > > > >Hardware name: xxx (DT)
> > > > > > >Workqueue: events deferred_probe_work_func
> > > > > > >pstate: 80c9 (Nzcv daif +PAN +UAO)
> > > > > > >pc : iommu_dma_map_sg+0x7c/0x2c8
> > > > > > >lr : iommu_dma_map_sg+0x40/0x2c8
> > > > > > >sp : ff80095eb4f0
> > > > > > >x29: ff80095eb4f0 x28: 
> > > > > > >x27: ffc0f9431578 x26: 
> > > > > > >x25:  x24: 0003
> > > > > > >x23: 0001 x22: ffc0fa9ac010
> > > > > > >x21:  x20: ffc0fab40980
> > > > > > >x19: ffc0fab40980 x18: 0003
> > > > > > >x17: 01c4 x16: 0007
> > > > > > >x15: 000e x14: 
> > > > > > >x13:  x12: 0028
> > > > > > >x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
> > > > > > >x9 :  x8 : ffc0fab409a0
> > > > > > >x7 :  x6 : 0002
> > > > > > >x5 : 0001 x4 : 
> > > > > > >x3 : 0001 x2 : 0002
> > > > > > >x1 : ffc0f9431578 x0 : 
> > > > > > >Process kworker/7:1 (pid: 70, stack limit = 0x17d08ffb)
> > > > > > >Call trace:
> > > > > > > iommu_dma_map_sg+0x7c/0x2c8
> > > > > > > __iommu_map_sg_attrs+0x70/0x84
> > > > > > > get_pages+0x170/0x1e8
> > > > > > > msm_gem_get_iova+0x8c/0x128
> > > > > > > _msm_gem_kernel_new+0x6c/0xc8
> > > > > > > msm_gem_kernel_new+0x4c/0x58
> > > > > > > dsi_tx_buf_alloc_6g+0x4c/0x8c
> > > > > > > msm_dsi_host_modeset_init+0xc8/0x108
> > > > > > > msm_dsi_modeset_init+0x54/0x18c
> > > > > > > _dpu_kms_drm_obj_init+0x430/0x474
> > > > > > > dpu_kms_hw_init+0x5f8/0x6b4
> > > > > > > msm_drm_bind+0x360/0x6c8
> > > > > > > try_to_bring_up_master.part.7+0x28/0x70
> > > > > > > component_master_add_with_match+0xe8/0x124
> > > > > > > msm_pdev_probe+0x294/0x2b4
> > > > > > > platform_drv_probe+0x58/0xa4
> > > > > > > really_probe+0x150/0x294
> > > > > > > driver_probe_device+0xac/0xe8
> > > > > > > __device_attach_driver+0xa4/0xb4
> > > > > > > bus_for_each_drv+0x98/0xc8
> > > > > > > __device_attach+0xac/0x12c
> > > > > > > device_initial_probe+0x24/0x30
> > > > > > > bus_probe_device+0x38/0x98
> > > > > > > deferred_probe_work_func+0x78/0xa4
> > > > > > > process_one_work+0x24c/0x3dc
> > > > > > > worker_thread+0x280/0x360
> > > > > > > kthread+0x134/0x13c
> > > > > > > ret_from_fork+0x10/0x18
> > > > > > >Code: d284 91000725 6b17039f 5400048a (f9401f40)
> > > > > > >---[ end trace f22dda57f3648e2c ]---
> > > > > > >Kernel panic - not syncing: Fatal exception
> > > > > > >SMP: stopping secondary CPUs
> > > > > > >Kernel Offset: disabled
> > > > > > >CPU features: 0x0,22802a18
> > > > > > >Memory Limit: none
> > > > > > > 
> > > > > > > The problem is that when drm/msm does it's own 
> > > > > > > iommu_attach_device(),
> > > > > > > now the domain returned by iommu_get_domain_for_dev() is drm/msm's
> > > > > > > domain, and it doesn't have domain->iova_cookie.
> > > > > > > 
> > > > > > > We kind of avoided this problem prior to sdm845/dpu because the 
> > > > > > > iommu
> > > > > > > was attached to the mdp node in dt, which is a child of the 
> > > > > > > toplevel
> > > > > > > mdss node (which corresponds to the dev passed in dma_map_sg()).  
> > > > > > > But
> > > > > > > with sdm845, now the iommu is attached at the mdss level so we 
> > > > > > > hit the
> > > > > > > iommu_dma_ops in dma_map_sg().
> > > > > > > 
> > > > > > > But auto allocating/attaching a domain before the driver is 
> > > > > > > probed was
> > > > > > > already a blocking problem for enabling per-context pagetables 
> > > > > > > for the
> > > > > > > GPU.  This problem is also now solved with this patch.
> > > > > > > 
> > > > > > > 

[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #16 from Richard Thier  ---
Created attachment 144427
  --> https://bugs.freedesktop.org/attachment.cgi?id=144427=edit
Simple diff/patch to test the issue

See attached diff/patch for what I am trying as a quickfix and testing what
causes the issue. Not a "real fix" just supposed to be used for TESTING!!!

My suspection is that the change in the "r600_buffer_common.c" file might be
needed for other cards too for setting the flag for the faster code path but it
maybe happens only for r600 because it is in this file?!

That is only my wild guess so far and will test this with the lot of logging in
the patch... Only provided for those who want to understand my later logs I
provide after building a version with this patch in place.

-- 
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 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110823

--- Comment #3 from Chris Wilson  ---
(In reply to Martin Peres from comment #0)
> Hi, it looks like amdgpu's userptrs are now broken:
> 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-kbl-8809g/
> igt@amdgpu_amd_ba...@userptr.html
>   
> Starting subtest: userptr
> (amd_basic:3888) CRITICAL: Test assertion failure function
> amdgpu_userptr_test, file ../tests/amdgpu/amd_basic.c:1331:
> (amd_basic:3888) CRITICAL: Failed assertion: r == 0
> (amd_basic:3888) CRITICAL: Last errno: 19, No such device
> (amd_basic:3888) CRITICAL: error: -19 != 0

Is quite clear for a change.

Now one might argue that amdgpu changing the userptr ABI behind a non-default
config option from a default option is a bit mean...

-- 
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 110823] [Intel-GFX-CI][BAT] igt@amdgpu/amd_basic@userptr - fail - Failed assertion: r == 0

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110823

Chris Wilson  changed:

   What|Removed |Added

  Component|DRM/AMDgpu  |IGT

--- Comment #2 from Chris Wilson  ---
CI config error.

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

[PULL] drm-intel-fixes

2019-06-03 Thread Joonas Lahtinen
Hi Dave & Daniel,

Missed last week's window of opportunity due to trouble getting
CI results for Icelake. So this is against -rc2 still to avoid
re-doing the GVT pull third time.

Just a single Icelake W/A for i915. For GVT a fix for recently
seen arbitrary DMA map fault and more enforcement fixes.

I'll be on my summer vacation starting end of this week, so
Jani/Rodrigo will cover for the rest of the -rcs.

Regards, Joonas

***

drm-intel-fixes-2019-06-03:

- Add missing Icelake W/A to disable GPU hang on cache ECC error

The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:

  Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-06-03

for you to fetch changes up to afb286bcae85ee816e8497596bf8e7f83347f47b:

  Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2019-05-31 10:51:59 +0300)


- Add missing Icelake W/A to disable GPU hang on cache ECC error


Colin Xu (3):
  drm/i915/gvt: Update force-to-nonpriv register whitelist
  drm/i915/gvt: Fix GFX_MODE handling
  drm/i915/gvt: Fix vGPU CSFE_CHICKEN1_REG mmio handler

Gao, Fred (1):
  drm/i915/gvt: Fix cmd length of VEB_DI_IECP

Joonas Lahtinen (1):
  Merge tag 'gvt-fixes-2019-05-30' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Tina Zhang (1):
  drm/i915/gvt: Initialize intel_gvt_gtt_entry in stack

Tvrtko Ursulin (1):
  drm/i915/icl: Add WaDisableBankHangMode

Xiong Zhang (1):
  drm/i915/gvt: refine ggtt range validation

 drivers/gpu/drm/i915/gvt/cmd_parser.c|  2 +-
 drivers/gpu/drm/i915/gvt/gtt.c   | 26 +++
 drivers/gpu/drm/i915/gvt/handlers.c  | 36 +++-
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_workarounds.c |  6 ++
 5 files changed, 62 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 00/10] Add C8, 30bpp and FP16 support to modetest

2019-06-03 Thread Ilia Mirkin
On Mon, Jun 3, 2019 at 3:32 AM Daniel Vetter  wrote:
>
> On Sun, Jun 02, 2019 at 08:40:08PM -0400, Ilia Mirkin wrote:
> > This series improves the pattern generation logic to support additional
> > formats, as well as a new "gradient" pattern (see patch comments on why
> > I found it useful).
> >
> > Furthermore, these formats are piped through to modetest, including the
> > ability to set a gamma table, which is necessary for the C8 indexed
> > format.
> >
> > This was tested on nouveau, and used for bring-up of the C8, XB30, and
> > FP16 formats on the NVIDIA hardware that supports these.
>
> Does nouveau also work with igt tests for this stuff? We do have support
> for interactive testing (i.e. "human pls check yourself" kind of tests) in
> igt, so ideally we could merge everything into one place. Long-term at
> least ...

nouveau has no special exclusions for programs that start with the
letters "igt", so presumably it should be OK with the basic tests.
However it was my impression that igt was targeted at automated
testing, and all the tests basically required crc, which is
questionable whether it exists in the hw in a manner usable by such
tests, and definitely not supported by nouveau in any case. As a
result, I haven't really taken much of a look.

Having something flexible like modetest has been really useful in
development. Being able to run with different formats, messing with
resolutions, scaling parameters for overlays, different patterns --
these things have all been helpful in validating that the new features
implemented actually work as expected. I plan on extending it further
to cover HDR, as part of my bringup of HDR on nouveau.

As an example, pre-GF119 FP16 support expects a 0..1024-valued input
instead of 0..1 (something which we did not previously know). I was
able to guess that by changing the pattern in the code to generate
larger numbers, after seeing a black display with the 0..1 pattern. (I
may have also messed with the gamma ramp to see if it was "working" or
not - I forget already.) Having a tool that makes things like that
simple to investigate is pretty valuable to me.

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

Re: [PATCH] of/device: add blacklist for iommu dma_ops

2019-06-03 Thread Rob Clark
On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy  wrote:
>
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa  wrote:
> >>
> >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark  wrote:
> >>>
> >>> So, another case I've come across, on the display side.. I'm working
> >>> on handling the case where bootloader enables display (and takes iommu
> >>> out of reset).. as soon as DMA domain gets attached we get iommu
> >>> faults, because bootloader has already configured display for scanout.
> >>> Unfortunately this all happens before actual driver is probed and has
> >>> a chance to intervene.
> >>>
> >>> It's rather unfortunate that we tried to be clever rather than just
> >>> making drivers call some function to opt-in to the hookup of dma iommu
> >>> ops :-(
> >>
> >> I think it still works for the 90% of cases and if 10% needs some
> >> explicit work in the drivers, that's better than requiring 100% of the
> >> drivers to do things manually.
>
> Right, it's not about "being clever", it's about not adding opt-in code
> to the hundreds and hundreds and hundreds of drivers which *might* ever
> find themselves used on a system where they would need the IOMMU's help
> for DMA.

Well, I mean, at one point we didn't do the automatic iommu hookup, we
could have just stuck with that and added a helper so drivers could
request the hookup.  Things wouldn't have been any more broken than
before, and when people bring up systems where iommu is required, they
could have added the necessary dma_iommu_configure() call.  But that
is water under the bridge now.

> >> Adding Marek who had the same problem on Exynos.
> >
> > I do wonder how many drivers need to iommu_map in their ->probe()?
> > I'm thinking moving the auto-hookup to after a successful probe(),
> > with some function a driver could call if they need mapping in probe,
> > might be a way to eventually get rid of the blacklist.  But I've no
> > idea how to find the subset of drivers that would be broken without a
> > dma_setup_iommu_stuff() call in their probe.
>
> Wouldn't help much. That particular issue is nothing to do with DMA ops
> really, it's about IOMMU initialisation. On something like SMMUv3 there
> is literally no way to turn the thing on without blocking unknown
> traffic - it *has* to have stream table entries programmed before it can
> even allow stuff to bypass.

fwiw, on these sdm850 laptops (and I think sdm845 boards like mtp and
db845c) the SMMU (v2) is taken out of bypass by the bootloader.  Bjorn
has some patches for arm-smmu to read-back the state at boot.

(Although older devices were booting with display enabled but SMMU in bypass.)

> The answer is either to either pay attention to the "Quiesce all DMA
> capable devices" part of the boot protocol (which has been there since
> pretty much forever), or to come up with some robust way of
> communicating "live" boot-time mappings to IOMMU drivers so that they
> can program themselves appropriately during probe.

Unfortunately display lit up by bootloader is basically ubiquitous.
Every single android phone does it.  All of the windows-arm laptops do
it.  Basically 99.9% of things that have a display do it.  It's a
tough problem to solve involving clks, gdsc, regulators, etc, in
addition to the display driver.. and sadly now smmu.  And devices
where we can make changes to and update the firmware are rather rare.
So there is really no option to ignore this problem.

I guess if we had some early-quirks mechanism like x86 does, we could
mash the display off early in boot.  That would be an easy solution.
Although I'd prefer a proper solution so that android phones aren't
carrying around enormous stacks of hack patches to achieve a smooth
flicker-free boot.

I suppose arm-smmu could realize that the context bank is already
taken out of bypass..  although I'm not entirely sure if we can assume
that the CPU would be able to read back the pagetable setup by the
bootloader.  Maybe Vivek has an idea about that?

BR,
-R


[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #15 from Richard Thier  ---
It seems similar issues not only affect me then...

-- 
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 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #14 from Richard Thier  ---
Now seeing that the commit diff is actually small, I can put some printf logs
in place to see what is going on and where the code ends up.

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

[v2 3/3] video/hdmi: Dropped static functions from kernel doc

2019-06-03 Thread Uma Shankar
Dropped static functions from kernel documentation.

v2: Dropped the comments altogether for static functions,
as the definitions seems self explanatory.

Suggested-by: Daniel Vetter 
Signed-off-by: Uma Shankar 
---
 drivers/video/hdmi.c | 30 --
 1 file changed, 30 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b99ba01..b939bc2 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1191,12 +1191,6 @@ static const char *hdmi_nups_get_name(enum hdmi_nups 
nups)
return "Invalid";
 }
 
-/**
- * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe
- * @level: logging level
- * @dev: device
- * @frame: HDMI AVI infoframe
- */
 static void hdmi_avi_infoframe_log(const char *level,
   struct device *dev,
   const struct hdmi_avi_infoframe *frame)
@@ -1268,12 +1262,6 @@ static const char *hdmi_spd_sdi_get_name(enum 
hdmi_spd_sdi sdi)
return "Reserved";
 }
 
-/**
- * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe
- * @level: logging level
- * @dev: device
- * @frame: HDMI SPD infoframe
- */
 static void hdmi_spd_infoframe_log(const char *level,
   struct device *dev,
   const struct hdmi_spd_infoframe *frame)
@@ -1404,12 +1392,6 @@ static void hdmi_spd_infoframe_log(const char *level,
return "Reserved";
 }
 
-/**
- * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe
- * @level: logging level
- * @dev: device
- * @frame: HDMI AUDIO infoframe
- */
 static void hdmi_audio_infoframe_log(const char *level,
 struct device *dev,
 const struct hdmi_audio_infoframe *frame)
@@ -1437,12 +1419,6 @@ static void hdmi_audio_infoframe_log(const char *level,
frame->downmix_inhibit ? "Yes" : "No");
 }
 
-/**
- * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe
- * @level: logging level
- * @dev: device
- * @frame: HDMI DRM infoframe
- */
 static void hdmi_drm_infoframe_log(const char *level,
   struct device *dev,
   const struct hdmi_drm_infoframe *frame)
@@ -1500,12 +1476,6 @@ static void hdmi_drm_infoframe_log(const char *level,
return "Reserved";
 }
 
-/**
- * hdmi_vendor_infoframe_log() - log info of HDMI VENDOR infoframe
- * @level: logging level
- * @dev: device
- * @frame: HDMI VENDOR infoframe
- */
 static void
 hdmi_vendor_any_infoframe_log(const char *level,
  struct device *dev,
-- 
1.9.1

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

[v2 2/3] drm: Fix docbook warnings in hdr metadata helper structures

2019-06-03 Thread Uma Shankar
Fixes the following warnings:
./include/drm/drm_mode_config.h:841: warning: Incorrect use of
kernel-doc format:  * hdr_output_metadata_property: Connector
property containing hdr
./include/drm/drm_mode_config.h:918: warning: Function parameter or member 
'hdr_output_metadata_property' not described in 'drm_mode_config'
./include/drm/drm_connector.h:1251: warning: Function parameter or member 
'hdr_output_metadata' not described in 'drm_connector'
./include/drm/drm_connector.h:1251: warning: Function parameter or member 
'hdr_sink_metadata' not described in 'drm_connector'

Also adds some property documentation for HDR Metadata Connector
Property in connector property create function.

v2: Fixed Sean Paul's review comments.

v3: Fixed Daniel Vetter's review comments, added the UAPI structure
definition section in kernel docs.

v4: Fixed Daniel Vetter's review comments.

Cc: Shashank Sharma 
Cc: Ville Syrjä 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Bartlomiej Zolnierkiewicz 
Cc: "Ville Syrjä" 
Cc: Hans Verkuil 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Sean Paul 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_connector.c | 37 +
 include/drm/drm_connector.h |  1 +
 include/drm/drm_mode_config.h   |  4 +--
 include/linux/hdmi.h| 12 +++
 include/uapi/drm/drm_mode.h | 74 -
 5 files changed, 125 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c9ac8b9..c445d57 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -956,6 +956,43 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
  *   is no longer protected and userspace should take appropriate action
  *   (whatever that might be).
  *
+ * HDR_OUTPUT_METADATA:
+ * Connector property to enable userspace to send HDR Metadata to
+ * driver. This metadata is based on the composition and blending
+ * policies decided by user, taking into account the hardware and
+ * sink capabilities. The driver gets this metadata and creates a
+ * Dynamic Range and Mastering Infoframe (DRM) in case of HDMI,
+ * SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then
+ * sent to sink. This notifies the sink of the upcoming frame's Color
+ * Encoding and Luminance parameters.
+ *
+ * Userspace first need to detect the HDR capabilities of sink by
+ * reading and parsing the EDID. Details of HDR metadata for HDMI
+ * are added in CTA 861.G spec. For DP , its defined in VESA DP
+ * Standard v1.4. It needs to then get the metadata information
+ * of the video/game/app content which are encoded in HDR (basically
+ * using HDR transfer functions). With this information it needs to
+ * decide on a blending policy and compose the relevant
+ * layers/overlays into a common format. Once this blending is done,
+ * userspace will be aware of the metadata of the composed frame to
+ * be send to sink. It then uses this property to communicate this
+ * metadata to driver which then make a Infoframe packet and sends
+ * to sink based on the type of encoder connected.
+ *
+ * Userspace will be responsible to do Tone mapping operation in case:
+ * - Some layers are HDR and others are SDR
+ * - HDR layers luminance is not same as sink
+ * It will even need to do colorspace conversion and get all layers
+ * to one common colorspace for blending. It can use either GL, Media
+ * or display engine to get this done based on the capabilties of the
+ * associated hardware.
+ *
+ * Driver expects metadata to be put in _output_metadata structure
+ * from userspace. It parses EDID and saves the sink metadata in
+ * _sink_metadata. Driver uses _hdmi_infoframe_set_hdr_metadata
+ * helper to set the HDR metadata, _drm_infoframe_pack to pack the
+ * infoframe as per spec, in case of HDMI encoder.
+ *
  * max bpc:
  * This range property is used by userspace to limit the bit depth. When
  * used the driver would limit the bpc in accordance with the valid range
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5476561..47e749b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1244,6 +1244,7 @@ struct drm_connector {
 */
struct llist_node free_node;
 
+   /** @hdr_sink_metadata: HDR Metadata Information read from sink */
struct hdr_sink_metadata hdr_sink_metadata;
 };
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4f88cc9..759d462 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -837,8 +837,8 @@ struct drm_mode_config {
struct drm_property *writeback_out_fence_ptr_property;
 
/**
-  

[v2 0/3] Document fixes for DRM UAPI and HDR

2019-06-03 Thread Uma Shankar
This series adds DRM UAPI header structure documentation to kernel
docs. Fixes issues with existing structure documentation in drm
uapi header.

This also fixes warnings in HDR doc and addresses suggestions from
Daniel Vetter.

v2: 2 patches from v1 are merged. This series version adds remaining
on top of that. Addressed review comments from Daniel Vetter.

Uma Shankar (3):
  drm: ADD UAPI structure definition section in kernel doc
  drm: Fix docbook warnings in hdr metadata helper structures
  video/hdmi: Dropped static functions from kernel doc

 Documentation/gpu/drm-uapi.rst  |  9 +
 drivers/gpu/drm/drm_connector.c | 37 +
 drivers/video/hdmi.c| 30 -
 include/drm/drm_connector.h |  1 +
 include/drm/drm_mode_config.h   |  4 +--
 include/linux/hdmi.h| 12 +++
 include/uapi/drm/drm_mode.h | 74 -
 7 files changed, 134 insertions(+), 33 deletions(-)

-- 
1.9.1

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

[v2 1/3] drm: ADD UAPI structure definition section in kernel doc

2019-06-03 Thread Uma Shankar
Add a new section for UAPI structure and helper definitions
in kernel docbook.

Suggested-by: Daniel Vetter 
Signed-off-by: Uma Shankar 
---
 Documentation/gpu/drm-uapi.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index f368e58..94f9052 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL
 mode setting, since on many devices the vertical blank counter is
 reset to 0 at some point during modeset. Modern drivers should not
 call this any more since with kernel mode setting it is a no-op.
+
+Userspace API Structures
+
+
+.. kernel-doc:: include/uapi/drm/drm_mode.h
+   :doc: overview
+
+.. kernel-doc:: include/uapi/drm/drm_mode.h
+   :internal:
-- 
1.9.1

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

[Bug 110781] Radeon: heavy r300 performance drop regression between 11.x and 19.x

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110781

--- Comment #13 from Rui Salvaterra  ---
This is interesting. I have the exact same problem on an old Turion X2 laptop
I've been given. I attributed it to memory controller contention (since the GPU
resides in the northbridge and the memory controller is integrated on the CPU),
but it feels unusually slow, to the point I had to completely disable
compositing (I'm running Ubuntu MATE 19.04), whereas an even slower Eee PC 901
has no trouble at all running compiz.

In another note, according to the specs, the R300 _should_ be able to run
purely on modesetting/GLAMOR (I have a laptop with a Mobility Radeon X1600 and
128 MiB of VRAM running GLAMOR with only some very minor glitches), but the
graphics are completely corrupted. This doesn't happen when using the radeon
DDX.

-- 
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 2/4] drm: Fix docbook warnings in hdr metadata helper structures

2019-06-03 Thread Shankar, Uma


>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
>Daniel
>Vetter
>Sent: Monday, June 3, 2019 1:53 PM
>To: Shankar, Uma 
>Cc: Sean Paul ; linux-fb...@vger.kernel.org;
>dcasta...@chromium.org; jo...@kwiboo.se; Maxime Ripard
>; intel-...@lists.freedesktop.org; Bartlomiej
>Zolnierkiewicz ; emil.l.veli...@gmail.com; dri-
>de...@lists.freedesktop.org; Hans Verkuil ; David Airlie
>; seanp...@chromium.org
>Subject: Re: [PATCH 2/4] drm: Fix docbook warnings in hdr metadata helper 
>structures
>
>On Thu, May 30, 2019 at 01:29:02AM +0530, Uma Shankar wrote:
>> Fixes the following warnings:
>> ./include/drm/drm_mode_config.h:841: warning: Incorrect use of
>> kernel-doc format:  * hdr_output_metadata_property: Connector
>> property containing hdr
>> ./include/drm/drm_mode_config.h:918: warning: Function parameter or member
>'hdr_output_metadata_property' not described in 'drm_mode_config'
>> ./include/drm/drm_connector.h:1251: warning: Function parameter or member
>'hdr_output_metadata' not described in 'drm_connector'
>> ./include/drm/drm_connector.h:1251: warning: Function parameter or member
>'hdr_sink_metadata' not described in 'drm_connector'
>>
>> Also adds some property documentation for HDR Metadata Connector
>> Property in connector property create function.
>>
>> v2: Fixed Sean Paul's review comments.
>>
>> v3: Fixed Daniel Vetter's review comments, added the UAPI structure
>> definition section in kernel docs.
>>
>> Cc: Shashank Sharma 
>> Cc: Ville Syrjälä 
>> Cc: Maarten Lankhorst 
>> Cc: Maxime Ripard 
>> Cc: Sean Paul 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: Bartlomiej Zolnierkiewicz 
>> Cc: "Ville Syrjälä" 
>> Cc: Hans Verkuil 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: linux-fb...@vger.kernel.org
>> Reviewed-by: Sean Paul 
>> Signed-off-by: Uma Shankar 
>> ---
>>  Documentation/gpu/drm-uapi.rst  |  9 +
>> drivers/gpu/drm/drm_connector.c | 31 +++
>>  include/drm/drm_connector.h |  1 +
>>  include/drm/drm_mode_config.h   |  4 ++--
>>  include/linux/hdmi.h|  1 +
>>  include/uapi/drm/drm_mode.h | 37
>-
>>  6 files changed, 80 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/gpu/drm-uapi.rst
>> b/Documentation/gpu/drm-uapi.rst index 05874d0..6b39e2c 100644
>> --- a/Documentation/gpu/drm-uapi.rst
>> +++ b/Documentation/gpu/drm-uapi.rst
>> @@ -329,3 +329,12 @@ DRM_IOCTL_MODESET_CTL
>>  mode setting, since on many devices the vertical blank counter is
>>  reset to 0 at some point during modeset. Modern drivers should not
>>  call this any more since with kernel mode setting it is a no-op.
>> +
>> +Userspace API Structures
>> +
>> +
>> +.. kernel-doc:: include/uapi/drm/drm_mode.h
>> +   :doc: overview
>> +
>> +.. kernel-doc:: include/uapi/drm/drm_mode.h
>> +   :internal:
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index c9ac8b9..6a93527 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -956,6 +956,37 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>>   *is no longer protected and userspace should take appropriate action
>>   *(whatever that might be).
>>   *
>> + * HDR_OUTPUT_METADATA:
>> + *  Connector property to enable userspace to send HDR Metadata to
>> + *  driver. This metadata is based on the composition and blending
>> + *  policies decided by user, taking into account the hardware and
>> + *  sink capabilities. The driver gets this metadata and creates a
>> + *  Dynamic Range and Mastering Infoframe (DRM) in case of HDMI,
>> + *  SDP packet (Non-audio INFOFRAME SDP v1.3) for DP. This is then
>> + *  sent to sink. This notifies the sink of the upcoming frame's Color
>> + *  Encoding and Luminance parameters.
>> + *
>> + *  Userspace first need to detect the HDR capabilities of sink by
>> + *  reading and parsing the EDID. Details of HDR metadata for HDMI
>> + *  are added in CTA 861.G spec. For DP , its defined in VESA DP
>> + *  Standard v1.4. It needs to then get the metadata information
>> + *  of the video/game/app content which are encoded in HDR (basically
>> + *  using HDR transfer functions). With this information it needs to
>> + *  decide on a blending policy and compose the relevant
>> + *  layers/overlays into a common format. Once this blending is done,
>> + *  userspace will be aware of the metadata of the composed frame to
>> + *  be send to sink. It then uses this property to communicate this
>> + *  metadata to driver which then make a Infoframe packet and sends
>> + *  to sink based on the type of encoder connected.
>> + *
>> + *  Userspace will be responsible to do Tone mapping operation in case:
>> + *  - Some layers are HDR and others are SDR
>> + *  - HDR layers luminance is not same as sink
>> + *  It will even need to do 

RE: [PATCH 4/4] video/hdmi: Dropped static functions from kernel doc

2019-06-03 Thread Shankar, Uma


>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 3, 2019 1:55 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma, 
>Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se; dan...@ffwll.ch
>Subject: Re: [PATCH 4/4] video/hdmi: Dropped static functions from kernel doc
>
>On Thu, May 30, 2019 at 01:29:04AM +0530, Uma Shankar wrote:
>> Dropped static functions from kernel documentation.
>>
>> Suggested-by: Daniel Vetter 
>> Signed-off-by: Uma Shankar 
>> ---
>>  drivers/video/hdmi.c | 32 
>>  1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index
>> b99ba01..72c654b 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -1191,11 +1191,11 @@ static const char *hdmi_nups_get_name(enum
>hdmi_nups nups)
>>  return "Invalid";
>>  }
>>
>> -/**
>> +/*
>>   * hdmi_avi_infoframe_log() - log info of HDMI AVI infoframe
>> - * @level: logging level
>> - * @dev: device
>> - * @frame: HDMI AVI infoframe
>> + * level: logging level
>> + * dev: device
>> + * frame: HDMI AVI infoframe
>>   */
>>  static void hdmi_avi_infoframe_log(const char *level,
>> struct device *dev,
>> @@ -1268,11 +1268,11 @@ static const char *hdmi_spd_sdi_get_name(enum
>hdmi_spd_sdi sdi)
>>  return "Reserved";
>>  }
>>
>> -/**
>> +/*
>>   * hdmi_spd_infoframe_log() - log info of HDMI SPD infoframe
>> - * @level: logging level
>> - * @dev: device
>> - * @frame: HDMI SPD infoframe
>> + * level: logging level
>> + * dev: device
>> + * frame: HDMI SPD infoframe
>>   */
>
>For internal functions I think there's not really any value in documenting 
>this. The
>variable names are obvious enough. Imo better to ditch this outright.

Ok, will drop the comments from all these static functions.

Regards,
Uma Shankar

>-Daniel
>
>>  static void hdmi_spd_infoframe_log(const char *level,
>> struct device *dev,
>> @@ -1404,11 +1404,11 @@ static void hdmi_spd_infoframe_log(const char *level,
>>  return "Reserved";
>>  }
>>
>> -/**
>> +/*
>>   * hdmi_audio_infoframe_log() - log info of HDMI AUDIO infoframe
>> - * @level: logging level
>> - * @dev: device
>> - * @frame: HDMI AUDIO infoframe
>> + * level: logging level
>> + * dev: device
>> + * frame: HDMI AUDIO infoframe
>>   */
>>  static void hdmi_audio_infoframe_log(const char *level,
>>   struct device *dev,
>> @@ -1437,11 +1437,11 @@ static void hdmi_audio_infoframe_log(const char
>*level,
>>  frame->downmix_inhibit ? "Yes" : "No");  }
>>
>> -/**
>> +/*
>>   * hdmi_drm_infoframe_log() - log info of HDMI DRM infoframe
>> - * @level: logging level
>> - * @dev: device
>> - * @frame: HDMI DRM infoframe
>> + * level: logging level
>> + * dev: device
>> + * frame: HDMI DRM infoframe
>>   */
>>  static void hdmi_drm_infoframe_log(const char *level,
>> struct device *dev,
>> --
>> 1.9.1
>>
>
>--
>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 3/4] drm: Fixed doc warnings in drm uapi header

2019-06-03 Thread Shankar, Uma


>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 3, 2019 1:56 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma, 
>Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se; dan...@ffwll.ch
>Subject: Re: [PATCH 3/4] drm: Fixed doc warnings in drm uapi header
>
>On Thu, May 30, 2019 at 01:29:03AM +0530, Uma Shankar wrote:
>> Fixed doc warnings in drm uapi header. All the UAPI structures are now
>> documented in kernel doc.
>>
>> Signed-off-by: Uma Shankar 
>
>Applied, thanks for the patch.
>
>Long-term there's obviously a lot more to do here, but this at least gets us 
>started.
>
>Btw I think it'd be good to split out the "add new uapi ioctl structures 
>section" part
>from the previous patch, and merge that separately.

Ok, will do the same.

Regards,
Uma Shankar

>Thanks, Daniel
>
>> ---
>>  include/uapi/drm/drm_mode.h | 22 ++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> index 5d3964f..02b2a2b 100644
>> --- a/include/uapi/drm/drm_mode.h
>> +++ b/include/uapi/drm/drm_mode.h
>> @@ -861,6 +861,10 @@ struct drm_format_modifier {  };
>>
>>  /**
>> + * struct drm_mode_create_blob - Create New block property
>> + * @data: Pointer to data to copy.
>> + * @length: Length of data to copy.
>> + * @blob_id: new property ID.
>>   * Create a new 'blob' data property, copying length bytes from data 
>> pointer,
>>   * and returning new blob ID.
>>   */
>> @@ -874,6 +878,8 @@ struct drm_mode_create_blob {  };
>>
>>  /**
>> + * struct drm_mode_destroy_blob - Destroy user blob
>> + * @blob_id: blob_id to destroy
>>   * Destroy a user-created blob property.
>>   */
>>  struct drm_mode_destroy_blob {
>> @@ -881,6 +887,12 @@ struct drm_mode_destroy_blob {  };
>>
>>  /**
>> + * struct drm_mode_create_lease - Create lease
>> + * @object_ids: Pointer to array of object ids.
>> + * @object_count: Number of object ids.
>> + * @flags: flags for new FD.
>> + * @lessee_id: unique identifier for lessee.
>> + * @fd: file descriptor to new drm_master file.
>>   * Lease mode resources, creating another drm_master.
>>   */
>>  struct drm_mode_create_lease {
>> @@ -898,6 +910,10 @@ struct drm_mode_create_lease {  };
>>
>>  /**
>> + * struct drm_mode_list_lessees - List lessees
>> + * @count_lessees: Number of lessees.
>> + * @pad: pad.
>> + * @lessees_ptr: Pointer to lessess.
>>   * List lesses from a drm_master
>>   */
>>  struct drm_mode_list_lessees {
>> @@ -918,6 +934,10 @@ struct drm_mode_list_lessees {  };
>>
>>  /**
>> + * struct drm_mode_get_lease - Get Lease
>> + * @count_objects: Number of leased objects.
>> + * @pad: pad.
>> + * @objects_ptr: Pointer to objects.
>>   * Get leased objects
>>   */
>>  struct drm_mode_get_lease {
>> @@ -938,6 +958,8 @@ struct drm_mode_get_lease {  };
>>
>>  /**
>> + * struct drm_mode_revoke_lease - Revoke lease
>> + * @lessee_id: Unique ID of lessee.
>>   * Revoke lease
>>   */
>>  struct drm_mode_revoke_lease {
>> --
>> 1.9.1
>>
>
>--
>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 1/4] drm: Drop a redundant unused variable

2019-06-03 Thread Shankar, Uma


>-Original Message-
>From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, June 3, 2019 1:42 PM
>To: Shankar, Uma 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>maarten.lankho...@linux.intel.com; ville.syrj...@linux.intel.com; Sharma, 
>Shashank
>; emil.l.veli...@gmail.com; brian.star...@arm.com;
>dcasta...@chromium.org; seanp...@chromium.org; Roper, Matthew D
>; jo...@kwiboo.se; dan...@ffwll.ch
>Subject: Re: [PATCH 1/4] drm: Drop a redundant unused variable
>
>On Thu, May 30, 2019 at 01:29:01AM +0530, Uma Shankar wrote:
>> Drop a redundant and unused variable "hdr_output_metadata" from
>> drm_connector.
>>
>> Suggested-by: Daniel Vetter 
>> Signed-off-by: Uma Shankar 
>
>For next time around: Please add Fixes: lines to indicate which already merged
>commit you're improving.

Thanks Daniel. Sure, will take care of that in future.

Regards,
Uma Shankar

>Patch merged, thanks.
>-Daniel
>
>> ---
>>  include/drm/drm_connector.h | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index f8f4003..5476561 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -1244,8 +1244,6 @@ struct drm_connector {
>>   */
>>  struct llist_node free_node;
>>
>> -/* HDR metdata */
>> -struct hdr_output_metadata hdr_output_metadata;
>>  struct hdr_sink_metadata hdr_sink_metadata;  };
>>
>> --
>> 1.9.1
>>
>
>--
>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 v3 08/10] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1

2019-06-03 Thread Simon Horman
On Tue, May 28, 2019 at 05:12:32PM +0300, Laurent Pinchart wrote:
> Add the new renesas,companion property to the LVDS0 node to point to the
> companion LVDS encoder LVDS1.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Jacopo Mondi 
> Tested-by: Jacopo Mondi 

Hi Laurent,

is this patch ready to be merged?


[Bug 110674] Crashes / Resets From AMDGPU / Radeon VII

2019-06-03 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110674

--- Comment #33 from Tom B  ---
is this likely to be fixed in 5.2 or before? It's a showstopping bug for those
affected.

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

  1   2   >