[PATCH v2 0/2] Add support for Tianma nt36672a video mode panel

2020-07-21 Thread Sumit Semwal
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support
for the same.
Most of the panel data is taken from downstream panel dts, and is converted to
drm-panel based driver by me.
It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other
dependent patches is here [1]

---
v2: In dt-binding, removed ports node, making port@0 directly under panel@0 
node.
Also updated the panel_on delay to a safer 200ms as needed for latest 
Android.


Sumit Semwal (2):
  dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
  drm: panel: Add tianma nt36672a panel driver

 .../display/panel/tianma,nt36672a.yaml| 104 +++
 MAINTAINERS   |   7 +
 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
 5 files changed, 982 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
 create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c

-- 
2.27.0

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


[PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-21 Thread Sumit Semwal
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.

Signed-off-by: Sumit Semwal 
Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16

---
v2: remove ports node, making port@0 directly under panel@0 node.
---
 .../display/panel/tianma,nt36672a.yaml| 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..cb1799fbbd32
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+  - Sumit Semwal 
+
+description: |
+  The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+  of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: tianma,nt36672a
+
+  reg:
+description: DSI virtual channel of the peripheral
+
+  reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+  can be configured using mux, pinctrl, pinctrl-names (active high)
+
+  vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+  Power IC supply
+
+  vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+  vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+  pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+  pinctrl-0:
+description: Active pinctrls
+
+  pinctrl-1:
+description: Suspend pinctrls
+
+  port@0:
+type: object
+description: DSI input port driven by master DSI
+properties:
+  reg:
+const: 0
+
+required:
+  - reg
+
+required:
+  - compatible
+  - reg
+  - vddi0-supply
+  - vddpos-supply
+  - vddneg-supply
+  - reset-gpios
+  - pinctrl-names
+  - pinctrl-0
+  - pinctrl-1
+  - port@0
+
+unevaluatedProperties: false
+
+examples:
+  - |+
+#include 
+dsi0 {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+  reg = <0>;
+  tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+  };
+};
+  };
+};
+
+...
-- 
2.27.0

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


[PATCH v2 2/2] drm: panel: Add tianma nt36672a panel driver

2020-07-21 Thread Sumit Semwal
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.

Add the drm panel driver for it.

During testing, Benni Steini  helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.

With current AOSP, we need to increase it to 200ms - this seems to be a safe
high value to avoid a white screen occassionally.

Signed-off-by: Sumit Semwal 
Cc: Benni Steini 
Change-Id: Ib822ef12464abcb50d2e539d11b8983be87c31f2

---
v2: increase reset sequence timing to a safe 200ms
---
 MAINTAINERS   |   7 +
 drivers/gpu/drm/panel/Kconfig |  11 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
 4 files changed, 878 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/ste,mcde.txt
 F: drivers/gpu/drm/mcde/
 
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal 
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: 
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
 DRM DRIVER FOR TDFX VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
  Say Y here if you want to enable support for TPO TD043MTEA1 800x480
  4.3" panel (found on the OMAP3 Pandora board).
 
+config DRM_PANEL_TIANMA_FHD_NT36672A
+   tristate "TIANMA NT36672A 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 the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
 config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
panel-sitronix-st7701.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c 
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..0af3a6ff5d55
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_cmd {
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_CMD(...) { \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+   "vddio",
+   "vddpos",
+   "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+   62000,
+   10,
+   10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+   80,
+   100,
+   100
+};
+
+struct panel_desc {
+   const struct drm_display_mode *display_mode;
+   const char *panel_name;
+
+   unsigned int width_mm;
+   unsigned int height_mm;
+
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+
+   const struct panel_cmd *on_cmds_1;
+   const struct panel_cmd *on_cmds_2;
+
+   const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+   const struct panel_desc *desc;
+
+   struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+   struct gpio_desc *reset_gpio;
+
+   struct pinctrl *pinctrl;

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

2020-07-21 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the devicetree tree got a conflict in:

  Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

between commit:

  5a2e9b658cdc ("dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml")

from the drm tree and commit:

  382646090f7f ("dt-bindings: drm/bridge: Replace HTTP links with HTTPS ones")

from the devicetree tree.

I fixed it up (I delete the file and adde the following merge fix
patch) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Wed, 22 Jul 2020 15:47:22 +1000
Subject: [PATCH] fix for "dt-bindings: drm/bridge: Replace HTTP links with 
HTTPS ones"

Signed-off-by: Stephen Rothwell 
---
 .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index be10e8cf31e1..f8622bd0f61e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -11,7 +11,7 @@ maintainers:
 
 description: |
   The Texas Instruments SN65DSI86 bridge takes MIPI DSI in and outputs eDP.
-  
http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+  
https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
 
 properties:
   compatible:
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


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


Re: [PATCH 06/11] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-21 Thread Daniel Vetter
On Tue, Jul 21, 2020 at 4:46 PM Christian König
 wrote:
>
> Am 21.07.20 um 11:24 schrieb dan...@ffwll.ch:
> > On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:
> >> The driver doesn't expose any not-mapable memory resources.
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>   drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
> >>   1 file changed, 4 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> >> b/drivers/gpu/drm/radeon/radeon_ttm.c
> >> index 54af06df865b..b474781a0920 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> >> @@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device 
> >> *bdev, uint32_t type,
> >>  switch (type) {
> >>  case TTM_PL_SYSTEM:
> >>  /* System memory */
> >> -man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> >> +man->flags = 0;
> >>  man->available_caching = TTM_PL_MASK_CACHING;
> >>  man->default_caching = TTM_PL_FLAG_CACHED;
> >>  break;
> >> @@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device 
> >> *bdev, uint32_t type,
> >>  man->func = _bo_manager_func;
> >>  man->available_caching = TTM_PL_MASK_CACHING;
> >>  man->default_caching = TTM_PL_FLAG_CACHED;
> >> -man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> >> +man->flags = 0;
> >>   #if IS_ENABLED(CONFIG_AGP)
> >>  if (rdev->flags & RADEON_IS_AGP) {
> >>  if (!rdev->ddev->agp) {
> >> @@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device 
> >> *bdev, uint32_t type,
> >>(unsigned)type);
> >>  return -EINVAL;
> >>  }
> >> -if (!rdev->ddev->agp->cant_use_aperture)
> >> -man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> > There is a bunch of agp drivers (alpha, ppc, that kind of stuff) with this
> > flag set. And radeon.ko did at least once work on these. And your patch to
> > disable agp only changes the default, it doesn't rip out the code.
>
> The key pint is that the flags for AGP are the same as the one for the
> PCIe path. So no functional change at all :)

I misread the code somehow, I didn't spot the unconditional setting of
FLAG_MAPPABLE for all TTM_PL_TT, irrespective of agp or not, somehow
thought that's another case.

Reviewed-by: Daniel Vetter 

>
> The real handling of cant_use_aperture is in radeon_ttm_io_mem_reserve().
>
> Christian.
>
> >
> > So not sure your assumption here is correct.
> > -Daniel
> >
> >>  man->available_caching = TTM_PL_FLAG_UNCACHED |
> >>   TTM_PL_FLAG_WC;
> >>  man->default_caching = TTM_PL_FLAG_WC;
> >> @@ -103,8 +101,7 @@ static int radeon_init_mem_type(struct ttm_bo_device 
> >> *bdev, uint32_t type,
> >>  case TTM_PL_VRAM:
> >>  /* "On-card" video ram */
> >>  man->func = _bo_manager_func;
> >> -man->flags = TTM_MEMTYPE_FLAG_FIXED |
> >> - TTM_MEMTYPE_FLAG_MAPPABLE;
> >> +man->flags = TTM_MEMTYPE_FLAG_FIXED;
> >>  man->available_caching = TTM_PL_FLAG_UNCACHED | 
> >> TTM_PL_FLAG_WC;
> >>  man->default_caching = TTM_PL_FLAG_WC;
> >>  break;
> >> @@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object 
> >> *bo, bool evict,
> >>
> >>   static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct 
> >> ttm_mem_reg *mem)
> >>   {
> >> -struct ttm_mem_type_manager *man = >man[mem->mem_type];
> >>  struct radeon_device *rdev = radeon_get_rdev(bdev);
> >>
> >>  mem->bus.addr = NULL;
> >> @@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct 
> >> ttm_bo_device *bdev, struct ttm_mem_
> >>  mem->bus.size = mem->num_pages << PAGE_SHIFT;
> >>  mem->bus.base = 0;
> >>  mem->bus.is_iomem = false;
> >> -if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> >> -return -EINVAL;
> >> +
> >>  switch (mem->mem_type) {
> >>  case TTM_PL_SYSTEM:
> >>  /* system memory */
> >> --
> >> 2.17.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>


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


Re: [PATCH v2] io-mapping: Indicate mapping failure

2020-07-21 Thread Daniel Vetter
On Tue, Jul 21, 2020 at 11:24 PM Andrew Morton
 wrote:
>
> On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J" 
>  wrote:
>
> > >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> > >+++ a/include/linux/io-mapping.h
> > >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> > >resource_size_t base,
> > >unsigned long size)
> > > {
> > >+iomap->iomem = ioremap_wc(base, size);
> > >+if (!iomap->iomem)
> > >+return NULL;
> > >+
> >
> > This does make more sense.
> >
> > I am confused by the two follow up emails I just got.
>
> One was your original patch, the other is my suggested alteration.
>
> > Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> > now in the tree.
>
> All is OK.  If my alteration is acceptable (and, preferably, tested!)
> then when the time comes, I'll fold it into the base patch, add a
> note indicating this change and shall then send it to Linus.

Your alternative also matches the other implementation of
io_mapping_init_wc, I was kinda tempted to do that suggestion too just
because of that. But then didn't send out that email.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


linux-next: manual merge of the amdgpu tree with Linus' tree

2020-07-21 Thread Stephen Rothwell
Hi all,

[I can't find a previous email about this, sorry ...]

There is a semantic conflict between Linus' tree and the amdgpu tree
between commit

  d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")

from Linus' tree and commts

  fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
  836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for renoir")

The automted git merge leaves two "case 12" labels.  I have been
reverting commit d7a6634a4cfb since July 3 ... This will need to be
fixed up when the amdgpu tree is next merged into the drm tree, or a back
merge of d7a6634a4cfb could be done into the amdgpu tree and the older
"case 12" label removed in that merge.

-- 
Cheers,
Stephen Rothwell


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


Re: drm/panel: remove return value of function drm_panel_add which always return true.

2020-07-21 Thread Sam Ravnborg
Hi Bernard,
On Tue, Jul 21, 2020 at 08:24:05PM +0800, Bernard wrote:
> 
> Hi:
> 
> The function "int drm_panel_add(struct drm_panel *panel)" always returns 
> true, this return value is meaningless.
> So I am planning to optimize this function to a non-return implementation, 
> "void drm_panel_add(struct drm_panel *panel)".
> 
> In order to achieve this optimization, I need to submit a patch series: 
> First, modify the code of each submodule that depends on the return value of 
> this function;
> And last, replace the declaration in the drm_panel.h file and implementation 
> in the drm_panel.c file;
> 
> Do you mind this optimization?
> Looking forward to your reply and suggestions!

First of all, thanks for reaching out.

And yes, please implement this simplification.

To avoid this ends up in too much small patches then I advise you to
divide it up like this:

- One patch to convert all panel drivers in drm/panel/*
  Or if you think this is too much to handle in one patch then split
  it in a few patches.
  We do not want one patch for each panel driver.
- Then a final patch to remove the return value from drm/drm_panel.c

Patches should be made on top of drm-misc-next.

This will make the number of patches manageable, easier to give good
names and easiest to review.

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #82 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #81)
> I assume this is the change, BTW:
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index d61186ff411d..2b8da2b17a5d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -424,6 +424,8 @@ struct dm_crtc_state {
>  struct dm_atomic_state {
> struct drm_private_state base;
>  
> +   /* This will be overwritten by the freelist pointer during kfree() */
> +   void *padding;
> struct dc_state *context;
>  };

Yeah that's exactly the change I made, save for the comment of course.

I just got around to actually testing it and it appears to still crash.
Either my hypothesis was wrong or I'm doing something wrong here.

Do you have any ideas?

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #81 from Kees Cook (k...@outflux.net) ---
I assume this is the change, BTW:

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index d61186ff411d..2b8da2b17a5d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -424,6 +424,8 @@ struct dm_crtc_state {
 struct dm_atomic_state {
struct drm_private_state base;

+   /* This will be overwritten by the freelist pointer during kfree() */
+   void *padding;
struct dc_state *context;
 };

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #80 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #79)
> I wonder if there's any way to set a watchpoint to see where exactly the
> dm_atomic_state gets filled with garbage data.

mm/slub.c set_freepointer() (via several possible paths through slab_free())
via writes the pointer. What you really want to know is "who called kfree()
before this tried to read from here?". 

> Also, since I'm not too familiar with freelists, do freelist pointers look
> like regular pointers? On a regular pointer on a system with a 48-bit
> virtual address space, regular pointers would be something like
> 0x. I've noticed that the data being inserted never
> followed this format. Is this something valuable to note or is that just
> the nature of freelist pointers?

With CONFIG_SLAB_FREELIST_HARDENED=y the contents will be randomly permuted on
a per-slab basis. Without, they'll look like a "regular" kernel heap pointer
(0x). You maybe have much more exciting failure modes without
CONFIG_SLAB_FREELIST_HARDENED since the pointer will actually be valid. :P

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


Re: pages pinned for BO lifetime and security

2020-07-21 Thread Gurchetan Singh
+Christian who added DMABUF_MOVE_NOTIFY which added the relevant blurb:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46

Currently, the user seems to amdgpu for P2P dma-buf and it seems to plumb
ttm (*move_notify) callback to dma-buf.  We're not sure if it's a security
issue occurring across DRM drivers, or one more specific to the new amdgpu
use case.

On Tue, Jul 21, 2020 at 1:03 PM Chia-I Wu  wrote:

> Hi list,
>
> virtio-gpu is moving in the direction where BO pages are pinned for
> the lifetime for simplicity.  I am wondering if that is considered a
> security issue in general, especially after running into the
> description of the new DMABUF_MOVE_NOTIFY config option.
>
> Most drivers do not have a shrinker, or whether a BO is purgeable is
> entirely controlled by the userspace (madvice).  They can be
> categorized as "a security problem where userspace is able to pin
> unrestricted amounts of memory".  But those drivers are normally found
> on systems without swap.  I don't think the issue applies.
>
> Of the desktop GPU drivers, i915's shrinker certainly supports purging
> to swap.  TTM is a bit hard to follow.  I can't really tell if amdgpu
> or nouveau supports that.  virtio-gpu is more commonly found on
> systems with swaps so I think it should follow the desktop practices?
>
> Truth is, the emulated virtio-gpu device always supports page moves
> with VIRTIO_GPU_CMD_RESOURCE_{ATTACH,DETACH}_BACKING.  It is just that
> the driver does not make use of them.  That makes this less of an
> issue because the driver can be fixed anytime (finger crossed that the
> emulator won't have bugs in these untested paths).  This issue becomes
> more urgent because we are considering adding a new HW command[1]
> where page moves will be disallowed.  We definitely don't want a HW
> command that is inherently insecure, if BO pages pinned for the
> lifetime is considered a security issue on desktops.
>
> [1] VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB
>
> https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/include/uapi/linux/virtio_gpu.h#L396
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4] Revert "drm/amd/display: Expose connector VRR range via debugfs"

2020-07-21 Thread Alex Deucher
On Fri, Jun 26, 2020 at 7:11 PM Manasi Navare  wrote:
>
> From: Bhanuprakash Modem 
>
> v3:
> * Rebase (Manasi)
> v2:
> * Rebase (Manasi)
>
> As both VRR min and max are already part of drm_display_info,
> drm can expose this VRR range for each connector.
>
> Hence this logic should move to core DRM.
>
> This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
>
> Signed-off-by: Bhanuprakash Modem 
> Cc: Nicholas Kazlauskas 
> Cc: Harry Wentland 
> Cc: Alex Deucher 
> Cc: Manasi Navare 
> Cc: AMD gfx 
> Reviewed-by: Nicholas Kazlauskas 

Applied.  Thanks!

Alex

> ---
>  .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 ---
>  1 file changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 1d692f4f42f3..b246354967bc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -820,24 +820,6 @@ static int output_bpc_show(struct seq_file *m, void 
> *data)
> return res;
>  }
>
> -/*
> - * Returns the min and max vrr vfreq through the connector's debugfs file.
> - * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> - */
> -static int vrr_range_show(struct seq_file *m, void *data)
> -{
> -   struct drm_connector *connector = m->private;
> -   struct amdgpu_dm_connector *aconnector = 
> to_amdgpu_dm_connector(connector);
> -
> -   if (connector->status != connector_status_connected)
> -   return -ENODEV;
> -
> -   seq_printf(m, "Min: %u\n", (unsigned int)aconnector->min_vfreq);
> -   seq_printf(m, "Max: %u\n", (unsigned int)aconnector->max_vfreq);
> -
> -   return 0;
> -}
> -
>  #ifdef CONFIG_DRM_AMD_DC_HDCP
>  /*
>   * Returns the HDCP capability of the Display (1.4 for now).
> @@ -1001,7 +983,6 @@ static ssize_t dp_dpcd_data_read(struct file *f, char 
> __user *buf,
>  DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
>  DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
>  DEFINE_SHOW_ATTRIBUTE(output_bpc);
> -DEFINE_SHOW_ATTRIBUTE(vrr_range);
>  #ifdef CONFIG_DRM_AMD_DC_HDCP
>  DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
>  #endif
> @@ -1058,7 +1039,6 @@ static const struct {
> {"link_settings", _link_settings_debugfs_fops},
> {"phy_settings", _phy_settings_debugfs_fop},
> {"test_pattern", _phy_test_pattern_fops},
> -   {"vrr_range", _range_fops},
>  #ifdef CONFIG_DRM_AMD_DC_HDCP
> {"hdcp_sink_capability", _sink_capability_fops},
>  #endif
> --
> 2.19.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Dave Airlie
On Tue, 21 Jul 2020 at 18:47, Thomas Hellström (Intel)
 wrote:
>
>
> On 7/21/20 9:45 AM, Christian König wrote:
> > Am 21.07.20 um 09:41 schrieb Daniel Vetter:
> >> On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
> >> wrote:
> >>> Hi,
> >>>
> >>> On 7/9/20 2:33 PM, Daniel Vetter wrote:
>  Comes up every few years, gets somewhat tedious to discuss, let's
>  write this down once and for all.
> 
>  What I'm not sure about is whether the text should be more explicit in
>  flat out mandating the amdkfd eviction fences for long running compute
>  workloads or workloads where userspace fencing is allowed.
> >>> Although (in my humble opinion) it might be possible to completely
> >>> untangle
> >>> kernel-introduced fences for resource management and dma-fences used
> >>> for
> >>> completion- and dependency tracking and lift a lot of restrictions
> >>> for the
> >>> dma-fences, including prohibiting infinite ones, I think this makes
> >>> sense
> >>> describing the current state.
> >> Yeah I think a future patch needs to type up how we want to make that
> >> happen (for some cross driver consistency) and what needs to be
> >> considered. Some of the necessary parts are already there (with like the
> >> preemption fences amdkfd has as an example), but I think some clear docs
> >> on what's required from both hw, drivers and userspace would be really
> >> good.
> >
> > I'm currently writing that up, but probably still need a few days for
> > this.
>
> Great! I put down some (very) initial thoughts a couple of weeks ago
> building on eviction fences for various hardware complexity levels here:
>
> https://gitlab.freedesktop.org/thomash/docs/-/blob/master/Untangling%20dma-fence%20and%20memory%20allocation.odt

We are seeing HW that has recoverable GPU page faults but only for
compute tasks, and scheduler without semaphores hw for graphics.

So a single driver may have to expose both models to userspace and
also introduces the problem of how to interoperate between the two
models on one card.

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


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Dave Airlie
>
> >> That's also why I'm not positive on the "no hw preemption, only
> >> scheduler" case: You still have a dma_fence for the batch itself,
> >> which means still no userspace controlled synchronization or other
> >> form of indefinite batches allowed. So not getting us any closer to
> >> enabling the compute use cases people want.
>
> What compute use case are you talking about? I'm only aware about the
> wait before signal case from Vulkan, the page fault case and the KFD
> preemption fence case.

So slight aside, but it does appear as if Intel's Level 0 API exposes
some of the same problems as vulkan.

They have fences:
"A fence cannot be shared across processes."

They have events (userspace fences) like Vulkan but specify:
"Signaled from the host, and waited upon from within a device’s command list."

"There are no protections against events causing deadlocks, such as
circular waits scenarios.

These problems are left to the application to avoid."

https://spec.oneapi.com/level-zero/latest/core/PROG.html#synchronization-primitives

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


Re: [PATCH v2] io-mapping: Indicate mapping failure

2020-07-21 Thread Andrew Morton
On Tue, 21 Jul 2020 21:02:44 + "Ruhl, Michael J"  
wrote:

> >--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
> >+++ a/include/linux/io-mapping.h
> >@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
> >resource_size_t base,
> >unsigned long size)
> > {
> >+iomap->iomem = ioremap_wc(base, size);
> >+if (!iomap->iomem)
> >+return NULL;
> >+
> 
> This does make more sense.
> 
> I am confused by the two follow up emails I just got.

One was your original patch, the other is my suggested alteration.

> Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
> now in the tree.

All is OK.  If my alteration is acceptable (and, preferably, tested!)
then when the time comes, I'll fold it into the base patch, add a
note indicating this change and shall then send it to Linus.

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #79 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #78)
> (In reply to mnrzk from comment #76)
> > If my understanding is correct, base would have previously been filled with
> > the freelist pointer (since it's the first 8 bytes). Now since the freelist
> > pointer is being put in the middle (rounded to the nearest sizeof(void*),
> >  or 8 bytes), it's being put in the last 8 bytes of *dm_state
> > (or dm_state->context).
> > 
> > I'll place a void* for padding in the middle of struct dm_atomic_state* and
> > if my hypothesis is correct, the padding will be filled with garbage data
> > instead of context and the bug should be fixed. Of course, there would
> > still be a use-after-free bug in the code which may cause other issues in
> > the future so I wouldn't really consider it a solution.
> 
> Agreed: that should make it disappear again, but as you say, it's just
> kicking the problem down the road since now the failing condition is losing
> a race with kfree()+kmalloc()+new contents.
> 
> And if you want to detect without crashing, you can just zero the padding at
> init time and report when it's non-NULL at workqueue run time... I wonder if
> KASAN can run in a mode where the allocation/freeing tracking happens, but
> without the heavy checking instrumentation? Then when the corruption is
> detected, it could dump a traceback about who did the early kfree()... hmmm.

So far I've been testing it by passing my GPU to my VM via vfio-pci and
attaching kgdb to the guest. To test if the context was invalid, I added
a check to make sure the context pointer wasn't garbage data (by checking
if dc_state was not null and the upper 16 bits were set on dc_state).

I wonder if there's any way to set a watchpoint to see where exactly the
dm_atomic_state gets filled with garbage data.

Also, since I'm not too familiar with freelists, do freelist pointers look
like regular pointers? On a regular pointer on a system with a 48-bit
virtual address space, regular pointers would be something like
0x. I've noticed that the data being inserted never
followed this format. Is this something valuable to note or is that just
the nature of freelist pointers?

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


RE: [PATCH v2] io-mapping: Indicate mapping failure

2020-07-21 Thread Ruhl, Michael J
>-Original Message-
>From: Andrew Morton 
>Sent: Tuesday, July 21, 2020 4:57 PM
>To: Ruhl, Michael J 
>Cc: dri-devel@lists.freedesktop.org; Mike Rapoport ;
>Andy Shevchenko ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH v2] io-mapping: Indicate mapping failure
>
>On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"
> wrote:
>
>> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
>> success, even when the ioremap fails.
>>
>> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
>> callers check for a NULL return on error this is unexpected.
>>
>> During a device probe, where the ioremap failed, a crash can look
>> like this:
>>
>> BUG: unable to handle page fault for address: 0021
>>  #PF: supervisor write access in kernel mode
>>  #PF: error_code(0x0002) - not-present page
>>  Oops: 0002 [#1] PREEMPT SMP
>>  CPU: 0 PID: 177 Comm:
>>  RIP: 0010:fill_page_dma [i915]
>>   gen8_ppgtt_create [i915]
>>   i915_ppgtt_create [i915]
>>   intel_gt_init [i915]
>>   i915_gem_init [i915]
>>   i915_driver_probe [i915]
>>   pci_device_probe
>>   really_probe
>>   driver_probe_device
>>
>> The remap failure occurred much earlier in the probe.  If it had
>> been propagated, the driver would have exited with an error.
>>
>> Return NULL on ioremap failure.
>>
>> ...
>>
>> --- a/include/linux/io-mapping.h
>> +++ b/include/linux/io-mapping.h
>> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>>  iomap->prot = pgprot_noncached(PAGE_KERNEL);
>>  #endif
>>
>> -return iomap;
>> +return iomap->iomem ? iomap : NULL;
>>  }
>>
>>  static inline void
>
>LGTM.  However I do think it would be stylistically better/typical to
>detect and handle the error early, rather than to blunder on,
>pointlessly initializing things?

Yeah, I pondered that, and then didn't do it...

>--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
>+++ a/include/linux/io-mapping.h
>@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
>  resource_size_t base,
>  unsigned long size)
> {
>+  iomap->iomem = ioremap_wc(base, size);
>+  if (!iomap->iomem)
>+  return NULL;
>+

This does make more sense.

I am confused by the two follow up emails I just got.

Shall I resubmit, or is this path (if !iomap->iomem) return NULL)
now in the tree. 

Thanks,

Mike

>   iomap->base = base;
>   iomap->size = size;
>-  iomap->iomem = ioremap_wc(base, size);
> #if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
>   iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
> #elif defined(pgprot_writecombine)
>@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
>   iomap->prot = pgprot_noncached(PAGE_KERNEL);
> #endif
>
>-  return iomap->iomem ? iomap : NULL;
>+  return iomap;
> }
>
> static inline void
>_

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #78 from Kees Cook (k...@outflux.net) ---
(In reply to mnrzk from comment #76)
> If my understanding is correct, base would have previously been filled with
> the freelist pointer (since it's the first 8 bytes). Now since the freelist
> pointer is being put in the middle (rounded to the nearest sizeof(void*),
>  or 8 bytes), it's being put in the last 8 bytes of *dm_state
> (or dm_state->context).
> 
> I'll place a void* for padding in the middle of struct dm_atomic_state* and
> if my hypothesis is correct, the padding will be filled with garbage data
> instead of context and the bug should be fixed. Of course, there would
> still be a use-after-free bug in the code which may cause other issues in
> the future so I wouldn't really consider it a solution.

Agreed: that should make it disappear again, but as you say, it's just kicking
the problem down the road since now the failing condition is losing a race with
kfree()+kmalloc()+new contents.

And if you want to detect without crashing, you can just zero the padding at
init time and report when it's non-NULL at workqueue run time... I wonder if
KASAN can run in a mode where the allocation/freeing tracking happens, but
without the heavy checking instrumentation? Then when the corruption is
detected, it could dump a traceback about who did the early kfree()... hmmm.

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


Re: [PATCH v2] io-mapping: Indicate mapping failure

2020-07-21 Thread Andrew Morton
On Tue, 21 Jul 2020 13:19:36 -0400 "Michael J. Ruhl"  
wrote:

> The !ATOMIC_IOMAP version of io_maping_init_wc will always return
> success, even when the ioremap fails.
> 
> Since the ATOMIC_IOMAP version returns NULL when the init fails, and
> callers check for a NULL return on error this is unexpected.
> 
> During a device probe, where the ioremap failed, a crash can look
> like this:
> 
> BUG: unable to handle page fault for address: 0021
>  #PF: supervisor write access in kernel mode
>  #PF: error_code(0x0002) - not-present page
>  Oops: 0002 [#1] PREEMPT SMP
>  CPU: 0 PID: 177 Comm:
>  RIP: 0010:fill_page_dma [i915]
>   gen8_ppgtt_create [i915]
>   i915_ppgtt_create [i915]
>   intel_gt_init [i915]
>   i915_gem_init [i915]
>   i915_driver_probe [i915]
>   pci_device_probe
>   really_probe
>   driver_probe_device
> 
> The remap failure occurred much earlier in the probe.  If it had
> been propagated, the driver would have exited with an error.
> 
> Return NULL on ioremap failure.
>
> ...
>
> --- a/include/linux/io-mapping.h
> +++ b/include/linux/io-mapping.h
> @@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
>   iomap->prot = pgprot_noncached(PAGE_KERNEL);
>  #endif
>  
> - return iomap;
> + return iomap->iomem ? iomap : NULL;
>  }
>  
>  static inline void

LGTM.  However I do think it would be stylistically better/typical to
detect and handle the error early, rather than to blunder on,
pointlessly initializing things?

--- a/include/linux/io-mapping.h~io-mapping-indicate-mapping-failure-fix
+++ a/include/linux/io-mapping.h
@@ -107,9 +107,12 @@ io_mapping_init_wc(struct io_mapping *io
   resource_size_t base,
   unsigned long size)
 {
+   iomap->iomem = ioremap_wc(base, size);
+   if (!iomap->iomem)
+   return NULL;
+
iomap->base = base;
iomap->size = size;
-   iomap->iomem = ioremap_wc(base, size);
 #if defined(pgprot_noncached_wc) /* archs can't agree on a name ... */
iomap->prot = pgprot_noncached_wc(PAGE_KERNEL);
 #elif defined(pgprot_writecombine)
@@ -118,7 +121,7 @@ io_mapping_init_wc(struct io_mapping *io
iomap->prot = pgprot_noncached(PAGE_KERNEL);
 #endif
 
-   return iomap->iomem ? iomap : NULL;
+   return iomap;
 }
 
 static inline void
_

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #77 from Kees Cook (k...@outflux.net) ---
(Midair collision... you saw the same about the structure layout as I did.
Here's my comment...)

(In reply to mnrzk from comment #30)
> I've been looking at this bug for a while now and I'll try to share what
> I've found about it.
> 
> In some conditions, when amdgpu_dm_atomic_commit_tail calls
> dm_atomic_get_new_state, dm_atomic_get_new_state returns a struct
> dm_atomic_state* with an garbage context pointer.

It looks like when amdgpu_dm_atomic_commit_tail() walks the private objects
list with for_each_new_private_obj_in_state(), it'll return the first object's
state when the function pointer tables match. This is a struct dm_atomic_state
allocation, which is 16 bytes:

struct drm_private_state {
struct drm_atomic_state *state;
};

struct dm_atomic_state {
struct drm_private_state base;
struct dc_state *context;
};

If struct dm_atomic_state is being freed early, this would match the behavior
seen: before 3202fa62f, .base.state would be overwritten with a freelist
pointer. After 3202fa62f, .context will be overwritten.

In looking for all "kfree(.*state" patterns in
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c, I see a few suspicious
things, maybe. dm_crtc_destroy_state() and amdgpu_dm_connector_funcs_reset() do
an explicit kfree(state) -- should they use dm_atomic_destroy_state() instead?
Or nothing at all, since I'd expect "state" to be managed by the drm layer via
the .atomic_destroy_state callback?


> I've also found that this bug exclusively occurs when commit_work is on the
> workqueue. After forcing drm_atomic_helper_commit to run all of the commits
> without adding to the workqueue and running the OS, the issue seems to have
> disappeared. The system was stable for at least 1.5 hours before I manually
> shut it down (meanwhile it has usually crashed within 30-45 minutes).

Is this the async call to "commit_work" in drm_atomic_helper_commit()?

There's a big warning in there:

/*
 * Everything below can be run asynchronously without the need to grab
 * any modeset locks at all under one condition: It must be guaranteed
 * that the asynchronous work has either been cancelled (if the driver
 * supports it, which at least requires that the framebuffers get
 * cleaned up with drm_atomic_helper_cleanup_planes()) or completed
 * before the new state gets committed on the software side with
 * drm_atomic_helper_swap_state().
 ...

I'm not sure how to determine if amdgpu_dm.c is doing this correctly?

I can't tell what can interfere with drm_atomic_helper_commit() -- I would
guess the race is between that and something else causing a kfree(), but I
don't know the APIs here at all...

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


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #76 from mn...@protonmail.com ---
(In reply to Kees Cook from comment #75)
> Hi!
> 
> First, let me say sorry for all the work my patch has caused! It seems like
> it might be tickling another (previously dormant) bug in the gpu driver.
> 
> 
> (In reply to mnrzk from comment #30)
> > I've been looking at this bug for a while now and I'll try to share what
> > I've found about it.
> > 
> > In some conditions, when amdgpu_dm_atomic_commit_tail calls
> > dm_atomic_get_new_state, dm_atomic_get_new_state returns a struct
> > dm_atomic_state* with an garbage context pointer.
> > 
> > I've also found that this bug exclusively occurs when commit_work is on the
> > workqueue. After forcing drm_atomic_helper_commit to run all of the commits
> > without adding to the workqueue and running the OS, the issue seems to have
> > disappeared. The system was stable for at least 1.5 hours before I manually
> > shut it down (meanwhile it has usually crashed within 30-45 minutes).
> > 
> > Perhaps there's some sort of race condition occurring after commit_work is
> > queued?
> 
> If it helps to explain what's happening in 3202fa62f, the kernel memory
> allocator is moving it's free pointer from offset 0 to the middle of the
> object. That means that when the memory is freed, it writes 8 bytes to join
> the newly freed memory into the allocator's freelist. That always happened,
> but after 3202fa62f it began writing it in the middle, not offset 0. If the
> work queue is trying to use freed memory, and before it didn't notice the
> first 8 bytes getting written, now it appears to notice the overwrite... but
> that still means something is freeing memory before it should.
> 
> Finding that might be a real trick. :( However, if you've suffered through
> all those bisections, I wonder if you can try one other thing, which is to
> compile the kernel with KASAN:
> 
> CONFIG_KASAN=y
> CONFIG_KASAN_GENERIC=y
> CONFIG_KASAN_OUTLINE=y
> CONFIG_KASAN_STACK=y
> CONFIG_KASAN_VMALLOC=y
> 
> This will make things _slow_, which might mean the use-after-free race may
> never trigger. *However* it's possible that it'll catch a bad behavior
> before it even needs to get hit in a race that triggers the behavior you're
> seeing. (And note that swapping CONFIG_KASAN_OUTLINE=y for
> CONFIG_KASAN_INLINE=y might speed things up, but the kernel image gets
> bigger).
> 
> I'm going to try to read the work queue code for the driver and see if
> anything obvious stands out...

Actually this makes perfect sense, struct dm_atomic_state* dm_state has
two components, base (a struct containing a struct drm_atomic_state*) and
context (a struct dc_state*). Reading through the code of
amdgpu_dm_atomic_commit_tail, I see that dm_state->base is never used.

If my understanding is correct, base would have previously been filled with
the freelist pointer (since it's the first 8 bytes). Now since the freelist
pointer is being put in the middle (rounded to the nearest sizeof(void*),
 or 8 bytes), it's being put in the last 8 bytes of *dm_state
(or dm_state->context).

I'll place a void* for padding in the middle of struct dm_atomic_state* and
if my hypothesis is correct, the padding will be filled with garbage data
instead of context and the bug should be fixed. Of course, there would
still be a use-after-free bug in the code which may cause other issues in
the future so I wouldn't really consider it a solution.

Regarding KASAN, I've tried compiling the kernel with KASAN enabled and
from my experience, the bug did not trigger after actively using the system
for 3 hours and leaving it on for 12 hours. This was almost a month ago
though so maybe I'll try again with different KASAN options (i.e.
CONFIG_KASAN_INLINE=y). If anyone has any more tips on getting KASAN to run
faster, I'll be glad to hear them.

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


[radeon-alex:amd-staging-drm-next 1133/1153] drivers/gpu/drm/amd/amdgpu/navi10_ih.c:64:2: warning: ISO C90 forbids mixed declarations and code

2020-07-21 Thread kernel test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   7173949df4548299ee6c63736f76247d3f288cd4
commit: f6668a70defec83ec0c837e052dd5490b66068d3 [1133/1153] drm/amdgpu: add 
timeout flush mechanism to update wptr for self interrupt
config: alpha-allmodconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f6668a70defec83ec0c837e052dd5490b66068d3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/navi10_ih.c: In function 
'force_update_wptr_for_self_int':
>> drivers/gpu/drm/amd/amdgpu/navi10_ih.c:64:2: warning: ISO C90 forbids mixed 
>> declarations and code [-Wdeclaration-after-statement]
  64 |  u32 ih_cntl = RREG32_SOC15(OSSSYS, 0, mmIH_CNTL2);
 |  ^~~
   In file included from drivers/gpu/drm/amd/amdgpu/navi10_ih.c:26:
   At top level:
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:192:19: warning: 'debug_evictions' 
defined but not used [-Wunused-const-variable=]
 192 | static const bool debug_evictions; /* = false */
 |   ^~~
   drivers/gpu/drm/amd/amdgpu/amdgpu.h:191:18: warning: 'sched_policy' defined 
but not used [-Wunused-const-variable=]
 191 | static const int sched_policy = KFD_SCHED_POLICY_HWS;
 |  ^~~~
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:33,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30,
from 
drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:65,
from drivers/gpu/drm/amd/amdgpu/navi10_ih.c:26:
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:76:32: warning: 
'dc_fixpt_ln2_div_2' defined but not used [-Wunused-const-variable=]
  76 | static const struct fixed31_32 dc_fixpt_ln2_div_2 = { 1488522236LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:75:32: warning: 
'dc_fixpt_ln2' defined but not used [-Wunused-const-variable=]
  75 | static const struct fixed31_32 dc_fixpt_ln2 = { 2977044471LL };
 |^~~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:74:32: warning: 
'dc_fixpt_e' defined but not used [-Wunused-const-variable=]
  74 | static const struct fixed31_32 dc_fixpt_e = { 11674931555LL };
 |^~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:73:32: warning: 
'dc_fixpt_two_pi' defined but not used [-Wunused-const-variable=]
  73 | static const struct fixed31_32 dc_fixpt_two_pi = { 26986075409LL };
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:72:32: warning: 
'dc_fixpt_pi' defined but not used [-Wunused-const-variable=]
  72 | static const struct fixed31_32 dc_fixpt_pi = { 13493037705LL };
 |^~~
   drivers/gpu/drm/amd/amdgpu/../display/include/fixed31_32.h:67:32: warning: 
'dc_fixpt_zero' defined but not used [-Wunused-const-variable=]
  67 | static const struct fixed31_32 dc_fixpt_zero = { 0 };
 |^

vim +64 drivers/gpu/drm/amd/amdgpu/navi10_ih.c

41  
42  /**
43   * force_update_wptr_for_self_int - Force update the wptr for self 
interrupt
44   *
45   * @adev: amdgpu_device pointer
46   * @threshold: threshold to trigger the wptr reporting
47   * @timeout: timeout to trigger the wptr reporting
48   * @enabled: Enable/disable timeout flush mechanism
49   *
50   * threshold input range: 0 ~ 15, default 0,
51   * real_threshold = 2^threshold
52   * timeout input range: 0 ~ 20, default 8,
53   * real_timeout = (2^timeout) * 1024 / (socclk_freq)
54   *
55   * Force update wptr for self interrupt ( >= SIENNA_CICHLID).
56   */
57  static void
58  force_update_wptr_for_self_int(struct amdgpu_device *adev,
59 u32 threshold, u32 timeout, bool enabled)
60  {
61  if (adev->asic_type < CHIP_SIENNA_CICHLID)
62  return;
63  
  > 64  u32 ih_cntl = RREG32_SOC15(OSSSYS, 0, mmIH_CNTL2);
65  u32 ih_rb_cntl = RREG32_SOC15(OSSSYS, 0, mmIH_RB_CNTL_RING1);
66  
67  ih_cntl = REG_SET_FIELD(ih_cntl, IH_CNTL2,
68  

pages pinned for BO lifetime and security

2020-07-21 Thread Chia-I Wu
Hi list,

virtio-gpu is moving in the direction where BO pages are pinned for
the lifetime for simplicity.  I am wondering if that is considered a
security issue in general, especially after running into the
description of the new DMABUF_MOVE_NOTIFY config option.

Most drivers do not have a shrinker, or whether a BO is purgeable is
entirely controlled by the userspace (madvice).  They can be
categorized as "a security problem where userspace is able to pin
unrestricted amounts of memory".  But those drivers are normally found
on systems without swap.  I don't think the issue applies.

Of the desktop GPU drivers, i915's shrinker certainly supports purging
to swap.  TTM is a bit hard to follow.  I can't really tell if amdgpu
or nouveau supports that.  virtio-gpu is more commonly found on
systems with swaps so I think it should follow the desktop practices?

Truth is, the emulated virtio-gpu device always supports page moves
with VIRTIO_GPU_CMD_RESOURCE_{ATTACH,DETACH}_BACKING.  It is just that
the driver does not make use of them.  That makes this less of an
issue because the driver can be fixed anytime (finger crossed that the
emulator won't have bugs in these untested paths).  This issue becomes
more urgent because we are considering adding a new HW command[1]
where page moves will be disallowed.  We definitely don't want a HW
command that is inherently insecure, if BO pages pinned for the
lifetime is considered a security issue on desktops.

[1] VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB
https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/include/uapi/linux/virtio_gpu.h#L396
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #75 from Kees Cook (k...@outflux.net) ---
Hi!

First, let me say sorry for all the work my patch has caused! It seems like it
might be tickling another (previously dormant) bug in the gpu driver.


(In reply to mnrzk from comment #30)
> I've been looking at this bug for a while now and I'll try to share what
> I've found about it.
> 
> In some conditions, when amdgpu_dm_atomic_commit_tail calls
> dm_atomic_get_new_state, dm_atomic_get_new_state returns a struct
> dm_atomic_state* with an garbage context pointer.
> 
> I've also found that this bug exclusively occurs when commit_work is on the
> workqueue. After forcing drm_atomic_helper_commit to run all of the commits
> without adding to the workqueue and running the OS, the issue seems to have
> disappeared. The system was stable for at least 1.5 hours before I manually
> shut it down (meanwhile it has usually crashed within 30-45 minutes).
> 
> Perhaps there's some sort of race condition occurring after commit_work is
> queued?

If it helps to explain what's happening in 3202fa62f, the kernel memory
allocator is moving it's free pointer from offset 0 to the middle of the
object. That means that when the memory is freed, it writes 8 bytes to join the
newly freed memory into the allocator's freelist. That always happened, but
after 3202fa62f it began writing it in the middle, not offset 0. If the work
queue is trying to use freed memory, and before it didn't notice the first 8
bytes getting written, now it appears to notice the overwrite... but that still
means something is freeing memory before it should.

Finding that might be a real trick. :( However, if you've suffered through all
those bisections, I wonder if you can try one other thing, which is to compile
the kernel with KASAN:

CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_OUTLINE=y
CONFIG_KASAN_STACK=y
CONFIG_KASAN_VMALLOC=y

This will make things _slow_, which might mean the use-after-free race may
never trigger. *However* it's possible that it'll catch a bad behavior before
it even needs to get hit in a race that triggers the behavior you're seeing.
(And note that swapping CONFIG_KASAN_OUTLINE=y for CONFIG_KASAN_INLINE=y might
speed things up, but the kernel image gets bigger).

I'm going to try to read the work queue code for the driver and see if anything
obvious stands out...

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


Re: [PATCH 1/2] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-07-21 Thread Manasi Navare
On Mon, Jul 20, 2020 at 05:40:10PM -0700, Almahallawy, Khaled wrote:
> On Mon, 2020-07-20 at 17:07 -0700, Manasi Navare wrote:
> > On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote:
> > > Add the missing CP2520 pattern 2 and 3 phy compliance patterns
> > >
> > > Signed-off-by: Khaled Almahallawy 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > >  include/drm/drm_dp_helper.h | 4 +++-
> > >  2 files changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index a3c82e726057..d0fb78c6aca6 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct
> > > drm_dp_aux *aux,
> > >  return err;
> > >
> > >  break;
> > > -case DP_PHY_TEST_PATTERN_CP2520:
> > > +case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > >  err = drm_dp_dpcd_read(aux,
> > > DP_TEST_HBR2_SCRAMBLER_RESET,
> > > >hbr2_reset,
> > > sizeof(data->hbr2_reset));
> >
> > Where do we read PAT2 and PAT3, I see you defined those newly and
> > patch 2/2 has them
> > in teh switch case but the drm_dp_get_phy_test_pattern function
> > doesnt read them?
> >
> 
> Per my understanding from the specs, only HBR2 (CP2520 PAT1) requires
> reading dpcd address 0024Ah to set HBR2_COMPLIANCT_SCRAMBLER_RESET.
> TPS4 (CP2520 PAT3) doesn’t require that.
> I’m not sure about CP2520 PAT2 if it has use or not. In the test scope
> we can select 6 patterns. PAT2 is not one of them.
> 
> Thanks
> ~Khaled

Okay got it, with that

Reviewed-by: Manasi Navare 

Manasi

> 
> > Manasi
> >
> > > diff --git a/include/drm/drm_dp_helper.h
> > > b/include/drm/drm_dp_helper.h
> > > index e47dc22ebf50..65dd6cd71f1e 100644
> > > --- a/include/drm/drm_dp_helper.h
> > > +++ b/include/drm/drm_dp_helper.h
> > > @@ -708,7 +708,9 @@
> > >  # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
> > >  # define DP_PHY_TEST_PATTERN_PRBS7  0x3
> > >  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
> > > -# define DP_PHY_TEST_PATTERN_CP2520 0x5
> > > +# define DP_PHY_TEST_PATTERN_CP2520_PAT10x5
> > > +# define DP_PHY_TEST_PATTERN_CP2520_PAT20x6
> > > +# define DP_PHY_TEST_PATTERN_CP2520_PAT30x7
> > >
> > >  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
> > >  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
> > > --
> > > 2.17.1
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-07-21 Thread Luben Tuikov
Hi Lucas,

Thank you for following up on this. Some things have slowed down,
given the world pandemic we've been experiencing this year.

I've had the design ready and half of it implemented and committed
into a branch. Just as per what I wrote earlier this year on this thread.

I need to finish the rest which isn't big, but does need
some unravelling of the current code. Then I need testing,
which I suppose a number of people can help, so long as
they can make a frame time out and kick in the timeout handler.

I'll have more details in a few weeks.

Regards,
Luben

On 2020-07-21 9:42 a.m., Andrey Grodzovsky wrote:
> Christian, I would want this very much but unfortunately I am on a strict 
> schedule for an internal project currently and hence will not be able to 
> actively participate. I will do my best to answer any questions Luben might 
> have 
> about current implementation.
> 
> Andrey
> 
> On 7/21/20 9:39 AM, Christian König wrote:
>> Luben had a good idea how to tackle the whole job handling.
>>
>> Andrey/Lucas can you work with Luben to get this cleaned up because there 
>> are 
>> a lot of requirements on this which not only come from AMD.
>>
>> Thanks,
>> Christian.
>>
>> Am 21.07.20 um 15:36 schrieb Andrey Grodzovsky:
>>> Lucas, Luben picked the work on this a few month ago as I was diverted to a 
>>> different project.
>>>
>>> Luben, can you update Lucas please ?
>>>
>>> Andrey
>>>
>>> On 7/21/20 7:03 AM, Lucas Stach wrote:
 It seems we all dropped the ball on this one. I believe this is still
 an open issue. Has there been any progress from your side on fixing
 this?

 Regards,
 Lucas
>>

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


Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

2020-07-21 Thread Lyude Paul
On Tue, 2020-07-21 at 12:00 -0400, Lyude Paul wrote:
> On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > > Sure thing. Also, feel free to let me know if you'd like access to one
> > > of
> > > the
> > > systems we saw breaking with this patch - I'm fairly sure I've got one
> > > of
> > > them
> > > locally at my apartment and don't mind setting up AMT/KVM/SSH
> > 
> > Probably no need for remote access (thanks for the offer, though). I
> > attached a test patch to the bug report:
> > 
> >   https://bugzilla.kernel.org/show_bug.cgi?id=208597
> > 
> > that tries to work it around (based on the ->pm_cap == 0). I wonder if
> > anyone would have time to try it out.
> 
> Will give it a shot today and let you know the result

Ahh-actually, I thought the laptop I had locally could reproduce this bug but
that doesn't appear to be the case whoops. Karol Herbst still has access to a
machine that can test this though, so they'll likely get to trying the patch
today or tommorrow

> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

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


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Daniel Vetter
On Tue, Jul 21, 2020 at 7:46 PM Thomas Hellström (Intel)
 wrote:
>
>
> On 2020-07-21 15:59, Christian König wrote:
> > Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):
> ...
> >> Yes, we can't do magic. As soon as an indefinite batch makes it to
> >> such hardware we've lost. But since we can break out while the batch
> >> is stuck in the scheduler waiting, what I believe we *can* do with
> >> this approach is to avoid deadlocks due to locally unknown
> >> dependencies, which has some bearing on this documentation patch, and
> >> also to allow memory allocation in dma-fence (not memory-fence)
> >> critical sections, like gpu fault- and error handlers without
> >> resorting to using memory pools.
> >
> > Avoiding deadlocks is only the tip of the iceberg here.
> >
> > When you allow the kernel to depend on user space to proceed with some
> > operation there are a lot more things which need consideration.
> >
> > E.g. what happens when an userspace process which has submitted stuff
> > to the kernel is killed? Are the prepared commands send to the
> > hardware or aborted as well? What do we do with other processes
> > waiting for that stuff?
> >
> > How to we do resource accounting? When processes need to block when
> > submitting to the hardware stuff which is not ready we have a process
> > we can punish for blocking resources. But how is kernel memory used
> > for a submission accounted? How do we avoid deny of service attacks
> > here were somebody eats up all memory by doing submissions which can't
> > finish?
> >
> Hmm. Are these problems really unique to user-space controlled
> dependencies? Couldn't you hit the same or similar problems with
> mis-behaving shaders blocking timeline progress?

We just kill them, which we can because stuff needs to complete in a
timely fashion, and without any further intervention - all
prerequisite dependencies must be and are known by the kernel.

But with the long/endless running compute stuff with userspace sync
point and everything free-wheeling, including stuff like "hey I'll
submit this patch but the memory isn't even all allocated yet, so I'm
just going to hang it on this semaphore until that's done" is entirely
different. There just shooting the batch kills the programming model,
and abitrarily holding up a batch for another one to first get its
memory also breaks it, because userspace might have issued them with
dependencies in the other order.

So with that execution model you don't run batches, but just an entire
context. Up to userspace what it does with that, and like with cpu
threads just running a busy loop doing nothing is perfectly legit
(from the kernel pov's at least) workload. Nothing in the kernel ever
waits on such a context to do anything, if the kernel needs something
you just preempt (or if it's memory and you have gpu page fault
handling, rip out the page). Accounting is all done on a specific gpu
context too. And probably we need a somewhat consistent approach on
how we handle these gpu context things (definitely needed for cgroups
and all that).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Intel


On 2020-07-21 15:59, Christian König wrote:

Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):

...
Yes, we can't do magic. As soon as an indefinite batch makes it to 
such hardware we've lost. But since we can break out while the batch 
is stuck in the scheduler waiting, what I believe we *can* do with 
this approach is to avoid deadlocks due to locally unknown 
dependencies, which has some bearing on this documentation patch, and 
also to allow memory allocation in dma-fence (not memory-fence) 
critical sections, like gpu fault- and error handlers without 
resorting to using memory pools.


Avoiding deadlocks is only the tip of the iceberg here.

When you allow the kernel to depend on user space to proceed with some 
operation there are a lot more things which need consideration.


E.g. what happens when an userspace process which has submitted stuff 
to the kernel is killed? Are the prepared commands send to the 
hardware or aborted as well? What do we do with other processes 
waiting for that stuff?


How to we do resource accounting? When processes need to block when 
submitting to the hardware stuff which is not ready we have a process 
we can punish for blocking resources. But how is kernel memory used 
for a submission accounted? How do we avoid deny of service attacks 
here were somebody eats up all memory by doing submissions which can't 
finish?


Hmm. Are these problems really unique to user-space controlled 
dependencies? Couldn't you hit the same or similar problems with 
mis-behaving shaders blocking timeline progress?


/Thomas



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


[PATCH v2] io-mapping: Indicate mapping failure

2020-07-21 Thread Michael J. Ruhl
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.

Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.

During a device probe, where the ioremap failed, a crash can look
like this:

BUG: unable to handle page fault for address: 0021
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 Oops: 0002 [#1] PREEMPT SMP
 CPU: 0 PID: 177 Comm:
 RIP: 0010:fill_page_dma [i915]
  gen8_ppgtt_create [i915]
  i915_ppgtt_create [i915]
  intel_gt_init [i915]
  i915_gem_init [i915]
  i915_driver_probe [i915]
  pci_device_probe
  really_probe
  driver_probe_device

The remap failure occurred much earlier in the probe.  If it had
been propagated, the driver would have exited with an error.

Return NULL on ioremap failure.

Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about 
the io-mapping")
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Andy Shevchenko 
Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Michael J. Ruhl 
---
v2: reflect review comments
---
 include/linux/io-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
 #endif
 
-   return iomap;
+   return iomap->iomem ? iomap : NULL;
 }
 
 static inline void
-- 
2.21.0

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


Re: [PATCH] drm/amd/powerplay: fix a crash when overclocking Vega M

2020-07-21 Thread Alex Deucher
Applied.  Thanks!

Alex

On Fri, Jul 17, 2020 at 8:23 AM Qiu Wenbo  wrote:
>
> Avoid kernel crash when vddci_control is SMU7_VOLTAGE_CONTROL_NONE and
> vddci_voltage_table is empty. It has been tested on Intel Hades Canyon
> (i7-8809G).
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208489
> Fixes: ac7822b0026f ("drm/amd/powerplay: add smumgr support for VEGAM (v2)")
> Signed-off-by: Qiu Wenbo 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> index 3da71a088b92..0ecc18b55ffb 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c
> @@ -644,9 +644,6 @@ static int vegam_get_dependency_volt_by_clk(struct 
> pp_hwmgr *hwmgr,
>
> /* sclk is bigger than max sclk in the dependence table */
> *voltage |= (dep_table->entries[i - 1].vddc * VOLTAGE_SCALE) << 
> VDDC_SHIFT;
> -   vddci = phm_find_closest_vddci(&(data->vddci_voltage_table),
> -   (dep_table->entries[i - 1].vddc -
> -   (uint16_t)VDDC_VDDCI_DELTA));
>
> if (SMU7_VOLTAGE_CONTROL_NONE == data->vddci_control)
> *voltage |= (data->vbios_boot_state.vddci_bootup_value *
> @@ -654,8 +651,13 @@ static int vegam_get_dependency_volt_by_clk(struct 
> pp_hwmgr *hwmgr,
> else if (dep_table->entries[i - 1].vddci)
> *voltage |= (dep_table->entries[i - 1].vddci *
> VOLTAGE_SCALE) << VDDC_SHIFT;
> -   else
> +   else {
> +   vddci = phm_find_closest_vddci(&(data->vddci_voltage_table),
> +   (dep_table->entries[i - 1].vddc -
> +   (uint16_t)VDDC_VDDCI_DELTA));
> +
> *voltage |= (vddci * VOLTAGE_SCALE) << VDDCI_SHIFT;
> +   }
>
> if (SMU7_VOLTAGE_CONTROL_NONE == data->mvdd_control)
> *mvdd = data->vbios_boot_state.mvdd_bootup_value * 
> VOLTAGE_SCALE;
> --
> 2.27.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #74 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
I sent a message to the LKML and amd-gfx list [1], asking Kees and Andrew on
how to proceed.

[1]: https://lkml.org/lkml/2020/7/21/729
 "[Regression] hangs caused by commit 3202fa62fb (slub: relocate freelist
pointer to middle of object)"

-- 
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 34/40] scsi: csiostor: csio_lnode: Demote kerneldoc that fails to meet the criteria

2020-07-21 Thread Lee Jones
This matches some of the other headers in the file.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or member 
'hw' not described in 'csio_lnode_init'
 drivers/scsi/csiostor/csio_lnode.c:2079: warning: Function parameter or member 
'pln' not described in 'csio_lnode_init'

Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: Dan Carpenter 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/csiostor/csio_lnode.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/csiostor/csio_lnode.c 
b/drivers/scsi/csiostor/csio_lnode.c
index 74ff8adc41f77..61cf54208451a 100644
--- a/drivers/scsi/csiostor/csio_lnode.c
+++ b/drivers/scsi/csiostor/csio_lnode.c
@@ -2068,10 +2068,9 @@ csio_ln_exit(struct csio_lnode *ln)
ln->fcfinfo = NULL;
 }
 
-/**
+/*
  * csio_lnode_init - Initialize the members of an lnode.
  * @ln:lnode
- *
  */
 int
 csio_lnode_init(struct csio_lnode *ln, struct csio_hw *hw,
-- 
2.25.1

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


[PATCH 20/40] scsi: lpfc: lpfc_sli: Remove unused variable 'pg_addr'

2020-07-21 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
 drivers/scsi/lpfc/lpfc_sli.c:15810:16: warning: variable ‘pg_addr’ set but not 
used [-Wunused-but-set-variable]
 15810 | unsigned long pg_addr;
 | ^~~

Cc: James Smart 
Cc: Dick Kennedy 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/lpfc/lpfc_sli.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 92fc6527e7ee6..86e5f8c75ba4e 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -15998,9 +15998,9 @@ lpfc_wq_create(struct lpfc_hba *phba, struct lpfc_queue 
*wq,
wq->queue_id, pci_barset, db_offset,
wq->dpp_id, dpp_barset, dpp_offset);
 
+#ifdef CONFIG_X86
/* Enable combined writes for DPP aperture */
pg_addr = (unsigned long)(wq->dpp_regaddr) & PAGE_MASK;
-#ifdef CONFIG_X86
rc = set_memory_wc(pg_addr, 1);
if (rc) {
lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
-- 
2.25.1

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


[PATCH 36/40] scsi: lpfc: lpfc_sli: Ensure variable has the same stipulations as code using it

2020-07-21 Thread Lee Jones
'pg_addr' is only used when CONFIG_X86 is defined.  So only declare it
if CONFIG_X86 is defined.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_sli.c: In function ‘lpfc_wq_create’:
 drivers/scsi/lpfc/lpfc_sli.c:15813:16: warning: unused variable ‘pg_addr’ 
[-Wunused-variable]
 15813 | unsigned long pg_addr;
 | ^~~

Cc: James Smart 
Cc: Dick Kennedy 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/lpfc/lpfc_sli.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index c44eed709d5fc..278ea0d74b4a8 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -15810,8 +15810,10 @@ lpfc_wq_create(struct lpfc_hba *phba, struct 
lpfc_queue *wq,
uint16_t pci_barset;
uint8_t dpp_barset;
uint32_t dpp_offset;
-   unsigned long pg_addr;
uint8_t wq_create_version;
+#ifdef CONFIG_X86
+   unsigned long pg_addr;
+#endif
 
/* sanity check on queue memory */
if (!wq || !cq)
-- 
2.25.1

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


[PATCH 28/40] scsi: lpfc: lpfc_mem: Provide description for lpfc_mem_alloc()'s 'align' param

2020-07-21 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_mem.c:85: warning: Function parameter or member 'align' 
not described in 'lpfc_mem_alloc'

Cc: James Smart 
Cc: Dick Kennedy 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/lpfc/lpfc_mem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/lpfc/lpfc_mem.c b/drivers/scsi/lpfc/lpfc_mem.c
index e8c0066eb4aaf..27ff67e9edae7 100644
--- a/drivers/scsi/lpfc/lpfc_mem.c
+++ b/drivers/scsi/lpfc/lpfc_mem.c
@@ -68,6 +68,7 @@ lpfc_mem_alloc_active_rrq_pool_s4(struct lpfc_hba *phba) {
 /**
  * lpfc_mem_alloc - create and allocate all PCI and memory pools
  * @phba: HBA to allocate pools for
+ * @align: alignment requirement for blocks; must be a power of two
  *
  * Description: Creates and allocates PCI pools lpfc_mbuf_pool,
  * lpfc_hrb_pool.  Creates and allocates kmalloc-backed mempools
-- 
2.25.1

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


[PATCH 23/40] scsi: lpfc: lpfc_sli: Fix-up around 120 documentation issues

2020-07-21 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/scsi/lpfc/lpfc_sli.c:257: warning: Function parameter or member 'mqe' 
not described in 'lpfc_sli4_mq_put'
 drivers/scsi/lpfc/lpfc_sli.c:257: warning: Excess function parameter 'wqe' 
description in 'lpfc_sli4_mq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Function parameter or member 'hq' 
not described in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Function parameter or member 'dq' 
not described in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Function parameter or member 'hrqe' 
not described in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Function parameter or member 'drqe' 
not described in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Excess function parameter 'q' 
description in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:675: warning: Excess function parameter 'wqe' 
description in 'lpfc_sli4_rq_put'
 drivers/scsi/lpfc/lpfc_sli.c:738: warning: Function parameter or member 'hq' 
not described in 'lpfc_sli4_rq_release'
 drivers/scsi/lpfc/lpfc_sli.c:738: warning: Function parameter or member 'dq' 
not described in 'lpfc_sli4_rq_release'
 drivers/scsi/lpfc/lpfc_sli.c:738: warning: Excess function parameter 'q' 
description in 'lpfc_sli4_rq_release'
 drivers/scsi/lpfc/lpfc_sli.c:1021: warning: Function parameter or member 
'xritag' not described in 'lpfc_test_rrq_active'
 drivers/scsi/lpfc/lpfc_sli.c:1132: warning: Function parameter or member 
'piocbq' not described in '__lpfc_sli_get_els_sglq'
 drivers/scsi/lpfc/lpfc_sli.c:1132: warning: Excess function parameter 'piocb' 
description in '__lpfc_sli_get_els_sglq'
 drivers/scsi/lpfc/lpfc_sli.c:1207: warning: Function parameter or member 
'piocbq' not described in '__lpfc_sli_get_nvmet_sglq'
 drivers/scsi/lpfc/lpfc_sli.c:1207: warning: Excess function parameter 'piocb' 
description in '__lpfc_sli_get_nvmet_sglq'
 drivers/scsi/lpfc/lpfc_sli.c:2243: warning: Function parameter or member 
'rb_list' not described in 'lpfc_sli_hbqbuf_get'
 drivers/scsi/lpfc/lpfc_sli.c:2243: warning: Excess function parameter 'phba' 
description in 'lpfc_sli_hbqbuf_get'
 drivers/scsi/lpfc/lpfc_sli.c:2243: warning: Excess function parameter 'hbqno' 
description in 'lpfc_sli_hbqbuf_get'
 drivers/scsi/lpfc/lpfc_sli.c:2262: warning: Function parameter or member 'hrq' 
not described in 'lpfc_sli_rqbuf_get'
 drivers/scsi/lpfc/lpfc_sli.c:2262: warning: Excess function parameter 'hbqno' 
description in 'lpfc_sli_rqbuf_get'
 drivers/scsi/lpfc/lpfc_sli.c:3429: warning: Function parameter or member 't' 
not described in 'lpfc_poll_eratt'
 drivers/scsi/lpfc/lpfc_sli.c:3429: warning: Excess function parameter 'ptr' 
description in 'lpfc_poll_eratt'
 drivers/scsi/lpfc/lpfc_sli.c:4115: warning: Excess function parameter 'pring' 
description in 'lpfc_sli_abort_fcp_rings'
 drivers/scsi/lpfc/lpfc_sli.c:5331: warning: Excess function parameter 'mboxq' 
description in 'lpfc_sli4_read_fcoe_params'
 drivers/scsi/lpfc/lpfc_sli.c:5879: warning: Function parameter or member 
'extnt_cnt' not described in 'lpfc_sli4_cfg_post_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:5879: warning: Function parameter or member 
'type' not described in 'lpfc_sli4_cfg_post_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:5879: warning: Function parameter or member 'emb' 
not described in 'lpfc_sli4_cfg_post_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:5879: warning: Function parameter or member 
'mbox' not described in 'lpfc_sli4_cfg_post_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:6459: warning: Function parameter or member 'pmb' 
not described in 'lpfc_sli4_ras_mbox_cmpl'
 drivers/scsi/lpfc/lpfc_sli.c:6459: warning: Excess function parameter 'pmboxq' 
description in 'lpfc_sli4_ras_mbox_cmpl'
 drivers/scsi/lpfc/lpfc_sli.c:6912: warning: Function parameter or member 
'extnt_cnt' not described in 'lpfc_sli4_get_allocated_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:6912: warning: Excess function parameter 
'extnt_count' description in 'lpfc_sli4_get_allocated_extnts'
 drivers/scsi/lpfc/lpfc_sli.c:7064: warning: Excess function parameter 'pring' 
description in 'lpfc_sli4_repost_sgl_list'
 drivers/scsi/lpfc/lpfc_sli.c:7312: warning: Function parameter or member 
'phba' not described in 'lpfc_init_idle_stat_hb'
 drivers/scsi/lpfc/lpfc_sli.c:8022: warning: Function parameter or member 't' 
not described in 'lpfc_mbox_timeout'
 drivers/scsi/lpfc/lpfc_sli.c:8022: warning: Excess function parameter 'ptr' 
description in 'lpfc_mbox_timeout'
 drivers/scsi/lpfc/lpfc_sli.c:8902: warning: Function parameter or member 
'mboxq' not described in 'lpfc_sli_issue_mbox_s4'
 drivers/scsi/lpfc/lpfc_sli.c:8902: warning: Excess function parameter 'pmbox' 
description in 'lpfc_sli_issue_mbox_s4'
 drivers/scsi/lpfc/lpfc_sli.c:9413: warning: Function parameter or member 
'piocbq' not described in 'lpfc_sli4_bpl2sgl'
 drivers/scsi/lpfc/lpfc_sli.c:9413: warning: Excess function parameter 'piocb' 
description in 'lpfc_sli4_bpl2sgl'
 

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207383

Jeremy Kescher (jer...@kescher.at) changed:

   What|Removed |Added

 CC||jer...@kescher.at

--- Comment #73 from Jeremy Kescher (jer...@kescher.at) ---
Confirming as well that 3202fa62f, cbfc35a48 and 89b83f282 are the commits that
cause this regression.

Tested with 5.7.9, Radeon RX 480.

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


Re: [PATCH for v5.9] dt-bindings: drm/bridge: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, 19 Jul 2020 19:44:57 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  .../devicetree/bindings/display/bridge/ti,sn65dsi86.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [PATCH for v5.9] drm/tilcdc: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, 19 Jul 2020 19:24:38 +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

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


Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.

2020-07-21 Thread Greg Kroah-Hartman
On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote:
> On 2020/07/16 19:00, Daniel Vetter wrote:
> > On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
> >> On 2020/07/16 0:12, Dan Carpenter wrote:
> >>> I've complained about integer overflows in fbdev for a long time...
> >>>
> >>> What I'd like to see is something like the following maybe.  I don't
> >>> know how to get the vc_data in fbmem.c so it doesn't include your checks
> >>> for negative.
> >>
> >> Yes. Like I said "Thus, I consider that we need more sanity/constraints 
> >> checks." at
> >> https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329...@i-love.sakura.ne.jp/
> >>  ,
> >> we want basic checks. That's a task for fbdev people who should be 
> >> familiar with
> >> necessary constraints.
> > 
> > I think the worldwide supply of people who understand fbdev and willing to
> > work on it is roughly 0. So if someone wants to fix this mess properly
> > (which likely means adding tons of over/underflow checks at entry points,
> > since you're never going to catch the driver bugs, there's too many and
> > not enough people who care) they need to fix this themselves.
> 
> But I think we can enforce reasonable constraint which is much stricter than 
> Dan's basic_checks()
> (which used INT_MAX). For example, do we need to accept var->{xres,yres} >= 
> 1048576, for
> "32768 rows or cols" * "32 pixels per character" = 1045876 and vc_do_resize() 
> accepts only
> rows and cols < 32768 ?
> 
> > 
> > Just to avoid confusion here.
> > 
> >> Anyway, my two patches are small and low cost; can we apply these patches 
> >> regardless
> >> of basic checks?
> > 
> > Which two patches where?
> 
> [PATCH v3] vt: Reject zero-sized screen buffer size.
>  from 
> https://lkml.kernel.org/r/20200712111013.11881-1-penguin-ker...@i-love.sakura.ne.jp

This is now in my tree.

> [PATCH v2] fbdev: Detect integer underflow at "struct 
> fbcon_ops"->clear_margins.
>  from 
> https://lkml.kernel.org/r/20200715015102.3814-1-penguin-ker...@i-love.sakura.ne.jp

That should be taken by the fbdev maintainer, but I can take it too if
people want.

thanks,

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


Re: [PATCH for v5.9] ARM: dts: mxs: Replace HTTP links with HTTPS ones

2020-07-21 Thread Rob Herring
On Sun, Jul 19, 2020 at 12:10:08PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  arch/arm/boot/dts/imx23-pinfunc.h | 4 ++--
>  arch/arm/boot/dts/imx28-pinfunc.h | 4 ++--
>  arch/arm/boot/dts/imx53-tx53-x13x.dts | 4 ++--
>  arch/arm/boot/dts/mxs-pinfunc.h   | 4 ++--
>  include/video/imx-ipu-v3.h| 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx23-pinfunc.h 
> b/arch/arm/boot/dts/imx23-pinfunc.h
> index 5c0f32ca3a93..f9d7eb6679de 100644
> --- a/arch/arm/boot/dts/imx23-pinfunc.h
> +++ b/arch/arm/boot/dts/imx23-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html

Replace the license text with SPDX tags instead.

>   */
>  
>  #ifndef __DT_BINDINGS_MX23_PINCTRL_H__
> diff --git a/arch/arm/boot/dts/imx28-pinfunc.h 
> b/arch/arm/boot/dts/imx28-pinfunc.h
> index e11f69ba0fe4..ffd5412b70ae 100644
> --- a/arch/arm/boot/dts/imx28-pinfunc.h
> +++ b/arch/arm/boot/dts/imx28-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  #ifndef __DT_BINDINGS_MX28_PINCTRL_H__
> diff --git a/arch/arm/boot/dts/imx53-tx53-x13x.dts 
> b/arch/arm/boot/dts/imx53-tx53-x13x.dts
> index 6cdf2082c742..a34d98cf6ed4 100644
> --- a/arch/arm/boot/dts/imx53-tx53-x13x.dts
> +++ b/arch/arm/boot/dts/imx53-tx53-x13x.dts
> @@ -41,8 +41,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm/boot/dts/mxs-pinfunc.h b/arch/arm/boot/dts/mxs-pinfunc.h
> index c6da987b20cb..6766292eee30 100644
> --- a/arch/arm/boot/dts/mxs-pinfunc.h
> +++ b/arch/arm/boot/dts/mxs-pinfunc.h
> @@ -7,8 +7,8 @@
>   * License. You may obtain a copy of the GNU General Public License
>   * Version 2 at the following locations:
>   *
> - * http://www.opensource.org/licenses/gpl-license.html
> - * http://www.gnu.org/copyleft/gpl.html
> + * https://www.opensource.org/licenses/gpl-license.html
> + * https://www.gnu.org/copyleft/gpl.html
>   */
>  
>  #ifndef __DT_BINDINGS_MXS_PINCTRL_H__
> diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
> index 06b0b57e996c..749490e3c66e 100644
> --- a/include/video/imx-ipu-v3.h
> +++ b/include/video/imx-ipu-v3.h
> @@ -5,8 +5,8 @@
>   * Public License.  You may obtain a copy of the GNU Lesser General
>   * Public License Version 2.1 or later at the following locations:
>   *
> - * http://www.opensource.org/licenses/lgpl-license.html
> - * http://www.gnu.org/copyleft/lgpl.html
> + * https://www.opensource.org/licenses/lgpl-license.html
> + * https://www.gnu.org/copyleft/lgpl.html
>   */
>  
>  #ifndef __DRM_IPU_H__
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

2020-07-21 Thread Lyude Paul
On Tue, 2020-07-21 at 18:27 +0300, Mika Westerberg wrote:
> On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
> > Sure thing. Also, feel free to let me know if you'd like access to one of
> > the
> > systems we saw breaking with this patch - I'm fairly sure I've got one of
> > them
> > locally at my apartment and don't mind setting up AMT/KVM/SSH
> 
> Probably no need for remote access (thanks for the offer, though). I
> attached a test patch to the bug report:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=208597
> 
> that tries to work it around (based on the ->pm_cap == 0). I wonder if
> anyone would have time to try it out.

Will give it a shot today and let you know the result

> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

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


Re: [PATCH -next] drm/nouveau/kms/nvd9-: Fix file release memory leak

2020-07-21 Thread Lyude Paul
Reviewed-by: Lyude Paul 

Thanks!

On Tue, 2020-07-21 at 15:17 +, Wei Yongjun wrote:
> When using single_open() for opening, single_release() should be
> used instead of seq_release(), otherwise there is a memory leak.
> 
> Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/crc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.c
> b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> index f17fb6d56757..4971a1042415 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/crc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/crc.c
> @@ -706,6 +706,7 @@ static const struct file_operations
> nv50_crc_flip_threshold_fops = {
>   .open = nv50_crc_debugfs_flip_threshold_open,
>   .read = seq_read,
>   .write = nv50_crc_debugfs_flip_threshold_set,
> + .release = single_release,
>  };
>  
>  int nv50_head_crc_late_register(struct nv50_head *head)
> 
> 
> 
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

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


Re: [PATCH 0/2] Fix warnings in display/bridge/nwl-dsi.yaml DT example

2020-07-21 Thread Rob Herring
On Fri, Jul 3, 2020 at 5:47 AM Ondrej Jirman  wrote:
>
> This patchset fixes warnings in the example in display/bridge/nwl-dsi.yaml
> revealed during port of display/panel/rocktech,jh057n00900.yaml to
> yaml.
>
> Please take a look.
>
> thank you and regards,
>   Ondrej Jirman
>
> Ondrej Jirman (2):
>   dt-bindings: display: Fix example in nwl-dsi.yaml
>   dt-binding: display: Allow a single port node on rocktech,jh057n00900

Series applied to drm-misc.

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


[PATCH v1] io-mapping: Indicate mapping failure

2020-07-21 Thread Michael J. Ruhl
The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.

Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.

Return NULL on ioremap failure.

Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about 
the io-mapping"
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Andy Shevchenko 
Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Michael J. Ruhl 
---
 include/linux/io-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
 #endif
 
-   return iomap;
+   return iomap->iomem ? iomap : NULL;
 }
 
 static inline void
-- 
2.21.0

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


io-mapping: Indicate mapping failure

2020-07-21 Thread Michael J. Ruhl
I found this when my system crashed long after the mapping failure.
The expected behavior should have been driver exit.

Since this is almost exclusively used for drm, I am posting to
the dri mailing list.  Should this go to another list as well?

Thanks,

Mike

Cc: Mike Rapoport 
Cc: Andy Shevchenko 


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


[Bug 208647] persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

--- Comment #5 from Jay Foad (jay.f...@gmail.com) ---
Created attachment 290439
  --> https://bugzilla.kernel.org/attachment.cgi?id=290439=edit
output of journalctl -b-5 -k

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


[Bug 208647] persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your full dmesg output and xorg log (if using X).

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


[Bug 208647] persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

Nicolai Hähnle (nhaeh...@gmail.com) changed:

   What|Removed |Added

 CC||nhaeh...@gmail.com

--- Comment #3 from Nicolai Hähnle (nhaeh...@gmail.com) ---
Hi Alex, I asked Jay to report this because (1) the fact that there's a fault
during boot is suspicious and points in the direction of this being the
kernel's fault and (2) the fact that it's an *mmhub* fault is even more
suspicious.

Certainly this seems to happen without Mesa video encode/decode activity, so it
can't really be Mesa's (or any graphics driver's) fault.

Someone suggested that audio support also goes through mmhub and that it may be
related. I have no idea if that's true.

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


[Bug 208647] persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

--- Comment #2 from Jay Foad (jay.f...@gmail.com) ---
Wouldn't there normally be a useful pid in the first line if it came from
userspace?

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


[Bug 208647] persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
This is most likely a userspace issue (e.g., mesa).  The kernel driver is just
the messenger.

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


Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

2020-07-21 Thread Lyude Paul
Sure thing. Also, feel free to let me know if you'd like access to one of the
systems we saw breaking with this patch - I'm fairly sure I've got one of them
locally at my apartment and don't mind setting up AMT/KVM/SSH

On Tue, 2020-07-21 at 15:22 +0300, Mika Westerberg wrote:
> Hi,
> 
> [Sorry for the delay, I was on vacation]
> 
> On Fri, Jul 17, 2020 at 01:32:10PM +0200, Karol Herbst wrote:
> > Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597
> 
> Thanks for reporting.
> 
> I'll check your logs and try to figure if there is something we can do
> to make both nouveau and TBT working at the same time.
> 
> > oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
> > once something breaks.
-- 
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat

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


RE: [PATCH] io-mapping: Indicate mapping failure

2020-07-21 Thread Ruhl, Michael J
>-Original Message-
>From: Andy Shevchenko 
>Sent: Tuesday, July 21, 2020 10:47 AM
>To: Ruhl, Michael J 
>Cc: dri-devel@lists.freedesktop.org; Andrew Morton foundation.org>; Mike Rapoport ; Chris Wilson
>; sta...@vger.kernel.org
>Subject: Re: [PATCH] io-mapping: Indicate mapping failure
>
>On Tue, Jul 21, 2020 at 10:16:41AM -0400, Michael J. Ruhl wrote:
>> Sometimes it is good to know when your mapping failed.
>
>Can you elaborate...

Sure, guess I was too glib. 

Currently  the io_mapping_init_wc (the !ATOMIC_IOMAP version), function will
always return success.

If the setting of the iomem (from ioremap_wc) fails, the only way for the 
caller to know is to check the value of iomap->iomem.

Since all of the callers expect a NULL return on error, and check for a NULL,
I felt this needed a fixes (i.e. unexpected behavior).

>> Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata
>about the io-mapping"
>
>...especially taking into account that Fixes implies regression / bug?

The failure (in my case a crash) is not revealed until the address is accessed
long after the init.

I will update the commit.

Mike

>--
>With Best Regards,
>Andy Shevchenko
>

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


Re: [PATCH -next] backlight: cr_bllcd: Remove unused variable 'intensity'

2020-07-21 Thread Lee Jones
On Tue, 21 Jul 2020, Wei Yongjun wrote:

> Gcc report unused-variable warning as follows:
> 
> drivers/video/backlight/cr_bllcd.c:62:6: warning:
>  unused variable 'intensity' [-Wunused-variable]
>62 |  int intensity = bd->props.brightness;
>   |  ^
> 
> After commit 24d34617c24f ("backlight: cr_bllcd: Introduce
> gpio-backlight semantics"), this variable is never used, this
> commit removing it.
> 
> Fixes: 24d34617c24f ("backlight: cr_bllcd: Introduce gpio-backlight 
> semantics")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/video/backlight/cr_bllcd.c | 1 -
>  1 file changed, 1 deletion(-)

Thanks for the patch, but this has already been fixed.

> diff --git a/drivers/video/backlight/cr_bllcd.c 
> b/drivers/video/backlight/cr_bllcd.c
> index a24d42e1ea3c..4ad0a72531fe 100644
> --- a/drivers/video/backlight/cr_bllcd.c
> +++ b/drivers/video/backlight/cr_bllcd.c
> @@ -59,7 +59,6 @@ struct cr_panel {
>  
>  static int cr_backlight_set_intensity(struct backlight_device *bd)
>  {
> - int intensity = bd->props.brightness;
>   u32 addr = gpio_bar + CRVML_PANEL_PORT;
>   u32 cur = inl(addr);
>  
> 

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 06/11] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-21 Thread Christian König

Am 21.07.20 um 11:24 schrieb dan...@ffwll.ch:

On Tue, Jul 21, 2020 at 09:32:40AM +0200, Christian König wrote:

The driver doesn't expose any not-mapable memory resources.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
  1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 54af06df865b..b474781a0920 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->func = _bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;
  #if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
@@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
  (unsigned)type);
return -EINVAL;
}
-   if (!rdev->ddev->agp->cant_use_aperture)
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;

There is a bunch of agp drivers (alpha, ppc, that kind of stuff) with this
flag set. And radeon.ko did at least once work on these. And your patch to
disable agp only changes the default, it doesn't rip out the code.


The key pint is that the flags for AGP are the same as the one for the 
PCIe path. So no functional change at all :)


The real handling of cant_use_aperture is in radeon_ttm_io_mem_reserve().

Christian.



So not sure your assumption here is correct.
-Daniel


man->available_caching = TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -103,8 +101,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
  
  static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)

  {
-   struct ttm_mem_type_manager *man = >man[mem->mem_type];
struct radeon_device *rdev = radeon_get_rdev(bdev);
  
  	mem->bus.addr = NULL;

@@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device 
*bdev, struct ttm_mem_
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
-   if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1

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


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


[Bug 208647] New: persistent amdgpu: [mmhub] page faults

2020-07-21 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208647

Bug ID: 208647
   Summary: persistent amdgpu: [mmhub] page faults
   Product: Drivers
   Version: 2.5
Kernel Version: 5.4.0-42-generic
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: jay.f...@gmail.com
Regression: No

Whenever X is running I get persistent page faults like this:

Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu: [mmhub] page fault (src_id:0 ring:169 vmid:0 pasid:0, for process  pid
0 thread  pid 0)
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:   in page starting at address 0xfffb from client 18
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00041F52
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  Faulty UTCL2 client ID: 0xf
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  MORE_FAULTS: 0x0
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  WALKER_ERROR: 0x1
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  PERMISSION_FAULTS: 0x5
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  MAPPING_ERROR: 0x1
Jul 21 15:19:16 jay-X470-AORUS-ULTRA-GAMING kernel: amdgpu :0c:00.0:
amdgpu:  RW: 0x1

Sometimes I get several of these per second. Sometimes there are none for a few
minutes.

If I boot into runlevel 3 (i.e. without starting X) I get one of these during
boot, but then there are no more after that.

I'm running Ubuntu 20.04 but I also saw this on 18.04.

Kernel version is 5.4.0-42-generic but I also saw this with 5.3.0-51-generic.

I'm using the amdgpu-pro drivers.

Graphics card is a Navi 10.

Motherboard is a Gigabyte X470 AORUS ULTRA GAMING.

CPU is an AMD Ryzen 9 3900X.

A very similar sounding bug was reported here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1888116

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


Re: [PATCH 08/11] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-21 Thread Christian König

Am 21.07.20 um 11:28 schrieb dan...@ffwll.ch:

On Tue, Jul 21, 2020 at 09:32:42AM +0200, Christian König wrote:

The driver does support some not-mapable resources, but
those are already handled correctly in the switch/case
statement in the code.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
  1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 44fa8bc49d18..0dd5e802091d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,7 +84,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -93,13 +93,12 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->func = _gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _vram_mgr_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -796,7 +795,6 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
   */
  static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct 
ttm_mem_reg *mem)
  {
-   struct ttm_mem_type_manager *man = >man[mem->mem_type];
struct amdgpu_device *adev = amdgpu_ttm_adev(bdev);
struct drm_mm_node *mm_node = mem->mm_node;
  
@@ -805,8 +803,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_

mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
-   if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;

This check catches the various special on-board memories, or at least I
couldnt' find where mmap for these is disallowed.


See the switch (mem->mem_type) just below, that return -EINVAL as well 
for those.


There is exactly zero functionality change here :)

Christian.


-Daniel


+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1

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


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


Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling

2020-07-21 Thread Rob Clark
On Mon, Jul 20, 2020 at 8:24 PM Viresh Kumar  wrote:
>
> On 20-07-20, 08:03, Rob Clark wrote:
> > On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar  
> > wrote:
> > >
> > > On 15-07-20, 08:36, Rob Clark wrote:
> > > > I can take the first two into msm-next, the 3rd will need to wait
> > > > until dev_pm_opp_set_bw() lands
> > >
> > > You can base that on a8351c12c6c7 in linux-next, I will make sure not to 
> > > rebase
> > > it anymore.
>
> This was 5.8-rc1 + 2 patches for OPP. That's all.
>
> > >
> >
> > I can't really base on something newer than drm-next
>
> But you need the OPP dependency, isn't it ?

With your ack, I can add the patch the dev_pm_opp_set_bw patch to my
tree and merge it via msm-next -> drm-next -> linus

Otherwise I can send a second later pull req that adds the final patch
after has rebased to 5.9-rc1 (by which point the opp next tree will
have presumably been merged

BR,
-R

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


Re: [PATCH v7 2/5] drm/imx: Add initial support for DCSS on iMX8MQ

2020-07-21 Thread Laurentiu Palcu
Hi Philipp,

On Tue, Jul 21, 2020 at 02:43:28PM +0200, Philipp Zabel wrote:
> Hi Laurentiu,
> 
> On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu 
> > 
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities include:
> >  * 4K@60fps;
> >  * HDR10;
> >  * one graphics and 2 video pipelines;
> >  * on-the-fly decompression of compressed video and graphics;
> > 
> > The reference manual can be found here:
> > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> > 
> > The current patch adds only basic functionality: one primary plane for
> > graphics, linear, tiled and super-tiled buffers support (no graphics
> > decompression yet), no HDR10 and no video planes.
> > 
> > Video planes support and HDR10 will be added in subsequent patches once
> > per-plane de-gamma/CSC/gamma support is in.
> > 
> > Signed-off-by: Laurentiu Palcu 
> > Reviewed-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/imx/Kconfig|   2 +
> >  drivers/gpu/drm/imx/Makefile   |   1 +
> >  drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
> >  drivers/gpu/drm/imx/dcss/Makefile  |   6 +
> >  drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  70 +++
> >  drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 219 +++
> >  drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 424 +
> >  drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++
> >  drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++
> >  drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
> >  drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 +
> >  drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 
> >  drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++
> >  drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
> >  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
> >  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
> >  drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
> >  17 files changed, 3962 insertions(+)
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> > 
> > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> > index 207bf7409dfb..6231048aa5aa 100644
> > --- a/drivers/gpu/drm/imx/Kconfig
> > +++ b/drivers/gpu/drm/imx/Kconfig
> > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI
> > depends on DRM_IMX
> > help
> >   Choose this if you want to use HDMI on i.MX6.
> > +
> > +source "drivers/gpu/drm/imx/dcss/Kconfig"
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index 21cdcc2faabc..b644deffe948 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++ b/drivers/gpu/drm/imx/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> >  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> >  
> >  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
> > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig 
> > b/drivers/gpu/drm/imx/dcss/Kconfig
> > new file mode 100644
> > index ..988979bc22cc
> > --- /dev/null
> > +++ b/drivers/gpu/drm/imx/dcss/Kconfig
> > @@ -0,0 +1,9 @@
> > +config DRM_IMX_DCSS
> > +   tristate "i.MX8MQ DCSS"
> > +   select RESET_CONTROLLER
> 
> Why does DCSS select RESET_CONTROLLER?

Why indeed? Apparently, for no reason at all... :/ I must've used SRC at
some point, at the very beginning, though I don't even remember using
it... Hmm, weird. I'll remove it. Thanks for spotting it.

Thanks,
Laurentiu

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


Re: [PATCH] drm/mcde: Fix stability issue

2020-07-21 Thread Sasha Levin
Hi

[This is an automated email]

This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all

The bot has tested the following trees: v5.7.9, v5.4.52, v4.19.133, v4.14.188, 
v4.9.230, v4.4.230.

v5.4.52: Failed to apply! Possible dependencies:
768859c239922 ("drm/mcde: Provide vblank handling unconditionally")
d920e8da3d837 ("drm/mcde: Fix frame sync setup for video mode panels")

v4.19.133: Failed to apply! Possible dependencies:
01648890f336a ("staging: vboxvideo: Embed drm_device into driver structure")
0424d7ba4574b ("staging: vboxvideo: Init fb_info.fix.smem once from 
fbdev_create")
0fdda2ce74e5f ("staging: vboxvideo: Move pin / unpin of fb out of 
vbox_crtc_set_base_and_mode")
131abc56e1bac ("drm/vboxvideo: Move the vboxvideo driver out of staging")
3498ea8b7e3c8 ("staging: vboxvideo: Fold vbox_drm_resume() into 
vbox_pm_resume()")
35f3288c453e2 ("staging: vboxvideo: Atomic phase 1: convert cursor to 
universal plane")
438340aa20975 ("staging: vboxvideo: Atomic phase 3: Switch last bits over 
to atomic")
4f2a8f5898ecd ("drm: Add ASPEED GFX driver")
5cf5332d529bf ("staging: vboxvideo: Restore page-flip support")
5fc537bfd0003 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
685bb884e0a42 ("staging: vboxvideo: Drop duplicate vbox_err.h file")
79815ee23890c ("staging: vboxvideo: Move setup of modesetting from 
driver_load to mode_init")
96bae04347b24 ("staging/vboxvideo: prepare for drmP.h removal from 
drm_modeset_helper.h")
a1d2a6339961e ("drm/lima: driver for ARM Mali4xx GPUs")
a5aca20574693 ("staging: vboxvideo: Fix modeset / page_flip error handling")
acc962c514007 ("staging: vboxvideo: Change licence headers over to SPDX")
cb5eaf187d1d9 ("staging: vboxvideo: Expose creation of universal primary 
plane")
cc0ec5eb721f1 ("staging: vboxvideo: Atomic phase 1: Use drm_plane_helpers 
for primary plane")
cd76c287a52fe ("staging: vboxvideo: Cleanup the comments")
ce8ec32cbd420 ("staging: vboxvideo: Remove vboxfb_create_object() wrapper")
cfc1fc63be447 ("staging: vboxvideo: Move bo_[un]resere calls into 
vbox_bo_[un]pin")
d46709094deb6 ("staging: vboxvideo: Fold driver_load/unload into 
probe/remove functions")
f4d6d90f83147 ("staging: vboxvideo: Add fl_flag argument to vbox_fb_pin() 
helper")

v4.14.188: Failed to apply! Possible dependencies:
01648890f336a ("staging: vboxvideo: Embed drm_device into driver structure")
0424d7ba4574b ("staging: vboxvideo: Init fb_info.fix.smem once from 
fbdev_create")
0fdda2ce74e5f ("staging: vboxvideo: Move pin / unpin of fb out of 
vbox_crtc_set_base_and_mode")
131abc56e1bac ("drm/vboxvideo: Move the vboxvideo driver out of staging")
179c02fe90a41 ("drm/tve200: Add new driver for TVE200")
1daddbc8dec56 ("staging: vboxvideo: Update driver to use drm_dev_register.")
1ebafd1561a05 ("staging: vboxvideo: Fix IRQs no longer working")
2408898e3b6c9 ("staging: vboxvideo: Add page-flip support")
3498ea8b7e3c8 ("staging: vboxvideo: Fold vbox_drm_resume() into 
vbox_pm_resume()")
35f3288c453e2 ("staging: vboxvideo: Atomic phase 1: convert cursor to 
universal plane")
438340aa20975 ("staging: vboxvideo: Atomic phase 3: Switch last bits over 
to atomic")
4f2a8f5898ecd ("drm: Add ASPEED GFX driver")
5b8ea816e8e05 ("drm/tinydrm: add driver for ST7735R panels")
5cf5332d529bf ("staging: vboxvideo: Restore page-flip support")
5fc537bfd0003 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
65aac17423284 ("staging: vboxvideo: Change address of scanout buffer on 
page-flip")
685bb884e0a42 ("staging: vboxvideo: Drop duplicate vbox_err.h file")
6d544fd6f4e15 ("drm/doc: Put all driver docs into a separate chapter")
79815ee23890c ("staging: vboxvideo: Move setup of modesetting from 
driver_load to mode_init")
96bae04347b24 ("staging/vboxvideo: prepare for drmP.h removal from 
drm_modeset_helper.h")
a1d2a6339961e ("drm/lima: driver for ARM Mali4xx GPUs")
a5aca20574693 ("staging: vboxvideo: Fix modeset / page_flip error handling")
acc962c514007 ("staging: vboxvideo: Change licence headers over to SPDX")
ba67f54d911c3 ("staging: vboxvideo: Pass a new framebuffer to 
vbox_crtc_do_set_base")
c575b7eeb89f9 ("drm/xen-front: Add support for Xen PV display frontend")
cb5eaf187d1d9 ("staging: vboxvideo: Expose creation of universal primary 
plane")
cc0ec5eb721f1 ("staging: vboxvideo: Atomic phase 1: Use drm_plane_helpers 
for primary plane")
cd76c287a52fe ("staging: vboxvideo: Cleanup the comments")
ce8ec32cbd420 ("staging: vboxvideo: Remove vboxfb_create_object() wrapper")
cfc1fc63be447 ("staging: vboxvideo: Move bo_[un]resere calls into 
vbox_bo_[un]pin")
d46709094deb6 ("staging: vboxvideo: Fold driver_load/unload into 
probe/remove functions")
f4d6d90f83147 ("staging: vboxvideo: Add fl_flag 

[PATCH] io-mapping: Indicate mapping failure

2020-07-21 Thread Michael J. Ruhl
Sometimes it is good to know when your mapping failed.

Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about 
the io-mapping"
Cc: Andrew Morton 
Cc: Mike Rapoport 
Cc: Andy Shevchenko 
Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Michael J. Ruhl 
---
 include/linux/io-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
 #endif
 
-   return iomap;
+   return iomap->iomem ? iomap : NULL;
 }
 
 static inline void
-- 
2.21.0

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


io-mapping: Indicate mapping failure

2020-07-21 Thread Michael J. Ruhl
I found this when my system crashed long after the mapping failure.
The expected behavior should have been driver exit.

Since this is almost exclusively used for drm, I am posting to
the dri mailing list.  Should this go to another list as well?

Thanks,

Mike



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


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Christian König

Am 21.07.20 um 12:47 schrieb Thomas Hellström (Intel):


On 7/21/20 11:50 AM, Daniel Vetter wrote:

On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
 wrote:


On 7/21/20 10:55 AM, Christian König wrote:

Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):

On 7/21/20 9:45 AM, Christian König wrote:

Am 21.07.20 um 09:41 schrieb Daniel Vetter:

On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
wrote:

Hi,

On 7/9/20 2:33 PM, Daniel Vetter wrote:

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more
explicit in
flat out mandating the amdkfd eviction fences for long running
compute
workloads or workloads where userspace fencing is allowed.

Although (in my humble opinion) it might be possible to completely
untangle
kernel-introduced fences for resource management and dma-fences
used for
completion- and dependency tracking and lift a lot of restrictions
for the
dma-fences, including prohibiting infinite ones, I think this
makes sense
describing the current state.
Yeah I think a future patch needs to type up how we want to make 
that

happen (for some cross driver consistency) and what needs to be
considered. Some of the necessary parts are already there (with
like the
preemption fences amdkfd has as an example), but I think some clear
docs
on what's required from both hw, drivers and userspace would be 
really

good.

I'm currently writing that up, but probably still need a few days
for this.

Great! I put down some (very) initial thoughts a couple of weeks ago
building on eviction fences for various hardware complexity levels 
here:


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fthomash%2Fdocs%2F-%2Fblob%2Fmaster%2FUntangling%2520dma-fence%2520and%2520memory%2520allocation.odtdata=02%7C01%7Cchristian.koenig%40amd.com%7C0af39422c4e744a9303b08d82d637d62%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309252665326201sdata=Zk3LVX7bbMpfAMsq%2Fs2jyA0puRQNcjzliJS%2BC7uDLMo%3Dreserved=0 




I don't think that this will ever be possible.

See that Daniel describes in his text is that indefinite fences are a
bad idea for memory management, and I think that this is a fixed fact.

In other words the whole concept of submitting work to the kernel
which depends on some user space interaction doesn't work and never 
will.

Well the idea here is that memory management will *never* depend on
indefinite fences: As soon as someone waits on a memory manager fence
(be it eviction, shrinker or mmu notifier) it breaks out of any
dma-fence dependencies and /or user-space interaction. The text 
tries to
describe what's required to be able to do that (save for 
non-preemptible

gpus where someone submits a forever-running shader).

Yeah I think that part of your text is good to describe how to
untangle memory fences from synchronization fences given how much the
hw can do.


So while I think this is possible (until someone comes up with a case
where it wouldn't work of course), I guess Daniel has a point in 
that it

won't happen because of inertia and there might be better options.

Yeah it's just I don't see much chance for splitting dma-fence itself.


Well that's the whole idea with the timeline semaphores and waiting for 
a signal number to appear.


E.g. instead of doing the wait with the dma_fence we are separating that 
out into the timeline semaphore object.


This not only avoids the indefinite fence problem for the wait before 
signal case in Vulkan, but also prevents userspace to submit stuff which 
can't be processed immediately.



That's also why I'm not positive on the "no hw preemption, only
scheduler" case: You still have a dma_fence for the batch itself,
which means still no userspace controlled synchronization or other
form of indefinite batches allowed. So not getting us any closer to
enabling the compute use cases people want.


What compute use case are you talking about? I'm only aware about the 
wait before signal case from Vulkan, the page fault case and the KFD 
preemption fence case.




Yes, we can't do magic. As soon as an indefinite batch makes it to 
such hardware we've lost. But since we can break out while the batch 
is stuck in the scheduler waiting, what I believe we *can* do with 
this approach is to avoid deadlocks due to locally unknown 
dependencies, which has some bearing on this documentation patch, and 
also to allow memory allocation in dma-fence (not memory-fence) 
critical sections, like gpu fault- and error handlers without 
resorting to using memory pools.


Avoiding deadlocks is only the tip of the iceberg here.

When you allow the kernel to depend on user space to proceed with some 
operation there are a lot more things which need consideration.


E.g. what happens when an userspace process which has submitted stuff to 
the kernel is killed? Are the prepared commands send to the hardware or 
aborted as 

Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property

2020-07-21 Thread Rob Herring
On Tue, Jul 21, 2020 at 3:23 AM Maxime Ripard  wrote:
>
> On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> > On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai 
> > >
> > > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > > RGB. Many low end ones only support up to 6 bits per channel natively.
> >
> > This should be implied by the panel's compatible property.
>
> I'm not sure it should, or at least it's not sufficient. Some panels
> while 24 bits capable might only have the higher bits connected to save
> off a couple of pins per color, in which case we should probably
> describe that somehow.

That's the bus/interface format which the 2nd paragraph said this was
not for. If it was, then just bits per component is not enough.

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


Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

2020-07-21 Thread Daniel Vetter
On Tue, Jul 21, 2020 at 2:59 PM Melissa Wen  wrote:
>
> Hi all,
>
> I traced the subtests' execution to figure out what happens (or not) in
> a clean run and a blocked run, and this led me to suspect the
> vkms_crtc_atomic_flush function. Examining the code and considering the
> DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
> drm_crtc_vblank_put pair. So I checked it that way, and again, the
> problem of sequential execution + dpms/suspend failures disappeared.
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..f60bf1495306 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -240,30 +240,31 @@ static void vkms_crtc_atomic_flush(struct drm_crtc 
> *crtc,
> spin_lock(>dev->event_lock);
>
> if (drm_crtc_vblank_get(crtc) != 0)
> drm_crtc_send_vblank_event(crtc, crtc->state->event);
> else
> drm_crtc_arm_vblank_event(crtc, crtc->state->event);
>
> spin_unlock(>dev->event_lock);
>
> crtc->state->event = NULL;
> }
>
> vkms_output->composer_state = to_vkms_crtc_state(crtc->state);
>
> spin_unlock_irq(_output->lock);
> +   drm_crtc_vblank_put(crtc);
>  }
>
> However, I'm not sure if it's just another duck-tape proposal or if it
> makes any sense. I'm still investigating better, but I think sharing
> with you may be more productive.

Wow nice find, really great debug work! And checking history, this bug
was there from the beginning. Now I have questions why this never
really blew up before ...

For the patch just a small fix needed, the put needs to be moved into
the if block. Otherwise we call _put() without calling _get(), and
that's also not good. Then just wrap it into a nice patch with the
commit message explaining the entire debug story (i.e. all the
evidence that lead you to this) and we should be good to go.

I'm still not really clear on why this breaks stuff when re-enabling
the crtc ...
-Daniel

> Melissa
>
> On 07/21, Daniel Vetter wrote:
> > On Tue, Jul 21, 2020 at 05:33:00AM +, Sidong Yang wrote:
> > > Hi, Daniel and Melissa
> > >
> > > I tested some code for this problem trying to find the code that make 
> > > problem in igt test.
> > > kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). 
> > > I check each steps
> > > and I found that without cleanup step, the problem solved.
> > > In cleanup step, igt test code seems like this.
> > >
> > > drmModeSetCrtc(display->drm_fd, crtc_id, 0 /* fb_id */, 0,
> > > 0 /* x, y */, NULL /* connector */, 0, NULL /* mode */)
> > >
> > > I commented out this function call and there is no problem in executing 
> > > tests repeatedly.
> > > I'm trying to find out what's happen in this call. but don't know until 
> > > now
> > > I hope this information help to solve the problem.
> >
> > Ah yes that fits the evidence we have from Melissa pretty well: Not
> > turning off the CRTC means the next test wont have to turn it back on
> > again. And the vblank bug seems to be in the code which turns the crtc
> > back on. At least inserting a vblank wait in there is enough to paper over
> > all the issues, per Melissa's testing.
> >
> > So at least we're now fairly confident where the bug is, that's some solid
> > progress.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



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


Re: [PATCH 1/1] video: backlight: cr_bllcd: Remove unused variable 'intensity'

2020-07-21 Thread Daniel Thompson
On Tue, Jul 21, 2020 at 08:39:19AM +0100, Lee Jones wrote:
> Fixes the following kernel build warning:
> 
>  drivers/video/backlight/cr_bllcd.c: In function ‘cr_backlight_set_intensity’:
>  drivers/video/backlight/cr_bllcd.c:62:6: warning: unused variable 
> ‘intensity’ [-Wunused-variable]
>  62 | int intensity = bd->props.brightness;
>  | ^
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Fixes: 24d34617c24f ("backlight: cr_bllcd: Introduce gpio-backlight 
> semantics")
> Signed-off-by: Lee Jones 

I doubt you are awaiting this for a one line fixup... but just in case:

Reviewed-by: Daniel Thompson 


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


Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-07-21 Thread Andrey Grodzovsky
Christian, I would want this very much but unfortunately I am on a strict 
schedule for an internal project currently and hence will not be able to 
actively participate. I will do my best to answer any questions Luben might have 
about current implementation.


Andrey

On 7/21/20 9:39 AM, Christian König wrote:

Luben had a good idea how to tackle the whole job handling.

Andrey/Lucas can you work with Luben to get this cleaned up because there are 
a lot of requirements on this which not only come from AMD.


Thanks,
Christian.

Am 21.07.20 um 15:36 schrieb Andrey Grodzovsky:
Lucas, Luben picked the work on this a few month ago as I was diverted to a 
different project.


Luben, can you update Lucas please ?

Andrey

On 7/21/20 7:03 AM, Lucas Stach wrote:

It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress from your side on fixing
this?

Regards,
Lucas



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


Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-07-21 Thread Christian König

Luben had a good idea how to tackle the whole job handling.

Andrey/Lucas can you work with Luben to get this cleaned up because 
there are a lot of requirements on this which not only come from AMD.


Thanks,
Christian.

Am 21.07.20 um 15:36 schrieb Andrey Grodzovsky:
Lucas, Luben picked the work on this a few month ago as I was diverted 
to a different project.


Luben, can you update Lucas please ?

Andrey

On 7/21/20 7:03 AM, Lucas Stach wrote:

It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress from your side on fixing
this?

Regards,
Lucas


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


Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-07-21 Thread Andrey Grodzovsky
Lucas, Luben picked the work on this a few month ago as I was diverted to a 
different project.


Luben, can you update Lucas please ?

Andrey

On 7/21/20 7:03 AM, Lucas Stach wrote:

It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress from your side on fixing
this?

Regards,
Lucas

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


Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco

2020-07-21 Thread Alexandre Torgue



On 7/21/20 2:55 PM, dillon min wrote:

Hi, Alexandre,


On Tue, Jul 21, 2020 at 7:54 PM Alexandre Torgue
 wrote:




On 7/21/20 12:39 PM, dillon min wrote:

Hi Alexandre,

On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
 wrote:


Hi Dillon

On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:

From: dillon min 

V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on stm32 spi controller.

V5:
1 instead of add send dummy data out under SIMPLEX_RX mode,
  add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
'SPI_3WIRE' mode



Concerning DT patches, they look goods for me. However I'll merge them
when drivers parts will be merged.

regards
Alex

This patchset status is :
dts:
  ARM: dts: stm32: Add dma config for spi5
  ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
  ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
stm32429-disco board

panel-bindings: Reviewed-by: Rob Herring, need more reviewing to merge
  dt-bindings: display: panel: Add ilitek ili9341 panel bindings

clk: Acked-by: Stephen Boyd , need more reviewing to merge
  clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
  turn off by clk_disable_unused()

drm-panel:  Reviewed-by: Linus Walleij . need more reviewing to merge
  drm/panel: Add ilitek ili9341 panel driver

spi-driver: Acked-by: Mark Brown ,merged into mainline
  spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
  spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
becoexit with 'SPI_3WIRE' mode

For ili9341 drivers, it seems to need more time to review, or might be dropped.
since the drm maintainer might create a new interface to support
DPI,DBI,DSI in one driver.
Currently it's under discussion. I will rework the ili9341 driver after that.

But, we can use the existing "drivers/gpu/drm/tiny/ili9341.c" driver to support
ili9341 on stm32f429-disco board only using the spi bus. except the
display refresh performance is not as good as the ltdc interface.

I can submit a new patch just with dts changed this week for it, if you need.




Thanks for this status. I'm close to send my PR for v5.9. There is no
needs to have an intermediate version (Except you absolutely want it).

Thanks
alex

Ok, I prefer to use the ltdc interface to drive ili9341 either.


Ok, so let's wait for the full review of this series.

Cheers
Alex



Thanks,
Dillon.



Thanks,
Dillon.





V4:
According to alexandre torgue's suggestion, combine ili9341 and
l3gd20's modification on stm32f429-disco board to one patchset.

Changes:

ili9341:

1 update ili9341 panel driver according to Linus's suggestion
2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4
3 merge l3gd20's change to this patchset

V3:
1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
 to support serial spi & parallel rgb interface in one driver.
2 update ilitek,ili9341.yaml dts binding documentation.
3 update stm32f429-disco dts binding

V2:
1 verify ilitek,ili9341.yaml with make O=../linux-stm32
 dt_binding_check
 DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/
 ilitek,ili9341.yaml

V1:
1 add ili9341 drm panel driver
2 add ltdc, spi5 controller for stm32f429-disco
3 add ltdc, spi5 pin map for stm32f429-disco
4 add docs about ili9341
5 fix ltdc driver loading hang in clk set rate bug


L3gd20:
V3:
1 merge stm32f429-disco dtbs binding with ili9341 part

V2:
1 insert blank line at stm32f420-disco.dts line 143
2 add more description for l3gd20 in commit message

V1:
1 enable spi5 controller on stm32f429-disco (dts)
2 add spi5 pinmap for stm32f429-disco  (dts)
3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4


dillon min (8):
 ARM: dts: stm32: Add dma config for spi5
 ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
 ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
   stm32429-disco board
 dt-bindings: display: panel: Add ilitek ili9341 panel bindings
 clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
   fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
 turn off by clk_disable_unused()
 drm/panel: Add ilitek ili9341 panel driver
 spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
 spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
   be coexit with 'SPI_3WIRE' mode

.../bindings/display/panel/ilitek,ili9341.yaml |   69 ++
arch/arm/boot/dts/stm32f4-pinctrl.dtsi |   67 +
arch/arm/boot/dts/stm32f429-disco.dts  |   48 +
arch/arm/boot/dts/stm32f429.dtsi   |3 +
drivers/clk/clk-stm32f4.c  |7 +-

Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco

2020-07-21 Thread dillon min
Hi, Alexandre,


On Tue, Jul 21, 2020 at 7:54 PM Alexandre Torgue
 wrote:
>
>
>
> On 7/21/20 12:39 PM, dillon min wrote:
> > Hi Alexandre,
> >
> > On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
> >  wrote:
> >>
> >> Hi Dillon
> >>
> >> On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
> >>> From: dillon min 
> >>>
> >>> V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> >>> for SPI_SIMPLEX_RX mode on stm32 spi controller.
> >>>
> >>> V5:
> >>> 1 instead of add send dummy data out under SIMPLEX_RX mode,
> >>>  add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
> >>> 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
> >>> 'SPI_3WIRE' mode
> >>>
> >>
> >> Concerning DT patches, they look goods for me. However I'll merge them
> >> when drivers parts will be merged.
> >>
> >> regards
> >> Alex
> > This patchset status is :
> > dts:
> >  ARM: dts: stm32: Add dma config for spi5
> >  ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
> >  ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
> >stm32429-disco board
> >
> > panel-bindings: Reviewed-by: Rob Herring, need more reviewing to merge
> >  dt-bindings: display: panel: Add ilitek ili9341 panel bindings
> >
> > clk: Acked-by: Stephen Boyd , need more reviewing to merge
> >  clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
> >fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
> >  turn off by clk_disable_unused()
> >
> > drm-panel:  Reviewed-by: Linus Walleij . need more reviewing to merge
> >  drm/panel: Add ilitek ili9341 panel driver
> >
> > spi-driver: Acked-by: Mark Brown ,merged into mainline
> >  spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
> >  spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
> >becoexit with 'SPI_3WIRE' mode
> >
> > For ili9341 drivers, it seems to need more time to review, or might be 
> > dropped.
> > since the drm maintainer might create a new interface to support
> > DPI,DBI,DSI in one driver.
> > Currently it's under discussion. I will rework the ili9341 driver after 
> > that.
> >
> > But, we can use the existing "drivers/gpu/drm/tiny/ili9341.c" driver to 
> > support
> > ili9341 on stm32f429-disco board only using the spi bus. except the
> > display refresh performance is not as good as the ltdc interface.
> >
> > I can submit a new patch just with dts changed this week for it, if you 
> > need.
> >
>
>
> Thanks for this status. I'm close to send my PR for v5.9. There is no
> needs to have an intermediate version (Except you absolutely want it).
>
> Thanks
> alex
Ok, I prefer to use the ltdc interface to drive ili9341 either.

Thanks,
Dillon.
>
> > Thanks,
> > Dillon.
> >>
> >>
> >>
> >>> V4:
> >>> According to alexandre torgue's suggestion, combine ili9341 and
> >>> l3gd20's modification on stm32f429-disco board to one patchset.
> >>>
> >>> Changes:
> >>>
> >>> ili9341:
> >>>
> >>> 1 update ili9341 panel driver according to Linus's suggestion
> >>> 2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4
> >>> 3 merge l3gd20's change to this patchset
> >>>
> >>> V3:
> >>> 1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
> >>> to support serial spi & parallel rgb interface in one driver.
> >>> 2 update ilitek,ili9341.yaml dts binding documentation.
> >>> 3 update stm32f429-disco dts binding
> >>>
> >>> V2:
> >>> 1 verify ilitek,ili9341.yaml with make O=../linux-stm32
> >>> dt_binding_check
> >>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/
> >>> ilitek,ili9341.yaml
> >>>
> >>> V1:
> >>> 1 add ili9341 drm panel driver
> >>> 2 add ltdc, spi5 controller for stm32f429-disco
> >>> 3 add ltdc, spi5 pin map for stm32f429-disco
> >>> 4 add docs about ili9341
> >>> 5 fix ltdc driver loading hang in clk set rate bug
> >>>
> >>>
> >>> L3gd20:
> >>> V3:
> >>> 1 merge stm32f429-disco dtbs binding with ili9341 part
> >>>
> >>> V2:
> >>> 1 insert blank line at stm32f420-disco.dts line 143
> >>> 2 add more description for l3gd20 in commit message
> >>>
> >>> V1:
> >>> 1 enable spi5 controller on stm32f429-disco (dts)
> >>> 2 add spi5 pinmap for stm32f429-disco  (dts)
> >>> 3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4
> >>>
> >>>
> >>> dillon min (8):
> >>> ARM: dts: stm32: Add dma config for spi5
> >>> ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
> >>> ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
> >>>   stm32429-disco board
> >>> dt-bindings: display: panel: Add ilitek ili9341 panel bindings
> >>> clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
> >>>   fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
> >>> turn off by clk_disable_unused()
> >>> drm/panel: Add ilitek ili9341 panel driver
> >>> spi: stm32: Add 'SPI_SIMPLEX_RX', 

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

2020-07-21 Thread Mika Westerberg
On Fri, Jul 17, 2020 at 09:52:09PM +0200, Lukas Wunner wrote:
> On Fri, Jul 17, 2020 at 03:04:10PM -0400, Lyude Paul wrote:
> > Isn't it possible to tell whether a PCI device is connected through
> > thunderbolt or not? We could probably get away with just defaulting
> > to 100ms for thunderbolt devices without DLL Link Active specified,
> > and then default to the old delay value for non-thunderbolt devices.
> 
> pci_is_thunderbolt_attached()

That only works with some devices. I think we should try to keep the
fact that some PCIe links may be tunneled over TBT/USB4 transparent to
the PCI core and try to treat them as "standard" PCIe links if possible
at all :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm/panel: remove return value of function drm_panel_add which always return true.

2020-07-21 Thread Bernard


Hi:

The function "int drm_panel_add(struct drm_panel *panel)" always returns true, 
this return value is meaningless.
So I am planning to optimize this function to a non-return implementation, 
"void drm_panel_add(struct drm_panel *panel)".

In order to achieve this optimization, I need to submit a patch series: 
First, modify the code of each submodule that depends on the return value of 
this function;
And last, replace the declaration in the drm_panel.h file and implementation in 
the drm_panel.c file;

Do you mind this optimization?
Looking forward to your reply and suggestions!

BR//Bernard





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


Re: [Freedreno] [PATCH] drm/msm/dpu: fix/enable 6bpc dither with split-lm

2020-07-21 Thread kalyan_t

On 2020-07-20 20:53, Rob Clark wrote:

On Mon, Jul 20, 2020 at 5:53 AM  wrote:


On 2020-07-16 03:49, Rob Clark wrote:
> From: Rob Clark 
>
> If split-lm is used (for ex, on sdm845), we can have multiple ping-
> pongs, but only a single phys encoder.  We need to configure dithering
> on each of them.
>
> Signed-off-by: Rob Clark 

 Reviewed-by: Kalyan Thota 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 22 ++-
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   |  3 +--
>  2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 46df0ff75b85..9b98b63c77fb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -212,14 +212,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
>   15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
>  };
>
> -static void _dpu_encoder_setup_dither(struct dpu_encoder_phys *phys)
> +static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp,
> unsigned bpc)
>  {
>   struct dpu_hw_dither_cfg dither_cfg = { 0 };
>
> - if (!phys->hw_pp || !phys->hw_pp->ops.setup_dither)
> + if (!hw_pp->ops.setup_dither)
>   return;
>
> - switch (phys->connector->display_info.bpc) {
> + switch (bpc) {
>   case 6:
>   dither_cfg.c0_bitdepth = 6;
>   dither_cfg.c1_bitdepth = 6;
> @@ -228,14 +228,14 @@ static void _dpu_encoder_setup_dither(struct
> dpu_encoder_phys *phys)
>   dither_cfg.temporal_en = 0;
>   break;
>   default:
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, NULL);
> + hw_pp->ops.setup_dither(hw_pp, NULL);
>   return;
>   }
>
>   memcpy(_cfg.matrix, dither_matrix,
>   sizeof(u32) * DITHER_MATRIX_SZ);
>
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, _cfg);
> + hw_pp->ops.setup_dither(hw_pp, _cfg);
>  }
>
>  void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys
> *phys_enc,
> @@ -1132,11 +1132,13 @@ static void
> _dpu_encoder_virt_enable_helper(struct drm_encoder *drm_enc)
>
>   _dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
>
> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
> - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> -
> - _dpu_encoder_setup_dither(phys);
> + if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI &&
> + !WARN_ON(dpu_enc->num_phys_encs == 0)) {
> + unsigned bpc = 
dpu_enc->phys_encs[0]->connector->display_info.bpc;
> + for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
> + if (!dpu_enc->hw_pp[i])
> + continue;
> + _dpu_encoder_setup_dither(dpu_enc->hw_pp[i], bpc);
>   }
>   }
>  }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 7411ab6bf6af..bea4ab5c58c5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -231,8 +231,7 @@ static void _setup_pingpong_ops(struct
> dpu_hw_pingpong *c,
>   c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
>   c->ops.get_line_count = dpu_hw_pp_get_line_count;
>
> - if (test_bit(DPU_PINGPONG_DITHER, ) &&
> - IS_SC7180_TARGET(c->hw.hwversion))
> + if (test_bit(DPU_PINGPONG_DITHER, ))
>   c->ops.setup_dither = dpu_hw_pp_setup_dither;
>  };

Change looks good to me


Does that count as a Reviewed-by?


Sure i have added the tag.


BR,
-R



- Kalyan

___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

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


Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

2020-07-21 Thread Mika Westerberg
Hi,

[Sorry for the delay, I was on vacation]

On Fri, Jul 17, 2020 at 01:32:10PM +0200, Karol Herbst wrote:
> Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597

Thanks for reporting.

I'll check your logs and try to figure if there is something we can do
to make both nouveau and TBT working at the same time.

> oddly enough I wasn't able to reproduce it on my XPS 9560, will ping
> once something breaks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco

2020-07-21 Thread Alexandre Torgue



On 7/21/20 12:39 PM, dillon min wrote:

Hi Alexandre,

On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
 wrote:


Hi Dillon

On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:

From: dillon min 

V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on stm32 spi controller.

V5:
1 instead of add send dummy data out under SIMPLEX_RX mode,
 add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
'SPI_3WIRE' mode



Concerning DT patches, they look goods for me. However I'll merge them
when drivers parts will be merged.

regards
Alex

This patchset status is :
dts:
 ARM: dts: stm32: Add dma config for spi5
 ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
 ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
   stm32429-disco board

panel-bindings: Reviewed-by: Rob Herring, need more reviewing to merge
 dt-bindings: display: panel: Add ilitek ili9341 panel bindings

clk: Acked-by: Stephen Boyd , need more reviewing to merge
 clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
   fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
 turn off by clk_disable_unused()

drm-panel:  Reviewed-by: Linus Walleij . need more reviewing to merge
 drm/panel: Add ilitek ili9341 panel driver

spi-driver: Acked-by: Mark Brown ,merged into mainline
 spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
 spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
   becoexit with 'SPI_3WIRE' mode

For ili9341 drivers, it seems to need more time to review, or might be dropped.
since the drm maintainer might create a new interface to support
DPI,DBI,DSI in one driver.
Currently it's under discussion. I will rework the ili9341 driver after that.

But, we can use the existing "drivers/gpu/drm/tiny/ili9341.c" driver to support
ili9341 on stm32f429-disco board only using the spi bus. except the
display refresh performance is not as good as the ltdc interface.

I can submit a new patch just with dts changed this week for it, if you need.




Thanks for this status. I'm close to send my PR for v5.9. There is no 
needs to have an intermediate version (Except you absolutely want it).


Thanks
alex


Thanks,
Dillon.





V4:
According to alexandre torgue's suggestion, combine ili9341 and
l3gd20's modification on stm32f429-disco board to one patchset.

Changes:

ili9341:

1 update ili9341 panel driver according to Linus's suggestion
2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4
3 merge l3gd20's change to this patchset

V3:
1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
to support serial spi & parallel rgb interface in one driver.
2 update ilitek,ili9341.yaml dts binding documentation.
3 update stm32f429-disco dts binding

V2:
1 verify ilitek,ili9341.yaml with make O=../linux-stm32
dt_binding_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/
ilitek,ili9341.yaml

V1:
1 add ili9341 drm panel driver
2 add ltdc, spi5 controller for stm32f429-disco
3 add ltdc, spi5 pin map for stm32f429-disco
4 add docs about ili9341
5 fix ltdc driver loading hang in clk set rate bug


L3gd20:
V3:
1 merge stm32f429-disco dtbs binding with ili9341 part

V2:
1 insert blank line at stm32f420-disco.dts line 143
2 add more description for l3gd20 in commit message

V1:
1 enable spi5 controller on stm32f429-disco (dts)
2 add spi5 pinmap for stm32f429-disco  (dts)
3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4


dillon min (8):
ARM: dts: stm32: Add dma config for spi5
ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
  stm32429-disco board
dt-bindings: display: panel: Add ilitek ili9341 panel bindings
clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
  fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
turn off by clk_disable_unused()
drm/panel: Add ilitek ili9341 panel driver
spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
  be coexit with 'SPI_3WIRE' mode

   .../bindings/display/panel/ilitek,ili9341.yaml |   69 ++
   arch/arm/boot/dts/stm32f4-pinctrl.dtsi |   67 +
   arch/arm/boot/dts/stm32f429-disco.dts  |   48 +
   arch/arm/boot/dts/stm32f429.dtsi   |3 +
   drivers/clk/clk-stm32f4.c  |7 +-
   drivers/gpu/drm/panel/Kconfig  |   12 +
   drivers/gpu/drm/panel/Makefile |1 +
   drivers/gpu/drm/panel/panel-ilitek-ili9341.c   | 1301 

   drivers/spi/spi-stm32.c|   19 +-
   drivers/spi/spi.c   

[PATCH] drm/imx: dw_hdmi-imx: use imx_drm_encoder_parse_of

2020-07-21 Thread Philipp Zabel
This is the same code and comment that is already shared by imx-ldb,
imx-tve, and parallel-display in imx_drm_encoder_parse_of().

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 87869b9997a6..a4f178c1d9bc 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -217,15 +217,9 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
hdmi->dev = >dev;
encoder = >encoder;
 
-   encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
-   /*
-* If we failed to find the CRTC(s) which this encoder is
-* supposed to be connected to, it's because the CRTC has
-* not been registered yet.  Defer probing, and hope that
-* the required CRTC is added later.
-*/
-   if (encoder->possible_crtcs == 0)
-   return -EPROBE_DEFER;
+   ret = imx_drm_encoder_parse_of(drm, encoder, dev->of_node);
+   if (ret)
+   return ret;
 
ret = dw_hdmi_imx_parse_dt(hdmi);
if (ret < 0)
-- 
2.20.1

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


[PATCH] drm/imx: drop panel attach/detach

2020-07-21 Thread Philipp Zabel
The drm_panel_attach/detach() functions are empty since
commit aa6c43644bc5 ("drm/panel: drop drm_device from drm_panel"),
remove them.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-ldb.c  | 10 --
 drivers/gpu/drm/imx/parallel-display.c |  6 --
 2 files changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 8791d60be92e..af757d1e21fe 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -455,13 +455,6 @@ static int imx_ldb_register(struct drm_device *drm,
drm_connector_attach_encoder(_ldb_ch->connector, encoder);
}
 
-   if (imx_ldb_ch->panel) {
-   ret = drm_panel_attach(imx_ldb_ch->panel,
-  _ldb_ch->connector);
-   if (ret)
-   return ret;
-   }
-
return 0;
 }
 
@@ -702,9 +695,6 @@ static void imx_ldb_unbind(struct device *dev, struct 
device *master,
for (i = 0; i < 2; i++) {
struct imx_ldb_channel *channel = _ldb->channel[i];
 
-   if (channel->panel)
-   drm_panel_detach(channel->panel);
-
kfree(channel->edid);
i2c_put_adapter(channel->ddc);
}
diff --git a/drivers/gpu/drm/imx/parallel-display.c 
b/drivers/gpu/drm/imx/parallel-display.c
index a831b5bd1613..8232f512b9ed 100644
--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -289,9 +289,6 @@ static int imx_pd_register(struct drm_device *drm,
   DRM_MODE_CONNECTOR_DPI);
}
 
-   if (imxpd->panel)
-   drm_panel_attach(imxpd->panel, >connector);
-
if (imxpd->next_bridge) {
ret = drm_bridge_attach(encoder, imxpd->next_bridge,
>bridge, 0);
@@ -357,9 +354,6 @@ static void imx_pd_unbind(struct device *dev, struct device 
*master,
 {
struct imx_parallel_display *imxpd = dev_get_drvdata(dev);
 
-   if (imxpd->panel)
-   drm_panel_detach(imxpd->panel);
-
kfree(imxpd->edid);
 }
 
-- 
2.20.1

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


[PATCH] gpu: ipu-v3: remove unused functions

2020-07-21 Thread Philipp Zabel
ipu_mbus_code_to_colorspace, ipu_stride_to_bytes, and
ipu_pixelformat_is_planar are unused. Remove them.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 67 -
 include/video/imx-ipu-v3.h  |  3 --
 2 files changed, 70 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b3dae9ec1a38..d166ee262ce4 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -133,73 +133,6 @@ enum ipu_color_space ipu_pixelformat_to_colorspace(u32 
pixelformat)
 }
 EXPORT_SYMBOL_GPL(ipu_pixelformat_to_colorspace);
 
-bool ipu_pixelformat_is_planar(u32 pixelformat)
-{
-   switch (pixelformat) {
-   case V4L2_PIX_FMT_YUV420:
-   case V4L2_PIX_FMT_YVU420:
-   case V4L2_PIX_FMT_YUV422P:
-   case V4L2_PIX_FMT_NV12:
-   case V4L2_PIX_FMT_NV21:
-   case V4L2_PIX_FMT_NV16:
-   case V4L2_PIX_FMT_NV61:
-   return true;
-   }
-
-   return false;
-}
-EXPORT_SYMBOL_GPL(ipu_pixelformat_is_planar);
-
-enum ipu_color_space ipu_mbus_code_to_colorspace(u32 mbus_code)
-{
-   switch (mbus_code & 0xf000) {
-   case 0x1000:
-   return IPUV3_COLORSPACE_RGB;
-   case 0x2000:
-   return IPUV3_COLORSPACE_YUV;
-   default:
-   return IPUV3_COLORSPACE_UNKNOWN;
-   }
-}
-EXPORT_SYMBOL_GPL(ipu_mbus_code_to_colorspace);
-
-int ipu_stride_to_bytes(u32 pixel_stride, u32 pixelformat)
-{
-   switch (pixelformat) {
-   case V4L2_PIX_FMT_YUV420:
-   case V4L2_PIX_FMT_YVU420:
-   case V4L2_PIX_FMT_YUV422P:
-   case V4L2_PIX_FMT_NV12:
-   case V4L2_PIX_FMT_NV21:
-   case V4L2_PIX_FMT_NV16:
-   case V4L2_PIX_FMT_NV61:
-   /*
-* for the planar YUV formats, the stride passed to
-* cpmem must be the stride in bytes of the Y plane.
-* And all the planar YUV formats have an 8-bit
-* Y component.
-*/
-   return (8 * pixel_stride) >> 3;
-   case V4L2_PIX_FMT_RGB565:
-   case V4L2_PIX_FMT_YUYV:
-   case V4L2_PIX_FMT_UYVY:
-   return (16 * pixel_stride) >> 3;
-   case V4L2_PIX_FMT_BGR24:
-   case V4L2_PIX_FMT_RGB24:
-   return (24 * pixel_stride) >> 3;
-   case V4L2_PIX_FMT_BGR32:
-   case V4L2_PIX_FMT_RGB32:
-   case V4L2_PIX_FMT_XBGR32:
-   case V4L2_PIX_FMT_XRGB32:
-   return (32 * pixel_stride) >> 3;
-   default:
-   break;
-   }
-
-   return -EINVAL;
-}
-EXPORT_SYMBOL_GPL(ipu_stride_to_bytes);
-
 int ipu_degrees_to_rot_mode(enum ipu_rotate_mode *mode, int degrees,
bool hflip, bool vflip)
 {
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 06b0b57e996c..d1b3889f74d8 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -484,9 +484,6 @@ int ipu_smfc_set_watermark(struct ipu_smfc *smfc, u32 
set_level, u32 clr_level);
 
 enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc);
 enum ipu_color_space ipu_pixelformat_to_colorspace(u32 pixelformat);
-enum ipu_color_space ipu_mbus_code_to_colorspace(u32 mbus_code);
-int ipu_stride_to_bytes(u32 pixel_stride, u32 pixelformat);
-bool ipu_pixelformat_is_planar(u32 pixelformat);
 int ipu_degrees_to_rot_mode(enum ipu_rotate_mode *mode, int degrees,
bool hflip, bool vflip);
 int ipu_rot_mode_to_degrees(int *degrees, enum ipu_rotate_mode mode,
-- 
2.20.1

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


Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

2020-07-21 Thread Melissa Wen
Hi all,

I traced the subtests' execution to figure out what happens (or not) in
a clean run and a blocked run, and this led me to suspect the
vkms_crtc_atomic_flush function. Examining the code and considering the
DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
drm_crtc_vblank_put pair. So I checked it that way, and again, the
problem of sequential execution + dpms/suspend failures disappeared.

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..f60bf1495306 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -240,30 +240,31 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
spin_lock(>dev->event_lock);

if (drm_crtc_vblank_get(crtc) != 0)
drm_crtc_send_vblank_event(crtc, crtc->state->event);
else
drm_crtc_arm_vblank_event(crtc, crtc->state->event);

spin_unlock(>dev->event_lock);

crtc->state->event = NULL;
}

vkms_output->composer_state = to_vkms_crtc_state(crtc->state);

spin_unlock_irq(_output->lock);
+   drm_crtc_vblank_put(crtc);
 }

However, I'm not sure if it's just another duck-tape proposal or if it
makes any sense. I'm still investigating better, but I think sharing
with you may be more productive.

Melissa

On 07/21, Daniel Vetter wrote:
> On Tue, Jul 21, 2020 at 05:33:00AM +, Sidong Yang wrote:
> > Hi, Daniel and Melissa
> > 
> > I tested some code for this problem trying to find the code that make 
> > problem in igt test.
> > kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). I 
> > check each steps
> > and I found that without cleanup step, the problem solved.
> > In cleanup step, igt test code seems like this.
> > 
> > drmModeSetCrtc(display->drm_fd, crtc_id, 0 /* fb_id */, 0, 
> > 0 /* x, y */, NULL /* connector */, 0, NULL /* mode */)
> > 
> > I commented out this function call and there is no problem in executing 
> > tests repeatedly.
> > I'm trying to find out what's happen in this call. but don't know until now
> > I hope this information help to solve the problem.
> 
> Ah yes that fits the evidence we have from Melissa pretty well: Not
> turning off the CRTC means the next test wont have to turn it back on
> again. And the vblank bug seems to be in the code which turns the crtc
> back on. At least inserting a vblank wait in there is enough to paper over
> all the issues, per Melissa's testing.
> 
> So at least we're now fairly confident where the bug is, that's some solid
> progress.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v7 2/5] drm/imx: Add initial support for DCSS on iMX8MQ

2020-07-21 Thread Philipp Zabel
Hi Laurentiu,

On Tue, 2020-07-21 at 13:20 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu 
> 
> This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> Some of its capabilities include:
>  * 4K@60fps;
>  * HDR10;
>  * one graphics and 2 video pipelines;
>  * on-the-fly decompression of compressed video and graphics;
> 
> The reference manual can be found here:
> https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> 
> The current patch adds only basic functionality: one primary plane for
> graphics, linear, tiled and super-tiled buffers support (no graphics
> decompression yet), no HDR10 and no video planes.
> 
> Video planes support and HDR10 will be added in subsequent patches once
> per-plane de-gamma/CSC/gamma support is in.
> 
> Signed-off-by: Laurentiu Palcu 
> Reviewed-by: Lucas Stach 
> ---
>  drivers/gpu/drm/imx/Kconfig|   2 +
>  drivers/gpu/drm/imx/Makefile   |   1 +
>  drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
>  drivers/gpu/drm/imx/dcss/Makefile  |   6 +
>  drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  70 +++
>  drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 219 +++
>  drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 424 +
>  drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++
>  drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++
>  drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
>  drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 +
>  drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 
>  drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++
>  drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
>  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
>  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
>  drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
>  17 files changed, 3962 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
>  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> 
> diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> index 207bf7409dfb..6231048aa5aa 100644
> --- a/drivers/gpu/drm/imx/Kconfig
> +++ b/drivers/gpu/drm/imx/Kconfig
> @@ -39,3 +39,5 @@ config DRM_IMX_HDMI
>   depends on DRM_IMX
>   help
> Choose this if you want to use HDMI on i.MX6.
> +
> +source "drivers/gpu/drm/imx/dcss/Kconfig"
> diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> index 21cdcc2faabc..b644deffe948 100644
> --- a/drivers/gpu/drm/imx/Makefile
> +++ b/drivers/gpu/drm/imx/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
>  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>  
>  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
> diff --git a/drivers/gpu/drm/imx/dcss/Kconfig 
> b/drivers/gpu/drm/imx/dcss/Kconfig
> new file mode 100644
> index ..988979bc22cc
> --- /dev/null
> +++ b/drivers/gpu/drm/imx/dcss/Kconfig
> @@ -0,0 +1,9 @@
> +config DRM_IMX_DCSS
> + tristate "i.MX8MQ DCSS"
> + select RESET_CONTROLLER

Why does DCSS select RESET_CONTROLLER?

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


Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-21 Thread Sumit Semwal
Hello Rob,

Thanks for the review!
On Tue, 21 Jul 2020 at 09:03, Rob Herring  wrote:
>
> On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of 
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal 
> > ---
> >  .../display/panel/tianma,nt36672a.yaml| 110 ++
> >  1 file changed, 110 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..3c583ca926ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > +  - Sumit Semwal 
> > +
> > +description: |
> > +  The nt36672a panel from Tianma is a FHD+ LCD display panel with a 
> > resolution
> > +  of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > +  - $ref: panel-common.yaml#
> > +
> > +properties:
> > +  compatible:
> > +const: tianma,nt36672a
> > +
> > +  reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > +  reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > +  can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > +  vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > +  Power IC supply
> > +
> > +  vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > +  vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > +  pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > +  pinctrl-0:
> > +description: Active pinctrls
> > +
> > +  pinctrl-1:
> > +description: Suspend pinctrls
>
> I think the pinctrl should go in the DSI controller node, not the
> display unless it is settings for 'reset-gpios'.
Yes, from the downstream code, this seems to be for reset-gpios.

>
> > +
> > +  ports:
> > +type: object
> > +properties:
> > +  port@0:
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > +  reg:
> > +const: 0
> > +
> > +required:
> > +  - reg
>
> For a single port, you can do just 'port' (without ports node).
Thanks; will update in next version.
>
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - vddi0-supply
> > +  - vddpos-supply
> > +  - vddneg-supply
> > +  - reset-gpios
> > +  - pinctrl-names
> > +  - pinctrl-0
> > +  - pinctrl-1
> > +  - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > +  - |+
> > +#include 
> > +dsi0 {
>
> dsi {
>
> > +  #address-cells = <1>;
> > +  #size-cells = <0>;
> > +
> > +  panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <_dsi_active>;
> > +pinctrl-1 = <_dsi_suspend>;
> > +
> > +ports {
> > +  #address-cells = <1>;
> > +  #size-cells = <0>;
> > +
> > +  port@0 {
> > +reg = <0>;
> > +tianma_nt36672a_in_0: endpoint {
> > +  remote-endpoint = <_out>;
> > +};
> > +  };
> > +};
> > +  };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >

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


Re: [PATCH 1/2 v1] dt-bindings: backlight: Add Kinetic KTD253 bindings

2020-07-21 Thread Daniel Thompson
On Mon, Jul 20, 2020 at 10:35:05PM +0200, Linus Walleij wrote:
> This adds device tree bindings for the Kinetic KTD253
> white LED backlight driver.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../leds/backlight/kinetic,ktd253.yaml| 48 +++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml 
> b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
> new file mode 100644
> index ..610bf9a0e270
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktd253.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Kinetic Technologies KTD253 one-wire backlight
> +
> +maintainers:
> +  - Linus Walleij 
> +
> +description: |
> +  The Kinetic Technologies KTD253 is a white LED backlight that is
> +  controlled by a single GPIO line. If you just turn on the backlight
> +  it goes to maximum backlight then you can set the level of backlight
> +  using pulses on the enable wire.
> +
> +properties:
> +  compatible:
> +const: kinetic,ktd253
> +
> +  gpios:
> +description: GPIO to use to enable/disable and dim the backlight.
> +maxItems: 1
> +
> +  default-brightness:
> +description: Default brightness level on boot. 0 is off.
> +minimum: 0
> +maximum: 255
> +
> +  max-brightness:
> +description: Maximum brightness that is allowed during runtime.
> +minimum: 0
> +maximum: 255

[I ended up dropping this into this thread... but it applies to both
patches]

I'm a bit sceptical of having a max-brightness in the DT and a driver
defined lookup table in the driver itself. That doesn't make a whole lot
of sense to me since the maximum brightness here is basically relies on
knowing what scale the Linux driver has opted to implement in its tables.

I think there are two options here.

1. Throw away the brightness table in the driver and expose the hardware
   steps directly (maybe using allowing properties such as
   max-brightness = 24 if the top 8 values cannot be distinguished
   visually).

2. Implement a brightness table in the DT if there really is a need
   to linearize the feel of the slider. In that case max-brightness
   can be inferred from the maximum value in the table.

Note that #2 is absolutely *not* the same as the tables in pwm_bl.c
(which are used to map a very wide linear scale on the hardware into a
smaller logarithmic interface for software to use). For this driver
the driver's lookup table is used to present an oversized
scale to software and quantizing it in the driver (using variably sized
quantums) to create a hardware value.

This can be useful if the hardware's perceptual response feels *really*
lumpy but often results in sliders with dead zones (because they do not
"snap" to the hardware intervals). Looking at the gaps in the driver I'm
suspect the table is not worth the effort (the difference in the deltas
is pretty modest) but I'm happy to contradicted by someone with access
to the hardware!


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


Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property

2020-07-21 Thread Maxime Ripard
On Mon, Jul 20, 2020 at 08:10:26PM -0600, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> > 
> > Some LCD panels do not support 24-bit true color, or 8bits per channel
> > RGB. Many low end ones only support up to 6 bits per channel natively.
> 
> This should be implied by the panel's compatible property.

I'm not sure it should, or at least it's not sufficient. Some panels
while 24 bits capable might only have the higher bits connected to save
off a couple of pins per color, in which case we should probably
describe that somehow.

Maxime


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


Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco

2020-07-21 Thread dillon min
Hi Alexandre,

On Tue, Jul 21, 2020 at 5:19 PM Alexandre Torgue
 wrote:
>
> Hi Dillon
>
> On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:
> > From: dillon min 
> >
> > V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> > for SPI_SIMPLEX_RX mode on stm32 spi controller.
> >
> > V5:
> > 1 instead of add send dummy data out under SIMPLEX_RX mode,
> > add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
> > 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
> > 'SPI_3WIRE' mode
> >
>
> Concerning DT patches, they look goods for me. However I'll merge them
> when drivers parts will be merged.
>
> regards
> Alex
This patchset status is :
dts:
ARM: dts: stm32: Add dma config for spi5
ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
  stm32429-disco board

panel-bindings: Reviewed-by: Rob Herring, need more reviewing to merge
dt-bindings: display: panel: Add ilitek ili9341 panel bindings

clk: Acked-by: Stephen Boyd , need more reviewing to merge
clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
  fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
turn off by clk_disable_unused()

drm-panel:  Reviewed-by: Linus Walleij . need more reviewing to merge
drm/panel: Add ilitek ili9341 panel driver

spi-driver: Acked-by: Mark Brown ,merged into mainline
spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
  becoexit with 'SPI_3WIRE' mode

For ili9341 drivers, it seems to need more time to review, or might be dropped.
since the drm maintainer might create a new interface to support
DPI,DBI,DSI in one driver.
Currently it's under discussion. I will rework the ili9341 driver after that.

But, we can use the existing "drivers/gpu/drm/tiny/ili9341.c" driver to support
ili9341 on stm32f429-disco board only using the spi bus. except the
display refresh performance is not as good as the ltdc interface.

I can submit a new patch just with dts changed this week for it, if you need.

Thanks,
Dillon.
>
>
>
> > V4:
> > According to alexandre torgue's suggestion, combine ili9341 and
> > l3gd20's modification on stm32f429-disco board to one patchset.
> >
> > Changes:
> >
> > ili9341:
> >
> > 1 update ili9341 panel driver according to Linus's suggestion
> > 2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4
> > 3 merge l3gd20's change to this patchset
> >
> > V3:
> > 1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
> >to support serial spi & parallel rgb interface in one driver.
> > 2 update ilitek,ili9341.yaml dts binding documentation.
> > 3 update stm32f429-disco dts binding
> >
> > V2:
> > 1 verify ilitek,ili9341.yaml with make O=../linux-stm32
> >dt_binding_check
> >DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/
> >ilitek,ili9341.yaml
> >
> > V1:
> > 1 add ili9341 drm panel driver
> > 2 add ltdc, spi5 controller for stm32f429-disco
> > 3 add ltdc, spi5 pin map for stm32f429-disco
> > 4 add docs about ili9341
> > 5 fix ltdc driver loading hang in clk set rate bug
> >
> >
> > L3gd20:
> > V3:
> > 1 merge stm32f429-disco dtbs binding with ili9341 part
> >
> > V2:
> > 1 insert blank line at stm32f420-disco.dts line 143
> > 2 add more description for l3gd20 in commit message
> >
> > V1:
> > 1 enable spi5 controller on stm32f429-disco (dts)
> > 2 add spi5 pinmap for stm32f429-disco  (dts)
> > 3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4
> >
> >
> > dillon min (8):
> >ARM: dts: stm32: Add dma config for spi5
> >ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
> >ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
> >  stm32429-disco board
> >dt-bindings: display: panel: Add ilitek ili9341 panel bindings
> >clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
> >  fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
> >turn off by clk_disable_unused()
> >drm/panel: Add ilitek ili9341 panel driver
> >spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
> >spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
> >  be coexit with 'SPI_3WIRE' mode
> >
> >   .../bindings/display/panel/ilitek,ili9341.yaml |   69 ++
> >   arch/arm/boot/dts/stm32f4-pinctrl.dtsi |   67 +
> >   arch/arm/boot/dts/stm32f429-disco.dts  |   48 +
> >   arch/arm/boot/dts/stm32f429.dtsi   |3 +
> >   drivers/clk/clk-stm32f4.c  |7 +-
> >   drivers/gpu/drm/panel/Kconfig  |   12 +
> >   drivers/gpu/drm/panel/Makefile |1 +
> >   drivers/gpu/drm/panel/panel-ilitek-ili9341.c   | 1301 
> > 
> >   drivers/spi/spi-stm32.c  

Re: [PATCH v5 0/8] Enable ili9341 and l3gd20 on stm32f429-disco

2020-07-21 Thread Alexandre Torgue

Hi Dillon

On 5/25/20 5:40 AM, dillon.min...@gmail.com wrote:

From: dillon min 

V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
for SPI_SIMPLEX_RX mode on stm32 spi controller.

V5:
1 instead of add send dummy data out under SIMPLEX_RX mode,
add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
'SPI_3WIRE' mode



Concerning DT patches, they look goods for me. However I'll merge them 
when drivers parts will be merged.


regards
Alex




V4:
According to alexandre torgue's suggestion, combine ili9341 and
l3gd20's modification on stm32f429-disco board to one patchset.

Changes:

ili9341:

1 update ili9341 panel driver according to Linus's suggestion
2 drop V1's No.5 patch, sumbit new changes for clk-stm32f4
3 merge l3gd20's change to this patchset

V3:
1 merge original tiny/ili9341.c driver to panel/panel-ilitek-ili9341.c
   to support serial spi & parallel rgb interface in one driver.
2 update ilitek,ili9341.yaml dts binding documentation.
3 update stm32f429-disco dts binding

V2:
1 verify ilitek,ili9341.yaml with make O=../linux-stm32
   dt_binding_check
   DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/panel/
   ilitek,ili9341.yaml

V1:
1 add ili9341 drm panel driver
2 add ltdc, spi5 controller for stm32f429-disco
3 add ltdc, spi5 pin map for stm32f429-disco
4 add docs about ili9341
5 fix ltdc driver loading hang in clk set rate bug


L3gd20:
V3:
1 merge stm32f429-disco dtbs binding with ili9341 part

V2:
1 insert blank line at stm32f420-disco.dts line 143
2 add more description for l3gd20 in commit message

V1:
1 enable spi5 controller on stm32f429-disco (dts)
2 add spi5 pinmap for stm32f429-disco  (dts)
3 add SPI_SIMPLEX_RX, SPI_3WIRE_RX support for stm32f4


dillon min (8):
   ARM: dts: stm32: Add dma config for spi5
   ARM: dts: stm32: Add pin map for ltdc & spi5 on stm32f429-disco board
   ARM: dts: stm32: enable ltdc binding with ili9341, gyro l3gd20 on
 stm32429-disco board
   dt-bindings: display: panel: Add ilitek ili9341 panel bindings
   clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate,
 fix duplicated ltdc clock register to 'clk_core' case ltdc's clock
   turn off by clk_disable_unused()
   drm/panel: Add ilitek ili9341 panel driver
   spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
   spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't
 be coexit with 'SPI_3WIRE' mode

  .../bindings/display/panel/ilitek,ili9341.yaml |   69 ++
  arch/arm/boot/dts/stm32f4-pinctrl.dtsi |   67 +
  arch/arm/boot/dts/stm32f429-disco.dts  |   48 +
  arch/arm/boot/dts/stm32f429.dtsi   |3 +
  drivers/clk/clk-stm32f4.c  |7 +-
  drivers/gpu/drm/panel/Kconfig  |   12 +
  drivers/gpu/drm/panel/Makefile |1 +
  drivers/gpu/drm/panel/panel-ilitek-ili9341.c   | 1301 
  drivers/spi/spi-stm32.c|   19 +-
  drivers/spi/spi.c  |3 +-
  10 files changed, 1521 insertions(+), 9 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c


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


[PATCH v3] drm/virtio: fix missing dma_fence_put() in virtio_gpu_execbuffer_ioctl()

2020-07-21 Thread Xin He
From: Qi Liu 

We should put the reference count of the fence after calling
virtio_gpu_cmd_submit(). So add the missing dma_fence_put().

Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit 
synchronization")
Co-developed-by: Xin He 
Signed-off-by: Xin He 
Signed-off-by: Qi Liu 
Reviewed-by: Muchun Song 
---

changelog in v3:
1) Change the subject from "drm/virtio: fixed memory leak in 
virtio_gpu_execbuffer_ioctl()" to 
   "drm/virtio: fix missing dma_fence_put() in virtio_gpu_execbuffer_ioctl()"
2) Rework the commit log

changelog in v2:
1) Add a change description 

 drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 5df722072ba0..19c5bc01eb79 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -179,6 +179,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device 
*dev, void *data,
 
virtio_gpu_cmd_submit(vgdev, buf, exbuf->size,
  vfpriv->ctx_id, buflist, out_fence);
+   dma_fence_put(_fence->f);
virtio_gpu_notify(vgdev);
return 0;
 
-- 
2.21.1 (Apple Git-122.3)

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


Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-07-21 Thread Lucas Stach
Hi Andrey,

Am Mittwoch, den 12.02.2020, 11:33 -0500 schrieb Andrey Grodzovsky:
> On 2/11/20 7:53 PM, Luben Tuikov wrote:
> > On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
> > > On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
> > > > On 2/10/20 4:50 PM, Luben Tuikov wrote:
> > > > > Hi Lucas,
> > > > > 
> > > > > Thank you for bringing awareness of this issue, publicly.
> > > > > 
> > > > > As soon as this patch showed up back in November of 2019,
> > > > > I objected to it, privately.
> > > > 
> > > > I didn't find this objection in my mail actually
> > Yes, I didn't send it to you.
> > 
> > > > > I suggested to instead use a _list_ to store the "state" of
> > > > > all jobs of the same state. Then, at any time, timeout interrupt
> > > > > or whatever, we can atomically (irq spinlock) move the timeout/bad
> > > > > job to the timedout/cleanup/bad job list, and wake someone up
> > > > > to deal with that list asynchronously, and return from the
> > > > > interrupt/etc.
> > > > > immediately.
> > > > 
> > > > Sounds a good idea to me, i think enough for us to have 2 lists,
> > > > timeout list for jobs scheduled to HW and not yet completed
> > > > (completion fence signaled) and cleanup list for those that did
> > > > complete. This should give alternative solution to the race condition
> > > > this patch was addressing without causing the break the Lucas
> > > > reported. If no one objects I think i can try implement it.
> > > > 
> > > > Andrey
> > > 
> > > Thinking more i realize Luben is right about having also bad job list as
> > > this is needed for normal job competition (by fence callback from
> > > amdgpu_fence_process)  and you need to decide if you move it to cleanup
> > > list from timeout list or not. If it's already in bad job list - meaning
> > > that it's being processed by GPU recovery code you don't touch it,
> > > otherwise you move it to cleanup list where it will be freed eventually
> > > by invocation of drm_sched_get_cleanup_job.
> > Yep...
> > 
> > Perhaps fewer lists, than "timeout", "bad" and "cleanup" could be had.
> > I'd also name the "bad" list as "recovery" list, as that is what would
> > be done to commands on that list.
> > 
> > "Timeout" is a status "timed-out", so perhaps just set the timeout
> > flag and move it to a "done" list. (Note that the command can still
> > complete asynchronously while on that list and while it has status
> > "timed-out'.)
> > 
> > The idea is that,
> > 1) it avoid contention and races when more than one context
> > can update the job at the same time, and
> > 2) easy to process all jobs of a certain state and/or
> > move them around, etc.
> > 
> > Let's discuss it and come up with a plan. :-)
> > 
> > Regards,
> > Luben
> 
> Sure, let me maybe come up with a draft patch so we have more concrete 
> stuff to discuss and review.

It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress from your side on fixing
this?

Regards,
Lucas

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


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Intel


On 7/21/20 11:50 AM, Daniel Vetter wrote:

On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
 wrote:


On 7/21/20 10:55 AM, Christian König wrote:

Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):

On 7/21/20 9:45 AM, Christian König wrote:

Am 21.07.20 um 09:41 schrieb Daniel Vetter:

On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
wrote:

Hi,

On 7/9/20 2:33 PM, Daniel Vetter wrote:

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more
explicit in
flat out mandating the amdkfd eviction fences for long running
compute
workloads or workloads where userspace fencing is allowed.

Although (in my humble opinion) it might be possible to completely
untangle
kernel-introduced fences for resource management and dma-fences
used for
completion- and dependency tracking and lift a lot of restrictions
for the
dma-fences, including prohibiting infinite ones, I think this
makes sense
describing the current state.

Yeah I think a future patch needs to type up how we want to make that
happen (for some cross driver consistency) and what needs to be
considered. Some of the necessary parts are already there (with
like the
preemption fences amdkfd has as an example), but I think some clear
docs
on what's required from both hw, drivers and userspace would be really
good.

I'm currently writing that up, but probably still need a few days
for this.

Great! I put down some (very) initial thoughts a couple of weeks ago
building on eviction fences for various hardware complexity levels here:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fthomash%2Fdocs%2F-%2Fblob%2Fmaster%2FUntangling%2520dma-fence%2520and%2520memory%2520allocation.odtdata=02%7C01%7Cchristian.koenig%40amd.com%7C8978bbd7823e4b41663708d82d52add3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309180424312390sdata=tTxx2vfzfwLM1IBJSqqAZRw1604R%2F0bI3MwN1%2FBf2VQ%3Dreserved=0


I don't think that this will ever be possible.

See that Daniel describes in his text is that indefinite fences are a
bad idea for memory management, and I think that this is a fixed fact.

In other words the whole concept of submitting work to the kernel
which depends on some user space interaction doesn't work and never will.

Well the idea here is that memory management will *never* depend on
indefinite fences: As soon as someone waits on a memory manager fence
(be it eviction, shrinker or mmu notifier) it breaks out of any
dma-fence dependencies and /or user-space interaction. The text tries to
describe what's required to be able to do that (save for non-preemptible
gpus where someone submits a forever-running shader).

Yeah I think that part of your text is good to describe how to
untangle memory fences from synchronization fences given how much the
hw can do.


So while I think this is possible (until someone comes up with a case
where it wouldn't work of course), I guess Daniel has a point in that it
won't happen because of inertia and there might be better options.

Yeah it's just I don't see much chance for splitting dma-fence itself.
That's also why I'm not positive on the "no hw preemption, only
scheduler" case: You still have a dma_fence for the batch itself,
which means still no userspace controlled synchronization or other
form of indefinite batches allowed. So not getting us any closer to
enabling the compute use cases people want.


Yes, we can't do magic. As soon as an indefinite batch makes it to such 
hardware we've lost. But since we can break out while the batch is stuck 
in the scheduler waiting, what I believe we *can* do with this approach 
is to avoid deadlocks due to locally unknown dependencies, which has 
some bearing on this documentation patch, and also to allow memory 
allocation in dma-fence (not memory-fence) critical sections, like gpu 
fault- and error handlers without resorting to using memory pools.


But again. I'm not saying we should actually implement this. Better to 
consider it and reject it than not consider it at all.


/Thomas


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


[PATCH v7 5/5] dt-bindings: display: imx: add bindings for DCSS

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

Add bindings for iMX8MQ Display Controller Subsystem.

Signed-off-by: Laurentiu Palcu 
Reviewed-by: Rob Herring 
---
 .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml 
b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
new file mode 100644
index ..68e4635e4874
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 NXP
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: iMX8MQ Display Controller Subsystem (DCSS)
+
+maintainers:
+  - Laurentiu Palcu 
+
+description:
+
+  The DCSS (display controller sub system) is used to source up to three
+  display buffers, compose them, and drive a display using HDMI 2.0a(with HDCP
+  2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays. HDR10
+  image processing capabilities are included to provide a solution capable of
+  driving next generation high dynamic range displays.
+
+properties:
+  compatible:
+const: nxp,imx8mq-dcss
+
+  reg:
+items:
+  - description: DCSS base address and size, up to IRQ steer start
+  - description: DCSS BLKCTL base address and size
+
+  interrupts:
+items:
+  - description: Context loader completion and error interrupt
+  - description: DTG interrupt used to signal context loader trigger time
+  - description: DTG interrupt for Vblank
+
+  interrupt-names:
+items:
+  - const: ctxld
+  - const: ctxld_kick
+  - const: vblank
+
+  clocks:
+items:
+  - description: Display APB clock for all peripheral PIO access interfaces
+  - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
+  - description: RTRAM clock
+  - description: Pixel clock, can be driven either by HDMI phy clock or 
MIPI
+  - description: DTRC clock, needed by video decompressor
+
+  clock-names:
+items:
+  - const: apb
+  - const: axi
+  - const: rtrm
+  - const: pix
+  - const: dtrc
+
+  assigned-clocks:
+items:
+  - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_AXI_ROOT
+  - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
+  - description: Phandle and clock specifier of either 
IMX8MQ_VIDEO2_PLL1_REF_SEL or
+ IMX8MQ_VIDEO_PLL1_REF_SEL
+
+  assigned-clock-parents:
+items:
+  - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
+  - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
+  - description: Phandle and clock specifier of IMX8MQ_CLK_27M
+
+  assigned-clock-rates:
+items:
+  - description: Must be 800 MHz
+  - description: Must be 400 MHz
+
+  port:
+type: object
+description:
+  A port node pointing to the input port of a HDMI/DP or MIPI display 
bridge.
+
+additionalProperties: false
+
+examples:
+  - |
+dcss: display-controller@32e0 {
+compatible = "nxp,imx8mq-dcss";
+reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
+interrupts = <6>, <8>, <9>;
+interrupt-names = "ctxld", "ctxld_kick", "vblank";
+interrupt-parent = <>;
+clocks = < 248>, < 247>, < 249>,
+ < 254>,< 122>;
+clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
+assigned-clocks = < 107>, < 109>, < 266>;
+assigned-clock-parents = < 78>, < 78>, < 3>;
+assigned-clock-rates = <8>,
+   <4>;
+port {
+dcss_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
-- 
2.23.0

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


[PATCH v7 2/5] drm/imx: Add initial support for DCSS on iMX8MQ

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
 * 4K@60fps;
 * HDR10;
 * one graphics and 2 video pipelines;
 * on-the-fly decompression of compressed video and graphics;

The reference manual can be found here:
https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM

The current patch adds only basic functionality: one primary plane for
graphics, linear, tiled and super-tiled buffers support (no graphics
decompression yet), no HDR10 and no video planes.

Video planes support and HDR10 will be added in subsequent patches once
per-plane de-gamma/CSC/gamma support is in.

Signed-off-by: Laurentiu Palcu 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/imx/Kconfig|   2 +
 drivers/gpu/drm/imx/Makefile   |   1 +
 drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
 drivers/gpu/drm/imx/dcss/Makefile  |   6 +
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  70 +++
 drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 219 +++
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 424 +
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++
 drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 +
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 
 drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++
 drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
 drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
 17 files changed, 3962 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
 create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c

diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 207bf7409dfb..6231048aa5aa 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -39,3 +39,5 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
  Choose this if you want to use HDMI on i.MX6.
+
+source "drivers/gpu/drm/imx/dcss/Kconfig"
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 21cdcc2faabc..b644deffe948 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
 obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
 
 obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
+obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
diff --git a/drivers/gpu/drm/imx/dcss/Kconfig b/drivers/gpu/drm/imx/dcss/Kconfig
new file mode 100644
index ..988979bc22cc
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/Kconfig
@@ -0,0 +1,9 @@
+config DRM_IMX_DCSS
+   tristate "i.MX8MQ DCSS"
+   select RESET_CONTROLLER
+   select IMX_IRQSTEER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM && ARCH_MXC
+   help
+ Choose this if you have a NXP i.MX8MQ based system and want to use the
+ Display Controller Subsystem. This option enables DCSS support.
diff --git a/drivers/gpu/drm/imx/dcss/Makefile 
b/drivers/gpu/drm/imx/dcss/Makefile
new file mode 100644
index ..8c7c8da42792
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/Makefile
@@ -0,0 +1,6 @@
+imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o \
+dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o 
dcss-crtc.o \
+dcss-plane.o
+
+obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o
+
diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c 
b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
new file mode 100644
index ..c9b54bb2692d
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+
+#include "dcss-dev.h"
+
+#define DCSS_BLKCTL_RESET_CTRL 0x00
+#define   B_CLK_RESETN BIT(0)
+#define   APB_CLK_RESETN   BIT(1)
+#define   P_CLK_RESETN BIT(2)
+#define   RTR_CLK_RESETN   BIT(4)
+#define DCSS_BLKCTL_CONTROL0   0x10
+#define   HDMI_MIPI_CLK_SELBIT(0)
+#define   

[PATCH v7 4/5] MAINTAINERS: Add entry for i.MX 8MQ DCSS driver

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

The driver is part of DRM subsystem and is located in drivers/gpu/drm/imx/dcss.

Signed-off-by: Laurentiu Palcu 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index dad5a62d21a7..200c5985b41f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12276,6 +12276,14 @@ F: drivers/iio/gyro/fxas21002c_core.c
 F: drivers/iio/gyro/fxas21002c_i2c.c
 F: drivers/iio/gyro/fxas21002c_spi.c
 
+NXP i.MX 8MQ DCSS DRIVER
+M: Laurentiu Palcu 
+R: Lucas Stach 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
+F: drivers/gpu/drm/imx/dcss/
+
 NXP SGTL5000 DRIVER
 M: Fabio Estevam 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
-- 
2.23.0

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


[PATCH v7 3/5] drm/imx/dcss: use drm_bridge_connector API

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

Make use of drm_bridge_connector API to have the connector initialized by the
display controller.

Signed-off-by: Laurentiu Palcu 
CC: Sam Ravnborg 
CC: Laurent Pinchart 
---
 drivers/gpu/drm/imx/dcss/dcss-dev.c | 17 +---
 drivers/gpu/drm/imx/dcss/dcss-kms.c | 31 -
 drivers/gpu/drm/imx/dcss/dcss-kms.h |  1 +
 3 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c 
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 83a4840435cf..c849533ca83e 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -8,9 +8,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "dcss-dev.h"
+#include "dcss-kms.h"
 
 static void dcss_clocks_enable(struct dcss_dev *dcss)
 {
@@ -247,9 +250,13 @@ void dcss_dev_destroy(struct dcss_dev *dcss)
 int dcss_dev_suspend(struct device *dev)
 {
struct dcss_dev *dcss = dcss_drv_dev_to_dcss(dev);
+   struct drm_device *ddev = dcss_drv_dev_to_drm(dev);
+   struct dcss_kms_dev *kms = container_of(ddev, struct dcss_kms_dev, 
base);
int ret;
 
-   drm_mode_config_helper_suspend(dcss_drv_dev_to_drm(dev));
+   drm_bridge_connector_disable_hpd(kms->connector);
+
+   drm_mode_config_helper_suspend(ddev);
 
if (pm_runtime_suspended(dev))
return 0;
@@ -266,9 +273,11 @@ int dcss_dev_suspend(struct device *dev)
 int dcss_dev_resume(struct device *dev)
 {
struct dcss_dev *dcss = dcss_drv_dev_to_dcss(dev);
+   struct drm_device *ddev = dcss_drv_dev_to_drm(dev);
+   struct dcss_kms_dev *kms = container_of(ddev, struct dcss_kms_dev, 
base);
 
if (pm_runtime_suspended(dev)) {
-   drm_mode_config_helper_resume(dcss_drv_dev_to_drm(dev));
+   drm_mode_config_helper_resume(ddev);
return 0;
}
 
@@ -278,7 +287,9 @@ int dcss_dev_resume(struct device *dev)
 
dcss_ctxld_resume(dcss->ctxld);
 
-   drm_mode_config_helper_resume(dcss_drv_dev_to_drm(dev));
+   drm_mode_config_helper_resume(ddev);
+
+   drm_bridge_connector_enable_hpd(kms->connector);
 
return 0;
 }
diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c 
b/drivers/gpu/drm/imx/dcss/dcss-kms.c
index 3ca49d0a3e61..135a62366ab8 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -74,7 +75,7 @@ static const struct drm_encoder_funcs 
dcss_kms_simple_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
-static int dcss_kms_setup_encoder(struct dcss_kms_dev *kms)
+static int dcss_kms_bridge_connector_init(struct dcss_kms_dev *kms)
 {
struct drm_device *ddev = >base;
struct drm_encoder *encoder = >encoder;
@@ -103,7 +104,23 @@ static int dcss_kms_setup_encoder(struct dcss_kms_dev *kms)
return ret;
}
 
-   return drm_bridge_attach(encoder, bridge, NULL, 0);
+   ret = drm_bridge_attach(encoder, bridge, NULL,
+   DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+   if (ret < 0) {
+   dev_err(ddev->dev, "Unable to attach bridge %pOF\n",
+   bridge->of_node);
+   return ret;
+   }
+
+   kms->connector = drm_bridge_connector_init(ddev, encoder);
+   if (IS_ERR(kms->connector)) {
+   dev_err(ddev->dev, "Unable to create bridge connector.\n");
+   return PTR_ERR(kms->connector);
+   }
+
+   drm_connector_attach_encoder(kms->connector, encoder);
+
+   return 0;
 }
 
 struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev *dcss)
@@ -131,18 +148,20 @@ struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev 
*dcss)
 
drm->irq_enabled = true;
 
-   ret = dcss_crtc_init(crtc, drm);
+   ret = dcss_kms_bridge_connector_init(kms);
if (ret)
goto cleanup_mode_config;
 
-   ret = dcss_kms_setup_encoder(kms);
+   ret = dcss_crtc_init(crtc, drm);
if (ret)
-   goto cleanup_crtc;
+   goto cleanup_mode_config;
 
drm_mode_config_reset(drm);
 
drm_kms_helper_poll_init(drm);
 
+   drm_bridge_connector_enable_hpd(kms->connector);
+
ret = drm_dev_register(drm, 0);
if (ret)
goto cleanup_crtc;
@@ -152,6 +171,7 @@ struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev *dcss)
return kms;
 
 cleanup_crtc:
+   drm_bridge_connector_disable_hpd(kms->connector);
drm_kms_helper_poll_fini(drm);
dcss_crtc_deinit(crtc, drm);
 
@@ -167,6 +187,7 @@ void dcss_kms_detach(struct dcss_kms_dev *kms)
struct drm_device *drm = >base;
 
drm_dev_unregister(drm);
+   drm_bridge_connector_disable_hpd(kms->connector);
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
drm_crtc_vblank_off(>crtc.base);
diff --git 

[PATCH v7 1/5] drm/imx: compile imx directory by default

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which 
would
bring in also IPUv3 core driver...

The current patch would allow adding new IPs in the imx/ directory without 
needing
to set DRM_IMX.

Signed-off-by: Laurentiu Palcu 
Reviewed-by: Lucas Stach 
---
 drivers/gpu/drm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..c4d12e756c63 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -100,7 +100,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STM) += stm/
 obj-$(CONFIG_DRM_STI) += sti/
-obj-$(CONFIG_DRM_IMX) += imx/
+obj-y  += imx/
 obj-$(CONFIG_DRM_INGENIC) += ingenic/
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
 obj-$(CONFIG_DRM_MESON)+= meson/
-- 
2.23.0

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


[PATCH v7 0/5] Add support for iMX8MQ Display Controller Subsystem

2020-07-21 Thread Laurentiu Palcu
From: Laurentiu Palcu 

Hi,

This patchset adds initial DCSS support for iMX8MQ chip. Initial support
includes only graphics plane support (no video planes), no HDR10 capabilities,
no graphics decompression (only linear, tiled and super-tiled buffers allowed).

Support for the rest of the features will be added incrementally, in subsequent
patches.

The patchset was tested with both HDP driver (in the downstream tree) and the 
upstream
MIPI-DSI driver (with a couple of patches on top, to make it work correctly 
with DCSS).

Thanks,
Laurentiu

Changes in v7:
 * Added a patch to initialize the connector using the drm_bridge_connector
   API as Sam suggested. Tested it using NWL_DSI and ADV7535 with
   Guido's patch [1] applied and one fix for ADV [2]. Also, some extra
   patches for ADV and NWL were needed, from our downstream tree, which
   will be upstreamed soon by their author;
 * Rest of the patches are untouched;

[1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html
[2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html

Changes in v6:
 * Addressed Rob's comment and added "additionalProperties: false" at
   the end of the bindings' properties. However, this change surfaced
   an issue with the assigned-clock* properties not being documented in
   the properties section. Added the descriptions and the bindings patch
   will need another review;
 * Added an entry for DCSS driver in the MAINTAINERS file;
 * Removed the component framework patch altogether;

Changes in v5:
 * Rebased to latest;
 * Took out component framework support and made it a separate patch so
   that people can still test with HDP driver, which makes use of it.
   But the idea is to get rid of it once HDP driver's next versions
   will remove component framework as well;
 * Slight improvement to modesetting: avoid cutting off the pixel clock
   if the new mode and the old one are equal. Also, in this case, is
   not necessary to wait for DTG to shut off. This would allow to switch
   from 8b RGB to 12b YUV422, for example, with no interruptions (at least
   from DCSS point of view);
 * Do not fire off CTXLD when going to suspend, unless it still has
   entries that need to be committed to DCSS;
 * Addressed Rob's comments on bindings;

Changes in v4:
 * Addressed Lucas and Philipp's comments:
   * Added DRM_KMS_CMA_HELPER dependency in Kconfig;
   * Removed usage of devm_ functions since I'm already doing all the
 clean-up in the submodules_deinit();
   * Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush();
   * Removed en_completion variable from dcss_crtc since this was
 introduced mainly to avoid vblank timeout warnings which were fixed
 by arming the vblank event in flush() instead of begin();
   * Removed clks_on and irq_enabled flags since all the calls to
 enabling/disabling clocks and interrupts were balanced;
   * Removed the custom atomic_commit callback and used the DRM core
 helper and, in the process, got rid of a workqueue that wasn't
 necessary anymore;
   * Fixed some minor DT binding issues flagged by Philipp;
   * Some other minor changes suggested by Lucas;
 * Removed YUV formats from the supported formats as these cannot work
   without the HDR10 module CSCs and LUTs. Will add them back when I
   will add support for video planes;

Changes in v3:
 * rebased to latest linux-next and made it compile as drmP.h was
   removed;
 * removed the patch adding the VIDEO2_PLL clock. It's already applied;
 * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set();
 * fixed a a spurious hang reported by Lukas Hartmann and encountered
   by me several times;
 * mask DPR and DTG interrupts by default, as they may come enabled from
   U-boot;

Changes in v2:
 * Removed '0x' in node's unit-address both in DT and yaml;
 * Made the address region size lowercase, to be consistent;
 * Removed some left-over references to P010;
 * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence 
compilation
   issues reported by kbuild for other architectures;


Laurentiu Palcu (5):
  drm/imx: compile imx directory by default
  drm/imx: Add initial support for DCSS on iMX8MQ
  drm/imx/dcss: use drm_bridge_connector API
  MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
  dt-bindings: display: imx: add bindings for DCSS

 .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 +++
 MAINTAINERS   |   8 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/imx/Kconfig   |   2 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dcss/Kconfig  |   9 +
 drivers/gpu/drm/imx/dcss/Makefile |   6 +
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c|  70 ++
 drivers/gpu/drm/imx/dcss/dcss-crtc.c  | 219 +
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 +
 drivers/gpu/drm/imx/dcss/dcss-dev.c   | 325 +++
 

Re: [PATCH 11/11] drm/ttm: remove TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-21 Thread kernel test robot
Hi "Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20200720]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.8-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-remove-optional-dummy-function-from-drivers-using-TTM/20200721-153530
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=ia64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_gem_vram_helper.c: In function 'bo_driver_init_mem_type':
>> drivers/gpu/drm/drm_gem_vram_helper.c:1012:16: error: 
>> 'TTM_MEMTYPE_FLAG_MAPPABLE' undeclared (first use in this function); did you 
>> mean 'TTM_MEMTYPE_FLAG_FIXED'?
1012 |   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
 |^
 |TTM_MEMTYPE_FLAG_FIXED
   drivers/gpu/drm/drm_gem_vram_helper.c:1012:16: note: each undeclared 
identifier is reported only once for each function it appears in
   drivers/gpu/drm/drm_gem_vram_helper.c: In function 
'bo_driver_io_mem_reserve':
   drivers/gpu/drm/drm_gem_vram_helper.c:1065:21: error: 
'TTM_MEMTYPE_FLAG_MAPPABLE' undeclared (first use in this function); did you 
mean 'TTM_MEMTYPE_FLAG_FIXED'?
1065 |  if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
 | ^
 | TTM_MEMTYPE_FLAG_FIXED

vim +1012 drivers/gpu/drm/drm_gem_vram_helper.c

6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1006  
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1007  static int 
bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1008   
   struct ttm_mem_type_manager *man)
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1009  {
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1010   switch (type) {
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1011   case TTM_PL_SYSTEM:
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11 @1012   man->flags = 
TTM_MEMTYPE_FLAG_MAPPABLE;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1013   
man->available_caching = TTM_PL_MASK_CACHING;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1014   
man->default_caching = TTM_PL_FLAG_CACHED;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1015   break;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1016   case TTM_PL_VRAM:
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1017   man->func = 
_bo_manager_func;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1018   man->flags = 
TTM_MEMTYPE_FLAG_FIXED |
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1019
TTM_MEMTYPE_FLAG_MAPPABLE;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1020   
man->available_caching = TTM_PL_FLAG_UNCACHED |
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1021   
 TTM_PL_FLAG_WC;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1022   
man->default_caching = TTM_PL_FLAG_WC;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1023   break;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1024   default:
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1025   return -EINVAL;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1026   }
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1027   return 0;
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1028  }
6b5ce4a1fb8489 Thomas Zimmermann 2019-09-11  1029  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-21 Thread Daniel Vetter
On Tue, Jul 21, 2020 at 11:38 AM Thomas Hellström (Intel)
 wrote:
>
>
> On 7/21/20 10:55 AM, Christian König wrote:
> > Am 21.07.20 um 10:47 schrieb Thomas Hellström (Intel):
> >>
> >> On 7/21/20 9:45 AM, Christian König wrote:
> >>> Am 21.07.20 um 09:41 schrieb Daniel Vetter:
>  On Mon, Jul 20, 2020 at 01:15:17PM +0200, Thomas Hellström (Intel)
>  wrote:
> > Hi,
> >
> > On 7/9/20 2:33 PM, Daniel Vetter wrote:
> >> Comes up every few years, gets somewhat tedious to discuss, let's
> >> write this down once and for all.
> >>
> >> What I'm not sure about is whether the text should be more
> >> explicit in
> >> flat out mandating the amdkfd eviction fences for long running
> >> compute
> >> workloads or workloads where userspace fencing is allowed.
> > Although (in my humble opinion) it might be possible to completely
> > untangle
> > kernel-introduced fences for resource management and dma-fences
> > used for
> > completion- and dependency tracking and lift a lot of restrictions
> > for the
> > dma-fences, including prohibiting infinite ones, I think this
> > makes sense
> > describing the current state.
>  Yeah I think a future patch needs to type up how we want to make that
>  happen (for some cross driver consistency) and what needs to be
>  considered. Some of the necessary parts are already there (with
>  like the
>  preemption fences amdkfd has as an example), but I think some clear
>  docs
>  on what's required from both hw, drivers and userspace would be really
>  good.
> >>>
> >>> I'm currently writing that up, but probably still need a few days
> >>> for this.
> >>
> >> Great! I put down some (very) initial thoughts a couple of weeks ago
> >> building on eviction fences for various hardware complexity levels here:
> >>
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fthomash%2Fdocs%2F-%2Fblob%2Fmaster%2FUntangling%2520dma-fence%2520and%2520memory%2520allocation.odtdata=02%7C01%7Cchristian.koenig%40amd.com%7C8978bbd7823e4b41663708d82d52add3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309180424312390sdata=tTxx2vfzfwLM1IBJSqqAZRw1604R%2F0bI3MwN1%2FBf2VQ%3Dreserved=0
> >>
> >
> > I don't think that this will ever be possible.
> >
> > See that Daniel describes in his text is that indefinite fences are a
> > bad idea for memory management, and I think that this is a fixed fact.
> >
> > In other words the whole concept of submitting work to the kernel
> > which depends on some user space interaction doesn't work and never will.
>
> Well the idea here is that memory management will *never* depend on
> indefinite fences: As soon as someone waits on a memory manager fence
> (be it eviction, shrinker or mmu notifier) it breaks out of any
> dma-fence dependencies and /or user-space interaction. The text tries to
> describe what's required to be able to do that (save for non-preemptible
> gpus where someone submits a forever-running shader).

Yeah I think that part of your text is good to describe how to
untangle memory fences from synchronization fences given how much the
hw can do.

> So while I think this is possible (until someone comes up with a case
> where it wouldn't work of course), I guess Daniel has a point in that it
> won't happen because of inertia and there might be better options.

Yeah it's just I don't see much chance for splitting dma-fence itself.
That's also why I'm not positive on the "no hw preemption, only
scheduler" case: You still have a dma_fence for the batch itself,
which means still no userspace controlled synchronization or other
form of indefinite batches allowed. So not getting us any closer to
enabling the compute use cases people want. So minimally I think hw
needs to be able to preempt, and preempt fairly quickly (i.e. within
shaders if you have long running shaders as your use-case), or support
gpu page faults. And depending how it all works different parts of the
driver code end up in dma fence critical sections, with different
restrictions.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 08/11] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-21 Thread Chauhan, Madhav
[AMD Public Use]

-Original Message-
From: dan...@ffwll.ch  
Sent: Tuesday, July 21, 2020 2:58 PM
Cc: dri-devel@lists.freedesktop.org; Chauhan, Madhav ; 
michael.j.r...@intel.com; tzimmerm...@suse.de
Subject: Re: [PATCH 08/11] drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE

On Tue, Jul 21, 2020 at 09:32:42AM +0200, Christian König wrote:
> The driver does support some not-mapable resources, but those are 
> already handled correctly in the switch/case statement in the code.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 44fa8bc49d18..0dd5e802091d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -84,7 +84,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
> uint32_t type,
>   switch (type) {
>   case TTM_PL_SYSTEM:
>   /* System memory */
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
>   man->available_caching = TTM_PL_MASK_CACHING;
>   man->default_caching = TTM_PL_FLAG_CACHED;
>   break;
> @@ -93,13 +93,12 @@ static int amdgpu_init_mem_type(struct ttm_bo_device 
> *bdev, uint32_t type,
>   man->func = _gtt_mgr_func;
>   man->available_caching = TTM_PL_MASK_CACHING;
>   man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = 0;
>   break;
>   case TTM_PL_VRAM:
>   /* "On-card" video ram */
>   man->func = _vram_mgr_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> -  TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->flags = TTM_MEMTYPE_FLAG_FIXED;
>   man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
>   man->default_caching = TTM_PL_FLAG_WC;
>   break;
> @@ -796,7 +795,6 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
> bool evict,
>   */
>  static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
> struct ttm_mem_reg *mem)  {
> - struct ttm_mem_type_manager *man = >man[mem->mem_type];
>   struct amdgpu_device *adev = amdgpu_ttm_adev(bdev);
>   struct drm_mm_node *mm_node = mem->mm_node;
>  
> @@ -805,8 +803,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device 
> *bdev, struct ttm_mem_
>   mem->bus.size = mem->num_pages << PAGE_SHIFT;
>   mem->bus.base = 0;
>   mem->bus.is_iomem = false;
> - if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
> - return -EINVAL;

This check catches the various special on-board memories, or at least I 
couldnt' find where mmap for these is disallowed.

For various on board memories (GDS, GWS, OA). TTM_MEMTYPE_FLAG_MAPPABLE  is not 
added while initializing the BO manger.
Can you please elaborate??

Regards,
Madhav

-Daniel

> +
>   switch (mem->mem_type) {
>   case TTM_PL_SYSTEM:
>   /* system memory */
> --
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7C
> Madhav.Chauhan%40amd.com%7C38d9dcf0a17344b8fa9008d82d586405%7C3dd8961f
> e4884e608e11a82d994e183d%7C0%7C0%7C637309204946382107sdata=4gkueE
> gTCU%2FQBqZS%2BepCLjEp%2F%2FEn%2FmhJl6EjB5LCfsQ%3Dreserved=0

--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2Fdata=02%7C01%7CMadhav.Chauhan%40amd.com%7C38d9dcf0a17344b8fa9008d82d586405%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309204946382107sdata=g%2F4b4hJZZ3XehZmCVRi61GfCiGIwnJZT8nG%2Bb025o6k%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >