RE: [PATCH v14 04/33] drm/i915: MEI interface implementation

[C, Ramalingam]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, February 21, 2019 1:10 AM
> To: C, Ramalingam 
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma 
> Subject: Re: [PATCH v14 04/33] drm/i915: MEI interface implementation
> 
> On Sat, Feb 16, 2019 at 11:06:51PM +0530, Ramalingam C wrote:
> > Defining the mei-i915 interface functions and initialization of the
> > interface.
> >
> > v2:
> >   Adjust to the new interface changes. [Tomas]
> >   Added further debug logs for the failures at MEI i/f.
> >   port in hdcp_port data is equipped to handle -ve values.
> > v3:
> >   mei comp is matched for global i915 comp master. [Daniel]
> >   In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
> >   mei wrappers are adjusted as per the i/f change [Daniel]
> > v4:
> >   port initialization is done only at hdcp2_init only [Danvet]
> > v5:
> >   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> > v6:
> >   HDCP_disable for all connectors incase of comp_unbind.
> >   Tear down HDCP comp interface at i915_unload [Daniel]
> > v7:
> >   Component init and fini are moved out of connector ops [Daniel]
> >   hdcp_disable is not called from unbind. [Daniel]
> > v8:
> >   subcomponent name is dropped as it is already merged.
> >
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter  [v11]
> 
> I think that r-b was for v7, not v8, and v11 of this patch doesn't even 
> exist. Series
> itself is as v14. Anyways, merged, thanks for all your work!

Thanks Daniel. Series version at which R-b was received for the original patch 
was captured here.
But yes. Should have captured the patch version instead.

-Ram
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c|   1 +
> >  drivers/gpu/drm/i915/i915_drv.h|   7 +
> >  drivers/gpu/drm/i915/intel_connector.c |   2 +
> >  drivers/gpu/drm/i915/intel_display.c   |   4 +
> >  drivers/gpu/drm/i915/intel_drv.h   |   8 +
> >  drivers/gpu/drm/i915/intel_hdcp.c  | 398
> -
> >  6 files changed, 419 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c index 6630212f2faf..c6354f6cdbdb
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv)
> > mutex_init(_priv->av_mutex);
> > mutex_init(_priv->wm.wm_mutex);
> > mutex_init(_priv->pps_mutex);
> > +   mutex_init(_priv->hdcp_comp_mutex);
> >
> > i915_memcpy_init_early(dev_priv);
> > intel_runtime_pm_init_early(dev_priv);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 5c8d0489a1cd..d375d1cf86f5
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -55,6 +55,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "i915_fixed.h"
> >  #include "i915_params.h"
> > @@ -2052,6 +2053,12 @@ struct drm_i915_private {
> >
> > struct i915_pmu pmu;
> >
> > +   struct i915_hdcp_comp_master *hdcp_master;
> > +   bool hdcp_comp_added;
> > +
> > +   /* Mutex to protect the above hdcp component related values. */
> > +   struct mutex hdcp_comp_mutex;
> > +
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> >  * will be rejected. Instead look for a better place.
> > diff --git a/drivers/gpu/drm/i915/intel_connector.c
> > b/drivers/gpu/drm/i915/intel_connector.c
> > index ee16758747c5..66ed3ee5998a 100644
> > --- a/drivers/gpu/drm/i915/intel_connector.c
> > +++ b/drivers/gpu/drm/i915/intel_connector.c
> > @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector
> > *connector)
> >
> > kfree(intel_connector->detect_edid);
> >
> > +   intel_hdcp_cleanup(intel_connector);
> > +
> > if (!IS_ERR_OR_NULL(intel_connector->edid))
> > kfree(intel_connector->edid);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 73a107b6eb9a..acb993ce7eaa 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15453,6 +15453,8 @@ int intel_modeset_init(struct drm_device *dev)
> > intel_update_czclk(dev_priv);
> > intel_modeset_init_hw(dev);
> >
> > +   intel_hdcp_component_init(dev_priv);
> > +
> > if (dev_priv->max_cdclk_freq == 0)
> > intel_update_max_cdclk(dev_priv);
> >
> > @@ -16314,6 +16316,8 @@ void intel_modeset_cleanup(struct drm_device
> *dev)
> > /* flush any delayed tasks or pending work */
> > flush_scheduled_work();
> >
> > +   intel_hdcp_component_fini(dev_priv);
> > +
> > drm_mode_config_cleanup(dev);
> >
> > intel_overlay_cleanup(dev_priv);
> > diff --git 

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On Wed, 2019-02-20 at 19:23 +, Kuehling, Felix wrote:
> On 2019-02-20 1:41 a.m., Thomas Hellstrom wrote:
> > On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
> > > On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> > > > On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> > > > > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > > > > > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> > > > > > > Another good question is also why the heck the acc_size
> > > > > > > counts
> > > > > > > towards
> > > > > > > the DMA32 zone?
> > > > > > DMA32 TTM pages are accounted in the DMA32 zone. Other
> > > > > > pages
> > > > > > are
> > > > > > not.
> > > > > Yeah, I'm perfectly aware of this. But this is for the
> > > > > accounting
> > > > > size!
> > > > > 
> > > > > We have an accounting for the stuff needed additional to the
> > > > > pages
> > > > > backing the BO (e.g. the page and DMA addr array).
> > > > > 
> > > > > And from the bug description it sounds like we use the DMA32
> > > > > zone
> > > > > for
> > > > > this accounting which of course is completely nonsense.
> > > > It's actually accounted in all available zones, since it would
> > > > be
> > > > pretty hard to determine exactly where that memory should be
> > > > accounted.
> > > > In particular if it's vmalloced. It might be DMA32, it might
> > > > not.
> > > > Given
> > > > the objective of stopping malicious user-space from exhausting
> > > > the
> > > > DMA32 zone it was, at the time the code was written, a
> > > > reasonable
> > > > approximation. With ever increasing memory sizes, there might
> > > > be
> > > > better
> > > > solutions?
> > > As far as I can see, in TTM, ttm_mem_global_alloc is only used
> > > for
> > > the
> > > acc_size in ttm_bo_init_reserved. Other than that vmwgfx also
> > > seems
> > > to
> > > use it to account for a few things that are allocated with
> > > kmalloc.
> > > 
> > > So would a better solution be to change ttm_mem_global_alloc to
> > > use
> > > only
> > > the kernel zone?
> > > 
> > IMO we need to determine what functionality to keep and then the
> > best
> > solution. The current code does its job, but is obviously too
> > restrictive. Both of the solutions you suggest open up for
> > potential
> > DOS attacks (DMA32 and kernel zones are not mutually exclusive.
> > They
> > overlap).
> On x86 with HIGHMEM there is no dma32 zone. Why do we need one on 
> x86_64? Can we make x86_64 more like HIGHMEM instead?
> 
> Regards,
>Felix
> 

IIRC with x86, the kernel zone is always smaller than any dma32 zone,
so we'd always exhaust the kernel zone before dma32 anyway.

Not sure why we have dma32 on x86 without highmem, though. sounds
superflous but harmless.

/Thomas



> 
> > 
> > /Thomas
> > 
> > 
> > 
> > 
> > > Regards,
> > > Felix
> > > 
> > > 
> > > > /Thomas
> > > > 
> > > > > Christian.
> > > > > 
> > > > > > For small persistent allocations using
> > > > > > ttm_mem_global_alloc(),
> > > > > > they
> > > > > > are
> > > > > > accounted also in the DMA32 zone, which may cause over-
> > > > > > accounting
> > > > > > of
> > > > > > that zone, but that's pretty unlikely to be a big problem..
> > > > > > 
> > > > > > /Thomas
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > In other words why should the internal bookkeeping pages
> > > > > > > be
> > > > > > > allocated
> > > > > > > in
> > > > > > > the DMA32 zone?
> > > > > > > 
> > > > > > > That doesn't sounds valid to me in any way,
> > > > > > > Christian.
> > > > > > > 
> > > > > > > Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> > > > > > > > Hmm,
> > > > > > > > 
> > > > > > > > This zone was intended to stop TTM page allocations
> > > > > > > > from
> > > > > > > > exhausting
> > > > > > > > the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> > > > > > > > default,
> > > > > > > > which
> > > > > > > > means if we drop this check, other devices may stop
> > > > > > > > functioning
> > > > > > > > unexpectedly?
> > > > > > > > 
> > > > > > > > However, in the end I'd expect the kernel page
> > > > > > > > allocation
> > > > > > > > system
> > > > > > > > to
> > > > > > > > make sure there are some pages left in the DMA32 zone,
> > > > > > > > otherwise
> > > > > > > > random non-IO page allocations would also potentially
> > > > > > > > exhaust
> > > > > > > > the
> > > > > > > > DMA32 zone without anybody caring, which means removing
> > > > > > > > this
> > > > > > > > zone
> > > > > > > > wouldn't be any worse than whatever other subsystems
> > > > > > > > may be
> > > > > > > > doing
> > > > > > > > already...
> > > > > > > > 
> > > > > > > > /Thomas
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 2/16/19 12:02 AM, Kuehling, Felix wrote:
> > > > > > > > > This is an RFC. I'm not sure this is the right
> > > > > > > > > solution,
> > > > > > > > > but
> > > > > > > > > it
> > > > > > > > > highlights the problem I'm trying to solve.
> > > > > > > > > 
> > > > > 

Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Vasily Khoruzhick]

On Tue, Feb 19, 2019 at 12:56 AM Maxime Ripard
 wrote:
>
> On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
> > On Mon, Feb 18, 2019 at 10:26 AM Rob Herring  wrote:
> > >
> > > On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
> > > > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > > > Validate the clock rate") prevents some panel and bridges from working 
> > > > with
> > > > sun4i driver.
> > >
> > > Sounds lile a regression that should be reverted. The fix is not a
> > > backwards compatible change either.
> >
> > anx6345 driver isn't mainlined yet and I'm not sure if this change
> > breaks any mainlined boards. So likely there's not enough
> > justification to revert it.
> >
> > > > Unfortunately, dotclock frequency for some modes are not achievable on
> > > > sunxi hardware, and there's a slight deviation in rate returned by
> > > > clk_round_rate(), so they fail this check.
> > > >
> > > > Experiments show that panels and bridges work fine with this slight
> > > > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > > > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works 
> > > > just
> > > > fine.
> > > >
> > > > This patch adds DT property to disable strict clock rate check
> > > >
> > > > Signed-off-by: Vasily Khoruzhick 
> > > > ---
> > > >  .../devicetree/bindings/display/sunxi/sun4i-drm.txt  | 2 ++
> > > >  drivers/gpu/drm/sun4i/sun4i_rgb.c| 5 +
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 3 +++
> > > >  drivers/gpu/drm/sun4i/sun4i_tcon.h   | 1 +
> > > >  4 files changed, 11 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > index f426bdb42f18..18c8b053a28d 100644
> > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > @@ -63,6 +63,8 @@ Required properties:
> > > >  Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > > >  first port should be the input endpoint. The second should be the
> > > >  output, usually to an HDMI connector.
> > > > +  - no-strict-clock-check: don't reject timings if exact dot clock 
> > > > can't be
> > > > +reached.
> > >
> > > This should be the default IMO. Most panels are a single timing, so if
> > > we reject it the fallback no display?
> >
> > As far as I remember the change was introduced to reject some modes
> > for which dotclock can't be reached when driver is used with VGA
> > bridge. So if we make it default it'll break boards with VGA bridge
> > and old DT.
> >
> > > I thought we had some mechanism already to allow some range of
> > > frequencies. I think the chromeos guys needed something IIRC.
> >
> > You can specify frequency range for panels, but there's nothing for
> > bridges. In my case EDID doesn't specify clock tolerance.
>
> I gave it some more though, and came up with the following patch. The
> basic idea is to leave the boundary check for the bridges that will
> have EDID and we need to filter out the modes that have no chance of
> being supported. The tolerancy used is the one defined in VESA specs,
> but I added a module parameter if you wanted to tune that.
>
> And finally, since most of our panels are single timings without any
> tolerancy, we just try our best in this case and that's it, while
> leaving the door open to support display_timings and being able to do
> more once we have an idea of what the tolerancies are.
>
> If that works for you, I'll submit it.
>
> Maxime
>
> --- >8 ---
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index f4a22689eb54..0460146aab75 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -43,6 +43,25 @@ drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
> encoder);
>  }
>
> +static inline struct drm_connector *
> +sun4i_rgb_get_connector_from_encoder(const struct drm_encoder *encoder)
> +{
> +   struct drm_connector *connector = NULL, *tmp;
> +   struct drm_connector_list_iter iter;
> +
> +   drm_connector_list_iter_begin(encoder->dev, );
> +   drm_for_each_connector_iter(tmp, )
> +   if (tmp->encoder == encoder) {
> +   connector = tmp;
> +   goto out;
> +   }
> +
> +out:
> +   drm_connector_list_iter_end();
> +
> +   return connector;
> +}
> +
>  static int sun4i_rgb_get_modes(struct drm_connector *connector)
>  {
> struct sun4i_rgb *rgb =
> @@ -52,11 +71,22 @@ static int sun4i_rgb_get_modes(struct drm_connector 
> *connector)
> return drm_panel_get_modes(tcon->panel);
>  }
>
> +/*
> + * VESA DMT defines a tolerancy of 0.5% 

[EARLY RFC][PATCH 1/4] dma-buf: Add dma-buf pools framework

[John Stultz]

This patch introduces the dma-buf pools framework.

This framework allows for different pool implementations to be
created, which act as dma-buf exporters, allowing userland to
allocate specific types of memory for use in dma-buf sharing.

This resembles the Android ION framework in that it takes that
code and renames most of the variables. (Following Rafael
Wysocki's earlier theory that the "easiest way to sell a once
rejected feature is to advertise it under a different name" :)

However, the API has been greatly simplified compared to ION.
This patchset extends some of my (and Benjamin's) earlier work
with the ION per-heap device nodes.

Each pool (previously "heap" in ION) has its own device node,
which one can allocate from using the DMABUF_POOL_IOC_ALLOC
which is very similar to the ION_IOC_ALLOC call.

There is no equivalent ION_IOC_HEAP_QUERY interface, as the
pools all have their own device nodes.

Additionally, any unused code from ION was removed.

NOTE: Reworked the per-pool devices to create a proper class so
Android can have a nice /dev/dmabuf_pools/ directory. Its working
but I'm almost sure if I did it wrong, as its much more complex
then just using a miscdevice. Extra review would be helpful.

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 MAINTAINERS  |  13 +
 drivers/dma-buf/Kconfig  |   2 +
 drivers/dma-buf/Makefile |   1 +
 drivers/dma-buf/pools/Kconfig|  10 +
 drivers/dma-buf/pools/Makefile   |   2 +
 drivers/dma-buf/pools/dmabuf-pools.c | 670 +++
 drivers/dma-buf/pools/dmabuf-pools.h | 244 +
 drivers/dma-buf/pools/pool-helpers.c | 317 +
 drivers/dma-buf/pools/pool-ioctl.c   |  94 +
 include/uapi/linux/dmabuf-pools.h|  59 +++
 10 files changed, 1412 insertions(+)
 create mode 100644 drivers/dma-buf/pools/Kconfig
 create mode 100644 drivers/dma-buf/pools/Makefile
 create mode 100644 drivers/dma-buf/pools/dmabuf-pools.c
 create mode 100644 drivers/dma-buf/pools/dmabuf-pools.h
 create mode 100644 drivers/dma-buf/pools/pool-helpers.c
 create mode 100644 drivers/dma-buf/pools/pool-ioctl.c
 create mode 100644 include/uapi/linux/dmabuf-pools.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e798ce..6bc3ab0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4614,6 +4614,19 @@ F:   include/linux/*fence.h
 F: Documentation/driver-api/dma-buf.rst
 T: git git://anongit.freedesktop.org/drm/drm-misc
 
+DMA-BUF POOLS FRAMEWORK
+M: Laura Abbott 
+R: Liam Mark 
+R: Brian Starkey 
+R: "Andrew F. Davis" 
+R: John Stultz 
+S: Maintained
+L: linux-me...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
+F: drivers/dma-buf/pools/*
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
 M: Vinod Koul 
 L: dmaeng...@vger.kernel.org
diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 2e5a0fa..c746510 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -39,4 +39,6 @@ config UDMABUF
  A driver to let userspace turn memfd regions into dma-bufs.
  Qemu can use this to create host dmabufs for guest framebuffers.
 
+source "drivers/dma-buf/pools/Kconfig"
+
 endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6c..9c295df 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
 obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-y  += pools/
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
 obj-$(CONFIG_UDMABUF)  += udmabuf.o
diff --git a/drivers/dma-buf/pools/Kconfig b/drivers/dma-buf/pools/Kconfig
new file mode 100644
index 000..caa7eb8
--- /dev/null
+++ b/drivers/dma-buf/pools/Kconfig
@@ -0,0 +1,10 @@
+menuconfig DMABUF_POOLS
+   bool "DMA-BUF Userland Memory Pools"
+   depends on HAS_DMA && MMU
+   select GENERIC_ALLOCATOR
+   select DMA_SHARED_BUFFER
+   help
+ Choose this option to enable the DMA-BUF userland, memory pools,
+ which allow userspace to allocate dma-bufs that can be shared between
+ drivers.
+ If you're not using Android its probably safe to say N here.
diff --git a/drivers/dma-buf/pools/Makefile b/drivers/dma-buf/pools/Makefile
new file mode 100644
index 000..6cb1284
--- /dev/null
+++ b/drivers/dma-buf/pools/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_DMABUF_POOLS) += dmabuf-pools.o pool-ioctl.o 
pool-helpers.o
diff --git a/drivers/dma-buf/pools/dmabuf-pools.c 
b/drivers/dma-buf/pools/dmabuf-pools.c

[EARLY RFC][PATCH 2/4] dma-buf: pools: Add page-pool for dma-buf pools

[John Stultz]

This adds the page-pool logic to the dma-buf pools which allows
a pool to keep pre-allocated/flushed pages around which can
speed up allocation performance.

NOTE: The page-pools name is term preserved from ION, but it has
potential to be easily confused with dma-buf pools. Suggestions
for alternatives here would be great.

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/dma-buf/pools/Makefile   |   2 +-
 drivers/dma-buf/pools/dmabuf-pools.h |  51 
 drivers/dma-buf/pools/page_pool.c| 157 +++
 3 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma-buf/pools/page_pool.c

diff --git a/drivers/dma-buf/pools/Makefile b/drivers/dma-buf/pools/Makefile
index 6cb1284..a51ec25 100644
--- a/drivers/dma-buf/pools/Makefile
+++ b/drivers/dma-buf/pools/Makefile
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DMABUF_POOLS) += dmabuf-pools.o pool-ioctl.o 
pool-helpers.o
+obj-$(CONFIG_DMABUF_POOLS) += dmabuf-pools.o pool-ioctl.o 
pool-helpers.o page_pool.o
diff --git a/drivers/dma-buf/pools/dmabuf-pools.h 
b/drivers/dma-buf/pools/dmabuf-pools.h
index 12110f2..e3a0aac 100644
--- a/drivers/dma-buf/pools/dmabuf-pools.h
+++ b/drivers/dma-buf/pools/dmabuf-pools.h
@@ -238,6 +238,57 @@ size_t dmabuf_pool_freelist_shrink(struct dmabuf_pool 
*pool,
  */
 size_t dmabuf_pool_freelist_size(struct dmabuf_pool *pool);
 
+/**
+ * functions for creating and destroying a page pool -- allows you
+ * to keep a page pool of pre allocated memory to use from your pool.  Keeping
+ * a page pool of memory that is ready for dma, ie any cached mapping have been
+ * invalidated from the cache, provides a significant performance benefit on
+ * many systems
+ */
+
+/**
+ * struct dmabuf_page_pool - pagepool struct
+ * @high_count:number of highmem items in the pool
+ * @low_count: number of lowmem items in the pool
+ * @high_items:list of highmem items
+ * @low_items: list of lowmem items
+ * @mutex: lock protecting this struct and especially the count
+ * item list
+ * @gfp_mask:  gfp_mask to use from alloc
+ * @order: order of pages in the pool
+ * @list:  plist node for list of pools
+ *
+ * Allows you to keep a page pool of pre allocated pages to use from your pool.
+ * Keeping a pool of pages that is ready for dma, ie any cached mapping have
+ * been invalidated from the cache, provides a significant performance benefit
+ * on many systems
+ */
+struct dmabuf_page_pool {
+   int high_count;
+   int low_count;
+   struct list_head high_items;
+   struct list_head low_items;
+   struct mutex mutex;
+   gfp_t gfp_mask;
+   unsigned int order;
+   struct plist_node list;
+};
+
+struct dmabuf_page_pool *dmabuf_page_pool_create(gfp_t gfp_mask,
+unsigned int order);
+void dmabuf_page_pool_destroy(struct dmabuf_page_pool *pool);
+struct page *dmabuf_page_pool_alloc(struct dmabuf_page_pool *pool);
+void dmabuf_page_pool_free(struct dmabuf_page_pool *pool, struct page *page);
+
+/** dmabuf_page_pool_shrink - shrinks the size of the memory cached in the pool
+ * @pool:  the page pool
+ * @gfp_mask:  the memory type to reclaim
+ * @nr_to_scan:number of items to shrink in pages
+ *
+ * returns the number of items freed in pages
+ */
+int dmabuf_page_pool_shrink(struct dmabuf_page_pool *pool, gfp_t gfp_mask,
+   int nr_to_scan);
 
 long dmabuf_pool_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
 
diff --git a/drivers/dma-buf/pools/page_pool.c 
b/drivers/dma-buf/pools/page_pool.c
new file mode 100644
index 000..c1fe994
--- /dev/null
+++ b/drivers/dma-buf/pools/page_pool.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * drivers/dma-buf/pools/page_pool.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+
+#include "dmabuf-pools.h"
+
+static inline struct page *dmabuf_page_pool_alloc_pages(
+   struct dmabuf_page_pool *pool)
+{
+   return alloc_pages(pool->gfp_mask, pool->order);
+}
+
+static void dmabuf_page_pool_free_pages(struct dmabuf_page_pool *pool,
+   struct page *page)
+{
+   __free_pages(page, pool->order);
+}
+
+static void dmabuf_page_pool_add(struct dmabuf_page_pool *pool,
+struct page *page)
+{
+   mutex_lock(>mutex);
+   if (PageHighMem(page)) {
+   list_add_tail(>lru, >high_items);
+   pool->high_count++;
+   } else {
+   

[EARLY RFC][PATCH 4/4] dma-buf: pools: Add CMA pool to dmabuf pools

[John Stultz]

This adds a CMA pool, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/dma-buf/pools/Kconfig|   8 +++
 drivers/dma-buf/pools/Makefile   |   1 +
 drivers/dma-buf/pools/cma_pool.c | 143 +++
 3 files changed, 152 insertions(+)
 create mode 100644 drivers/dma-buf/pools/cma_pool.c

diff --git a/drivers/dma-buf/pools/Kconfig b/drivers/dma-buf/pools/Kconfig
index 787b2a6..e984304 100644
--- a/drivers/dma-buf/pools/Kconfig
+++ b/drivers/dma-buf/pools/Kconfig
@@ -15,3 +15,11 @@ config DMABUF_POOLS_SYSTEM
help
  Choose this option to enable the system dmabuf pool. The system pool
  is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config DMABUF_POOLS_CMA
+   bool "DMA-BUF CMA Pool"
+   depends on DMABUF_POOLS && DMA_CMA
+   help
+ Choose this option to enable dma-buf CMA pools. This pool is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/dma-buf/pools/Makefile b/drivers/dma-buf/pools/Makefile
index 2ccf2a1..ac8aa28 100644
--- a/drivers/dma-buf/pools/Makefile
+++ b/drivers/dma-buf/pools/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DMABUF_POOLS) += dmabuf-pools.o pool-ioctl.o 
pool-helpers.o page_pool.o
 obj-$(CONFIG_DMABUF_POOLS_SYSTEM)  += system_pool.o
+obj-$(CONFIG_DMABUF_POOLS_CMA) += cma_pool.o
diff --git a/drivers/dma-buf/pools/cma_pool.c b/drivers/dma-buf/pools/cma_pool.c
new file mode 100644
index 000..0bd783f
--- /dev/null
+++ b/drivers/dma-buf/pools/cma_pool.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * drivers/dma-buf/pools/cma_pool.c
+ *
+ * Copyright (C) 2012, 2019 Linaro Ltd.
+ * Author:  for ST-Ericsson.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmabuf-pools.h"
+
+struct cma_pool {
+   struct dmabuf_pool pool;
+   struct cma *cma;
+};
+
+#define to_cma_pool(x) container_of(x, struct cma_pool, pool)
+
+/* dmabuf pool CMA operations functions */
+static int cma_pool_allocate(struct dmabuf_pool *pool,
+struct dmabuf_pool_buffer *buffer,
+unsigned long len,
+unsigned long flags)
+{
+   struct cma_pool *cma_pool = to_cma_pool(pool);
+   struct sg_table *table;
+   struct page *pages;
+   unsigned long size = PAGE_ALIGN(len);
+   unsigned long nr_pages = size >> PAGE_SHIFT;
+   unsigned long align = get_order(size);
+   int ret;
+
+   if (align > CONFIG_CMA_ALIGNMENT)
+   align = CONFIG_CMA_ALIGNMENT;
+
+   pages = cma_alloc(cma_pool->cma, nr_pages, align, false);
+   if (!pages)
+   return -ENOMEM;
+
+   if (PageHighMem(pages)) {
+   unsigned long nr_clear_pages = nr_pages;
+   struct page *page = pages;
+
+   while (nr_clear_pages > 0) {
+   void *vaddr = kmap_atomic(page);
+
+   memset(vaddr, 0, PAGE_SIZE);
+   kunmap_atomic(vaddr);
+   page++;
+   nr_clear_pages--;
+   }
+   } else {
+   memset(page_address(pages), 0, size);
+   }
+
+   table = kmalloc(sizeof(*table), GFP_KERNEL);
+   if (!table)
+   goto err;
+
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret)
+   goto free_mem;
+
+   sg_set_page(table->sgl, pages, size, 0);
+
+   buffer->priv_virt = pages;
+   buffer->sg_table = table;
+   return 0;
+
+free_mem:
+   kfree(table);
+err:
+   cma_release(cma_pool->cma, pages, nr_pages);
+   return -ENOMEM;
+}
+
+static void cma_pool_free(struct dmabuf_pool_buffer *buffer)
+{
+   struct cma_pool *cma_pool = to_cma_pool(buffer->pool);
+   struct page *pages = buffer->priv_virt;
+   unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
+
+   /* release memory */
+   cma_release(cma_pool->cma, pages, nr_pages);
+   /* release sg table */
+   sg_free_table(buffer->sg_table);
+   kfree(buffer->sg_table);
+}
+
+static struct dmabuf_pool_ops cma_pool_ops = {
+   .allocate = cma_pool_allocate,
+   .free = cma_pool_free,
+   .map_user = dmabuf_pool_map_user,
+   .map_kernel = dmabuf_pool_map_kernel,
+   .unmap_kernel = dmabuf_pool_unmap_kernel,
+};
+
+static struct dmabuf_pool *__cma_pool_create(struct cma *cma)
+{
+   struct cma_pool *cma_pool;
+
+   cma_pool = kzalloc(sizeof(*cma_pool), GFP_KERNEL);
+
+   if (!cma_pool)
+   return 

[EARLY RFC][PATCH 3/4] dma-buf: pools: Add system/system-contig pools to dmabuf pools

[John Stultz]

This patch adds system and system-contig pools to the dma-buf
pools framework.

This allows applications to get a page-allocator backed
dma-buf, of either non-contiguous or contiguous memory.

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/dma-buf/pools/Kconfig   |   7 +
 drivers/dma-buf/pools/Makefile  |   1 +
 drivers/dma-buf/pools/system_pool.c | 374 
 3 files changed, 382 insertions(+)
 create mode 100644 drivers/dma-buf/pools/system_pool.c

diff --git a/drivers/dma-buf/pools/Kconfig b/drivers/dma-buf/pools/Kconfig
index caa7eb8..787b2a6 100644
--- a/drivers/dma-buf/pools/Kconfig
+++ b/drivers/dma-buf/pools/Kconfig
@@ -8,3 +8,10 @@ menuconfig DMABUF_POOLS
  which allow userspace to allocate dma-bufs that can be shared between
  drivers.
  If you're not using Android its probably safe to say N here.
+
+config DMABUF_POOLS_SYSTEM
+   bool "DMA-BUF System Pool"
+   depends on DMABUF_POOLS
+   help
+ Choose this option to enable the system dmabuf pool. The system pool
+ is backed by pages from the buddy allocator. If in doubt, say Y.
diff --git a/drivers/dma-buf/pools/Makefile b/drivers/dma-buf/pools/Makefile
index a51ec25..2ccf2a1 100644
--- a/drivers/dma-buf/pools/Makefile
+++ b/drivers/dma-buf/pools/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DMABUF_POOLS) += dmabuf-pools.o pool-ioctl.o 
pool-helpers.o page_pool.o
+obj-$(CONFIG_DMABUF_POOLS_SYSTEM)  += system_pool.o
diff --git a/drivers/dma-buf/pools/system_pool.c 
b/drivers/dma-buf/pools/system_pool.c
new file mode 100644
index 000..1756990
--- /dev/null
+++ b/drivers/dma-buf/pools/system_pool.c
@@ -0,0 +1,374 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * drivers/dma-buf/pools/system_pool.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ * Copyright (C) 2019 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "dmabuf-pools.h"
+
+#define NUM_ORDERS ARRAY_SIZE(orders)
+
+static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
+__GFP_NORETRY) & ~__GFP_RECLAIM;
+static gfp_t low_order_gfp_flags  = GFP_HIGHUSER | __GFP_ZERO;
+static const unsigned int orders[] = {8, 4, 0};
+
+static int order_to_index(unsigned int order)
+{
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++)
+   if (order == orders[i])
+   return i;
+   WARN_ON(1);
+   return -1;
+}
+
+static inline unsigned int order_to_size(int order)
+{
+   return PAGE_SIZE << order;
+}
+
+struct system_pool {
+   struct dmabuf_pool pool;
+   struct dmabuf_page_pool *page_pools[NUM_ORDERS];
+};
+
+static struct page *alloc_buffer_page(struct system_pool *sys_pool,
+ struct dmabuf_pool_buffer *buffer,
+ unsigned long order)
+{
+   struct dmabuf_page_pool *pagepool =
+   sys_pool->page_pools[order_to_index(order)];
+
+   return dmabuf_page_pool_alloc(pagepool);
+}
+
+static void free_buffer_page(struct system_pool *sys_pool,
+struct dmabuf_pool_buffer *buffer,
+struct page *page)
+{
+   struct dmabuf_page_pool *pagepool;
+   unsigned int order = compound_order(page);
+
+   /* go to system */
+   if (buffer->private_flags & DMABUF_POOL_PRIV_FLAG_SHRINKER_FREE) {
+   __free_pages(page, order);
+   return;
+   }
+
+   pagepool = sys_pool->page_pools[order_to_index(order)];
+
+   dmabuf_page_pool_free(pagepool, page);
+}
+
+static struct page *alloc_largest_available(struct system_pool *sys_pool,
+   struct dmabuf_pool_buffer *buffer,
+   unsigned long size,
+   unsigned int max_order)
+{
+   struct page *page;
+   int i;
+
+   for (i = 0; i < NUM_ORDERS; i++) {
+   if (size < order_to_size(orders[i]))
+   continue;
+   if (max_order < orders[i])
+   continue;
+
+   page = alloc_buffer_page(sys_pool, buffer, orders[i]);
+   if (!page)
+   continue;
+
+   return page;
+   }
+
+   return NULL;
+}
+
+static int system_pool_allocate(struct dmabuf_pool *pool,
+   struct dmabuf_pool_buffer *buffer,
+   unsigned long size,
+   unsigned long flags)
+{
+   struct system_pool *sys_pool = container_of(pool,
+

[EARLY RFC][PATCH 0/4] dmabuf pools infrastructure (destaging ION)

[John Stultz]

Here is a very early peek at my dmabuf pools patchset, which
tries to destage a fair chunk of ION functionality.

This build and boots, but I've not gotten to testing the actual
pool devices yet (need to write some kselftests)! I just wanted
some early feedback on the overall direction.

The patchset implements per-pool devices (extending my ion
per-heap devices patchset from last week), which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
pool.

The interface is similar, but simpler then IONs, only providing
an ALLOC ioctl.

Also, I've only destaged the system/system-contig and cma pools,
since the ION carveout and chunk heaps depended on out of tree
board files to initialize those heaps. I'll leave that to folks
who are actually using those heaps.

Let me know what you think!

thanks
-john

Cc: Laura Abbott 
Cc: Benjamin Gaignard 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Chenbo Feng 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org

John Stultz (4):
  dma-buf: Add dma-buf pools framework
  dma-buf: pools: Add page-pool for dma-buf pools
  dma-buf: pools: Add system/system-contig pools to dmabuf pools
  dma-buf: pools: Add CMA pool to dmabuf pools

 MAINTAINERS  |  13 +
 drivers/dma-buf/Kconfig  |   2 +
 drivers/dma-buf/Makefile |   1 +
 drivers/dma-buf/pools/Kconfig|  25 ++
 drivers/dma-buf/pools/Makefile   |   4 +
 drivers/dma-buf/pools/cma_pool.c | 143 
 drivers/dma-buf/pools/dmabuf-pools.c | 670 +++
 drivers/dma-buf/pools/dmabuf-pools.h | 295 +++
 drivers/dma-buf/pools/page_pool.c| 157 
 drivers/dma-buf/pools/pool-helpers.c | 317 +
 drivers/dma-buf/pools/pool-ioctl.c   |  94 +
 drivers/dma-buf/pools/system_pool.c  | 374 +++
 include/uapi/linux/dmabuf-pools.h|  59 +++
 13 files changed, 2154 insertions(+)
 create mode 100644 drivers/dma-buf/pools/Kconfig
 create mode 100644 drivers/dma-buf/pools/Makefile
 create mode 100644 drivers/dma-buf/pools/cma_pool.c
 create mode 100644 drivers/dma-buf/pools/dmabuf-pools.c
 create mode 100644 drivers/dma-buf/pools/dmabuf-pools.h
 create mode 100644 drivers/dma-buf/pools/page_pool.c
 create mode 100644 drivers/dma-buf/pools/pool-helpers.c
 create mode 100644 drivers/dma-buf/pools/pool-ioctl.c
 create mode 100644 drivers/dma-buf/pools/system_pool.c
 create mode 100644 include/uapi/linux/dmabuf-pools.h

-- 
2.7.4

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

Re: [PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

[Vasily Khoruzhick]

On Wed, Feb 20, 2019 at 2:33 AM Maxime Ripard  wrote:
>
> On Tue, Feb 19, 2019 at 07:44:56AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 19, 2019 at 12:56 AM Maxime Ripard

> > Maxime, thanks for your patch but  it doesn't work for me. Pinebook
> > needs 1% tolerance. Having it as a module parameter means that no
> > distro will be able to boot on Pinebook out of the box.
>
> I don't really know what to tell you, the VESA spec defines everywhere
> that tolerance, and if we're not able to provide that, then we're not
> compliant and I don't want us to not be compliant just because one
> panel needed to be a bit more flexible, and especially since what
> could work on one panel might fail on another one.
>
> If you want alternate solutions, then please answer to:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/630441.html
>
> or provide the EDID blob.

Uh, I spoke to early, my bad. I made a mistake when I calculated rate
deviation for 768p last time - I took 73MHz as dotclock, but actual
requested rate 72.3 MHz and it gets 72.296296 MHz, so it's within 0.5%
tolerance. 1080p pinebook needs 138.5 MHz and gets 138.461538 MHz -
also within 0.5%.

However your patch has an issue, I'll respond to your previous email.

> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] libkms: update list of intel_drivers for Android build

[Tapani Pälli]

Add new iris driver, remove deprecated ilo driver.

Signed-off-by: Tapani Pälli 
---
 libkms/Android.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libkms/Android.mk b/libkms/Android.mk
index 0be72054..a8b9489f 100644
--- a/libkms/Android.mk
+++ b/libkms/Android.mk
@@ -1,6 +1,6 @@
 DRM_GPU_DRIVERS := $(strip $(filter-out swrast, $(BOARD_GPU_DRIVERS)))
 
-intel_drivers := i915 i965 i915g ilo
+intel_drivers := i915 i965 i915g iris
 radeon_drivers := r300g r600g radeonsi
 nouveau_drivers := nouveau
 virgl_drivers := virgl
-- 
2.20.1

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 20/02/2019 13.52, Sam Ravnborg wrote:
> Hi Peter.
> 
> On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
>> Hi Sam,
>>
>> On 15/02/2019 20.07, Sam Ravnborg wrote:
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
>>> Please do not use drmP.h in new drivers - we try to get rid of this file.
>>
>> ...
>>
 +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
 +{
 +  struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
 +  struct drm_display_mode *mode;
 +
 +  mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
 +  if (!mode) {
 +  dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
>>
>> drm/drmP.h is needed for this dev_err.
> drmP.h is only a set of include files and forwards today.
> So you need to figure out what to replace it with.
> 
> Often removing drmP.h requires you to add more than one extra include file.

Replacing it with
#include 

works perfectly.

Thanks,
- Péter

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

[PATCH] drm/qxl: unbind vgacon

[Gerd Hoffmann]

Problem:  qxl switches from native mode back into vga compatibility mode
when it notices someone is accessing vga registers.  And vgacon does
exactly that before fbcon takes over.

Before qxl switched to the generic fbdev emulation that didn't cause any
problems.  With the generic fbdev emulation the switch to vga mode
happens now and then, probably caused by a initialization order change
and triggered by a printk in a bad moment.

So make sure we take vgacon out of the picture by making dummycon
taking over the console early enough.

Not entriely happy with the approach, I'm open to better ideas.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index bb81e310eb..88349dc13e 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -89,6 +90,11 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
drm_kms_helper_poll_init(>ddev);
 
+   /* unbind vgacon to make sure it doesn't touch our vga registers */
+   console_lock();
+   ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, true);
+   console_unlock();
+
/* Complete initialization. */
ret = drm_dev_register(>ddev, ent->driver_data);
if (ret)
-- 
2.9.3

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

Re: [PATCH libdrm] xf86drm: Fix operator precedence

[Frank Binns]

Reviewed-by: Frank Binns 

Thierry Reding  writes:

> From: Thierry Reding 
>
> The array subscription operator ([]) has higher precedence than the
> indirection operator (*), so we need to use parentheses to properly
> instruct the compiler to dereference the pointer to an array first,
> and then subscript into the array.
>
> Fixes a crash observed on Tegra.
>
> Signed-off-by: Thierry Reding 
> ---
>  xf86drm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index d006bb38f800..5de37083c9a3 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -3606,14 +3606,14 @@ static int drmParseOFDeviceInfo(int maj, int min, 
> char ***compatible)
>  free(value);
>  }
>  
> -*compatible[i] = tmp_name;
> +(*compatible)[i] = tmp_name;
>  }
>  
>  return 0;
>  
>  free:
>  while (i--)
> -free(*compatible[i]);
> +free((*compatible)[i]);
>  
>  free(*compatible);
>  return err;

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

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Sam Ravnborg]

Hi Peter.

Always good to see that feedback input is used.
 
> OK.
> 
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +static void osd101t2587_panel_shutdown(struct mipi_dsi_device *dsi)
> >> +{
> >> +  struct osd101t2587_panel *osd101t2587 = mipi_dsi_get_drvdata(dsi);
> >> +
> > Maybe call osd101t2587_panel_unprepare() here to turn off power supply?
> 
> Make sense, in this order:
>   osd101t2587_panel_disable(>base);
>   osd101t2587_panel_unprepare(>base);
> 
> But should the osd101t2587_panel_remove() do the same thing? or the
> osd101t2587_panel_disable() is redundant in the osd101t2587_panel_remove()?

I do not know the details to answer this.
In other words - I do not know if we can rely on that panel->disbale is always
called when a driver is removed.
Try to read the descriptions and maybe test it.

Other drivers do as far as I recall use disable in the remove function.

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

Re: [PATCH v4 3/4] drm/vc4: Detect and ignore underruns caused by out-of-sync dlists

[Paul Kocialkowski]

Hi,

On Wed, 2019-02-06 at 15:51 -0800, Eric Anholt wrote:
> Paul Kocialkowski  writes:
> 
> > When the pipeline is reconfigured with a different mode, changes take
> > effect immediately for the CRTC and encoder while the HVS takes some
> > time to switch the active display list. This results in a period of
> > time where the pipeline is out of sync, that is very likely to cause
> > an underrun to be reported. Because the underrun is not related to the
> > new configuration, reporting it to userspace is a false positive.
> 
> This seems like a serious issue.  How are we enabling a CRTC with the
> corresponding HVS still scanning out old contents?  Did we need to wait
> for HVS to finish its old frame when we turned off the CRTC, so it's
> ready to receive the START when it's been set up with the new dlist and
> the CRTC is turned back on?  Or maybe do some sort of reset of that
> dlist when a crtc is being enabled?

Yes this has definitely been quite a burden. I have already tried
waiting for the end of frame before disabling the crtc, as well as
playing with various other bits and FIFO reset (see the "HDMI mode
reconfiguration issue mitigation" thread). Alas, nothing helped and I
moved on to implementing a workaround after you said not to block on
this particular point.

> If we can't sort that out, it feels to me like we should be enabling the
> interrupts from the flip_done path (when we know that the HVS is
> scanning out the new frame) instead of trying to mitigate enabling them
> too early.

Thanks for the hint! I looked into this solution and it seems viable,
although I found out that interrupt masking is not always honored by
the hardware. With some extra care, it seems to be working reliably.

I'll send a new iteration implementing the workaround this way.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: drm bridge control from another driver

[A H]

Hi,

Writing from non-standard mail composer, forgive formatting mistakes.

On Tue, Feb 19, 2019 at 5:22 PM Vinay Simha B N  wrote:

> added the temperature alert irq handler in adv driver , in the irq
> calling schedule_work(>hpd_work); , initially in the
> adv7511_detect , if we set status = connector_status_disconnected; later
> when irq handler calls the schedule work, hpd does not works.
> [   55.052677] [drm] Cannot find any crtc or sizes
> [   55.058786] [drm] Cannot find any crtc or sizes
>
> by default driver of adv, hpd does not works as expected, board boots
> without hdmi connected, after postboot if we connect hdmi , in irq hpd_work
> ,but to get the display we need to press ctrl+alt+backspace.
>
>
Apparently driver has some problems with hotplug handling. As you wrote
earlier:
> in userspace when i tried manually  below commands, there is no impact in
the display.
> /sys/class/drm/card0-HDMI-A-1/status
> echo off > status
> echo on > status

It suggests that code has some issues with hotplug detection/reporting.
The rule should be that if connector status changes
drm_kms_helper_hotplug_event should be called, it looks like it is not.

Regards
Andrzej



> On Thu, Feb 14, 2019 at 8:03 PM Andrzej Hajda  wrote:
>
>> On 13.02.2019 15:31, Vinay Simha B N wrote:
>> >
>> >
>> > On Wed, Feb 13, 2019 at 7:44 PM Andrzej Hajda > > > wrote:
>> >
>> > On 13.02.2019 14:40, Vinay Simha B N wrote:
>> > > Andrzej/Daniel,
>> > >
>> > > please suggest any input on the scenario for temperature control
>> and
>> > > dsi bridge enable/disable.
>> > >
>> > > On Mon, Feb 11, 2019 at 2:41 PM Vinay Simha B N
>> > mailto:simha...@gmail.com>
>> > > >> wrote:
>> > >
>> > > dsi2hdmi(adv7511) chip operating temperature range is -10 degC
>> > > to +85 degC. We want to enable/disable the bridge only when
>> > > temperature range is inbetween these range.
>> > >
>> > > We have temperature control chip to read the temp, tLow an
>> tHigh
>> > > can be set. whenever interrupt(alert) triggers we want to
>> > > enablel/disable the bridge.
>> > >
>> > > Any suggestion what is the better way to handle this scenario?
>> > >
>> >
>> > Why do you need to bother about this quite big range at all?
>> >
>> > we are looking for -10 deg C, this system will be used in a place
>> > where temp goes beyond -20 deg C... processor(apq8016/410c) can handle
>> > upto -30, but dsi2hdmi(adv7533) chip if enabled beyond -10 deg C, life
>> > of the chip goes down or it cannot operate at all.
>> >
>> >
>> > I guess the best would be to set whole platform operating
>> temperature
>> > range, and poweroff/sleep/slow down/??? whole system, not just one
>> > random chip, which probably is not the most fragile piece, am I
>> right?
>> >
>> > right now we are focused only to disable the hdmi chip if temp goes
>> > beyond -10, since this is only chip in board faces temp issue, other
>> > components are fine to go upto -30 deg C.
>> >
>> >
>> > If you really insist on handling it per chip, you can try to
>> > investigate
>> > following paths:
>> >
>> > 1. Just disable the chip, without noticing drm, other drivers, or
>> > userspace, and re-enable it if temperature become acceptable, but I
>> am
>> > not sure if this will not change behavior of other chips.
>> >
>> > dsi2hdmi tied with drm framework, i need to enable/disable the bridge.
>> > i can disable the regulators enabled for it , but this does not work
>> > as we want.
>> >
>> >
>> > 2. Disable the chip and report to the drm subsystem
>> > connector_status_disconnected - this will cause drm to stop display
>> > pipeline and userspace notification.
>> >
>> > any references/driver on how to disable and report to drm susbsystem
>> > will help to implement.
>> > connector_status_disconnected i need to call in the interrupt handler
>> > of tmp102 driver.
>>
>>
>> Look at the code of adv7511_hpd_work, it evaluates connector status
>> based on ADV7511_REG_STATUS, so you can put there temperature check
>> also, and call 'schedule_work(>hpd_work)'
>>
>> if temperature passes valid temp range.
>>
>> If you want to do it in mainline, please consult it with adv7511
>> authors/commiters.
>>
>>
>> Regards
>>
>> Andrzej
>>
>>
>> >
>> > in userspace when i tried manually  below commands, there is no impact
>> > in the display.
>> > /sys/class/drm/card0-HDMI-A-1/status
>> > echo off > status
>> > echo on > status
>> >
>> >
>> > Regards
>> >
>> > Andrzej
>> >
>> >
>> > >
>> > > regards,
>> > > vinaysimha
>> > >
>> > > On Mon, Feb 11, 2019 at 2:10 PM Daniel Vetter
>> > mailto:dan...@ffwll.ch>
>> > > >> wrote:
>> > >
>> > > On Mon, Feb 11, 2019 at 09:32:54AM +0100, Andrzej 

[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller

[bugzilla-daemon]

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

--- Comment #5 from CI Bug Log  ---
A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-icl-u2, fi-icl-u3: random tests - incomplete +}

New failures caught by the filter:

*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_225/fi-icl-u3/igt@kms_rotation_...@multiplane-rotation-cropping-top.html

-- 
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 4/4] drm/panel: Add OSD101T2587-53TS driver

[Sam Ravnborg]

Hi Peter.

On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
> Hi Sam,
> 
> On 15/02/2019 20.07, Sam Ravnborg wrote:
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> > Please do not use drmP.h in new drivers - we try to get rid of this file.
> 
> ...
> 
> >> +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
> >> +{
> >> +  struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
> >> +  struct drm_display_mode *mode;
> >> +
> >> +  mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
> >> +  if (!mode) {
> >> +  dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
> 
> drm/drmP.h is needed for this dev_err.
drmP.h is only a set of include files and forwards today.
So you need to figure out what to replace it with.

Often removing drmP.h requires you to add more than one extra include file.

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

[PATCH v5 0/3] drm/vc4: Add a load tracker

[Paul Kocialkowski]

Hi,

Here is a fourth iteration of the VC4 load tracking series, which was
initially developed by Boris Brezillon and that I have now taken over.

This new iteration takes in account comments from v3 and comes with a
new approach for avoiding underrun reports when reconfiguring the
pipeline. It is now based on detection instead of delaying the underrun
interrupt unmasking.

It can be tested with a dedicated IGT GPU Tools series:
  VC4 load tracker testing

Changes since v4:
* Unmasked underrun in vc4_crtc_handle_page_flip instead of the previous
  workaround for detecting out-of-sync display lists causing underruns;
* Added comments where it felt relevant;
* Made underrun masking/unmasking per-channel to avoid race conditions
  resulting in unwanted masking/unmasking;
* Added a check for unmasked interrupt before acting upon it;
* Disabled shortline/underrun interrupts at initial config time;
* Added collected Reviewed-by tags.

Changes since v3:
* Returned IRQ_NONE for short line interrupt to avoid storm;
* Made register definitions with per-channel offsets more direct;
* cleaned all IRQ fields instead of writing back the status bit as
  advised by docs;
* Reworked first commit's message;
* Removed in-commit changelogs with inconsistent revision numbers;
* Removed explicit wait for sync before unmasking underrun interrupt;
* Checked that the display lists are synced before reporting underrun;

Cheers,

Paul

Boris Brezillon (2):
  drm/vc4: Report HVS underrun errors
  drm/vc4: Add a load tracker to prevent HVS underflow errors

Paul Kocialkowski (1):
  drm/vc4: Add a debugfs entry to disable/enable the load tracker

 drivers/gpu/drm/vc4/vc4_crtc.c|   8 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  10 +++
 drivers/gpu/drm/vc4/vc4_drv.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h |  24 ++
 drivers/gpu/drm/vc4/vc4_hvs.c |  95 +++
 drivers/gpu/drm/vc4/vc4_kms.c | 122 +-
 drivers/gpu/drm/vc4/vc4_plane.c   |  57 ++
 drivers/gpu/drm/vc4/vc4_regs.h|  51 -
 8 files changed, 332 insertions(+), 36 deletions(-)

-- 
2.20.1

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

[PATCH v5 2/3] drm/vc4: Add a load tracker to prevent HVS underflow errors

[Paul Kocialkowski]

From: Boris Brezillon 

The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.

This patch is trying to model the per-plane HVS and memory bus bandwidth
consumption and take a decision at atomic_check() time whether the
estimated load will fit in the HVS and membus budget.

Note that we take an extra margin on the memory bus consumption to let
the system run smoothly when other blocks are doing heavy use of the
memory bus. Same goes for the HVS limit, except the margin is smaller in
this case, since the HVS is not used by external components.

Signed-off-by: Boris Brezillon 
Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/vc4/vc4_drv.c   |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h   |  11 
 drivers/gpu/drm/vc4/vc4_kms.c   | 103 +++-
 drivers/gpu/drm/vc4/vc4_plane.c |  57 ++
 4 files changed, 171 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 52576dee809e..3227706700f9 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -311,6 +311,7 @@ static void vc4_drm_unbind(struct device *dev)
 
drm_mode_config_cleanup(drm);
 
+   drm_atomic_private_obj_fini(>load_tracker);
drm_atomic_private_obj_fini(>ctm_manager);
 
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 6f86af1b3212..bbab084911f3 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -207,6 +207,7 @@ struct vc4_dev {
 
struct drm_modeset_lock ctm_state_lock;
struct drm_private_obj ctm_manager;
+   struct drm_private_obj load_tracker;
 };
 
 static inline struct vc4_dev *
@@ -378,6 +379,16 @@ struct vc4_plane_state {
 * when async update is not possible.
 */
bool dlist_initialized;
+
+   /* Load of this plane on the HVS block. The load is expressed in HVS
+* cycles/sec.
+*/
+   u64 hvs_load;
+
+   /* Memory bandwidth needed for this plane. This is expressed in
+* bytes/sec.
+*/
+   u64 membus_load;
 };
 
 static inline struct vc4_plane_state *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index b971258dcfd4..6e20604573de 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -34,6 +34,18 @@ static struct vc4_ctm_state *to_vc4_ctm_state(struct 
drm_private_state *priv)
return container_of(priv, struct vc4_ctm_state, base);
 }
 
+struct vc4_load_tracker_state {
+   struct drm_private_state base;
+   u64 hvs_load;
+   u64 membus_load;
+};
+
+static struct vc4_load_tracker_state *
+to_vc4_load_tracker_state(struct drm_private_state *priv)
+{
+   return container_of(priv, struct vc4_load_tracker_state, base);
+}
+
 static struct vc4_ctm_state *vc4_get_ctm_state(struct drm_atomic_state *state,
   struct drm_private_obj *manager)
 {
@@ -395,6 +407,81 @@ vc4_ctm_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
return 0;
 }
 
+static int vc4_load_tracker_atomic_check(struct drm_atomic_state *state)
+{
+   struct drm_plane_state *old_plane_state, *new_plane_state;
+   struct vc4_dev *vc4 = to_vc4_dev(state->dev);
+   struct vc4_load_tracker_state *load_state;
+   struct drm_private_state *priv_state;
+   struct drm_plane *plane;
+   int i;
+
+   priv_state = drm_atomic_get_private_obj_state(state,
+ >load_tracker);
+   if (IS_ERR(priv_state))
+   return PTR_ERR(priv_state);
+
+   load_state = to_vc4_load_tracker_state(priv_state);
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state,
+  new_plane_state, i) {
+   struct vc4_plane_state *vc4_plane_state;
+
+   if (old_plane_state->fb && old_plane_state->crtc) {
+   vc4_plane_state = to_vc4_plane_state(old_plane_state);
+   load_state->membus_load -= vc4_plane_state->membus_load;
+   load_state->hvs_load -= vc4_plane_state->hvs_load;
+   }
+
+   if (new_plane_state->fb && new_plane_state->crtc) {
+   vc4_plane_state = to_vc4_plane_state(new_plane_state);
+   load_state->membus_load += vc4_plane_state->membus_load;
+   load_state->hvs_load += vc4_plane_state->hvs_load;
+   }
+   }
+
+   /* The absolute limit is 2Gbyte/sec, but let's take a margin to let
+* the system work when other blocks are accessing the memory.
+*/
+   if (load_state->membus_load > SZ_1G + SZ_512M)
+ 

[PATCH v5 1/3] drm/vc4: Report HVS underrun errors

[Paul Kocialkowski]

From: Boris Brezillon 

Add a debugfs entry and helper for reporting HVS underrun errors as
well as helpers for masking and unmasking the underrun interrupts.
Add an IRQ handler and initial IRQ configuration.
Rework related register definitions to take the channel number.

Signed-off-by: Boris Brezillon 
Signed-off-by: Paul Kocialkowski 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c|  8 +++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  1 +
 drivers/gpu/drm/vc4/vc4_drv.h | 10 
 drivers/gpu/drm/vc4/vc4_hvs.c | 95 +++
 drivers/gpu/drm/vc4/vc4_kms.c | 10 
 drivers/gpu/drm/vc4/vc4_regs.h| 51 ++---
 6 files changed, 140 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 730008d3da76..64c964b7c577 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -834,6 +834,14 @@ static void vc4_crtc_handle_page_flip(struct vc4_crtc 
*vc4_crtc)
drm_crtc_send_vblank_event(crtc, vc4_crtc->event);
vc4_crtc->event = NULL;
drm_crtc_vblank_put(crtc);
+
+   /* Wait for the page flip to unmask the underrun to ensure that
+* the display list was updated by the hardware. Before that
+* happens, the HVS will be using the previous display list with
+* the CRTC and encoder already reconfigured, leading to
+* underruns. This can be seen when reconfiguring the CRTC.
+*/
+   vc4_hvs_unmask_underrun(dev, vc4_crtc->channel);
}
spin_unlock_irqrestore(>event_lock, flags);
 }
diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 7a0003de71ab..64021bcba041 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -23,6 +23,7 @@ static const struct drm_info_list vc4_debugfs_list[] = {
{"vec_regs", vc4_vec_debugfs_regs, 0},
{"txp_regs", vc4_txp_debugfs_regs, 0},
{"hvs_regs", vc4_hvs_debugfs_regs, 0},
+   {"hvs_underrun",  vc4_hvs_debugfs_underrun, 0},
{"crtc0_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)0},
{"crtc1_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)1},
{"crtc2_regs", vc4_crtc_debugfs_regs, 0, (void *)(uintptr_t)2},
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index ce1af06cc197..6f86af1b3212 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -184,6 +184,13 @@ struct vc4_dev {
/* Bitmask of the current bin_alloc used for overflow memory. */
uint32_t bin_alloc_overflow;
 
+   /* Incremented when an underrun error happened after an atomic commit.
+* This is particularly useful to detect when a specific modeset is too
+* demanding in term of memory or HVS bandwidth which is hard to guess
+* at atomic check time.
+*/
+   atomic_t underrun;
+
struct work_struct overflow_mem_work;
 
int power_refcount;
@@ -767,6 +774,9 @@ void vc4_irq_reset(struct drm_device *dev);
 extern struct platform_driver vc4_hvs_driver;
 void vc4_hvs_dump_state(struct drm_device *dev);
 int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused);
+int vc4_hvs_debugfs_underrun(struct seq_file *m, void *unused);
+void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
+void vc4_hvs_mask_underrun(struct drm_device *dev, int channel);
 
 /* vc4_kms.c */
 int vc4_kms_load(struct drm_device *dev);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 5d8c749c9749..918e71256ecc 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -22,6 +22,7 @@
  * each CRTC.
  */
 
+#include 
 #include 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
@@ -102,6 +103,18 @@ int vc4_hvs_debugfs_regs(struct seq_file *m, void *unused)
 
return 0;
 }
+
+int vc4_hvs_debugfs_underrun(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_printer p = drm_seq_file_printer(m);
+
+   drm_printf(, "%d\n", atomic_read(>underrun));
+
+   return 0;
+}
 #endif
 
 /* The filter kernel is composed of dwords each containing 3 9-bit
@@ -166,6 +179,67 @@ static int vc4_hvs_upload_linear_kernel(struct vc4_hvs 
*hvs,
return 0;
 }
 
+void vc4_hvs_mask_underrun(struct drm_device *dev, int channel)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
+
+   dispctrl &= ~SCALER_DISPCTRL_DSPEISLUR(channel);
+
+   HVS_WRITE(SCALER_DISPCTRL, dispctrl);
+}
+
+void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   u32 dispctrl = HVS_READ(SCALER_DISPCTRL);
+
+   dispctrl |= 

[PATCH v5 3/3] drm/vc4: Add a debugfs entry to disable/enable the load tracker

[Paul Kocialkowski]

In order to test whether the load tracker is working as expected, we
need the ability to compare the commit result with the underrun
indication. With the load tracker always enabled, commits that are
expected to trigger an underrun are always rejected, so userspace
cannot get the actual underrun indication from the hardware.

Add a debugfs entry to disable/enable the load tracker, so that a DRM
commit expected to trigger an underrun can go through with the load
tracker disabled. The underrun indication is then available to
userspace and can be checked against the commit result with the load
tracker enabled.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_debugfs.c | 9 +
 drivers/gpu/drm/vc4/vc4_drv.h | 3 +++
 drivers/gpu/drm/vc4/vc4_kms.c | 9 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_debugfs.c 
b/drivers/gpu/drm/vc4/vc4_debugfs.c
index 64021bcba041..59cdad89f844 100644
--- a/drivers/gpu/drm/vc4/vc4_debugfs.c
+++ b/drivers/gpu/drm/vc4/vc4_debugfs.c
@@ -36,6 +36,15 @@ static const struct drm_info_list vc4_debugfs_list[] = {
 int
 vc4_debugfs_init(struct drm_minor *minor)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(minor->dev);
+   struct dentry *dentry;
+
+   dentry = debugfs_create_bool("hvs_load_tracker", S_IRUGO | S_IWUSR,
+minor->debugfs_root,
+>load_tracker_enabled);
+   if (!dentry)
+   return -ENOMEM;
+
return drm_debugfs_create_files(vc4_debugfs_list, VC4_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
 }
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index bbab084911f3..7a3c093e7443 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -195,6 +195,9 @@ struct vc4_dev {
 
int power_refcount;
 
+   /* Set to true when the load tracker is active. */
+   bool load_tracker_enabled;
+
/* Mutex controlling the power refcount. */
struct mutex power_lock;
 
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 6e20604573de..5160cad25fce 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -439,6 +439,10 @@ static int vc4_load_tracker_atomic_check(struct 
drm_atomic_state *state)
}
}
 
+   /* Don't check the load when the tracker is disabled. */
+   if (!vc4->load_tracker_enabled)
+   return 0;
+
/* The absolute limit is 2Gbyte/sec, but let's take a margin to let
 * the system work when other blocks are accessing the memory.
 */
@@ -511,6 +515,11 @@ int vc4_kms_load(struct drm_device *dev)
struct vc4_load_tracker_state *load_state;
int ret;
 
+   /* Start with the load tracker enabled. Can be disabled through the
+* debugfs load_tracker file.
+*/
+   vc4->load_tracker_enabled = true;
+
sema_init(>async_modeset, 1);
 
/* Set support for vblank irq fast disable, before drm_vblank_init() */
-- 
2.20.1

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

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[Brian Starkey]

On Tue, Feb 19, 2019 at 01:47:36PM -0800, John Stultz wrote:
> On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott  wrote:
> >
> > On 2/15/19 12:24 PM, John Stultz wrote:
> > > The per-device heaps don't support HEAP_QUERY ioctl, since
> > > the name is provided in the devnode path and the heapid isn't
> > > useful with the new interface (one uses the fd of heapdevice).
> > >
> > > But, one missing bit of functionality is a way to find the
> > > heap type. So provide a HEAP_INFO ioctl which exposes the
> > > heap type out so there is the potential for some sort of
> > > dynamic heap matching/discovery.
> > >
> > > Most likely this IOCTL will be useful when extended to allow
> > > some sort of opaque constraint bitfield to be shared so userland
> > > can match heaps with devices in a fully dynamic way.
> > >
> >
> > We've been waiting on the constraint solving for a while and
> > it's never really happened :(
> >
> 
> Yea. I'm not trying to open that up again.
> 
> > It certainly works but I'm concerned about adding this and
> > then finding (yet again) that it doesn't work. We're
> > getting the heap name now but do we lose anything if we
> > don't expose it as part of the ABI?
> 
> Right. So all we're exporting in this patch is the heap_type. This was
> somewhat of an afterthought for me, as practically, I suspect the
> gralloc users of ion will know which heap they want by name, and won't
> do any sort of dynamic heap finding.
> 
> That said, ion's current API provides the QUERY interface which gives
> you a list of heap ids/names/types, so if you wanted something that on
> any random system was able to find a ION_HEAP_TYPE_DMA heap and use
> it, you could.
> 
> So this HEAP_INFO ioctl provides a way to do the same. That's it.
> 
> That said, I could envision the ioctl to be extended (via the reserved
> values) to provide some sort of constraint cookie to allow for
> constraint solving, but that's still a unsolved issue at large.
> 
> Given the handwaving at the constraints part, and that the heap type
> is a pretty coarse grained enum (only 6 types, as of now - one being
> catchall "custom"), I'm fine holding off on this bit unless folks
> really see it as valuable.

What do people think about putting the heap type into the device name?
The whole query API is then replaced with `ls`

-Brian

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

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

Bug ID: 109692
   Summary: deadlock occurs during GPU reset
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

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

Steps for reproduce:
1. $ git clone git://people.freedesktop.org/~agd5f/linux -b
amd-staging-drm-next
2. $ make bzImage && make module
3. # make modules_install && make install
4. Launch "Shadow of the Tomb Raider"
--- Here GPU hung occurs ---
and after few time 
--- Here start GPU reset ---
--- Here Deadlock occurs ---

[  291.746741] amdgpu :0b:00.0: [gfxhub] no-retry page fault (src_id:0
ring:158 vmid:7 pasid:32774, for process SOTTR.exe pid 5250 thread SOTTR.exe
pid 5250)
[  291.746750] amdgpu :0b:00.0:   in page starting at address
0x2000 from 27
[  291.746754] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0070113C
[  297.135183] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out.
[  302.255032] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out.
[  302.265813] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
signaled seq=13292, emitted seq=13293
[  302.265950] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process SOTTR.exe pid 5250 thread SOTTR.exe pid 5250
[  302.265974] amdgpu :0b:00.0: GPU reset begin!

[  302.266337] ==
[  302.266338] WARNING: possible circular locking dependency detected
[  302.266340] 5.0.0-rc1-drm-next-kernel+ #1 Tainted: G C   
[  302.266341] --
[  302.266343] kworker/5:2/871 is trying to acquire lock:
[  302.266345] 0abbb16a (&(>fence_drv.lock)->rlock){-.-.}, at:
dma_fence_remove_callback+0x1a/0x60
[  302.266352] 
   but task is already holding lock:
[  302.266353] 6e32ba38 (&(>job_list_lock)->rlock){-.-.}, at:
drm_sched_stop+0x34/0x140 [gpu_sched]
[  302.266358] 
   which lock already depends on the new lock.

[  302.266360] 
   the existing dependency chain (in reverse order) is:
[  302.266361] 
   -> #1 (&(>job_list_lock)->rlock){-.-.}:
[  302.266366]drm_sched_process_job+0x4d/0x180 [gpu_sched]
[  302.266368]dma_fence_signal+0x111/0x1a0
[  302.266414]amdgpu_fence_process+0xa3/0x100 [amdgpu]
[  302.266470]sdma_v4_0_process_trap_irq+0x6e/0xa0 [amdgpu]
[  302.266523]amdgpu_irq_dispatch+0xc0/0x250 [amdgpu]
[  302.266576]amdgpu_ih_process+0x84/0xf0 [amdgpu]
[  302.266628]amdgpu_irq_handler+0x1b/0x50 [amdgpu]
[  302.266632]__handle_irq_event_percpu+0x3f/0x290
[  302.266635]handle_irq_event_percpu+0x31/0x80
[  302.266637]handle_irq_event+0x34/0x51
[  302.266639]handle_edge_irq+0x7c/0x1a0
[  302.266643]handle_irq+0xbf/0x100
[  302.266646]do_IRQ+0x61/0x120
[  302.266648]ret_from_intr+0x0/0x22
[  302.266651]cpuidle_enter_state+0xbf/0x470
[  302.266654]do_idle+0x1ec/0x280
[  302.266657]cpu_startup_entry+0x19/0x20
[  302.20]start_secondary+0x1b3/0x200
[  302.23]secondary_startup_64+0xa4/0xb0
[  302.24] 
   -> #0 (&(>fence_drv.lock)->rlock){-.-.}:
[  302.28]_raw_spin_lock_irqsave+0x49/0x83
[  302.266670]dma_fence_remove_callback+0x1a/0x60
[  302.266673]drm_sched_stop+0x59/0x140 [gpu_sched]
[  302.266717]amdgpu_device_pre_asic_reset+0x4f/0x240 [amdgpu]
[  302.266761]amdgpu_device_gpu_recover+0x88/0x7d0 [amdgpu]
[  302.266822]amdgpu_job_timedout+0x109/0x130 [amdgpu]
[  302.266827]drm_sched_job_timedout+0x40/0x70 [gpu_sched]
[  302.266831]process_one_work+0x272/0x5d0
[  302.266834]worker_thread+0x50/0x3b0
[  302.266836]kthread+0x108/0x140
[  302.266839]ret_from_fork+0x27/0x50
[  302.266840] 
   other info that might help us debug this:

[  302.266841]  Possible unsafe locking scenario:

[  302.266842]CPU0CPU1
[  302.266843]
[  302.266844]   lock(&(>job_list_lock)->rlock);
[  302.266846]   
lock(&(>fence_drv.lock)->rlock);
[  302.266847]   
lock(&(>job_list_lock)->rlock);
[  302.266849]   lock(&(>fence_drv.lock)->rlock);
[  302.266850] 
*** DEADLOCK ***

[  302.266852] 5 locks held by kworker/5:2/871:
[  302.266853]  #0: d133fb6e ((wq_completion)"events"){+.+.}, at:
process_one_work+0x1e9/0x5d0
[  302.266857]  #1: 8a5c3f7e

Re: [PATCH v3 0/8] drm/sun4i: dsi: Add burst mode support

[Maxime Ripard]

Hi,

On Mon, Feb 18, 2019 at 04:01:09PM +0530, Jagan Teki wrote:
> On Mon, Feb 18, 2019 at 1:56 PM Paul Kocialkowski
>  wrote:
> > On Fri, 2019-02-15 at 22:37 +0530, Jagan Teki wrote:
> > > On 15/02/19 8:10 PM, Jagan Teki wrote:
> > > >
> > > > On Fri, 15 Feb, 2019, 7:43 PM Maxime Ripard,  > > > > wrote:
> > > >
> > > > On Mon, Feb 11, 2019 at 03:41:21PM +0100, Maxime Ripard wrote:
> > > >  > Hi,
> > > >  >
> > > >  > Here is a series implementing the burst mode support for DSI.
> > > >  >
> > > >  > It's been tested on an A33 board with the panel supported on the 
> > > > last
> > > >  > patch, which should remove all quirks due to a different SoC 
> > > > from the
> > > >  > equation.
> > > >
> > > > I should have sent that mail yesterday, but patches 1-4 and 6-7 were
> > > > merged. Patch 5 was discarded since it was not consistent with the
> > > > rest of the driver, and 8 had some comments.
> > > >
> > > >
> > > > Are the applied patches from this series or from my v7 series?
> > > >
> > > >   Would you please point me the branch.
> > > >
> > >
> > > Unfortunately my last mail didn't reach arm mailing list.
> > >
> > > Just wanted to know are the applied patches from this series or from my
> > > v7 series? Would you please point me the repo, I couldn't find it on
> > > git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git
> >
> > This series is the one that was applied upstream. You can find the
> > commits merged at: https://cgit.freedesktop.org/drm/drm-misc/log/
> 
> Thanks for sharing the link Paul.
> 
> This is really really discouraging.
> 
> Don't know whom to ask directly about this, but I am really upset
> about this move.

I appreciate and understand that, and I feel sorry it ended up like
this.

> Most of the changes from applied series have similar patches that are
> been part of my series of patches. I've been sending this since last
> September (which was sent way prior than this series).

Note that only the burst part has been merged, and the first time you
sent it was in November.

> How come the same series is recreated and applied with minor changes
> while the original series was still in discussion. At least Maxime
> should have informed me or he should have rejected my work from
> patchwork or atleast NAK in ML?

I did, both in private and public. And I've told you on numerous
occasions what was wrong with your series and the way you were pushing
things. But let's break it down:

v8:
  - Chen-Yu and I spent a lot of time (almost two full work days in my
case, Chen-Yu at least a full evening from what I know) trying to
make sense of the Allwinner BSP code, and report what was being
done. This was made public on the mailing lists, and you were in
cc [1][2]. It happened the week before your submission, yet you
ignored most of those changes, and I told you so [3], mentionning
a bunch of other recurring comments I had that were not really
addressed.
  - This series and the other also had some obvious flaw that had 0
chance to work properly (which you eventually noticed[4])

v7:
  - Chen-Yu and I were already discussing and pointing out some
issues, that were not addressed[5]

v6:
  - Reviewing a PLL issue, already mentionned in the v5 and v2 [6]

v5:
  - I mention that the display I have is broken, just like in your v4 [6].
Just like in the v4, I'm asking for a panel datasheet so
that I can help you debug this further. This is ignored.
  - I asked for clarifications on that PLL min_rate, just like in the
previous versions [7]

v4 
 - I mention that the only other DSI display there is is broken
   [8]. I'm again asking for datasheet and better commit logs.

v3
  - Some more ignored comments [9]

A64 DSI v2
  - Asking details on the PLL min_rate, comments ignored [10]
  - Untested code [11]

Burst v2
  - More details asked, obvious flaws [12]

v1
  - Me asking for better commit logs and some justifications [13][14][15]


TL; DR: there's not been any single iteration of those patches where
you wouldn't have ignored some comments made on a previous iteration,
despite for some patches numerous questions around the same points,
and with very significant time invested in this by numerous people
(Chen-Yu, myself and Paul to a lesser extent).

This is what was completely stalling your series, and I'm sure
frustrating both sides. You even acknowledged that in that mail:
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/632060.html

Yet, you submitted your v8 versions without taking our comments into
account.

> All these burst changes and random fixes are reviewed in couple of
> versions, now the versioning moved to v8[1] [2]. For each and every
> versioning I'm trying to fix the previous version comments, code
> improvements, commit messages. In fact for each rotation I'm trying to
> validate 4 different panels which eventually consume all my 16 

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[John Stultz]

On Wed, Feb 20, 2019 at 7:07 AM Brian Starkey  wrote:
>
> On Tue, Feb 19, 2019 at 01:47:36PM -0800, John Stultz wrote:
> > On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott  wrote:
> > >
> > > On 2/15/19 12:24 PM, John Stultz wrote:
> > > > The per-device heaps don't support HEAP_QUERY ioctl, since
> > > > the name is provided in the devnode path and the heapid isn't
> > > > useful with the new interface (one uses the fd of heapdevice).
> > > >
> > > > But, one missing bit of functionality is a way to find the
> > > > heap type. So provide a HEAP_INFO ioctl which exposes the
> > > > heap type out so there is the potential for some sort of
> > > > dynamic heap matching/discovery.
> > > >
> > > > Most likely this IOCTL will be useful when extended to allow
> > > > some sort of opaque constraint bitfield to be shared so userland
> > > > can match heaps with devices in a fully dynamic way.
> > > >
> > >
> > > We've been waiting on the constraint solving for a while and
> > > it's never really happened :(
> > >
> >
> > Yea. I'm not trying to open that up again.
> >
> > > It certainly works but I'm concerned about adding this and
> > > then finding (yet again) that it doesn't work. We're
> > > getting the heap name now but do we lose anything if we
> > > don't expose it as part of the ABI?
> >
> > Right. So all we're exporting in this patch is the heap_type. This was
> > somewhat of an afterthought for me, as practically, I suspect the
> > gralloc users of ion will know which heap they want by name, and won't
> > do any sort of dynamic heap finding.
> >
> > That said, ion's current API provides the QUERY interface which gives
> > you a list of heap ids/names/types, so if you wanted something that on
> > any random system was able to find a ION_HEAP_TYPE_DMA heap and use
> > it, you could.
> >
> > So this HEAP_INFO ioctl provides a way to do the same. That's it.
> >
> > That said, I could envision the ioctl to be extended (via the reserved
> > values) to provide some sort of constraint cookie to allow for
> > constraint solving, but that's still a unsolved issue at large.
> >
> > Given the handwaving at the constraints part, and that the heap type
> > is a pretty coarse grained enum (only 6 types, as of now - one being
> > catchall "custom"), I'm fine holding off on this bit unless folks
> > really see it as valuable.
>
> What do people think about putting the heap type into the device name?
> The whole query API is then replaced with `ls`

Hrm. I'm a bit hesitant on that, as that enshrines a naming convention as abi.

Also I personally don't think the heap-types are particularly well
defined. The memory itself is either contiguous or not, 32bit dma
accessible or not, etc. -  the specific implementation "type"
[system-contig, carveout, chunk, cma] isn't as useful from userland
other then conventions of how the heaps may be partitioned between
users.

So I'm probably happier to hide that detail.  If someone wants to do
dynamic heap discovery, we probably need a proper constraint solution.

For now, a potential generic gralloc would just have to have some
device specific policy file that defines which heap device to use for
which type of allocation it wants. Not completely unlike an fstab.

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

[Bug 109693] Hang of the graphics driver and assertion on si_upload_vertex_buffer_descriptors

[bugzilla-daemon]

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

Bug ID: 109693
   Summary: Hang of the graphics driver and assertion on
si_upload_vertex_buffer_descriptors
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jpetri...@gnome.org
QA Contact: dri-devel@lists.freedesktop.org

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

After this [1] commit, the GL tests we have on gstreamer started to causing a
hang in my machine (Gstreamer issue [2]). I was running mesa 18.2.8 and it was
constantly hanging upon running those specific tests. Once I upgraded to mesa
18.3.3 half the times it hangs and the other half it hits the following
assertion. Compiling and running against mesa 19.0 rc5 didn't change things.

pipelines_gl_launch_lines:
../src/gallium/drivers/radeonsi/si_descriptors.c:1150:
si_upload_vertex_buffer_descriptors: Assertion `num_records >= 0 && num_records
<= UINT_MAX' failed.

the whole log is [here] [3]

To reproduce you can run the following:

```
git clone https://gitlab.freedesktop.org/gstreamer/gst-build.git
cd gst-build
meson build -Dintrospection=disabled -Dgtk_doc=disabled -Dexamples=disabled
-Dsharp=disabled
ninja -C build/
./gst-uninstalled.py gst-validate-launcher check.gst-plugins-base.pipelines_gl*
-fs --mute --dump-on-failure --no-display --meson-no-rebuild -M
"/tmp/validate-output/"
```

gpu info:

lspci -v
04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven
Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c3) (prog-if 00
[VGA controller])
Subsystem: Lenovo Device 3801
Flags: bus master, fast devsel, latency 0, IRQ 71
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at d000 (64-bit, prefetchable) [size=2M]
I/O ports at 1000 [size=256]
Memory at d060 (32-bit, non-prefetchable) [size=512K]
Capabilities: 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

➜ glxinfo | grep 'OpenGL vendor'
OpenGL vendor string: X.Org


[1]:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/acc098a736949d465d7f77e5de94a75627209147
[2]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/543
[3]:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/543#note_121059

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

[Jani Nikula]

Hi Dave and Daniel, one final fix for v5.0, cc: stable.

BR,
Jani.

The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438:

  Linux 5.0-rc7 (2019-02-17 18:46:40 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-02-20

for you to fetch changes up to d179b88deb3bf6fed4991a31fd6f0f2cad21fab5:

  drm/i915/fbdev: Actually configure untiled displays (2019-02-20 16:02:55 
+0200)


drm/i915 fbdev takeover fix for v5.0


Chris Wilson (1):
  drm/i915/fbdev: Actually configure untiled displays

 drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/3] drm/vc4: Add a load tracker

[Eric Anholt]

Paul Kocialkowski  writes:

> Hi,
>
> Here is a fourth iteration of the VC4 load tracking series, which was
> initially developed by Boris Brezillon and that I have now taken over.
>
> This new iteration takes in account comments from v3 and comes with a
> new approach for avoiding underrun reports when reconfiguring the
> pipeline. It is now based on detection instead of delaying the underrun
> interrupt unmasking.
>
> It can be tested with a dedicated IGT GPU Tools series:
>   VC4 load tracker testing

Series is:

Reviewed-by: Eric Anholt 

Thanks for persisting on this!


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

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Kuehling, Felix]

On 2019-02-20 1:41 a.m., Thomas Hellstrom wrote:
> On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
>> On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
>>> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
 Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
>> Another good question is also why the heck the acc_size
>> counts
>> towards
>> the DMA32 zone?
> DMA32 TTM pages are accounted in the DMA32 zone. Other pages
> are
> not.
 Yeah, I'm perfectly aware of this. But this is for the accounting
 size!

 We have an accounting for the stuff needed additional to the
 pages
 backing the BO (e.g. the page and DMA addr array).

 And from the bug description it sounds like we use the DMA32 zone
 for
 this accounting which of course is completely nonsense.
>>> It's actually accounted in all available zones, since it would be
>>> pretty hard to determine exactly where that memory should be
>>> accounted.
>>> In particular if it's vmalloced. It might be DMA32, it might not.
>>> Given
>>> the objective of stopping malicious user-space from exhausting the
>>> DMA32 zone it was, at the time the code was written, a reasonable
>>> approximation. With ever increasing memory sizes, there might be
>>> better
>>> solutions?
>> As far as I can see, in TTM, ttm_mem_global_alloc is only used for
>> the
>> acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems
>> to
>> use it to account for a few things that are allocated with kmalloc.
>>
>> So would a better solution be to change ttm_mem_global_alloc to use
>> only
>> the kernel zone?
>>
> IMO we need to determine what functionality to keep and then the best
> solution. The current code does its job, but is obviously too
> restrictive. Both of the solutions you suggest open up for potential
> DOS attacks (DMA32 and kernel zones are not mutually exclusive. They
> overlap).
On x86 with HIGHMEM there is no dma32 zone. Why do we need one on 
x86_64? Can we make x86_64 more like HIGHMEM instead?

Regards,
   Felix


>
>
> /Thomas
>
>
>
>
>> Regards,
>> Felix
>>
>>
>>> /Thomas
>>>
 Christian.

> For small persistent allocations using ttm_mem_global_alloc(),
> they
> are
> accounted also in the DMA32 zone, which may cause over-
> accounting
> of
> that zone, but that's pretty unlikely to be a big problem..
>
> /Thomas
>
>
>
>
>
>> In other words why should the internal bookkeeping pages be
>> allocated
>> in
>> the DMA32 zone?
>>
>> That doesn't sounds valid to me in any way,
>> Christian.
>>
>> Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
>>> Hmm,
>>>
>>> This zone was intended to stop TTM page allocations from
>>> exhausting
>>> the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
>>> default,
>>> which
>>> means if we drop this check, other devices may stop
>>> functioning
>>> unexpectedly?
>>>
>>> However, in the end I'd expect the kernel page allocation
>>> system
>>> to
>>> make sure there are some pages left in the DMA32 zone,
>>> otherwise
>>> random non-IO page allocations would also potentially
>>> exhaust
>>> the
>>> DMA32 zone without anybody caring, which means removing
>>> this
>>> zone
>>> wouldn't be any worse than whatever other subsystems may be
>>> doing
>>> already...
>>>
>>> /Thomas
>>>
>>>
>>> On 2/16/19 12:02 AM, Kuehling, Felix wrote:
 This is an RFC. I'm not sure this is the right solution,
 but
 it
 highlights the problem I'm trying to solve.

 The dma32_zone limits the acc_size of all allocated BOs
 to
 2GB.
 On a
 64-bit system with hundreds of GB of system memory and
 GPU
 memory,
 this can become a bottle neck. We're seeing TTM memory
 allocation
 failures not because we're truly out of memory, but
 because
 we're
 out of space in the dma32_zone for the acc_size needed
 for
 our BO
 book-keeping.

 Signed-off-by: Felix Kuehling 
 CC: thellst...@vmware.com
 CC: christian.koe...@amd.com
 ---
  drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
 b/drivers/gpu/drm/ttm/ttm_memory.c
 index f1567c3..bb05365 100644
 --- a/drivers/gpu/drm/ttm/ttm_memory.c
 +++ b/drivers/gpu/drm/ttm/ttm_memory.c
 @@ -363,7 +363,7 @@ static int
 ttm_mem_init_highmem_zone(struct
 ttm_mem_global *glob,
  glob->zones[glob->num_zones++] = zone;
  return 0;
  }
 

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #1 from Andrey Grodzovsky  ---
Thanks, I will try to find time sometime soon to investigate this new deadlock.

-- 
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 v14 04/33] drm/i915: MEI interface implementation

[Daniel Vetter]

On Sat, Feb 16, 2019 at 11:06:51PM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
> 
> v2:
>   Adjust to the new interface changes. [Tomas]
>   Added further debug logs for the failures at MEI i/f.
>   port in hdcp_port data is equipped to handle -ve values.
> v3:
>   mei comp is matched for global i915 comp master. [Daniel]
>   In hdcp_shim hdcp_protocol() is replaced with const variable. [Daniel]
>   mei wrappers are adjusted as per the i/f change [Daniel]
> v4:
>   port initialization is done only at hdcp2_init only [Danvet]
> v5:
>   I915 registers a subcomponent to be matched with mei_hdcp [Daniel]
> v6:
>   HDCP_disable for all connectors incase of comp_unbind.
>   Tear down HDCP comp interface at i915_unload [Daniel]
> v7:
>   Component init and fini are moved out of connector ops [Daniel]
>   hdcp_disable is not called from unbind. [Daniel]
> v8:
>   subcomponent name is dropped as it is already merged.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter  [v11]

I think that r-b was for v7, not v8, and v11 of this patch doesn't even
exist. Series itself is as v14. Anyways, merged, thanks for all your work!
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.c|   1 +
>  drivers/gpu/drm/i915/i915_drv.h|   7 +
>  drivers/gpu/drm/i915/intel_connector.c |   2 +
>  drivers/gpu/drm/i915/intel_display.c   |   4 +
>  drivers/gpu/drm/i915/intel_drv.h   |   8 +
>  drivers/gpu/drm/i915/intel_hdcp.c  | 398 
> -
>  6 files changed, 419 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6630212f2faf..c6354f6cdbdb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -906,6 +906,7 @@ static int i915_driver_init_early(struct drm_i915_private 
> *dev_priv)
>   mutex_init(_priv->av_mutex);
>   mutex_init(_priv->wm.wm_mutex);
>   mutex_init(_priv->pps_mutex);
> + mutex_init(_priv->hdcp_comp_mutex);
>  
>   i915_memcpy_init_early(dev_priv);
>   intel_runtime_pm_init_early(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5c8d0489a1cd..d375d1cf86f5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_fixed.h"
>  #include "i915_params.h"
> @@ -2052,6 +2053,12 @@ struct drm_i915_private {
>  
>   struct i915_pmu pmu;
>  
> + struct i915_hdcp_comp_master *hdcp_master;
> + bool hdcp_comp_added;
> +
> + /* Mutex to protect the above hdcp component related values. */
> + struct mutex hdcp_comp_mutex;
> +
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> diff --git a/drivers/gpu/drm/i915/intel_connector.c 
> b/drivers/gpu/drm/i915/intel_connector.c
> index ee16758747c5..66ed3ee5998a 100644
> --- a/drivers/gpu/drm/i915/intel_connector.c
> +++ b/drivers/gpu/drm/i915/intel_connector.c
> @@ -88,6 +88,8 @@ void intel_connector_destroy(struct drm_connector 
> *connector)
>  
>   kfree(intel_connector->detect_edid);
>  
> + intel_hdcp_cleanup(intel_connector);
> +
>   if (!IS_ERR_OR_NULL(intel_connector->edid))
>   kfree(intel_connector->edid);
>  
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 73a107b6eb9a..acb993ce7eaa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15453,6 +15453,8 @@ int intel_modeset_init(struct drm_device *dev)
>   intel_update_czclk(dev_priv);
>   intel_modeset_init_hw(dev);
>  
> + intel_hdcp_component_init(dev_priv);
> +
>   if (dev_priv->max_cdclk_freq == 0)
>   intel_update_max_cdclk(dev_priv);
>  
> @@ -16314,6 +16316,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>   /* flush any delayed tasks or pending work */
>   flush_scheduled_work();
>  
> + intel_hdcp_component_fini(dev_priv);
> +
>   drm_mode_config_cleanup(dev);
>  
>   intel_overlay_cleanup(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 11c696025085..f8e8482573c8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct drm_printer;
> @@ -395,6 +396,9 @@ struct intel_hdcp_shim {
>   /* Detects panel's hdcp capability. This is optional for HDMI. */
>   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
>   bool *hdcp_capable);
> +
> + /* HDCP adaptation(DP/HDMI) required on the port */
> + enum hdcp_wired_protocol protocol;
>  };
>  
>  struct intel_hdcp {
> @@ -415,6 

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #2 from Andrey Grodzovsky  ---
Is this deadlock happens to you always now or only sometimes ?

-- 
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 v14 16/33] drm/i915: Fix KBL HDCP2.2 encrypt status signalling

[Daniel Vetter]

On Sat, Feb 16, 2019 at 11:07:03PM +0530, Ramalingam C wrote:
> HDCP transmitter is supposed to indicate the HDCP encryption status of
> the link through enc_en signals in a window of time called "window of
> opportunity" defined by HDCP HDMI spec.
> 
> But on KBL this timing of signalling has an issue. To fix the issue this
> WA of resetting the signalling is required.
> 
> v2:
>   WA is moved into the toggle_signalling [Daniel]
> v3:
>   Commit msg is rewritten with more information
> v4:
>   Reviewed-by Daniel.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 

Merged all the i915 patches to dinq for 5.2.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 42 
> +++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 6a3e400f54d7..c2c91e6645a5 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct 
> intel_digital_port *intel_dig_port,
>   return ret;
>  }
>  
> +static int kbl_repositioning_enc_en_signal(struct intel_connector *connector)
> +{
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct drm_crtc *crtc = connector->base.state->crtc;
> + struct intel_crtc *intel_crtc = container_of(crtc,
> +  struct intel_crtc, base);
> + u32 scanline;
> + int ret;
> +
> + for (;;) {
> + scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
> + if (scanline > 100 && scanline < 200)
> + break;
> + usleep_range(25, 50);
> + }
> +
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, false);
> + if (ret) {
> + DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
> + return ret;
> + }
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base, true);
> + if (ret) {
> + DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static
>  int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port 
> *intel_dig_port,
> bool enable)
>  {
> + struct intel_hdmi *hdmi = _dig_port->hdmi;
> + struct intel_connector *connector = hdmi->attached_connector;
> + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   int ret;
>  
>   if (!enable)
> @@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct 
> intel_digital_port *intel_dig_port,
> enable ? "Enable" : "Disable", ret);
>   return ret;
>   }
> +
> + /*
> +  * WA: To fix incorrect positioning of the window of
> +  * opportunity and enc_en signalling in KABYLAKE.
> +  */
> + if (IS_KABYLAKE(dev_priv) && enable)
> + return kbl_repositioning_enc_en_signal(connector);
> +
>   return 0;
>  }
>  
> -- 
> 2.7.4
> 

-- 
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: [RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

[Ira Weiny]

On Wed, Feb 20, 2019 at 07:19:30AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny 
> > 
> > Resending these as I had only 1 minor comment which I believe we have 
> > covered
> > in this series.  I was anticipating these going through the mm tree as they
> > depend on a cleanup patch there and the IB changes are very minor.  But they
> > could just as well go through the IB tree.
> > 
> > NOTE: This series depends on my clean up patch to remove the write parameter
> > from gup_fast_permitted()[1]
> > 
> > HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> > advantages.  These pages can be held for a significant time.  But
> > get_user_pages_fast() does not protect against mapping of FS DAX pages.
> 
> This I don't get - if you do lock down long term mappings performance
> of the actual get_user_pages call shouldn't matter to start with.
> 
> What do I miss?

A couple of points.

First "longterm" is a relative thing and at this point is probably a misnomer.
This is really flagging a pin which is going to be given to hardware and can't
move.  I've thought of a couple of alternative names but I think we have to
settle on if we are going to use FL_LAYOUT or something else to solve the
"longterm" problem.  Then I think we can change the flag to a better name.

Second, It depends on how often you are registering memory.  I have spoken with
some RDMA users who consider MR in the performance path...  For the overall
application performance.  I don't have the numbers as the tests for HFI1 were
done a long time ago.  But there was a significant advantage.  Some of which is
probably due to the fact that you don't have to hold mmap_sem.

Finally, architecturally I think it would be good for everyone to use *_fast.
There are patches submitted to the RDMA list which would allow the use of
*_fast (they reworking the use of mmap_sem) and as soon as they are accepted
I'll submit a patch to convert the RDMA core as well.  Also to this point
others are looking to use *_fast.[2]

As an asside, Jasons pointed out in my previous submission that *_fast and
*_unlocked look very much the same.  I agree and I think further cleanup will
be coming.  But I'm focused on getting the final solution for DAX at the
moment.

Ira

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

Re: [PATCH V5 5/8] clk: mediatek: add MUX_GATE_FLAGS_2

[Stephen Boyd]

Quoting wangyan wang (2019-02-19 18:53:54)
> From: chunhui dai 
> 
> Add MUX_GATE_FLAGS_2 for the clock which needs to set two falgs.

s/falgs/flags/

> Such as some mux need to set the flags of "CLK_MUX_ROUND_CLOSEST".
> 
> Signed-off-by: chunhui dai 
> Signed-off-by: wangyan wang 
> ---
>  drivers/clk/mediatek/clk-mtk.c |  2 +-
>  drivers/clk/mediatek/clk-mtk.h | 20 ++--
>  2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 9c0ae4278a94..2ed996404804 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -167,7 +167,7 @@ struct clk *mtk_clk_register_composite(const struct 
> mtk_composite *mc,
> mux->mask = BIT(mc->mux_width) - 1;
> mux->shift = mc->mux_shift;
> mux->lock = lock;
> -
> +   mux->flags = mc->mux_flags;
> mux_hw = >hw;
> mux_ops = _mux_ops;
>  
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index f83c2bbb677e..4b88d196d52f 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -81,15 +81,13 @@ struct mtk_composite {
> signed char divider_shift;
> signed char divider_width;
>  
> +   unsigned char mux_flags;

Why isn't it an unsigned long? Isn't this supposed to match the
frameworks version of the clk flags?

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

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

Bug ID: 109695
   Summary: qemu using spice gl and sandbox resourcecontrol=deny
crashes with SIGSYS on radeonsi
   Product: Mesa
   Version: 18.3
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: a...@tutanota.com
QA Contact: dri-devel@lists.freedesktop.org

Since upgrading Mesa from 18.2 to 18.3, launching a QEMU virtual machine with
Spice OpenGL enabled (for virgl), causes QEMU to crash with SIGSYS inside the
radeonsi driver. The reason for this is that the QEMU sandbox option
'resourcecontrol=deny' disables the sched_setaffinity syscall called in
pthread_setaffinity_np, which is now used by the radeonsi driver.

A simple way to reproduce this problem is:
$ gdb --batch --ex run --ex bt --args qemu-system-x86_64 -spice gl=on -sandbox
on,resourcecontrol=deny
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x745aa700 (LWP 23432)]
[New Thread 0x708e5700 (LWP 23433)]
[New Thread 0x7fffe3fff700 (LWP 23434)]
[New Thread 0x7fffe37fe700 (LWP 23435)]

Thread 4 "qemu-system-x86" received signal SIGSYS, Bad system call.
[Switching to Thread 0x7fffe3fff700 (LWP 23434)]
0x768cc9cf in __pthread_setaffinity_new (th=,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
34  ../sysdeps/unix/sysv/linux/pthread_setaffinity.c: No such file or
directory.
#0  0x768cc9cf in __pthread_setaffinity_new (th=,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
#1  0x712ba2b3 in util_queue_thread_func
(input=input@entry=0x5640b1f0) at ../src/util/u_queue.c:252
#2  0x712b9c17 in impl_thrd_routine (p=) at
../src/../include/c11/threads_posix.h:87
#3  0x768c1fa3 in start_thread (arg=) at
pthread_create.c:486
#4  0x767f280f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


The problematic code at src/util/u_queue.c:252 was added in the following
commit:
commit d877451b48a59ab0f9a4210fc736f51da5851c9a
Author: Marek Olšák 
Date:   Mon Oct 1 15:51:06 2018 -0400

util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY

Initial version discussed with Rob Clark under a different patch name.
This approach leaves his driver unaffected.


Since setting the thread affinity seems non-essential here, the failing syscall
should be handled gracefully, for example by setting a signal handler to ignore
the SIGSYS signal.

-- 
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] mm: Don't let userspace spam allocations warnings

[Daniel Vetter]

memdump_user usually gets fed unchecked userspace input. Blasting a
full backtrace into dmesg every time is a bit excessive - I'm not sure
on the kernel rule in general, but at least in drm we're trying not to
let unpriviledge userspace spam the logs freely. Definitely not entire
warning backtraces.

It also means more filtering for our CI, because our testsuite
exercises these corner cases and so hits these a lot.

Signed-off-by: Daniel Vetter 
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Michal Hocko 
Cc: Roman Gushchin 
Cc: Vlastimil Babka 
Cc: Jan Stancek 
Cc: Kees Cook 
Cc: Andrey Ryabinin 
Cc: "Michael S. Tsirkin" 
Cc: Huang Ying 
Cc: Bartosz Golaszewski 
Cc: linux...@kvack.org
---
 mm/util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/util.c b/mm/util.c
index 1ea055138043..379319b1bcfd 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -150,7 +150,7 @@ void *memdup_user(const void __user *src, size_t len)
 {
void *p;
 
-   p = kmalloc_track_caller(len, GFP_USER);
+   p = kmalloc_track_caller(len, GFP_USER | __GFP_NOWARN);
if (!p)
return ERR_PTR(-ENOMEM);
 
-- 
2.20.1

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

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 143423
  --> https://bugs.freedesktop.org/attachment.cgi?id=143423=edit
yet another 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 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 143422
  --> https://bugs.freedesktop.org/attachment.cgi?id=143422=edit
yet another 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 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #6 from Andrey Grodzovsky  ---
(In reply to Andrey Grodzovsky from comment #2)
> Is this deadlock happens to you always now or only sometimes ?

I think i see the problem but not sure yet how to fix it.

-- 
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 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #17 from Harry Wentland  ---
I don't have that laptop but this link mentions a method to "Update the BIOS
when Windows does not start": https://support.hp.com/ca-en/document/c00042629

I'd be more curious to know if the patch I posted fixes it.

-- 
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] mm: Don't let userspace spam allocations warnings

[Michal Hocko]

On Wed 20-02-19 21:40:58, Daniel Vetter wrote:
> memdump_user usually gets fed unchecked userspace input. Blasting a
> full backtrace into dmesg every time is a bit excessive - I'm not sure
> on the kernel rule in general, but at least in drm we're trying not to
> let unpriviledge userspace spam the logs freely. Definitely not entire
> warning backtraces.

Yes, this makes sense to me. This API sounds like an example where
returning ENOMEM to the userspace right away is much better than
spamming the log for large allocation requests. Smaller allocations
simply do not fail and the OOM killer report will be printed regardless
of __GFP_NOWARN.

> It also means more filtering for our CI, because our testsuite
> exercises these corner cases and so hits these a lot.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Andrew Morton 
> Cc: Mike Rapoport 
> Cc: Michal Hocko 
> Cc: Roman Gushchin 
> Cc: Vlastimil Babka 
> Cc: Jan Stancek 
> Cc: Kees Cook 
> Cc: Andrey Ryabinin 
> Cc: "Michael S. Tsirkin" 
> Cc: Huang Ying 
> Cc: Bartosz Golaszewski 
> Cc: linux...@kvack.org

Acked-by: Michal Hocko 

> ---
>  mm/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/util.c b/mm/util.c
> index 1ea055138043..379319b1bcfd 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -150,7 +150,7 @@ void *memdup_user(const void __user *src, size_t len)
>  {
>   void *p;
>  
> - p = kmalloc_track_caller(len, GFP_USER);
> + p = kmalloc_track_caller(len, GFP_USER | __GFP_NOWARN);
>   if (!p)
>   return ERR_PTR(-ENOMEM);
>  
> -- 
> 2.20.1
> 

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

[PATCH 6/7] drm/vc4: Add helpers for pm get/put.

[Eric Anholt]

This makes sure the vc4_reset doesn't hit an obscure race with the
GET_PARAM ioctl, fixes a decrement outside of the lock, and prevents
future code from making mistakes with the weird return value of
pm_runtime_get_sync().

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 21 +
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_gem.c | 21 +
 drivers/gpu/drm/vc4/vc4_v3d.c | 33 +
 4 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index de1d0ce11831..f95891a61d52 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -77,28 +77,25 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
 
switch (args->param) {
case DRM_VC4_PARAM_V3D_IDENT0:
-   ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret < 0)
+   ret = vc4_v3d_pm_get(vc4);
+   if (ret)
return ret;
args->value = V3D_READ(V3D_IDENT0);
-   pm_runtime_mark_last_busy(>v3d->pdev->dev);
-   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   vc4_v3d_pm_put(vc4);
break;
case DRM_VC4_PARAM_V3D_IDENT1:
-   ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret < 0)
+   ret = vc4_v3d_pm_get(vc4);
+   if (ret)
return ret;
args->value = V3D_READ(V3D_IDENT1);
-   pm_runtime_mark_last_busy(>v3d->pdev->dev);
-   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   vc4_v3d_pm_put(vc4);
break;
case DRM_VC4_PARAM_V3D_IDENT2:
-   ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret < 0)
+   ret = vc4_v3d_pm_get(vc4);
+   if (ret)
return ret;
args->value = V3D_READ(V3D_IDENT2);
-   pm_runtime_mark_last_busy(>v3d->pdev->dev);
-   pm_runtime_put_autosuspend(>v3d->pdev->dev);
+   vc4_v3d_pm_put(vc4);
break;
case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
case DRM_VC4_PARAM_SUPPORTS_ETC1:
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 495c5a13a948..c71988b270bc 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -809,6 +809,8 @@ void vc4_plane_async_set_fb(struct drm_plane *plane,
 /* vc4_v3d.c */
 extern struct platform_driver vc4_v3d_driver;
 int vc4_v3d_get_bin_slot(struct vc4_dev *vc4);
+int vc4_v3d_pm_get(struct vc4_dev *vc4);
+void vc4_v3d_pm_put(struct vc4_dev *vc4);
 
 /* vc4_validate.c */
 int
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 8d816e5ed762..4544a478f106 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -969,12 +969,7 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
/* Release the reference we had on the perf monitor. */
vc4_perfmon_put(exec->perfmon);
 
-   mutex_lock(>power_lock);
-   if (--vc4->power_refcount == 0) {
-   pm_runtime_mark_last_busy(>v3d->pdev->dev);
-   pm_runtime_put_autosuspend(>v3d->pdev->dev);
-   }
-   mutex_unlock(>power_lock);
+   vc4_v3d_pm_put(vc4);
 
kfree(exec);
 }
@@ -1153,17 +1148,11 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
return -ENOMEM;
}
 
-   mutex_lock(>power_lock);
-   if (vc4->power_refcount++ == 0) {
-   ret = pm_runtime_get_sync(>v3d->pdev->dev);
-   if (ret < 0) {
-   mutex_unlock(>power_lock);
-   vc4->power_refcount--;
-   kfree(exec);
-   return ret;
-   }
+   ret = vc4_v3d_pm_get(vc4);
+   if (ret) {
+   kfree(exec);
+   return ret;
}
-   mutex_unlock(>power_lock);
 
exec->args = args;
INIT_LIST_HEAD(>unref_list);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index f008584eb739..7820b8eaaa98 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -124,6 +124,39 @@ static int vc4_v3d_debugfs_ident(struct seq_file *m, void 
*unused)
return 0;
 }
 
+/**
+ * Wraps pm_runtime_get_sync() in a refcount, so that we can reliably
+ * get the pm_runtime refcount to 0 in vc4_reset().
+ */
+int
+vc4_v3d_pm_get(struct vc4_dev *vc4)
+{
+   mutex_lock(>power_lock);
+   if (vc4->power_refcount++ == 0) {
+   int ret = pm_runtime_get_sync(>v3d->pdev->dev);
+
+   if (ret < 0) {
+   vc4->power_refcount--;
+   mutex_unlock(>power_lock);
+   return ret;
+   }
+   

[PATCH 2/7] drm/vc4: Use drm_print_regset32() for our debug register dumping.

[Eric Anholt]

This removes a bunch of duplicated boilerplate for the debugfs vs
runtime printk debug dumping.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_crtc.c |  68 ++---
 drivers/gpu/drm/vc4/vc4_dpi.c  |  23 ++---
 drivers/gpu/drm/vc4/vc4_drv.h  |   7 ++
 drivers/gpu/drm/vc4/vc4_dsi.c  | 155 +
 drivers/gpu/drm/vc4/vc4_hdmi.c | 156 +
 drivers/gpu/drm/vc4/vc4_hvs.c  |  87 -
 drivers/gpu/drm/vc4/vc4_txp.c  |  28 +++---
 drivers/gpu/drm/vc4/vc4_v3d.c  | 173 -
 drivers/gpu/drm/vc4/vc4_vec.c  |  67 ++---
 9 files changed, 350 insertions(+), 414 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 730008d3da76..6d7072026056 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -67,43 +68,29 @@ to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
 #define CRTC_WRITE(offset, val) writel(val, vc4_crtc->regs + (offset))
 #define CRTC_READ(offset) readl(vc4_crtc->regs + (offset))
 
-#define CRTC_REG(reg) { reg, #reg }
-static const struct {
-   u32 reg;
-   const char *name;
-} crtc_regs[] = {
-   CRTC_REG(PV_CONTROL),
-   CRTC_REG(PV_V_CONTROL),
-   CRTC_REG(PV_VSYNCD_EVEN),
-   CRTC_REG(PV_HORZA),
-   CRTC_REG(PV_HORZB),
-   CRTC_REG(PV_VERTA),
-   CRTC_REG(PV_VERTB),
-   CRTC_REG(PV_VERTA_EVEN),
-   CRTC_REG(PV_VERTB_EVEN),
-   CRTC_REG(PV_INTEN),
-   CRTC_REG(PV_INTSTAT),
-   CRTC_REG(PV_STAT),
-   CRTC_REG(PV_HACT_ACT),
+static const struct debugfs_reg32 crtc_regs[] = {
+   VC4_REG32(PV_CONTROL),
+   VC4_REG32(PV_V_CONTROL),
+   VC4_REG32(PV_VSYNCD_EVEN),
+   VC4_REG32(PV_HORZA),
+   VC4_REG32(PV_HORZB),
+   VC4_REG32(PV_VERTA),
+   VC4_REG32(PV_VERTB),
+   VC4_REG32(PV_VERTA_EVEN),
+   VC4_REG32(PV_VERTB_EVEN),
+   VC4_REG32(PV_INTEN),
+   VC4_REG32(PV_INTSTAT),
+   VC4_REG32(PV_STAT),
+   VC4_REG32(PV_HACT_ACT),
 };
 
-static void vc4_crtc_dump_regs(struct vc4_crtc *vc4_crtc)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(crtc_regs); i++) {
-   DRM_INFO("0x%04x (%s): 0x%08x\n",
-crtc_regs[i].reg, crtc_regs[i].name,
-CRTC_READ(crtc_regs[i].reg));
-   }
-}
-
 #ifdef CONFIG_DEBUG_FS
 int vc4_crtc_debugfs_regs(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
int crtc_index = (uintptr_t)node->info_ent->data;
+   struct drm_printer p = drm_seq_file_printer(m);
struct drm_crtc *crtc;
struct vc4_crtc *vc4_crtc;
int i;
@@ -118,11 +105,7 @@ int vc4_crtc_debugfs_regs(struct seq_file *m, void *unused)
return 0;
vc4_crtc = to_vc4_crtc(crtc);
 
-   for (i = 0; i < ARRAY_SIZE(crtc_regs); i++) {
-   seq_printf(m, "%s (0x%04x): 0x%08x\n",
-  crtc_regs[i].name, crtc_regs[i].reg,
-  CRTC_READ(crtc_regs[i].reg));
-   }
+   drm_print_regset32(, _crtc->regset);
 
return 0;
 }
@@ -434,8 +417,10 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
bool debug_dump_regs = false;
 
if (debug_dump_regs) {
-   DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
-   vc4_crtc_dump_regs(vc4_crtc);
+   struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
+   dev_info(_crtc->pdev->dev, "CRTC %d regs before:\n",
+drm_crtc_index(crtc));
+   drm_print_regset32(, _crtc->regset);
}
 
if (vc4_crtc->channel == 2) {
@@ -476,8 +461,10 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
vc4_crtc_lut_load(crtc);
 
if (debug_dump_regs) {
-   DRM_INFO("CRTC %d regs after:\n", drm_crtc_index(crtc));
-   vc4_crtc_dump_regs(vc4_crtc);
+   struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
+   dev_info(_crtc->pdev->dev, "CRTC %d regs after:\n",
+drm_crtc_index(crtc));
+   drm_print_regset32(, _crtc->regset);
}
 }
 
@@ -1169,11 +1156,16 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
if (!match)
return -ENODEV;
vc4_crtc->data = match->data;
+   vc4_crtc->pdev = pdev;
 
vc4_crtc->regs = vc4_ioremap_regs(pdev, 0);
if (IS_ERR(vc4_crtc->regs))
return PTR_ERR(vc4_crtc->regs);
 
+   vc4_crtc->regset.base = vc4_crtc->regs;
+   vc4_crtc->regset.regs = crtc_regs;
+   vc4_crtc->regset.nregs = ARRAY_SIZE(crtc_regs);
+
/* For now, we create just the primary and the legacy cursor
   

[PATCH 3/7] drm/vc4: Use common helpers for debugfs setup by the driver components.

[Eric Anholt]

The global list of all debugfs entries for the driver was painful: the
list couldn't see into the components' structs, so each component had
its own debugs show function to find the component, then find the
regset and dump it.  The components also had to be careful to check
that they were actually registered in vc4 before dereferencing
themselves, in case they weren't probed on a particular platform.
They routinely failed at that.

Instead, we can have the components add their debugfs callbacks to a
little list in vc4 to be registered at drm_dev_register() time, which
gets vc4_debugfs.c out of the business of knowing the whole list of
components.

Thanks to this change, dsi0 (if it existed) would register its node.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c  |  6 +--
 drivers/gpu/drm/vc4/vc4_crtc.c| 33 +++-
 drivers/gpu/drm/vc4/vc4_debugfs.c | 84 ---
 drivers/gpu/drm/vc4/vc4_dpi.c | 20 +---
 drivers/gpu/drm/vc4/vc4_drv.c |  1 +
 drivers/gpu/drm/vc4/vc4_drv.h | 38 ++
 drivers/gpu/drm/vc4/vc4_dsi.c | 24 ++---
 drivers/gpu/drm/vc4/vc4_hdmi.c|  6 +--
 drivers/gpu/drm/vc4/vc4_hvs.c | 16 +-
 drivers/gpu/drm/vc4/vc4_txp.c | 20 +---
 drivers/gpu/drm/vc4/vc4_v3d.c | 19 ++-
 drivers/gpu/drm/vc4/vc4_vec.c | 20 +---
 12 files changed, 125 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 92e3f98d8478..8c509d560bf0 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -66,8 +66,7 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
mutex_unlock(>purgeable.lock);
 }
 
-#ifdef CONFIG_DEBUG_FS
-int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
+static int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
@@ -99,7 +98,6 @@ int vc4_bo_stats_debugfs(struct seq_file *m, void *unused)
 
return 0;
 }
-#endif
 
 /* Takes ownership of *name and returns the appropriate slot for it in
  * the bo_labels[] array, extending it as necessary.
@@ -1025,6 +1023,8 @@ int vc4_bo_cache_init(struct drm_device *dev)
 
mutex_init(>bo_lock);
 
+   vc4_debugfs_add_file(dev, "bo_stats", vc4_bo_stats_debugfs, NULL);
+
INIT_LIST_HEAD(>bo_cache.time_list);
 
INIT_WORK(>bo_cache.time_work, vc4_bo_cache_time_work);
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 6d7072026056..9a62f12aca54 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -84,33 +84,6 @@ static const struct debugfs_reg32 crtc_regs[] = {
VC4_REG32(PV_HACT_ACT),
 };
 
-#ifdef CONFIG_DEBUG_FS
-int vc4_crtc_debugfs_regs(struct seq_file *m, void *unused)
-{
-   struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct drm_device *dev = node->minor->dev;
-   int crtc_index = (uintptr_t)node->info_ent->data;
-   struct drm_printer p = drm_seq_file_printer(m);
-   struct drm_crtc *crtc;
-   struct vc4_crtc *vc4_crtc;
-   int i;
-
-   i = 0;
-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   if (i == crtc_index)
-   break;
-   i++;
-   }
-   if (!crtc)
-   return 0;
-   vc4_crtc = to_vc4_crtc(crtc);
-
-   drm_print_regset32(, _crtc->regset);
-
-   return 0;
-}
-#endif
-
 bool vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id,
 bool in_vblank_irq, int *vpos, int *hpos,
 ktime_t *stime, ktime_t *etime,
@@ -1062,6 +1035,7 @@ static const struct drm_crtc_helper_funcs 
vc4_crtc_helper_funcs = {
 
 static const struct vc4_crtc_data pv0_data = {
.hvs_channel = 0,
+   .debugfs_name = "crtc0_regs",
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI0,
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_DPI,
@@ -1070,6 +1044,7 @@ static const struct vc4_crtc_data pv0_data = {
 
 static const struct vc4_crtc_data pv1_data = {
.hvs_channel = 2,
+   .debugfs_name = "crtc1_regs",
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI1,
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_SMI,
@@ -1078,6 +1053,7 @@ static const struct vc4_crtc_data pv1_data = {
 
 static const struct vc4_crtc_data pv2_data = {
.hvs_channel = 1,
+   .debugfs_name = "crtc2_regs",
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_HDMI,
[PV_CONTROL_CLK_SELECT_VEC] = VC4_ENCODER_TYPE_VEC,
@@ -1239,6 +1215,9 @@ static int vc4_crtc_bind(struct device *dev, struct 
device *master, void *data)
 

[PATCH 7/7] drm/vc4: Make sure that the v3d ident debugfs has vc4's power on.

[Eric Anholt]

Otherwise, you sometimes decode the ident fields based on 0xdeadbeef
register reads.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_v3d.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 7820b8eaaa98..36e6c7086ecf 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -108,18 +108,23 @@ static int vc4_v3d_debugfs_ident(struct seq_file *m, void 
*unused)
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   uint32_t ident1 = V3D_READ(V3D_IDENT1);
-   uint32_t nslc = VC4_GET_FIELD(ident1, V3D_IDENT1_NSLC);
-   uint32_t tups = VC4_GET_FIELD(ident1, V3D_IDENT1_TUPS);
-   uint32_t qups = VC4_GET_FIELD(ident1, V3D_IDENT1_QUPS);
-
-   seq_printf(m, "Revision:   %d\n",
-  VC4_GET_FIELD(ident1, V3D_IDENT1_REV));
-   seq_printf(m, "Slices: %d\n", nslc);
-   seq_printf(m, "TMUs:   %d\n", nslc * tups);
-   seq_printf(m, "QPUs:   %d\n", nslc * qups);
-   seq_printf(m, "Semaphores: %d\n",
-  VC4_GET_FIELD(ident1, V3D_IDENT1_NSEM));
+   int ret = vc4_v3d_pm_get(vc4);
+
+   if (ret == 0) {
+   uint32_t ident1 = V3D_READ(V3D_IDENT1);
+   uint32_t nslc = VC4_GET_FIELD(ident1, V3D_IDENT1_NSLC);
+   uint32_t tups = VC4_GET_FIELD(ident1, V3D_IDENT1_TUPS);
+   uint32_t qups = VC4_GET_FIELD(ident1, V3D_IDENT1_QUPS);
+
+   seq_printf(m, "Revision:   %d\n",
+  VC4_GET_FIELD(ident1, V3D_IDENT1_REV));
+   seq_printf(m, "Slices: %d\n", nslc);
+   seq_printf(m, "TMUs:   %d\n", nslc * tups);
+   seq_printf(m, "QPUs:   %d\n", nslc * qups);
+   seq_printf(m, "Semaphores: %d\n",
+  VC4_GET_FIELD(ident1, V3D_IDENT1_NSEM));
+   vc4_v3d_pm_put(vc4);
+   }
 
return 0;
 }
-- 
2.20.1

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

[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"

[bugzilla-daemon]

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

--- Comment #16 from Michael A. Leonetti (mikealeone...@gmail.com) ---
Created attachment 281247
  --> https://bugzilla.kernel.org/attachment.cgi?id=281247=edit
dmesg 4.18.0 with debugs

Did I do this correctly? I see a lot more call track information in this file.

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

[PATCH 1/7] drm: Add a helper function for printing a debugfs_regset32.

[Eric Anholt]

The debugfs_regset32 is nice to use for reducing boilerplate in
dumping a bunch of regs in debugfs, but we also want to be able to
print to dmesg them at runtime for driver debugging.  drm_printer lets
us format debugfs and the printk the same way.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/drm_print.c | 16 
 include/drm/drm_print.h |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 0e7fc3e7dfb4..5ecc0f04cd0c 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -253,3 +253,19 @@ void drm_err(const char *format, ...)
va_end(args);
 }
 EXPORT_SYMBOL(drm_err);
+
+void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32 *regset)
+{
+   int namelen = 0;
+   int i;
+
+   for (i = 0; i < regset->nregs; i++)
+   namelen = max(namelen, (int)strlen(regset->regs[i].name));
+
+   for (i = 0; i < regset->nregs; i++) {
+   drm_printf(p, "%*s = 0x%08x\n",
+  namelen, regset->regs[i].name,
+  readl(regset->base + regset->regs[i].offset));
+   }
+}
+EXPORT_SYMBOL(drm_print_regset32);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index afbc3beef089..3a4247319e63 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: print
@@ -84,6 +85,7 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 void drm_puts(struct drm_printer *p, const char *str);
+void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32 
*regset);
 
 __printf(2, 0)
 /**
-- 
2.20.1

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

[PATCH 5/7] drm/vc4: Disable V3D interactions if the v3d component didn't probe.

[Eric Anholt]

One might want to use the VC4 display stack without using Mesa.
Similar to the debugfs fixes for not having all of the possible
display bits enabled, make sure you can't oops in vc4 if v3d isn't
enabled.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 11 +++
 drivers/gpu/drm/vc4/vc4_gem.c | 10 ++
 drivers/gpu/drm/vc4/vc4_irq.c |  9 +
 drivers/gpu/drm/vc4/vc4_perfmon.c | 18 ++
 4 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 1927d1b756f5..de1d0ce11831 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -72,6 +72,9 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
if (args->pad != 0)
return -EINVAL;
 
+   if (!vc4->v3d)
+   return -EINVAL;
+
switch (args->param) {
case DRM_VC4_PARAM_V3D_IDENT0:
ret = pm_runtime_get_sync(>v3d->pdev->dev);
@@ -251,6 +254,7 @@ static int vc4_drm_bind(struct device *dev)
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm;
struct vc4_dev *vc4;
+   struct device_node *node;
int ret = 0;
 
dev->coherent_dma_mask = DMA_BIT_MASK(32);
@@ -259,6 +263,13 @@ static int vc4_drm_bind(struct device *dev)
if (!vc4)
return -ENOMEM;
 
+   /* If VC4 V3D is missing, don't advertise render nodes. */
+   node = of_find_compatible_node(NULL, NULL, "brcm,bcm2835-v3d");
+   if (node)
+   of_node_put(node);
+   else
+   vc4_drm_driver.driver_features &= ~DRIVER_RENDER;
+
drm = drm_dev_alloc(_drm_driver, dev);
if (IS_ERR(drm))
return PTR_ERR(drm);
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 5ee5bf7fedf7..8d816e5ed762 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -74,6 +74,11 @@ vc4_get_hang_state_ioctl(struct drm_device *dev, void *data,
u32 i;
int ret = 0;
 
+   if (!vc4->v3d) {
+   DRM_DEBUG("VC4_GET_HANG_STATE with no VC4 V3D probed\n");
+   return -EINVAL;
+   }
+
spin_lock_irqsave(>job_lock, irqflags);
kernel_state = vc4->hang_state;
if (!kernel_state) {
@@ -1124,6 +1129,11 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct dma_fence *in_fence;
int ret = 0;
 
+   if (!vc4->v3d) {
+   DRM_DEBUG("VC4_SUBMIT_CL with no VC4 V3D probed\n");
+   return -EINVAL;
+   }
+
if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
 VC4_SUBMIT_CL_FIXED_RCL_ORDER |
 VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
diff --git a/drivers/gpu/drm/vc4/vc4_irq.c b/drivers/gpu/drm/vc4/vc4_irq.c
index 4cd2ccfe15f4..ffd0a4388752 100644
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -229,6 +229,9 @@ vc4_irq_preinstall(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
+   if (!vc4->v3d)
+   return;
+
init_waitqueue_head(>job_wait_queue);
INIT_WORK(>overflow_mem_work, vc4_overflow_mem_work);
 
@@ -243,6 +246,9 @@ vc4_irq_postinstall(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
+   if (!vc4->v3d)
+   return 0;
+
/* Enable both the render done and out of memory interrupts. */
V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS);
 
@@ -254,6 +260,9 @@ vc4_irq_uninstall(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
+   if (!vc4->v3d)
+   return;
+
/* Disable sending interrupts for our driver's IRQs. */
V3D_WRITE(V3D_INTDIS, V3D_DRIVER_IRQS);
 
diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c 
b/drivers/gpu/drm/vc4/vc4_perfmon.c
index 495150415020..6562d3d30b20 100644
--- a/drivers/gpu/drm/vc4/vc4_perfmon.c
+++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
@@ -100,12 +100,18 @@ void vc4_perfmon_close_file(struct vc4_file *vc4file)
 int vc4_perfmon_create_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_file *vc4file = file_priv->driver_priv;
struct drm_vc4_perfmon_create *req = data;
struct vc4_perfmon *perfmon;
unsigned int i;
int ret;
 
+   if (!vc4->v3d) {
+   DRM_DEBUG("Creating perfmon no VC4 V3D probed\n");
+   return -EINVAL;
+   }
+
/* Number of monitored counters cannot exceed HW limits. */
if (req->ncounters > DRM_VC4_MAX_PERF_COUNTERS ||
!req->ncounters)
@@ -146,10 +152,16 @@ int vc4_perfmon_create_ioctl(struct drm_device *dev, void 
*data,
 int vc4_perfmon_destroy_ioctl(struct drm_device *dev, void *data,
  struct drm_file 

[PATCH 4/7] drm/vc4: Use drm_printer for the debugfs and runtime bo stats output.

[Eric Anholt]

Now I can extend the stats without more copy and pasting between the
two.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_bo.c | 48 +++-
 1 file changed, 14 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 8c509d560bf0..88ebd681d7eb 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -40,7 +40,7 @@ static bool is_user_label(int label)
return label >= VC4_BO_TYPE_COUNT;
 }
 
-static void vc4_bo_stats_dump(struct vc4_dev *vc4)
+static void vc4_bo_stats_print(struct drm_printer *p, struct vc4_dev *vc4)
 {
int i;
 
@@ -48,21 +48,21 @@ static void vc4_bo_stats_dump(struct vc4_dev *vc4)
if (!vc4->bo_labels[i].num_allocated)
continue;
 
-   DRM_INFO("%30s: %6dkb BOs (%d)\n",
-vc4->bo_labels[i].name,
-vc4->bo_labels[i].size_allocated / 1024,
-vc4->bo_labels[i].num_allocated);
+   drm_printf(p, "%30s: %6dkb BOs (%d)\n",
+  vc4->bo_labels[i].name,
+  vc4->bo_labels[i].size_allocated / 1024,
+  vc4->bo_labels[i].num_allocated);
}
 
mutex_lock(>purgeable.lock);
if (vc4->purgeable.num)
-   DRM_INFO("%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
-vc4->purgeable.size / 1024, vc4->purgeable.num);
+   drm_printf(p, "%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
+  vc4->purgeable.size / 1024, vc4->purgeable.num);
 
if (vc4->purgeable.purged_num)
-   DRM_INFO("%30s: %6zdkb BOs (%d)\n", "total purged BO",
-vc4->purgeable.purged_size / 1024,
-vc4->purgeable.purged_num);
+   drm_printf(p, "%30s: %6zdkb BOs (%d)\n", "total purged BO",
+  vc4->purgeable.purged_size / 1024,
+  vc4->purgeable.purged_num);
mutex_unlock(>purgeable.lock);
 }
 
@@ -71,30 +71,9 @@ static int vc4_bo_stats_debugfs(struct seq_file *m, void 
*unused)
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   int i;
-
-   mutex_lock(>bo_lock);
-   for (i = 0; i < vc4->num_labels; i++) {
-   if (!vc4->bo_labels[i].num_allocated)
-   continue;
-
-   seq_printf(m, "%30s: %6dkb BOs (%d)\n",
-  vc4->bo_labels[i].name,
-  vc4->bo_labels[i].size_allocated / 1024,
-  vc4->bo_labels[i].num_allocated);
-   }
-   mutex_unlock(>bo_lock);
+   struct drm_printer p = drm_seq_file_printer(m);
 
-   mutex_lock(>purgeable.lock);
-   if (vc4->purgeable.num)
-   seq_printf(m, "%30s: %6zdkb BOs (%d)\n", "userspace BO cache",
-  vc4->purgeable.size / 1024, vc4->purgeable.num);
-
-   if (vc4->purgeable.purged_num)
-   seq_printf(m, "%30s: %6zdkb BOs (%d)\n", "total purged BO",
-  vc4->purgeable.purged_size / 1024,
-  vc4->purgeable.purged_num);
-   mutex_unlock(>purgeable.lock);
+   vc4_bo_stats_print(, vc4);
 
return 0;
 }
@@ -473,8 +452,9 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t 
unaligned_size,
}
 
if (IS_ERR(cma_obj)) {
+   struct drm_printer p = drm_info_printer(vc4->dev->dev);
DRM_ERROR("Failed to allocate from CMA:\n");
-   vc4_bo_stats_dump(vc4);
+   vc4_bo_stats_print(, vc4);
return ERR_PTR(-ENOMEM);
}
bo = to_vc4_bo(_obj->base);
-- 
2.20.1

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

[Bug 109692] deadlock occurs during GPU reset

[bugzilla-daemon]

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

--- Comment #5 from mikhail.v.gavri...@gmail.com ---
(In reply to Andrey Grodzovsky from comment #2)
> Is this deadlock happens to you always now or only sometimes ?

Looks like deadlock happens always.

-- 
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] mm: Don't let userspace spam allocations warnings

[Kees Cook]

On Wed, Feb 20, 2019 at 12:41 PM Daniel Vetter  wrote:
>
> memdump_user usually gets fed unchecked userspace input. Blasting a
> full backtrace into dmesg every time is a bit excessive - I'm not sure
> on the kernel rule in general, but at least in drm we're trying not to
> let unpriviledge userspace spam the logs freely. Definitely not entire
> warning backtraces.
>
> It also means more filtering for our CI, because our testsuite
> exercises these corner cases and so hits these a lot.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: Kees Cook 

-Kees

> Cc: Andrew Morton 
> Cc: Mike Rapoport 
> Cc: Michal Hocko 
> Cc: Roman Gushchin 
> Cc: Vlastimil Babka 
> Cc: Jan Stancek 
> Cc: Kees Cook 
> Cc: Andrey Ryabinin 
> Cc: "Michael S. Tsirkin" 
> Cc: Huang Ying 
> Cc: Bartosz Golaszewski 
> Cc: linux...@kvack.org
> ---
>  mm/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index 1ea055138043..379319b1bcfd 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -150,7 +150,7 @@ void *memdup_user(const void __user *src, size_t len)
>  {
> void *p;
>
> -   p = kmalloc_track_caller(len, GFP_USER);
> +   p = kmalloc_track_caller(len, GFP_USER | __GFP_NOWARN);
> if (!p)
> return ERR_PTR(-ENOMEM);
>
> --
> 2.20.1
>


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

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

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

--- Comment #1 from Marek Olšák  ---
Mesa needs a way to query that it can't set thread affinity.

-- 
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: [RFC v4 10/17] kunit: test: add test managed resource tests

[Stephen Boyd]

Quoting Brendan Higgins (2019-02-19 15:20:18)
> On Fri, Feb 15, 2019 at 12:54 PM Stephen Boyd  wrote:
> >
> > Quoting Brendan Higgins (2019-02-14 13:37:22)
> > > +
> > > +static struct kunit_case kunit_resource_test_cases[] = {
> >
> > Can these arrays be const?
> 
> There is some private mutable state inside of `struct kunit_case` that
> would be kind of annoying to pull out; I don't think it would make it
> cleaner.

Fair enough. Thanks for checking.

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

[PATCH] drm/rockchip: vop: reset scale mode when win is disabled

[Jonas Karlman]

NV12 framebuffers produced by the VPU shows distorted on RK3288
after win has been disabled when scaling is active.

This issue can be reproduced using a 1080p modeset by:
- Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0
- Disable win0
- Display a 1920x1080 NV12 framebuffer without scaling on win0
- Output will now show the framebuffer distorted

And by:
- Scale a 1280x720 NV12 framebuffer to 1920x1080
- Change to a 720p modeset (win gets disabled and scaling reset to none)
- Output will now show the framebuffer distorted

Fix this by setting scale mode to none when win is disabled.

Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
Signed-off-by: Jonas Karlman 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb70fb486fbf..cdbb47566cac 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -511,6 +511,18 @@ static void vop_core_clks_disable(struct vop *vop)
clk_disable(vop->hclk);
 }
 
+static void vop_win_disable(struct vop *vop, const struct vop_win_data *win)
+{
+   if (win->phy->scl && win->phy->scl->ext) {
+   VOP_SCL_SET_EXT(vop, win, yrgb_hor_scl_mode, SCALE_NONE);
+   VOP_SCL_SET_EXT(vop, win, yrgb_ver_scl_mode, SCALE_NONE);
+   VOP_SCL_SET_EXT(vop, win, cbcr_hor_scl_mode, SCALE_NONE);
+   VOP_SCL_SET_EXT(vop, win, cbcr_ver_scl_mode, SCALE_NONE);
+   }
+
+   VOP_WIN_SET(vop, win, enable, 0);
+}
+
 static int vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
@@ -556,7 +568,7 @@ static int vop_enable(struct drm_crtc *crtc)
struct vop_win *vop_win = >win[i];
const struct vop_win_data *win = vop_win->data;
 
-   VOP_WIN_SET(vop, win, enable, 0);
+   vop_win_disable(vop, win);
}
spin_unlock(>reg_lock);
 
@@ -700,7 +712,7 @@ static void vop_plane_atomic_disable(struct drm_plane 
*plane,
 
spin_lock(>reg_lock);
 
-   VOP_WIN_SET(vop, win, enable, 0);
+   vop_win_disable(vop, win);
 
spin_unlock(>reg_lock);
 }
@@ -1476,7 +1488,7 @@ static int vop_initial(struct vop *vop)
int channel = i * 2 + 1;
 
VOP_WIN_SET(vop, win, channel, (channel + 1) << 4 | channel);
-   VOP_WIN_SET(vop, win, enable, 0);
+   vop_win_disable(vop, win);
VOP_WIN_SET(vop, win, gate, 1);
}
 
-- 
2.17.1

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

[pull] radeon and amdgpu drm-fixes-5.0

[Alex Deucher]

Hi Dave, Daniel,

A bit bigger than normal for this week due to fixes for some long
standing display issues that are bound for stable.  These changes would
be going to stable anyway, so I figured it was better via 5.0 than 5.1.
- Several display fixes
- Fix PX systems due to core changes in runtime pm
- Disable bulk moves.  They are fixed in 5.1, but fix is too invasive for 5.0

The following changes since commit a3b22b9f11d9fbc48b0291ea92259a5a810e9438:

  Linux 5.0-rc7 (2019-02-17 18:46:40 -0800)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-5.0

for you to fetch changes up to a213c2c7e235cfc0e0a161a558f7fdf2fb3a624a:

  drm/amdgpu: disable bulk moves for now (2019-02-20 17:13:27 -0500)


Alex Deucher (1):
  drm/amdgpu: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

Bhawanpreet Lakha (2):
  drm/amd/display: fix optimize_bandwidth func pointer for dce80
  drm/amd/display: set clocks to 0 on suspend on dce80

Christian König (1):
  drm/amdgpu: disable bulk moves for now

Leo (Hanghong) Ma (1):
  drm/amd/display: Fix MST reboot/poweroff sequence

Nicholas Kazlauskas (1):
  drm/amd/display: Fix negative cursor pos programming

Rafael J. Wysocki (1):
  gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

Roman Li (1):
  drm/amd/display: Raise dispclk value for dce11

shaoyunl (1):
  drm/amdgpu: Update sdma golden setting for vega20

 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  2 ++
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c|  4 ++--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  5 +++--
 drivers/gpu/drm/amd/display/dc/dce/dce_clk_mgr.c  | 11 ---
 .../drm/amd/display/dc/dce100/dce100_hw_sequencer.h   |  4 
 .../gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c |  2 +-
 drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 19 ---
 .../gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_kms.c   |  1 +
 10 files changed, 40 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] drm/v3d: Make sure the GPU is on when measuring clocks.

[Eric Anholt]

You'll get garbage measurements if the registers always read back
0xdeadbeef

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/v3d/v3d_debugfs.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index eb2b2d2f8553..a24af2d2f574 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -187,6 +187,11 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
uint32_t cycles;
int core = 0;
int measure_ms = 1000;
+   int ret;
+
+   ret = pm_runtime_get_sync(v3d->dev);
+   if (ret < 0)
+   return ret;
 
if (v3d->ver >= 40) {
V3D_CORE_WRITE(core, V3D_V4_PCTR_0_SRC_0_3,
@@ -210,6 +215,9 @@ static int v3d_measure_clock(struct seq_file *m, void 
*unused)
   cycles / (measure_ms * 1000),
   (cycles / (measure_ms * 100)) % 10);
 
+   pm_runtime_mark_last_busy(v3d->dev);
+   pm_runtime_put_autosuspend(v3d->dev);
+
return 0;
 }
 
-- 
2.20.1

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

[PATCH v3 1/3] drm/v3d: Add support for V3D v4.2.

[Eric Anholt]

No compatible string for it yet, just the version-dependent changes.
They've now tied the hub and the core interrupt lines into a single
interrupt line coming out of the block.  It also turns out I made a
mistake in modeling the V3D v3.3 and v4.1 bridge as a part of V3D
itself -- the bridge is going away in favor of an external reset
controller in a larger HW module.

v2: Use consistent checks for whether we're on 4.2, and fix a leak in
an error path.
v3: Use more general means of determining if the current 4.2 changes
are in place, as apparently other platforms may switch back (noted
by Dave).  Update the binding doc.

Signed-off-by: Eric Anholt 
---
 .../devicetree/bindings/gpu/brcm,bcm-v3d.txt  | 11 ++--
 drivers/gpu/drm/v3d/v3d_drv.c | 21 +++---
 drivers/gpu/drm/v3d/v3d_drv.h |  2 ++
 drivers/gpu/drm/v3d/v3d_gem.c | 12 +++-
 drivers/gpu/drm/v3d/v3d_irq.c | 28 +++
 5 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
index c907aa8dd755..b2df82b44625 100644
--- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
@@ -6,15 +6,20 @@ For V3D 2.x, see brcm,bcm-vc4.txt.
 Required properties:
 - compatible:  Should be "brcm,7268-v3d" or "brcm,7278-v3d"
 - reg: Physical base addresses and lengths of the register areas
-- reg-names:   Names for the register areas.  The "hub", "bridge", and "core0"
+- reg-names:   Names for the register areas.  The "hub" and "core0"
  register areas are always required.  The "gca" register area
- is required if the GCA cache controller is present.
+ is required if the GCA cache controller is present.  The
+ "bridge" register area is required if an external reset
+ controller is not present.
 - interrupts:  The interrupt numbers.  The first interrupt is for the hub,
- while the following interrupts are for the cores.
+ while the following interrupts are separate interrupt lines
+ for the cores (if they don't share the hub's interrupt).
  See bindings/interrupt-controller/interrupts.txt
 
 Optional properties:
 - clocks:  The core clock the unit runs on
+- resets:  The reset line for v3d, if not using a mapping of the bridge
+ See bindings/reset/reset.txt
 
 v3d {
compatible = "brcm,7268-v3d";
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index b189b1a0ae7e..392e458b55bd 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -496,10 +497,6 @@ static int v3d_platform_drm_probe(struct platform_device 
*pdev)
v3d->pdev = pdev;
drm = >drm;
 
-   ret = map_regs(v3d, >bridge_regs, "bridge");
-   if (ret)
-   goto dev_free;
-
ret = map_regs(v3d, >hub_regs, "hub");
if (ret)
goto dev_free;
@@ -514,6 +511,22 @@ static int v3d_platform_drm_probe(struct platform_device 
*pdev)
v3d->cores = V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_NCORES);
WARN_ON(v3d->cores > 1); /* multicore not yet implemented */
 
+   v3d->reset = devm_reset_control_get_exclusive(dev, NULL);
+   if (IS_ERR(v3d->reset)) {
+   ret = PTR_ERR(v3d->reset);
+
+   if (ret == -EPROBE_DEFER)
+   goto dev_free;
+
+   v3d->reset = NULL;
+   ret = map_regs(v3d, >bridge_regs, "bridge");
+   if (ret) {
+   dev_err(dev,
+   "Failed to get reset control or bridge regs\n");
+   goto dev_free;
+   }
+   }
+
if (v3d->ver < 41) {
ret = map_regs(v3d, >gca_regs, "gca");
if (ret)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 9e0e11f57307..fab9979b7e1f 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -39,6 +39,7 @@ struct v3d_dev {
 * and revision.
 */
int ver;
+   bool single_irq_line;
 
struct device *dev;
struct platform_device *pdev;
@@ -47,6 +48,7 @@ struct v3d_dev {
void __iomem *bridge_regs;
void __iomem *gca_regs;
struct clk *clk;
+   struct reset_control *reset;
 
/* Virtual and DMA addresses of the single shared page table. */
volatile u32 *pt;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 0d1e5e0b8042..109be31e47ea 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 

[PATCH v3 2/3] drm/v3d: Don't try to set OVRTMUOUT on V3D 4.x.

[Eric Anholt]

The old field is gone and the register now has a different field,
QRMAXCNT for how many TMU requests get serviced before thread switch.
We were accidentally reducing it from its default of 0x3 (4 requests)
to 0x0 (1).

v2: Skip setting the reg at all on 4.x, instead of trying to update
only the old field.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/v3d/v3d_gem.c  | 3 ++-
 drivers/gpu/drm/v3d/v3d_regs.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 109be31e47ea..449d01ea54a0 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -25,7 +25,8 @@ v3d_init_core(struct v3d_dev *v3d, int core)
 * type.  If you want the default behavior, you can still put
 * "2" in the indirect texture state's output_type field.
 */
-   V3D_CORE_WRITE(core, V3D_CTL_MISCCFG, V3D_MISCCFG_OVRTMUOUT);
+   if (v3d->ver < 40)
+   V3D_CORE_WRITE(core, V3D_CTL_MISCCFG, V3D_MISCCFG_OVRTMUOUT);
 
/* Whenever we flush the L2T cache, we always want to flush
 * the whole thing.
diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
index 6ccdee9d47bd..8e88af237610 100644
--- a/drivers/gpu/drm/v3d/v3d_regs.h
+++ b/drivers/gpu/drm/v3d/v3d_regs.h
@@ -216,6 +216,8 @@
 # define V3D_IDENT2_BCG_INTBIT(28)
 
 #define V3D_CTL_MISCCFG0x00018
+# define V3D_CTL_MISCCFG_QRMAXCNT_MASK V3D_MASK(3, 1)
+# define V3D_CTL_MISCCFG_QRMAXCNT_SHIFT1
 # define V3D_MISCCFG_OVRTMUOUT BIT(0)
 
 #define V3D_CTL_L2CACTL0x00020
-- 
2.20.1

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

[Bug 102581] 3D texture mipmapping broken

[bugzilla-daemon]

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

--- Comment #5 from Felix Potthast  ---
Created attachment 143426
  --> https://bugs.freedesktop.org/attachment.cgi?id=143426=edit
Test program

The bug is still present for me with mesa 18.3.4-1
I wrote a little test program which compares an uploaded
3dtexture mipmap with the corresponding output of glGetTexImage.

It should output nothing, but on my desktop pc it outputs:

Error in level 2
Error in level 3
Error in level 4

Compile with "gcc test.c -o test -lglfw -lepoxy"

-- 
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] drm/writeback: Delete drm_writeback_cleanup_job

[Daniel Vetter]

No implementation, no callers.

Cc: Brian Starkey 
Cc: Liviu Dudau 
Cc: Eric Anholt 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_writeback.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 23df9d463003..f34895f7fcb1 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -125,8 +125,6 @@ int drm_writeback_connector_init(struct drm_device *dev,
 void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
 struct drm_writeback_job *job);
 
-void drm_writeback_cleanup_job(struct drm_writeback_job *job);
-
 void
 drm_writeback_signal_completion(struct drm_writeback_connector *wb_connector,
int status);
-- 
2.20.1

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

[PATCH v6 1/3] drm: Add CRTC background color property (v5)

[Matt Roper]

Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes).  Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.

To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value.  Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.

v2:
 - Swap internal representation's blue and red bits to make it easier
   to read if printed out.  (Ville)
 - Document bgcolor property in drm_blend.c.  (Sean Paul)
 - s/background_color/bgcolor/ for consistency between property name and
   value storage field.  (Sean Paul)
 - Add a convenience function to attach property to a given crtc.

v3:
 - Restructure ARGB component extraction macros to be easier to
   understand and enclose the parameters in () to avoid calculations
   if expressions are passed.  (Sean Paul)
 - s/rgba/argb/ in helper function/macro names.  Even though the idea is
   to not worry about the internal representation of the u64, it can
   still be confusing to look at code that uses 'rgba' terminology, but
   stores values with argb ordering.  (Ville)

v4:
 - Drop the bgcolor_changed flag.  (Ville, Brian Starkey)
 - Clarify in kerneldoc that background color is expected to undergo the
   same pipe-level degamma/csc/gamma transformations that planes do.
   (Brian Starkey)
 - Update kerneldoc to indicate non-opaque colors are allowed, but are
   generally only useful in special cases such as when writeback
   connectors are used (Brian Starkey / Eric Anholt)

v5:
 - Set crtc->state->bgcolor to solid black inside
   drm_crtc_add_bgcolor_property() in case drivers don't do this
   themselves.  (Ville)
 - Add kerneldoc to drm_crtc_add_bgcolor_property() function.

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä 
Cc: Sean Paul 
Cc: Brian Starkey 
Cc: Eric Anholt 
Cc: Stéphane Marchesin 
Cc: Daniel Vetter 
Signed-off-by: Matt Roper 
Reviewed-by(v2): Sean Paul 
Reviewed-by: Brian Starkey 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 
 drivers/gpu/drm/drm_blend.c   | 41 ---
 drivers/gpu/drm/drm_mode_config.c |  6 ++
 include/drm/drm_blend.h   |  1 +
 include/drm/drm_crtc.h| 12 
 include/drm/drm_mode_config.h |  5 +
 include/uapi/drm/drm_mode.h   | 28 ++
 7 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd401d3ca..5436201a6a0d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
return -EFAULT;
 
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+   } else if (property == config->bgcolor_property) {
+   state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+   else if (property == config->bgcolor_property)
+   *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property, 
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 0c78ca386cbe..2ff69fae385c 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -175,9 +175,22 @@
  *  plane does not expose the "alpha" property, then this is
  *  assumed to be 1.0
  *
- * Note that all the property extensions described here apply either to the
- * plane or the CRTC (e.g. for the background color, which currently is not
- * exposed and assumed to be black).
+ * The property extensions described above all apply to the plane.  Drivers
+ * may also expose the following crtc property extension:
+ *
+ * BACKGROUND_COLOR:
+ * Background color is setup with drm_crtc_add_bgcolor_property().  It
+ * controls the ARGB color of a full-screen layer that exists below all
+ * planes.  This color will be used for pixels not covered by any plane
+ * and may also be blended with plane contents as allowed by a plane's
+ * alpha values.  The background color defaults to black, and is assumed
+ * to be black for drivers 

[PATCH v6 2/3] drm/i915/gen9+: Add support for pipe background color (v6)

[Matt Roper]

Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes.  Let's expose this for use by
compositors.

v2:
 - Split out bgcolor sanitization and programming of csc/gamma bits to a
   separate patch that we can land before the ABI changes are ready to
   go in.  (Ville)
 - Change a temporary variable name to be more consistent with
   other similar functions.  (Ville)
 - Change register name to SKL_CANVAS for consistency with the
   CHV_CANVAS register.

v3:
 - Switch register name back to SKL_BOTTOM_COLOR.  (Ville)
 - Use non-_FW register write.  (Ville)
 - Minor parameter rename for consistency.  (Ville)

v4:
 - Removed use of bgcolor_changed flag.

v5:
 - s/uint64_t/u64/

v6:
 - Rebase onto latest drm-tip (bgcolor writing now moves to the new
   color_commit function added by Ville's series)

Cc: dri-devel@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 +
 drivers/gpu/drm/i915/intel_color.c   | 11 ---
 drivers/gpu/drm/i915/intel_display.c | 11 +++
 3 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2aeea977283f..0d9d951512af 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3060,6 +3060,15 @@ static int i915_display_info(struct seq_file *m, void 
*unused)
intel_plane_info(m, crtc);
}
 
+   if (INTEL_GEN(dev_priv) >= 9 && pipe_config->base.active) {
+   u64 background = pipe_config->base.bgcolor;
+
+   seq_printf(m, "\tbackground color (10bpc): r=%x g=%x 
b=%x\n",
+  DRM_ARGB_RED(background, 10),
+  DRM_ARGB_GREEN(background, 10),
+  DRM_ARGB_BLUE(background, 10));
+   }
+
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
   yesno(!crtc->cpu_fifo_underrun_disabled),
   yesno(!crtc->pch_fifo_underrun_disabled));
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index da7a07d5ccea..1e329a3ee6bd 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -424,12 +424,17 @@ static void skl_color_commit(const struct 
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
+   u64 propval = crtc_state->base.bgcolor;
u32 val = 0;
 
+   /* Hardware is programmed with 10 bits of precision */
+   val = DRM_ARGB_RED(propval, 10) << 20
+   | DRM_ARGB_GREEN(propval, 10) << 10
+   | DRM_ARGB_BLUE(propval, 10);
+
/*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC appropriately
-* so that its handling will match how we program our planes.
+* Apply pipe gamma and CSC appropriately so that its handling will
+* match how we program our planes.
 */
if (crtc_state->gamma_enable)
val |= SKL_BOTTOM_COLOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index afa21daaae51..49e99d73ef89 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11220,6 +11220,8 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+   struct drm_crtc_state *old_crtc_state =
+   drm_atomic_get_old_crtc_state(crtc_state->state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
 
@@ -11242,6 +11244,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
return ret;
}
 
+   if (crtc_state->bgcolor != old_crtc_state->bgcolor)
+   pipe_config->update_pipe = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(pipe_config);
@@ -14423,6 +14428,9 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
WARN_ON(drm_crtc_index(_crtc->base) != intel_crtc->pipe);
 
+   if (INTEL_GEN(dev_priv) >= 9)
+   drm_crtc_add_bgcolor_property(_crtc->base);
+
return 0;
 
 fail:
@@ -15665,6 +15673,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state = 
to_intel_crtc_state(crtc->base.state);
enum 

[PATCH v6 3/3] drm/i915: Add background color hardware readout and state check

[Matt Roper]

We should support readout and verification of crtc background color as
we do with other pipe state.  Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.

At boot time the pipe color is already sanitized to full black as
required by ABI, so the new readout here won't break that requirement.

Suggested-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 49e99d73ef89..2eba05e2fda6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9869,6 +9869,7 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum intel_display_power_domain power_domain;
u64 power_domain_mask;
+   u32 bgcolor;
bool active;
 
intel_crtc_init_scalers(crtc, pipe_config);
@@ -9947,6 +9948,15 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
pipe_config->pixel_multiplier = 1;
}
 
+   if (INTEL_GEN(dev_priv) >= 9) {
+   bgcolor = I915_READ(SKL_BOTTOM_COLOR(crtc->pipe));
+   pipe_config->base.bgcolor =
+   drm_argb(10, 0x,
+bgcolor >> 20 & 0x3FF,
+bgcolor >> 10 & 0x3FF,
+bgcolor   & 0x3FF);
+   }
+
 out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put_unchecked(dev_priv, power_domain);
@@ -11580,6 +11590,10 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  drm_rect_width(>base.dst),
  drm_rect_height(>base.dst));
}
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   DRM_DEBUG_KMS("background color: %llx\n",
+ pipe_config->base.bgcolor);
 }
 
 static bool check_digital_port_conflicts(struct drm_atomic_state *state)
@@ -11946,6 +11960,16 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
} \
 } while (0)
 
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+   if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+   pipe_config_err(adjust, __stringify(name), \
+ "(expected 0x%016llx, found 0x%016llx)\n", \
+ current_config->name & mask, \
+ pipe_config->name & mask); \
+   ret = false; \
+   } \
+} while (0)
+
 #define PIPE_CONF_CHECK_I(name) do { \
if (current_config->name != pipe_config->name) { \
pipe_config_err(adjust, __stringify(name), \
@@ -12201,6 +12225,14 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
 
PIPE_CONF_CHECK_I(min_voltage_level);
 
+   /*
+* Hardware only holds top 10 bits of each color component; ignore
+* bottom six bits (and all of alpha) when comparing against readout.
+*/
+   if (INTEL_GEN(dev_priv) >= 9)
+   PIPE_CONF_CHECK_LLX_MASKED(base.bgcolor, 0xFFC0FFC0FFC0);
+
+#undef PIPE_CONF_CHECK_LLX_MASKED
 #undef PIPE_CONF_CHECK_X
 #undef PIPE_CONF_CHECK_I
 #undef PIPE_CONF_CHECK_BOOL
-- 
2.14.5

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

[PATCH v6 0/3] CRTC background color

[Matt Roper]

This version is just a rebase of v5 onto the latest drm-tip, which was
posted here:
  https://lists.freedesktop.org/archives/intel-gfx/2019-January/188352.html

There were some minor conflicts with Ville's csc/gamma disable series,
so the background color write has now moved to the new color_commit
function, but that's about the only notable rebase change.

Reviewed userspace (chromeos) is here:
  https://chromium-review.googlesource.com/c/chromium/src/+/1278858
  
https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436

I've made some minor changes to the i-g-t test, so I'll resend those
again shortly.

All the kernel patches are reviewed now, so I think this series is ready
to merge.  Since the i915 patches rely on other stuff that's landed
pretty recently in dinq, it's probably easiest to merge this via the
i915 tree; just need an Ack from Dave/Daniel.

Matt Roper (3):
  drm: Add CRTC background color property (v5)
  drm/i915/gen9+: Add support for pipe background color (v6)
  drm/i915: Add background color hardware readout and state check

 drivers/gpu/drm/drm_atomic_uapi.c|  4 
 drivers/gpu/drm/drm_blend.c  | 41 +++---
 drivers/gpu/drm/drm_mode_config.c|  6 +
 drivers/gpu/drm/i915/i915_debugfs.c  |  9 
 drivers/gpu/drm/i915/intel_color.c   | 11 ++---
 drivers/gpu/drm/i915/intel_display.c | 43 
 include/drm/drm_blend.h  |  1 +
 include/drm/drm_crtc.h   | 12 ++
 include/drm/drm_mode_config.h|  5 +
 include/uapi/drm/drm_mode.h  | 28 +++
 10 files changed, 154 insertions(+), 6 deletions(-)

-- 
2.14.5

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

[PATCH V5 3/8] drm/mediatek: using different flags of clk for HDMI phy

[wangyan wang]

From: chunhui dai 

The parent rate of hdmi phy had set by DPI driver.
We should not set or change the parent rate of MT2701 hdmi phy,
as a result we should remove the flags of "CLK_SET_RATE_PARENT"
from the clock of MT2701 hdmi phy.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 13 +
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  1 +
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c |  1 +
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  1 +
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 13c5e65b9ead..370309d684ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -107,13 +107,11 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy 
*hdmi_phy)
return NULL;
 }
 
-static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
-const struct clk_ops **ops)
+static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
+struct clk_init_data *clk_init)
 {
-   if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
-   *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
-   else
-   dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+   clk_init->flags = hdmi_phy->conf->flags;
+   clk_init->ops = hdmi_phy->conf->hdmi_phy_clk_ops;
 }
 
 static int mtk_hdmi_phy_probe(struct platform_device *pdev)
@@ -126,7 +124,6 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
struct clk_init_data clk_init = {
.num_parents = 1,
.parent_names = (const char * const *)_clk_name,
-   .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
};
 
struct phy *phy;
@@ -164,7 +161,7 @@ static int mtk_hdmi_phy_probe(struct platform_device *pdev)
hdmi_phy->dev = dev;
hdmi_phy->conf =
(struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
-   mtk_hdmi_phy_clk_get_ops(hdmi_phy, _init.ops);
+   mtk_hdmi_phy_clk_get_data(hdmi_phy, _init);
hdmi_phy->pll_hw.init = _init;
hdmi_phy->pll = devm_clk_register(dev, _phy->pll_hw);
if (IS_ERR(hdmi_phy->pll)) {
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index fdad8b17a915..446e2acd1926 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -21,6 +21,7 @@ struct mtk_hdmi_phy;
 
 struct mtk_hdmi_phy_conf {
bool tz_disabled;
+   unsigned long flags;
const struct clk_ops *hdmi_phy_clk_ops;
void (*hdmi_phy_enable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
void (*hdmi_phy_disable_tmds)(struct mtk_hdmi_phy *hdmi_phy);
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b26fb7dbdb28..43bc058d5528 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -234,6 +234,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy 
*hdmi_phy)
 
 struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
.tz_disabled = true,
+   .flags = CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index cb23c1e4692a..63dde42521b8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -317,6 +317,7 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy 
*hdmi_phy)
 }
 
 struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+   .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
.hdmi_phy_clk_ops = _hdmi_phy_pll_ops,
.hdmi_phy_enable_tmds = mtk_hdmi_phy_enable_tmds,
.hdmi_phy_disable_tmds = mtk_hdmi_phy_disable_tmds,
-- 
2.14.1

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

Re: [PATCH RFC] drm: add func to better detect wether swiotlb is needed

[Michael Labriola]

On Sat, Feb 16, 2019 at 2:00 PM Koenig, Christian
 wrote:
>
> Am 15.02.19 um 22:29 schrieb Michael D Labriola:
> > This commit fixes DRM failures on Xen PV systems that were introduced in
> > v4.17 by the following commits:
> >
> > 82626363 drm: add func to get max iomem address v2
> > fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
> > 1bc3d3cc drm/radeon: only enable swiotlb path when need v2
> >
> > The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
> > in the radeon and amdgpu device drivers causes Gnome to immediately crash
> > on Xen PV systems, returning the user to the login screen.  The following
> > kernel errors get logged:
> >
> > [   28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
> > [   31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 
> > bytes)
> > [   31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
> > allocate GEM object (16384000, 2, 4096, -14)
> > [   31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 
> > bytes)
> > [   31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
> > allocate GEM object (16384000, 2, 4096, -14)
> > [   31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp 
> > 7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
> > [   31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f 
> > 1f 44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78 
> > <48> 8b 80 88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
> > [   38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
> > [   40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 
> > bytes)
> > [   40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
> > allocate GEM object (16384000, 2, 4096, -14)
> > [   40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 
> > bytes)
> > [   40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
> > allocate GEM object (16384000, 2, 4096, -14)
> > [   40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40 
> > sp 7ffcd24ea5f8 error 15
> > [   40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00 
> > 80 f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> > <00> 00 00 00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00
> >
> > This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
> > xen_pv_domain() check to it, and moves the bit shifting comparison that
> > always follows its usage into the function (simplifying the drm driver
> > code).
>
> You signed of by line is missing. Apart from that it looks like a good
> fix to me.

Oops, I can resend w/ signoff.

> But the question is why does Xen needs dma_alloc_coherent() ?

I'm not sure I understand, even after discussing on xen-devel.  What I
was told by Juergen (on CC) is:

"The thing which is different between Xen PV guests and most others
(all others(?), now that Lguest and UML have been dropped) is that
what Linux thinks of as PFN $N isn't necessarily adjacent to PFN $N+1
in system physical address space.

Therefore, code which has a buffer spanning a page boundary can't just
convert a pointer to the buffer into a physical address, and hand that
address to a device.  You generally end up with either memory
corruption (DMA hitting the wrong page allocated to the guest), or an
IOMMU fault (DMA hitting a pages which isn't allocated to the guest)."

And Christoph (also on CC) pointed out:

"ttm_populate_and_map_pages uses dma_map_page to map GPU memory,
and from what I can tell from your report potentially lots of it.

So this does "properly" use the DMA API for some amount of "properly".
The problem here is that ttm_populate_and_map_pages first allocates
memory and then maps it in a way where it bounce buffers a lot,
leading to a swiotlb buffer exaustion, as seen in your report.

ttm_dma_populate also sort of "properly" uses the DMA API in that it
uses the dma_alloc_coherent allocator.  The benefit of that allocator is
that is always returns addressable memory without exhausing the swiotlb
buffer.  The dowside of ttm_dma_populate / dma_alloc_coherent is that
on architectures where PCIe is not cache coherent it pointlessly
up other resources, as coherent DMA memory can be a very finite resource
there.

So for a short term fix forcing the dma_alloc_coherent route on
Xen/x86 is the right thing.  On Xen/arm and Xen/arm64 is might already
be problemeatic due to the explanation above unfortunately.

The real fix is to finally get broadly available non-coherent device
memory allocator into mainlaine and with ttm_populate_and_map_pages
to use it.  Note that for non-coherent devices it seems like
ttm_populate_and_map_pages also seems to miss proper ownership
management but that is another issue.

My proposal for such an allocator here:

   https://lwn.net/Articles/774429/;

>
> Using 

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Jason Gunthorpe]

On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:
> On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > >
> > > From: Jérôme Glisse 
> > >
> > > Since last version [4] i added the extra bits needed for the change_pte
> > > optimization (which is a KSM thing). Here i am not posting users of
> > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > it).
> > 
> > The users look small and straightforward. Why not await acks and
> > reviewed-by's for the users like a typical upstream submission and
> > merge them together? Is all of the functionality of this
> > infrastructure consumed by the proposed users? Last time I checked it
> > was only a subset.
> 
> Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> were ok with it too. I do not want to merge things through Andrew
> for all of this we discussed that in the past, merge mm bits through
> Andrew in one release and bits that use things in the next release.

It is usually cleaner for everyone to split patches like this, for
instance I always prefer to merge RDMA patches via RDMA when
possible. Less conflicts.

The other somewhat reasonable option is to get acks and send your own
complete PR to Linus next week? That works OK for tree-wide changes.

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

Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

[Frank Rowand]

On 2/19/19 10:34 PM, Brendan Higgins wrote:
> On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand  wrote:
> 
>> I have not read through the patches in any detail.  I have read some of
>> the code to try to understand the patches to the devicetree unit tests.
>> So that may limit how valid my comments below are.
> 
> No problem.
> 
>>
>> I found the code difficult to read in places where it should have been
>> much simpler to read.  Structuring the code in a pseudo object oriented
>> style meant that everywhere in a code path that I encountered a dynamic
>> function call, I had to go find where that dynamic function call was
>> initialized (and being the cautious person that I am, verify that
>> no where else was the value of that dynamic function call).  With
>> primitive vi and tags, that search would have instead just been a
>> simple key press (or at worst a few keys) if hard coded function
>> calls were done instead of dynamic function calls.  In the code paths
>> that I looked at, I did not see any case of a dynamic function being
>> anything other than the value it was originally initialized as.
>> There may be such cases, I did not read the entire patch set.  There
>> may also be cases envisioned in the architects mind of how this
>> flexibility may be of future value.  Dunno.
> 
> Yeah, a lot of it is intended to make architecture specific
> implementations and some other future work easier. Some of it is also
> for testing purposes. Admittedly some is for neither reason, but given
> the heavy usage elsewhere, I figured there was no harm since it was
> all private internal usage anyway.
> 

Increasing the cost for me (and all the other potential code readers)
to read the code is harm.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5 7/8] drm/mediatek: using new factor for tvdpll in MT2701

[wangyan wang]

From: chunhui dai 

The factor depends on the divider of DPI in MT2701, therefore,
we should fix this factor to the right and new one.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 69c6e42dad6b..4a2f4a650494 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -662,13 +662,11 @@ static unsigned int mt8173_calculate_factor(int clock)
 static unsigned int mt2701_calculate_factor(int clock)
 {
if (clock <= 64000)
-   return 16;
-   else if (clock <= 128000)
-   return 8;
-   else if (clock <= 256000)
return 4;
-   else
+   else if (clock <= 128000)
return 2;
+   else
+   return 1;
 }
 
 static const struct mtk_dpi_conf mt8173_conf = {
-- 
2.14.1

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

Re: [PATCH] drm/msm: Remove pm_runtime calls from msm_iommu.c

[Bjorn Andersson]

On Tue 19 Feb 10:48 PST 2019, Jordan Crouse wrote:

> Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
> device before doing a IOMMU operation. This was because usually the
> IOMMU driver didn't do power control of its own and since the hardware
> used the same clocks and power as the respective multimedia device it
> was a easy way to make sure that the power was available.
> 
> Now two things have changed. First, the SMMU devices can do their own power
> control and more important bringing up the a6xx GPU isn't as easy as
> turning on some clocks. To bring the GPU up we need the GMU which itself
> needs the IOMMU so we have a chicken and egg problem.
> 
> Luckily this is easily fixed by removing the pm_runtime calls from the
> functions and letting the device link to the IOMMU device handle the magic.
> 
> Signed-off-by: Jordan Crouse 

Thanks for the patch Jordan, this resolves the previously seen splat and
the GPU driver is now happily initialized.

Tested-by: Bjorn Andersson 

Regards,
Bjorn

> ---
> 
>  drivers/gpu/drm/msm/msm_iommu.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 4d62790..12bb54c 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -38,13 +38,8 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const 
> char * const *names,
>   int cnt)
>  {
>   struct msm_iommu *iommu = to_msm_iommu(mmu);
> - int ret;
>  
> - pm_runtime_get_sync(mmu->dev);
> - ret = iommu_attach_device(iommu->domain, mmu->dev);
> - pm_runtime_put_sync(mmu->dev);
> -
> - return ret;
> + return iommu_attach_device(iommu->domain, mmu->dev);
>  }
>  
>  static void msm_iommu_detach(struct msm_mmu *mmu, const char * const *names,
> @@ -52,9 +47,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const 
> char * const *names,
>  {
>   struct msm_iommu *iommu = to_msm_iommu(mmu);
>  
> - pm_runtime_get_sync(mmu->dev);
>   iommu_detach_device(iommu->domain, mmu->dev);
> - pm_runtime_put_sync(mmu->dev);
>  }
>  
>  static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
> @@ -63,9 +56,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
>   struct msm_iommu *iommu = to_msm_iommu(mmu);
>   size_t ret;
>  
> -//   pm_runtime_get_sync(mmu->dev);
>   ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> -//   pm_runtime_put_sync(mmu->dev);
>   WARN_ON(!ret);
>  
>   return (ret == len) ? 0 : -EINVAL;
> @@ -75,9 +66,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
> iova, unsigned len)
>  {
>   struct msm_iommu *iommu = to_msm_iommu(mmu);
>  
> - pm_runtime_get_sync(mmu->dev);
>   iommu_unmap(iommu->domain, iova, len);
> - pm_runtime_put_sync(mmu->dev);
>  
>   return 0;
>  }
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5 5/8] clk: mediatek: add MUX_GATE_FLAGS_2

[wangyan wang]

From: chunhui dai 

Add MUX_GATE_FLAGS_2 for the clock which needs to set two falgs.
Such as some mux need to set the flags of "CLK_MUX_ROUND_CLOSEST".

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/clk/mediatek/clk-mtk.c |  2 +-
 drivers/clk/mediatek/clk-mtk.h | 20 ++--
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 9c0ae4278a94..2ed996404804 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -167,7 +167,7 @@ struct clk *mtk_clk_register_composite(const struct 
mtk_composite *mc,
mux->mask = BIT(mc->mux_width) - 1;
mux->shift = mc->mux_shift;
mux->lock = lock;
-
+   mux->flags = mc->mux_flags;
mux_hw = >hw;
mux_ops = _mux_ops;
 
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index f83c2bbb677e..4b88d196d52f 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -81,15 +81,13 @@ struct mtk_composite {
signed char divider_shift;
signed char divider_width;
 
+   unsigned char mux_flags;
+
signed char num_parents;
 };
 
-/*
- * In case the rate change propagation to parent clocks is undesirable,
- * this macro allows to specify the clock flags manually.
- */
-#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
-   _gate, _flags) {\
+#define MUX_GATE_FLAGS_2(_id, _name, _parents, _reg, _shift,   \
+   _width, _gate, _flags, _muxflags) { \
.id = _id,  \
.name = _name,  \
.mux_reg = _reg,\
@@ -101,8 +99,18 @@ struct mtk_composite {
.parent_names = _parents,   \
.num_parents = ARRAY_SIZE(_parents),\
.flags = _flags,\
+   .mux_flags = _muxflags, \
}
 
+/*
+ * In case the rate change propagation to parent clocks is undesirable,
+ * this macro allows to specify the clock flags manually.
+ */
+#define MUX_GATE_FLAGS(_id, _name, _parents, _reg, _shift, _width, \
+   _gate, _flags)  \
+   MUX_GATE_FLAGS_2(_id, _name, _parents, _reg,\
+   _shift, _width, _gate, _flags, 0)
+
 /*
  * Unless necessary, all MUX_GATE clocks propagate rate changes to their
  * parent clock by default.
-- 
2.14.1

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

Re: [PATCH V5 0/8] make mt7623 clock of hdmi stable

[Ryder Lee]

On Wed, 2019-02-20 at 10:53 +0800, wangyan wang wrote:
> From: Wangyan Wang 
> 
> V4 adopt maintainer's suggestion.
> Here is the change list between V4 & V5
> 1. add Reviewed-by:CK Hu 
> in " drm/mediatek: fix the rate ..." commit message.
> 
> 2. describe the reason why mt7623 clock of hdmi 
> is more stable than before.
> the tvdpll should be stable in hdmi normal setting
> to guarantee clock of hdmi stable, but the tvdpll 
> may be changed in original code ,the patch is to
> deal with the problem, you can find more descriptions
> in patch "drm/mediatek:using different flags of clk ...".
> 
> 
> chunhui dai (8):
>   drm/mediatek: recalculate hdmi phy clock of MT2701 by querying
> hardware
>   drm/mediatek: move the setting of fixed divider
>   drm/mediatek: using different flags of clk for HDMI phy
>   drm/mediatek: fix the rate and divder of hdmi phy for MT2701
>   clk: mediatek: add MUX_GATE_FLAGS_2
>   clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
>   drm/mediatek: using new factor for tvdpll in MT2701
>   drm/mediatek: fix the rate of parent for hdmi phy in MT2701
> 
>  drivers/clk/mediatek/clk-mt2701.c  |  4 +-
>  drivers/clk/mediatek/clk-mtk.c |  2 +-
>  drivers/clk/mediatek/clk-mtk.h | 20 ++---
>  drivers/gpu/drm/mediatek/mtk_dpi.c |  8 ++--
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 34 
>  drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  7 +---
>  drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 56 
> +++---
>  drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
>  8 files changed, 102 insertions(+), 52 deletions(-)
> 

I could see the Debian Gnome desktop on my MT7623 R2.

Tested-by: Ryder Lee 


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

Re: drm dsi2hdmi bridge - temperature sensor

[Vinay Simha B N]

rob,

hpd works in kernel 5.0.0-rc6, i.e postboot if we connect hdmi display
comes(apq8016).

added the temperature alert_handler in adv7511_drv.c
in adv7511_detect , i had set status = connector_status_disconnected; ,
since display should not come initially,
but when irq calls
schedule_work(>hpd_work)/ adv7511_irq_process(adv7511, true); in
temp_alert_handler , hdmi display does not comes
[drm] Cannot find any crtc or sizes

any suggestion on how to initially not switch on the hdmi display and later
enable when irq from temp alert.

On Fri, Feb 15, 2019 at 1:24 AM Sam Ravnborg  wrote:

> Hi Rob.
>
> > >
> > > (Background is to not enable the display until temp is within an
> > > acceptable range, and disable it if it goes out of range, to prevent
> > > hw damage I guess)
> >
> > The thermal framework already has support for temperature trip points
> > triggering "throttlers". I guess the display could be a throttling
> > device. Really, why wouldn't you just shutdown? Seems like a strange
> > usecase to keep running with the display going on and off based on
> > temperature.
>
> (Jumping into the middle of a discussion here, and maybe I got it wrong)
>
> For the devices I work with a shutdown would be highly unexpected
> just because something insignificant like the display fails to work.
> The devices are used to control the climate for birds, sometimes in hot
> areas.
> We do not want the device to shut down and let emergency take over,
> due to a non-functional display.
>
> Sam
>


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

[PATCH V5 2/8] drm/mediatek: move the setting of fixed divider

[wangyan wang]

From: chunhui dai 

move the setting of fixed divider from enable/disable
to the function of setting rate.

the patch is for hdmi pll divider, the divder should
be configured before clock calculation to ensure the
clock is right.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index b25c9dfc432a..b26fb7dbdb28 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -79,7 +79,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
-   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -94,7 +93,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
-   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
@@ -123,6 +121,7 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
 
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_PREDIV_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON6, RG_HTPLL_POSDIV_MASK);
+   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
  RG_HTPLL_IC_MASK);
mtk_hdmi_phy_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
@@ -209,7 +208,6 @@ static void mtk_hdmi_phy_enable_tmds(struct mtk_hdmi_phy 
*hdmi_phy)
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
usleep_range(80, 100);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
-   mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
@@ -221,7 +219,6 @@ static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy 
*hdmi_phy)
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_DRV_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_PRED_MASK);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SER_MASK);
-   mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN);
usleep_range(80, 100);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_EN_SLDO_MASK);
-- 
2.14.1

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

[PATCH V5 0/8] make mt7623 clock of hdmi stable

[wangyan wang]

From: Wangyan Wang 

V4 adopt maintainer's suggestion.
Here is the change list between V4 & V5
1. add Reviewed-by:CK Hu 
in " drm/mediatek: fix the rate ..." commit message.

2. describe the reason why mt7623 clock of hdmi 
is more stable than before.
the tvdpll should be stable in hdmi normal setting
to guarantee clock of hdmi stable, but the tvdpll 
may be changed in original code ,the patch is to
deal with the problem, you can find more descriptions
in patch "drm/mediatek:using different flags of clk ...".


chunhui dai (8):
  drm/mediatek: recalculate hdmi phy clock of MT2701 by querying
hardware
  drm/mediatek: move the setting of fixed divider
  drm/mediatek: using different flags of clk for HDMI phy
  drm/mediatek: fix the rate and divder of hdmi phy for MT2701
  clk: mediatek: add MUX_GATE_FLAGS_2
  clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel
  drm/mediatek: using new factor for tvdpll in MT2701
  drm/mediatek: fix the rate of parent for hdmi phy in MT2701

 drivers/clk/mediatek/clk-mt2701.c  |  4 +-
 drivers/clk/mediatek/clk-mtk.c |  2 +-
 drivers/clk/mediatek/clk-mtk.h | 20 ++---
 drivers/gpu/drm/mediatek/mtk_dpi.c |  8 ++--
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 34 
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  7 +---
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 56 +++---
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 23 +++
 8 files changed, 102 insertions(+), 52 deletions(-)

-- 
2.14.1

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

[PATCH -next] drm/amdgpu: remove set but not used variables 'vm, bo'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function 
'update_gpuvm_pte':
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:840:20: warning:
 variable 'bo' set but not used [-Wunused-but-set-variable]

drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:838:20: warning:
 variable 'vm' set but not used [-Wunused-but-set-variable]

They're never used since introduction in a46a2cd103a8 ("drm/amdgpu: Add GPUVM
memory management functions for KFD")

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index d7b10d79f1de..63daf758cd03 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -837,13 +837,7 @@ static int update_gpuvm_pte(struct amdgpu_device *adev,
struct amdgpu_sync *sync)
 {
int ret;
-   struct amdgpu_vm *vm;
-   struct amdgpu_bo_va *bo_va;
-   struct amdgpu_bo *bo;
-
-   bo_va = entry->bo_va;
-   vm = bo_va->base.vm;
-   bo = bo_va->base.bo;
+   struct amdgpu_bo_va *bo_va = entry->bo_va;
 
/* Update the page tables  */
ret = amdgpu_vm_bo_update(adev, bo_va, false);





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

[PATCH v5 1/8] drm/mediatek: recalculate hdmi phy clock of MT2701 by querying hardware

[wangyan wang]

From: chunhui dai 

Recalculate the rate of this clock, by querying hardware.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c|  7 ++
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  3 +--
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 35 ++
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  8 ++
 4 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 4ef9c57ffd44..13c5e65b9ead 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -29,12 +29,9 @@ long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned 
long rate,
return rate;
 }
 
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
-  unsigned long parent_rate)
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
 {
-   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
-   return hdmi_phy->pll_rate;
+   return readl(hdmi_phy->regs + offset);
 }
 
 void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index f39b1fc66612..fdad8b17a915 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -41,6 +41,7 @@ struct mtk_hdmi_phy {
unsigned int ibias_up;
 };
 
+u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset);
 void mtk_hdmi_phy_clear_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
 u32 bits);
 void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
@@ -50,8 +51,6 @@ void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 
offset,
 struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
 long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
 unsigned long *parent_rate);
-unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
-  unsigned long parent_rate);
 
 extern struct platform_driver mtk_hdmi_phy_driver;
 extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index fcc42dc6ea7f..b25c9dfc432a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -153,6 +153,41 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
  RG_HDMITX_DRV_IBIAS_MASK);
return 0;
 }
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+   unsigned long out_rate, val;
+
+   val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+   & RG_HTPLL_PREDIV_MASK) >> RG_HTPLL_PREDIV;
+   switch (val) {
+   case 0x00:
+   out_rate = parent_rate;
+   break;
+   case 0x01:
+   out_rate = parent_rate / 2;
+   break;
+   default:
+   out_rate = parent_rate / 4;
+   break;
+   }
+
+   val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON6)
+   & RG_HTPLL_FBKDIV_MASK) >> RG_HTPLL_FBKDIV;
+   out_rate *= (val + 1) * 2;
+   val = (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2)
+   & RG_HDMITX_TX_POSDIV_MASK);
+
+   out_rate >>= (val >> RG_HDMITX_TX_POSDIV);
+
+   if (mtk_hdmi_phy_read(hdmi_phy, HDMI_CON2) & RG_HDMITX_EN_TX_POSDIV)
+   out_rate = out_rate / 5;
+
+   hdmi_phy->pll_rate = out_rate;
+
+   return hdmi_phy->pll_rate;
+}
 
 static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index ed5916b27658..cb23c1e4692a 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,14 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }
 
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+  unsigned long parent_rate)
+{
+   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+   return hdmi_phy->pll_rate;
+}
+
 static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
.unprepare = mtk_hdmi_pll_unprepare,
-- 
2.14.1

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

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Kenneth Graunke]

On Tuesday, February 19, 2019 10:08:13 AM PST Ville Syrjälä wrote:
> On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> > On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > > 
> > > 0x0f30
> > > ff049b6ce21d2814451afd4a116d001712e0116b
> > > drm/i915: bind driver to ValleyView chipsets
> > > 
> > > 0x8A70
> > > d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> > > drm/i915/icl: Add the ICL PCI IDs
> > > 
> > > The Intel Media SDK describes these as
> > > 
> > > /* VLV */
> > > { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */
> > 
> > hmmm... no idea about this one...
> > Ville?
> > maybe we should just remove from kernel since it was never
> > missed from Mesa?
> 
> Bspec says that is the infamous X0. Assuming it's not
> lying to us it should be safe to remove.

That fits my memory too, 0f30 was never a PCI ID for a product that
actually shipped.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/tinydrm: Trivia typo fix

[Andy Shevchenko]

Fix adddress -> address typo.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 3a05e56f9b0d..2f8c2d1d09bc 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -897,7 +897,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *mipi,
 * Even though it's not the SPI device that does DMA (the master does),
 * the dma mask is necessary for the dma_alloc_wc() in
 * drm_gem_cma_create(). The dma_addr returned will be a physical
-* adddress which might be different from the bus address, but this is
+* address which might be different from the bus address, but this is
 * not a problem since the address will not be used.
 * The virtual address is used in the transfer and the SPI core
 * re-maps it on the SPI master device using the DMA streaming API
-- 
2.20.1

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

[PATCH V5 6/8] clk: mediatek: using CLK_MUX_ROUND_CLOSEST for the clock of dpi1_sel

[wangyan wang]

From: chunhui dai 

The MUX clock of dpi1_sel should select the closet clock for itself.
We could add this flag to enable this function of MUX in CCF.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/clk/mediatek/clk-mt2701.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701.c 
b/drivers/clk/mediatek/clk-mt2701.c
index ab6ab07f53e6..905a2316f6a7 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -535,8 +535,8 @@ static const struct mtk_composite top_muxes[] = {
0x0080, 8, 2, 15),
MUX_GATE(CLK_TOP_DPI0_SEL, "dpi0_sel", dpi0_parents,
0x0080, 16, 3, 23),
-   MUX_GATE(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
-   0x0080, 24, 2, 31),
+   MUX_GATE_FLAGS_2(CLK_TOP_DPI1_SEL, "dpi1_sel", dpi1_parents,
+   0x0080, 24, 2, 31, 0, CLK_MUX_ROUND_CLOSEST),
 
MUX_GATE(CLK_TOP_TVE_SEL, "tve_sel", tve_parents,
0x0090, 0, 3, 7),
-- 
2.14.1

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

[PATCH 2/2] drm/panel: Add support for EDT ETM0430G0DH6

[Marek Vasut]

The EDT ETM0430G0DH6 is 4.3" 480x272 panel, which can be
supported by the simple panel driver.

Signed-off-by: Marek Vasut 
Cc: Philipp Zabel 
Cc: Thierry Reding 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..bd4b18ef7226 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1096,6 +1096,30 @@ static const struct panel_desc dlc_dlc1010gig = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
 };
 
+static const struct drm_display_mode edt_etm0430g0dh6_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 2,
+   .hsync_end = 480 + 2 + 41,
+   .htotal = 480 + 2 + 41 + 2,
+   .vdisplay = 272,
+   .vsync_start = 272 + 2,
+   .vsync_end = 272 + 2 + 10,
+   .vtotal = 272 + 2 + 10 + 2,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc edt_etm0430g0dh6 = {
+   .modes = _etm0430g0dh6_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+};
+
 static const struct drm_display_mode edt_et057090dhu_mode = {
.clock = 25175,
.hdisplay = 640,
@@ -2619,6 +2643,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "dlc,dlc1010gig",
.data = _dlc1010gig,
+   }, {
+   .compatible = "edt,etm0430g0dh6",
+   .data = _etm0430g0dh6,
}, {
.compatible = "edt,et057090dhu",
.data = _et057090dhu,
-- 
2.19.2

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

Re: [RFC v4 08/17] kunit: test: add support for test abort

[Frank Rowand]

On 2/19/19 7:39 PM, Brendan Higgins wrote:
> On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand  wrote:
>>
>> On 2/14/19 1:37 PM, Brendan Higgins wrote:
>>> Add support for aborting/bailing out of test cases. Needed for
>>> implementing assertions.
>>>
>>> Signed-off-by: Brendan Higgins 
>>> ---
>>> Changes Since Last Version
>>>  - This patch is new introducing a new cross-architecture way to abort
>>>out of a test case (needed for KUNIT_ASSERT_*, see next patch for
>>>details).
>>>  - On a side note, this is not a complete replacement for the UML abort
>>>mechanism, but covers the majority of necessary functionality. UML
>>>architecture specific featurs have been dropped from the initial
>>>patchset.
>>> ---
>>>  include/kunit/test.h |  24 +
>>>  kunit/Makefile   |   3 +-
>>>  kunit/test-test.c| 127 ++
>>>  kunit/test.c | 208 +--
>>>  4 files changed, 353 insertions(+), 9 deletions(-)
>>>  create mode 100644 kunit/test-test.c
>>
>> < snip >
>>
>>> diff --git a/kunit/test.c b/kunit/test.c
>>> index d18c50d5ed671..6e5244642ab07 100644
>>> --- a/kunit/test.c
>>> +++ b/kunit/test.c
>>> @@ -6,9 +6,9 @@
>>>   * Author: Brendan Higgins 
>>>   */
>>>
>>> -#include 
>>>  #include 
>>> -#include 
>>> +#include 
>>> +#include 
>>>  #include 
>>>
>>>  static bool kunit_get_success(struct kunit *test)
>>> @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool 
>>> success)
>>>   spin_unlock_irqrestore(>lock, flags);
>>>  }
>>>
>>> +static bool kunit_get_death_test(struct kunit *test)
>>> +{
>>> + unsigned long flags;
>>> + bool death_test;
>>> +
>>> + spin_lock_irqsave(>lock, flags);
>>> + death_test = test->death_test;
>>> + spin_unlock_irqrestore(>lock, flags);
>>> +
>>> + return death_test;
>>> +}
>>> +
>>> +static void kunit_set_death_test(struct kunit *test, bool death_test)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(>lock, flags);
>>> + test->death_test = death_test;
>>> + spin_unlock_irqrestore(>lock, flags);
>>> +}
>>> +
>>>  static int kunit_vprintk_emit(const struct kunit *test,
>>> int level,
>>> const char *fmt,
>>> @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct 
>>> kunit_stream *stream)
>>>   stream->commit(stream);
>>>  }
>>>
>>> +static void __noreturn kunit_abort(struct kunit *test)
>>> +{
>>> + kunit_set_death_test(test, true);
>>> +
>>> + test->try_catch.throw(>try_catch);
>>> +
>>> + /*
>>> +  * Throw could not abort from test.
>>> +  */
>>> + kunit_err(test, "Throw could not abort from test!");
>>> + show_stack(NULL, NULL);
>>> + BUG();
>>
>> kunit_abort() is what will be call as the result of an assert failure.
> 
> Yep. Does that need clarified somewhere.
>>
>> BUG(), which is a panic, which is crashing the system is not acceptable
>> in the Linux kernel.  You will just annoy Linus if you submit this.
> 
> Sorry, I thought this was an acceptable use case since, a) this should
> never be compiled in a production kernel, b) we are in a pretty bad,
> unpredictable state if we get here and keep going. I think you might
> have said elsewhere that you think "a" is not valid? In any case, I
> can replace this with a WARN, would that be acceptable?

A WARN may or may not make sense, depending on the context.  It may
be sufficient to simply report a test failure (as in the old version
of case (2) below.

Answers to "a)" and "b)":

a) it might be in a production kernel

a') it is not acceptable in my development kernel either

b) No.  You don't crash a developer's kernel either unless it is
required to avoid data corruption.

b') And you can not do replacements like:

(1) in of_unittest_check_tree_linkage()

-  old  -

if (!of_root)
return;

-  new  -

KUNIT_ASSERT_NOT_ERR_OR_NULL(test, of_root);

(2) in of_unittest_property_string()

-  old  -

/* of_property_read_string_index() tests */
rc = of_property_read_string_index(np, "string-property", 0, strings);
unittest(rc == 0 && !strcmp(strings[0], "foobar"), 
"of_property_read_string_index() failure; rc=%i\n", rc);

-  new  -

/* of_property_read_string_index() tests */
rc = of_property_read_string_index(np, "string-property", 0, strings);
KUNIT_ASSERT_EQ(test, rc, 0);
KUNIT_EXPECT_STREQ(test, strings[0], "foobar");


If a test fails, that is no reason to abort testing.  The remainder of the unit
tests can still run.  There may be cascading failures, but that is ok.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V5 8/8] drm/mediatek: fix the rate of parent for hdmi phy in MT2701

[wangyan wang]

From: chunhui dai 

We should not change the rate of parent for hdmi phy when
doing round_rate for this clock. The parent clock of hdmi
phy must be the same as it. We change it when doing set_rate
only.

Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 14 --
 drivers/gpu/drm/mediatek/mtk_hdmi_phy.h|  3 ---
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 11 +++
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 14 ++
 4 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
index 370309d684ec..ca8bc1489f37 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -15,20 +15,6 @@ static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.owner = THIS_MODULE,
 };
 
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate)
-{
-   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-
-   hdmi_phy->pll_rate = rate;
-   if (rate <= 7425)
-   *parent_rate = rate;
-   else
-   *parent_rate = rate / 2;
-
-   return rate;
-}
-
 u32 mtk_hdmi_phy_read(struct mtk_hdmi_phy *hdmi_phy, u32 offset)
 {
return readl(hdmi_phy->regs + offset);
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h 
b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
index 446e2acd1926..c6061ad15ff0 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.h
@@ -50,9 +50,6 @@ void mtk_hdmi_phy_set_bits(struct mtk_hdmi_phy *hdmi_phy, u32 
offset,
 void mtk_hdmi_phy_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
   u32 val, u32 mask);
 struct mtk_hdmi_phy *to_mtk_hdmi_phy(struct clk_hw *hw);
-long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
-unsigned long *parent_rate);
-
 extern struct platform_driver mtk_hdmi_phy_driver;
 extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
 extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 88dd9e812ca0..33893a180c2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -152,6 +152,17 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
  RG_HDMITX_DRV_IBIAS_MASK);
return 0;
 }
+
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+   hdmi_phy->pll_rate = rate;
+
+   return rate;
+}
+
 static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
   unsigned long parent_rate)
 {
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 63dde42521b8..3a339f516613 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -285,6 +285,20 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
return 0;
 }
 
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
+
+   hdmi_phy->pll_rate = rate;
+   if (rate <= 7425)
+   *parent_rate = rate;
+   else
+   *parent_rate = rate / 2;
+
+   return rate;
+}
+
 static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
   unsigned long parent_rate)
 {
-- 
2.14.1

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

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On 2/20/19 9:07 AM, Christian König wrote:

Am 20.02.19 um 07:41 schrieb Thomas Hellstrom:

On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:

On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:

On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:

Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:

On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:

Another good question is also why the heck the acc_size
counts
towards
the DMA32 zone?

DMA32 TTM pages are accounted in the DMA32 zone. Other pages
are
not.

Yeah, I'm perfectly aware of this. But this is for the accounting
size!

We have an accounting for the stuff needed additional to the
pages
backing the BO (e.g. the page and DMA addr array).

And from the bug description it sounds like we use the DMA32 zone
for
this accounting which of course is completely nonsense.

It's actually accounted in all available zones, since it would be
pretty hard to determine exactly where that memory should be
accounted.
In particular if it's vmalloced. It might be DMA32, it might not.
Given
the objective of stopping malicious user-space from exhausting the
DMA32 zone it was, at the time the code was written, a reasonable
approximation. With ever increasing memory sizes, there might be
better
solutions?

As far as I can see, in TTM, ttm_mem_global_alloc is only used for
the
acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems
to
use it to account for a few things that are allocated with kmalloc.

So would a better solution be to change ttm_mem_global_alloc to use
only
the kernel zone?


IMO we need to determine what functionality to keep and then the best
solution. The current code does its job, but is obviously too
restrictive. Both of the solutions you suggest open up for potential
DOS attacks (DMA32 and kernel zones are not mutually exclusive. They
overlap).


Yeah and exactly because of this it doesn't make to much sense to 
account the housekeeping stuff in both zones.


IMO it makes sense because (given the assumption that kmalloc/vmalloc 
doesn't care) , accounting only in DMA32 in low memory configurations 
will not guarantee that kernel is not exhausted. Accounting only in 
kernel in huge memory configurations will not guarantee that DMA32 is 
not exhausted.




IIRC the kernel takes perfectly care by itself that kmalloced memory 
doesn't eat up everything in the DMA32 zone.


If we can somehow verify this, or at least illustrate that it's likely, 
I'm perfectly fine with either patch from the vmwgfx POW.


Thanks,
Thomas





Christian.




/Thomas





Regards,
    Felix



/Thomas


Christian.


For small persistent allocations using ttm_mem_global_alloc(),
they
are
accounted also in the DMA32 zone, which may cause over-
accounting
of
that zone, but that's pretty unlikely to be a big problem..

/Thomas






In other words why should the internal bookkeeping pages be
allocated
in
the DMA32 zone?

That doesn't sounds valid to me in any way,
Christian.

Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:

Hmm,

This zone was intended to stop TTM page allocations from
exhausting
the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
default,
which
means if we drop this check, other devices may stop
functioning
unexpectedly?

However, in the end I'd expect the kernel page allocation
system
to
make sure there are some pages left in the DMA32 zone,
otherwise
random non-IO page allocations would also potentially
exhaust
the
DMA32 zone without anybody caring, which means removing
this
zone
wouldn't be any worse than whatever other subsystems may be
doing
already...

/Thomas


On 2/16/19 12:02 AM, Kuehling, Felix wrote:

This is an RFC. I'm not sure this is the right solution,
but
it
highlights the problem I'm trying to solve.

The dma32_zone limits the acc_size of all allocated BOs
to
2GB.
On a
64-bit system with hundreds of GB of system memory and
GPU
memory,
this can become a bottle neck. We're seeing TTM memory
allocation
failures not because we're truly out of memory, but
because
we're
out of space in the dma32_zone for the acc_size needed
for
our BO
book-keeping.

Signed-off-by: Felix Kuehling 
CC: thellst...@vmware.com
CC: christian.koe...@amd.com
---
 drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index f1567c3..bb05365 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -363,7 +363,7 @@ static int
ttm_mem_init_highmem_zone(struct
ttm_mem_global *glob,
 glob->zones[glob->num_zones++] = zone;
 return 0;
 }
-#else
+#elifndef CONFIG_64BIT
 static int ttm_mem_init_dma32_zone(struct
ttm_mem_global
*glob,
    const struct sysinfo *si)
 {
@@ -441,7 +441,7 @@ int ttm_mem_global_init(struct
ttm_mem_global
*glob)
 ret = ttm_mem_init_highmem_zone(glob, );
 if (unlikely(ret != 0))
 goto out_no_zone;

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Koenig, Christian]

Am 20.02.19 um 09:10 schrieb zhoucm1:


On 2019年02月20日 15:59, Koenig, Christian wrote:
Am 20.02.19 um 05:53 schrieb zhoucm1:


On 2019年02月19日 19:32, Koenig, Christian wrote:
Hi David,

Could you have a look if it's reasonable?

Patch #1 is also something I already fixed on my local branch.

But patch #2 won't work like this.

We can't return an error from drm_syncobj_add_point() because we already 
submitted work to the hardware. And just dropping the fence like you do in the 
patch is a clearly no-go as well.

Then do you have any idea to skip the messed order signal point?

No, I don't think we can actually do this.
But as Lionel pointed out, user mode shouldn't query a smaller timeline payload 
compared to last time, we must skip messed order signal point!

No we don't.

That userspace queries a smaller timeline payload compared to last time is 
because userspace messed up signaling order in the first place.

Additional to that I'm not sure that userspace would query a smaller timeline 
payload. IIRC our workaround for messed up signaling order handled that case 
gracefully as well.

Christian.


-David


The only solution I can see would be to lock down the syncobj to modifications 
while command submission is in progress. And that in turn would mean a huge 
bunch of ww_mutex overhead we will certainly want to avoid.

Christian.


-David

Regards,
Christian.

Am 19.02.19 um 11:46 schrieb zhoucm1:

Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is already rebased 
to latest drm-misc(kernel 5.0). You can directly use that branch.


-David

On 2019年02月19日 01:01, Koenig, Christian wrote:
Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:
Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj implementation?

David is the expert on that, but as far as I know that is forbidden by the 
vulkan spec.

I'm not finding anything in the vulkan spec that makes out of order signaling 
illegal.
That's why I came up with this test, just verifying that the timeline does not 
go backward in term of its payload.

Well we need to handle this case gracefully in the kernel, so it is still a 
good testcase.

Christian.


-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:
Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. either the 
same way as during CS or we abort and return an error message.

I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, and we 
shouldn't lead to deadlock.

Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a warning?

Otherwise like Lionel's unexpected use cases, which easily leads to deadlock.


-David

On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: 

Re: [PATCH v1 2/2] drm/mediatek: add mipi_tx driver for mt8183

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-19 at 17:14 +0800, Jitao Shi wrote:
> This patch add mt8183 mipi_tx driver.
> And also support other chips that use the same binding and driver.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c|   2 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.h|   1 +
>  drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 ++
>  3 files changed, 171 insertions(+)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fa361c8be8d7..83fb7717d383 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -198,6 +198,8 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
> .data = _mipitx_data },
>   { .compatible = "mediatek,mt8173-mipi-tx",
> .data = _mipitx_data },
> + { .compatible = "mediatek,mt8183-mipi-tx",

This compatible string does not exist in [1], please add it.

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/mediatek/mediatek%2Cdsi.txt

> +   .data = _mipitx_data },
>   { },
>  };
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> index 2d7f05b0d6a7..af83023e81cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> @@ -47,5 +47,6 @@ unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
>  
>  extern const struct mtk_mipitx_data mt2701_mipitx_data;
>  extern const struct mtk_mipitx_data mt8173_mipitx_data;
> +extern const struct mtk_mipitx_data mt8183_mipitx_data;
>  
>  #endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> new file mode 100644
> index ..07f70a3cad13
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.

2019

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */

Please follow the license rule [1].

[1] https://www.kernel.org/doc/html/v4.20/process/license-rules.html

> +
> +#include "mtk_mipi_tx.h"
> +
> +#define MIPITX_LANE_CON  0x000c
> +#define RG_DSI_CPHY_T1DRV_EN BIT(0)
> +#define RG_DSI_ANA_CK_SELBIT(1)
> +#define RG_DSI_PHY_CK_SELBIT(2)
> +#define RG_DSI_CPHY_EN   BIT(3)
> +#define RG_DSI_PHYCK_INV_EN  BIT(4)
> +#define RG_DSI_PWR04_EN  BIT(5)
> +#define RG_DSI_BG_LPF_EN BIT(6)
> +#define RG_DSI_BG_CORE_ENBIT(7)
> +#define RG_DSI_PAD_TIEL_SEL  BIT(8)

Aligned to mt8173_mipi_tx.c, bitwise definition would add one more
'tab'.

> +
> +#define MIPITX_PLL_PWR   0x0028
> +#define MIPITX_PLL_CON0  0x002c
> +#define MIPITX_PLL_CON1  0x0030
> +#define MIPITX_PLL_CON2  0x0034
> +#define MIPITX_PLL_CON3  0x0038
> +#define MIPITX_PLL_CON4  0x003c
> +#define RG_DSI_PLL_IBIAS (3 << 10)
> +
> +#define MIPITX_D2_SW_CTL_EN  0x0144
> +#define MIPITX_D0_SW_CTL_EN  0x0244
> +#define MIPITX_CK_CKMODE_EN  0x0328
> +#define DSI_CK_CKMODE_EN BIT(0)
> +#define MIPITX_CK_SW_CTL_EN  0x0344
> +#define MIPITX_D1_SW_CTL_EN  0x0444
> +#define MIPITX_D3_SW_CTL_EN  0x0544
> +#define DSI_SW_CTL_ENBIT(0)
> +#define AD_DSI_PLL_SDM_PWR_ONBIT(0)
> +#define AD_DSI_PLL_SDM_ISO_ENBIT(1)
> +
> +#define RG_DSI_PLL_ENBIT(4)
> +#define RG_DSI_PLL_POSDIV(0x7 << 8)
> +
> +static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
> +{
> + struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
> + unsigned int txdiv, txdiv0, txdiv1;

txdiv1 is useless, so remove it.

> + u64 pcw;
> + int ret;
> +
> + dev_dbg(mipi_tx->dev, "prepare: %u bps\n", mipi_tx->data_rate);
> +
> + if (mipi_tx->data_rate >= 20) {
> + txdiv = 1;
> + txdiv0 = 0;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 10) {
> + txdiv = 2;
> + txdiv0 = 1;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 5) {
> + txdiv = 4;
> + txdiv0 = 2;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate > 25000) {
> + txdiv = 8;
> + txdiv0 = 3;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 12500) {
> + txdiv = 16;
> + txdiv0 = 4;
> + txdiv1 = 0;
> + } else {
> +

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On Wed, 2019-02-20 at 08:35 +, Koenig, Christian wrote:
> Am 20.02.19 um 09:14 schrieb Thomas Hellstrom:
> > On 2/20/19 9:07 AM, Christian König wrote:
> > > Am 20.02.19 um 07:41 schrieb Thomas Hellstrom:
> > > > On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
> > > > > On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> > > > > > On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> > > > > > > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > > > > > > > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian
> > > > > > > > wrote:
> > > > > > > > > Another good question is also why the heck the
> > > > > > > > > acc_size
> > > > > > > > > counts
> > > > > > > > > towards
> > > > > > > > > the DMA32 zone?
> > > > > > > > DMA32 TTM pages are accounted in the DMA32 zone. Other
> > > > > > > > pages
> > > > > > > > are
> > > > > > > > not.
> > > > > > > Yeah, I'm perfectly aware of this. But this is for the
> > > > > > > accounting
> > > > > > > size!
> > > > > > > 
> > > > > > > We have an accounting for the stuff needed additional to
> > > > > > > the
> > > > > > > pages
> > > > > > > backing the BO (e.g. the page and DMA addr array).
> > > > > > > 
> > > > > > > And from the bug description it sounds like we use the
> > > > > > > DMA32 zone
> > > > > > > for
> > > > > > > this accounting which of course is completely nonsense.
> > > > > > It's actually accounted in all available zones, since it
> > > > > > would be
> > > > > > pretty hard to determine exactly where that memory should
> > > > > > be
> > > > > > accounted.
> > > > > > In particular if it's vmalloced. It might be DMA32, it
> > > > > > might not.
> > > > > > Given
> > > > > > the objective of stopping malicious user-space from
> > > > > > exhausting the
> > > > > > DMA32 zone it was, at the time the code was written, a
> > > > > > reasonable
> > > > > > approximation. With ever increasing memory sizes, there
> > > > > > might be
> > > > > > better
> > > > > > solutions?
> > > > > As far as I can see, in TTM, ttm_mem_global_alloc is only
> > > > > used for
> > > > > the
> > > > > acc_size in ttm_bo_init_reserved. Other than that vmwgfx also
> > > > > seems
> > > > > to
> > > > > use it to account for a few things that are allocated with
> > > > > kmalloc.
> > > > > 
> > > > > So would a better solution be to change ttm_mem_global_alloc
> > > > > to use
> > > > > only
> > > > > the kernel zone?
> > > > > 
> > > > IMO we need to determine what functionality to keep and then
> > > > the best
> > > > solution. The current code does its job, but is obviously too
> > > > restrictive. Both of the solutions you suggest open up for
> > > > potential
> > > > DOS attacks (DMA32 and kernel zones are not mutually exclusive.
> > > > They
> > > > overlap).
> > > 
> > > Yeah and exactly because of this it doesn't make to much sense
> > > to 
> > > account the housekeeping stuff in both zones.
> > 
> > IMO it makes sense because (given the assumption that
> > kmalloc/vmalloc 
> > doesn't care) , accounting only in DMA32 in low memory
> > configurations 
> > will not guarantee that kernel is not exhausted. Accounting only
> > in 
> > kernel in huge memory configurations will not guarantee that DMA32
> > is 
> > not exhausted.
> 
> DMA32 is not exhausted by TTMs kmalloc/vmalloc because otherwise any 
> other kmalloc/vmalloc could exhaust it as well.
> 
> I mean its probably 20+ years ago that I last looked at stuff in
> this 
> part of the kernel, but I don't think we have ever changed the
> handling 
> of DMA/DMA32 or otherwise we would be running into massive
> exhaustion 
> problems already on modern systems.
> 
> > > IIRC the kernel takes perfectly care by itself that kmalloced
> > > memory 
> > > doesn't eat up everything in the DMA32 zone.
> > 
> > If we can somehow verify this, or at least illustrate that it's 
> > likely, I'm perfectly fine with either patch from the vmwgfx POW.
> 
> Well I actually think that the whole accounting of housekeeping
> towards 
> the memory zones is completely pointless in the first place. Even if
> we 
> swap things out we still have the same BO and TTM structures around
> anyway.

Well, the whole point of this is to stop malicious user-space apps from
exhausting memory, causing a DOS vulnerability, similaraly for example
to how processes are stopped from creating to many open file
descriptors or other kernel structures. IIRC, for example, you used to
be able to call gem open in an infinite loop with the same bo until you
brought a random big process down using the OOM killer. With vmwgfx you
can't do that. You'd end up swapping out all available BOs and then
you'd get an error.

> 
> What we should rather to is to make sure that all processes using a
> BO 
> have their RSS increased because they do so. So when a process tries
> to 
> exhaust a memory domain it is simply killed by the OOM killer.

Yes, if there is a way to reliably do that and also take care of other
kernel structures that are created by 

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Christian König]

Am 20.02.19 um 07:41 schrieb Thomas Hellstrom:

On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:

On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:

On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:

Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:

On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:

Another good question is also why the heck the acc_size
counts
towards
the DMA32 zone?

DMA32 TTM pages are accounted in the DMA32 zone. Other pages
are
not.

Yeah, I'm perfectly aware of this. But this is for the accounting
size!

We have an accounting for the stuff needed additional to the
pages
backing the BO (e.g. the page and DMA addr array).

And from the bug description it sounds like we use the DMA32 zone
for
this accounting which of course is completely nonsense.

It's actually accounted in all available zones, since it would be
pretty hard to determine exactly where that memory should be
accounted.
In particular if it's vmalloced. It might be DMA32, it might not.
Given
the objective of stopping malicious user-space from exhausting the
DMA32 zone it was, at the time the code was written, a reasonable
approximation. With ever increasing memory sizes, there might be
better
solutions?

As far as I can see, in TTM, ttm_mem_global_alloc is only used for
the
acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems
to
use it to account for a few things that are allocated with kmalloc.

So would a better solution be to change ttm_mem_global_alloc to use
only
the kernel zone?


IMO we need to determine what functionality to keep and then the best
solution. The current code does its job, but is obviously too
restrictive. Both of the solutions you suggest open up for potential
DOS attacks (DMA32 and kernel zones are not mutually exclusive. They
overlap).


Yeah and exactly because of this it doesn't make to much sense to 
account the housekeeping stuff in both zones.


IIRC the kernel takes perfectly care by itself that kmalloced memory 
doesn't eat up everything in the DMA32 zone.


Christian.




/Thomas





Regards,
Felix



/Thomas


Christian.


For small persistent allocations using ttm_mem_global_alloc(),
they
are
accounted also in the DMA32 zone, which may cause over-
accounting
of
that zone, but that's pretty unlikely to be a big problem..

/Thomas






In other words why should the internal bookkeeping pages be
allocated
in
the DMA32 zone?

That doesn't sounds valid to me in any way,
Christian.

Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:

Hmm,

This zone was intended to stop TTM page allocations from
exhausting
the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
default,
which
means if we drop this check, other devices may stop
functioning
unexpectedly?

However, in the end I'd expect the kernel page allocation
system
to
make sure there are some pages left in the DMA32 zone,
otherwise
random non-IO page allocations would also potentially
exhaust
the
DMA32 zone without anybody caring, which means removing
this
zone
wouldn't be any worse than whatever other subsystems may be
doing
already...

/Thomas


On 2/16/19 12:02 AM, Kuehling, Felix wrote:

This is an RFC. I'm not sure this is the right solution,
but
it
highlights the problem I'm trying to solve.

The dma32_zone limits the acc_size of all allocated BOs
to
2GB.
On a
64-bit system with hundreds of GB of system memory and
GPU
memory,
this can become a bottle neck. We're seeing TTM memory
allocation
failures not because we're truly out of memory, but
because
we're
out of space in the dma32_zone for the acc_size needed
for
our BO
book-keeping.

Signed-off-by: Felix Kuehling 
CC: thellst...@vmware.com
CC: christian.koe...@amd.com
---
 drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index f1567c3..bb05365 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -363,7 +363,7 @@ static int
ttm_mem_init_highmem_zone(struct
ttm_mem_global *glob,
 glob->zones[glob->num_zones++] = zone;
 return 0;
 }
-#else
+#elifndef CONFIG_64BIT
 static int ttm_mem_init_dma32_zone(struct
ttm_mem_global
*glob,
const struct sysinfo *si)
 {
@@ -441,7 +441,7 @@ int ttm_mem_global_init(struct
ttm_mem_global
*glob)
 ret = ttm_mem_init_highmem_zone(glob, );
 if (unlikely(ret != 0))
 goto out_no_zone;
-#else
+#elifndef CONFIG_64BIT
 ret = ttm_mem_init_dma32_zone(glob, );
 if (unlikely(ret != 0))
 goto out_no_zone;

___
amd-gfx mailing list
amd-...@lists.freedesktop.org

[PATCH] drm: add func to better detect wether swiotlb is needed

[Michael D Labriola]

This commit fixes DRM failures on Xen PV systems that were introduced in
v4.17 by the following commits:

82626363 drm: add func to get max iomem address v2
fd5fd480 drm/amdgpu: only enable swiotlb alloc when need v2
1bc3d3cc drm/radeon: only enable swiotlb path when need v2

The introduction of ->need_swiotlb to the ttm_dma_populate() conditionals
in the radeon and amdgpu device drivers causes Gnome to immediately crash
on Xen PV systems, returning the user to the login screen.  The following
kernel errors get logged:

[   28.554259] radeon_dp_aux_transfer_native: 200 callbacks suppressed
[   31.219821] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   31.220030] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   31.226109] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   31.226300] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   31.300734] gnome-shell[1935]: segfault at 88 ip 7f39151cd904 sp 
7ffc97611ad8 error 4 in libmutter-cogl.so[7f3915178000+aa000]
[   31.300745] Code: 5f c3 0f 1f 40 00 48 8b 47 78 48 8b 40 40 ff e0 66 0f 1f 
44 00 00 48 8b 47 78 48 8b 40 48 ff e0 66 0f 1f 44 00 00 48 8b 47 78 <48> 8b 80 
88 00 00 00 ff e0 0f 1f 00 48 8b 47 78 48 8b 40 68 ff e0
[   38.193302] radeon_dp_aux_transfer_native: 116 callbacks suppressed
[   40.009317] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   40.009488] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   40.015114] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes)
[   40.015297] [drm:radeon_gem_object_create [radeon]] *ERROR* Failed to 
allocate GEM object (16384000, 2, 4096, -14)
[   40.028302] gnome-shell[2431]: segfault at 2dadf40 ip 02dadf40 sp 
7ffcd24ea5f8 error 15
[   40.028306] Code: 20 6e 31 00 00 00 00 00 00 00 00 37 e3 3d 2d 7f 00 00 80 
f4 e6 3d 2d 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 
00 00 00 00 00 c1 00 00 00 00 00 00 00 80 e1 d2 03 00 00

This commit renames drm_get_max_iomem() to drm_need_swiotlb(), adds a
xen_pv_domain() check to it, and moves the bit shifting comparison that
always follows its usage into the function (simplifying the drm driver
code).

Signed-off-by: Michael D Labriola 
---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c  |  2 +-
 drivers/gpu/drm/drm_memory.c   | 19 ---
 drivers/gpu/drm/radeon/radeon_device.c |  2 +-
 include/drm/drm_cache.h|  2 +-
 6 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 910c4ce..6bc0266 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -1029,7 +1029,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 747c068..8638adf 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -1155,7 +1155,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index f35d7a5..4f67093 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -989,7 +989,7 @@ static int gmc_v9_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
printk(KERN_WARNING "amdgpu: No coherent DMA available.\n");
}
-   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
+   adev->need_swiotlb = drm_need_swiotlb(dma_bits);
 
if (adev->asic_type == CHIP_VEGA20) {
r = gfxhub_v1_1_get_xgmi_info(adev);
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index d69e4fc..6af59a6 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include "drm_legacy.h"
 
@@ -150,15 +151,27 @@ void drm_legacy_ioremapfree(struct drm_local_map *map, 
struct 

[PATCH 1/2] dt-bindings: display: Add ETM0430G0DH6 bindings

[Marek Vasut]

Document the Emerging Display Technology Corp. (EDT) ETM0430G0DH6
display, which is a 480x272 4.3" TFT display.

Signed-off-by: Marek Vasut 
Cc: Rob Herring 
Cc: Jan Tuerk 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
---
 .../devicetree/bindings/display/panel/edt,et-series.txt   | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
index f56b99ebd9be..d9f21d62422e 100644
--- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
+++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
@@ -6,6 +6,14 @@ Display bindings for EDT Display Technology Corp. Displays 
which are
 compatible with the simple-panel binding, which is specified in
 simple-panel.txt
 
+4,3" WVGA TFT Panels
+
+
++-+-+-+
+| Identifier  | compatbile  | description |
++=+=+=+
+| ETM0430G0DH6| edt,etm0430g0dh6| 480x272 TFT Display |
++-+-+-+
 
 5,7" WVGA TFT Panels
 
-- 
2.19.2

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

[PATCH V5 4/8] drm/mediatek: fix the rate and divder of hdmi phy for MT2701

[wangyan wang]

From: chunhui dai 

Due to a clerical error,there is one zero less for 1280.
Fix it for 12800.

Fixes: 0fc721b2968e ("drm/mediatek: add hdmi driver for MT2701 and MT7623")

Reviewed-by: CK Hu 
Signed-off-by: chunhui dai 
Signed-off-by: wangyan wang 
---
 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
index 43bc058d5528..88dd9e812ca0 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -114,8 +114,8 @@ static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, 
unsigned long rate,
 
if (rate <= 6400)
pos_div = 3;
-   else if (rate <= 1280)
-   pos_div = 1;
+   else if (rate <= 12800)
+   pos_div = 2;
else
pos_div = 1;
 
-- 
2.14.1

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

Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[zhoucm1]

On 2019年02月20日 15:59, Koenig, Christian wrote:

Am 20.02.19 um 05:53 schrieb zhoucm1:




On 2019年02月19日 19:32, Koenig, Christian wrote:

Hi David,


Could you have a look if it's reasonable?


Patch #1 is also something I already fixed on my local branch.

But patch #2 won't work like this.

We can't return an error from drm_syncobj_add_point() because we 
already submitted work to the hardware. And just dropping the fence 
like you do in the patch is a clearly no-go as well.


Then do you have any idea to skip the messed order signal point?


No, I don't think we can actually do this.
But as Lionel pointed out, user mode shouldn't query a smaller timeline 
payload compared to last time, we must skip messed order signal point!


-David



The only solution I can see would be to lock down the syncobj to 
modifications while command submission is in progress. And that in 
turn would mean a huge bunch of ww_mutex overhead we will certainly 
want to avoid.


Christian.



-David


Regards,
Christian.

Am 19.02.19 um 11:46 schrieb zhoucm1:


Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is 
already rebased to latest drm-misc(kernel 5.0). You can directly 
use that branch.



-David


On 2019年02月19日 01:01, Koenig, Christian wrote:

Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:

Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj 
implementation?


David is the expert on that, but as far as I know that is 
forbidden by the vulkan spec.


I'm not finding anything in the vulkan spec that makes out of 
order signaling illegal.
That's why I came up with this test, just verifying that the 
timeline does not go backward in term of its payload.


Well we need to handle this case gracefully in the kernel, so it 
is still a good testcase.


Christian.



-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:

Hi David,

well I think Lionel is testing the invalid signal order on 
purpose :)


Anyway we really need to handle invalid order graceful here. 
E.g. either the same way as during CS or we abort and return an 
error message.


I think just using the same approach as during CS ist the best 
we can do.


Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:


Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't 
in-order, and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just 
give a warning?


Otherwise like Lionel's unexpected use cases, which easily leads 
to deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 

[PATCH v4 2/3] dt-bindings: panel: Add YAML schemas for the Ronbo RB070D30 panel

[Maxime Ripard]

The Ronbo RB070D30 panel is a 1024x600 MIPI-DSI panel.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml | 52 

 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml 
b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
new file mode 100644
index ..a0e6fa1559cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR X11)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ronbo,rb070d30.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ronbo RB070D30 DSI Display Panel
+
+maintainers:
+  - Maxime Ripard 
+
+properties:
+  compatible:
+const: ronbo,rb070d30
+
+  reg:
+description: MIPI-DSI virtual channel
+
+  power-gpios:
+description: GPIO used for the power pin
+maxItems: 1
+
+  reset-gpios:
+description: GPIO used for the reset pin
+maxItems: 1
+
+  shlr-gpios:
+description: GPIO used for the shlr pin (horizontal flip)
+maxItems: 1
+
+  updn-gpios:
+description: GPIO used for the updn pin (vertical flip)
+maxItems: 1
+
+  vcc-lcd-supply:
+description: Power regulator
+
+  backlight:
+description: Backlight used by the panel
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+required:
+  - compatible
+  - power-gpios
+  - reg
+  - reset-gpios
+  - shlr-gpios
+  - updn-gpios
+  - vcc-lcd-supply
+
+additionalProperties: false
+  
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/3] drm/panel: Add Ronbo RB070D30 panel

[Maxime Ripard]

From: Konstantin Sudakov 

The Ronbo RB070D30 panel is a MIPI-DSI panel based on a Fitipower EK79007
controller and a 1024x600 panel.

Reviewed-by: Paul Kocialkowski 
Reviewed-by: Sam Ravnborg 
Signed-off-by: Konstantin Sudakov 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/Kconfig|   9 +-
 drivers/gpu/drm/panel/Makefile   |   1 +-
 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 258 -
 3 files changed, 268 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e070153ef21..f53f817356db 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -149,6 +149,15 @@ config DRM_PANEL_RAYDIUM_RM68200
  Say Y here if you want to enable support for Raydium RM68200
  720x1280 DSI video mode panel.
 
+config DRM_PANEL_RONBO_RB070D30
+   tristate "Ronbo Electronics RB070D30 panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Ronbo Electronics
+ RB070D30 1024x600 DSI panel.
+
 config DRM_PANEL_SAMSUNG_S6D16D0
tristate "Samsung S6D16D0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e7ab71968bbf..7834947a53b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += 
panel-orisetech-otm8009a.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) += 
panel-raspberrypi-touchscreen.o
 obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
+obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c 
b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
new file mode 100644
index ..3c15764f0c03
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018-2019, Bridge Systems BV
+ * Copyright (C) 2018-2019, Bootlin
+ * Copyright (C) 2017, Free Electrons
+ *
+ * This file based on panel-ilitek-ili9881c.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct rb070d30_panel {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+   struct backlight_device *backlight;
+   struct regulator *supply;
+
+   struct {
+   struct gpio_desc *power;
+   struct gpio_desc *reset;
+   struct gpio_desc *updn;
+   struct gpio_desc *shlr;
+   } gpios;
+};
+
+static inline struct rb070d30_panel *panel_to_rb070d30_panel(struct drm_panel 
*panel)
+{
+   return container_of(panel, struct rb070d30_panel, panel);
+}
+
+static int rb070d30_panel_prepare(struct drm_panel *panel)
+{
+   struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
+   int ret;
+
+   ret = regulator_enable(ctx->supply);
+   if (ret < 0) {
+   DRM_DEV_ERROR(>dsi->dev, "Failed to enable supply: %d\n", 
ret);
+   return ret;
+   }
+
+   msleep(20);
+   gpiod_set_value(ctx->gpios.power, 1);
+   msleep(20);
+   gpiod_set_value(ctx->gpios.reset, 1);
+   msleep(20);
+   return 0;
+}
+
+static int rb070d30_panel_unprepare(struct drm_panel *panel)
+{
+   struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
+
+   gpiod_set_value(ctx->gpios.reset, 0);
+   gpiod_set_value(ctx->gpios.power, 0);
+   regulator_disable(ctx->supply);
+
+   return 0;
+}
+
+static int rb070d30_panel_enable(struct drm_panel *panel)
+{
+   struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
+   int ret;
+
+   ret = mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
+   if (ret)
+   return ret;
+
+   ret = backlight_enable(ctx->backlight);
+   if (ret)
+   goto out;
+
+   return 0;
+
+out:
+   mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+   return ret;
+}
+
+static int rb070d30_panel_disable(struct drm_panel *panel)
+{
+   struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
+
+   backlight_disable(ctx->backlight);
+   return mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
+}
+
+/* Default timings */
+static const struct drm_display_mode default_mode = {
+   .clock  = 51206,
+   .hdisplay   = 1024,
+   .hsync_start= 1024 + 160,
+   .hsync_end  = 1024 

[PATCH v4 0/3] drm/panel: Add Ronbo RB070D30

[Maxime Ripard]

Hi,

Here is a series adding a driver for the Ronbo RB070D30 panel. This was
previously integrated in the DSI burst series, but those parts have been
merged since.

It's been tested on an Allwinner A33 board.

Let me know what you think,
Maxime

Changes from v3:
  - Added patches for the DT binding and vendor documentation
  - Addressed the comments from Sam and Paul
  - Dropped the merged patches
  - Fixed error in Ronbo panel error path

Changes from v2:
  - Change the start delay calculation according to the legacy driver in
Allwinner's BSP
  - Fixed the edge calculation to add the same parentheses around the
factors
  - Added a bunch of fixes to timings
  - Added a patch to make hblk computation more accurate, and added a
comment
  - Renamed the panel to Ronbo and fixed a bunch of things
  - Added the Reviewed-By

Konstantin Sudakov (2):
  dt-bindings: Add vendor prefix for Ronbo Electronics
  drm/panel: Add Ronbo RB070D30 panel

Maxime Ripard (1):
  dt-bindings: panel: Add YAML schemas for the Ronbo RB070D30 panel

 Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml |  52 
+++-
 Documentation/devicetree/bindings/vendor-prefixes.txt   |   1 +-
 drivers/gpu/drm/panel/Kconfig   |   9 +++-
 drivers/gpu/drm/panel/Makefile  |   1 +-
 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c| 258 
-
 5 files changed, 321 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-ronbo-rb070d30.c

base-commit: b68999315c0cea0f71efae4adbc3508abc9f0f9c
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/3] dt-bindings: Add vendor prefix for Ronbo Electronics

[Maxime Ripard]

From: Konstantin Sudakov 

Ronbo Electronics manufactures display panels.

Signed-off-by: Konstantin Sudakov 
Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4f225ce815d8..b64d8316dfae 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -337,6 +337,7 @@ riscv   RISC-V Foundation
 rockchip   Fuzhou Rockchip Electronics Co., Ltd
 rohm   ROHM Semiconductor Co., Ltd
 roofullShenzhen Roofull Technology Co, Ltd
+ronbo   Ronbo Electronics
 samsungSamsung Semiconductor
 samtec Samtec/Softing company
 sancloud   Sancloud Ltd
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Koenig, Christian]

Am 20.02.19 um 09:14 schrieb Thomas Hellstrom:
> On 2/20/19 9:07 AM, Christian König wrote:
>> Am 20.02.19 um 07:41 schrieb Thomas Hellstrom:
>>> On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
 On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
>> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
>>> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
 Another good question is also why the heck the acc_size
 counts
 towards
 the DMA32 zone?
>>> DMA32 TTM pages are accounted in the DMA32 zone. Other pages
>>> are
>>> not.
>> Yeah, I'm perfectly aware of this. But this is for the accounting
>> size!
>>
>> We have an accounting for the stuff needed additional to the
>> pages
>> backing the BO (e.g. the page and DMA addr array).
>>
>> And from the bug description it sounds like we use the DMA32 zone
>> for
>> this accounting which of course is completely nonsense.
> It's actually accounted in all available zones, since it would be
> pretty hard to determine exactly where that memory should be
> accounted.
> In particular if it's vmalloced. It might be DMA32, it might not.
> Given
> the objective of stopping malicious user-space from exhausting the
> DMA32 zone it was, at the time the code was written, a reasonable
> approximation. With ever increasing memory sizes, there might be
> better
> solutions?
 As far as I can see, in TTM, ttm_mem_global_alloc is only used for
 the
 acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems
 to
 use it to account for a few things that are allocated with kmalloc.

 So would a better solution be to change ttm_mem_global_alloc to use
 only
 the kernel zone?

>>> IMO we need to determine what functionality to keep and then the best
>>> solution. The current code does its job, but is obviously too
>>> restrictive. Both of the solutions you suggest open up for potential
>>> DOS attacks (DMA32 and kernel zones are not mutually exclusive. They
>>> overlap).
>>
>> Yeah and exactly because of this it doesn't make to much sense to 
>> account the housekeeping stuff in both zones.
>
> IMO it makes sense because (given the assumption that kmalloc/vmalloc 
> doesn't care) , accounting only in DMA32 in low memory configurations 
> will not guarantee that kernel is not exhausted. Accounting only in 
> kernel in huge memory configurations will not guarantee that DMA32 is 
> not exhausted.

DMA32 is not exhausted by TTMs kmalloc/vmalloc because otherwise any 
other kmalloc/vmalloc could exhaust it as well.

I mean its probably 20+ years ago that I last looked at stuff in this 
part of the kernel, but I don't think we have ever changed the handling 
of DMA/DMA32 or otherwise we would be running into massive exhaustion 
problems already on modern systems.

>>
>> IIRC the kernel takes perfectly care by itself that kmalloced memory 
>> doesn't eat up everything in the DMA32 zone.
>
> If we can somehow verify this, or at least illustrate that it's 
> likely, I'm perfectly fine with either patch from the vmwgfx POW.

Well I actually think that the whole accounting of housekeeping towards 
the memory zones is completely pointless in the first place. Even if we 
swap things out we still have the same BO and TTM structures around anyway.

What we should rather to is to make sure that all processes using a BO 
have their RSS increased because they do so. So when a process tries to 
exhaust a memory domain it is simply killed by the OOM killer.

Regards,
Christian.

>
> Thanks,
> Thomas
>
>
>
>>
>> Christian.
>>
>>>
>>>
>>> /Thomas
>>>
>>>
>>>
>>>
 Regards,
     Felix


> /Thomas
>
>> Christian.
>>
>>> For small persistent allocations using ttm_mem_global_alloc(),
>>> they
>>> are
>>> accounted also in the DMA32 zone, which may cause over-
>>> accounting
>>> of
>>> that zone, but that's pretty unlikely to be a big problem..
>>>
>>> /Thomas
>>>
>>>
>>>
>>>
>>>
 In other words why should the internal bookkeeping pages be
 allocated
 in
 the DMA32 zone?

 That doesn't sounds valid to me in any way,
 Christian.

 Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> Hmm,
>
> This zone was intended to stop TTM page allocations from
> exhausting
> the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> default,
> which
> means if we drop this check, other devices may stop
> functioning
> unexpectedly?
>
> However, in the end I'd expect the kernel page allocation
> system
> to
> make sure there are some pages left in the DMA32 zone,
> otherwise
> random 

Re: [PULL] topic/mei-hdcp

[Joonas Lahtinen]

Quoting Daniel Vetter (2019-02-19 09:55:27)
> Hi all,
> 
> topic/mei-hdcp-2019-02-19:
> Prep patches + headers for the mei-hdcp/i915 component interfaces
> 
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
> 
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
> 
> Joonas, please pull into drm-intel-next-queued so I can apply the i915
> hdcp patches.

This is now pulled.

Regards, Joonas

> 
> Greg/Arnd, I think there's two options to get the mei-hdcp patches landed
> into drivers-misc:
> - You pull this topic pull and then apply the mei-hdcp patches on top in
>   char-misc-next.
> - I also pull in char-misc-next to get at 32ea33a04484 ("mei: bus: export
>   to_mei_cl_device for mei client devices drivers") and then apply all the
>   mei-hdcp stuff into a new topic branch.
> 
> I think 2nd option would be better, allows us to integration test easier,
> and we'll have a topic branch in case we need a fixup spanning mei-hdcp
> and i915. Also would allow me to start merging the patches, since I think
> it's too late for 5.1.
> 
> Cheers, Daniel
> 
> The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:
> 
>   Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-intel tags/topic/mei-hdcp-2019-02-19
> 
> for you to fetch changes up to 35c0272502cca0a1b461d310c23aac94a503983d:
> 
>   drm/audio: declaration of struct device (2019-02-18 20:19:28 +0100)
> 
> 
> Prep patches + headers for the mei-hdcp/i915 component interfaces
> 
> Also contains the prep work in the component helpers plus adjustements
> for the snd-hda/i915 component interface.
> 
> Plus one small static inline in the drm_hdcp.h header that both i915
> and mei_hdcp will need.
> 
> 
> Daniel Vetter (3):
>   component: Add documentation
>   components: multiple components for a device
>   i915/snd_hdac: I915 subcomponent for the snd_hdac
> 
> Ramalingam C (5):
>   drm/i915: enum port definition is moved into i915_drm.h
>   drm/i915: header for i915 - MEI_HDCP interface
>   drm/i915: MEI interface definition
>   drm: helper functions for hdcp2 seq_num to from u32
>   drm/audio: declaration of struct device
> 
>  Documentation/driver-api/component.rst   |  17 +++
>  Documentation/driver-api/device_link.rst |   3 +
>  Documentation/driver-api/index.rst   |   1 +
>  drivers/base/component.c | 206 
> +--
>  drivers/gpu/drm/i915/intel_audio.c   |   4 +-
>  drivers/gpu/drm/i915/intel_display.h |  16 +--
>  include/drm/drm_audio_component.h|   1 +
>  include/drm/drm_hdcp.h   |  18 +++
>  include/drm/i915_component.h |   5 +
>  include/drm/i915_drm.h   |  15 +++
>  include/drm/i915_mei_hdcp_interface.h| 149 ++
>  include/linux/component.h|  76 
>  include/sound/hda_component.h|   5 +-
>  sound/hda/hdac_component.c   |   4 +-
>  sound/hda/hdac_i915.c|   6 +-
>  15 files changed, 493 insertions(+), 33 deletions(-)
>  create mode 100644 Documentation/driver-api/component.rst
>  create mode 100644 include/drm/i915_mei_hdcp_interface.h
> 
> -- 
> 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