[PATCH v3 3/6] dt-bindings: Add panel-timing subnode to simple-panel

[Sean Paul]

This patch adds a new subnode to simple-panel allowing us to override
the typical timing expressed in the panel's display_timing.

Changes in v2:
 - Split out the binding into a new patch (Rob)
 - display-timings is a new section (Rob)
 - Use the full display-timings subnode instead of picking the timing
   out (Rob/Thierry)
Changes in v3:
 - Go back to using the timing subnode directly, but rename to
   panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 .../bindings/display/panel/simple-panel.txt| 30 ++
 1 file changed, 30 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 45a457ad38f0..7788b9ce160b 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -12,6 +12,24 @@ Optional properties:
 - enable-gpios: GPIO pin to enable or disable the panel
 - backlight: phandle of the backlight device attached to the panel
 
+panel-timing subnode
+
+
+This optional subnode is for devices which require a mode differing from the
+panel's "typical" display timing as programmed in the simple-panel driver.
+Overriding the driver mode must only be done in the following scenario:
+ - The restrictions motivating the override cannot be applied to the platform's
+   display driver (ie: it must be specific to the device not the platform)
+ - The panel must not have a fixed mode attributed to it in the driver
+ - The panel must provide at list one display_timing range by which the 
override
+   mode can be validated against
+ - The override mode will use the 'typ' values from the panel-timings subnode
+ - You must provide all required properties for the panel-timing subnode
+
+Format information on the panel-timing subnode can be found in
+display-timing.txt.
+
+
 Example:
 
panel: panel {
@@ -22,4 +40,16 @@ Example:
enable-gpios = < 90 0>;
 
backlight = <>;
+
+   panel-timing {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   };
};
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 4/6] drm/panel: simple: Add ability to override typical timing

[Sean Paul]

This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:

- panel must not specify fixed mode (since the override mode will
  either be the same as the fixed mode, or we'll be unable to
  check the bounds of the overried)
- panel must specify at least one display_timing range which will be
  used to ensure the override mode fits within its bounds

Changes in v2:
 - Parse the full display-timings node (using the native-mode) (Rob)
Changes in v3:
 - No longer parse display-timings subnode, use panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 67 +++-
 1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..87488392bca1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -34,6 +34,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct panel_desc {
@@ -87,6 +88,8 @@ struct panel_simple {
struct i2c_adapter *ddc;
 
struct gpio_desc *enable_gpio;
+
+   struct drm_display_mode override_mode;
 };
 
 static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -99,11 +102,22 @@ static int panel_simple_get_fixed_modes(struct 
panel_simple *panel)
struct drm_connector *connector = panel->base.connector;
struct drm_device *drm = panel->base.drm;
struct drm_display_mode *mode;
+   bool has_override = panel->override_mode.type;
unsigned int i, num = 0;
 
if (!panel->desc)
return 0;
 
+   if (has_override) {
+   mode = drm_mode_duplicate(drm, >override_mode);
+   if (mode) {
+   drm_mode_probed_add(connector, mode);
+   num++;
+   } else {
+   dev_err(drm->dev, "failed to add override mode\n");
+   }
+   }
+
for (i = 0; i < panel->desc->num_timings; i++) {
const struct display_timing *dt = >desc->timings[i];
struct videomode vm;
@@ -120,7 +134,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
 
mode->type |= DRM_MODE_TYPE_DRIVER;
 
-   if (panel->desc->num_timings == 1)
+   if (panel->desc->num_timings == 1 && !has_override)
mode->type |= DRM_MODE_TYPE_PREFERRED;
 
drm_mode_probed_add(connector, mode);
@@ -291,10 +305,58 @@ static const struct drm_panel_funcs panel_simple_funcs = {
.get_timings = panel_simple_get_timings,
 };
 
+#define PANEL_SIMPLE_BOUNDS_CHECK(to_check, bounds, field) \
+   (to_check->field.typ >= bounds->field.min && \
+to_check->field.typ <= bounds->field.max)
+static void panel_simple_add_override_mode(struct device *dev,
+  struct panel_simple *panel,
+  const struct display_timing *ot)
+{
+   const struct panel_desc *desc = panel->desc;
+   struct videomode vm;
+   int i;
+
+   if (desc->num_modes) {
+   dev_err(dev, "Reject override mode: panel has a fixed mode\n");
+   return;
+   }
+   if (!desc->num_timings) {
+   dev_err(dev, "Reject override mode: no timings specified\n");
+   return;
+   }
+
+   for (i = 0; i < panel->desc->num_timings; i++) {
+   const struct display_timing *dt = >desc->timings[i];
+
+   if (!PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, hsync_len) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vactive) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vfront_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vback_porch) ||
+   !PANEL_SIMPLE_BOUNDS_CHECK(ot, dt, vsync_len))
+   continue;
+
+   if (ot->flags != dt->flags)
+   continue;
+
+   videomode_from_timing(ot, );
+   drm_display_mode_from_videomode(, >override_mode);
+   panel->override_mode.type |= 

[PATCH v3 0/6] drm/panel: simple: Add mode support to devicetree

[Sean Paul]

Hello!

Here's v3 of the set. I've reintroduced the single display timing node
in the dt binding from v1, and left the improved docs and patch split
from v2. I've also added a patch to clarify that a single display timing
node should always be named panel-timing, which was feedback from v1.

Cover letter from v1 (was the same in v2) is here:
https://lists.freedesktop.org/archives/dri-devel/2018-February/164886.html

Thanks for the reviews so far,

Sean


Sean Paul (6):
  dt-bindings: Clarify timing subnode use as panel-timing
  dt-bindings: Add headings to simple-panel bindings
  dt-bindings: Add panel-timing subnode to simple-panel
  drm/panel: simple: Add ability to override typical timing
  drm/panel: simple: Use display_timing for lq123p1jx31
  arm64: dts: rockchip: Specify override mode for kevin panel

 .../bindings/display/panel/display-timing.txt  |  5 ++
 .../bindings/display/panel/simple-panel.txt| 34 
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  | 14 
 drivers/gpu/drm/panel/panel-simple.c   | 94 ++
 4 files changed, 132 insertions(+), 15 deletions(-)

-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 5/6] drm/panel: simple: Use display_timing for lq123p1jx31

[Sean Paul]

Convert the sharp lq123p1jx31 from using a fixed mode to specifying a
display timing with min/typ/max values. This allows us to capture the
timings set forth in the datasheet as well as the additional values that
we've cleared with the display vendor to avoid interference with the
digitizer on the Samsung Chromebook Plus (kevin).

A follow-on patch will specify the override mode for kevin devices.

Changes in v2:
 - None
Changes in v3:
 - None

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 87488392bca1..6de9c39bc182 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1806,23 +1806,22 @@ static const struct panel_desc sharp_lq101k1ly04 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
 };
 
-static const struct drm_display_mode sharp_lq123p1jx31_mode = {
-   .clock = 252750,
-   .hdisplay = 2400,
-   .hsync_start = 2400 + 48,
-   .hsync_end = 2400 + 48 + 32,
-   .htotal = 2400 + 48 + 32 + 80,
-   .vdisplay = 1600,
-   .vsync_start = 1600 + 3,
-   .vsync_end = 1600 + 3 + 10,
-   .vtotal = 1600 + 3 + 10 + 33,
-   .vrefresh = 60,
-   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+static const struct display_timing sharp_lq123p1jx31_timing = {
+   .pixelclock = { 25275, 25275, 266604720 },
+   .hactive = { 2400, 2400, 2400 },
+   .hfront_porch = { 48, 48, 48 },
+   .hback_porch = { 80, 80, 84 },
+   .hsync_len = { 32, 32, 32 },
+   .vactive = { 1600, 1600, 1600 },
+   .vfront_porch = { 3, 3, 3 },
+   .vback_porch = { 33, 33, 120 },
+   .vsync_len = { 10, 10, 10 },
+   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
 };
 
 static const struct panel_desc sharp_lq123p1jx31 = {
-   .modes = _lq123p1jx31_mode,
-   .num_modes = 1,
+   .timings = _lq123p1jx31_timing,
+   .num_timings = 1,
.bpc = 8,
.size = {
.width = 259,
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 1/6] dt-bindings: Clarify timing subnode use as panel-timing

[Sean Paul]

Add a note in the documentation explaining when it's appropriate to use
the display-timings subnode on its own, as well as the preferred name to
use (panel-timing).

Changes in v3:
 - Added

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 Documentation/devicetree/bindings/display/panel/display-timing.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt 
b/Documentation/devicetree/bindings/display/panel/display-timing.txt
index 58fa3e48481d..78222ced1874 100644
--- a/Documentation/devicetree/bindings/display/panel/display-timing.txt
+++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt
@@ -80,6 +80,11 @@ The parameters are defined as:
   |  |v|  |   |
   +--+-+--+---+
 
+Note: In addition to being used as subnode(s) of display-timings, the timing
+  subnode may also be used on its own. This is appropriate if only one mode
+  need be conveyed. In this case, the node should be named 'panel-timing'.
+
+
 Example:
 
display-timings {
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

[Sean Paul]

This patch adds an override mode for kevin devices. The mode increases
both back porches to allow a pixel clock of 2kHz as opposed to the
'typical' value of 252750kHz. This is needed to avoid interference with
the touch digitizer on these laptops.

Changes in v2:
 - Wrap the timing in display-timings node to match binding (Rob/Thierry)
Changes in v3:
 - Unwrap the timing from display-timings and rename panel-timing (Rob)

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 191a6bcb1704..658411ce37ea 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -98,6 +98,20 @@
backlight = <>;
power-supply = <_disp>;
 
+   panel-timing {
+   clock-frequency = <266604720>;
+   hactive = <2400>;
+   hfront-porch = <48>;
+   hback-porch = <84>;
+   hsync-len = <32>;
+   hsync-active = <0>;
+   vactive = <1600>;
+   vfront-porch = <3>;
+   vback-porch = <120>;
+   vsync-len = <10>;
+   vsync-active = <0>;
+   };
+
ports {
panel_in_edp: endpoint {
remote-endpoint = <_out_panel>;
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 2/6] dt-bindings: Add headings to simple-panel bindings

[Sean Paul]

In preparation for a new subnode section in a follow-on patch, add
explicit headings to the existings sections for simple-panel.

Changes in v2:
 - Added
Changes in v3:
 - None

Cc: Doug Anderson 
Cc: Eric Anholt 
Cc: Heiko Stuebner 
Cc: Jeffy Chen 
Cc: Rob Herring 
Cc: Stéphane Marchesin 
Cc: Thierry Reding 
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-rockc...@lists.infradead.org
Signed-off-by: Sean Paul 
---
 Documentation/devicetree/bindings/display/panel/simple-panel.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt 
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index 16d8ff088b7d..45a457ad38f0 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -1,4 +1,8 @@
 Simple display panel
+
+
+panel node
+--
 
 Required properties:
 - power-supply: See panel-common.txt
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH] drm_fb_cma_helper: Delete an error message for a failed memory allocation in drm_fbdev_cma_init_with_funcs()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 19:30:06 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..59f0d8dbfa61 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -408,10 +408,9 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
int ret;
 
fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
-   if (!fbdev_cma) {
-   dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
+   if (!fbdev_cma)
return ERR_PTR(-ENOMEM);
-   }
+
fbdev_cma->fb_funcs = funcs;
 
helper = _cma->fb_helper;
-- 
2.16.1

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

Re: [PATCH v3 3/6] dt-bindings: Add panel-timing subnode to simple-panel

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> This patch adds a new subnode to simple-panel allowing us to override
> the typical timing expressed in the panel's display_timing.
>
> Changes in v2:
>  - Split out the binding into a new patch (Rob)
>  - display-timings is a new section (Rob)
>  - Use the full display-timings subnode instead of picking the timing
>out (Rob/Thierry)
> Changes in v3:
>  - Go back to using the timing subnode directly, but rename to
>panel-timing (Rob)
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  .../bindings/display/panel/simple-panel.txt| 30 
> ++
>  1 file changed, 30 insertions(+)

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

Re: -EPROBE_DEFER and failed DSI panel probe

[Boris Brezillon]

+Thierry and Archit for the drm_panel/panel_bridge bits.

Hi all,

I'm resurrecting this thread because Eric asked me to find a solution
to this problem :-).

On Mon, 20 Nov 2017 08:53:05 +0100
Andrzej Hajda  wrote:

> On 18.11.2017 02:16, Eric Anholt wrote:
> > Andrzej Hajda  writes:
> >  
> >> On 16.11.2017 21:27, Eric Anholt wrote:  
> >>> Andrzej Hajda  writes:
> >>>  
>  On 15.11.2017 21:26, Eric Anholt wrote:  
> > I'm happy to have the DSI panel finally working on VC4 (just waiting on
> > https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
> > but now I've got another problem to solve.  It would be great if I could
> > include the DSI panel in our upstream DT, so that it automatically
> > worked when you plugged one in.  However, right now we return
> > -EPROBE_DEFER during bind unless the panel has actually shown up.  This
> > means that if you don't have the panel actually connected, you get this
> > sequence at startup:
> >
> > [   10.719929] [drm] Initialized
> > [   10.829510] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi 
> > mapping ok
> > [   10.844043] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> > [vc4])
> > [   10.848626] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops 
> > [vc4])
> > [   10.850214] vc4-drm soc:gpu: failed to bind 3f70.dsi (ops 
> > vc4_dsi_ops [vc4]): -517
> > [   10.856559] vc4-drm soc:gpu: master bind failed: -517
> >
> > [...]
> >
> > [   10.967718] rpi_touchscreen 3-0045: Atmel I2C read failed: -6
> >
> > Once the panel driver fails to probe, we never get asked to re-bind vc4,
> > and drm_of_find_panel_or_bridge looks like it would just give us
> > -EPROBE_DEFER again since the panel still wasn't registered.

Well, that's not surprising since I2C is not an hotplug-friendly bus.
So, if you declare a device in the DT, and this device is not accessible
(returns I2C errors), that means there's no device at all, and there's
no reason for the I2C core to retry later.

> >
> > Does anyone have any suggestions for handling this?  
>  I guess you should call component_add only when all required resources
>  are present(including panel), I suppose moving it to vc4_dsi_host_attach
>  should help.  
> >>> How can I decide when the panel driver has tried to probe and failed,
> >>> versus not tried to probe yet?  find_panel_or_bridge gives me
> >>> -EPROBE_DEFER either way.

We could have a fake/dummy panel object that is registered to the
panel list when we know the device will never be available (because
it's simply not connected to the control bus). This way, instead of
-EPROBE_DEFER, the drm_panel layer could return -ENODEV. But still,
this alone won't solve your problem, because, AFAICT, the way the VC4
dev registration work is: "bind all components of the display pipeline,
and if there's one missing, do not register the DRM device". So, you'd
have to change that for: "only wait for mandatory elements", and then
declare the DSI panel as optional (don't know how to encode that in
the DT).

> >>>  
>  On the other side I am curious why EPROBE_DEFER from bind does not fail
>  probing of some component (the last one probed), with proper error
>  propagation it should cause defer_probing of one of the components or
>  master, and probe/bind should be retried after panel's probe.  
> >>> The panel probe failed, though, so there's no trigger to re-probe other
> >>> drivers.  
> >> OK, I misunderstood your problem. And after 2nd read I am not sure what
> >> do you want to achieve exactly?
> >>
> >> Do you want to 'hotplug' DSI panel? Or just make it working with and
> >> without the panel. In 2nd case other paths (HDMI) should still work, I
> >> guess.  
> > Yeah, the second thing.  I would like to use a single DT to describe a
> > platform where the panel may or may not be present, so the panel driver
> > (panel-raspberrypi-touchscreen.c) will throw an error from the I2C part
> > of the probe or not instead of creating the DSI device and attaching the
> > panel.
> >  
> >> Lets assume that you are interested in the latter case. There could be
> >> multiple solutions more or less hacky:
> >>
> >> 1. Use connector's HPD infrastructure to signal presence of the panel,
> >> ie. in mipi_dsi::host_(attach|detach) callback you grab the panel and
> >> change connector status to connected|disconnected and calls
> >> drm_kms_helper_hotplug_event, it is done this way in 
> >> exynos_dsi_host_attach.  
> > This is basically what I had before all the review reworks, and the
> > regression from this state is keeping me from merging the current driver
> > downstream.
> >
> > This option is unfortunate because we'll have forced *some* output on at
> > boot time, and then when the panel driver shows up later we don't resize
> > the 

[PATCH 7/8] drm/msm/adreno: Add ringbuffer data to the GPU state

[Jordan Crouse]

Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt |  5 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 40 
 drivers/gpu/drm/msm/msm_gpu.h|  2 ++
 3 files changed, 47 insertions(+)

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
index ec56640..3f54b44 100644
--- a/Documentation/gpu/drm-msm-crash-dump.txt
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -22,6 +22,11 @@ ringbuffer:   # Ringbuffer data. There will be a sequence 
for each ringbuffer
retired-fence:  # [decimal] THe last fence retired on the ring
rptr:   # [decimal] The current read pointer (rptr) for the ring
wptr:   # [decimal] The current write pointer (wptr) for the ring
+   size:   # [decimal] The maximum size of the ring programmed in the
+   # hardware
+   data:   # [ascii85] The contents of the ring encoded as ascii85.
+  # Only the unused portions of the ring will be printed (up
+   # to a maximum of 'size' bytes
 registers:# Sets of register values. This section can be used multiple
   # times for different ranges of registers. Each register will be
   # on its own line.
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 920db2e..e9b7b36 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,6 +17,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 #include "adreno_gpu.h"
 #include "msm_gem.h"
@@ -397,10 +398,29 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
+   int size = 0, j;
+
state->ring[i].fence = gpu->rb[i]->memptrs->fence;
state->ring[i].seqno = gpu->rb[i]->seqno;
state->ring[i].rptr = get_rptr(adreno_gpu, gpu->rb[i]);
state->ring[i].wptr = get_wptr(gpu->rb[i]);
+
+   /*
+* Only copy used parts of the ring buffers (this should save
+* data size for lightly used rings)
+*/
+   for(j = 0; j < MSM_GPU_RINGBUFFER_SZ >> 2; j++)
+   if (gpu->rb[i]->start[j])
+   size = j;
+
+   if (size) {
+   state->ring[i].data = kmalloc((size + 1) << 2, 
GFP_KERNEL);
+   if (state->ring[i].data) {
+   memcpy(state->ring[i].data, gpu->rb[i]->start,
+   (size + 1) << 2);
+   state->ring[i].data_size = (size + 1) << 2;
+   }
+   }
}
 
/* Count the number of registers */
@@ -431,9 +451,13 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
 
 static void adreno_gpu_state_destroy(struct kref *kref)
 {
+   int i;
struct msm_gpu_state *state = container_of(kref,
struct msm_gpu_state, ref);
 
+   for(i = 0; i < ARRAY_SIZE(state->ring); i++)
+   kfree(state->ring[i].data);
+
kfree(state->comm);
kfree(state->cmd);
kfree(state->registers);
@@ -473,6 +497,22 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state 
*state,
drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
+   drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
+
+   if (state->ring[i].data && state->ring[i].data_size) {
+   u32 *ptr = (u32 *) state->ring[i].data;
+   char out[ASCII85_BUFSZ];
+   long len = ascii85_encode_len(state->ring[i].data_size);
+   int j;
+
+   drm_printf(p, "data: !!ascii85 |\n");
+   drm_printf(p, " ");
+
+   for(j = 0; j < len; j++)
+   drm_printf(p, ascii85_encode(ptr[j], out));
+
+   drm_printf(p, "\n");
+   }
}
 
drm_printf(p, "registers:\n");
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index e65f507..48f7b21 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -190,6 +190,8 @@ struct msm_gpu_state {
u32 seqno;
u32 rptr;
u32 wptr;
+   void *data;
+   int data_size;
} 

[PATCH] drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 18:42:51 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 2b8bf2dd6387..5eb0d3292525 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -286,7 +286,6 @@ static int g2d_init_cmdlist(struct g2d_data *g2d)
 
node = kcalloc(G2D_CMDLIST_NUM, sizeof(*node), GFP_KERNEL);
if (!node) {
-   dev_err(dev, "failed to allocate memory\n");
ret = -ENOMEM;
goto err;
}
@@ -1358,10 +1357,9 @@ int exynos_g2d_exec_ioctl(struct drm_device *drm_dev, 
void *data,
return -EFAULT;
 
runqueue_node = kmem_cache_alloc(g2d->runqueue_slab, GFP_KERNEL);
-   if (!runqueue_node) {
-   dev_err(dev, "failed to allocate memory\n");
+   if (!runqueue_node)
return -ENOMEM;
-   }
+
run_cmdlist = _node->run_cmdlist;
event_list = _node->event_list;
INIT_LIST_HEAD(run_cmdlist);
-- 
2.16.1

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

[PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Jordan Crouse]

The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.

[v2 - Update the API to be cleaner for the caller suggested by
Chris Wilson]

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 38 ++
 include/linux/ascii85.h   | 39 +++
 2 files changed, 45 insertions(+), 32 deletions(-)
 create mode 100644 include/linux/ascii85.h

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9440593..8bc72c7 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_drv.h"
 
@@ -502,35 +503,12 @@ void i915_error_printf(struct drm_i915_error_state_buf 
*e, const char *f, ...)
va_end(args);
 }
 
-static int
-ascii85_encode_len(int len)
-{
-   return DIV_ROUND_UP(len, 4);
-}
-
-static bool
-ascii85_encode(u32 in, char *out)
-{
-   int i;
-
-   if (in == 0)
-   return false;
-
-   out[5] = '\0';
-   for (i = 5; i--; ) {
-   out[i] = '!' + in % 85;
-   in /= 85;
-   }
-
-   return true;
-}
-
 static void print_error_obj(struct drm_i915_error_state_buf *m,
struct intel_engine_cs *engine,
const char *name,
struct drm_i915_error_object *obj)
 {
-   char out[6];
+   char out[ASCII85_BUFSZ];
int page;
 
if (!obj)
@@ -545,19 +523,15 @@ static void print_error_obj(struct 
drm_i915_error_state_buf *m,
 
err_compression_marker(m);
for (page = 0; page < obj->page_count; page++) {
-   int i, len;
+   int i;
+   long len = PAGE_SIZE;
 
-   len = PAGE_SIZE;
if (page == obj->page_count - 1)
len -= obj->unused;
len = ascii85_encode_len(len);
 
-   for (i = 0; i < len; i++) {
-   if (ascii85_encode(obj->pages[page][i], out))
-   err_puts(m, out);
-   else
-   err_puts(m, "z");
-   }
+   for (i = 0; i < len; i++)
+   error_puts(m, ascii85_encode(obj->pages[page][i], out));
}
err_puts(m, "\n");
 }
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
new file mode 100644
index 000..322bbed
--- /dev/null
+++ b/include/linux/ascii85.h
@@ -0,0 +1,39 @@
+
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (c) 2008 Intel Corporation
+ * Copyright (c) The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _ASCII85_H_
+#define _ASCII85_H_
+
+#include 
+
+#define ASCII85_BUFSZ 6
+
+static inline long
+ascii85_encode_len(long len)
+{
+   return DIV_ROUND_UP(len, 4);
+}
+
+static inline char *
+ascii85_encode(u32 in, char *out)
+{
+   int i;
+
+   if (in == 0)
+   return "z";
+
+   out[5] = '\0';
+   for (i = 5; i--; ) {
+   out[i] = '!' + in % 85;
+   in /= 85;
+   }
+
+   return out;
+}
+
+#endif
-- 
1.9.1

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

Re: [PATCH v3 2/6] dt-bindings: Add headings to simple-panel bindings

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> In preparation for a new subnode section in a follow-on patch, add
> explicit headings to the existings sections for simple-panel.
>
> Changes in v2:
>  - Added
> Changes in v3:
>  - None
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  Documentation/devicetree/bindings/display/panel/simple-panel.txt | 4 
>  1 file changed, 4 insertions(+)

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

[PATCH 5/8] drm/msm/gpu: Capture the GPU state on a GPU hang

[Jordan Crouse]

Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be captured on the next hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Kconfig |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  34 +++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   4 +-
 drivers/gpu/drm/msm/msm_debugfs.c   |   7 ++-
 drivers/gpu/drm/msm/msm_gpu.c   | 103 +---
 drivers/gpu/drm/msm/msm_gpu.h   |  38 +++-
 6 files changed, 161 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 38cbde9..843a9d4 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -12,6 +12,7 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
+   select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index af776f1..e86238ce 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -392,6 +392,8 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
if (!state)
return ERR_PTR(-ENOMEM);
 
+   kref_init(>ref);
+
do_gettimeofday(>time);
 
for (i = 0; i < gpu->nr_rings; i++) {
@@ -427,18 +429,28 @@ struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu 
*gpu)
return state;
 }
 
-void adreno_gpu_state_put(struct msm_gpu_state *state)
+static void adreno_gpu_state_destroy(struct kref *kref)
 {
-   if (IS_ERR_OR_NULL(state))
-   return;
+   struct msm_gpu_state *state = container_of(kref,
+   struct msm_gpu_state, ref);
 
+   kfree(state->comm);
+   kfree(state->cmd);
kfree(state->registers);
kfree(state);
 }
 
+int adreno_gpu_state_put(struct msm_gpu_state *state)
+{
+   if (IS_ERR_OR_NULL(state))
+   return 1;
+
+   return kref_put(>ref, adreno_gpu_state_destroy);
+}
+
 #ifdef CONFIG_DEBUG_FS
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m)
+   struct drm_printer *p)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
@@ -446,23 +458,23 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   seq_printf(m, "status:   %08x\n", state->rbbm_status);
-   seq_printf(m, "revision: %d (%d.%d.%d.%d)\n",
+   drm_printf(p, "status:   %08x\n", state->rbbm_status);
+   drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
for (i = 0; i < gpu->nr_rings; i++) {
-   seq_printf(m, "rb %d: fence:%d/%d\n", i,
+   drm_printf(p, "rb %d: fence:%d/%d\n", i,
state->ring[i].fence, state->ring[i].seqno);
 
-   seq_printf(m, "  rptr: %d\n", state->ring[i].rptr);
-   seq_printf(m, "rb wptr:  %d\n", state->ring[i].wptr);
+   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
}
 
-   seq_printf(m, "IO:region %s  0002\n", gpu->name);
+   drm_printf(p, "IO:region %s  0002\n", gpu->name);
for (i = 0; i < state->nr_registers; i++) {
-   seq_printf(m, "IO:R %08x %08x\n",
+   drm_printf(p, "IO:R %08x %08x\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 815ae98..077bf11 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -216,7 +216,7 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 bool adreno_idle(struct msm_gpu *gpu, struct msm_ringbuffer *ring);
 #ifdef CONFIG_DEBUG_FS
 void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
-   struct seq_file *m);
+   struct drm_printer *p);
 #endif
 void adreno_dump_info(struct msm_gpu *gpu);
 void adreno_dump(struct msm_gpu *gpu);
@@ -229,7 +229,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 void adreno_gpu_cleanup(struct adreno_gpu *gpu);
 
 struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu);
-void 

[PATCH 8/8] drm/msm/adreno: Add a5xx specific registers for the GPU state

[Jordan Crouse]

HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture.  Add a5xx specific code
to program the crashdumper and retrieve the wayward registers
and dump them for the crash state.

Also, remove a block of registers the regular CPU accessible
list that aren't useful for debug which helps reduce the size
of the crash state file by a goodly amount.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   8 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   8 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 235 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  23 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   4 +-
 5 files changed, 247 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 4b9284a..6dd2b13 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -420,10 +420,12 @@ static void a3xx_dump(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index b8dcbb1..093ca30 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -456,10 +456,12 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
 
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
-   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+   struct msm_gpu_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
 
-   if (IS_ERR(state))
-   return state;
+   if (!state)
+   return ERR_PTR(-ENOMEM);
+
+   adreno_gpu_state_get(gpu, state);
 
state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b0910bb..764407c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "msm_gem.h"
 #include "msm_mmu.h"
 #include "a5xx_gpu.h"
@@ -1123,8 +1124,9 @@ static irqreturn_t a5xx_irq(struct msm_gpu *gpu)
0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
-   0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
-   0xB9A0, 0xB9BF, ~0
+   0xEAA5, 0xEAC2, 0xA800, 0xA800, 0xA820, 0xA828, 0xA840, 0xA87D,
+   0XA880, 0xA88D, 0xA890, 0xA8A3, 0xA8D0, 0xA8D8, 0xA8E0, 0xA8F5,
+   0xAC60, 0xAC60, ~0,
 };
 
 static void a5xx_dump(struct msm_gpu *gpu)
@@ -1195,24 +1197,231 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+struct a5xx_crashdumper {
+   void *ptr;
+   struct drm_gem_object *bo;
+   u64 iova;
+};
+
+struct a5xx_gpu_state {
+   struct msm_gpu_state base;
+   u32 *hlsqregs;
+};
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+   readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+   interval, timeout)
+
+static int a5xx_crashdumper_init(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   dumper->ptr = msm_gem_kernel_new_locked(gpu->dev,
+   SZ_1M, MSM_BO_UNCACHED, gpu->aspace,
+   >bo, >iova);
+
+   if (IS_ERR(dumper->ptr))
+   return PTR_ERR(dumper->ptr);
+
+   return 0;
+}
+
+static void a5xx_crashdumper_free(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   msm_gem_put_iova(dumper->bo, gpu->aspace);
+   msm_gem_put_vaddr(dumper->bo);
+
+   drm_gem_object_unreference(dumper->bo);
+}
+
+static int a5xx_crashdumper_run(struct msm_gpu *gpu,
+   struct a5xx_crashdumper *dumper)
+{
+   u32 val;
+
+   if (IS_ERR_OR_NULL(dumper->ptr))
+   return -EINVAL;
+
+   gpu_write64(gpu, REG_A5XX_CP_CRASH_SCRIPT_BASE_LO,
+   REG_A5XX_CP_CRASH_SCRIPT_BASE_HI, dumper->iova);
+
+   gpu_write(gpu, REG_A5XX_CP_CRASH_DUMP_CNTL, 1);
+
+   return gpu_poll_timeout(gpu, REG_A5XX_CP_CRASH_DUMP_CNTL, val,
+   val & 0x04, 100, 1);
+}
+
+/*
+ * These are a list 

[PATCH 3/8] drm/msm/gpu: Capture the state of the GPU

[Jordan Crouse]

Add the infrastructure to capture the state current state of the
GPU and store it in memory. This is useful for storing the state
of a hung GPU so it can be dumped later.

For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this can
be extended to capture a much larger set of GPU information.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 15 +
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 14 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 22 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 19 
 6 files changed, 127 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 1dd84d3..c351292 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -426,6 +426,19 @@ static void a3xx_dump(struct msm_gpu *gpu)
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
adreno_dump(gpu);
 }
+
+static struct msm_gpu_state *a3xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A3XX */
 static const unsigned int a3xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_AXXX_CP_RB_BASE),
@@ -452,6 +465,8 @@ static void a3xx_dump(struct msm_gpu *gpu)
 #ifdef CONFIG_DEBUG_FS
.show = a3xx_show,
 #endif
+   .gpu_state_get = a3xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
 };
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 2884b1b..faf5d60 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -464,6 +464,18 @@ static void a4xx_show(struct msm_gpu *gpu, struct seq_file 
*m)
 }
 #endif
 
+static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
+
+   if (IS_ERR(state))
+   return state;
+
+   state->rbbm_status = gpu_read(gpu, REG_A4XX_RBBM_STATUS);
+
+   return state;
+}
+
 /* Register offset defines for A4XX, in order of enum adreno_regs */
 static const unsigned int a4xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_BASE, REG_A4XX_CP_RB_BASE),
@@ -540,6 +552,8 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
 #ifdef CONFIG_DEBUG_FS
.show = a4xx_show,
 #endif
+   .gpu_state_get = a4xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a4xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a4f68af..08f2579 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1195,6 +1195,26 @@ static int a5xx_get_timestamp(struct msm_gpu *gpu, 
uint64_t *value)
return 0;
 }
 
+static struct msm_gpu_state *a5xx_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct msm_gpu_state *state;
+
+   /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+   a5xx_set_hwcg(gpu, false);
+
+   state = adreno_gpu_state_get(gpu);
+
+   if (!IS_ERR(state))
+   state->rbbm_status = gpu_read(gpu, REG_A5XX_RBBM_STATUS);
+
+   a5xx_set_hwcg(gpu, true);
+
+   return state;
+}
+
 #ifdef CONFIG_DEBUG_FS
 static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
 {
@@ -1244,6 +1264,8 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
*value)
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
+   .gpu_state_get = a5xx_gpu_state_get,
+   .gpu_state_put = adreno_gpu_state_put,
},
.get_timestamp = a5xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 87133c6c..35b77f0 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -382,6 +382,60 @@ bool adreno_idle(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
return false;
 }
 
+struct msm_gpu_state *adreno_gpu_state_get(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct msm_gpu_state *state;
+   int i, count = 0;
+
+   state = kzalloc(sizeof(*state), GFP_KERNEL);
+   if (!state)
+   return 

[PATCH 6/8] drm/msm/adreno: Convert the show/crash file format

[Jordan Crouse]

Convert the format of the 'show' debugfs file and the crash
dump to a  format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.

Signed-off-by: Jordan Crouse 
---
 Documentation/gpu/drm-msm-crash-dump.txt | 29 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 23 ++-
 2 files changed, 43 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt

diff --git a/Documentation/gpu/drm-msm-crash-dump.txt 
b/Documentation/gpu/drm-msm-crash-dump.txt
new file mode 100644
index 000..ec56640
--- /dev/null
+++ b/Documentation/gpu/drm-msm-crash-dump.txt
@@ -0,0 +1,29 @@
+# drm/msm GPU crash dump format
+#
+# This is a description of the format of the drm/msm GPU crash dump format that
+# can be read from /sys/kernel/dri/X/show or from devcoredump following a GPU
+# hang or fault
+
+---
+kernel:   # [string] The kernel version as printed by UTS_RELEASE
+module:   # [string] The module that generated the crash dump
+time: # [seconds.microseconds] The kernel time at crash
+comm: # [string] comm string for the binary that generated the fault
+  # (if known)
+cmdline:  # [string] the cmdline for the binary that generated the fault
+  # (if known)
+revision: # [ id core.major.minor.patchlevel] The GPU id followed by the
+  # individual components of the id separated by dots
+rbbm-status:  # [hex] The current value of RBBM_STATUS which shows what GPU
+  # components were in use at the time of the crash
+ringbuffer:   # Ringbuffer data. There will be a sequence for each ringbuffer
+  -id: # [decimal] Ringbuffer identifier (0 based index)
+   last-fence: # [decimal] The last fence issued on the ring
+   retired-fence:  # [decimal] THe last fence retired on the ring
+   rptr:   # [decimal] The current read pointer (rptr) for the ring
+   wptr:   # [decimal] The current write pointer (wptr) for the ring
+registers:# Sets of register values. This section can be used multiple
+  # times for different ranges of registers. Each register will be
+  # on its own line.
+  - [offset, value] # offset: [hex] byte offset of the register
+# value: [hex] value of the register
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index e86238ce..920db2e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -458,23 +458,28 @@ void adreno_show(struct msm_gpu *gpu, struct 
msm_gpu_state *state,
if (IS_ERR_OR_NULL(state))
return;
 
-   drm_printf(p, "status:   %08x\n", state->rbbm_status);
drm_printf(p, "revision: %d (%d.%d.%d.%d)\n",
adreno_gpu->info->revn, adreno_gpu->rev.core,
adreno_gpu->rev.major, adreno_gpu->rev.minor,
adreno_gpu->rev.patchid);
 
-   for (i = 0; i < gpu->nr_rings; i++) {
-   drm_printf(p, "rb %d: fence:%d/%d\n", i,
-   state->ring[i].fence, state->ring[i].seqno);
+   drm_printf(p, "rbbm-status: 0x%08x\n", state->rbbm_status);
+
+   drm_printf(p, "ringbuffer:\n");
 
-   drm_printf(p, "  rptr: %d\n", state->ring[i].rptr);
-   drm_printf(p, "rb wptr:  %d\n", state->ring[i].wptr);
+   for (i = 0; i < gpu->nr_rings; i++) {
+   drm_printf(p, "  - id: %d\n", i);
+   drm_printf(p, "last-fence: %d\n", state->ring[i].seqno);
+   drm_printf(p, "retired-fence: %d\n", state->ring[i].fence);
+   drm_printf(p, "rptr: %d\n", state->ring[i].rptr);
+   drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
}
 
-   drm_printf(p, "IO:region %s  0002\n", gpu->name);
-   for (i = 0; i < state->nr_registers; i++) {
-   drm_printf(p, "IO:R %08x %08x\n",
+   drm_printf(p, "registers:\n");
+   drm_printf(p, "  - [offset, value]\n");
+
+   for(i = 0; i < state->nr_registers; i++) {
+   drm_printf(p, "  - [0x%04x, 0x%08x]\n",
state->registers[i * 2] << 2,
state->registers[(i * 2) + 1]);
}
-- 
1.9.1

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

[PATCH 2/8] drm: drm_printer: Add printer for devcoredump

[Jordan Crouse]

Add a drm printer suitable for use with the read callback for
devcoredump or any other file operation read() function that
isn't otherwise covered by seq_file.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/drm_print.c | 54 +
 include/drm/drm_print.h | 27 +++
 2 files changed, 81 insertions(+)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518f..f6efde4 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -30,6 +30,60 @@
 #include 
 #include 
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
+{
+   struct drm_print_iterator *iterator = p->arg;
+
+   ssize_t len;
+
+   if (!iterator->remain)
+   return;
+
+   if (iterator->offset < iterator->start) {
+   char *buf;
+   ssize_t copy;
+
+   /* Figure out how big the string will be */
+   len = snprintf(NULL, 0, "%pV", vaf);
+
+   if (iterator->offset + len <= iterator->start) {
+   iterator->offset += len;
+   return;
+   }
+
+   /* Print the string into a temporary buffer */
+   buf = kmalloc(len + 1,
+   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   if (!buf)
+   return;
+
+   snprintf(buf, len + 1, "%pV", vaf);
+
+   copy = len - (iterator->start - iterator->offset);
+
+   if (copy > iterator->remain)
+   copy = iterator->remain;
+
+   /* Copy out the bit of the string that we need */
+   memcpy(iterator->data,
+   buf + (iterator->start - iterator->offset), copy);
+
+   iterator->offset = iterator->start + copy;
+   iterator->remain -= copy;
+
+   kfree(buf);
+   } else {
+   ssize_t pos = iterator->offset - iterator->start;
+
+   len = scnprintf(((char *) iterator->data) + pos,
+   iterator->remain, "%pV", vaf);
+
+   iterator->offset += len;
+   iterator->remain -= len;
+   }
+}
+EXPORT_SYMBOL(__drm_printfn_coredump);
+
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf)
 {
seq_printf(p->arg, "%pV", vaf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e..29eee51 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -73,6 +73,7 @@ struct drm_printer {
const char *prefix;
 };
 
+void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_debug(struct drm_printer *p, struct va_format *vaf);
@@ -104,6 +105,32 @@ struct drm_printer {
 #define drm_printf_indent(printer, indent, fmt, ...) \
drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", 
##__VA_ARGS__)
 
+struct drm_print_iterator {
+   void *data;
+
+   ssize_t start;
+   ssize_t offset;
+   ssize_t remain;
+};
+
+/**
+ * drm_coredump_printer - construct a _printer that can output to a buffer
+ * from the read function for devcoredump
+ * @iter: A pointer to a struct drm_print_iterator for the read instance
+ *
+ * RETURNS:
+ * The _printer object
+ */
+static inline struct drm_printer
+drm_coredump_printer(struct drm_print_iterator *iter)
+{
+   struct drm_printer p = {
+   .printfn = __drm_printfn_coredump,
+   .arg = iter,
+   };
+   return p;
+}
+
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
  * @f:  the  seq_file to output to
-- 
1.9.1

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

[RFC v3 0/8] drm/msm: GPU crash state

[Jordan Crouse]

This is revision 3 of my stack implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/).

The goal is to store and provide enough information to debug software
and hardware issues on the Adreno hardware in a semi human-readable
format that can also be parsed by scripts.

So far this is a relatively basic dump of registers and data but future patches
will add more details and target specific information.

You can see an example of the output for a simple invalid opcode error on the
db820c here: https://hastebin.com/olaruyakaz.bash

v3: Make recommended changes to ascii85 per Chris Wilson. Use devcoredump to
dump crash states as suggested by Bjorn Andersson and add a new drm_print
facility to facilitate that. Remove the now obsolete 'crash' debugfs node.
Add documentation for the crash dump output.

v2: Convert output to yaml, use ascii85 to dump ringbuffer contents.

Jordan Crouse (8):
  include: Move ascii85 functions from i915 to linux/ascii85.h
  drm: drm_printer: Add printer for devcoredump
  drm/msm/gpu: Capture the state of the GPU
  drm/msm/gpu: Convert the GPU show function to use the GPU state
  drm/msm/gpu: Capture the GPU state on a GPU hang
  drm/msm/adreno: Convert the show/crash file format
  drm/msm/adreno: Add ringbuffer data to the GPU state
  drm/msm/adreno: Add a5xx specific registers for the GPU state

 Documentation/gpu/drm-msm-crash-dump.txt |  34 +
 drivers/gpu/drm/drm_print.c  |  54 +++
 drivers/gpu/drm/i915/i915_gpu_error.c|  38 +
 drivers/gpu/drm/msm/Kconfig  |   1 +
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c|  28 ++--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c|  20 ++-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 239 +--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  | 146 ---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h  |   7 +-
 drivers/gpu/drm/msm/msm_debugfs.c|  24 +++-
 drivers/gpu/drm/msm/msm_gpu.c| 103 +++--
 drivers/gpu/drm/msm/msm_gpu.h|  58 +++-
 include/drm/drm_print.h  |  27 
 include/linux/ascii85.h  |  39 +
 14 files changed, 721 insertions(+), 97 deletions(-)
 create mode 100644 Documentation/gpu/drm-msm-crash-dump.txt
 create mode 100644 include/linux/ascii85.h

-- 
1.9.1

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

[PATCH 4/8] drm/msm/gpu: Convert the GPU show function to use the GPU state

[Jordan Crouse]

Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping a previously captured state from a GPU hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 ++--
 drivers/gpu/drm/msm/msm_debugfs.c   | 21 +++--
 drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
 7 files changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index c351292..4b9284a 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -410,15 +410,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
~0   /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-}
-#endif
-
 /* would be nice to not have to duplicate the _show() stuff with printk(): */
 static void a3xx_dump(struct msm_gpu *gpu)
 {
@@ -463,7 +454,7 @@ static struct msm_gpu_state *a3xx_gpu_state_get(struct 
msm_gpu *gpu)
.irq = a3xx_irq,
.destroy = a3xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a3xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a3xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index faf5d60..b8dcbb1 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -454,16 +454,6 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
~0 /* sentinel */
 };
 
-#ifdef CONFIG_DEBUG_FS
-static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
-   adreno_show(gpu, m);
-
-}
-#endif
-
 static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
 {
struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
@@ -550,7 +540,7 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
.irq = a4xx_irq,
.destroy = a4xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a4xx_show,
+   .show = adreno_show,
 #endif
.gpu_state_get = a4xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 08f2579..b0910bb 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-#ifdef CONFIG_DEBUG_FS
-static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
-{
-   seq_printf(m, "status:   %08x\n",
-   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
-
-   /*
-* Temporarily disable hardware clock gating before going into
-* adreno_show to avoid issues while reading the registers
-*/
-   a5xx_set_hwcg(gpu, false);
-   adreno_show(gpu, m);
-   a5xx_set_hwcg(gpu, true);
-}
-#endif
-
 static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1260,7 +1244,7 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
*value)
.irq = a5xx_irq,
.destroy = a5xx_destroy,
 #ifdef CONFIG_DEBUG_FS
-   .show = a5xx_show,
+   .show = adreno_show,
.debugfs_init = a5xx_debugfs_init,
 #endif
.gpu_busy = a5xx_gpu_busy,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 35b77f0..af776f1 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -437,38 +437,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
 }
 
 #ifdef CONFIG_DEBUG_FS
-void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
+void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state *state,
+   struct seq_file *m)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
 
+   if (IS_ERR_OR_NULL(state))
+   return;
+
+   seq_printf(m, "status:   %08x\n", state->rbbm_status);

Re: [PATCH 1/8] include: Move ascii85 functions from i915 to linux/ascii85.h

[Chris Wilson]

Quoting Jordan Crouse (2018-02-08 17:31:50)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
> 
> [v2 - Update the API to be cleaner for the caller suggested by
> Chris Wilson]
> 
> Signed-off-by: Jordan Crouse 
> ---
> @@ -545,19 +523,15 @@ static void print_error_obj(struct 
> drm_i915_error_state_buf *m,
>  
> err_compression_marker(m);
> for (page = 0; page < obj->page_count; page++) {
> -   int i, len;
> +   int i;
> +   long len = PAGE_SIZE;

Please keep len = PAGE_SIZE below, so that the computation of len is
grouped. In fact, just ignore the s/int/long/ here as we know it is
bounded to int.

With that,
Reviewed-by: Chris Wilson 

Pick a tree where you want this applied...
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 1/1] drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476) problems:

[Joe Moriarty]

The Parfait (version 2.1.0) static code analysis tool found multiple NULL
pointer derefernce problems.

- drivers/gpu/drm/drm_dp_mst_topology.c
The call to drm_dp_calculate_rad() in function drm_dp_port_setup_pdt()
could result in a NULL pointer being returned to port->mstb due to a
failure to allocate memory for port->mstb.

- drivers/gpu/drm/drm_drv.c
Any calls to drm_minor_get_slot() could result in the return of a NULL
pointer when an invalid DRM device type is encountered.  2 helper
functions where added for pointer manipulation (drm_minor_get_slot()
and drm_minor_set_minor()) along with checks for valid pointers for
struct drm_device variables throughout this module.

- drivers/gpu/drm/drm_edid.c
The call to drm_cvt_mode() in function drm_mode_std() for the
HDTV hack resulted in the possibility of accessing a NULL pointer
if drm_mode_std() returned NULL.  A check for this added right after
the call to drm_cvt_mode() in this particular area of code.

- drivers/gpu/drm/drm_vblank.c
Null pointer checks were added to return values from calls to
drm_crtc_from_index().  There is a possibility, however minute, that
crtc->index may not be found when trying to find the struct crtc
from it's assigned index given in drm_crtc_init_with_planes().
3 return checks for NULL where added.

Signed-off-by: Joe Moriarty 
Reviewed-by: Steven Sistare 
---
 drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
 drivers/gpu/drm/drm_drv.c | 38 +++
 drivers/gpu/drm/drm_edid.c|  2 ++
 drivers/gpu/drm/drm_vblank.c  |  6 +++---
 4 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa58d3c2..ec503d416062 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1082,10 +1082,12 @@ static bool drm_dp_port_setup_pdt(struct 
drm_dp_mst_port *port)
lct = drm_dp_calculate_rad(port, rad);
 
port->mstb = drm_dp_add_mst_branch_device(lct, rad);
-   port->mstb->mgr = port->mgr;
-   port->mstb->port_parent = port;
+   if (port->mstb) {
+   port->mstb->mgr = port->mgr;
+   port->mstb->port_parent = port;
 
-   send_link = true;
+   send_link = true;
+   }
break;
}
return send_link;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9acc1e157813..938eee77f014 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -99,10 +99,36 @@ static struct drm_minor **drm_minor_get_slot(struct 
drm_device *dev,
case DRM_MINOR_CONTROL:
return >control;
default:
+   DRM_ERROR("Error in %s: Invalid dev, type = %d\n",
+ __func__, type);
return NULL;
}
 }
 
+static inline int drm_minor_set_minor(struct drm_device *dev,
+ unsigned int type,
+ struct drm_minor *minor)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+   int retval = -ENODEV;
+
+   if (slot) {
+   retval = 0;
+   *slot = minor;
+   }
+   return retval;
+}
+
+static inline struct drm_minor *drm_minor_get_minor(struct drm_device *dev,
+   unsigned int type)
+{
+   struct drm_minor **slot = drm_minor_get_slot(dev, type);
+
+   if (slot)
+   return *slot;
+   return NULL;
+}
+
 static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 {
struct drm_minor *minor;
@@ -137,8 +163,9 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned 
int type)
goto err_index;
}
 
-   *drm_minor_get_slot(dev, type) = minor;
-   return 0;
+   r = drm_minor_set_minor(dev, type, minor);
+   if (r == 0)
+   return r;
 
 err_index:
spin_lock_irqsave(_minor_lock, flags);
@@ -155,6 +182,9 @@ static void drm_minor_free(struct drm_device *dev, unsigned 
int type)
unsigned long flags;
 
slot = drm_minor_get_slot(dev, type);
+   if (!slot)
+   return
+
minor = *slot;
if (!minor)
return;
@@ -177,7 +207,7 @@ static int drm_minor_register(struct drm_device *dev, 
unsigned int type)
 
DRM_DEBUG("\n");
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_slot(dev, type);
if (!minor)
return 0;
 
@@ -209,7 +239,7 @@ static void drm_minor_unregister(struct drm_device *dev, 
unsigned int type)
struct drm_minor *minor;
unsigned long flags;
 
-   minor = *drm_minor_get_slot(dev, type);
+   minor = drm_minor_get_slot(dev, type);
if (!minor 

Re: [PATCH v2 1/2] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

El Thu, Feb 08, 2018 at 09:33:53AM -0500 Harry Wentland ha dit:

> On 2018-02-07 08:51 PM, Matthias Kaehlcke wrote:
> > Use subdir-ccflags instead of specifying the same flags for every source
> > file.
> > 
> > Signed-off-by: Matthias Kaehlcke 
> > Reviewed-by: Guenter Roeck 
> > ---
> > Changes in v2:
> > - added 'Reviewed-by: Guenter Roeck ' tag
> > 
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile | 10 +-
> >  1 file changed, 1 insertion(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > index 3488af2b5786..b8cadf833e71 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > @@ -24,15 +24,7 @@
> >  # It provides the general basic services required by other DAL
> >  # subcomponents.
> >  
> > -CFLAGS_display_mode_vba.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_mode_lib.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_pipe_clocks.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_soc_bounding_box.o := -mhard-float -msse 
> > -mpreferred-stack-boundary=4
> > -CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
> > -
> > +subdir-ccflags-y += -mhard-float -msse -mpreferred-stack-boundary=4
> 
> Are you sure this will only apply to dc/dml?
> 
> The way the amdgpu build is setup I've seen this flag apply to all of amdgpu, 
> even if specified in a subdirectories build file. The reason being that 
> amdgpu/Makefile recursively includes all other Makefiles in the module.
> 
> According to kbuild/makefiles.txt this will have effect for the kbuild file 
> where it's present and all subdirectories:
> 
> https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt:
> > subdir-ccflags-y, subdir-asflags-y
> > The two flags listed above are similar to ccflags-y and asflags-y.
> > The difference is that the subdir- variants have effect for the kbuild
> > file where they are present and all subdirectories.
> > Options specified using subdir-* are added to the commandline before
> > the options specified using the non-subdir variants.
> > 
> > Example:
> > subdir-ccflags-y := -Werror

Thanks, I didn't realize the recursive inclusion from amdgpu/Makefile,
in this case using subdir-ccflags-y indeed isn't a good idea.

> For your 2nd patch you probably want to make a dml_cflags variable
> that's set different for clang and gcc, and then still set it for
> all files in DML individually.

Yep, that was my first impulse and then I remembered
subdir-ccflags-y. Will go back to that.

> You'll probably also have to do the same for dc/calcs/Makefile.

Thanks for the heads up!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/6] dt-bindings: Clarify timing subnode use as panel-timing

[Rob Herring]

On Thu, Feb 8, 2018 at 11:48 AM, Sean Paul  wrote:
> Add a note in the documentation explaining when it's appropriate to use
> the display-timings subnode on its own, as well as the preferred name to
> use (panel-timing).
>
> Changes in v3:
>  - Added
>
> Cc: Doug Anderson 
> Cc: Eric Anholt 
> Cc: Heiko Stuebner 
> Cc: Jeffy Chen 
> Cc: Rob Herring 
> Cc: Stéphane Marchesin 
> Cc: Thierry Reding 
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-rockc...@lists.infradead.org
> Signed-off-by: Sean Paul 
> ---
>  Documentation/devicetree/bindings/display/panel/display-timing.txt | 5 +
>  1 file changed, 5 insertions(+)

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

Re: [Freedreno] [PATCH 4/8] drm/msm/gpu: Convert the GPU show function to use the GPU state

[Rob Clark]

On Thu, Feb 8, 2018 at 12:31 PM, Jordan Crouse  wrote:
> Convert the existing GPU show function to use the GPU state to
> dump the information rather than reading it directly from the hardware.
> This will require an additional step to capture the state before
> dumping it for the existing nodes but it will greatly facilitate reusing
> the same code for dumping a previously captured state from a GPU hang.
>
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 11 +--
>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c   | 12 +---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 18 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 30 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h |  4 ++--
>  drivers/gpu/drm/msm/msm_debugfs.c   | 21 +++--
>  drivers/gpu/drm/msm/msm_gpu.h   |  3 ++-
>  7 files changed, 35 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index c351292..4b9284a 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -410,15 +410,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
> ~0   /* sentinel */
>  };
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A3XX_RBBM_STATUS));
> -   adreno_show(gpu, m);
> -}
> -#endif
> -
>  /* would be nice to not have to duplicate the _show() stuff with printk(): */
>  static void a3xx_dump(struct msm_gpu *gpu)
>  {
> @@ -463,7 +454,7 @@ static struct msm_gpu_state *a3xx_gpu_state_get(struct 
> msm_gpu *gpu)
> .irq = a3xx_irq,
> .destroy = a3xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a3xx_show,
> +   .show = adreno_show,
>  #endif
> .gpu_state_get = a3xx_gpu_state_get,
> .gpu_state_put = adreno_gpu_state_put,
> diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> index faf5d60..b8dcbb1 100644
> --- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
> @@ -454,16 +454,6 @@ static irqreturn_t a4xx_irq(struct msm_gpu *gpu)
> ~0 /* sentinel */
>  };
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a4xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A4XX_RBBM_STATUS));
> -   adreno_show(gpu, m);
> -
> -}
> -#endif
> -
>  static struct msm_gpu_state *a4xx_gpu_state_get(struct msm_gpu *gpu)
>  {
> struct msm_gpu_state *state = adreno_gpu_state_get(gpu);
> @@ -550,7 +540,7 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, 
> uint64_t *value)
> .irq = a4xx_irq,
> .destroy = a4xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a4xx_show,
> +   .show = adreno_show,
>  #endif
> .gpu_state_get = a4xx_gpu_state_get,
> .gpu_state_put = adreno_gpu_state_put,
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 08f2579..b0910bb 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1215,22 +1215,6 @@ static struct msm_gpu_state *a5xx_gpu_state_get(struct 
> msm_gpu *gpu)
> return state;
>  }
>
> -#ifdef CONFIG_DEBUG_FS
> -static void a5xx_show(struct msm_gpu *gpu, struct seq_file *m)
> -{
> -   seq_printf(m, "status:   %08x\n",
> -   gpu_read(gpu, REG_A5XX_RBBM_STATUS));
> -
> -   /*
> -* Temporarily disable hardware clock gating before going into
> -* adreno_show to avoid issues while reading the registers
> -*/
> -   a5xx_set_hwcg(gpu, false);
> -   adreno_show(gpu, m);
> -   a5xx_set_hwcg(gpu, true);
> -}
> -#endif
> -
>  static struct msm_ringbuffer *a5xx_active_ring(struct msm_gpu *gpu)
>  {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> @@ -1260,7 +1244,7 @@ static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t 
> *value)
> .irq = a5xx_irq,
> .destroy = a5xx_destroy,
>  #ifdef CONFIG_DEBUG_FS
> -   .show = a5xx_show,
> +   .show = adreno_show,
> .debugfs_init = a5xx_debugfs_init,
>  #endif
> .gpu_busy = a5xx_gpu_busy,
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 35b77f0..af776f1 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -437,38 +437,34 @@ void adreno_gpu_state_put(struct msm_gpu_state *state)
>  }
>
>  #ifdef CONFIG_DEBUG_FS
> -void adreno_show(struct msm_gpu *gpu, struct seq_file 

[PATCH 1/3] drm/amd/powerplay/hwmgr: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 20:32:39 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 4 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 1 -
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 4 +---
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index b314d09d41af..c0699b884894 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -286,10 +286,8 @@ static int cz_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 0229f774f7a9..ded33ed03f11 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -815,7 +815,6 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate space for vddc_dep_on_dal_pwrl! \n");
return -ENOMEM;
} else {
table_clk_vlt->count = 4;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 569073e3a5a1..967b93e56113 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -107,10 +107,8 @@ static int rv_init_dynamic_state_adjustment_rule_settings(
struct phm_clock_voltage_dependency_table *table_clk_vlt =
kzalloc(table_size, GFP_KERNEL);
 
-   if (NULL == table_clk_vlt) {
-   pr_err("Can not allocate memory!\n");
+   if (!table_clk_vlt)
return -ENOMEM;
-   }
 
table_clk_vlt->count = 8;
table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_0;
-- 
2.16.1

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

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Laurent Pinchart]

Hi Kieran,

On Thursday, 8 February 2018 01:30:43 EET Kieran Bingham wrote:
> On 07/02/18 21:59, Laurent Pinchart wrote:
> > On Wednesday, 7 February 2018 17:14:09 EET Kieran Bingham wrote:
> >> On 29/01/18 10:26, Laurent Pinchart wrote:
> >>> On Monday, 22 January 2018 14:50:00 EET Kieran Bingham wrote:
>  The ADV7511 has four 256-byte maps that can be accessed via the main
>  I²C ports. Each map has it own I²C address and acts as a standard slave
>  device on the I²C bus.
>  
>  Allow a device tree node to override the default addresses so that
>  address conflicts with other devices on the same bus may be resolved at
>  the board description level.
>  
>  Signed-off-by: Kieran Bingham 
>  ---
>  
>   .../bindings/display/bridge/adi,adv7511.txt| 10 +-
> >>> 
> >>> I don't mind personally, but device tree maintainers usually ask for DT
> >>> bindings changes to be split to a separate patch.
> >>> 
>   drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36++-
>   3 files changed, 37 insertions(+), 13 deletions(-)
>  
>  diff --git
>  a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  index 0047b1394c70..f6bb9f6d3f48 100644
>  --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  
>  @@ -70,6 +70,9 @@ Optional properties:
> rather than generate its own timings for HDMI output.
>   - clocks: from common clock binding: reference to the CEC clock.
>   - clock-names: from common clock binding: must be "cec".
>  +- reg-names : Names of maps with programmable addresses.
>  +It can contain any map needing a non-default address.
>  +Possible maps names are : "main", "edid", "cec", "packet"
> >>> 
> >>> Is the reg-names property (and the additional maps) mandatory or
> >>> optional ? If mandatory you should also update the existing DT sources
> >>> that use those bindings.
> >> 
> >> They are currently optional. I do prefer it that way - but perhaps due to
> >> an issue mentioned below we might need to make this driver mandatory ?>> 
> >> 
> >>> If optional you should define which I2C addresses will be used when
> >>> the maps are not specified (and in that case I think we should go for
> >>> the addresses listed as default in the datasheet, which correspond to
> >>> the current driver implementation when the main address is 0x3d/0x7a).
> >> 
> >> The current addresses do not correspond to the datasheet, even when the
> >> implementation main address is set to 0x3d.
> > 
> > Don't they ? The driver currently uses the following (8-bit) I2C
> > addresses:
> > 
> > EDID:   main + 4  = 0x7e (0x3f)
> > Packet: main - 10 = 0x70 (0x38)
> > CEC:main - 2  = 0x78 (0x3c)
> > 
> > Those are the default addresses according to section 4.1 of the ADV7511W
> > programming guide (rev. B), and they match the ones you set in this patch.
> 
> Sorry - I was clearly subtracting 8bit values from a 7bit address in my
> failed assertion, to both you and Archit.

No worries.

> >> Thus, in my opinion - they are currently 'wrong' - but perhaps changing
> >> them is considered breakage too.
> >> 
> >> A particular issue will arise here too - as on this device - when the
> >> device is in low-power mode (after probe, before use) - the maps will
> >> respond on their *hardware default* addresses (the ones implemented in
> >> this patch), and thus consume that address on the I2C bus regardless of
> >> their settings in the driver.
> > 
> > We've discussed this previously and I share you concern. Just to make sure
> > I remember correctly, did all the secondary maps reset to their default
> > addresses, or just the EDID map ?
> 
> The following responds on the bus when programmed at alternative addresses,
> and in low power mode. The responses are all 0, but that's still going to
> conflict with other hardware if it tries to use the 'un-used' addresses.
> 
> Packet (0x38),
> Main (0x39),
> Fixed (set to 0 by software, but shows up at 0x3e)
> and EDID (0x3f).
> 
> So actually it's only the CEC which don't respond when in "low-power-mode".
> 
> As far as I can see, (git grep  -B3 adi,adv75) - The r8a7792-wheat.dts is
> the only instance of a device using 0x3d, which means that Sergei's patch
> changed the behaviour of all the existing devices before that.
> 
> Thus - this patch could be seen to be a 'correction' back to the original
> behaviour for all devices except the Wheat, and possibly devices added after
> Sergei's patch went in.
> 
> However - by my understanding, - any device which has only one ADV75(3,1)+
> should use the hardware defined addresses (the hardware defaults will be
> conflicting on the 

[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).

[bugzilla-daemon]

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

Eugene (ken20...@ukr.net) changed:

   What|Removed |Added

 CC||ken20...@ukr.net

--- Comment #4 from Eugene (ken20...@ukr.net) ---
$ uname -a
Linux GA-MA790FX-DQ6 4.13.0-32-generic #35~16.04.1-Ubuntu SMP Thu Jan 25
10:13:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Oland
PRO [Radeon R7 240/340]

$ dmesg | grep -i "failed VCE resume" -A7 -B20
[1.890001] [TTM] Initializing DMA pool allocator
[1.890025] [drm] radeon: 1024M of VRAM memory ready
[1.890026] [drm] radeon: 2048M of GTT memory ready.
[1.890034] [drm] Loading oland Microcode
[1.890191] [drm] Internal thermal controller with fan control
[1.890268] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[1.897887] [drm] radeon: dpm initialized
[1.903155] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[1.903218] [drm] GART: num cpu pages 524288, num gpu pages 524288
[1.906208] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[1.906211] [drm] PCIE gen 2 link speeds already enabled
[1.912329] r8169 :03:00.0 enp3s0: renamed from eth1
[1.921990] [drm] PCIE GART of 2048M enabled (table at 0x001D6000).
[1.922107] radeon :01:00.0: WB enabled
[1.922110] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x99599f7e5c00
[1.922112] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x4c04 and cpu addr 0x99599f7e5c04
[1.922114] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x4c08 and cpu addr 0x99599f7e5c08
[1.922115] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x4c0c and cpu addr 0x99599f7e5c0c
[1.922116] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x4c10 and cpu addr 0x99599f7e5c10
[1.922515] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0xb8da41435a18
[2.022790] radeon :01:00.0: failed VCE resume (-110).
[2.022848] firewire_ohci :06:0e.0: added OHCI v1.10 device as card 0, 4
IR + 8 IT contexts, quirks 0x2
[2.022858] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.022859] [drm] Driver supports precise vblank timestamp query.
[2.022860] radeon :01:00.0: radeon: MSI limited to 32-bit
[2.022908] radeon :01:00.0: radeon: using MSI.
[2.022946] [drm] radeon: irq initialized.
[2.026917] ata9.00: ATAPI: Optiarc DVD RW AD-7170A, 1.02, max UDMA/66

P.S. dmesg is in attachment

-- 
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 2/3] drm/amd/powerplay/hwmgr: Adjust layout for source code from five if statements

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:01:24 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: Comparisons should place the constant on the right side
of the test
WARNING: else is not generally useful after a break or return

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c   | 33 +++-
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c  | 31 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c |  5 ++--
 3 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index c0699b884894..870c517f2057 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -1772,37 +1772,34 @@ static int cz_read_sensor(struct pp_hwmgr *hwmgr, int 
idx,
return 0;
case AMDGPU_PP_SENSOR_UVD_VCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   vclk = uvd_table->entries[uvd_index].vclk;
-   *((uint32_t *)value) = vclk;
-   return 0;
-   }
+
+   vclk = uvd_table->entries[uvd_index].vclk;
+   *((uint32_t *)value) = vclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_UVD_DCLK:
if (!cz_hwmgr->uvd_power_gated) {
-   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (uvd_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   dclk = uvd_table->entries[uvd_index].dclk;
-   *((uint32_t *)value) = dclk;
-   return 0;
-   }
+
+   dclk = uvd_table->entries[uvd_index].dclk;
+   *((uint32_t *)value) = dclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
case AMDGPU_PP_SENSOR_VCE_ECCLK:
if (!cz_hwmgr->vce_power_gated) {
-   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS) {
+   if (vce_index >= CZ_MAX_HARDWARE_POWERLEVELS)
return -EINVAL;
-   } else {
-   ecclk = vce_table->entries[vce_index].ecclk;
-   *((uint32_t *)value) = ecclk;
-   return 0;
-   }
+
+   ecclk = vce_table->entries[vce_index].ecclk;
+   *((uint32_t *)value) = ecclk;
+   return 0;
}
*((uint32_t *)value) = 0;
return 0;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ded33ed03f11..2681c9317d25 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -813,24 +813,23 @@ int 
phm_initializa_dynamic_state_adjustment_rule_settings(struct pp_hwmgr *hwmgr
/* initialize vddc_dep_on_dal_pwrl table */
table_size = sizeof(uint32_t) + 4 * sizeof(struct 
phm_clock_voltage_dependency_record);
table_clk_vlt = kzalloc(table_size, GFP_KERNEL);
-
-   if (NULL == table_clk_vlt) {
+   if (!table_clk_vlt)
return -ENOMEM;
-   } else {
-   table_clk_vlt->count = 4;
-   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
-   table_clk_vlt->entries[0].v = 0;
-   table_clk_vlt->entries[1].clk = PP_DAL_POWERLEVEL_LOW;
-   table_clk_vlt->entries[1].v = 720;
-   table_clk_vlt->entries[2].clk = PP_DAL_POWERLEVEL_NOMINAL;
-   table_clk_vlt->entries[2].v = 810;
-   table_clk_vlt->entries[3].clk = PP_DAL_POWERLEVEL_PERFORMANCE;
-   table_clk_vlt->entries[3].v = 900;
-   if (pptable_info != NULL)
-   pptable_info->vddc_dep_on_dal_pwrl = table_clk_vlt;
-   hwmgr->dyn_state.vddc_dep_on_dal_pwrl = table_clk_vlt;
-   }
 
+   table_clk_vlt->count = 4;
+   table_clk_vlt->entries[0].clk = PP_DAL_POWERLEVEL_ULTRALOW;
+   table_clk_vlt->entries[0].v = 0;
+   table_clk_vlt->entries[1].clk = PP_DAL_POWERLEVEL_LOW;
+   table_clk_vlt->entries[1].v = 720;

[PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Matthias Kaehlcke]

calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- patch added

Note to self: if this patterns proliferates further we probably want to
put the evaluation of the correct compiler flag in some common place.

 drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index af0f452f3c9f..95f332ee3e7e 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -24,7 +24,13 @@
 # It calculates Bandwidth and Watermarks values for HW programming
 #
 
-calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+calcs_ccflags := -mhard-float -msse $(cc_stack_align)
 
 CFLAGS_dcn_calcs.o := $(calcs_ccflags)
 CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 3/4] amdgpu/dc/dml: Support clang option for stack alignment

[Matthias Kaehlcke]

DML uses the compiler option -mpreferred-stack-boundary=4 to configure
a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
instead, which expects as parameter the alignment in bytes, and not a
power of two like -mpreferred-stack-boundary.

Probe for both compiler options and use the correct one, similar to
what is done in arch/x86/Makefile.

Reported-by: Guenter Roeck 
Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- adapted use of variable instead of subdir-ccflags-y

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 96b337a03172..782886cac61c 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,7 +24,13 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-dml_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
+   cc_stack_align := -mpreferred-stack-boundary=4
+else ifneq ($(call cc-option, -mstack-alignment=16),)
+   cc_stack_align := -mstack-alignment=16
+endif
+
+dml_ccflags := -mhard-float -msse $(cc_stack_align)
 
 CFLAGS_display_mode_vba.o := $(dml_ccflags)
 CFLAGS_display_mode_lib.o := $(dml_ccflags)
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 1/4] amdgpu/dc/dml: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use a variable for common CFLAGS instead of specifying the same flags
for every source file.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- Use variable for compiler options instead of subdir-ccflags-y

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index 3488af2b5786..96b337a03172 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -24,15 +24,16 @@
 # It provides the general basic services required by other DAL
 # subcomponents.
 
-CFLAGS_display_mode_vba.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_mode_lib.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_pipe_clocks.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_calc.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml1_display_rq_dlg_calc.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_display_rq_dlg_helpers.o := -mhard-float -msse 
-mpreferred-stack-boundary=4
-CFLAGS_soc_bounding_box.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dml_common_defs.o := -mhard-float -msse -mpreferred-stack-boundary=4
+dml_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
 
+CFLAGS_display_mode_vba.o := $(dml_ccflags)
+CFLAGS_display_mode_lib.o := $(dml_ccflags)
+CFLAGS_display_pipe_clocks.o := $(dml_ccflags)
+CFLAGS_display_rq_dlg_calc.o := $(dml_ccflags)
+CFLAGS_dml1_display_rq_dlg_calc.o := $(dml_ccflags)
+CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
+CFLAGS_soc_bounding_box.o := $(dml_ccflags)
+CFLAGS_dml_common_defs.o := $(dml_ccflags)
 
 DML = display_mode_lib.o display_rq_dlg_calc.o \
  display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v3 2/4] amdgpu/dc/calcs: Consolidate redundant CFLAGS

[Matthias Kaehlcke]

Use a variable for common CFLAGS instead of specifying the same flags
for every source file.

Signed-off-by: Matthias Kaehlcke 
---
Changes in v3:
- patch added

 drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 7959e382ed28..af0f452f3c9f 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -24,9 +24,11 @@
 # It calculates Bandwidth and Watermarks values for HW programming
 #
 
-CFLAGS_dcn_calcs.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dcn_calc_auto.o := -mhard-float -msse -mpreferred-stack-boundary=4
-CFLAGS_dcn_calc_math.o := -mhard-float -msse -mpreferred-stack-boundary=4 
-Wno-tautological-compare
+calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
+
+CFLAGS_dcn_calcs.o := $(calcs_ccflags)
+CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
+CFLAGS_dcn_calc_math.o := $(calcs_ccflags) -Wno-tautological-compare
 
 BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
 
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v1 0/1] Parfait changes

[Joe Moriarty]

The following patch(s) are bugs found by the static compiler
'Parfait'.  Care was taken to make sure false positive results
were removed from this patchset.

Parfait Overview


https://labs.oracle.com/pls/apex/f?p=labs:49:P49_PROJECT_ID:13

Joe Moriarty (1):
  drm: Multiple Null pointer dereference [null-pointer-deref] (CWE 476)
problems:

 drivers/gpu/drm/drm_dp_mst_topology.c |  8 +---
 drivers/gpu/drm/drm_drv.c | 38 +++
 drivers/gpu/drm/drm_edid.c|  2 ++
 drivers/gpu/drm/drm_vblank.c  |  6 +++---
 4 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.15.0

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

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Thu, Feb 08, 2018 at 10:27:54AM +0100, Andrzej Hajda wrote:
> On 07.02.2018 22:43, Rob Herring wrote:
> > On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
> >> On 05.02.2018 07:08, Rob Herring wrote:
> >>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
>  These bindings allow to describe most known standard USB connectors
>  and it should be possible to extend it if necessary.
>  USB connectors, beside USB can be used to route other protocols,
>  for example UART, Audio, MHL. In such case every device passing data
>  through the connector should have appropriate graph bindings.
> 
>  Signed-off-by: Andrzej Hajda 
>  ---
>  v2:
>  - moved connector type(A,B,C) to compatible string (Rob),
>  - renamed size property to type (Rob),
>  - changed type description to be less confusing (Laurent),
>  - removed vendor specific compatibles (implied by graph port number),
> >>> How so? More below...
> >>>
>  - added requirement of connector being a child of IC (Rob),
>  - removed max-mode (subtly suggested by Rob, it should be detected anyway
>    by USB Controller in runtime, downside is that device is not able to
>    report its real capabilities, maybe better would be to make it 
>  optional(?)),
>  - assigned port numbers to data buses (Rob).
> 
>  Regards
>  Andrzej
> 
>  Signed-off-by: Andrzej Hajda 
>  ---
>   .../bindings/connector/usb-connector.txt   | 48 
>  ++
>   1 file changed, 48 insertions(+)
>   create mode 100644 
>  Documentation/devicetree/bindings/connector/usb-connector.txt
> 
>  diff --git 
>  a/Documentation/devicetree/bindings/connector/usb-connector.txt 
>  b/Documentation/devicetree/bindings/connector/usb-connector.txt
>  new file mode 100644
>  index ..02020f5d760a
>  --- /dev/null
>  +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>  @@ -0,0 +1,48 @@
>  +USB Connector
>  +=
>  +
>  +USB connector node represents physical USB connector. It should be
>  +a child of USB interface controller.
>  +
>  +Required properties:
>  +- compatible: describes type of the connector, must be one of:
>  +"usb-a-connector", "usb-b-connector", "usb-c-connector",
> >>> Nit: one per line.
> >>>
>  +
>  +Optional properties:
>  +- label: symbolic name for the connector
>  +- type: size of the connector, should be specified in case of USB-A, 
>  USB-B
>  +  non-standard (large) connector sizes: "mini", "micro"
>  +
>  +Required nodes:
>  +- any data bus to the connector should be modeled using the OF graph 
>  bindings
>  +  specified in bindings/graph.txt, unless the bus is between parent 
>  node and
>  +  the connector. Since single connector can have multpile data buses 
>  every bus
>  +  has assigned OF graph port number as follows:
>  +0: High Speed (HS), present in all connectors,
>  +1: Super Speed (SS), present in SS capable connectors,
>  +2: Sideband use (SBU), present in USB-C,
>  +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
>  micro-USB
> >>> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
> >>> That makes me think the Samsung connector should have its own compatible 
> >>> string.
> >> Do you mean, sth like:
> >>     connector {
> >>             compatible = "samsung,usb-connector-11pin";
> >>             label = "micro-USB";
> >>             ports {
> >>                     #address-cells = <1>;
> >>                     #size-cells = <0>;
> >>
> >>                     port@3 {
> >>                             reg = <3>;
> >>                             musb_con_mhl_in: endpoint {
> >>                                     remote-endpoint = <_out>;
> >>                             };
> >>                     };
> >>     };
> > Yes, basically.
> >
> >> Or should I add "usb-b-connector" extra compatible and "type" property?
> > type would be micro? I think type and "usb-b-connector" are fine if this 
> > is a superset like a USB3 SS micro connector.
> >
> >> I slightly prefer my approach(less different bindings), but I am also OK
> >> with the above.
> > How do you know it is a Samsung connector then? Just because you have 
> > port 3? I think it is better to be explicit.
> 
> OK.
> 
> >
> >>> Can we go ahead and define the video modes of Type-C? Normally, if 2 
> >>> data streams are mutually exclusive, then they are a single port with 2 
> >>> endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
> >>> port 3 is always video. We can still know what is mutually exclusive 
> >>> based on the compatible. 
> >> I am sorry, I do not understand what you mean. Port 3 is present only in
> >> 11-pin Samsung 

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Maxime Ripard]

On Wed, Feb 07, 2018 at 01:49:59PM +0100, Giulio Benetti wrote:
> Hi,
> 
> Il 07/02/2018 11:39, Maxime Ripard ha scritto:
> > On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> > Also, how was it tested? This seems quite weird that we haven't caught
> > that one sooner, and I'm a bit worried about the possible regressions
> > here.
> 
>  It sounds really strange to me too,
>  because everybody under uboot use "sync:3"(HIGH).
>  I will retry to measure,
>  unfortunately at home I don't have a scope,
>  but I think I'm going to have one soon, because of this. :)
> >>>
> >>> Here I am with scope captures and tcon0 registers dump:
> >>> tcon0_regs => https://pasteboard.co/H4r8Zcs.png
> >>> dclk_d0 => https://pasteboard.co/H4r8QRe.png
> >>> dclk_de => https://pasteboard.co/H4r8zh4R.png
> >>> dclk_vsnc => https://pasteboard.co/H4r8Hye.png
> >>>
> >>> As you can see circled in reg on registers,
> >>> TCON0_IO_POL_REG = 0x.
> >>> But on all the waveforms you can see:
> >>> - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
> >>> the rising front overlaps dclk rising edge(not good), so to me this is
> >>> falling, then I mean it Negative.
> >>> - dclk_de: de pulse is clearly negative, even if register is 0 and its'
> >>> polarity bit is 0.
> >>> - dclk_vsnc: same as dclk_de
> >>> - dclk_hsync: I didn't take scope screenshot but I can assure you it's
> >>> negative.
> >>>
> >>> You can also check all the other registers about TCON0.
> >>>
> >>> Now I proceed testing it on A33, maybe the peripheral is slightly
> >>> different between Axx SoCs, if I find it that way,
> >>> it should be only a check about SoC or peripheral ID,
> >>> and treat polarity as it should be done.
> >>
> >> Here I am with A33 waveforms:
> >> tcon0_regs => https://pasteboard.co/H4rXfN0M.png
> >> dclk_d0 => https://pasteboard.co/H4rVXwy.png
> >> dclk_de => https://pasteboard.co/H4rWDt8.png
> >> dclk_vsnc => https://pasteboard.co/H4rWRACu.png
> >> dclk_hsync => https://pasteboard.co/H4rWK6I.png
> >>
> >> It behaves the same way as A20, so as I mean IO polarity,
> >> all signals(except D0-D23), are inverted.
> >> For A33 I've used A33-OLinuXino.
> >> For A20 our LiNova1.
> > 
> > If you have an A33 handy, you probably want to read that mail:
> > https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html
> > 
> > Especially the 90-phase part.
> 
> Here is a summary of different SoCs TCON:
> With DCLK_Sel:
> 0x0 => normal phase
> 0x1 => 1/3 phase
> 0x2 => 2/3 phase
> 
> A10, A20

Have you tested the option 4 and 5 there too?

> With DCLK_Sel:
> 0x0 => normal phase
> 0x1 => 1/3 phase
> 0x2 => 2/3 phase
> 0x5 => DCLK/2 phase 0
> 0x4 => DCLK/2 phase 90
> 
> A31, A31s, A33, A80, A83T

Ok, great, so Chen-Yu was right :)

I guess the option 5 (DCLK/2 phase 0) is still to early, just like
you've shown in the previous captures?

> Also I've found that TCON1 has not this feature,
> nor first, nor second case(at least is not described on user manuals).

At lot of things are not described, unfortunately...

> So I could handle differently according to SoC.
> Unfortunately there is not TCON register keeping IP version,
> so the only way I see is to create a long if-or statement to understand
> which kind of TCON we're using.

You can base that on the compatible, and add a field in the
sun4i_tcon_quirks structure, that will avoid the if statements you
mentionned.

> But what sounds not the best to me, is that DCLK is divided by 2 if
> using phase 90. So we need to reconsider also bitclock driver according
> to this.
> I don't know if it make sense.
> 
> IMHO, I would keep only:
> - As normal => "0x1 => 1/3 phase"

So that would mean sampling at raising edge on this one??

> - As inverted => "0x0 => normal phase"

And falling edge?

If so, and if remember the captures properly, the sampling would occur
right before the rise, and not really around the fall.

Would 2/3 be better here?

> According to scope captures above on both A20 and A33.
> Unfortunately I don't have other boards for the other SoCs to take captures.
> 
> What do you think?

I guess we can make that part applicable to all SoCs, we haven't seen
any significant differences on those part.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Harry Wentland]

On 2018-02-08 04:03 PM, Harry Wentland wrote:
> On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
>> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
>> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
>> instead, which expects as parameter the alignment in bytes, and not a
>> power of two like -mpreferred-stack-boundary.
>>
>> Probe for both compiler options and use the correct one, similar to
>> what is done in arch/x86/Makefile.
>>
>> Signed-off-by: Matthias Kaehlcke 
> 
> Series is
> Reviewed-by: Harry Wentland 

... and merged to amd-staging-drm-next.

I had to resolve a small conflict with patches 1 & 2. Not a big deal but 
curious what development branch you use. We normally use this for amd-gfx 
development: 
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next (although 
it might be a bit behind our internal dev tree).

Harry

> 
> Harry
> 
>> ---
>> Changes in v3:
>> - patch added
>>
>> Note to self: if this patterns proliferates further we probably want to
>> put the evaluation of the correct compiler flag in some common place.
>>
>>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
>> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> index af0f452f3c9f..95f332ee3e7e 100644
>> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
>> @@ -24,7 +24,13 @@
>>  # It calculates Bandwidth and Watermarks values for HW programming
>>  #
>>  
>> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
>> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
>> +cc_stack_align := -mpreferred-stack-boundary=4
>> +else ifneq ($(call cc-option, -mstack-alignment=16),)
>> +cc_stack_align := -mstack-alignment=16
>> +endif
>> +
>> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
>>  
>>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
>>
> ___
> 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 104919] R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert "drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs" v2

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #7 from Andy Furniss  ---
Fix is in affected kernels.

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

[PATCH 0/3] drm/amd/powerplay/hwmgr: Adjustments for eight function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:37:42 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in three functions
  Adjust layout for source code from five if statements
  Delete an unnecessary return statement in three functions

 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 37 ++
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 35 +---
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c   |  5 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c |  4 +--
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  1 -
 5 files changed, 35 insertions(+), 47 deletions(-)

-- 
2.16.1

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

[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).

[bugzilla-daemon]

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

--- Comment #5 from Eugene (ken20...@ukr.net) ---
Created attachment 274071
  --> https://bugzilla.kernel.org/attachment.cgi?id=274071=edit
dmesg_GA-MA790FX-DQ6

-- 
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 3/3] drm/amd/powerplay/hwmgr: Delete an unnecessary return statement in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 21:10:58 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: void function return statements are not generally useful

Thus remove such a statement in the affected functions.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 3 ---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 2681c9317d25..e07b32491092 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -653,8 +653,6 @@ void phm_trim_voltage_table_to_fit_state_table(uint32_t 
max_vol_steps,
vol_table->entries[i] = vol_table->entries[i + diff];
 
vol_table->count = max_vol_steps;
-
-   return;
 }
 
 int phm_reset_single_dpm_table(void *table,
@@ -906,7 +904,6 @@ void hwmgr_init_default_caps(struct pp_hwmgr *hwmgr)
 
phm_cap_set(hwmgr->platform_descriptor.platformCaps,

PHM_PlatformCaps_FanSpeedInTableIsRPM);
-   return;
 }
 
 int hwmgr_set_user_specify_caps(struct pp_hwmgr *hwmgr)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 2d55dabc77d4..fcdb3563d860 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3618,7 +3618,6 @@ static uint32_t vega10_find_highest_dpm_level(
 static void vega10_apply_dal_minimum_voltage_request(
struct pp_hwmgr *hwmgr)
 {
-   return;
 }
 
 static int vega10_get_soc_index_for_max_uclk(struct pp_hwmgr *hwmgr)
-- 
2.16.1

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

[PATCH] drm/amdkfd: Delete an error message for a failed memory allocation in kfd_topology_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Thu, 8 Feb 2018 22:23:57 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 19ce59028d6b..610e3d4ac575 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -1019,7 +1019,6 @@ int kfd_topology_init(void)
crat_image = kmalloc(image_size, GFP_KERNEL);
if (!crat_image) {
ret = -ENOMEM;
-   pr_err("No memory for allocating CRAT image\n");
goto err;
}
ret = kfd_topology_get_crat_acpi(crat_image, _size);
-- 
2.16.1

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

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Harry Wentland]

On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> instead, which expects as parameter the alignment in bytes, and not a
> power of two like -mpreferred-stack-boundary.
> 
> Probe for both compiler options and use the correct one, similar to
> what is done in arch/x86/Makefile.
> 
> Signed-off-by: Matthias Kaehlcke 

Series is
Reviewed-by: Harry Wentland 

Harry

> ---
> Changes in v3:
> - patch added
> 
> Note to self: if this patterns proliferates further we probably want to
> put the evaluation of the correct compiler flag in some common place.
> 
>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> index af0f452f3c9f..95f332ee3e7e 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> @@ -24,7 +24,13 @@
>  # It calculates Bandwidth and Watermarks values for HW programming
>  #
>  
> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> + cc_stack_align := -mpreferred-stack-boundary=4
> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> + cc_stack_align := -mstack-alignment=16
> +endif
> +
> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
>  
>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] meson: include headers in root directory in ext_libdrm

[Dylan Baker]

Which is used in wraps.
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 1342a5b3..4aaeb7e1 100644
--- a/meson.build
+++ b/meson.build
@@ -294,7 +294,7 @@ libdrm = shared_library(
 
 ext_libdrm = declare_dependency(
   link_with : libdrm,
-  include_directories : inc_drm,
+  include_directories : [inc_root, inc_drm],
 )
 
 install_headers('libsync.h', 'xf86drm.h', 'xf86drmMode.h')
-- 
2.16.0

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

Re: [PATCH v3 4/4] amdgpu/dc/calcs: Support clang option for stack alignment

[Matthias Kaehlcke]

El Thu, Feb 08, 2018 at 04:44:21PM -0500 Harry Wentland ha dit:

> On 2018-02-08 04:03 PM, Harry Wentland wrote:
> > On 2018-02-08 03:53 PM, Matthias Kaehlcke wrote:
> >> calcs uses the compiler option -mpreferred-stack-boundary=4 to configure
> >> a stack alignment of 16 bytes. Clang uses the option -mstack-alignment
> >> instead, which expects as parameter the alignment in bytes, and not a
> >> power of two like -mpreferred-stack-boundary.
> >>
> >> Probe for both compiler options and use the correct one, similar to
> >> what is done in arch/x86/Makefile.
> >>
> >> Signed-off-by: Matthias Kaehlcke 
> > 
> > Series is
> > Reviewed-by: Harry Wentland 
> 
> ... and merged to amd-staging-drm-next.

Thanks!

> I had to resolve a small conflict with patches 1 & 2. Not a big deal but 
> curious what development branch you use. We normally use this for amd-gfx 
> development: 
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next 
> (although it might be a bit behind our internal dev tree).

I typically use Linus' tree as base, will try to remember to check
future patches against amd-staging-drm-next.

> >> ---
> >> Changes in v3:
> >> - patch added
> >>
> >> Note to self: if this patterns proliferates further we probably want to
> >> put the evaluation of the correct compiler flag in some common place.
> >>
> >>  drivers/gpu/drm/amd/display/dc/calcs/Makefile | 8 +++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile 
> >> b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> index af0f452f3c9f..95f332ee3e7e 100644
> >> --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
> >> @@ -24,7 +24,13 @@
> >>  # It calculates Bandwidth and Watermarks values for HW programming
> >>  #
> >>  
> >> -calcs_ccflags := -mhard-float -msse -mpreferred-stack-boundary=4
> >> +ifneq ($(call cc-option, -mpreferred-stack-boundary=4),)
> >> +  cc_stack_align := -mpreferred-stack-boundary=4
> >> +else ifneq ($(call cc-option, -mstack-alignment=16),)
> >> +  cc_stack_align := -mstack-alignment=16
> >> +endif
> >> +
> >> +calcs_ccflags := -mhard-float -msse $(cc_stack_align)
> >>  
> >>  CFLAGS_dcn_calcs.o := $(calcs_ccflags)
> >>  CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
> >>
> > ___
> > 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 1/3] drm: add func to get max iomem address

[Christian König]

Am 08.02.2018 um 09:32 schrieb Chunming Zhou:

it will be used to check if the driver needs swiotlb

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 


Reviewed-by: Christian König  for the whole 
series.



---
  include/drm/drm_cache.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..442c9ba63d03 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
num_pages);
  void drm_clflush_sg(struct sg_table *st);
  void drm_clflush_virt_range(void *addr, unsigned long length);
  
+static inline u64 drm_get_max_iomem(void)

+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}
+
+
  static inline bool drm_arch_can_wc_memory(void)
  {
  #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)


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

Re: [PATCH v4 02/12] clk: sunxi-ng: Use u64 for calculation of nkmp rate

[Maxime Ripard]

On Wed, Feb 07, 2018 at 10:17:03PM +0100, Jernej Skrabec wrote:
> When parent rate is 24MHz and multiplier N >= 180, intermediate clock
> rate doesn't fit in 32 bit variable anymore.
> 
> Because of that, introduce function for calculating clock rate which
> uses 64 bit variable for intermediate result.
> 
> Signed-off-by: Jernej Skrabec 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com


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

Re: [PATCH v2] drm/bridge/synopsys: dsi: Add 1.31 version support

[Philippe CORNU]

Many thanks
Philippe :-)

On 02/08/2018 08:39 AM, Andrzej Hajda wrote:
> On 06.02.2018 09:42, Philippe Cornu wrote:
>> Add support for the Synopsys DesignWare MIPI DSI version 1.31
>> Two registers need to be updated/added for supporting 1.31:
>> * PHY_TMR_CFG 0x9c (updated)
>>1.30 [31:24] phy_hs2lp_time
>> [23:16] phy_lp2hs_time
>> [14: 0] max_rd_time
>>
>>1.31 [25:16] phy_hs2lp_time
>> [ 9: 0] phy_lp2hs_time
>>
>> * PHY_TMR_RD_CFG 0xf4 (new)
>>1.31 [14: 0] max_rd_time
>>
>> Signed-off-by: Philippe Cornu 
> Queued to drm-misc-next.
> --
> Regards
> Andrzej
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge/synopsys: dsi: Add read feature

[Philippe CORNU]

Many thanks
Philippe :-)

On 02/08/2018 08:39 AM, Andrzej Hajda wrote:
> On 04.02.2018 22:31, Philippe Cornu wrote:
>> This patch adds the DCS/GENERIC DSI read feature.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
> Queued to drm-misc-next.
> --
> Regards
> Andrzej
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/amdgpu: only enable swiotlb alloc when need

[Christian König]

Am 08.02.2018 um 07:00 schrieb Chunming Zhou:

get the max io mapping address of system memory to see if it is over
our card accessing range.

Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   | 2 ++
  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 2 ++
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 2 ++
  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 2 ++
  6 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 257424dd8a52..627a06185368 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1437,6 +1437,7 @@ struct amdgpu_device {
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
struct work_struct  reset_work;
struct notifier_block   acpi_nb;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..a021de9629ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1018,7 +1018,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
}
  
  #ifdef CONFIG_SWIOTLB

-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, adev->dev, ctx);
}
  #endif
@@ -1045,7 +1045,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
adev = amdgpu_ttm_adev(ttm->bdev);
  
  #ifdef CONFIG_SWIOTLB

-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
return;
}
@@ -2007,7 +2007,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
  
  #ifdef CONFIG_SWIOTLB

-   if (!swiotlb_nr_tbl())
+   if (!(adev->need_swiotlb && swiotlb_nr_tbl()))
--count;
  #endif
  
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c

index 5eacc0819b66..63d0720ac21f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -22,6 +22,7 @@
   */
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "gmc_v6_0.h"
  #include "amdgpu_ucode.h"
@@ -855,6 +856,7 @@ static int gmc_v6_0_sw_init(void *handle)
  
  	adev->need_dma32 = false;

dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);


The code here is mixed up. The check needs to come later, after we tried 
to set the dma_mask and possible failed.


Same for all other GMC variants as well.

Apart from that the series looks good to me,
Christian.


r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index ce7f484f86f9..f70a81fcadec 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -22,6 +22,7 @@
   */
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "cikd.h"
  #include "cik.h"
@@ -1003,6 +1004,7 @@ static int gmc_v7_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index f53f3936fd4f..21fe9afb6e73 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -22,6 +22,7 @@
   */
  #include 
  #include 
+#include 
  #include "amdgpu.h"
  #include "gmc_v8_0.h"
  #include "amdgpu_ucode.h"
@@ -1101,6 +1102,7 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 2c60981d2eec..8730768efd13 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -21,6 +21,7 @@
   *
   */
  #include 
+#include 
  #include "amdgpu.h"
  #include "gmc_v9_0.h"
  #include 

[PATCH 3/3] drm/radeon: only enable swiotlb path when need v2

[Chunming Zhou]

swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later

Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 2 ++
 drivers/gpu/drm/radeon/radeon_ttm.c| 6 +++---
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d34887873dea..4a2eb409aacc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2387,6 +2387,7 @@ struct radeon_device {
struct radeon_dummy_pagedummy_page;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
boolneeds_reset, in_reset;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 8d3e3d2e0090..7f40c6f7c4dd 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1378,6 +1379,7 @@ int radeon_device_init(struct radeon_device *rdev,
pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32));
pr_warn("radeon: No coherent DMA available\n");
}
+   rdev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
/* Registers mapping */
/* TODO: block userspace mapping of io register */
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..c1e3862a48a4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -756,7 +756,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm,
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, rdev->dev, ctx);
}
 #endif
@@ -788,7 +788,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, rdev->dev);
return;
}
@@ -1155,7 +1155,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
count = ARRAY_SIZE(radeon_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(rdev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
-- 
2.14.1

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

[PATCH 2/3] drm/amdgpu: only enable swiotlb alloc when need v2

[Chunming Zhou]

get the max io mapping address of system memory to see if it is over
our card accessing range.
v2: move checking later

Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 3 +++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 2 ++
 6 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 257424dd8a52..627a06185368 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1437,6 +1437,7 @@ struct amdgpu_device {
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
struct work_struct  reset_work;
struct notifier_block   acpi_nb;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..a021de9629ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1018,7 +1018,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
}
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, adev->dev, ctx);
}
 #endif
@@ -1045,7 +1045,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
adev = amdgpu_ttm_adev(ttm->bdev);
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
return;
}
@@ -2007,7 +2007,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(adev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 5eacc0819b66..1945fe842188 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v6_0.h"
 #include "amdgpu_ucode.h"
@@ -866,6 +867,7 @@ static int gmc_v6_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
dev_warn(adev->dev, "amdgpu: No coherent DMA available.\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v6_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index ce7f484f86f9..761def04f93f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "cikd.h"
 #include "cik.h"
@@ -1014,6 +1015,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index f53f3936fd4f..2489be7ad62b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v8_0.h"
 #include "amdgpu_ucode.h"
@@ -1101,6 +1102,7 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
@@ -1112,6 +1114,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 2c60981d2eec..0f4a9a8575a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ 

[PATCH 1/3] drm: add func to get max iomem address

[Chunming Zhou]

it will be used to check if the driver needs swiotlb

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
---
 include/drm/drm_cache.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..442c9ba63d03 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
num_pages);
 void drm_clflush_sg(struct sg_table *st);
 void drm_clflush_virt_range(void *addr, unsigned long length);
 
+static inline u64 drm_get_max_iomem(void)
+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}
+
+
 static inline bool drm_arch_can_wc_memory(void)
 {
 #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
-- 
2.14.1

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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

ragnaros39...@yandex.com changed:

   What|Removed |Added

   Keywords||regression
   Priority|medium  |high

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

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Hyun Kwon]

Hi Daniel,

On Tue, 2018-01-30 at 02:27:07 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> > 
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
> > 
> > Signed-off-by: Hyun Kwon 
> 
> Another thought: If we require that a format description has either cpp or
> the macro-pixel stuff set (but not both), then we could avoid changing the
> entire table. Calculating the width in bytes would first use cpp, and if
> that's 0, try to compute the width using the macro-pixel stuff. And if
> that's also 0, then WARN_ON (since it's a kernel bug).

That certainly will minimize the change. Thanks a lot for suggestion! I will
address your comments in next version.

Thanks,
-hyun

> -Daniel
> 
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 
> > +--
> >  include/drm/drm_fourcc.h |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  const struct drm_format_info *__drm_format_info(u32 format)
> >  {
> > static const struct drm_format_info formats[] = {
> > -   { .format = DRM_FORMAT_C8,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR1555,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA5551,.depth = 15, 
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA5551,.depth = 15, 
> > .num_planes = 1, 

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #10 from Michael Zapf  ---
I now believe there is a general problem with amdgpu's new DC. 

On another system, without an AV receiver in the chain, my display resolution
is reset to 1368x768 when I turn off the monitor and back on. That's a really
mess (not only my desktop after that). I have to reboot to get the full
resolution again; killing X or unplugging the monitor does not restore it.

Seems as if I have to turn off DC again and wait for a fix. 

I have this issue in my office (RX460) and on my second PC (RX580),
reproduceably, all running openSUSE Tumbleweed, 4.15.1.

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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

Bug ID: 105018
   Summary: Kernel panic when waking up after screen goes blank.
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ragnaros39...@yandex.com

I'm currently running on latest Manjaro XFCE with the 4.15 kernel just
released, and I found that the system would crash when trying to wake up after
the screen went blank.

The system is an AMD Laptop (ASUS ROG STRIX GL702ZC), and the problem is 100%
reproducible with the following steps:

- Lock the screen, leave the screen blank for at least 3-5 minutes.
- Try wake the screen up, like moving the mouse cursor.

At first I did not find the cause, but after looking into the journalctl I was
able to find something that appears to be a kernel panic. It existed since the
beginning, with the 4.14 kernel, and remained unsolved even after upgrading to
4.15 kernel.

Feb 07 11:48:59 linuxsys kernel: BUG: unable to handle kernel NULL pointer
dereference at   (null)
Feb 07 11:48:59 linuxsys kernel: IP: dce110_vblank_set+0x4f/0xb0 [amdgpu]
Feb 07 11:48:59 linuxsys kernel: PGD 7e2ac2067 P4D 7e2ac2067 PUD 7e2a7e067 PMD
0 
Feb 07 11:48:59 linuxsys kernel: Oops:  [#1] PREEMPT SMP NOPTI
Feb 07 11:48:59 linuxsys kernel: Modules linked in: vmw_vsock_vmci_transport
vsock rfcomm fuse bnep vmnet(O) arc4 amdkfd nls_iso8859_1 amd_iommu_v2
nls_cp437 vfat fat amdgpu iwlmvm uvcvideo mac80211 videobuf2_vmalloc
edac_mce_amd btusb vide
Feb 07 11:48:59 linuxsys kernel:  rng_core cryptd pcspkr k10temp i2c_piix4
shpchp battery wmi thermal ac tpm_crb tpm_tis tpm_tis_core video tpm
asus_wireless i2c_hid button acpi_cpufreq sch_fq_codel vmmon(O) vmw_vmci
vboxnetflt(O) vboxnetad
Feb 07 11:48:59 linuxsys kernel: CPU: 15 PID: 1467 Comm: xfwm4 Tainted: G  
 W  O 4.15.0-1-MANJARO #1
Feb 07 11:48:59 linuxsys kernel: Hardware name: ASUSTeK COMPUTER INC.
GL702ZC/GL702ZC, BIOS GL702ZC.303 12/15/2017
Feb 07 11:48:59 linuxsys kernel: RIP: 0010:dce110_vblank_set+0x4f/0xb0 [amdgpu]
Feb 07 11:48:59 linuxsys kernel: RSP: 0018:b4e388c7bbe0 EFLAGS: 00010002
Feb 07 11:48:59 linuxsys kernel: RAX: 9b458850c000 RBX: 0001
RCX: 
Feb 07 11:48:59 linuxsys kernel: RDX:  RSI: 000c
RDI: 
Feb 07 11:48:59 linuxsys kernel: RBP: 9b4b2f4168e0 R08: 
R09: 
Feb 07 11:48:59 linuxsys kernel: R10: 7fff89afe9f0 R11: 9b4b2b86ac40
R12: 9b4b38511a80
Feb 07 11:48:59 linuxsys kernel: R13: c12bbba0 R14: 9b4b281f
R15: 9b4b3ab4cb68
Feb 07 11:48:59 linuxsys kernel: FS:  7f0bdae66980()
GS:9b4b3e9c() knlGS:
Feb 07 11:48:59 linuxsys kernel: CS:  0010 DS:  ES:  CR0:
80050033
Feb 07 11:48:59 linuxsys kernel: CR2:  CR3: 0007d96c8000
CR4: 003406e0
Feb 07 11:48:59 linuxsys kernel: Call Trace:
Feb 07 11:48:59 linuxsys kernel:  amdgpu_dm_set_crtc_irq_state+0x31/0x60
[amdgpu]
Feb 07 11:48:59 linuxsys kernel:  amdgpu_irq_update+0x55/0x90 [amdgpu]
Feb 07 11:48:59 linuxsys kernel:  drm_vblank_enable+0x84/0x100 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_vblank_get+0x8d/0xb0 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_wait_vblank_ioctl+0x12a/0x690 [drm]
Feb 07 11:48:59 linuxsys kernel:  ? unix_stream_recvmsg+0x53/0x70
Feb 07 11:48:59 linuxsys kernel:  ? drm_legacy_modeset_ctl_ioctl+0x100/0x100
[drm]
Feb 07 11:48:59 linuxsys kernel:  drm_ioctl_kernel+0x5b/0xb0 [drm]
Feb 07 11:48:59 linuxsys kernel:  drm_ioctl+0x2d5/0x370 [drm]
Feb 07 11:48:59 linuxsys kernel:  ? drm_legacy_modeset_ctl_ioctl+0x100/0x100
[drm]
Feb 07 11:48:59 linuxsys kernel:  ? do_iter_write+0xdc/0x190
Feb 07 11:48:59 linuxsys kernel:  ? vfs_writev+0xb9/0x110
Feb 07 11:48:59 linuxsys kernel:  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
Feb 07 11:48:59 linuxsys kernel:  do_vfs_ioctl+0xa4/0x630
Feb 07 11:48:59 linuxsys kernel:  ? __sys_recvmsg+0x4e/0x90
Feb 07 11:48:59 linuxsys kernel:  ? __sys_recvmsg+0x7d/0x90
Feb 07 11:48:59 linuxsys kernel:  SyS_ioctl+0x74/0x80
Feb 07 11:48:59 linuxsys kernel:  entry_SYSCALL_64_fastpath+0x20/0x83
Feb 07 11:48:59 linuxsys kernel: RIP: 0033:0x7f0bd74b3d87
Feb 07 11:48:59 linuxsys kernel: RSP: 002b:7fff89afea38 EFLAGS: 0246
Feb 07 11:48:59 linuxsys kernel: Code: e8 17 20 04 00 83 e8 4e 0f b6 d0 48 89
d0 48 c1 e0 05 48 01 d0 48 c1 e0 05 49 03 86 60 01 00 00 84 db 48 8b b8 78 02
00 00 74 18 <48> 8b 07 be 02 00 00 00 48 8b 80 d8 00 00 00 e8 6d 43 7e ee 84 
Feb 07 11:48:59 linuxsys kernel: RIP: dce110_vblank_set+0x4f/0xb0 [amdgpu] RSP:
b4e388c7bbe0
Feb 07 11:48:59 linuxsys kernel: CR2: 
Feb 07 11:48:59 linuxsys kernel: ---[ end trace 36522610c84ff0f3 ]---

The cause 

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

"Pandiyan, Dhinakaran"  writes:

> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>> > The current PSR code has a two call sites that each schedule delayed
>> > work to activate PSR.  As far as I can tell, each call site intends
>> > to keep PSR inactive for the given amount of time and then allow it
>> > to be activated.
>> >
>> > The call sites are:
>> >
>> >  - intel_psr_enable(), which explicitly states in a comment that
>> >it's trying to keep PSR off a short time after the dispay is
>> >initialized as a workaround.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>> >
>> >  - intel_psr_flush().  There isn't an explcit explanation, but the
>> >intent is presumably to keep PSR off until the display has been
>> >idle for 100ms.
>> 
>> The reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>> >
>> > The current code doesn't actually accomplish either of these goals.
>> > Rather than keeping PSR inactive for the given amount of time, it
>> > will schedule PSR for activation after the given time, with the
>> > earliest target time in such a request winning.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>  if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>> >
>> > In other words, if intel_psr_enable() is immediately followed by
>> > intel_psr_flush(), then PSR will be activated after 100ms even if
>> > intel_psr_enable() wanted a longer delay.  And, if the screen is
>> > being constantly updated so that intel_psr_flush() is called once
>> > per frame at 60Hz, PSR will still be activated once every 100ms.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))
>
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?

That's not my understanding of work_busy man.

"work_busy - test whether a work is currently pending or running"

I consider it as pending one...

But yeap... it was a long time ago that I did this so I'm not sure...

>
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
>
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 
>
>
> However, I think 
>
>   if (dev_priv->psr.busy_frontbuffer_bits)
>   goto unlock;
>
>   intel_psr_activate(intel_dp);
>
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
>
>
>
>
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

> On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
>  wrote:
> 
> 
>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
>> Hi Andy,
>> 
>> thanks for getting involved with PSR and sorry for not replying sooner.
>> 
>> I first saw this patch on that bugzilla entry but only now I stop to
>> really think why I have written the code that way.
>> 
>> So some clarity below.
>> 
>>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
>>> The current PSR code has a two call sites that each schedule delayed
>>> work to activate PSR.  As far as I can tell, each call site intends
>>> to keep PSR inactive for the given amount of time and then allow it
>>> to be activated.
>>> 
>>> The call sites are:
>>> 
>>> - intel_psr_enable(), which explicitly states in a comment that
>>>   it's trying to keep PSR off a short time after the dispay is
>>>   initialized as a workaround.
>> 
>> First of all I really want to kill this call here and remove the
>> FIXME. It was an ugly hack that I added to solve a corner case
>> that was leaving me with blank screens when activating so sooner.
>> 
>>> 
>>> - intel_psr_flush().  There isn't an explcit explanation, but the
>>>   intent is presumably to keep PSR off until the display has been
>>>   idle for 100ms.
>> 
>> The reason for 100 is kind of ugly-nonsense-empirical value
>> I concluded from VLV/CHV experience.
>> On platforms with HW tracking HW waits few identical frames
>> until really activating PSR. VLV/CHV activation is immediate.
>> But HW is also different and there it seemed that hw needed a
>> few more time before starting the transitions.
>> Furthermore I didn't want to add that so quickly because I didn't
>> want to take the risk of killing battery with software tracking
>> when doing transitions so quickly using software tracking.
>> 
>>> 
>>> The current code doesn't actually accomplish either of these goals.
>>> Rather than keeping PSR inactive for the given amount of time, it
>>> will schedule PSR for activation after the given time, with the
>>> earliest target time in such a request winning.
>> 
>> Putting that way I was asking myself how that hack had ever fixed
>> my issue. Because the way you explained here seems obvious that it
>> wouldn't ever fix my bug or any other.
>> 
>> So I applied your patch and it made even more sense (without considering
>> the fact I want to kill the first call anyways).
>> 
>> So I came back, removed your patch and tried to understand how did
>> it ever worked.
>> 
>> So, the thing is that intel_psr_flush will never be really executed
>> if intel_psr_enable wasn't executed. That is guaranteed by:
>> 
>> mutex_lock(_priv->psr.lock);
>>if (!dev_priv->psr.enabled) {
>> 
>> So, intel_psr_enable will be for sure the first one to schedule the
>> work delayed to the ugly higher delay.
>> 
>>> 
>>> In other words, if intel_psr_enable() is immediately followed by
>>> intel_psr_flush(), then PSR will be activated after 100ms even if
>>> intel_psr_enable() wanted a longer delay.  And, if the screen is
>>> being constantly updated so that intel_psr_flush() is called once
>>> per frame at 60Hz, PSR will still be activated once every 100ms.
>> 
>> During this time you are right, many calls of intel_psr_exit
>> coming from flush functions can be called... But none of
>> them will schedule the work with 100 delay.
>> 
>> they will skip on
>> if (!work_busy(_priv->psr.work.work))

As below, the first call will.  Then, 100ms later, the work will fire.  Then 
the next flush will schedule it again, etc.

> 
> Wouldn't work_busy() return false until the work is actually queued
> which is 100ms after calling schedule_delayed_work()?
> 
> For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> until 100ms.
> 
> The first psr_work will end up getting scheduled at 100ms, which I
> believe is not what we want. 

Indeed.  I stuck some printks in and this seems to be what happens.

> 
> 
> However, I think 
> 
>if (dev_priv->psr.busy_frontbuffer_bits)
>goto unlock;
> 
>intel_psr_activate(intel_dp);
> 
> in psr_work might prevent activate being called at 100ms if an
> invalidate happened to be called before that.
> 

On my system, invalidate is never called.  Even if it were called, that check 
would only help if we got lucky and the work fired after invalidate and before 
the subsequent flush.

> 
> 
> 
>> 
>> So, the higher delayed *hack* will be respected and PSR won't get
>> activated before that.
>> 
>> On the other hand you might ask what if,
>> for some strange reason,
>> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
>> Well, on this case this would be ok, because it happens only
>> once and only on gen > 9 where hw tracking will wait the minimal
>> number of frames before the actual transition to PSR.
>> 
>> In either cases I believe we are safe.
>> 
>> Thanks,
>> Rodrigo.
___
dri-devel mailing list

[PATCH 1/3] drm: add func to get max iomem address v2

[Chunming Zhou]

it will be used to check if the driver needs swiotlb
v2: Don't use inline, instead, move function to drm_memory.c (Mechel Daenzer 
)

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/drm_memory.c | 13 +
 include/drm/drm_cache.h  |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index fc0ebd273ef8..7ca500b8c399 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -149,3 +149,16 @@ void drm_legacy_ioremapfree(struct drm_local_map *map, 
struct drm_device *dev)
iounmap(map->handle);
 }
 EXPORT_SYMBOL(drm_legacy_ioremapfree);
+
+u64 drm_get_max_iomem(void)
+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}
+EXPORT_SYMBOL(drm_get_max_iomem);
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..bfe1639df02d 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -38,6 +38,8 @@
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
 void drm_clflush_sg(struct sg_table *st);
 void drm_clflush_virt_range(void *addr, unsigned long length);
+u64 drm_get_max_iomem(void);
+
 
 static inline bool drm_arch_can_wc_memory(void)
 {
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

Hi Andy,

thanks for getting involved with PSR and sorry for not replying sooner.

I first saw this patch on that bugzilla entry but only now I stop to
really think why I have written the code that way.

So some clarity below.

On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR.  As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to be activated.
>
> The call sites are:
>
>  - intel_psr_enable(), which explicitly states in a comment that
>it's trying to keep PSR off a short time after the dispay is
>initialized as a workaround.

First of all I really want to kill this call here and remove the
FIXME. It was an ugly hack that I added to solve a corner case
that was leaving me with blank screens when activating so sooner.

>
>  - intel_psr_flush().  There isn't an explcit explanation, but the
>intent is presumably to keep PSR off until the display has been
>idle for 100ms.

The reason for 100 is kind of ugly-nonsense-empirical value
I concluded from VLV/CHV experience.
On platforms with HW tracking HW waits few identical frames
until really activating PSR. VLV/CHV activation is immediate.
But HW is also different and there it seemed that hw needed a
few more time before starting the transitions.
Furthermore I didn't want to add that so quickly because I didn't
want to take the risk of killing battery with software tracking
when doing transitions so quickly using software tracking.

>
> The current code doesn't actually accomplish either of these goals.
> Rather than keeping PSR inactive for the given amount of time, it
> will schedule PSR for activation after the given time, with the
> earliest target time in such a request winning.

Putting that way I was asking myself how that hack had ever fixed
my issue. Because the way you explained here seems obvious that it
wouldn't ever fix my bug or any other.

So I applied your patch and it made even more sense (without considering
the fact I want to kill the first call anyways).

So I came back, removed your patch and tried to understand how did
it ever worked.

So, the thing is that intel_psr_flush will never be really executed
if intel_psr_enable wasn't executed. That is guaranteed by:

mutex_lock(_priv->psr.lock);
if (!dev_priv->psr.enabled) {

So, intel_psr_enable will be for sure the first one to schedule the
work delayed to the ugly higher delay.

>
> In other words, if intel_psr_enable() is immediately followed by
> intel_psr_flush(), then PSR will be activated after 100ms even if
> intel_psr_enable() wanted a longer delay.  And, if the screen is
> being constantly updated so that intel_psr_flush() is called once
> per frame at 60Hz, PSR will still be activated once every 100ms.

During this time you are right, many calls of intel_psr_exit
coming from flush functions can be called... But none of
them will schedule the work with 100 delay.

they will skip on
if (!work_busy(_priv->psr.work.work))

So, the higher delayed *hack* will be respected and PSR won't get
activated before that.

On the other hand you might ask what if,
for some strange reason,
(intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
Well, on this case this would be ok, because it happens only
once and only on gen > 9 where hw tracking will wait the minimal
number of frames before the actual transition to PSR.

In either cases I believe we are safe.

Thanks,
Rodrigo.

>
> Rewrite the code so that it does what was intended.  This adds
> a new function intel_psr_schedule(), which will enable PSR after
> the requested time but no sooner.
>
> Signed-off-by: Andy Lutomirski 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++-
>  drivers/gpu/drm/i915/intel_psr.c| 69 
> -
>  3 files changed, 71 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c65e381b85f3..b67db93f905d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2663,8 +2663,13 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>  dev_priv->psr.busy_frontbuffer_bits);
> - seq_printf(m, "Re-enable work scheduled: %s\n",
> -yesno(work_busy(_priv->psr.work.work)));
> +
> + if (timer_pending(_priv->psr.activate_timer))
> + seq_printf(m, "Activate scheduled: yes, in %ldms\n",
> +(long)(dev_priv->psr.earliest_activate - jiffies) *
> +1000 / HZ);
> + else
> + seq_printf(m, "Re-enable scheduled: no\n");
>
>   if (HAS_DDI(dev_priv)) {
>   

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> Hi Andy,
> 
> thanks for getting involved with PSR and sorry for not replying sooner.
> 
> I first saw this patch on that bugzilla entry but only now I stop to
> really think why I have written the code that way.
> 
> So some clarity below.
> 
> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> > The current PSR code has a two call sites that each schedule delayed
> > work to activate PSR.  As far as I can tell, each call site intends
> > to keep PSR inactive for the given amount of time and then allow it
> > to be activated.
> >
> > The call sites are:
> >
> >  - intel_psr_enable(), which explicitly states in a comment that
> >it's trying to keep PSR off a short time after the dispay is
> >initialized as a workaround.
> 
> First of all I really want to kill this call here and remove the
> FIXME. It was an ugly hack that I added to solve a corner case
> that was leaving me with blank screens when activating so sooner.
> 
> >
> >  - intel_psr_flush().  There isn't an explcit explanation, but the
> >intent is presumably to keep PSR off until the display has been
> >idle for 100ms.
> 
> The reason for 100 is kind of ugly-nonsense-empirical value
> I concluded from VLV/CHV experience.
> On platforms with HW tracking HW waits few identical frames
> until really activating PSR. VLV/CHV activation is immediate.
> But HW is also different and there it seemed that hw needed a
> few more time before starting the transitions.
> Furthermore I didn't want to add that so quickly because I didn't
> want to take the risk of killing battery with software tracking
> when doing transitions so quickly using software tracking.
> 
> >
> > The current code doesn't actually accomplish either of these goals.
> > Rather than keeping PSR inactive for the given amount of time, it
> > will schedule PSR for activation after the given time, with the
> > earliest target time in such a request winning.
> 
> Putting that way I was asking myself how that hack had ever fixed
> my issue. Because the way you explained here seems obvious that it
> wouldn't ever fix my bug or any other.
> 
> So I applied your patch and it made even more sense (without considering
> the fact I want to kill the first call anyways).
> 
> So I came back, removed your patch and tried to understand how did
> it ever worked.
> 
> So, the thing is that intel_psr_flush will never be really executed
> if intel_psr_enable wasn't executed. That is guaranteed by:
> 
> mutex_lock(_priv->psr.lock);
>   if (!dev_priv->psr.enabled) {
> 
> So, intel_psr_enable will be for sure the first one to schedule the
> work delayed to the ugly higher delay.
> 
> >
> > In other words, if intel_psr_enable() is immediately followed by
> > intel_psr_flush(), then PSR will be activated after 100ms even if
> > intel_psr_enable() wanted a longer delay.  And, if the screen is
> > being constantly updated so that intel_psr_flush() is called once
> > per frame at 60Hz, PSR will still be activated once every 100ms.
> 
> During this time you are right, many calls of intel_psr_exit
> coming from flush functions can be called... But none of
> them will schedule the work with 100 delay.
> 
> they will skip on
> if (!work_busy(_priv->psr.work.work))

Wouldn't work_busy() return false until the work is actually queued
which is 100ms after calling schedule_delayed_work()?

For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
until 100ms.

The first psr_work will end up getting scheduled at 100ms, which I
believe is not what we want. 


However, I think 

if (dev_priv->psr.busy_frontbuffer_bits)
goto unlock;

intel_psr_activate(intel_dp);

in psr_work might prevent activate being called at 100ms if an
invalidate happened to be called before that.




> 
> So, the higher delayed *hack* will be respected and PSR won't get
> activated before that.
> 
> On the other hand you might ask what if,
> for some strange reason,
> (intel_dp->panel_power_cycle_delay * 5) is lesser than 100.
> Well, on this case this would be ok, because it happens only
> once and only on gen > 9 where hw tracking will wait the minimal
> number of frames before the actual transition to PSR.
> 
> In either cases I believe we are safe.
> 
> Thanks,
> Rodrigo.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104142] Stack trace in runpm when Tonga card powers down

[bugzilla-daemon]

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

--- Comment #5 from JohnDoe  ---
I ran into this bug when upgrading to 4.15.1. Anything I can do to help?

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

[RFC][PATCH v3] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.

Feedback or comments would be greatly appreciated!

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Change-Id: I81abdd4d1dc7d9f2ef31078c91679b532d3262fd
Signed-off-by: John Stultz 
---
The full patchset I'm testing with can be found here:
https://github.com/johnstultz-work/drm_hwcomposer/commits/drm_hwc

v2:
* Make platformhisi and the generic importer exclusive in the build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to reduce
  code duplication
* Rework to avoid board specific logic (tweak gralloc to be consistent
  between the two)
---
 Android.mk   |  13 +
 platformdrmgeneric.h |   2 +-
 platformhisi.cpp | 132 +++
 platformhisi.h   |  48 +++
 4 files changed, 194 insertions(+), 1 deletion(-)
 create mode 100644 platformhisi.cpp
 create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index ee5b8bf..f37e4c3 100644
--- a/Android.mk
+++ b/Android.mk
@@ -74,7 +74,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
 
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
 LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
 
 LOCAL_MODULE := hwcomposer.drm
 LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
   int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
   int ReleaseBuffer(hwc_drm_bo_t *bo) override;
 
- private:
   uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
 
   DrmResources *drm_;
 
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..5f17c20
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+#ifdef USE_HISI_IMPORTER
+// static
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+#endif
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm), 
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, 
(EGLint)DrmGenericImporter::ConvertHalFormatToDrm(hnd->req_format),
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+EGL_DMA_BUF_PLANE0_OFFSET_EXT, 0,
+EGL_DMA_BUF_PLANE0_PITCH_EXT, hnd->byte_stride,
+EGL_NONE,
+  };
+  return eglCreateImageKHR(egl_display, EGL_NO_CONTEXT, 

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

[Pandiyan, Dhinakaran]

On Thu, 2018-02-08 at 17:01 -0800, Andy Lutomirski wrote:
> 
> 
> > On Feb 8, 2018, at 4:39 PM, Pandiyan, Dhinakaran 
> >  wrote:
> > 
> > 
> >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote:
> >> Hi Andy,
> >> 
> >> thanks for getting involved with PSR and sorry for not replying sooner.
> >> 
> >> I first saw this patch on that bugzilla entry but only now I stop to
> >> really think why I have written the code that way.
> >> 
> >> So some clarity below.
> >> 
> >>> On Mon, Feb 05, 2018 at 10:07:09PM +, Andy Lutomirski wrote:
> >>> The current PSR code has a two call sites that each schedule delayed
> >>> work to activate PSR.  As far as I can tell, each call site intends
> >>> to keep PSR inactive for the given amount of time and then allow it
> >>> to be activated.
> >>> 
> >>> The call sites are:
> >>> 
> >>> - intel_psr_enable(), which explicitly states in a comment that
> >>>   it's trying to keep PSR off a short time after the dispay is
> >>>   initialized as a workaround.
> >> 
> >> First of all I really want to kill this call here and remove the
> >> FIXME. It was an ugly hack that I added to solve a corner case
> >> that was leaving me with blank screens when activating so sooner.
> >> 
> >>> 
> >>> - intel_psr_flush().  There isn't an explcit explanation, but the
> >>>   intent is presumably to keep PSR off until the display has been
> >>>   idle for 100ms.
> >> 
> >> The reason for 100 is kind of ugly-nonsense-empirical value
> >> I concluded from VLV/CHV experience.
> >> On platforms with HW tracking HW waits few identical frames
> >> until really activating PSR. VLV/CHV activation is immediate.
> >> But HW is also different and there it seemed that hw needed a
> >> few more time before starting the transitions.
> >> Furthermore I didn't want to add that so quickly because I didn't
> >> want to take the risk of killing battery with software tracking
> >> when doing transitions so quickly using software tracking.
> >> 
> >>> 
> >>> The current code doesn't actually accomplish either of these goals.
> >>> Rather than keeping PSR inactive for the given amount of time, it
> >>> will schedule PSR for activation after the given time, with the
> >>> earliest target time in such a request winning.
> >> 
> >> Putting that way I was asking myself how that hack had ever fixed
> >> my issue. Because the way you explained here seems obvious that it
> >> wouldn't ever fix my bug or any other.
> >> 
> >> So I applied your patch and it made even more sense (without considering
> >> the fact I want to kill the first call anyways).
> >> 
> >> So I came back, removed your patch and tried to understand how did
> >> it ever worked.
> >> 
> >> So, the thing is that intel_psr_flush will never be really executed
> >> if intel_psr_enable wasn't executed. That is guaranteed by:
> >> 
> >> mutex_lock(_priv->psr.lock);
> >>if (!dev_priv->psr.enabled) {
> >> 
> >> So, intel_psr_enable will be for sure the first one to schedule the
> >> work delayed to the ugly higher delay.
> >> 
> >>> 
> >>> In other words, if intel_psr_enable() is immediately followed by
> >>> intel_psr_flush(), then PSR will be activated after 100ms even if
> >>> intel_psr_enable() wanted a longer delay.  And, if the screen is
> >>> being constantly updated so that intel_psr_flush() is called once
> >>> per frame at 60Hz, PSR will still be activated once every 100ms.
> >> 
> >> During this time you are right, many calls of intel_psr_exit
> >> coming from flush functions can be called... But none of
> >> them will schedule the work with 100 delay.
> >> 
> >> they will skip on
> >> if (!work_busy(_priv->psr.work.work))
> 
> As below, the first call will.  Then, 100ms later, the work will fire.  Then 
> the next flush will schedule it again, etc.
> 
> > 
> > Wouldn't work_busy() return false until the work is actually queued
> > which is 100ms after calling schedule_delayed_work()?
> > 
> > For e.g, flushes at 0, 16, 32...96 will have work_busy() returning false
> > until 100ms.
> > 
> > The first psr_work will end up getting scheduled at 100ms, which I
> > believe is not what we want. 
> 
> Indeed.  I stuck some printks in and this seems to be what happens.
> 
> > 
> > 
> > However, I think 
> > 
> >if (dev_priv->psr.busy_frontbuffer_bits)
> >goto unlock;
> > 
> >intel_psr_activate(intel_dp);
> > 
> > in psr_work might prevent activate being called at 100ms if an
> > invalidate happened to be called before that.
> > 
> 
> On my system, invalidate is never called.
I noticed the same in console mode with fbdev, there are no invalidates.

>   Even if it were called, that check would only help if we got lucky and the 
> work fired after invalidate and before the subsequent flush.
> 
Agreed. This dependency on invalidate sure looks wrong. 

> > 
> > 
> > 
> >> 
> >> So, the higher delayed *hack* will be respected and PSR won't get
> >> activated before that.
> >> 
> >> On the other hand you 

[PATCH 2/3] drm/amdgpu: only enable swiotlb alloc when need v2

[Chunming Zhou]

get the max io mapping address of system memory to see if it is over
our card accessing range.
v2: move checking later

Change-Id: Ibc38dbd34a20af5b4a4b1ed154c14e1c58aa4c55
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   | 2 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   | 3 +++
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c   | 2 ++
 6 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 257424dd8a52..627a06185368 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1437,6 +1437,7 @@ struct amdgpu_device {
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
struct work_struct  reset_work;
struct notifier_block   acpi_nb;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 95f990140f2a..a021de9629ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1018,7 +1018,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm,
}
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, adev->dev, ctx);
}
 #endif
@@ -1045,7 +1045,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt *ttm)
adev = amdgpu_ttm_adev(ttm->bdev);
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (adev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, adev->dev);
return;
}
@@ -2007,7 +2007,7 @@ static int amdgpu_ttm_debugfs_init(struct amdgpu_device 
*adev)
count = ARRAY_SIZE(amdgpu_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(adev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
index 5eacc0819b66..1945fe842188 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v6_0.h"
 #include "amdgpu_ucode.h"
@@ -866,6 +867,7 @@ static int gmc_v6_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
dev_warn(adev->dev, "amdgpu: No coherent DMA available.\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v6_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index ce7f484f86f9..761def04f93f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "cikd.h"
 #include "cik.h"
@@ -1014,6 +1015,7 @@ static int gmc_v7_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v7_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index f53f3936fd4f..2489be7ad62b 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "gmc_v8_0.h"
 #include "amdgpu_ucode.h"
@@ -1101,6 +1102,7 @@ static int gmc_v8_0_sw_init(void *handle)
 */
adev->need_dma32 = false;
dma_bits = adev->need_dma32 ? 32 : 40;
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
r = pci_set_dma_mask(adev->pdev, DMA_BIT_MASK(dma_bits));
if (r) {
adev->need_dma32 = true;
@@ -1112,6 +1114,7 @@ static int gmc_v8_0_sw_init(void *handle)
pci_set_consistent_dma_mask(adev->pdev, DMA_BIT_MASK(32));
pr_warn("amdgpu: No coherent DMA available\n");
}
+   adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
r = gmc_v8_0_init_microcode(adev);
if (r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 2c60981d2eec..0f4a9a8575a4 100644
--- 

[PATCH 3/3] drm/radeon: only enable swiotlb path when need v2

[Chunming Zhou]

swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later

Change-Id: I1802645833155a9cd808913f863981173a82145f
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h| 1 +
 drivers/gpu/drm/radeon/radeon_device.c | 2 ++
 drivers/gpu/drm/radeon/radeon_ttm.c| 6 +++---
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d34887873dea..4a2eb409aacc 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2387,6 +2387,7 @@ struct radeon_device {
struct radeon_dummy_pagedummy_page;
boolshutdown;
boolneed_dma32;
+   boolneed_swiotlb;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
boolneeds_reset, in_reset;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 8d3e3d2e0090..7f40c6f7c4dd 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1378,6 +1379,7 @@ int radeon_device_init(struct radeon_device *rdev,
pci_set_consistent_dma_mask(rdev->pdev, DMA_BIT_MASK(32));
pr_warn("radeon: No coherent DMA available\n");
}
+   rdev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
 
/* Registers mapping */
/* TODO: block userspace mapping of io register */
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..c1e3862a48a4 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -756,7 +756,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm,
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
return ttm_dma_populate(>ttm, rdev->dev, ctx);
}
 #endif
@@ -788,7 +788,7 @@ static void radeon_ttm_tt_unpopulate(struct ttm_tt *ttm)
 #endif
 
 #ifdef CONFIG_SWIOTLB
-   if (swiotlb_nr_tbl()) {
+   if (rdev->need_swiotlb && swiotlb_nr_tbl()) {
ttm_dma_unpopulate(>ttm, rdev->dev);
return;
}
@@ -1155,7 +1155,7 @@ static int radeon_ttm_debugfs_init(struct radeon_device 
*rdev)
count = ARRAY_SIZE(radeon_ttm_debugfs_list);
 
 #ifdef CONFIG_SWIOTLB
-   if (!swiotlb_nr_tbl())
+   if (!(rdev->need_swiotlb && swiotlb_nr_tbl()))
--count;
 #endif
 
-- 
2.14.1

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

Re: [RFC v2 02/10] drm: drm_fourcc: Introduce macro-pixel info to drm_format_info

[Hyun Kwon]

Hi Daniel,

On Tue, 2018-01-30 at 02:22:40 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> > 
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
> 
> Should we mandate that macro-pixels are always byte-aligned? This would
> mean cpm for characters per macro-pixel would be more meaningful.
> 

Agreed. That would simplify stuff and be more clean.

> > 
> > Signed-off-by: Hyun Kwon 
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 136 
> > +--
> >  include/drm/drm_fourcc.h |   9 +++
> >  2 files changed, 77 insertions(+), 68 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> >  const struct drm_format_info *__drm_format_info(u32 format)
> >  {
> > static const struct drm_format_info formats[] = {
> > -   { .format = DRM_FORMAT_C8,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 },  .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XRGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_XBGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRX,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ARGB,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_ABGR,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_RGBA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },
> > -   { .format = DRM_FORMAT_BGRA,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub 
> > = 1 },

[snip]

> + { .format = DRM_FORMAT_NV16,.depth = 0,  
> .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV61,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV24,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_NV42,.depth = 0,  
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm =  { 1, 1, 0 
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > +   { .format = DRM_FORMAT_YUYV,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_YVYU,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm =  { 1, 0, 0 
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > +   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> > .num_planes = 1, .cpp = 

Re: [PATCH v1 1/2] dt-bindings/display/panel: otm8009a: Add optional power-supply property

[Rob Herring]

On Mon, Feb 05, 2018 at 10:45:31AM +0100, Philippe Cornu wrote:
> Some boards use a dedicated voltage regulator for this panel.
> Add & document this related optional power-supply property.
> 
> Signed-off-by: Philippe Cornu 
> ---
>  Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [PATCH 1/9] dt-bindings: add binding for Rockchip hdmi phy using an Innosilicon IP

[Rob Herring]

On Mon, Feb 05, 2018 at 03:34:27PM +0100, Heiko Stuebner wrote:
> From: Zheng Yang 
> 
> The phy is used so far in two Rockchip socs the rk3228 and the rk3328.
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Heiko Stuebner 
> ---
>  .../bindings/phy/phy-rockchip-inno-hdmi.txt| 42 
> ++
>  1 file changed, 42 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-rockchip-inno-hdmi.txt

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

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #16 from Matthew Scheirer  ---
I get this as well with a 290 on 4.15 ONLY when DC is enabled. Its a dirty
enough taint to leave btrfs volumes in inconsistent states so its straight
crashing the kernel.

Feb 08 17:06:08 system kernel: RSP: 002b:7f56c62fc1a8 EFLAGS: 0246
Feb 08 17:06:08 system kernel: amdgpu :01:00.0: swiotlb buffer is full (sz:
2097152 bytes)
Feb 08 17:06:08 system kernel: swiotlb: coherent allocation failed for device
:01:00.0 size=2097152
Feb 08 17:06:08 system kernel: CPU: 5 PID: 2216 Comm: Compositor Tainted: G
  O 4.15.1-2-ARCH #1
Feb 08 17:06:08 system kernel: Hardware name: ASUS All Series/Z87I-DELUXE, BIOS
1204 11/26/2014
Feb 08 17:06:08 system kernel: Call Trace:
Feb 08 17:06:08 system kernel:  dump_stack+0x5c/0x85
Feb 08 17:06:08 system kernel:  swiotlb_alloc_coherent+0xe0/0x150
Feb 08 17:06:08 system kernel:  ttm_dma_pool_get_pages+0x1f3/0x5c0 [ttm]
Feb 08 17:06:08 system kernel:  ttm_dma_populate+0x24a/0x340 [ttm]
Feb 08 17:06:08 system kernel:  ttm_tt_bind+0x29/0x60 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_handle_move_mem+0x5da/0x610 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_validate+0x135/0x150 [ttm]
Feb 08 17:06:08 system kernel:  ttm_bo_init_reserved+0x3a7/0x480 [ttm]
Feb 08 17:06:08 system kernel:  amdgpu_bo_do_create+0x1b4/0x420 [amdgpu]
Feb 08 17:06:08 system kernel:  ? amdgpu_fill_buffer+0x310/0x310 [amdgpu]
Feb 08 17:06:08 system kernel:  amdgpu_bo_create+0x50/0x210 [amdgpu]
Feb 08 17:06:08 system kernel:  ? ttm_eu_backoff_reservation+0x4d/0x70 [ttm]
Feb 08 17:06:08 system kernel:  amdgpu_gem_object_create+0x7f/0x110 [amdgpu]
Feb 08 17:06:08 system kernel:  amdgpu_gem_create_ioctl+0x1e6/0x280 [amdgpu]
Feb 08 17:06:08 system kernel:  ? page_add_file_rmap+0x11/0x140
Feb 08 17:06:08 system kernel:  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
Feb 08 17:06:08 system kernel:  drm_ioctl_kernel+0x5b/0xb0 [drm]
Feb 08 17:06:08 system kernel:  drm_ioctl+0x2d5/0x370 [drm]
Feb 08 17:06:08 system kernel:  ? amdgpu_gem_object_close+0x1e0/0x1e0 [amdgpu]
Feb 08 17:06:08 system kernel:  ? __handle_mm_fault+0xd30/0x1260
Feb 08 17:06:08 system kernel:  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
Feb 08 17:06:08 system kernel:  do_vfs_ioctl+0xa4/0x630
Feb 08 17:06:08 system kernel:  ? __do_page_fault+0x29d/0x500
Feb 08 17:06:08 system kernel:  ? SyS_futex+0x12d/0x180
Feb 08 17:06:08 system kernel:  SyS_ioctl+0x74/0x80
Feb 08 17:06:08 system kernel:  ? do_page_fault+0x32/0x110
Feb 08 17:06:08 system kernel:  entry_SYSCALL_64_fastpath+0x20/0x83
Feb 08 17:06:08 system kernel: RIP: 0033:0x7f56f7570d87

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

Re: [PATCH v3 3/3] drm/omap: Make omapdss API more generic

[Tomi Valkeinen]

On 07/02/18 16:11, Jyri Sarha wrote:
> The new omapdss API is HW independent and cleans up some of the DSS5
> specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
> register bits and replace them with HW independent generic u64 based
> macros. The new macros make it more straight forward to implement the
> IRQ code for the future DSS versions that do not share the same
> register structure as DSS2 to DSS5 has.
> 
> Signed-off-by: Jyri Sarha 



Can you add a comment here that describes the layout of the u64 irq bits
container.

> +#define DSS_IRQ_DEVICE_OCP_ERR   BIT_ULL(0)
> +
> +#define DSS_IRQ_MGR_BIT_N(ch, bit)   (4 + 4 * ch + bit)
> +#define DSS_IRQ_OVL_BIT_N(ovl, bit) \
> + (DSS_IRQ_MGR_BIT_N(DSS_MAX_CHANNELS, 0) + 1 * ovl + bit)
> +
> +#define DSS_IRQ_MGR_BIT(ch, bit) BIT_ULL(DSS_IRQ_MGR_BIT_N(ch, bit))
> +#define DSS_IRQ_OVL_BIT(ovl, bit)BIT_ULL(DSS_IRQ_OVL_BIT_N(ovl, bit))
> +
> +#define DSS_IRQ_MGR_MASK(ch) \
> + GENMASK_ULL(DSS_IRQ_MGR_BIT_N(ch, 3), DSS_IRQ_MGR_BIT_N(ch, 0))
> +#define DSS_IRQ_OVL_MASK(ovl) \
> + GENMASK_ULL(DSS_IRQ_OVL_BIT_N(ovl, 0), DSS_IRQ_OVL_BIT_N(ovl, 0))
> +
> +#define DSS_IRQ_MGR_FRAME_DONE(ch)   DSS_IRQ_MGR_BIT(ch, 0)
> +#define DSS_IRQ_MGR_VSYNC_EVEN(ch)   DSS_IRQ_MGR_BIT(ch, 1)
> +#define DSS_IRQ_MGR_VSYNC_ODD(ch)DSS_IRQ_MGR_BIT(ch, 2)
> +#define DSS_IRQ_MGR_SYNC_LOST(ch)DSS_IRQ_MGR_BIT(ch, 3)
> +
> +#define DSS_IRQ_OVL_FIFO_UNDERFLOW(ovl)  DSS_IRQ_OVL_BIT(ovl, 0)
>  
>  struct omap_dss_device;
>  struct dss_lcd_mgr_config;
> @@ -678,9 +670,8 @@ void dss_mgr_unregister_framedone_handler(enum 
> omap_channel channel,
>  /* dispc ops */
>  
>  struct dispc_ops {
> - u32 (*read_irqstatus)(void);
> - void (*clear_irqstatus)(u32 mask);
> - void (*write_irqenable)(u32 mask);
> + u64 (*read_and_clear_irqstatus)(void);
> + void (*write_irqenable)(u64 enable);
>  
>   int (*request_irq)(irq_handler_t handler, void *dev_id);
>   void (*free_irq)(void *dev_id);
> @@ -694,13 +685,12 @@ struct dispc_ops {
>   const char *(*get_ovl_name)(enum omap_plane_id plane);
>   const char *(*get_mgr_name)(enum omap_channel channel);
>  
> + bool (*mgr_has_framedone)(enum omap_channel channel);
> +
>   u32 (*get_memory_bandwidth_limit)(void);
>  
>   void (*mgr_enable)(enum omap_channel channel, bool enable);
>   bool (*mgr_is_enabled)(enum omap_channel channel);
> - u32 (*mgr_get_vsync_irq)(enum omap_channel channel);
> - u32 (*mgr_get_framedone_irq)(enum omap_channel channel);
> - u32 (*mgr_get_sync_lost_irq)(enum omap_channel channel);
>   bool (*mgr_go_busy)(enum omap_channel channel);
>   void (*mgr_go)(enum omap_channel channel);
>   void (*mgr_set_lcd_config)(enum omap_channel channel,
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index fee8a63..f7e1668 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -149,7 +149,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>   enum omap_channel channel = omap_crtc->channel;
>   struct omap_irq_wait *wait;
> - u32 framedone_irq, vsync_irq;
> + u64 vsync_irq, framedone_irq;
>   int ret;
>  
>   if (WARN_ON(omap_crtc->enabled == enable))
> @@ -169,8 +169,10 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>   omap_crtc->ignore_digit_sync_lost = true;
>   }
>  
> - framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
> - vsync_irq = priv->dispc_ops->mgr_get_vsync_irq(channel);
> +
> + vsync_irq = (DSS_IRQ_MGR_VSYNC_EVEN(channel) |
> +  DSS_IRQ_MGR_VSYNC_ODD(channel));
> + framedone_irq = DSS_IRQ_MGR_FRAME_DONE(channel);
>  
>   if (enable) {
>   wait = omap_irq_wait_init(dev, vsync_irq, 1);
> @@ -184,7 +186,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
> bool enable)
>* even and odd frames.
>*/
>  
> - if (framedone_irq)
> + if (priv->dispc_ops->mgr_has_framedone(channel))

Is it valid to do DSS_IRQ_MGR_FRAME_DONE(channel) above, even if there's
no framedone irq for the channel? Well, I know it won't crash, but from
code-cleanliness point of view, perhaps it's better to first check if we
have a framedone, and only then get it.

>   wait = omap_irq_wait_init(dev, framedone_irq, 1);
>   else
>   wait = omap_irq_wait_init(dev, vsync_irq, 2);
> @@ -272,17 +274,17 @@ static void omap_crtc_dss_unregister_framedone(
>   * Setup, Flush and Page Flip
>   */
>  
> -void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus)
> +void omap_crtc_error_irq(struct drm_crtc *crtc, u64 irqstatus)
>  {
>   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
>  
>   if 

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 07.02.2018 22:43, Rob Herring wrote:
> On Mon, Feb 05, 2018 at 10:06:35AM +0100, Andrzej Hajda wrote:
>> On 05.02.2018 07:08, Rob Herring wrote:
>>> On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
 These bindings allow to describe most known standard USB connectors
 and it should be possible to extend it if necessary.
 USB connectors, beside USB can be used to route other protocols,
 for example UART, Audio, MHL. In such case every device passing data
 through the connector should have appropriate graph bindings.

 Signed-off-by: Andrzej Hajda 
 ---
 v2:
 - moved connector type(A,B,C) to compatible string (Rob),
 - renamed size property to type (Rob),
 - changed type description to be less confusing (Laurent),
 - removed vendor specific compatibles (implied by graph port number),
>>> How so? More below...
>>>
 - added requirement of connector being a child of IC (Rob),
 - removed max-mode (subtly suggested by Rob, it should be detected anyway
   by USB Controller in runtime, downside is that device is not able to
   report its real capabilities, maybe better would be to make it 
 optional(?)),
 - assigned port numbers to data buses (Rob).

 Regards
 Andrzej

 Signed-off-by: Andrzej Hajda 
 ---
  .../bindings/connector/usb-connector.txt   | 48 
 ++
  1 file changed, 48 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/connector/usb-connector.txt

 diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
 b/Documentation/devicetree/bindings/connector/usb-connector.txt
 new file mode 100644
 index ..02020f5d760a
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
 @@ -0,0 +1,48 @@
 +USB Connector
 +=
 +
 +USB connector node represents physical USB connector. It should be
 +a child of USB interface controller.
 +
 +Required properties:
 +- compatible: describes type of the connector, must be one of:
 +"usb-a-connector", "usb-b-connector", "usb-c-connector",
>>> Nit: one per line.
>>>
 +
 +Optional properties:
 +- label: symbolic name for the connector
 +- type: size of the connector, should be specified in case of USB-A, USB-B
 +  non-standard (large) connector sizes: "mini", "micro"
 +
 +Required nodes:
 +- any data bus to the connector should be modeled using the OF graph 
 bindings
 +  specified in bindings/graph.txt, unless the bus is between parent node 
 and
 +  the connector. Since single connector can have multpile data buses 
 every bus
 +  has assigned OF graph port number as follows:
 +0: High Speed (HS), present in all connectors,
 +1: Super Speed (SS), present in SS capable connectors,
 +2: Sideband use (SBU), present in USB-C,
 +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung 
 micro-USB
>>> This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
>>> That makes me think the Samsung connector should have its own compatible 
>>> string.
>> Do you mean, sth like:
>>     connector {
>>             compatible = "samsung,usb-connector-11pin";
>>             label = "micro-USB";
>>             ports {
>>                     #address-cells = <1>;
>>                     #size-cells = <0>;
>>
>>                     port@3 {
>>                             reg = <3>;
>>                             musb_con_mhl_in: endpoint {
>>                                     remote-endpoint = <_out>;
>>                             };
>>                     };
>>     };
> Yes, basically.
>
>> Or should I add "usb-b-connector" extra compatible and "type" property?
> type would be micro? I think type and "usb-b-connector" are fine if this 
> is a superset like a USB3 SS micro connector.
>
>> I slightly prefer my approach(less different bindings), but I am also OK
>> with the above.
> How do you know it is a Samsung connector then? Just because you have 
> port 3? I think it is better to be explicit.

OK.

>
>>> Can we go ahead and define the video modes of Type-C? Normally, if 2 
>>> data streams are mutually exclusive, then they are a single port with 2 
>>> endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
>>> port 3 is always video. We can still know what is mutually exclusive 
>>> based on the compatible. 
>> I am sorry, I do not understand what you mean. Port 3 is present only in
>> 11-pin Samsung micro-USB, USB Type-C has only ports 0, 1, 2.
> So video on Type C would be on port 1 (SS), endpoint ? ? That's not 
> defined in the binding and I want to define it.

USB type C does not have dedicated video lines, it has only: HS, SS, SBU
(and optionally CC) data lines[1] and in my RFC I have modeled data

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #25 from Michel Dänzer  ---
(In reply to Bong Cosca from comment #24)
> My screen width is 1280px. Is there a reason why the amdgpu driver says the
> GPU has a front buffer pitch of 6144 bytes in non-accelerated mode while the
> pitch in accelerated mode is 5120?

Where do you see that?

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

Re: [PATCH v1 2/2] drm/stm: ltdc: remove non-alpha color formats on layer 2 for older hw

[Benjamin Gaignard]

2018-02-06 10:13 GMT+01:00 Yannick FERTRE :
> Reviewed-by: Yannick Fertré 
>
>
> On 02/01/2018 11:42 AM, Philippe Cornu wrote:
>> Hw older versions support non-alpha color formats derived
>> from native alpha color formats only on the primary layer.
>> For instance, RG16 native format without alpha works fine
>> on 2nd layer but XR24 (derived color format from AR24)
>> does not work on 2nd layer.
>>
>> Signed-off-by: Philippe Cornu 

Applied on drm-misc-next

Benjamin

>> ---
>>   drivers/gpu/drm/stm/ltdc.c | 20 
>>   drivers/gpu/drm/stm/ltdc.h |  1 +
>>   2 files changed, 21 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index f6f26fc0ae9e..1a3277e483d5 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -703,6 +703,11 @@ static void ltdc_plane_atomic_update(struct drm_plane 
>> *plane,
>>   if (!fb->format->has_alpha)
>>   val = BF1_CA | BF2_1CA;
>>
>> + /* Manage hw-specific capabilities */
>> + if (ldev->caps.non_alpha_only_l1 &&
>> + plane->type != DRM_PLANE_TYPE_PRIMARY)
>> + val = BF1_PAXCA | BF2_1PAXCA;
>> +
>>   reg_update_bits(ldev->regs, LTDC_L1BFCR + lofs,
>>   LXBFCR_BF2 | LXBFCR_BF1, val);
>>
>> @@ -785,6 +790,12 @@ static struct drm_plane *ltdc_plane_create(struct 
>> drm_device *ddev,
>>   drm_fmt_no_alpha = get_pixelformat_without_alpha(drm_fmt);
>>   if (!drm_fmt_no_alpha)
>>   continue;
>> +
>> + /* Manage hw-specific capabilities */
>> + if (ldev->caps.non_alpha_only_l1 &&
>> + type != DRM_PLANE_TYPE_PRIMARY)
>> + continue;
>> +
>>   formats[nb_fmt++] = drm_fmt_no_alpha;
>>   }
>>
>> @@ -913,10 +924,19 @@ static int ltdc_get_caps(struct drm_device *ddev)
>>   case HWVER_10300:
>>   ldev->caps.reg_ofs = REG_OFS_NONE;
>>   ldev->caps.pix_fmt_hw = ltdc_pix_fmt_a0;
>> + /*
>> +  * Hw older versions support non-alpha color formats derived
>> +  * from native alpha color formats only on the primary layer.
>> +  * For instance, RG16 native format without alpha works fine
>> +  * on 2nd layer but XR24 (derived color format from AR24)
>> +  * does not work on 2nd layer.
>> +  */
>> + ldev->caps.non_alpha_only_l1 = true;
>>   break;
>>   case HWVER_20101:
>>   ldev->caps.reg_ofs = REG_OFS_4;
>>   ldev->caps.pix_fmt_hw = ltdc_pix_fmt_a1;
>> + ldev->caps.non_alpha_only_l1 = false;
>>   break;
>>   default:
>>   return -ENODEV;
>> diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
>> index edd1c0a446d1..edb268129c54 100644
>> --- a/drivers/gpu/drm/stm/ltdc.h
>> +++ b/drivers/gpu/drm/stm/ltdc.h
>> @@ -17,6 +17,7 @@ struct ltdc_caps {
>>   u32 reg_ofs;/* register offset for applicable regs */
>>   u32 bus_width;  /* bus width (32 or 64 bits) */
>>   const u32 *pix_fmt_hw;  /* supported pixel formats */
>> + bool non_alpha_only_l1; /* non-native no-alpha formats on layer 1 */
>>   };
>>
>>   struct ltdc_device {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] drm/stm: ltdc: add non-alpha color formats

[Benjamin Gaignard]

2018-02-06 10:12 GMT+01:00 Yannick FERTRE :
> Reviewed-by: Yannick Fertré 
>
>
> On 02/01/2018 11:42 AM, Philippe Cornu wrote:
>> ltdc supports natively some color formats with alpha (like
>> ARGB, ARGB1555, ARGB...). Related non-alpha formats are
>> supported too (ARGB->XRGB, ARGB->XRGB...) by
>> adjusting ltdc blending factors.
>>
>> Note: Wayland/Weston requests by default the non-alpha XRGB
>> color format.
>>
>> Signed-off-by: Philippe Cornu 

Applied on drm-misc-next

Benjamin
>> ---
>>   drivers/gpu/drm/stm/ltdc.c | 33 +++--
>>   1 file changed, 31 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 90b3de516c91..f6f26fc0ae9e 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -328,6 +328,26 @@ static inline u32 to_drm_pixelformat(enum ltdc_pix_fmt 
>> pf)
>>   }
>>   }
>>
>> +static inline u32 get_pixelformat_without_alpha(u32 drm)
>> +{
>> + switch (drm) {
>> + case DRM_FORMAT_ARGB:
>> + return DRM_FORMAT_XRGB;
>> + case DRM_FORMAT_RGBA:
>> + return DRM_FORMAT_RGBX;
>> + case DRM_FORMAT_ARGB1555:
>> + return DRM_FORMAT_XRGB1555;
>> + case DRM_FORMAT_RGBA5551:
>> + return DRM_FORMAT_RGBX5551;
>> + case DRM_FORMAT_ARGB:
>> + return DRM_FORMAT_XRGB;
>> + case DRM_FORMAT_RGBA:
>> + return DRM_FORMAT_RGBX;
>> + default:
>> + return 0;
>> + }
>> +}
>> +
>>   static irqreturn_t ltdc_irq_thread(int irq, void *arg)
>>   {
>>   struct drm_device *ddev = arg;
>> @@ -680,6 +700,9 @@ static void ltdc_plane_atomic_update(struct drm_plane 
>> *plane,
>>
>>   /* Specifies the blending factors */
>>   val = BF1_PAXCA | BF2_1PAXCA;
>> + if (!fb->format->has_alpha)
>> + val = BF1_CA | BF2_1CA;
>> +
>>   reg_update_bits(ldev->regs, LTDC_L1BFCR + lofs,
>>   LXBFCR_BF2 | LXBFCR_BF1, val);
>>
>> @@ -747,8 +770,8 @@ static struct drm_plane *ltdc_plane_create(struct 
>> drm_device *ddev,
>>   struct device *dev = ddev->dev;
>>   struct drm_plane *plane;
>>   unsigned int i, nb_fmt = 0;
>> - u32 formats[NB_PF];
>> - u32 drm_fmt;
>> + u32 formats[NB_PF * 2];
>> + u32 drm_fmt, drm_fmt_no_alpha;
>>   int ret;
>>
>>   /* Get supported pixel formats */
>> @@ -757,6 +780,12 @@ static struct drm_plane *ltdc_plane_create(struct 
>> drm_device *ddev,
>>   if (!drm_fmt)
>>   continue;
>>   formats[nb_fmt++] = drm_fmt;
>> +
>> + /* Add the no-alpha related format if any & supported */
>> + drm_fmt_no_alpha = get_pixelformat_without_alpha(drm_fmt);
>> + if (!drm_fmt_no_alpha)
>> + continue;
>> + formats[nb_fmt++] = drm_fmt_no_alpha;
>>   }
>>
>>   plane = devm_kzalloc(dev, sizeof(*plane), GFP_KERNEL);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/6] drm/omap: Fail probe if irq registration fails

[Jyri Sarha]

Call to omap_drm_irq_install() may fail with an error code. In such a
case the driver probe should fail.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 71ea43f..e6e7a2c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -329,9 +329,9 @@ static int omap_modeset_init(struct drm_device *dev)
 
drm_mode_config_reset(dev);
 
-   omap_drm_irq_install(dev);
+   ret = omap_drm_irq_install(dev);
 
-   return 0;
+   return ret;
 }
 
 /*
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 0/6] drm/omap: Make omapdss API more generic + related patches

[Jyri Sarha]

The purpose of these patches is to make easier to add support for
future DSS version.

Since v3:
- "drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops"
  - Make ovl_names array static const char * const
- Add:
  - "drm/omap: move common stuff from dss.h to omapdss.h"
  - "drm/omap: dss: Move platform_device_register from core.c to dss.c probe"
  - "drm/omap: dss: platform_register_drivers() to dss.c and remove core.c"

Since v2:
- Simplify dispc_mgr_has_framedone() 
- dispc_hw_to_api_irq() and dispc_api_to_hw_irq() use new dispc_irq_bits[]
- rename dispc_ops read_irqstatus() to read_and_clear_irqstatus() and remove
  clearmask
- precalculate priv->irq_uf_mask in omap_drm_irq_install() and use it in
  omap_irq_fifo_underflow()

Here is the v2 round:
https://lists.freedesktop.org/archives/dri-devel/2018-January/161353.html

Since RFC:

This the v2 rouns of a this RFC patch:
https://patchwork.kernel.org/patch/10066245/

The first patch is a simple fix that should be applied in any case.

I did not split the mgr_has_framedone() callback as a separate patch. It
quite literally replaces the mgr_get_framedone_irq() and makes no
sense without the "drm/omap: Make omapdss API more generic"-patch.

Best regards,
  Jyri

Jyri Sarha (5):
  drm/omap: Fail probe if irq registration fails
  drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops
  drm/omap: Make omapdss API more generic
  drm/omap: dss: Move platform_device_register from core.c to dss.c
probe
  drm/omap: dss: platform_register_drivers() to dss.c and remove core.c

Tomi Valkeinen (1):
  drm/omap: move common stuff from dss.h to omapdss.h

 drivers/gpu/drm/omapdrm/dss/Makefile  |   2 +-
 drivers/gpu/drm/omapdrm/dss/core.c|  88 
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 113 --
 drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 +
 drivers/gpu/drm/omapdrm/dss/dss.c |  56 +++
 drivers/gpu/drm/omapdrm/dss/dss.h |  37 --
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 104 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c   |  27 +++-
 drivers/gpu/drm/omapdrm/omap_crtc.h   |   2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c|   4 +-
 drivers/gpu/drm/omapdrm/omap_drv.h|   3 +-
 drivers/gpu/drm/omapdrm/omap_irq.c| 125 +++---
 drivers/gpu/drm/omapdrm/omap_irq.h|   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |  18 ++---
 drivers/gpu/drm/omapdrm/omap_plane.h  |   1 +
 15 files changed, 331 insertions(+), 284 deletions(-)
 delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

[PATCH v4 2/6] drm/omap: Add get_ovl_name() and get_mgr_name() to dispc_ops

[Jyri Sarha]

Add get_ovl_name() and get_mgr_name() to dispc_ops and get rid of
adhoc names here and there in the omapdrm code. This moves the names
of hardware entities to omapdss side where they have to be when new
omapdss backend drivers are introduced.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 21 +
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  3 +++
 drivers/gpu/drm/omapdrm/omap_crtc.c   | 11 ++-
 drivers/gpu/drm/omapdrm/omap_irq.c| 19 +++
 drivers/gpu/drm/omapdrm/omap_plane.c  | 13 +++--
 5 files changed, 36 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 4e8f68e..8b4814a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -680,6 +680,24 @@ void dispc_runtime_put(void)
WARN_ON(r < 0 && r != -ENOSYS);
 }
 
+static const char *dispc_get_ovl_name(enum omap_plane_id plane)
+{
+   static const char * const ovl_names[] = {
+   [OMAP_DSS_GFX]  = "GFX",
+   [OMAP_DSS_VIDEO1]   = "VID1",
+   [OMAP_DSS_VIDEO2]   = "VID2",
+   [OMAP_DSS_VIDEO3]   = "VID3",
+   [OMAP_DSS_WB]   = "WB",
+   };
+
+   return ovl_names[plane];
+}
+
+static const char *dispc_get_mgr_name(enum omap_channel channel)
+{
+   return mgr_desc[channel].name;
+}
+
 static u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
 {
return mgr_desc[channel].vsync_irq;
@@ -4506,6 +4524,9 @@ static void dispc_errata_i734_wa(void)
.get_num_ovls = dispc_get_num_ovls,
.get_num_mgrs = dispc_get_num_mgrs,
 
+   .get_ovl_name = dispc_get_ovl_name,
+   .get_mgr_name = dispc_get_mgr_name,
+
.get_memory_bandwidth_limit = dispc_get_memory_bandwidth_limit,
 
.mgr_enable = dispc_mgr_enable,
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index f8f83e8..d7ed1a4 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -691,6 +691,9 @@ struct dispc_ops {
int (*get_num_ovls)(void);
int (*get_num_mgrs)(void);
 
+   const char *(*get_ovl_name)(enum omap_plane_id plane);
+   const char *(*get_mgr_name)(enum omap_channel channel);
+
u32 (*get_memory_bandwidth_limit)(void);
 
void (*mgr_enable)(enum omap_channel channel, bool enable);
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e..fee8a63 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -662,13 +662,6 @@ static void omap_crtc_reset(struct drm_crtc *crtc)
  * Init and Cleanup
  */
 
-static const char *channel_names[] = {
-   [OMAP_DSS_CHANNEL_LCD] = "lcd",
-   [OMAP_DSS_CHANNEL_DIGIT] = "tv",
-   [OMAP_DSS_CHANNEL_LCD2] = "lcd2",
-   [OMAP_DSS_CHANNEL_LCD3] = "lcd3",
-};
-
 void omap_crtc_pre_init(void)
 {
memset(omap_crtcs, 0, sizeof(omap_crtcs));
@@ -696,7 +689,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
channel = out->dispc_channel;
omap_dss_put_device(out);
 
-   DBG("%s", channel_names[channel]);
+   DBG("%s", priv->dispc_ops->get_mgr_name(channel));
 
/* Multiple displays on same channel is not allowed */
if (WARN_ON(omap_crtcs[channel] != NULL))
@@ -711,7 +704,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
init_waitqueue_head(_crtc->pending_wait);
 
omap_crtc->channel = channel;
-   omap_crtc->name = channel_names[channel];
+   omap_crtc->name = priv->dispc_ops->get_mgr_name(channel);
 
ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
_crtc_funcs, NULL);
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 53ba424..b0f6850 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -144,15 +144,10 @@ static void omap_irq_fifo_underflow(struct 
omap_drm_private *priv,
 {
static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
  DEFAULT_RATELIMIT_BURST);
-   static const struct {
-   const char *name;
-   u32 mask;
-   } sources[] = {
-   { "gfx", DISPC_IRQ_GFX_FIFO_UNDERFLOW },
-   { "vid1", DISPC_IRQ_VID1_FIFO_UNDERFLOW },
-   { "vid2", DISPC_IRQ_VID2_FIFO_UNDERFLOW },
-   { "vid3", DISPC_IRQ_VID3_FIFO_UNDERFLOW },
-   };
+   static const u32 irqbits[] = { DISPC_IRQ_GFX_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID1_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID2_FIFO_UNDERFLOW,
+  DISPC_IRQ_VID3_FIFO_UNDERFLOW };
 
const u32 mask = DISPC_IRQ_GFX_FIFO_UNDERFLOW
 

[PATCH v4 3/6] drm/omap: Make omapdss API more generic

[Jyri Sarha]

The new omapdss API is HW independent and cleans up some of the DSS5
specific hacks from the omapdrm side and gets rid off the DSS5 IRQ
register bits and replace them with HW independent generic u64 based
macros. The new macros make it more straight forward to implement the
IRQ code for the future DSS versions that do not share the same
register structure as DSS2 to DSS5 has.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 106 ++
 drivers/gpu/drm/omapdrm/dss/dispc.h   |  33 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  64 --
 drivers/gpu/drm/omapdrm/omap_crtc.c   |  16 +++--
 drivers/gpu/drm/omapdrm/omap_crtc.h   |   2 +-
 drivers/gpu/drm/omapdrm/omap_drv.h|   3 +-
 drivers/gpu/drm/omapdrm/omap_irq.c| 120 +++---
 drivers/gpu/drm/omapdrm/omap_irq.h|   2 +-
 drivers/gpu/drm/omapdrm/omap_plane.c  |   7 ++
 drivers/gpu/drm/omapdrm/omap_plane.h  |   1 +
 10 files changed, 214 insertions(+), 140 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 8b4814a..2caffed 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -698,27 +698,10 @@ static const char *dispc_get_mgr_name(enum omap_channel 
channel)
return mgr_desc[channel].name;
 }
 
-static u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
+static bool dispc_mgr_has_framedone(enum omap_channel channel)
 {
-   return mgr_desc[channel].vsync_irq;
-}
-
-static u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
-{
-   if (channel == OMAP_DSS_CHANNEL_DIGIT && dispc.feat->no_framedone_tv)
-   return 0;
-
-   return mgr_desc[channel].framedone_irq;
-}
-
-static u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel)
-{
-   return mgr_desc[channel].sync_lost_irq;
-}
-
-u32 dispc_wb_get_framedone_irq(void)
-{
-   return DISPC_IRQ_FRAMEDONEWB;
+   return channel != OMAP_DSS_CHANNEL_DIGIT ||
+   !dispc.feat->no_framedone_tv;
 }
 
 static void dispc_mgr_enable(enum omap_channel channel, bool enable)
@@ -3604,6 +3587,77 @@ static void dispc_write_irqenable(u32 mask)
dispc_read_reg(DISPC_IRQENABLE);
 }
 
+struct dispc_irq_bit {
+   u32 hw;
+   u64 api;
+};
+
+static const struct dispc_irq_bit dispc_irq_bits[] = {
+   { DISPC_IRQ_OCP_ERR, DSS_IRQ_DEVICE_OCP_ERR },
+
+   { DISPC_IRQ_FRAMEDONE, DSS_IRQ_MGR_FRAME_DONE(0) },
+   { DISPC_IRQ_VSYNC, DSS_IRQ_MGR_VSYNC_EVEN(0) },
+   { DISPC_IRQ_SYNC_LOST, DSS_IRQ_MGR_SYNC_LOST(0) },
+
+   { DISPC_IRQ_EVSYNC_EVEN, DSS_IRQ_MGR_VSYNC_EVEN(1) },
+   { DISPC_IRQ_EVSYNC_ODD, DSS_IRQ_MGR_VSYNC_ODD(1) },
+   { DISPC_IRQ_SYNC_LOST_DIGIT, DSS_IRQ_MGR_SYNC_LOST(1) },
+   { DISPC_IRQ_FRAMEDONETV, DSS_IRQ_MGR_FRAME_DONE(1) },
+
+   { DISPC_IRQ_SYNC_LOST2, DSS_IRQ_MGR_SYNC_LOST(2) },
+   { DISPC_IRQ_VSYNC2, DSS_IRQ_MGR_VSYNC_EVEN(2) },
+   { DISPC_IRQ_FRAMEDONE2, DSS_IRQ_MGR_FRAME_DONE(2) },
+
+   { DISPC_IRQ_SYNC_LOST3, DSS_IRQ_MGR_SYNC_LOST(3) },
+   { DISPC_IRQ_VSYNC3, DSS_IRQ_MGR_VSYNC_EVEN(3) },
+   { DISPC_IRQ_FRAMEDONE3, DSS_IRQ_MGR_FRAME_DONE(3) },
+
+   { DISPC_IRQ_GFX_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(0) },
+   { DISPC_IRQ_VID1_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(1) },
+   { DISPC_IRQ_VID2_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(2) },
+   { DISPC_IRQ_VID3_FIFO_UNDERFLOW, DSS_IRQ_OVL_FIFO_UNDERFLOW(3) },
+};
+
+static u64 dispc_hw_to_api_irq(u32 hw)
+{
+   u64 api = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dispc_irq_bits); i++)
+   if (hw & dispc_irq_bits[i].hw)
+   api |= dispc_irq_bits[i].api;
+
+   return api;
+}
+
+static u32 dispc_api_to_hw_irq(u64 api)
+{
+   u32 hw = 0;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dispc_irq_bits); i++)
+   if (api & dispc_irq_bits[i].api)
+   hw |= dispc_irq_bits[i].hw;
+
+   return hw;
+}
+
+static u64 dispc_api_read_and_clear_irqstatus(void)
+{
+   u32 hw_status = dispc_read_irqstatus();
+
+   dispc_clear_irqstatus(hw_status);
+
+   return dispc_hw_to_api_irq(hw_status);
+}
+
+static void dispc_api_write_irqenable(u64 enable)
+{
+   u32 hw_enable = dispc_api_to_hw_irq(enable);
+
+   dispc_write_irqenable(hw_enable);
+}
+
 void dispc_enable_sidle(void)
 {
REG_FLD_MOD(DISPC_SYSCONFIG, 2, 4, 3);  /* SIDLEMODE: smart idle */
@@ -4453,7 +4507,7 @@ static void dispc_errata_i734_wa_fini(void)
 
 static void dispc_errata_i734_wa(void)
 {
-   u32 framedone_irq = dispc_mgr_get_framedone_irq(OMAP_DSS_CHANNEL_LCD);
+   u32 framedone_irq = DISPC_IRQ_FRAMEDONE;
struct omap_overlay_info ovli;
struct dss_lcd_mgr_config lcd_conf;
u32 gatestate;
@@ -4511,9 +4565,8 @@ static void dispc_errata_i734_wa(void)
 }
 
 static const struct dispc_ops dispc_ops = {

[PATCH v4 6/6] drm/omap: dss: platform_register_drivers() to dss.c and remove core.c

[Jyri Sarha]

The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/Makefile |  2 +-
 drivers/gpu/drm/omapdrm/dss/core.c   | 66 
 drivers/gpu/drm/omapdrm/dss/dss.c| 37 
 3 files changed, 38 insertions(+), 67 deletions(-)
 delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c

diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
b/drivers/gpu/drm/omapdrm/dss/Makefile
index 904101c..5950c3f 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -6,7 +6,7 @@ omapdss-base-y := base.o display.o dss-of.o output.o
 
 obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 # Core DSS files
-omapdss-y := core.o dss.o dispc.o dispc_coefs.o \
+omapdss-y := dss.o dispc.o dispc_coefs.o \
pll.o video-pll.o
 omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
 omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
diff --git a/drivers/gpu/drm/omapdrm/dss/core.c 
b/drivers/gpu/drm/omapdrm/dss/core.c
deleted file mode 100644
index 6c9f667..000
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen 
- *
- * Some code and ideas taken from drivers/video/omap/ driver
- * by Imre Deak.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#define DSS_SUBSYS_NAME "CORE"
-
-#include 
-#include 
-#include 
-
-#include "omapdss.h"
-#include "dss.h"
-
-/* INIT */
-static struct platform_driver * const omap_dss_drivers[] = {
-   _dsshw_driver,
-   _dispchw_driver,
-#ifdef CONFIG_OMAP2_DSS_DSI
-   _dsihw_driver,
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
-   _venchw_driver,
-#endif
-#ifdef CONFIG_OMAP4_DSS_HDMI
-   _hdmi4hw_driver,
-#endif
-#ifdef CONFIG_OMAP5_DSS_HDMI
-   _hdmi5hw_driver,
-#endif
-};
-
-static int __init omap_dss_init(void)
-{
-   return platform_register_drivers(omap_dss_drivers,
-ARRAY_SIZE(omap_dss_drivers));
-}
-
-static void __exit omap_dss_exit(void)
-{
-   platform_unregister_drivers(omap_dss_drivers,
-   ARRAY_SIZE(omap_dss_drivers));
-}
-
-module_init(omap_dss_init);
-module_exit(omap_dss_exit);
-
-MODULE_AUTHOR("Tomi Valkeinen ");
-MODULE_DESCRIPTION("OMAP2/3 Display Subsystem");
-MODULE_LICENSE("GPL v2");
-
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 3cfe4a7..701f49b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1564,3 +1564,40 @@ struct platform_driver omap_dsshw_driver = {
.suppress_bind_attrs = true,
},
 };
+
+/* INIT */
+static struct platform_driver * const omap_dss_drivers[] = {
+   _dsshw_driver,
+   _dispchw_driver,
+#ifdef CONFIG_OMAP2_DSS_DSI
+   _dsihw_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+   _venchw_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+   _hdmi4hw_driver,
+#endif
+#ifdef CONFIG_OMAP5_DSS_HDMI
+   _hdmi5hw_driver,
+#endif
+};
+
+static int __init omap_dss_init(void)
+{
+   return platform_register_drivers(omap_dss_drivers,
+ARRAY_SIZE(omap_dss_drivers));
+}
+
+static void __exit omap_dss_exit(void)
+{
+   platform_unregister_drivers(omap_dss_drivers,
+   ARRAY_SIZE(omap_dss_drivers));
+}
+
+module_init(omap_dss_init);
+module_exit(omap_dss_exit);
+
+MODULE_AUTHOR("Tomi Valkeinen ");
+MODULE_DESCRIPTION("OMAP2/3 Display Subsystem");
+MODULE_LICENSE("GPL v2");
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH 1/3] drm: add func to get max iomem address

[Chunming Zhou]

On 2018年02月08日 17:09, Michel Dänzer wrote:

On 2018-02-08 09:32 AM, Chunming Zhou wrote:

it will be used to check if the driver needs swiotlb

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
---
  include/drm/drm_cache.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..442c9ba63d03 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
num_pages);
  void drm_clflush_sg(struct sg_table *st);
  void drm_clflush_virt_range(void *addr, unsigned long length);
  
+static inline u64 drm_get_max_iomem(void)

+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}

I don't think this needs to be an inline function, does it?
If no inline, will report building warning that this function is defined 
but not used in some files including drm_cache.h


Regards,
David Zhou





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

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #137223|text/x-log  |text/plain
  mime type||

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

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #6 from Michel Dänzer  ---
Did you capture the Xorg log and dmesg before or after the problem occurred? If
before, can you grab them again after?

What was the last kernel version where this didn't happen?

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

Re: Atomic driver and old remove FB behavior

[Oleksandr Andrushchenko]

Hi, Maarten!

On 02/06/2018 05:37 PM, Maarten Lankhorst wrote:

Op 06-02-18 om 15:43 schreef Oleksandr Andrushchenko:

Hello, Maarten!


On 02/01/2018 12:13 PM, Oleksandr Andrushchenko wrote:

On 02/01/2018 12:04 PM, Maarten Lankhorst wrote:

Op 01-02-18 om 08:08 schreef Oleksandr Andrushchenko:

Hi, all!

I am working on a para-virtualized frontend DRM driver for Xen [1]
which implements display device I/O interface for Xen guest OSes [2].

At the moment I am rebasing the existing implementation from 4.9 kernel
to recent and found that when user-space DRM application exits then CRTC's
.set_config callback is not called to reset CRTC's mode to NULL.

I tracked the change down to commit 846c7dfc1193eb2f9866fe2fa0ae7d45c72f95b9
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

  This introduces a slight behavioral change to rmfb. Instead of
  disabling a crtc when the primary plane is disabled, we try to
  preserve it.

  If the atomic commit is rejected by the driver then we will still
  fall back to the old behavior and turn off the crtc.
"
which per my understanding is ok for real hardware, but in my case I still
need .set_config to be called with NULL: this way I can tell the backend

driver that it can release resources for this connection on its end.


I tried to implement drm_mode_config_funcs's .atomic_commit returning -EINVAL
on tear down, but at best it made CRTC's atomic state change to NOCRTC, but
still no .set_config callback seen.

Can anyone please tell me the right sequence to implement old remove FB
behavior for atomic drivers? Or what could be the problem on my side?

rmfb was never meant to mean that the crtc will be disabled as well. vmwgfx 
relied on that
behavior as well for old userspace support because userspace never called 
set_config.

If you're an atomic driver, the driver core will never call set_config any 
more, even if the
first attempt to disable returns -EINVAL. Even the fbcon helpers now perform 
direct
calls to atomic_commit().

understood, thank you for clarification

I started to re-implement the existing code in my driver to comply to the
new atomic behavior in terms of "the driver core will never call set_config any 
more"
and the question now is what would be the right place to put a check for mode 
change?
Basically, I would like to know where I can get "struct drm_mode_set" as
I used to have in drm_crtc_funcs.set_config callback? Or some other source of
information I can derive (x,y), (width,height), pixel format for the mode
when it changes.

Any validation check needs to be in atomic_check(), the other check
depends on what kind of check you are looking at. atomic_begin() and
atomic_flush() are usually for plane updates.

If you have special needs for atomic updates, you could always implement
your own implementation for commit_tail(), the original is something like this:

{
drm_atomic_helper_commit_modeset_disables() -> can always put all 
disables here, including when mode is changed. If you replace this, make sure you 
put drm_atomic_helper_update_legacy_modeset_state() after all disables..

Next 2 calls can be swapped, depending on whether planes need to be 
programmed before crtc enabling or after:
{
drm_atomic_helper_commit_modeset_enables() -> putting enables 
here..
drm_atomic_helper_commit_planes()
}

drm_atomic_helper_commit_hw_done()
drm_atomic_helper_wait_for_flip_done()
drm_atomic_helper_wait_for_vblanks()
drm_atomic_helper_cleanup_planes()
}

You can always trace the flow and see if there's a function call that's useful 
for you in there.

Thank you for such a detailed explanation


I would just call set_config if required in 2 places, once in crtc disable, 
once in crtc enable.

Well, in the other mail thread [1] Ville Syrjälä gave an idea to switch
from own CRTC implementation to drm_simple_kms_helper which can be 
definitely

done now as I'm moving from legacy to fully atomic operation.
So, I did the change and have something like the below now:

static void display_enable(struct drm_simple_display_pipe *pipe,
    struct drm_crtc_state *crtc_state)
{
    struct drm_plane *plane = >plane;
    struct drm_framebuffer *fb = plane->state->fb;
    struct drm_crtc *crtc = >crtc;

    display_set_config(pipe, fb);
    drm_crtc_vblank_on(crtc);
}

static void display_disable(struct drm_simple_display_pipe *pipe)
{
    struct drm_crtc *crtc = >crtc;

    display_set_config(pipe, NULL);
    drm_crtc_vblank_off(crtc);
}
I believe this is what you meant while suggesting "once in crtc
disable, once in crtc enable" WRT drm_simple_kms_helper's
drm_simple_display_pipe_funcs callbacks.

Candidates I am playing with are:
1. drm_crtc_helper_funcs.atomic_flush
2. drm_mode_config_funcs.atomic_commit

During experiments with the above I see that during "on" phase in the
drm_crtc_state I can see that mode, enable and active 

[PATCH] drm/panel: Fix ARM Versatile panel clocks

[Linus Walleij]

These clocks are in kHz not in Hz, oops. Fix it so my
new bandwidth calculations patch starts working with these
panels.

Cc: Eric Anholt 
Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/panel/panel-arm-versatile.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c 
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index 3930b4925b15..35707d0ae6b0 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -132,7 +132,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 79,
.height_mm = 54,
.mode = {
-   .clock = 1000,
+   .clock = 1,
.hdisplay = 320,
.hsync_start = 320 + 6,
.hsync_end = 320 + 6 + 6,
@@ -156,7 +156,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 171,
.height_mm = 130,
.mode = {
-   .clock = 2500,
+   .clock = 25000,
.hdisplay = 640,
.hsync_start = 640 + 24,
.hsync_end = 640 + 24 + 96,
@@ -179,7 +179,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 34,
.height_mm = 45,
.mode = {
-   .clock = 62500,
+   .clock = 625000,
.hdisplay = 176,
.hsync_start = 176 + 2,
.hsync_end = 176 + 2 + 3,
@@ -203,7 +203,7 @@ static const struct versatile_panel_type versatile_panels[] 
= {
.width_mm = 37,
.height_mm = 50,
.mode = {
-   .clock = 540,
+   .clock = 5400,
.hdisplay = 240,
.hsync_start = 240 + 10,
.hsync_end = 240 + 10 + 10,
-- 
2.14.3

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

Re: Questions on page flips and atomic modeset

[Oleksandr Andrushchenko]

Hello, Ville!

On 02/06/2018 06:04 PM, Ville Syrjälä wrote:

On Tue, Feb 06, 2018 at 11:59:37AM +0200, Oleksandr Andrushchenko wrote:

Hello, Ville!

Thank you very much for such a comprehensive answer.

Please see inline


On 02/05/2018 06:47 PM, Ville Syrjälä wrote:

On Mon, Feb 05, 2018 at 06:03:25PM +0200, Oleksandr Andrushchenko wrote:

Hello,


I have a DRM driver which implements display protocol for Xen [1]
and this protocol has a dedicated XENDISPL_OP_PG_FLIP request which
tells the other end that some display buffer needs to be displayed,
e.g. it is issued by the frontend DRM driver to the corresponding
backend when the former wants to display a buffer.
Two notes:
1. Communication between two remote parties can obviously fail.
2. At the moment only primary plane is supported, so we can think of
the display buffer as of CRTC's primary fb.

There are two APIs available for user-space to initiate a page-flip
(please correct me if I am wrong here): legacy via DRM_IOCTL_MODE_PAGE_FLIP
and more recent via DRM_IOCTL_MODE_ATOMIC. My current implementation
(which is 4.9 based) uses drm_crtc_funcs.page_flip callback to send
XENDISPL_OP_PG_FLIP request to the backend, so if communication fails
I can return an error code, so the DRM core knows that page flip
cannot be done.

But now I am about to enable page flipping via DRM_IOCTL_MODE_ATOMIC for
which this happens without DRM_IOCTL_MODE_PAGE_FLIP, but via .atomic_check +
.atomic_flush callbacks.

The solution I have in mind is that I move the XENDISPL_OP_PG_FLIP request
to the .atomic_flush callback which seems to be the right place to serve
both DRM_IOCTL_MODE_PAGE_FLIP and DRM_IOCTL_MODE_ATOMIC (is this?).

The questions I have with this are:

1. What is the framebuffer I can send to the backend?
I assume I can use crtc->primary->fb from
drm_crtc_helper_funcs.atomic_flush,
is this assumption correct?

Planes are explicit in the atomic world, so you should just deal with
the plane if and when it's part of the drm_atomic_state. Look at eg.
drm_atomic_helper_commit_planes() how to figure out what's in the
state.

Yes, this is clear. The question was about the frame buffer
I get in drm_crtc_helper_funcs.atomic_flush which only has
old_crtc_state, so I assumed I can use crtc->primary->fb there.
Or you mean I have to dig into old_crtc_state->state to find
out if there is a plane and if it has a frambuffer and if so
use it instead of crtc->primary->fb?

You will get the plane explicitly as part of the drm_atomic_state.
Normally you shouldn't need to go find it via other means.

Oh, and never use the plane->fb etc. pointers in an atomic driver.
Those are for legacy purposes only. Atomic drivers should only ever
deal with proper state objects.

I am using fb from corresponding state now, thank you



   And I guess you're already planning on using that helper since
you mention .atomic_flush().

Not directly, but via drm_mode_config_funcs.atomic_commit

.atomic_commit() is a hook the driver has to provide. Most drivers use
the helper for it, which in turn requires the driver to provide other
hooks such as .atomic_flush(). That is what you appear to be doing.

you are correct

One should really think of the drm_atomic_state as more of a transaction
rather than as a state (since not all objects need be part of it).

Thank you

2. Is the check (either to send or not) for crtc->primary->fb != NULL
enough?
I assume there are other cases when .atomic_flush gets called,
so is there a way I can filter out unneeded cases? E.g. those which
are not for page flipping?

Each object taking part in the transaction will have an associated
new state and old state.

As I replied above I only have old state in .atomic_flush

Oh right. That way of passing the old state only dates back to earlier
days of atomic. To find the new state what you should do these days
is something like:

foo(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
struct drm_atomic_state *state = old_state->state;
struct drm_crtc_state *new_state =
drm_atomic_get_new_crtc_state(state, crtc);
...

The old way was to use the crtc->state pointer as either the old
or new state depending on where you are in the commit sequence.
But that wasn't very good so Maarten changed things so that we
now have explicit old and new states for each object tracked in
the drm_atomic_state.

I think what we should really do is change most of the hooks to
pass crtc+drm_atomic_state instead, and let each function grab
the old and/or new crtc state from the drm_atomic_state as needed.
I believe that would avoid confusing people with just the old or
new state.

That would be great

   You can compare the two to figure out what
changed, and in addition there may already some flags in the base
class for the state that indicate what may have changed (eg.
drm_crtc_state::mode_changed etc.). Such flags may be set by the
core to help figure out what needs doing.

Yes, thank you

3. If 

[PATCH] dma-buf: Remove unused sync_dump()

[Chris Wilson]

sync_dump() is an unused, unexported, function that adds 64k to the
kernel image and doesn't even provide locking around the global array it
uses.

add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
Function old new   delta
sync_dump198   --198
sync_dump_buf  65536   -  -65536

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
---
 drivers/dma-buf/sync_debug.c | 26 --
 drivers/dma-buf/sync_debug.h |  2 --
 2 files changed, 28 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index c4c8ecb24aa9..d1caa9f060a1 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -207,29 +207,3 @@ static __init int sync_debugfs_init(void)
return 0;
 }
 late_initcall(sync_debugfs_init);
-
-#define DUMP_CHUNK 256
-static char sync_dump_buf[64 * 1024];
-void sync_dump(void)
-{
-   struct seq_file s = {
-   .buf = sync_dump_buf,
-   .size = sizeof(sync_dump_buf) - 1,
-   };
-   int i;
-
-   sync_debugfs_show(, NULL);
-
-   for (i = 0; i < s.count; i += DUMP_CHUNK) {
-   if ((s.count - i) > DUMP_CHUNK) {
-   char c = s.buf[i + DUMP_CHUNK];
-
-   s.buf[i + DUMP_CHUNK] = 0;
-   pr_cont("%s", s.buf + i);
-   s.buf[i + DUMP_CHUNK] = c;
-   } else {
-   s.buf[s.count] = 0;
-   pr_cont("%s", s.buf + i);
-   }
-   }
-}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index d615a89f774c..1fd4d9ab3c4a 100644
--- a/drivers/dma-buf/sync_debug.h
+++ b/drivers/dma-buf/sync_debug.h
@@ -70,14 +70,12 @@ void sync_timeline_debug_add(struct sync_timeline *obj);
 void sync_timeline_debug_remove(struct sync_timeline *obj);
 void sync_file_debug_add(struct sync_file *fence);
 void sync_file_debug_remove(struct sync_file *fence);
-void sync_dump(void);
 
 #else
 # define sync_timeline_debug_add(obj)
 # define sync_timeline_debug_remove(obj)
 # define sync_file_debug_add(fence)
 # define sync_file_debug_remove(fence)
-# define sync_dump()
 #endif
 
 #endif /* _LINUX_SYNC_H */
-- 
2.16.1

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

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

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

--- Comment #24 from Bong Cosca  ---
My screen width is 1280px. Is there a reason why the amdgpu driver says the GPU
has a front buffer pitch of 6144 bytes in non-accelerated mode while the pitch
in accelerated mode is 5120?

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

Re: [PATCH v3 0/3] drm/omap: Make omapdss API more generic + related patches

[Tomi Valkeinen]

On 07/02/18 16:11, Jyri Sarha wrote:
> Since v2:
> - Simplify dispc_mgr_has_framedone() 
> - dispc_hw_to_api_irq() and dispc_api_to_hw_irq() use new dispc_irq_bits[]
> - rename dispc_ops read_irqstatus() to read_and_clear_irqstatus() and remove
>   clearmask
> - precalculate priv->irq_uf_mask in omap_drm_irq_install() and use it in
>   omap_irq_fifo_underflow()

Can you run these through checkpatch? There was at least one issue that
needs to be fixed:

WARNING: static const char * array should probably be static const char
* const

Other than the small comments I sent, I think it looks good.

Laurent, do you have any objections?

I think we probably will change the design later on how the irqs are
handled (possibly move the irq handling code away from the common
parts), but I think this cleans up things nicely for the time being.

 Tomi

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

[PATCH v4 10/12] drm/sun4i: Implement A83T HDMI driver

[Jernej Skrabec]

A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.

Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Kconfig  |   9 ++
 drivers/gpu/drm/sun4i/Makefile |   4 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 196 
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |  44 ++
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 270 +
 5 files changed, 523 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
 create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 882d85db9053..7327da3bc94f 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
  do some alpha blending and feed graphics to TCON. If M is
  selected the module will be called sun4i-backend.
 
+config DRM_SUN8I_DW_HDMI
+   tristate "Support for Allwinner version of DesignWare HDMI"
+   depends on DRM_SUN4I
+   select DRM_DW_HDMI
+   help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
 config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2b37a6abbb1d..a7c47d9aa64d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,6 +9,9 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
 sun4i-drm-hdmi-y   += sun4i_hdmi_i2c.o
 sun4i-drm-hdmi-y   += sun4i_hdmi_tmds_clk.o
 
+sun8i-drm-hdmi-y   += sun8i_dw_hdmi.o
+sun8i-drm-hdmi-y   += sun8i_hdmi_phy.o
+
 sun8i-mixer-y  += sun8i_mixer.o sun8i_ui_layer.o \
   sun8i_vi_layer.o sun8i_ui_scaler.o \
   sun8i_vi_scaler.o sun8i_csc.o
@@ -26,4 +29,5 @@ obj-$(CONFIG_DRM_SUN4I)   += sun6i_drc.o
 
 obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
 obj-$(CONFIG_DRM_SUN4I_HDMI)   += sun4i-drm-hdmi.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
 obj-$(CONFIG_DRM_SUN8I_MIXER)  += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index ..9f40a44b456b
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Jernej Skrabec 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "sun8i_dw_hdmi.h"
+
+static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+  struct drm_display_mode *mode,
+  struct drm_display_mode *adj_mode)
+{
+   struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
+
+   clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
+}
+
+static const struct drm_encoder_helper_funcs
+sun8i_dw_hdmi_encoder_helper_funcs = {
+   .mode_set = sun8i_dw_hdmi_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs sun8i_dw_hdmi_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static enum drm_mode_status
+sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
+const struct drm_display_mode *mode)
+{
+   if (mode->clock > 297000)
+   return MODE_CLOCK_HIGH;
+
+   return MODE_OK;
+}
+
+static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
+ void *data)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct dw_hdmi_plat_data *plat_data;
+   struct drm_device *drm = data;
+   struct device_node *phy_node;
+   struct drm_encoder *encoder;
+   struct sun8i_dw_hdmi *hdmi;
+   int ret;
+
+   if (!pdev->dev.of_node)
+   return -ENODEV;
+
+   hdmi = devm_kzalloc(>dev, sizeof(*hdmi), GFP_KERNEL);
+   if (!hdmi)
+   return -ENOMEM;
+
+   plat_data = >plat_data;
+   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;
+
+   

[PATCH v2] spi: kconfig: Remove AVR32 dep. from SPI_ATMEL

[Ulf Magnusson]

The AVR32 symbol was removed in commit 26202873bb51 ("avr32: remove
support for AVR32 architecture").
---
Changes in v2:
Remove the AVR32 reference from the help text too.

 drivers/spi/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 603783976b81..6fb0347a24f2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -72,10 +72,10 @@ config SPI_ARMADA_3700
 config SPI_ATMEL
tristate "Atmel SPI Controller"
depends on HAS_DMA
-   depends on (ARCH_AT91 || AVR32 || COMPILE_TEST)
+   depends on (ARCH_AT91 || COMPILE_TEST)
help
  This selects a driver for the Atmel SPI Controller, present on
- many AT32 (AVR32) and AT91 (ARM) chips.
+ many AT91 (ARM) chips.
 
 config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
-- 
2.14.1

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

[PATCH v7 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

[Vivek Gautam]

From: Sricharan R 

The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.

Signed-off-by: Sricharan R 
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam 
---
 drivers/iommu/arm-smmu.c | 42 ++
 1 file changed, 38 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 9e2f917e16c2..c024f69c1682 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -913,11 +913,15 @@ static void arm_smmu_destroy_domain_context(struct 
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = _domain->cfg;
-   int irq;
+   int ret, irq;
 
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
 
+   ret = pm_runtime_get_sync(smmu->dev);
+   if (ret)
+   return;
+
/*
 * Disable the context bank and free the page tables before freeing
 * it.
@@ -932,6 +936,8 @@ static void arm_smmu_destroy_domain_context(struct 
iommu_domain *domain)
 
free_io_pgtable_ops(smmu_domain->pgtbl_ops);
__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+   pm_runtime_put_sync(smmu->dev);
 }
 
 static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
@@ -1407,14 +1413,22 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
 
-   ret = arm_smmu_master_alloc_smes(dev);
+   ret = pm_runtime_get_sync(smmu->dev);
if (ret)
goto out_cfg_free;
 
+   ret = arm_smmu_master_alloc_smes(dev);
+   if (ret)
+   goto out_rpm_put;
+
iommu_device_link(>iommu, dev);
 
+   pm_runtime_put_sync(smmu->dev);
+
return 0;
 
+out_rpm_put:
+   pm_runtime_put_sync(smmu->dev);
 out_cfg_free:
kfree(cfg);
 out_free:
@@ -1427,7 +1441,7 @@ static void arm_smmu_remove_device(struct device *dev)
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct arm_smmu_master_cfg *cfg;
struct arm_smmu_device *smmu;
-
+   int ret;
 
if (!fwspec || fwspec->ops != _smmu_ops)
return;
@@ -1435,8 +1449,15 @@ static void arm_smmu_remove_device(struct device *dev)
cfg  = fwspec->iommu_priv;
smmu = cfg->smmu;
 
+   ret = pm_runtime_get_sync(smmu->dev);
+   if (ret)
+   return;
+
iommu_device_unlink(>iommu, dev);
arm_smmu_master_free_smes(fwspec);
+
+   pm_runtime_put_sync(smmu->dev);
+
iommu_group_remove_device(dev);
kfree(fwspec->iommu_priv);
iommu_fwspec_free(dev);
@@ -2131,6 +2152,14 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
if (err)
return err;
 
+   platform_set_drvdata(pdev, smmu);
+
+   pm_runtime_enable(dev);
+
+   err = pm_runtime_get_sync(dev);
+   if (err)
+   return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2172,9 +2201,9 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
return err;
}
 
-   platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
arm_smmu_test_smr_masks(smmu);
+   pm_runtime_put_sync(dev);
 
/*
 * For ACPI and generic DT bindings, an SMMU will be probed before
@@ -2211,8 +2240,13 @@ static int arm_smmu_device_remove(struct platform_device 
*pdev)
if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
dev_err(>dev, "removing device with active domains!\n");
 
+   pm_runtime_get_sync(smmu->dev);
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+   pm_runtime_put_sync(smmu->dev);
+
+   pm_runtime_disable(smmu->dev);
+
return 0;
 }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH v4 11/12] ARM: dts: sun8i: a83t: Add HDMI display pipeline

[Jernej Skrabec]

This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi, hdmi phy and hdmi pinctrl entries.

Signed-off-by: Jernej Skrabec 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +-
 1 file changed, 118 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7f4955a5fab7..b8e629e5dbf3 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -155,7 +155,7 @@
 
de: display-engine {
compatible = "allwinner,sun8i-a83t-display-engine";
-   allwinner,pipelines = <>;
+   allwinner,pipelines = <>, <>;
status = "disabled";
};
 
@@ -208,6 +208,32 @@
};
};
 
+   mixer1: mixer@120 {
+   compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+   reg = <0x0120 0x10>;
+   clocks = <_clocks CLK_BUS_MIXER1>,
+<_clocks CLK_MIXER1>;
+   clock-names = "bus",
+ "mod";
+   resets = <_clocks RST_WB>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer1_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer1_out_tcon1: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer1>;
+   };
+   };
+   };
+   };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -256,6 +282,43 @@
};
};
 
+   tcon1: lcd-controller@1c0d000 {
+   compatible = "allwinner,sun8i-a83t-tcon-tv";
+   reg = <0x01c0d000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON1>, < CLK_TCON1>;
+   clock-names = "ahb", "tcon-ch1";
+   resets = < RST_BUS_TCON1>;
+   reset-names = "lcd";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon1_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon1_in_mixer1: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon1>;
+   };
+   };
+
+   tcon1_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   tcon1_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = 
<_in_tcon1>;
+   };
+   };
+   };
+   };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
 "allwinner,sun7i-a20-mmc";
@@ -427,6 +490,11 @@
drive-strength = <40>;
};
 
+   hdmi_pins: hdmi-pins {
+   pins = "PH6", "PH7", "PH8";
+   function = "hdmi";
+   };
+
i2c0_pins: i2c0-pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -685,6 +753,55 @@
interrupts = ;
};
 
+   hdmi: hdmi@1ee {
+   compatible = "allwinner,sun8i-a83t-dw-hdmi";
+   reg = <0x01ee 0x1>;
+   reg-io-width = <1>;
+   interrupts = ;
+   clocks = < CLK_BUS_HDMI>, < CLK_HDMI_SLOW>,
+< CLK_HDMI>;
+   clock-names = "iahb", "isfr", "tmds";
+   resets = < RST_BUS_HDMI1>;
+  

[PATCH v4 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata

[Jernej Skrabec]

dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.

Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")

Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Acked-by: Neil Armstrong 
Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c   | 31 -
 drivers/gpu/drm/imx/dw_hdmi-imx.c   | 13 +---
 drivers/gpu/drm/meson/meson_dw_hdmi.c   | 14 +
 drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 12 +--
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
 include/drm/bridge/dw_hdmi.h| 13 ++--
 6 files changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
 
-   platform_set_drvdata(pdev, hdmi);
-
return hdmi;
 
 err_iahb:
@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
 /* 
-
  * Probe/remove API, used from platforms based on the DRM bridge API.
  */
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
 {
struct dw_hdmi *hdmi;
 
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
 
drm_bridge_add(>bridge);
 
-   return 0;
+   return hdmi;
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_probe);
 
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
 {
-   struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(>bridge);
 
__dw_hdmi_remove(hdmi);
@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
 /* 
-
  * Bind/unbind API, used from platforms based on the component framework.
  */
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
 {
struct dw_hdmi *hdmi;
int ret;
 
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
-   return PTR_ERR(hdmi);
+   return hdmi;
 
ret = drm_bridge_attach(encoder, >bridge, NULL);
if (ret) {
-   dw_hdmi_remove(pdev);
+   dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}
 
-   return 0;
+   return hdmi;
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_bind);
 
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
 {
-   struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
 }
 EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
 struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+   struct dw_hdmi *hdmi;
struct regmap *regmap;
 };
 
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
drm_encoder_init(drm, encoder, _hdmi_imx_encoder_funcs,
 DRM_MODE_ENCODER_TMDS, NULL);
 
-   ret = dw_hdmi_bind(pdev, encoder, plat_data);
+   platform_set_drvdata(pdev, hdmi);
+
+   hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
 
/*
 * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
 * which would have called the encoder cleanup.  Do it manually.
 */
-   if (ret)
+   if (IS_ERR(hdmi->hdmi)) {
+   ret = PTR_ERR(hdmi->hdmi);
drm_encoder_cleanup(encoder);
+   }
 
return ret;
 }
@@ -254,7 +259,9 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device 

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

[Giulio Benetti]

Hi,

Il 07/02/2018 11:39, Maxime Ripard ha scritto:
> On Wed, Jan 24, 2018 at 08:37:28PM +0100, Giulio Benetti wrote:
> Also, how was it tested? This seems quite weird that we haven't caught
> that one sooner, and I'm a bit worried about the possible regressions
> here.

 It sounds really strange to me too,
 because everybody under uboot use "sync:3"(HIGH).
 I will retry to measure,
 unfortunately at home I don't have a scope,
 but I think I'm going to have one soon, because of this. :)
>>>
>>> Here I am with scope captures and tcon0 registers dump:
>>> tcon0_regs => https://pasteboard.co/H4r8Zcs.png
>>> dclk_d0 => https://pasteboard.co/H4r8QRe.png
>>> dclk_de => https://pasteboard.co/H4r8zh4R.png
>>> dclk_vsnc => https://pasteboard.co/H4r8Hye.png
>>>
>>> As you can see circled in reg on registers,
>>> TCON0_IO_POL_REG = 0x.
>>> But on all the waveforms you can see:
>>> - dclk_d0: clock phase is 0, but it starts with falling edge, otherwise
>>> the rising front overlaps dclk rising edge(not good), so to me this is
>>> falling, then I mean it Negative.
>>> - dclk_de: de pulse is clearly negative, even if register is 0 and its'
>>> polarity bit is 0.
>>> - dclk_vsnc: same as dclk_de
>>> - dclk_hsync: I didn't take scope screenshot but I can assure you it's
>>> negative.
>>>
>>> You can also check all the other registers about TCON0.
>>>
>>> Now I proceed testing it on A33, maybe the peripheral is slightly
>>> different between Axx SoCs, if I find it that way,
>>> it should be only a check about SoC or peripheral ID,
>>> and treat polarity as it should be done.
>>
>> Here I am with A33 waveforms:
>> tcon0_regs => https://pasteboard.co/H4rXfN0M.png
>> dclk_d0 => https://pasteboard.co/H4rVXwy.png
>> dclk_de => https://pasteboard.co/H4rWDt8.png
>> dclk_vsnc => https://pasteboard.co/H4rWRACu.png
>> dclk_hsync => https://pasteboard.co/H4rWK6I.png
>>
>> It behaves the same way as A20, so as I mean IO polarity,
>> all signals(except D0-D23), are inverted.
>> For A33 I've used A33-OLinuXino.
>> For A20 our LiNova1.
> 
> If you have an A33 handy, you probably want to read that mail:
> https://lists.freedesktop.org/archives/dri-devel/2017-July/147951.html
> 
> Especially the 90-phase part.

Here is a summary of different SoCs TCON:
With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase

A10, A20

With DCLK_Sel:
0x0 => normal phase
0x1 => 1/3 phase
0x2 => 2/3 phase
0x5 => DCLK/2 phase 0
0x4 => DCLK/2 phase 90

A31, A31s, A33, A80, A83T

Also I've found that TCON1 has not this feature,
nor first, nor second case(at least is not described on user manuals).

So I could handle differently according to SoC.
Unfortunately there is not TCON register keeping IP version,
so the only way I see is to create a long if-or statement to understand
which kind of TCON we're using.

But what sounds not the best to me, is that DCLK is divided by 2 if
using phase 90. So we need to reconsider also bitclock driver according
to this.
I don't know if it make sense.

IMHO, I would keep only:
- As normal => "0x1 => 1/3 phase"
- As inverted => "0x0 => normal phase"

According to scope captures above on both A20 and A33.
Unfortunately I don't have other boards for the other SoCs to take captures.

What do you think?

> 
> Maxime
> 

-- 
Giulio Benetti
R Manager &
Advanced Research

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: add func to get max iomem address

[Michel Dänzer]

On 2018-02-08 09:32 AM, Chunming Zhou wrote:
> it will be used to check if the driver needs swiotlb
> 
> Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
> Signed-off-by: Chunming Zhou 
> Reviewed-by: Monk Liu 
> ---
>  include/drm/drm_cache.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
> index beab0f0d0cfb..442c9ba63d03 100644
> --- a/include/drm/drm_cache.h
> +++ b/include/drm/drm_cache.h
> @@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
> num_pages);
>  void drm_clflush_sg(struct sg_table *st);
>  void drm_clflush_virt_range(void *addr, unsigned long length);
>  
> +static inline u64 drm_get_max_iomem(void)
> +{
> + struct resource *tmp;
> + u64 max_iomem = 0;
> +
> + for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
> + max_iomem = max(max_iomem,  tmp->end);
> + }
> +
> + return max_iomem;
> +}

I don't think this needs to be an inline function, does it?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: add func to get max iomem address

[Christian König]

Am 08.02.2018 um 10:09 schrieb Michel Dänzer:

On 2018-02-08 09:32 AM, Chunming Zhou wrote:

it will be used to check if the driver needs swiotlb

Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
Signed-off-by: Chunming Zhou 
Reviewed-by: Monk Liu 
---
  include/drm/drm_cache.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index beab0f0d0cfb..442c9ba63d03 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[], unsigned long 
num_pages);
  void drm_clflush_sg(struct sg_table *st);
  void drm_clflush_virt_range(void *addr, unsigned long length);
  
+static inline u64 drm_get_max_iomem(void)

+{
+   struct resource *tmp;
+   u64 max_iomem = 0;
+
+   for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
+   max_iomem = max(max_iomem,  tmp->end);
+   }
+
+   return max_iomem;
+}

I don't think this needs to be an inline function, does it?


Well it is defined in a header, so it must be inline because of this.

But if you know a good place, we could also move it into some C file.

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

Re: [PATCH 1/3] drm: add func to get max iomem address

[Michel Dänzer]

On 2018-02-08 10:15 AM, Chunming Zhou wrote:
> On 2018年02月08日 17:09, Michel Dänzer wrote:
>> On 2018-02-08 09:32 AM, Chunming Zhou wrote:
>>> it will be used to check if the driver needs swiotlb
>>>
>>> Change-Id: Idbe47af8f12032d4803bb3d47273e807f19169c3
>>> Signed-off-by: Chunming Zhou 
>>> Reviewed-by: Monk Liu 
>>> ---
>>>   include/drm/drm_cache.h | 13 +
>>>   1 file changed, 13 insertions(+)
>>>
>>> diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
>>> index beab0f0d0cfb..442c9ba63d03 100644
>>> --- a/include/drm/drm_cache.h
>>> +++ b/include/drm/drm_cache.h
>>> @@ -39,6 +39,19 @@ void drm_clflush_pages(struct page *pages[],
>>> unsigned long num_pages);
>>>   void drm_clflush_sg(struct sg_table *st);
>>>   void drm_clflush_virt_range(void *addr, unsigned long length);
>>>   +static inline u64 drm_get_max_iomem(void)
>>> +{
>>> +    struct resource *tmp;
>>> +    u64 max_iomem = 0;
>>> +
>>> +    for (tmp = iomem_resource.child; tmp; tmp = tmp->sibling) {
>>> +    max_iomem = max(max_iomem,  tmp->end);
>>> +    }
>>> +
>>> +    return max_iomem;
>>> +}
>> I don't think this needs to be an inline function, does it?
> If no inline, will report building warning that this function is defined
> but not used in some files including drm_cache.h

What I mean is that it can be a normal function in drivers/gpu/drm/*.c
with EXPORT_SYMBOL.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel