Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda]

On 16.11.2017 21:27, Eric Anholt wrote:
> Andrzej Hajda  writes:
>
>> On 15.11.2017 21:26, Eric Anholt wrote:
>>> I'm happy to have the DSI panel finally working on VC4 (just waiting on
>>> https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
>>> but now I've got another problem to solve.  It would be great if I could
>>> include the DSI panel in our upstream DT, so that it automatically
>>> worked when you plugged one in.  However, right now we return
>>> -EPROBE_DEFER during bind unless the panel has actually shown up.  This
>>> means that if you don't have the panel actually connected, you get this
>>> sequence at startup:
>>>
>>> [   10.719929] [drm] Initialized
>>> [   10.829510] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi 
>>> mapping ok
>>> [   10.844043] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
>>> [   10.848626] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
>>> [   10.850214] vc4-drm soc:gpu: failed to bind 3f70.dsi (ops 
>>> vc4_dsi_ops [vc4]): -517
>>> [   10.856559] vc4-drm soc:gpu: master bind failed: -517
>>>
>>> [...]
>>>
>>> [   10.967718] rpi_touchscreen 3-0045: Atmel I2C read failed: -6
>>>
>>> Once the panel driver fails to probe, we never get asked to re-bind vc4,
>>> and drm_of_find_panel_or_bridge looks like it would just give us
>>> -EPROBE_DEFER again since the panel still wasn't registered.
>>>
>>> Does anyone have any suggestions for handling this?
>> I guess you should call component_add only when all required resources
>> are present(including panel), I suppose moving it to vc4_dsi_host_attach
>> should help.
> How can I decide when the panel driver has tried to probe and failed,
> versus not tried to probe yet?  find_panel_or_bridge gives me
> -EPROBE_DEFER either way.
>
>> On the other side I am curious why EPROBE_DEFER from bind does not fail
>> probing of some component (the last one probed), with proper error
>> propagation it should cause defer_probing of one of the components or
>> master, and probe/bind should be retried after panel's probe.
> The panel probe failed, though, so there's no trigger to re-probe other
> drivers.

OK, I misunderstood your problem. And after 2nd read I am not sure what
do you want to achieve exactly?

Do you want to 'hotplug' DSI panel? Or just make it working with and
without the panel. In 2nd case other paths (HDMI) should still work, I
guess.

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.

2. Check for presence of the panel's driver before registering the bus,
if not present defer probing (but I am not sure if driver's registration
will trigger deferred probing, should be checked).

This way if the panel's driver is present during mipi bus registration
and after that panel should be bound to the drivers, otherwise  it means
probe failed. This solutions requires discovering panels compatible in
DSI driver. Quite complicated and very hacky.

3. In panel's probe attach the panel to the bus before hardware probe
and detach it if the physical panel is not present. This way dsi host
callbacks will be called and can be used to discover failed probes.


Regards

Andrzej

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

[PATCH 1/5] drm: Add DRM client cap for aspect-ratio

[Shashank Sharma]

From: aknautiy 

A new drm client cap is required to enable user-space to advertise
if it supports modes with aspect-ratio. Based on this cap value, the
kernel will take a call on exposing the aspect ratio information in
modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: aknautiy 
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 7 +++
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 4aafe48..e092550 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 0e0c868..6e0e435 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,13 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True if client has asked to expose the aspect-ratio flags with mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..fe5f531 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will expose aspect ratio flags to userspace.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

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

[PATCH 2/5] drm: Handle aspect ratio in modeset paths

[Shashank Sharma]

From: aknautiy 

If the user mode does not support aspect-ratio, and requests for
a modeset with aspect ratio flags, then the flag bits reprsenting
aspect ratio must be ignored.

Similarly, if user space doesn't set the aspect ratio client cap,
while preparing a usermode, the aspect-ratio info must not be given
into it.

This patch:
1. adds a new bit field aspect_ratio_allowed in drm_atomic_state,
   which is set only if the aspect-ratio is supported by the user.
2. discards the aspect-ratio info from the user mode while
   preparing kernel mode structure, during modeset, if the
   user does not support aspect ratio.
3. avoids setting the aspect-ratio info in user-mode, while
   converting user-mode from the kernel-mode.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 
Signed-off-by: aknautiy 
---
 drivers/gpu/drm/drm_atomic.c | 41 +
 drivers/gpu/drm/drm_crtc.c   | 19 +++
 include/drm/drm_atomic.h |  2 ++
 3 files changed, 54 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7e0e7be..3ef429b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -33,7 +33,6 @@
 #include 
 
 #include "drm_crtc_internal.h"
-
 void __drm_crtc_commit_free(struct kref *kref)
 {
struct drm_crtc_commit *commit =
@@ -337,18 +336,30 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
state->mode_blob = NULL;
 
if (mode) {
-   drm_mode_convert_to_umode(, mode);
+   /*
+* If the user has not asked for aspect ratio support,
+* take a copy of the 'mode' and set the aspect ratio as
+* None. This copy is used to prepare the user-mode with no
+* aspect-ratio info.
+*/
+   struct drm_display_mode ar_mode;
+   struct drm_atomic_state *atomic_state = state->state;
+
+   drm_mode_copy(_mode, mode);
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_mode.picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   drm_mode_convert_to_umode(, _mode);
state->mode_blob =
drm_property_create_blob(state->crtc->dev,
-sizeof(umode),
-);
+sizeof(umode),
+);
if (IS_ERR(state->mode_blob))
return PTR_ERR(state->mode_blob);
 
-   drm_mode_copy(>mode, mode);
+   drm_mode_copy(>mode, _mode);
state->enable = true;
DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
-mode->name, state);
+ar_mode.name, state);
} else {
memset(>mode, 0, sizeof(state->mode));
state->enable = false;
@@ -385,10 +396,23 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
 
if (blob) {
+   struct drm_mode_modeinfo *ar_umode;
+   struct drm_atomic_state *atomic_state;
+
+   /*
+* If the user-space does not ask for aspect-ratio
+* the aspect ratio bits in the drmModeModeinfo from user,
+* does not mean anything. Therefore these bits must be
+* discarded.
+*/
+   ar_umode = (struct drm_mode_modeinfo *) blob->data;
+   atomic_state = state->state;
+   if (atomic_state && !atomic_state->allow_aspect_ratio)
+   ar_umode->flags &= (~DRM_MODE_FLAG_PIC_AR_MASK);
if (blob->length != sizeof(struct drm_mode_modeinfo) ||
drm_mode_convert_umode(>mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+  (const struct drm_mode_modeinfo *)
+   ar_umode))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
@@ -2241,6 +2265,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 
state->acquire_ctx = 
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
+   state->allow_aspect_ratio = file_priv->aspect_ratio_allowed;
 
 retry:
plane_mask = 0;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e6..a2d34fa 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -425,6 +425,13 @@ 

[PATCH 4/5] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 4a3f68a..2e8a11e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1015,6 +1015,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1549,6 +1550,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1594,6 +1610,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
2.7.4

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

[PATCH 3/5] drm: Expose modes with aspect ratio, only if requested

[Shashank Sharma]

From: aknautiy 

We parse the EDID and add all the modes in the connector's
modelist. This adds CEA modes with aspect ratio information
too, regadless of if user space requested this information or
not.

This patch prunes the modes with aspect-ratio information, from
a connector's modelist, if the user-space has not set the aspect
ratio DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: aknautiy 
---
 drivers/gpu/drm/drm_connector.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc89..a246bb5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1285,6 +1285,13 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE)
+   return false;
 
return true;
 }
-- 
2.7.4

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

[PATCH 0/5] Aspect ratio support in DRM layer

[Shashank Sharma]

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in
translation during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series, adds a DRM client option for aspect ratio, and loads aspect
ratio flags, only when the client sets this cap. Also, to test this patch series
there is a userspace implementation by Ankit Nautiyal in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/

This, helps us in passing HDMI compliance test cases like 7-27, where the test
equipment applies a CEA mode, and expects the exact VIC in the AVI infoframes.

Shashank Sharma (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ankit Nautiyal (3):
  drm: Add DRM client cap for aspect-ratio
  drm: Handle aspect ratio in modeset paths
  drm: Expose modes with aspect ratio, only if requested

 drivers/gpu/drm/drm_atomic.c| 41 +++
 drivers/gpu/drm/drm_connector.c |  7 +++
 drivers/gpu/drm/drm_crtc.c  | 19 ++
 drivers/gpu/drm/drm_ioctl.c |  5 +
 drivers/gpu/drm/drm_modes.c | 43 +
 include/drm/drm_atomic.h|  2 ++
 include/drm/drm_file.h  |  7 +++
 include/uapi/drm/drm.h  |  7 +++
 include/uapi/drm/drm_mode.h |  6 ++
 9 files changed, 129 insertions(+), 8 deletions(-)

-- 
2.7.4

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

[PATCH 5/5] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2e8a11e..b9ec35b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1559,6 +1559,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1620,6 +1626,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5597a87..64177d7 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -89,6 +89,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -98,6 +100,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
2.7.4

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

[PATCH libdrm] tests: kms: screen probe: Get screen mode when con->count_modes is nonzero

[Liu Ying]

We should not get screen mode when a connector has no modes,
but just leave it be zero.
This may avoid the segmentation fault issue when a connector
status is disconnected, which is caused by memory copying
from a NULL connector mode pointer to a screen mode.

Signed-off-by: Liu Ying 
---
 tests/kms/libkms-test-screen.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/kms/libkms-test-screen.c b/tests/kms/libkms-test-screen.c
index 3369022..9ecf032 100644
--- a/tests/kms/libkms-test-screen.c
+++ b/tests/kms/libkms-test-screen.c
@@ -46,7 +46,8 @@ static void kms_screen_probe(struct kms_screen *screen)
else
screen->connected = false;
 
-   memcpy(>mode, >modes[0], sizeof(drmModeModeInfo));
+   if (con->count_modes)
+   memcpy(>mode, >modes[0], sizeof(drmModeModeInfo));
screen->width = screen->mode.hdisplay;
screen->height = screen->mode.vdisplay;
 
-- 
2.7.4

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

[Bug 103788] Screen goes blank after screen sleep and wioll not come back on

[bugzilla-daemon]

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

coolo...@gmail.com changed:

   What|Removed |Added

   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

[Bug 103788] Screen goes blank after screen sleep and wioll not come back on

[bugzilla-daemon]

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

Bug ID: 103788
   Summary: Screen goes blank after screen sleep and wioll not
come back on
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: coolo...@gmail.com

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

Works fine until screen sleeps, after screen sleeps it will not wake up again.
System is still alive as I can ssh in, but I cannot switch VT, and keyboard
input seems to cause the GPU fan to spin faster.
I also seem unable to kill Xorg via ssh, no matter what I try.

MSI Vega 56, Artix Linux x86_64, linux-amd-staging-drm-next-git
4.14.0-rc3-26c860d55796

-- 
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 95058] When monitors sleep, backlights stay on, screen is black, and can't be woke up

[bugzilla-daemon]

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

--- Comment #2 from coolo...@gmail.com ---
I believe I am getting the same issue on my MSI Vega 56 while running
linux-amd-drm-next kernel one archlinux.
Works fine until screen sleeps, after screen sleeps it will not wake up again.
System is still alive as I can say in, but I cannot switch VT, and keyboard
input seems to cause the GPU fan to spin faster.

-- 
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 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:56 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_edid.c | 23 +--
   1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
   {
+   enum hdmi_picture_aspect picture_aspect;
int err;
   
   	if (!frame || !mode)

@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);

This is slightly going in the loop.
- During the modeset the driver cant specify the aspect ratio
information, as DRM layer lacks this support.
- So we fill the VIC field, by comparing the mode with the
DRM_CEA_MODES[] list. This will pick the first mode
available in the list (regardless of its aspect ratio), and fill the
VIC, as we don't consider aspect ratio while comparing timings.
- Again, now while sending the aspect ratio, we are picking up the VIC,
which may not be correct.

So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is
first in list, we will always pick 4:3 aspect ratio.

Yes. The user didn't care about the aspect ratio (or rather couldn't
specify one) so we just pick one. Which is exactly what we've been
doing ever since we started sending the VIC in the infoframe.
Correct, and we are hoping that this should be better (if not fixed) 
with the aspect ratio support
patches + DRM cap. If the userspace doesn't set the cap, then anyways 
there is no aspect ratio

field available, and VIC would be always 0, as this becomes a Non CEA mode.

Or do you think it would be a better idea to send some VIC instead of No 
VIC, when userspace doesn't

set the DRM cap for aspect ratio ?

- Shashank

- Shashank
   
+	/*

+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
   


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

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:53 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_edid.c | 18 ++
   1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
   static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

This doesn't look right. This means we are expecting a CEA mode without
a pic aspect ratio field,
which is invalid.

No, it's perfectly valid. It's what we currently get from userspace.
Yep, but that's due to missing Aspect ratio handling in the DRM layer. 
If that's fixed, as per the list of CEA modes,
each CEA VIC contains an aspect ratio, which is a part of its unique 
identity.


I guess once we have the aspect ratio handling in DRM layer, it 
would/should look like this:

- EDID gives you all supported modes, including CEA modes with Aspect ratio
- Userspcae gets the mode information, with aspect ratio (for CEA modes)
If ( Userspace picks one of the CEA modes)
- sends a modeset
- we find a matching CEA VIC, found one from modedb
- we load this VIC = nonzero information in AVI IF VIC field,
else
- sends a modeset
- we could not find a matching CEA VIC, as aspect ratio is 0
- we make VIC field in AVI IF as 0

This is important, as HDMI compliance test 7-27 inspects if the VIC 
field in the AVI IF is accurate.


- Shashank

Ankit is going to publish the aspect ratio patch
series again, with proper DRM cap and flags check. Would it be
ok if we have a look that handling first ?

This patch will be needed by that work. Otherwise we're going to stop
sending a VIC for CEA modes with current userspace.
I guess we should force userspaces to start bothering about aspect ratio 
field, right now we
are doing this for Wayland based compositors, may be we should extend it 
to X based too.


- Shashank



+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
   
   		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
*/
   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
   {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
   
   	if (!to_match->clock)

return 0;
   
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

same here, and probably in other CEA match functions.

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct 

Re: [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:51 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.

I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which
talks about
switch from 3D to 2D.  To me it looks like:
If (sending_to_hdmi2_sinks) {
  - for 3d modes send HF-VSIF
  - for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
When you switch from 3d->2d {
   - send_HF-VSIF with 3D_valid bit = 0/1
   }
} else { /* HDMI 1.4b sinks from Appendix F */
  -  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
}

Should we add a is_hdmi2 check and separate these cases ?

We don't support the HDMI forum infoframe. Maybe someone forgot to
implement that when adding the rest of HDMI 2.0 support? ;)

How to make an 'embarrassed smile ' smiley :) ?
Will start looking into it. Meanwhile
Reviewed-by: Shashank Sharma 

v2: Fix the getting has_hdmi_infoframe from display_info
  Always fail constructing the infoframe if the display
  possibly can't handle it

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
   drivers/gpu/drm/drm_edid.c| 34 
+--
   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
   drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
   drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
   drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
   drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
   drivers/gpu/drm/zte/zx_hdmi.c |  1 +
   include/drm/drm_connector.h   |  5 +
   include/drm/drm_edid.h|  1 +
   12 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..4417276ba02e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
union hdmi_infoframe frm;
u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
   
+			/* FIXME: We need the connector here */

drm_hdmi_vendor_infoframe_from_display_mode(
-   , adjusted_mode);
+   , NULL, adjusted_mode);
vic = frm.vendor.hdmi.vic;
if (vic >= ARRAY_SIZE(mhl_vic))
vic = 0;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a64ce7112288..b172139502d6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct 
dw_hdmi *hdmi,
u8 buffer[10];
ssize_t err;
   
-	err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode);
if (err < 0)
/*
 * Going into that statement does not means vendor infoframe
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..9ada0ccf50df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3393,6 +3393,7 @@ static int
   do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
   const u8 *video_db, u8 video_len)
   {
+   struct drm_display_info *info = 

Re: [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/16/2017 9:46 PM, Ville Syrjälä wrote:

On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.

v2: Handle unpack() as well
  Pull the length calculation into a helper

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Reviewed-by: Andrzej Hajda  #v1
Signed-off-by: Ville Syrjälä 
---
   drivers/video/hdmi.c | 51 +++
   1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
hdmi_vendor_infoframe *frame)
   }
   EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
   
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)

+{
+   /* for side by side (half) we also need to provide 3D_Ext_Data */
+   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   return 6;
+   else if (frame->vic != 0 || frame->s3d_struct != 
HDMI_3D_STRUCTURE_INVALID)
+   return 5;
+   else
+   return 4;
+}
+
   /**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
buffer
* @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
   
-	/* empty info frame */

-   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
-   return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
   
-	/* for side by side (half) we also need to provide 3D_Ext_Data */

-   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
-   frame->length = 6;
-   else
-   frame->length = 5;
+   frame->length = hdmi_vendor_infoframe_length(frame);
   
   	length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
   
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,

ptr[5] = 0x0c;
ptr[6] = 0x00;
   
-	if (frame->vic) {

-   ptr[7] = 0x1 << 5;/* video format */
-   ptr[8] = frame->vic;
-   } else {
+   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5;/* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+   } else if (frame->vic) {

Please correct me if I dint understand this properly, but for a HDMI 2.0
sink + 3D transmission, wouldn't I be sending
HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

That vic will be in the AVI infoframe. Here we're concerned about the
VIC in the HDMI vendor infoframe.
Yep, I was thinking if there is any way we can cross check that there is 
a valid HDMI 2 vic

before we do anything here, but seems like a long shot.

Reviewed-by: Shashank Sharma 

- Shashank

+   ptr[7] = 0x1 << 5;/* video format */
+   ptr[8] = frame->vic;
+   } else {
+   ptr[7] = 0x0 << 5;/* video format */
}
   
   	hdmi_infoframe_set_checksum(buffer, length);

@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
   
   	if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||

ptr[1] != 1 ||
-   (ptr[2] != 5 && ptr[2] != 6))
+   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
   
   	length = ptr[2];

@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
   
   	hvf->length = length;
   
-	if (hdmi_video_format == 0x1) {

-   hvf->vic = ptr[4];
-   } else if (hdmi_video_format == 0x2) {
+   if (hdmi_video_format == 0x2) {
+   if (length != 5 && length != 6)
+   return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= 

[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer

[bugzilla-daemon]

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

--- Comment #13 from higu...@gmx.net ---
Can you give me any pointer how to "call the ACPI _PR3 method"?

i already install acpi_call, but have no idea how to use it

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

[RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[John Stultz]

From: Arnd Bergmann 

An otherwise correct cleanup patch from Dan Carpenter turned a broken
failure handling from a feature patch by Hans Verkuil into a kernel
Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
adv7511/33: add HDMI CEC support").

I've managed to piece together several partial problems, though
I'm still struggling with the bigger picture:

adv7511_probe() registers a drm_bridge structure that was allocated
with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
unknown reason, which in turn triggers the registered structure to be
removed.

Elsewhere, kirin_drm_platform_probe() gets called, which calls
of_graph_get_remote_node(), and that returns NULL. Before Dan's
patch we would go on with a NULL pointer here and register that,
now kirin_drm_platform_probe() fails with -ENODEV.

In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
which after not finding a panel goes on to call of_drm_find_bridge(),
and that crashes due to the earlier list corruption.

This addresses the first issue by making sure that adv7511_probe()
does not completely fail when the adv7511_cec_init() function fails,
and instead we just disable the CEC feature. This avoids having the
driver entirely fail to load if just the CEC initialization fails.

Reported-by: Naresh Kamboju 
Cc: Xinliang Liu 
Cc: Dan Carpenter 
Cc: Sean Paul 
Cc: Hans Verkuil 
Cc: Archit Taneja 
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Arnd Bergmann 
[jstultz: Reworked so when adv7511_cec_init() fails, we disable the feature 
instead
of disabling the entire driver, which causes graphics to not funciton]
Signed-off-by: John Stultz 
---
Just wanted to send out my rework of Arnd's patch here.
Feedback would be welcome.

thanks
-john

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 0e14f15..939c3b9 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
 
 #ifdef CONFIG_DRM_I2C_ADV7511_CEC
ret = adv7511_cec_init(dev, adv7511, offset);
-   if (ret)
-   goto err_unregister_cec;
 #else
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
-ADV7511_CEC_CTRL_POWER_DOWN);
+   ret = 1;
 #endif
+   if (ret)
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
+ADV7511_CEC_CTRL_POWER_DOWN);
 
return 0;
 
-- 
2.7.4

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

Re: [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling

[John Stultz]

On Thu, Nov 16, 2017 at 2:20 PM, John Stultz  wrote:
> On Thu, Nov 16, 2017 at 1:50 PM, John Stultz  wrote:
>> On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann  wrote:
>>> An otherwise correct cleanup patch from Dan Carpenter turned a broken
>>> failure handling from a feature patch by Hans Verkuil into a kernel
>>> Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
>>> for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
>>> adv7511/33: add HDMI CEC support").
>>>
>>> I've managed to piece together several partial problems, though
>>> I'm still struggling with the bigger picture:
>>>
>>> adv7511_probe() registers a drm_bridge structure that was allocated
>>> with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
>>> unknown reason, which in turn triggers the registered structure to be
>>> removed.
>>>
>>> Elsewhere, kirin_drm_platform_probe() gets called, which calls
>>> of_graph_get_remote_node(), and that returns NULL. Before Dan's
>>> patch we would go on with a NULL pointer here and register that,
>>> now kirin_drm_platform_probe() fails with -ENODEV.
>>>
>>> In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
>>> which after not finding a panel goes on to call of_drm_find_bridge(),
>>> and that crashes due to the earlier list corruption.
>>>
>>> This addresses the first issue by making sure that adv7511_probe()
>>> does not leave behind any corrupted list entries. This should
>>> get the system back to boot but needs testing. From my understanding,
>>> there is at least one more bug that needs to be resolved to actually
>>> get everything to work again.
>>
>> So I've started hitting the issue this patch tries to address (now
>> that the related code landed in Linus' tree). The only issue is that
>> with this fix, I don't see graphics initializing properly, so I
>> suspect something is still wrong with the error handling (though what
>> exactly I'm not sure).
>
> So this seems to only happen when CONFIG_DRM_I2C_ADV7511_CEC is
> enabled. If it is on, I don't get any graphics, but if its disabled
> graphics works.
>
> Tying this with Arnd's patch, I'm guessing adv7511_cec_init() is
> failing, but it seems like instead of just disabling the CEC feature,
> we're failing to load the driver entirely.
>
> Maybe should the logic be something like:
> #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> ret = adv7511_cec_init(dev, adv7511, offset);
> if (ret)
> #endif
> regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> ADV7511_CEC_CTRL_POWER_DOWN);
>
> ?

I just tested with this, and this approach seems to work for me.

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

Re: [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling

[John Stultz]

On Thu, Nov 16, 2017 at 1:50 PM, John Stultz  wrote:
> On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann  wrote:
>> An otherwise correct cleanup patch from Dan Carpenter turned a broken
>> failure handling from a feature patch by Hans Verkuil into a kernel
>> Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
>> for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
>> adv7511/33: add HDMI CEC support").
>>
>> I've managed to piece together several partial problems, though
>> I'm still struggling with the bigger picture:
>>
>> adv7511_probe() registers a drm_bridge structure that was allocated
>> with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
>> unknown reason, which in turn triggers the registered structure to be
>> removed.
>>
>> Elsewhere, kirin_drm_platform_probe() gets called, which calls
>> of_graph_get_remote_node(), and that returns NULL. Before Dan's
>> patch we would go on with a NULL pointer here and register that,
>> now kirin_drm_platform_probe() fails with -ENODEV.
>>
>> In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
>> which after not finding a panel goes on to call of_drm_find_bridge(),
>> and that crashes due to the earlier list corruption.
>>
>> This addresses the first issue by making sure that adv7511_probe()
>> does not leave behind any corrupted list entries. This should
>> get the system back to boot but needs testing. From my understanding,
>> there is at least one more bug that needs to be resolved to actually
>> get everything to work again.
>
> So I've started hitting the issue this patch tries to address (now
> that the related code landed in Linus' tree). The only issue is that
> with this fix, I don't see graphics initializing properly, so I
> suspect something is still wrong with the error handling (though what
> exactly I'm not sure).

So this seems to only happen when CONFIG_DRM_I2C_ADV7511_CEC is
enabled. If it is on, I don't get any graphics, but if its disabled
graphics works.

Tying this with Arnd's patch, I'm guessing adv7511_cec_init() is
failing, but it seems like instead of just disabling the CEC feature,
we're failing to load the driver entirely.

Maybe should the logic be something like:
#ifdef CONFIG_DRM_I2C_ADV7511_CEC
ret = adv7511_cec_init(dev, adv7511, offset);
if (ret)
#endif
regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
ADV7511_CEC_CTRL_POWER_DOWN);

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

Re: [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling

[John Stultz]

On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann  wrote:
> An otherwise correct cleanup patch from Dan Carpenter turned a broken
> failure handling from a feature patch by Hans Verkuil into a kernel
> Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
> for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
> adv7511/33: add HDMI CEC support").
>
> I've managed to piece together several partial problems, though
> I'm still struggling with the bigger picture:
>
> adv7511_probe() registers a drm_bridge structure that was allocated
> with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
> unknown reason, which in turn triggers the registered structure to be
> removed.
>
> Elsewhere, kirin_drm_platform_probe() gets called, which calls
> of_graph_get_remote_node(), and that returns NULL. Before Dan's
> patch we would go on with a NULL pointer here and register that,
> now kirin_drm_platform_probe() fails with -ENODEV.
>
> In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
> which after not finding a panel goes on to call of_drm_find_bridge(),
> and that crashes due to the earlier list corruption.
>
> This addresses the first issue by making sure that adv7511_probe()
> does not leave behind any corrupted list entries. This should
> get the system back to boot but needs testing. From my understanding,
> there is at least one more bug that needs to be resolved to actually
> get everything to work again.

So I've started hitting the issue this patch tries to address (now
that the related code landed in Linus' tree). The only issue is that
with this fix, I don't see graphics initializing properly, so I
suspect something is still wrong with the error handling (though what
exactly I'm not sure).

If you have a new version of the patch with Hans' feedback in it, I'd
be happy to re-test.

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

[Bug 102985] HDMI 2.0 4k EDIDs not available (Radeon RX Vega 56)

[bugzilla-daemon]

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

--- Comment #4 from invergo  ---
Sorry, I should have attached that in a file.

Just before those kernel errors were these:

Nov 16 21:23:21 jackalope gnome-shell[1020]: JS WARNING:
[resource:///org/gnome/shell/ui/modalDialog.js 218]: reference to undefined
property "GdkX11Screen"
Nov 16 21:23:21 jackalope gnome-shell[1020]: Failed to apply DRM plane
transform 0: Invalid argument
Nov 16 21:23:21 jackalope kernel: [drm] {3840x2160, 4400x2250@594000Khz}
Nov 16 21:23:28 jackalope kernel: [drm] {1920x1080, 2200x1125@148500Khz}
N

I'm not sure if the first two gnome-shell errors are relevant.
The latter two kernel messages I guess reflect the attempt to change
resolutions to 3840x2160, but then is it trying to revert back to 1920x1080
albeit at 15Khz?

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

Re: [PATCH] drm/amd/display: remove unnecessary cast and use kcalloc instead of kzalloc

[Alex Deucher]

On Wed, Nov 15, 2017 at 10:45 AM, Colin King  wrote:
> From: Colin Ian King 
>
> Use kcalloc instead of kzalloc and the cast on the return from kzalloc is
> unnecessary and can be removed.
>
> Signed-off-by: Colin Ian King 

Reviewed and pushed.

Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/basics/logger.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/basics/logger.c 
> b/drivers/gpu/drm/amd/display/dc/basics/logger.c
> index e04e8ecd4874..2ff5b467603d 100644
> --- a/drivers/gpu/drm/amd/display/dc/basics/logger.c
> +++ b/drivers/gpu/drm/amd/display/dc/basics/logger.c
> @@ -70,9 +70,8 @@ static bool construct(struct dc_context *ctx, struct 
> dal_logger *logger,
>  {
> /* malloc buffer and init offsets */
> logger->log_buffer_size = DAL_LOGGER_BUFFER_MAX_SIZE;
> -   logger->log_buffer = (char *)kzalloc(logger->log_buffer_size * 
> sizeof(char),
> -GFP_KERNEL);
> -
> +   logger->log_buffer = kcalloc(logger->log_buffer_size, sizeof(char),
> +GFP_KERNEL);
> if (!logger->log_buffer)
> return false;
>
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Jan Vesely]

Signed-off-by: Jan Vesely 
---
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
index f1d48281e322..b3bee39661ab 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue_vi.c
@@ -37,15 +37,16 @@ static bool initialize_vi(struct kernel_queue *kq, struct 
kfd_dev *dev,
enum kfd_queue_type type, unsigned int queue_size)
 {
int retval;
+   unsigned int size = ALIGN(queue_size, PAGE_SIZE);
 
-   retval = kfd_gtt_sa_allocate(dev, PAGE_SIZE, >eop_mem);
+   retval = kfd_gtt_sa_allocate(dev, size, >eop_mem);
if (retval != 0)
return false;
 
kq->eop_gpu_addr = kq->eop_mem->gpu_addr;
kq->eop_kernel_addr = kq->eop_mem->cpu_ptr;
 
-   memset(kq->eop_kernel_addr, 0, PAGE_SIZE);
+   memset(kq->eop_kernel_addr, 0, size);
 
return true;
 }
-- 
2.13.6

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

[Bug 102985] HDMI 2.0 4k EDIDs not available (Radeon RX Vega 56)

[bugzilla-daemon]

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

--- Comment #3 from invergo  ---
I'm now on drm-next-amd-dc-staging commit 4479ed411cf4. I can see in my logs
that all of the modes in my TV's EDID are being detected.  GDM launches at
1920x1080 as usual, but when I try to log in, all video output is lost (TV
reports no input) and the computer freezes, requiring a hard reboot.  If I
first switch to a virtual console and restart GDM, I'm able to log into a
1920x1080 Gnome desktop. Under the Displays settings, all of my TV's supported
resolutions are listed.  However, when I switch to a 4k resolution, the system
crashes again and the video output is lost.

Checking my logs, I see the following errors:

Nov 16 21:23:28 jackalope kernel: [drm:atom_op_jump [amdgpu]] *ERROR* atombios
stuck in loop for more than 5secs aborting
Nov 16 21:23:28 jackalope kernel: [drm:amdgpu_atom_execute_table_locked
[amdgpu]] *ERROR* atombios stuck executing B544 (len 1373, WS 12, PS 8) @
0xB9FF
Nov 16 21:23:28 jackalope kernel: [ cut here ]
Nov 16 21:23:28 jackalope kernel: WARNING: CPU: 3 PID: 1020 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c:1262
dce110_prog_pixclk_crtc_otg+0x131/0x140 [amdgpu]
Nov 16 21:23:28 jackalope kernel: Modules linked in: fuse sd_mod joydev uas
mousedev input_leds hid_sony ff_memless usb_storage btusb btrtl btbcm amdkfd
amd_iommu_v2 amdgpu arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp
coretemp kvm_intel iTCO_wdt iTCO_vendor_support mxm_wmi evdev mac_hid kvm
irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
chash aes_x86_64 ttm crypto_simd glue_helper cryptd intel_cstate drm_kms_helper
intel_rapl_perf iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_hdmi
psmouse pcspkr snd_hda_codec_generic led_class drm syscopyarea sysfillrect
iwlwifi sysimgblt snd_hda_intel fb_sys_fops i2c_algo_bit snd_hda_codec
snd_hda_core snd_hwdep cfg80211 snd_pcm r8169 snd_timer snd mii hci_uart mei_me
btqca tpm_tis i2c_i801 soundcore btintel tpm_tis_core mei shpchp bluetooth
Nov 16 21:23:28 jackalope kernel:  thermal tpm ecdh_generic fan battery rfkill
wmi video intel_lpss_acpi i2c_hid intel_lpss acpi_als kfifo_buf acpi_pad
industrialio button sch_fq_codel sg crypto_user ip_tables x_tables ext4 crc16
mbcache jbd2 fscrypto hid_logitech_hidpp hid_logitech_dj usbhid hid serio_raw
atkbd libps2 crc32c_intel ahci libahci xhci_pci libata nvme xhci_hcd nvme_core
scsi_mod usbcore usb_common i8042 serio
Nov 16 21:23:28 jackalope kernel: CPU: 3 PID: 1020 Comm: gnome-shell Not
tainted 4.14.0-rc3-4479ed411cf4 #1
Nov 16 21:23:28 jackalope kernel: Hardware name: MSI MS-7A67/H270I GAMING PRO
AC (MS-7A67), BIOS 2.00 12/15/2016
Nov 16 21:23:28 jackalope kernel: task: 8802538f1e80 task.stack:
c90004c5c000
Nov 16 21:23:28 jackalope kernel: RIP:
0010:dce110_prog_pixclk_crtc_otg+0x131/0x140 [amdgpu]
Nov 16 21:23:28 jackalope kernel: RSP: 0018:c90004c5f860 EFLAGS: 00010246
Nov 16 21:23:28 jackalope kernel: RAX:  RBX: 8801edb24188
RCX: 
Nov 16 21:23:28 jackalope kernel: RDX: 8802538f1e80 RSI: 0001df80
RDI: 88025871e188
Nov 16 21:23:28 jackalope kernel: RBP: c90004c5f888 R08: 0001
R09: a08ec301
Nov 16 21:23:28 jackalope kernel: R10: c90004c5f680 R11: 81e9846d
R12: 8801edb0
Nov 16 21:23:28 jackalope kernel: R13: 880241a9e000 R14: 8801edb24000
R15: 8801edb0
Nov 16 21:23:28 jackalope kernel: FS:  7fa3cc812f00()
GS:88026ed8() knlGS:
Nov 16 21:23:28 jackalope kernel: CS:  0010 DS:  ES:  CR0:
80050033
Nov 16 21:23:28 jackalope kernel: CR2: 5609529fd140 CR3: 00024213e006
CR4: 003606e0
Nov 16 21:23:28 jackalope kernel: DR0:  DR1: 
DR2: 
Nov 16 21:23:28 jackalope kernel: DR3:  DR6: fffe0ff0
DR7: 0400
Nov 16 21:23:28 jackalope kernel: Call Trace:
Nov 16 21:23:28 jackalope kernel:  apply_single_controller_ctx_to_hw+0x49/0x330
[amdgpu]
Nov 16 21:23:28 jackalope kernel:  dce110_apply_ctx_to_hw+0x41b/0x750 [amdgpu]
Nov 16 21:23:28 jackalope kernel:  dc_commit_state+0x2a1/0x3c0 [amdgpu]
Nov 16 21:23:28 jackalope kernel:  amdgpu_dm_atomic_commit_tail+0x2cd/0xa50
[amdgpu]
Nov 16 21:23:28 jackalope kernel:  ? wait_for_common+0x14e/0x180
Nov 16 21:23:28 jackalope kernel:  ? wait_for_common+0x14e/0x180
Nov 16 21:23:28 jackalope kernel:  ? wait_for_completion_timeout+0x13/0x20
Nov 16 21:23:28 jackalope kernel:  commit_tail+0x3f/0x60 [drm_kms_helper]
Nov 16 21:23:28 jackalope kernel:  drm_atomic_helper_commit+0x106/0x110
[drm_kms_helper]
Nov 16 21:23:28 jackalope kernel:  amdgpu_dm_atomic_commit+0x87/0xa0 [amdgpu]
Nov 16 21:23:28 jackalope kernel:  drm_atomic_commit+0x4b/0x50 [drm]
Nov 16 21:23:28 jackalope kernel:  drm_atomic_helper_set_config+0x81/0x90
[drm_kms_helper]
Nov 16 21:23:28 jackalope 

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie  wrote:
>
> This sounds more like a Monty Python sketch than a serious question.

It's a serious question when the files start appearing in random
places where they don't belong.

There's a place for automatically generated files.

But that "there is a place" very much also implies that they shouldn't
be all over the tree.

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

Re: [git pull] drm for v4.15

[Dave Airlie]

On 16 November 2017 at 14:59, Linus Torvalds
 wrote:
> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>>
>> There is some code touched on sound/soc, but I think the sound tree
>> should have the same commits from the same base,so this may luck different
>> if you pulled it as I generated my pull request a couple of days ago. 
>> Otherwise
>> the highlights are below.
>
> I'm more curious about (and disgusted by) this one:
>
>   include/dt-bindings/msm/msm-bus-ids.h
>
> wtf? It's full of defines that aren't actually used anywhere.  Which
> is just as well, since it doesn't seem to be included from anything
> either.
>
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
>
> Is somebody getting paid by line of code?

It would still cost less than transcribing each register and all it's fields by
hand from pdfs generated from the same place.

This sounds more like a Monty Python sketch than a serious question. (In
my day we hard transcribed 1000s of register by hand before breakfast, and
then we ate the pdf printouts for breakfast).

The sheer size of those headers should be proof enough that they shouldn't
be handcrafted.

Next thing you'll be telling people to get off your lawn!

But this seems like Rob dropped the ball, he's no longer allowed run
git add without
passing every filename by hand, and I probably should have noticed
when I pulled it
but an 887 line register header file is quite small in a
+65,000,-56000 pull req.

Dave.
___
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

[Eric Anholt]

Andrzej Hajda  writes:

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

How can I decide when the panel driver has tried to probe and failed,
versus not tried to probe yet?  find_panel_or_bridge gives me
-EPROBE_DEFER either way.

> On the other side I am curious why EPROBE_DEFER from bind does not fail
> probing of some component (the last one probed), with proper error
> propagation it should cause defer_probing of one of the components or
> master, and probe/bind should be retried after panel's probe.

The panel probe failed, though, so there's no trigger to re-probe other
drivers.


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 00/22] drm/cma-helper: Remove drm_fbdev_cma* functions

[Noralf Trønnes]

Den 16.11.2017 09.14, skrev Shawn Guo:

On Wed, Nov 15, 2017 at 03:19:39PM +0100, Noralf Trønnes wrote:

This patchset adds drm_fb_cma_fbdev_init/fini() functions that replaces
drm_fbdev_cma_init/fini(). The reason for doing so is to get rid of
struct drm_fbdev_cma and it's wrapper functions. The final piece will
happen when tinydrm moves away from the cma helper and we can remove the
struct.

Note:
Patches 19-22 depends on patchset:
[v3] drm: Add simple modeset suspend/resume helpers

Is there a git branch somewhere we can test?



Here you go: https://github.com/notro/linux/tree/drm_fb_cma_fbdev_init

It includes the pending fsl-dcu suspend/resume patches and the patchset
mentioned above.

Noralf.

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

[Bug 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #6 from Rene Barbosa  ---
An interesting information: It's only with open source amdgpu driver. With
amdgpu-pro it's not happening but this driver isn't compatible with Ubuntu
17.10.

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

Applied "ASoC: AMD: Make the driver name consistent across files" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: Make the driver name consistent across files

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From a76d7f5454c688b52dc849e832cc4c6dd0975723 Mon Sep 17 00:00:00 2001
From: Akshu Agrawal 
Date: Fri, 3 Nov 2017 16:35:44 -0400
Subject: [PATCH] ASoC: AMD: Make the driver name consistent across files

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee00383..95c61ecdd1dd 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1170,7 +1172,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = _pm_ops,
},
 };
@@ -1181,4 +1183,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.14.1

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

[Bug 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #5 from Rene Barbosa  ---
Err. Sorry about that.
I've uploaded the correct file now.

-- 
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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

Rene Barbosa  changed:

   What|Removed |Added

 Attachment #135524|0   |1
is obsolete||

--- Comment #4 from Rene Barbosa  ---
Created attachment 135527
  --> https://bugs.freedesktop.org/attachment.cgi?id=135527=edit
dmesg

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

[Bug 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
(In reply to Rene Barbosa from comment #0)
> Created attachment 135524 [details]
> dmesg

Looks like you attached the wrong file.  Please attach your full dmesg output.

-- 
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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #135524|application/x-desktop   |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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #2 from Rene Barbosa  ---
Created attachment 135526
  --> https://bugs.freedesktop.org/attachment.cgi?id=135526=edit
modules

-- 
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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

--- Comment #1 from Rene Barbosa  ---
Created attachment 135525
  --> https://bugs.freedesktop.org/attachment.cgi?id=135525=edit
lspci

-- 
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 103783] atombios stuck in loop for more than 5secs

[bugzilla-daemon]

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

Bug ID: 103783
   Summary: atombios stuck in loop for more than 5secs
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: renebarbos...@gmail.com

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

Hello there,

I'm using Ubuntu 17.10 (fully updated) and my system is crashing at shutdown.
It's freezing until I force a reboot/shutdown using Magic SysRq.

The error is:

Nov 6 22:16:49 rene-Inspiron-5447 kernel: [ 248.294280] [drm:atom_op_jump
[amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
Nov 6 22:16:49 rene-Inspiron-5447 kernel: [ 248.294336]
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing 75A8 (len 272, WS 0, PS 4) @ 0x75F1
Nov 6 22:16:49 rene-Inspiron-5447 kernel: [ 248.294384]
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck
executing 640C (len 68, WS 0, PS 8) @ 0x6430]

This behavior is only happening when my laptop is charging. When running on
battery I got a clean shutdown/reboot.

Already tried to run the latest kernel package from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14 and the problem is exactly
the same.

ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: linux-image-4.13.0-16-generic 4.13.0-16.19 [modified:
boot/vmlinuz-4.13.0-16-generic]
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: rene 1249 F pulseaudio
 /dev/snd/controlC0: rene 1249 F pulseaudio
CurrentDesktop: GNOME
Date: Wed Nov 8 01:00:51 2017
EcryptfsInUse: Yes
HibernationDevice: RESUME=UUID=0f3b9237-1086-430d-be15-043b9ca00fd2
InstallationDate: Installed on 2017-11-06 (1 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
MachineType: Dell Inc. Inspiron 5447
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic.efi.signed
root=UUID=1237aa76-9a2f-4a06-8552-526f124914ff ro quiet splash
acpi_backlight=intel_backlight
RelatedPackageVersions:
 linux-restricted-modules-4.13.0-16-generic N/A
 linux-backports-modules-4.13.0-16-generic N/A
 linux-firmware 1.169
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/25/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A10
dmi.board.name: 0MHP6R
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A10
dmi.modalias:
dmi:bvnDellInc.:bvrA10:bd08/25/2016:svnDellInc.:pnInspiron5447:pvrA10:rvnDellInc.:rn0MHP6R:rvrA00:cvnDellInc.:ct8:cvrA10:
dmi.product.family: 00
dmi.product.name: Inspiron 5447
dmi.product.version: A10
dmi.sys.vendor: Dell Inc.

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

[radeon-alex:amd-staging-drm-next 1458/1474] drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c:73:6: error: passing argument 6 of 'amdgpu_bo_create_kernel' from incompatible pointer type

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   be1e8b7c9bbedf5963f9573bcd9cb9ba5046c50d
commit: 1cfd8e237f0318e330190ac21d63c58ae6a1f66c [1458/1474] drm/amdgpu:cleanup 
GMC & gart garbage function
config: i386-randconfig-s0-201746 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 1cfd8e237f0318e330190ac21d63c58ae6a1f66c
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c: In function 
'amdgpu_gart_table_vram_alloc':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c:73:6: error: passing argument 6 of 
>> 'amdgpu_bo_create_kernel' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 >gart.table_addr, >gart.ptr);
 ^
   In file included from drivers/gpu//drm/amd/amdgpu/amdgpu.h:1946:0,
from drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c:33:
   drivers/gpu//drm/amd/amdgpu/amdgpu_object.h:215:5: note: expected 'u64 * 
{aka long long unsigned int *}' but argument is of type 'dma_addr_t * {aka 
unsigned int *}'
int amdgpu_bo_create_kernel(struct amdgpu_device *adev,
^~~
   drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c: In function 
'amdgpu_gart_table_vram_free':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c:88:5: error: passing argument 2 of 
>> 'amdgpu_bo_free_kernel' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
>gart.table_addr,
^
   In file included from drivers/gpu//drm/amd/amdgpu/amdgpu.h:1946:0,
from drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c:33:
   drivers/gpu//drm/amd/amdgpu/amdgpu_object.h:219:6: note: expected 'u64 * 
{aka long long unsigned int *}' but argument is of type 'dma_addr_t * {aka 
unsigned int *}'
void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr,
 ^
   cc1: some warnings being treated as errors

vim +/amdgpu_bo_create_kernel +73 drivers/gpu//drm/amd/amdgpu/amdgpu_gart.c

34  
35  /*
36   * GART
37   * The GART (Graphics Aperture Remapping Table) is an aperture
38   * in the GPU's address space.  System pages can be mapped into
39   * the aperture and look like contiguous pages from the GPU's
40   * perspective.  A page table maps the pages in the aperture
41   * to the actual backing pages in system memory.
42   *
43   * Radeon GPUs support both an internal GART, as described above,
44   * and AGP.  AGP works similarly, but the GART table is configured
45   * and maintained by the northbridge rather than the driver.
46   * Radeon hw has a separate AGP aperture that is programmed to
47   * point to the AGP aperture provided by the northbridge and the
48   * requests are passed through to the northbridge aperture.
49   * Both AGP and internal GART can be used at the same time, however
50   * that is not currently supported by the driver.
51   *
52   * This file handles the common internal GART management.
53   */
54  
55  /*
56   * Common GART table functions.
57   */
58  
59  /**
60   * amdgpu_gart_table_vram_alloc - allocate vram for gart page table
61   *
62   * @adev: amdgpu_device pointer
63   *
64   * Allocate video memory for GART page table
65   * (pcie r4xx, r5xx+).  These asics require the
66   * gart table to be in video memory.
67   * Returns 0 for success, error for failure.
68   */
69  int amdgpu_gart_table_vram_alloc(struct amdgpu_device *adev)
70  {
71  return amdgpu_bo_create_kernel(adev, adev->gart.table_size, 
PAGE_SIZE,
72  AMDGPU_GEM_DOMAIN_VRAM, 
>gart.robj,
  > 73  >gart.table_addr, 
>gart.ptr);
74  }
75  
76  /**
77   * amdgpu_gart_table_vram_free - free gart page table vram
78   *
79   * @adev: amdgpu_device pointer
80   *
81   * Free the video memory used for the GART page table
82   * (pcie r4xx, r5xx+).  These asics require the gart table to
83   * be in video memory.
84   */
85  void amdgpu_gart_table_vram_free(struct amdgpu_device *adev)
86  {
87  amdgpu_bo_free_kernel(>gart.robj,
  > 88  >gart.table_addr,
89  >gart.ptr);
90  }
91  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


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

Re: [git pull] drm for v4.15

[Michel Dänzer]

On 16/11/17 05:59 AM, Linus Torvalds wrote:
> 
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
> 
> Is somebody getting paid by line of code?

At least in the case of amdgpu, it's more like nobody's getting paid to
write/maintain register header files by hand full-time. I hope you can
agree nobody should have to do that.

The headers are generated from the same database used for other OSes,
which minimizes the potential for error. We used hand-written headers in
the radeon driver, and there was a fair number of bugs due to subtle
errors in them.


-- 
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 0/4] treewide: Fix line continuation formats

[Joe Perches]

On Thu, 2017-11-16 at 12:11 -0500, Mimi Zohar wrote:
> On Thu, 2017-11-16 at 07:27 -0800, Joe Perches wrote:
> > Avoid using line continations in formats as that causes unexpected
> > output.
> 
> Is having lines greater than 80 characters the preferred method?

yes.

>  Could you add quotes before the backlash and before the first word on
> the next line instead?

coalesced formats are preferred.

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

Re: [PATCH v2 2/2] drm: rcar-du: Clip planes to screen boundaries

[Ville Syrjälä]

On Mon, Nov 13, 2017 at 10:47:00AM +0200, Laurent Pinchart wrote:
> Unlike the KMS API, the hardware doesn't support planes exceeding the
> screen boundaries or planes being located fully off-screen. We need to
> clip plane coordinates to support the use case.
> 
> Fortunately the DRM core offers the drm_plane_helper_check_state()
> helper that valides the scaling factor and clips the plane coordinates.
> Use it to implement the plane atomic check and use the clipped source
> and destination rectangles from the plane state instead of the unclipped
> source and CRTC coordinates to configure the device.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 37 
> ++---
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 10 ++---
>  3 files changed, 39 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index b492063a6e1f..5685d5af6998 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -319,7 +319,8 @@ static void rcar_du_crtc_update_planes(struct 
> rcar_du_crtc *rcrtc)
>   struct rcar_du_plane *plane = >group->planes[i];
>   unsigned int j;
>  
> - if (plane->plane.state->crtc != >crtc)
> + if (plane->plane.state->crtc != >crtc ||
> + !plane->plane.state->visible)
>   continue;
>  
>   /* Insert the plane in the sorted planes array. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 4f076c364f25..9cf02b44902d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -570,16 +570,39 @@ int __rcar_du_plane_atomic_check(struct drm_plane 
> *plane,
>const struct rcar_du_format_info **format)
>  {
>   struct drm_device *dev = plane->dev;
> + struct drm_crtc_state *crtc_state;
> + struct drm_rect clip;
> + int ret;
>  
> - if (!state->fb || !state->crtc) {
> + if (!state->crtc) {
> + /*
> +  * The visible field is not reset by the DRM core but only
> +  * updated by drm_plane_helper_check_state(), set it manually.
> +  */
> + state->visible = false;
>   *format = NULL;
>   return 0;
> - }
> + };

spurious ;

>  
> - if (state->src_w >> 16 != state->crtc_w ||
> - state->src_h >> 16 != state->crtc_h) {
> - dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
> - return -EINVAL;
> + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + clip.x1 = 0;
> + clip.y1 = 0;
> + clip.x2 = crtc_state->adjusted_mode.hdisplay;
> + clip.y2 = crtc_state->adjusted_mode.vdisplay;

crtc_state->mode would be more correct. I messed that up too in my
recent vmwgfx fix [1]. But this should probably work just as well
if you don't have a crtc scaler in your pipeline.

Also you may want to leave the clip empty when !crtc_state->enable.
That way you'll be guaranteed to get visible==false. The helper is
currently a bit broken wrt. the crtc->enable vs. crtc_state->enable.
I've fixed that in [1] as well but those patches haven't been pushed
yet.

After getting that stuff in, I'm going to attempt moving this
clipping stuff entirely into the helper to avoid these kinds of
mistakes in the future.

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

> +
> + ret = drm_plane_helper_check_state(state, ,
> +DRM_PLANE_HELPER_NO_SCALING,
> +DRM_PLANE_HELPER_NO_SCALING,
> +true, true);
> + if (ret < 0)
> + return ret;
> +
> + if (!state->visible) {
> + *format = NULL;
> + return 0;
>   }
>  
>   *format = rcar_du_format_info(state->fb->format->format);
> @@ -607,7 +630,7 @@ static void rcar_du_plane_atomic_update(struct drm_plane 
> *plane,
>   struct rcar_du_plane_state *old_rstate;
>   struct rcar_du_plane_state *new_rstate;
>  
> - if (!plane->state->crtc)
> + if (!plane->state->visible)
>   return;
>  
>   rcar_du_plane_setup(rplane);
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index dd66dcb8da23..6d1a82ee50ed 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -212,7 +212,11 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane 
> *plane,
>   unsigned int i;
>   int ret;
>  
> - if (!state->fb)
> + /*
> +  * There's no need 

Re: [PATCH v2 02/10] drm/uapi: Validate the mode flags/type

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 06:02:59PM +, Jose Abreu wrote:
> Hi Ville,
> 
> On 15-11-2017 15:49, Ville Syrjala wrote:
> >  
> > +#define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
> > +DRM_MODE_FLAG_NHSYNC | \
> > +DRM_MODE_FLAG_PVSYNC | \
> > +DRM_MODE_FLAG_NVSYNC | \
> > +DRM_MODE_FLAG_INTERLACE |  \
> > +DRM_MODE_FLAG_DBLSCAN |\
> > +DRM_MODE_FLAG_CSYNC |  \
> > +DRM_MODE_FLAG_PCSYNC | \
> > +DRM_MODE_FLAG_NCSYNC | \
> > +DRM_MODE_FLAG_HSKEW |  \
> > +DRM_MODE_FLAG_BCAST |  \
> > +DRM_MODE_FLAG_PIXMUX | \
> > +DRM_MODE_FLAG_DBLCLK | \
> > +DRM_MODE_FLAG_CLKDIV2 |\
> > +DRM_MODE_FLAG_3D_MASK)
> > +
> >  
> 
> I see this doesn't include the picture aspect ratio flags.
> Shouldn't we add this now so that userspace can start using them?

Not until we have the client cap to keep them hidden from userspace that
isn't prepared to see them.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH AUTOSEL for 4.9 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV

[Ville Syrjälä]

On Wed, Nov 15, 2017 at 04:44:54PM +, alexander.le...@verizon.com wrote:
> On Wed, Nov 15, 2017 at 01:08:05PM +0200, Ville Syrjälä wrote:
> >On Wed, Nov 15, 2017 at 02:45:43AM +, alexander.le...@verizon.com wrote:
> >> From: Ville Syrjälä 
> >>
> >> [ Upstream commit 1be4d3793d5a93daddcd9be657c429b38ad750a3 ]
> >>
> >> The watermark should never exceed the FIFO size, so we need to
> >> check against the current FIFO size instead of the theoretical
> >> maximum when we clamp the level 0 watermark.
> >>
> >> Signed-off-by: Ville Syrjälä 
> >> Link: 
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.freedesktop.org_patch_msgid_1480354637-2D14209-2D4-2Dgit-2Dsend-2Demail-2Dville.syrjala-40linux.intel.com=DwIDAw=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=bUtaaC9mlBij4OjEG_D-KPul_335azYzfC4Rjgomobo=iuPtUar-VEGbH1jmVH_UTr4C02X8fmjHUfNYix-Yc0Y=ha_F0zP3A1Aztp5S5e6_bqdhiuuPXhn0dRWQ58vv3Is=
> >> Reviewed-by: Maarten Lankhorst 
> >> Signed-off-by: Sasha Levin 
> >
> >Why are these patches being proposed for stable? They're not straight up
> >fixes for known issues, and there's always a chance that something will
> >break. Who is doing the qa on this?
> 
> Hi Ville,
> 
> They were selected automatically as part of a new process we're trying
> out. If you disagree with the selection I'd be happy to drop it.

How does that automatic process decide that a patch should be backported?

drm and i915 are very fast moving targets so unintended side effects from
backported patches is a real possibility. So I would recommend against
backporting anything that isn't fixing a real issue affecting users. We
do try to add the cc:stable to such patches.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:10:55PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
> > 3D to 2D mode in a timely fashion if the source simply stops sending the
> > HDMI infoframe. The suggested workaround is to keep sending the
> > infoframe even when strictly not necessary (ie. no VIC and no S3D).
> > HDMI 1.4 does allow for this behaviour, stating that sending the
> > infoframe is optional in this case.
> >
> > The infoframe was first specified in HDMI 1.4, so in theory sinks
> > predating that may not appreciate us sending an uknown infoframe
> > their way. To avoid regressions let's try to determine if the sink
> > supports the infoframe or not. Unfortunately there's no direct way
> > to do that, so instead we'll just check if we managed to parse any
> > HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
> > sink will accept the infoframe. Also if the EDID contains the HDMI
> > 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
> > the infoframe.
> I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which 
> talks about
> switch from 3D to 2D.  To me it looks like:
> If (sending_to_hdmi2_sinks) {
>  - for 3d modes send HF-VSIF
>  - for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
>When you switch from 3d->2d {
>   - send_HF-VSIF with 3D_valid bit = 0/1
>   }
> } else { /* HDMI 1.4b sinks from Appendix F */
>  -  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
> }
> 
> Should we add a is_hdmi2 check and separate these cases ?

We don't support the HDMI forum infoframe. Maybe someone forgot to
implement that when adding the rest of HDMI 2.0 support? ;)

> 
> >
> > v2: Fix the getting has_hdmi_infoframe from display_info
> >  Always fail constructing the infoframe if the display
> >  possibly can't handle it
> >
> > Cc: Shashank Sharma 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
> >   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
> >   drivers/gpu/drm/drm_edid.c| 34 
> > +--
> >   drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
> >   drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
> >   drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
> >   drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
> >   drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
> >   drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
> >   drivers/gpu/drm/zte/zx_hdmi.c |  1 +
> >   include/drm/drm_connector.h   |  5 +
> >   include/drm/drm_edid.h|  1 +
> >   12 files changed, 57 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
> > b/drivers/gpu/drm/bridge/sil-sii8620.c
> > index b7eb704d0a8a..4417276ba02e 100644
> > --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> > +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> > @@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge 
> > *bridge,
> > union hdmi_infoframe frm;
> > u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
> >   
> > +   /* FIXME: We need the connector here */
> > drm_hdmi_vendor_infoframe_from_display_mode(
> > -   , adjusted_mode);
> > +   , NULL, adjusted_mode);
> > vic = frm.vendor.hdmi.vic;
> > if (vic >= ARRAY_SIZE(mhl_vic))
> > vic = 0;
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index a64ce7112288..b172139502d6 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1437,7 +1437,9 @@ static void 
> > hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi,
> > u8 buffer[10];
> > ssize_t err;
> >   
> > -   err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);
> > +   err = drm_hdmi_vendor_infoframe_from_display_mode(,
> > + >connector,
> > + mode);
> > if (err < 0)
> > /*
> >  * Going into that statement does not means vendor infoframe
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 749d07a01772..9ada0ccf50df 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3393,6 +3393,7 @@ static int
> >   do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
> >

Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:31:36PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > If the user mode would specify an aspect ratio other than 4:3 or 16:9
> > we now silently ignore it. Maybe a better apporoach is to return an
> > error? Let's try that.
> >
> > Also we must be careful that we don't try to send illegal picture
> > aspect in the infoframe as it's only capable of signalling none,
> > 4:3, and 16:9. Currently we're sending these bogus infoframes
> > whenever the cea mode specifies some other aspect ratio.
> >
> > Cc: Shashank Sharma 
> > Cc: Sean Paul 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_edid.c | 23 +--
> >   1 file changed, 17 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 00aa98f3e55d..bafb3ee4ea97 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> >  const struct drm_display_mode *mode,
> >  bool is_hdmi2_sink)
> >   {
> > +   enum hdmi_picture_aspect picture_aspect;
> > int err;
> >   
> > if (!frame || !mode)
> > @@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> > hdmi_avi_infoframe *frame,
> >  * Populate picture aspect ratio from either
> >  * user input (if specified) or from the CEA mode list.
> >  */
> > -   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
> > -   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
> > -   frame->picture_aspect = mode->picture_aspect_ratio;
> > -   else if (frame->video_code > 0)
> > -   frame->picture_aspect = drm_get_cea_aspect_ratio(
> > -   frame->video_code);
> > +   picture_aspect = mode->picture_aspect_ratio;
> > +   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
> > +   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
> This is slightly going in the loop.
> - During the modeset the driver cant specify the aspect ratio 
> information, as DRM layer lacks this support.
> - So we fill the VIC field, by comparing the mode with the 
> DRM_CEA_MODES[] list. This will pick the first mode
>available in the list (regardless of its aspect ratio), and fill the 
> VIC, as we don't consider aspect ratio while comparing timings.
> - Again, now while sending the aspect ratio, we are picking up the VIC, 
> which may not be correct.
> 
> So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is 
> first in list, we will always pick 4:3 aspect ratio.

Yes. The user didn't care about the aspect ratio (or rather couldn't
specify one) so we just pick one. Which is exactly what we've been
doing ever since we started sending the VIC in the infoframe.

> 
> - Shashank
> >   
> > +   /*
> > +* The infoframe can't convey anything but none, 4:3
> > +* and 16:9, so if the user has asked for anything else
> > +* we can only satisfy it by specifying the right VIC.
> > +*/
> > +   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
> > +   if (picture_aspect !=
> > +   drm_get_cea_aspect_ratio(frame->video_code))
> > +   return -EINVAL;
> > +   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
> > +   }
> > +
> > +   frame->picture_aspect = picture_aspect;
> > frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
> > frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
> >   

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:21:44PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
> > cause us to not send out any VICs in the AVI infoframes. That commit
> > was since reverted, but if and when we add aspect ratio handing back
> > we need to be more careful.
> >
> > Let's handle this by considering the aspect ratio as a requirement
> > for cea mode matching only if the passed in mode actually has a
> > non-zero aspect ratio field. This will keep userspace that doesn't
> > provide an aspect ratio working as before by matching it to the
> > first otherwise equal cea mode. And once userspace starts to
> > provide the aspect ratio it will be considerd a hard requirement
> > for the match.
> >
> > Also change the hdmi mode matching to use drm_mode_match() for
> > consistency, but we don't match on aspect ratio there since the
> > spec doesn't list a specific aspect ratio for those modes.
> >
> > Cc: Shashank Sharma 
> > Cc: "Lin, Jia" 
> > Cc: Akashdeep Sharma 
> > Cc: Jim Bride 
> > Cc: Jose Abreu 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_edid.c | 18 ++
> >   1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 7220b8f9a7e8..00aa98f3e55d 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
> > drm_display_mode *mode)
> >   static u8 drm_match_cea_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >  unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> This doesn't look right. This means we are expecting a CEA mode without 
> a pic aspect ratio field,
> which is invalid.

No, it's perfectly valid. It's what we currently get from userspace.

> Ankit is going to publish the aspect ratio patch 
> series again, with proper DRM cap and flags check. Would it be
> ok if we have a look that handling first ?

This patch will be needed by that work. Otherwise we're going to stop
sending a VIC for CEA modes with current userspace.

> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
> > struct drm_display_mode *to_m
> >*/
> >   u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > DRM_MODE_MATCH_FLAGS;
> > u8 vic;
> >   
> > if (!to_match->clock)
> > return 0;
> >   
> > +   if (to_match->picture_aspect_ratio)
> > +   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> same here, and probably in other CEA match functions.
> > +
> > for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
> > struct drm_display_mode cea_mode = edid_cea_modes[vic];
> > unsigned int clock1, clock2;
> > @@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> > *to_match)
> > continue;
> >   
> > do {
> > -   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
> > _mode))
> > +   if (drm_mode_match(to_match, _mode, match_flags))
> > return vic;
> > } while (cea_mode_alternate_timings(vic, _mode));
> > }
> > @@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct 
> > drm_display_mode *hdmi_mode)
> >   static u8 drm_match_hdmi_mode_clock_tolerance(const struct 
> > drm_display_mode *to_match,
> >   unsigned int clock_tolerance)
> >   {
> > +   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
> > 

Re: [PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 08:06:18PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/13/2017 10:34 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
> > when switching from 3D to 2D mode, even if the infoframe isn't strictly
> > necessary (ie. not needed to transmit the VIC or stereo information).
> > This is a workaround against some sinks that fail to realize that they
> > should switch from 3D to 2D mode when the source stop transmitting
> > the infoframe.
> >
> > v2: Handle unpack() as well
> >  Pull the length calculation into a helper
> >
> > Cc: Shashank Sharma 
> > Cc: Andrzej Hajda 
> > Cc: Thierry Reding 
> > Cc: Hans Verkuil 
> > Cc: linux-me...@vger.kernel.org
> > Reviewed-by: Andrzej Hajda  #v1
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/video/hdmi.c | 51 
> > +++
> >   1 file changed, 31 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> > index 1cf907ecded4..111a0ab6280a 100644
> > --- a/drivers/video/hdmi.c
> > +++ b/drivers/video/hdmi.c
> > @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
> > hdmi_vendor_infoframe *frame)
> >   }
> >   EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
> >   
> > +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe 
> > *frame)
> > +{
> > +   /* for side by side (half) we also need to provide 3D_Ext_Data */
> > +   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > +   return 6;
> > +   else if (frame->vic != 0 || frame->s3d_struct != 
> > HDMI_3D_STRUCTURE_INVALID)
> > +   return 5;
> > +   else
> > +   return 4;
> > +}
> > +
> >   /**
> >* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
> > buffer
> >* @frame: HDMI infoframe
> > @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
> > hdmi_vendor_infoframe *frame,
> > u8 *ptr = buffer;
> > size_t length;
> >   
> > -   /* empty info frame */
> > -   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> > -   return -EINVAL;
> > -
> > /* only one of those can be supplied */
> > if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> > return -EINVAL;
> >   
> > -   /* for side by side (half) we also need to provide 3D_Ext_Data */
> > -   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > -   frame->length = 6;
> > -   else
> > -   frame->length = 5;
> > +   frame->length = hdmi_vendor_infoframe_length(frame);
> >   
> > length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> >   
> > @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
> > hdmi_vendor_infoframe *frame,
> > ptr[5] = 0x0c;
> > ptr[6] = 0x00;
> >   
> > -   if (frame->vic) {
> > -   ptr[7] = 0x1 << 5;  /* video format */
> > -   ptr[8] = frame->vic;
> > -   } else {
> > +   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
> > ptr[7] = 0x2 << 5;  /* video format */
> > ptr[8] = (frame->s3d_struct & 0xf) << 4;
> > if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
> > ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
> > +   } else if (frame->vic) {
> Please correct me if I dint understand this properly, but for a HDMI 2.0 
> sink + 3D transmission, wouldn't I be sending
> HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

That vic will be in the AVI infoframe. Here we're concerned about the
VIC in the HDMI vendor infoframe.

> 
> - Shashank
> > +   ptr[7] = 0x1 << 5;  /* video format */
> > +   ptr[8] = frame->vic;
> > +   } else {
> > +   ptr[7] = 0x0 << 5;  /* video format */
> > }
> >   
> > hdmi_infoframe_set_checksum(buffer, length);
> > @@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
> > hdmi_vendor_any_infoframe *frame,
> >   
> > if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||
> > ptr[1] != 1 ||
> > -   (ptr[2] != 5 && ptr[2] != 6))
> > +   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
> > return -EINVAL;
> >   
> > length = ptr[2];
> > @@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
> > hdmi_vendor_any_infoframe *frame,
> >   
> > hvf->length = length;
> >   
> > -   if (hdmi_video_format == 0x1) {
> > -   hvf->vic = ptr[4];
> > -   } else if (hdmi_video_format == 0x2) {
> > +   if (hdmi_video_format == 0x2) {
> > +   if (length != 5 && length != 6)
> > +   return -EINVAL;
> > hvf->s3d_struct = ptr[4] >> 4;
> > if (hvf->s3d_struct >= 

Re: [PATCH] drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug

[Ville Syrjälä]

On Thu, Nov 16, 2017 at 03:19:35PM +0100, Benjamin Gaignard wrote:
> 2017-10-30 10:19 GMT+01:00 Daniel Vetter :
> > On Tue, Oct 24, 2017 at 11:01:32AM +0200, Benjamin Gaignard wrote:
> >> 2017-10-23 17:25 GMT+02:00 Ville Syrjala :
> >> > From: Ville Syrjälä 
> >> >
> >> > Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
> >> > even drivers that don't implement accurate vblank timestamps will end
> >> > up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
> >> > time drm_crtc_arm_vblank_event() gets called. The could be as often
> >> > as every frame for each active crtc.
> >> >
> >> > Considering drm_crtc_accurate_vblank_count() is never any worse than
> >> > the drm_vblank_count() we used previously, let's just skip the WARN
> >> > unless DRM_UT_VBL is enabled. That way people won't be bothered by
> >> > this unless they're debugging vblank code. And let's also change it
> >> > to WARN_ONCE() so that even when you're debugging vblank code you
> >> > won't get drowned by constant WARNs.
> >> >
> >> > Cc: sta...@vger.kernel.org
> >> > Cc: Daniel Vetter 
> >> > Cc: "Szyprowski, Marek" 
> >> > Cc: Andrzej Hajda 
> >> > Reported-by: Andrzej Hajda 
> >> > Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
> >> > Signed-off-by: Ville Syrjälä 
> >>
> >> I have tested it on sti and stm driver, it fix the problem, thanks.
> >>
> >> Acked-by: Benjamin Gaignard 
> >>
> >> > ---
> >> >  drivers/gpu/drm/drm_vblank.c | 4 ++--
> >> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> >> > index 13722c373a6a..c81c297995c6 100644
> >> > --- a/drivers/gpu/drm/drm_vblank.c
> >> > +++ b/drivers/gpu/drm/drm_vblank.c
> >> > @@ -299,8 +299,8 @@ u32 drm_crtc_accurate_vblank_count(struct drm_crtc 
> >> > *crtc)
> >> > u32 vblank;
> >> > unsigned long flags;
> >> >
> >> > -   WARN(!dev->driver->get_vblank_timestamp,
> >> > -"This function requires support for accurate vblank 
> >> > timestamps.");
> >> > +   WARN_ONCE(drm_debug & DRM_UT_VBL && 
> >> > !dev->driver->get_vblank_timestamp,
> >> > + "This function requires support for accurate vblank 
> >> > timestamps.");
> >
> > Somewhat a bikeshed, but if we e.g. enable debugging in a CI or piglit
> > run, then this could change the results. I'd go with a if ()
> > DRM_DEBUG_VBLANK. Either way:
> >
> > Reviewed-by: Daniel Vetter 
> >
> 
> Does something is missing to merge this fix in drm-misc ?
> Without it I got warning at each frame.

Pushed... 9 days ago it seems.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: remove file that was added accidentally

[Rob Herring]

On Thu, Nov 16, 2017 at 8:05 AM, Rob Clark  wrote:
> I think this snuck in when I applied the patch for f97decac5f4c (didn't
> apply cleanly, required some manual applying + git-add).  It is unused
> and shouldn't be here.  My bad.
>
> Fixes: f97decac5f4c "drm/msm: Support multiple ringbuffers"
> Signed-off-by: Rob Clark 
> ---
>  include/dt-bindings/msm/msm-bus-ids.h | 887 
> --
>  1 file changed, 887 deletions(-)
>  delete mode 100644 include/dt-bindings/msm/msm-bus-ids.h

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

Re: [PATCH 2/4] drm: amd: Fix line continuation formats

[Joe Perches]

On Thu, 2017-11-16 at 10:38 -0500, Harry Wentland wrote:
> On 2017-11-16 10:27 AM, Joe Perches wrote:
> > Line continuations with excess spacing causes unexpected output.
[]
> > @@ -872,9 +870,8 @@ static bool perform_clock_recovery_sequence(
> > if (retry_count >= LINK_TRAINING_MAX_CR_RETRY) {
> > ASSERT(0);
> > dm_logger_write(link->ctx->logger, LOG_ERROR,
> > -   "%s: Link Training Error, could not \
> > -get CR after %d tries. \
> > -   Possibly voltage swing issue", __func__,
> > +   "%s: Link Training Error, could not get CR after %d 
> > tries. Possibly voltage swing issue",
> 
> Would probably be good to add a '\n' here as well but that's not the main 
> intention of this patch.

About 1/4 of the dm_logger_write calls are missing
newlines and I think it should be a separate patch.

I encourage you to fix them one day.

> Reviewed-by: Harry Wentland 

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

Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

[Emil Velikov]

On 15 November 2017 at 21:25, Sharma, Deepak  wrote:

>>
>> I'd still recommend updating the two functions' documentation, ideally 
>> coupled with enforcing for *parent to be non NULL.
>> Could be code as follow-up though.
>>
> If I got it correctly you are referring   "Note that for purely virtual 
> devices @parent can be NULL" for said two functions.
> I think changes might be required if it was "should/must be NULL"?


Since you're changing the behaviour:
The statement "Note that for purely virtual devices @parent can be
NULL" is never true and should be dropped.

Additionally, you want to update the functions to error out when
parent is NULL since it indicates a driver bug.
For the drm_dev_set_unique hunk one can drop the comment (it's NA) and
simplify to:

ret = drm_dev_set_unique(dev, dev_name(parent));

As mentioned before - it can be code as follow-up.


>>
>> Most of which use i915 <> vgem. If you don't have the HW to test, one can 
>> use the Intel GFX trybot.
>> Just keep [1] in the To/CC list and you'll get a report with the results.
>>
>
> Thanks. I have added Intel GFX trybot in CC, that should be sufficient or I 
> need to send patch again using git send-mail?
>
Right, should have been clearer - the actual patches should be send/cc'd.
Otherwise one has know way of retrieving (and thus testing) the patch ;-)

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

Re: [PATCH 2/4] drm: amd: Fix line continuation formats

[Harry Wentland]

On 2017-11-16 10:27 AM, Joe Perches wrote:
> Line continuations with excess spacing causes unexpected output.
> 
> Miscellanea:
> 
> o Added missing '\n' to a few of the coalesced pr_ formats
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 -
>  .../amd/powerplay/hwmgr/process_pptables_v1_0.c|  6 ++---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 27 
> --
>  drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |  6 ++---
>  .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  |  9 +++-
>  .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   |  6 ++---
>  6 files changed, 22 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index ced42484dcfc..6743786afcce 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -220,8 +220,7 @@ static void dpcd_set_lt_pattern_and_lane_settings(
>   size_in_bytes);
>  
>   dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
> - "%s:\n %x VS set = %x  PE set = %x \
> - max VS Reached = %x  max PE Reached = %x\n",
> + "%s:\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
> Reached = %x\n",
>   __func__,
>   DP_TRAINING_LANE0_SET,
>   dpcd_lane[0].bits.VOLTAGE_SWING_SET,
> @@ -558,8 +557,7 @@ static void dpcd_set_lane_settings(
>   */
>  
>   dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
> - "%s\n %x VS set = %x  PE set = %x \
> - max VS Reached = %x  max PE Reached = %x\n",
> + "%s\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
> Reached = %x\n",
>   __func__,
>   DP_TRAINING_LANE0_SET,
>   dpcd_lane[0].bits.VOLTAGE_SWING_SET,
> @@ -872,9 +870,8 @@ static bool perform_clock_recovery_sequence(
>   if (retry_count >= LINK_TRAINING_MAX_CR_RETRY) {
>   ASSERT(0);
>   dm_logger_write(link->ctx->logger, LOG_ERROR,
> - "%s: Link Training Error, could not \
> -  get CR after %d tries. \
> - Possibly voltage swing issue", __func__,
> + "%s: Link Training Error, could not get CR after %d 
> tries. Possibly voltage swing issue",

Would probably be good to add a '\n' here as well but that's not the main 
intention of this patch.

Either way patch is
Reviewed-by: Harry Wentland 

Harry

> + __func__,
>   LINK_TRAINING_MAX_CR_RETRY);
>  
>   }
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> index d1af1483c69b..813f827e4270 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> @@ -523,8 +523,7 @@ static int get_pcie_table(
>   if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
>   pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
>   else
> - pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! \
> - Disregarding the excess entries... \n");
> + pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! Disregarding the excess entries...\n");
>  
>   pcie_table->count = pcie_count;
>   for (i = 0; i < pcie_count; i++) {
> @@ -563,8 +562,7 @@ static int get_pcie_table(
>   if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
>   pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
>   else
> - pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! \
> - Disregarding the excess entries... \n");
> + pr_err("Number of Pcie Entries exceed the number of 
> SCLK Dpm Levels! Disregarding the excess entries...\n");
>  
>   pcie_table->count = pcie_count;
>  
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 4f79c21f27ed..9599fe0ba779 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -546,8 +546,7 @@ static void vega10_patch_with_vdd_leakage(struct pp_hwmgr 
> *hwmgr,
>   }
>  
>   if (*voltage > ATOM_VIRTUAL_VOLTAGE_ID0)
> - pr_info("Voltage value looks like a Leakage ID \
> - but it's not patched\n");
> + pr_info("Voltage value looks like a Leakage ID but it's not 
> patched\n");
>  }
>  
>  /**
> @@ -701,18 +700,14 @@ static int 
> 

[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related

[bugzilla-daemon]

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

--- Comment #8 from Andy Furniss  ---
It's not OK, I don't know what happened there, maybe I wasn't in the kernel I
thought, though I am not convinced.
Whatever the reason, I can't get it to work now.

-- 
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/4] treewide: Fix line continuation formats

[Joe Perches]

Avoid using line continations in formats as that causes unexpected
output.

Joe Perches (4):
  rk3399_dmc: Fix line continuation format
  drm: amd: Fix line continuation formats
  [media] dibx000_common: Fix line continuation format
  ima: Fix line continuation format

 drivers/devfreq/rk3399_dmc.c   |  4 ++--
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 -
 .../amd/powerplay/hwmgr/process_pptables_v1_0.c|  6 ++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 27 --
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |  6 ++---
 .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  |  9 +++-
 .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   |  6 ++---
 drivers/media/dvb-frontends/dibx000_common.c   |  8 +++
 security/integrity/ima/ima_template.c  | 11 -
 9 files changed, 33 insertions(+), 55 deletions(-)

-- 
2.15.0

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

[PATCH 2/4] drm: amd: Fix line continuation formats

[Joe Perches]

Line continuations with excess spacing causes unexpected output.

Miscellanea:

o Added missing '\n' to a few of the coalesced pr_ formats

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   | 11 -
 .../amd/powerplay/hwmgr/process_pptables_v1_0.c|  6 ++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 27 --
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c   |  6 ++---
 .../gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c  |  9 +++-
 .../gpu/drm/amd/powerplay/smumgr/vega10_smumgr.c   |  6 ++---
 6 files changed, 22 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index ced42484dcfc..6743786afcce 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -220,8 +220,7 @@ static void dpcd_set_lt_pattern_and_lane_settings(
size_in_bytes);
 
dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
-   "%s:\n %x VS set = %x  PE set = %x \
-   max VS Reached = %x  max PE Reached = %x\n",
+   "%s:\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
Reached = %x\n",
__func__,
DP_TRAINING_LANE0_SET,
dpcd_lane[0].bits.VOLTAGE_SWING_SET,
@@ -558,8 +557,7 @@ static void dpcd_set_lane_settings(
*/
 
dm_logger_write(link->ctx->logger, LOG_HW_LINK_TRAINING,
-   "%s\n %x VS set = %x  PE set = %x \
-   max VS Reached = %x  max PE Reached = %x\n",
+   "%s\n %x VS set = %x  PE set = %x max VS Reached = %x  max PE 
Reached = %x\n",
__func__,
DP_TRAINING_LANE0_SET,
dpcd_lane[0].bits.VOLTAGE_SWING_SET,
@@ -872,9 +870,8 @@ static bool perform_clock_recovery_sequence(
if (retry_count >= LINK_TRAINING_MAX_CR_RETRY) {
ASSERT(0);
dm_logger_write(link->ctx->logger, LOG_ERROR,
-   "%s: Link Training Error, could not \
-get CR after %d tries. \
-   Possibly voltage swing issue", __func__,
+   "%s: Link Training Error, could not get CR after %d 
tries. Possibly voltage swing issue",
+   __func__,
LINK_TRAINING_MAX_CR_RETRY);
 
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
index d1af1483c69b..813f827e4270 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
@@ -523,8 +523,7 @@ static int get_pcie_table(
if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
else
-   pr_err("Number of Pcie Entries exceed the number of 
SCLK Dpm Levels! \
-   Disregarding the excess entries... \n");
+   pr_err("Number of Pcie Entries exceed the number of 
SCLK Dpm Levels! Disregarding the excess entries...\n");
 
pcie_table->count = pcie_count;
for (i = 0; i < pcie_count; i++) {
@@ -563,8 +562,7 @@ static int get_pcie_table(
if ((uint32_t)atom_pcie_table->ucNumEntries <= pcie_count)
pcie_count = (uint32_t)atom_pcie_table->ucNumEntries;
else
-   pr_err("Number of Pcie Entries exceed the number of 
SCLK Dpm Levels! \
-   Disregarding the excess entries... \n");
+   pr_err("Number of Pcie Entries exceed the number of 
SCLK Dpm Levels! Disregarding the excess entries...\n");
 
pcie_table->count = pcie_count;
 
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 4f79c21f27ed..9599fe0ba779 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -546,8 +546,7 @@ static void vega10_patch_with_vdd_leakage(struct pp_hwmgr 
*hwmgr,
}
 
if (*voltage > ATOM_VIRTUAL_VOLTAGE_ID0)
-   pr_info("Voltage value looks like a Leakage ID \
-   but it's not patched\n");
+   pr_info("Voltage value looks like a Leakage ID but it's not 
patched\n");
 }
 
 /**
@@ -701,18 +700,14 @@ static int 
vega10_set_private_data_based_on_pptable(struct pp_hwmgr *hwmgr)
table_info->vdd_dep_on_mclk;
 
PP_ASSERT_WITH_CODE(allowed_sclk_vdd_table,
-   "VDD dependency on SCLK table is missing. \
-   This table is mandatory", return -EINVAL);
+   "VDD dependency on SCLK table is missing. This 

Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 23 +--
  1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00aa98f3e55d..bafb3ee4ea97 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
  {
+   enum hdmi_picture_aspect picture_aspect;
int err;
  
  	if (!frame || !mode)

@@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);

This is slightly going in the loop.
- During the modeset the driver cant specify the aspect ratio 
information, as DRM layer lacks this support.
- So we fill the VIC field, by comparing the mode with the 
DRM_CEA_MODES[] list. This will pick the first mode
  available in the list (regardless of its aspect ratio), and fill the 
VIC, as we don't consider aspect ratio while comparing timings.
- Again, now while sending the aspect ratio, we are picking up the VIC, 
which may not be correct.


So if we have 720x480(4:3) and 720x480(16:9) in the list, as 4:3 is 
first in list, we will always pick 4:3 aspect ratio.


- Shashank
  
+	/*

+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
  


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

[PATCH 1/3] drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888

[Dave Stevenson]

Filling out the list of supported formats based on those the
hardware can support.

Signed-off-by: Dave Stevenson 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 423a23e..513b4b1 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -121,6 +121,14 @@ static const struct hvs_format {
.pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
},
{
+   .drm = DRM_FORMAT_RGB888, .hvs = HVS_PIXEL_FORMAT_RGB888,
+   .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
+   },
+   {
+   .drm = DRM_FORMAT_BGR888, .hvs = HVS_PIXEL_FORMAT_RGB888,
+   .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
+   },
+   {
.drm = DRM_FORMAT_YUV422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
},
-- 
2.7.4

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

[PATCH 0/3] drm/vc4 support for extra formats

[Dave Stevenson]

These are relatively trivial patches that just expand the
list of formats that the vc4 DRM driver will accept.
RGB888, BGR888, NV21, and NV61 tested with the modetest app from the libdrm
repo. YUV422 and YVU422 can't be as they aren't supported.

Dave Stevenson (3):
  drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888
  drm/vc4: Use .pixel_order instead of custom .flip_cbcr
  drm/vc4: Add support for NV21 and NV61.

 drivers/gpu/drm/vc4/vc4_plane.c | 38 ++
 1 file changed, 26 insertions(+), 12 deletions(-)

-- 
2.7.4

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

[PATCH 3/3] drm/vc4: Add support for NV21 and NV61.

[Dave Stevenson]

NV12 (YUV420 2 plane) and NV16 (YUV422 2 plane) were
supported, but NV21 and NV61 (same but with Cb and Cr
swapped) weren't. Add them.

Signed-off-by: Dave Stevenson 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 6373fd5..515f979 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -153,10 +153,20 @@ static const struct hvs_format {
.pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
+   .drm = DRM_FORMAT_NV21,
+   .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
+   },
+   {
.drm = DRM_FORMAT_NV16,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
.pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
+   {
+   .drm = DRM_FORMAT_NV61,
+   .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
+   },
 };
 
 static const struct hvs_format *vc4_get_hvs_format(u32 drm_format)
-- 
2.7.4

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

[PATCH 2/3] drm/vc4: Use .pixel_order instead of custom .flip_cbcr

[Dave Stevenson]

The hardware has enums for altering the Cr and Cb order,
so use this instead of having a flag which swaps the
order the pointers are presented to the hardware
(that only worked for 3 plane formats anyway).

Explicitly sets .pixel_order in each case, rather than
relying on then default XYCBCR order being a value 0.

Signed-off-by: Dave Stevenson 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 513b4b1..6373fd5 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -86,7 +86,6 @@ static const struct hvs_format {
u32 hvs; /* HVS_FORMAT_* */
u32 pixel_order;
bool has_alpha;
-   bool flip_cbcr;
 } hvs_formats[] = {
{
.drm = DRM_FORMAT_XRGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
@@ -131,28 +130,32 @@ static const struct hvs_format {
{
.drm = DRM_FORMAT_YUV422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_YVU422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
-   .flip_cbcr = true,
+   .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
},
{
.drm = DRM_FORMAT_YUV420,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_3PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_YVU420,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_3PLANE,
-   .flip_cbcr = true,
+   .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
},
{
.drm = DRM_FORMAT_NV12,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_NV16,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
+   .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
 };
 
@@ -625,15 +628,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
 * The pointers may be any byte address.
 */
vc4_state->ptr0_offset = vc4_state->dlist_count;
-   if (!format->flip_cbcr) {
-   for (i = 0; i < num_planes; i++)
-   vc4_dlist_write(vc4_state, vc4_state->offsets[i]);
-   } else {
-   WARN_ON_ONCE(num_planes != 3);
-   vc4_dlist_write(vc4_state, vc4_state->offsets[0]);
-   vc4_dlist_write(vc4_state, vc4_state->offsets[2]);
-   vc4_dlist_write(vc4_state, vc4_state->offsets[1]);
-   }
+   for (i = 0; i < num_planes; i++)
+   vc4_dlist_write(vc4_state, vc4_state->offsets[i]);
 
/* Pointer Context Word 0/1/2: Written by the HVS */
for (i = 0; i < num_planes; i++)
-- 
2.7.4

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

Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_edid.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7220b8f9a7e8..00aa98f3e55d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
  static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
This doesn't look right. This means we are expecting a CEA mode without 
a pic aspect ratio field,
which is invalid.  Ankit is going to publish the aspect ratio patch 
series again, with proper DRM cap and flags check. Would it be

ok if we have a look that handling first ?

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
   */
  u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

return 0;
  
+	if (to_match->picture_aspect_ratio)

+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;

same here, and probably in other CEA match functions.

+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
  
  		do {

-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
  static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
  {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
  
  	if (!to_match->clock)

@@ -3020,7 +3029,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
  
-		if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))

+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
  
@@ -3037,6 +3046,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_

   */
  static u8 

[Bug 101473] (SI) latest stable & cant boot

[bugzilla-daemon]

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

--- Comment #6 from denisgolo...@yandex.ru ---
(In reply to Alex Deucher from comment #5)
> The message:
>  Invalid PCI ROM header structure: expecting 0xaa55, got 0x
> is harmless and can be ignored.

Ok. Thanks

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

Re: [PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
HDMI 1.4 does allow for this behaviour, stating that sending the
infoframe is optional in this case.

The infoframe was first specified in HDMI 1.4, so in theory sinks
predating that may not appreciate us sending an uknown infoframe
their way. To avoid regressions let's try to determine if the sink
supports the infoframe or not. Unfortunately there's no direct way
to do that, so instead we'll just check if we managed to parse any
HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the
sink will accept the infoframe. Also if the EDID contains the HDMI
2.0 HDMI Forum VSDB we can assume the sink is prepared to receive
the infoframe.
I am trying to get some sense from HDMI 2.0 spec section 10.2.1, which 
talks about

switch from 3D to 2D.  To me it looks like:
If (sending_to_hdmi2_sinks) {
- for 3d modes send HF-VSIF
- for 2d modes && defined in H14b HFVSIF, send H14B-VSIF
  When you switch from 3d->2d {
 - send_HF-VSIF with 3D_valid bit = 0/1
 }
} else { /* HDMI 1.4b sinks from Appendix F */
-  send H14b-VSIF with HDMI_video_format[2:0 = 0 OR 1]
}

Should we add a is_hdmi2 check and separate these cases ?



v2: Fix the getting has_hdmi_infoframe from display_info
 Always fail constructing the infoframe if the display
 possibly can't handle it

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/bridge/sil-sii8620.c  |  3 ++-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  4 +++-
  drivers/gpu/drm/drm_edid.c| 34 +--
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++--
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  3 ++-
  drivers/gpu/drm/nouveau/nv50_display.c|  3 ++-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  1 +
  drivers/gpu/drm/sti/sti_hdmi.c|  4 +++-
  drivers/gpu/drm/zte/zx_hdmi.c |  1 +
  include/drm/drm_connector.h   |  5 +
  include/drm/drm_edid.h|  1 +
  12 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index b7eb704d0a8a..4417276ba02e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge,
union hdmi_infoframe frm;
u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
  
+			/* FIXME: We need the connector here */

drm_hdmi_vendor_infoframe_from_display_mode(
-   , adjusted_mode);
+   , NULL, adjusted_mode);
vic = frm.vendor.hdmi.vic;
if (vic >= ARRAY_SIZE(mhl_vic))
vic = 0;
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a64ce7112288..b172139502d6 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct 
dw_hdmi *hdmi,
u8 buffer[10];
ssize_t err;
  
-	err = drm_hdmi_vendor_infoframe_from_display_mode(, mode);

+   err = drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode);
if (err < 0)
/*
 * Going into that statement does not means vendor infoframe
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 749d07a01772..9ada0ccf50df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3393,6 +3393,7 @@ static int
  do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
   const u8 *video_db, u8 video_len)
  {
+   struct drm_display_info *info = >display_info;
int modes = 0, offset = 0, i, multi_present = 0, multi_len;
u8 vic_len, hdmi_3d_len = 0;
u16 mask;
@@ -3520,6 +3521,8 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const 
u8 *db, u8 len,
}
  
  out:

+   if (modes > 0)
+   info->has_hdmi_infoframe = true;
return modes;
  }
  
@@ -4243,6 +4246,8 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector 

[Bug 101473] (SI) latest stable & cant boot

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  ---
The message:
 Invalid PCI ROM header structure: expecting 0xaa55, got 0x
is harmless and can be ignored.

-- 
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 101473] (SI) latest stable & cant boot

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

Summary|(SI) latest stable & cant   |(SI) latest stable & cant
   |boot - Invalid PCI ROM  |boot
   |header structure: expecting |
   |0xaa55, got 0x  |

-- 
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 01/10] video/hdmi: Allow "empty" HDMI infoframes

[Sharma, Shashank]

Regards

Shashank


On 11/13/2017 10:34 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that they
should switch from 3D to 2D mode when the source stop transmitting
the infoframe.

v2: Handle unpack() as well
 Pull the length calculation into a helper

Cc: Shashank Sharma 
Cc: Andrzej Hajda 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Reviewed-by: Andrzej Hajda  #v1
Signed-off-by: Ville Syrjälä 
---
  drivers/video/hdmi.c | 51 +++
  1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907ecded4..111a0ab6280a 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct 
hdmi_vendor_infoframe *frame)
  }
  EXPORT_SYMBOL(hdmi_vendor_infoframe_init);
  
+static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame)

+{
+   /* for side by side (half) we also need to provide 3D_Ext_Data */
+   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+   return 6;
+   else if (frame->vic != 0 || frame->s3d_struct != 
HDMI_3D_STRUCTURE_INVALID)
+   return 5;
+   else
+   return 4;
+}
+
  /**
   * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary 
buffer
   * @frame: HDMI infoframe
@@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct 
hdmi_vendor_infoframe *frame,
u8 *ptr = buffer;
size_t length;
  
-	/* empty info frame */

-   if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
-   return -EINVAL;
-
/* only one of those can be supplied */
if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
return -EINVAL;
  
-	/* for side by side (half) we also need to provide 3D_Ext_Data */

-   if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
-   frame->length = 6;
-   else
-   frame->length = 5;
+   frame->length = hdmi_vendor_infoframe_length(frame);
  
  	length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
  
@@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,

ptr[5] = 0x0c;
ptr[6] = 0x00;
  
-	if (frame->vic) {

-   ptr[7] = 0x1 << 5;/* video format */
-   ptr[8] = frame->vic;
-   } else {
+   if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) {
ptr[7] = 0x2 << 5;/* video format */
ptr[8] = (frame->s3d_struct & 0xf) << 4;
if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+   } else if (frame->vic) {
Please correct me if I dint understand this properly, but for a HDMI 2.0 
sink + 3D transmission, wouldn't I be sending

HDMI 2.0 VIC = 94 as well as some valid s3d flag (like side by side) ?

- Shashank

+   ptr[7] = 0x1 << 5;/* video format */
+   ptr[8] = frame->vic;
+   } else {
+   ptr[7] = 0x0 << 5;/* video format */
}
  
  	hdmi_infoframe_set_checksum(buffer, length);

@@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
  
  	if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR ||

ptr[1] != 1 ||
-   (ptr[2] != 5 && ptr[2] != 6))
+   (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6))
return -EINVAL;
  
  	length = ptr[2];

@@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union 
hdmi_vendor_any_infoframe *frame,
  
  	hvf->length = length;
  
-	if (hdmi_video_format == 0x1) {

-   hvf->vic = ptr[4];
-   } else if (hdmi_video_format == 0x2) {
+   if (hdmi_video_format == 0x2) {
+   if (length != 5 && length != 6)
+   return -EINVAL;
hvf->s3d_struct = ptr[4] >> 4;
if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) {
-   if (length == 6)
-   hvf->s3d_ext_data = ptr[5] >> 4;
-   else
+   if (length != 6)
return -EINVAL;
+   hvf->s3d_ext_data = ptr[5] >> 4;
}
+   } else if (hdmi_video_format == 0x1) {
+   if (length != 5)
+   return -EINVAL;
+   hvf->vic = 

Re: [PATCH] drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug

[Benjamin Gaignard]

2017-10-30 10:19 GMT+01:00 Daniel Vetter :
> On Tue, Oct 24, 2017 at 11:01:32AM +0200, Benjamin Gaignard wrote:
>> 2017-10-23 17:25 GMT+02:00 Ville Syrjala :
>> > From: Ville Syrjälä 
>> >
>> > Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > even drivers that don't implement accurate vblank timestamps will end
>> > up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
>> > time drm_crtc_arm_vblank_event() gets called. The could be as often
>> > as every frame for each active crtc.
>> >
>> > Considering drm_crtc_accurate_vblank_count() is never any worse than
>> > the drm_vblank_count() we used previously, let's just skip the WARN
>> > unless DRM_UT_VBL is enabled. That way people won't be bothered by
>> > this unless they're debugging vblank code. And let's also change it
>> > to WARN_ONCE() so that even when you're debugging vblank code you
>> > won't get drowned by constant WARNs.
>> >
>> > Cc: sta...@vger.kernel.org
>> > Cc: Daniel Vetter 
>> > Cc: "Szyprowski, Marek" 
>> > Cc: Andrzej Hajda 
>> > Reported-by: Andrzej Hajda 
>> > Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
>> > Signed-off-by: Ville Syrjälä 
>>
>> I have tested it on sti and stm driver, it fix the problem, thanks.
>>
>> Acked-by: Benjamin Gaignard 
>>
>> > ---
>> >  drivers/gpu/drm/drm_vblank.c | 4 ++--
>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
>> > index 13722c373a6a..c81c297995c6 100644
>> > --- a/drivers/gpu/drm/drm_vblank.c
>> > +++ b/drivers/gpu/drm/drm_vblank.c
>> > @@ -299,8 +299,8 @@ u32 drm_crtc_accurate_vblank_count(struct drm_crtc 
>> > *crtc)
>> > u32 vblank;
>> > unsigned long flags;
>> >
>> > -   WARN(!dev->driver->get_vblank_timestamp,
>> > -"This function requires support for accurate vblank 
>> > timestamps.");
>> > +   WARN_ONCE(drm_debug & DRM_UT_VBL && 
>> > !dev->driver->get_vblank_timestamp,
>> > + "This function requires support for accurate vblank 
>> > timestamps.");
>
> Somewhat a bikeshed, but if we e.g. enable debugging in a CI or piglit
> run, then this could change the results. I'd go with a if ()
> DRM_DEBUG_VBLANK. Either way:
>
> Reviewed-by: Daniel Vetter 
>

Does something is missing to merge this fix in drm-misc ?
Without it I got warning at each frame.

Benjamin

>> >
>> > spin_lock_irqsave(>vblank_time_lock, flags);
>> >
>> > --
>> > 2.13.6
>> >
>> > ___
>> > 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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: remove file that was added accidentally

[Rob Clark]

I think this snuck in when I applied the patch for f97decac5f4c (didn't
apply cleanly, required some manual applying + git-add).  It is unused
and shouldn't be here.  My bad.

Fixes: f97decac5f4c "drm/msm: Support multiple ringbuffers"
Signed-off-by: Rob Clark 
---
 include/dt-bindings/msm/msm-bus-ids.h | 887 --
 1 file changed, 887 deletions(-)
 delete mode 100644 include/dt-bindings/msm/msm-bus-ids.h

diff --git a/include/dt-bindings/msm/msm-bus-ids.h 
b/include/dt-bindings/msm/msm-bus-ids.h
deleted file mode 100644
index a75d304473d5..
--- a/include/dt-bindings/msm/msm-bus-ids.h
+++ /dev/null
@@ -1,887 +0,0 @@
-/* Copyright (c) 2014-2016, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only 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.
- */
-
-#ifndef __MSM_BUS_IDS_H
-#define __MSM_BUS_IDS_H
-
-/* Aggregation types */
-#define AGG_SCHEME_NONE0
-#define AGG_SCHEME_LEG 1
-#define AGG_SCHEME_1   2
-
-/* Topology related enums */
-#defineMSM_BUS_FAB_DEFAULT 0
-#defineMSM_BUS_FAB_APPSS 0
-#defineMSM_BUS_FAB_SYSTEM 1024
-#defineMSM_BUS_FAB_MMSS 2048
-#defineMSM_BUS_FAB_SYSTEM_FPB 3072
-#defineMSM_BUS_FAB_CPSS_FPB 4096
-
-#defineMSM_BUS_FAB_BIMC 0
-#defineMSM_BUS_FAB_SYS_NOC 1024
-#defineMSM_BUS_FAB_MMSS_NOC 2048
-#defineMSM_BUS_FAB_OCMEM_NOC 3072
-#defineMSM_BUS_FAB_PERIPH_NOC 4096
-#defineMSM_BUS_FAB_CONFIG_NOC 5120
-#defineMSM_BUS_FAB_OCMEM_VNOC 6144
-#defineMSM_BUS_FAB_MMSS_AHB 2049
-#defineMSM_BUS_FAB_A0_NOC 6145
-#defineMSM_BUS_FAB_A1_NOC 6146
-#defineMSM_BUS_FAB_A2_NOC 6147
-#defineMSM_BUS_FAB_GNOC 6148
-#defineMSM_BUS_FAB_CR_VIRT 6149
-
-#defineMSM_BUS_MASTER_FIRST 1
-#defineMSM_BUS_MASTER_AMPSS_M0 1
-#defineMSM_BUS_MASTER_AMPSS_M1 2
-#defineMSM_BUS_APPSS_MASTER_FAB_MMSS 3
-#defineMSM_BUS_APPSS_MASTER_FAB_SYSTEM 4
-#defineMSM_BUS_SYSTEM_MASTER_FAB_APPSS 5
-#defineMSM_BUS_MASTER_SPS 6
-#defineMSM_BUS_MASTER_ADM_PORT0 7
-#defineMSM_BUS_MASTER_ADM_PORT1 8
-#defineMSM_BUS_SYSTEM_MASTER_ADM1_PORT0 9
-#defineMSM_BUS_MASTER_ADM1_PORT1 10
-#defineMSM_BUS_MASTER_LPASS_PROC 11
-#defineMSM_BUS_MASTER_MSS_PROCI 12
-#defineMSM_BUS_MASTER_MSS_PROCD 13
-#defineMSM_BUS_MASTER_MSS_MDM_PORT0 14
-#defineMSM_BUS_MASTER_LPASS 15
-#defineMSM_BUS_SYSTEM_MASTER_CPSS_FPB 16
-#defineMSM_BUS_SYSTEM_MASTER_SYSTEM_FPB 17
-#defineMSM_BUS_SYSTEM_MASTER_MMSS_FPB 18
-#defineMSM_BUS_MASTER_ADM1_CI 19
-#defineMSM_BUS_MASTER_ADM0_CI 20
-#defineMSM_BUS_MASTER_MSS_MDM_PORT1 21
-#defineMSM_BUS_MASTER_MDP_PORT0 22
-#defineMSM_BUS_MASTER_MDP_PORT1 23
-#defineMSM_BUS_MMSS_MASTER_ADM1_PORT0 24
-#defineMSM_BUS_MASTER_ROTATOR 25
-#defineMSM_BUS_MASTER_GRAPHICS_3D 26
-#defineMSM_BUS_MASTER_JPEG_DEC 27
-#defineMSM_BUS_MASTER_GRAPHICS_2D_CORE0 28
-#defineMSM_BUS_MASTER_VFE 29
-#defineMSM_BUS_MASTER_VFE0 MSM_BUS_MASTER_VFE
-#defineMSM_BUS_MASTER_VPE 30
-#defineMSM_BUS_MASTER_JPEG_ENC 31
-#defineMSM_BUS_MASTER_GRAPHICS_2D_CORE1 32
-#defineMSM_BUS_MMSS_MASTER_APPS_FAB 33
-#defineMSM_BUS_MASTER_HD_CODEC_PORT0 34
-#defineMSM_BUS_MASTER_HD_CODEC_PORT1 35
-#defineMSM_BUS_MASTER_SPDM 36
-#defineMSM_BUS_MASTER_RPM 37
-#defineMSM_BUS_MASTER_MSS 38
-#defineMSM_BUS_MASTER_RIVA 39
-#defineMSM_BUS_MASTER_SNOC_VMEM 40
-#defineMSM_BUS_MASTER_MSS_SW_PROC 41
-#defineMSM_BUS_MASTER_MSS_FW_PROC 42
-#defineMSM_BUS_MASTER_HMSS 43
-#defineMSM_BUS_MASTER_GSS_NAV 44
-#defineMSM_BUS_MASTER_PCIE 45
-#defineMSM_BUS_MASTER_SATA 46
-#defineMSM_BUS_MASTER_CRYPTO 47
-#defineMSM_BUS_MASTER_VIDEO_CAP 48
-#defineMSM_BUS_MASTER_GRAPHICS_3D_PORT1 49
-#defineMSM_BUS_MASTER_VIDEO_ENC 50
-#defineMSM_BUS_MASTER_VIDEO_DEC 51
-#defineMSM_BUS_MASTER_LPASS_AHB 52
-#defineMSM_BUS_MASTER_QDSS_BAM 53
-#defineMSM_BUS_MASTER_SNOC_CFG 54
-#defineMSM_BUS_MASTER_CRYPTO_CORE0 55
-#defineMSM_BUS_MASTER_CRYPTO_CORE1 56
-#defineMSM_BUS_MASTER_MSS_NAV 57
-#defineMSM_BUS_MASTER_OCMEM_DMA 58
-#defineMSM_BUS_MASTER_WCSS 59
-#defineMSM_BUS_MASTER_QDSS_ETR 60
-#defineMSM_BUS_MASTER_USB3 61

[Bug 101473] (SI) latest stable & cant boot - Invalid PCI ROM header structure: expecting 0xaa55, got 0x0000

[bugzilla-daemon]

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

--- Comment #4 from denisgolo...@yandex.ru ---
Tested under Linux 4.13.9 + ck1 patch, Mesa 17.2.5, xf64-video-amdgpu (git
875339c1064f666a2391b4a5a495eddda9407ab6), libdrm-2.4.88.

-- 
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 v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.

Signed-off-by: H. Nikolaus Schaller 
---
 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 ++--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4 +++-
 3 files changed, 7 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt 
b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
similarity index 84%
rename from 
Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index 7175dc3740ac..ed34253d9fb1 100644
--- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
 
 
 Required properties:
-- compatible: "toppoly,td028ttec1"
+- compatible: "tpo,td028ttec1"
 
 Optional properties:
 - label: a symbolic name for the panel
@@ -14,7 +14,7 @@ Example
 ---
 
 lcd-panel: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 0a38a0e8c925..2dab491478c2 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -452,7 +452,7 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
-   { .compatible = "omapdss,toppoly,td028ttec1", },
+   { .compatible = "omapdss,tpo,td028ttec1", },
{},
 };
 
@@ -471,7 +471,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 57e9e146ff74..b67b324e9919 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -455,6 +455,8 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
+   { .compatible = "omapdss,tpo,td028ttec1", },
+   /* keep to not break older DTB */
{ .compatible = "omapdss,toppoly,td028ttec1", },
{},
 };
@@ -474,7 +476,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:toppoly,td028ttec1");
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
-- 
2.12.2

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

[Bug 101473] (SI) latest stable & cant boot - Invalid PCI ROM header structure: expecting 0xaa55, got 0x0000

[bugzilla-daemon]

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

--- Comment #3 from denisgolo...@yandex.ru ---
Created attachment 135516
  --> https://bugs.freedesktop.org/attachment.cgi?id=135516=edit
XFX Radeon RX580 dmesg

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

[POC 08/16] drm/img-rogue: dma_buf_ops .kmap_* are now .map_*

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/physmem_dmabuf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/physmem_dmabuf.c 
b/drivers/gpu/drm/img-rogue/1.6/physmem_dmabuf.c
index 406886f..4fb813f 100644
--- a/drivers/gpu/drm/img-rogue/1.6/physmem_dmabuf.c
+++ b/drivers/gpu/drm/img-rogue/1.6/physmem_dmabuf.c
@@ -130,8 +130,8 @@ static const struct dma_buf_ops sPVRDmaBufOps =
.map_dma_buf   = PVRDmaBufOpsMap,
.unmap_dma_buf = PVRDmaBufOpsUnmap,
.release   = PVRDmaBufOpsRelease,
-   .kmap_atomic   = PVRDmaBufOpsKMap,
-   .kmap  = PVRDmaBufOpsKMap,
+   .map_atomic= PVRDmaBufOpsKMap,
+   .map   = PVRDmaBufOpsKMap,
.mmap  = PVRDmaBufOpsMMap,
 };
 
-- 
2.7.4

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

[POC 05/16] drm/img-rogue: adapt to changed fence API

[Ulrich Hecht]

Everything "fence..." is now "dma_fence...".

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/pvr_buffer_sync.c | 36 ++---
 drivers/gpu/drm/img-rogue/1.6/pvr_fence.c   | 70 -
 drivers/gpu/drm/img-rogue/1.6/pvr_fence.h   | 20 +++
 3 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/pvr_buffer_sync.c 
b/drivers/gpu/drm/img-rogue/1.6/pvr_buffer_sync.c
index 3afa0cc..3d6f1dc 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pvr_buffer_sync.c
+++ b/drivers/gpu/drm/img-rogue/1.6/pvr_buffer_sync.c
@@ -53,7 +53,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #include "physmem_dmabuf.h"
 
 struct pvr_buffer_sync_check_data {
-   struct fence_cb base;
+   struct dma_fence_cb base;
 
u32 nr_fences;
struct pvr_fence **fences;
@@ -172,7 +172,7 @@ pvr_buffer_sync_pmrs_fence_count(u32 nr_pmrs, PMR **pmrs, 
u32 *pmr_flags)
 {
struct reservation_object *resv;
struct reservation_object_list *resv_list;
-   struct fence *fence;
+   struct dma_fence *fence;
u32 fence_count = 0;
bool exclusive;
int i;
@@ -204,7 +204,7 @@ pvr_buffer_sync_check_fences_create(u32 nr_pmrs, PMR 
**pmrs, u32 *pmr_flags)
struct pvr_buffer_sync_check_data *data;
struct reservation_object *resv;
struct reservation_object_list *resv_list;
-   struct fence *fence;
+   struct dma_fence *fence;
u32 fence_count;
bool exclusive;
int i, j;
@@ -247,7 +247,7 @@ pvr_buffer_sync_check_fences_create(u32 nr_pmrs, PMR 
**pmrs, u32 *pmr_flags)
if (!data->fences[data->nr_fences - 1]) {
data->nr_fences--;
PVR_FENCE_TRACE(fence, "waiting on exclusive 
fence\n");
-   WARN_ON(fence_wait(fence, true) <= 0);
+   WARN_ON(dma_fence_wait(fence, true) <= 0);
}
}
 
@@ -262,7 +262,7 @@ pvr_buffer_sync_check_fences_create(u32 nr_pmrs, PMR 
**pmrs, u32 *pmr_flags)
if (!data->fences[data->nr_fences - 1]) {
data->nr_fences--;
PVR_FENCE_TRACE(fence, "waiting on 
non-exclusive fence\n");
-   WARN_ON(fence_wait(fence, true) <= 0);
+   WARN_ON(dma_fence_wait(fence, true) <= 
0);
}
}
}
@@ -294,7 +294,7 @@ pvr_buffer_sync_check_fences_destroy(struct 
pvr_buffer_sync_check_data *data)
 }
 
 static void
-pvr_buffer_sync_check_data_cleanup(struct fence *fence, struct fence_cb *cb)
+pvr_buffer_sync_check_data_cleanup(struct dma_fence *fence, struct 
dma_fence_cb *cb)
 {
struct pvr_buffer_sync_check_data *data =
container_of(cb, struct pvr_buffer_sync_check_data, base);
@@ -471,9 +471,9 @@ pvr_buffer_sync_append_start(u32 nr_pmrs,
 * Note: we take an additional reference on the update fence in case
 * it signals before we can add it to a reservation object.
 */
-   fence_get(>update_fence->base);
+   dma_fence_get(>update_fence->base);
 
-   err = fence_add_callback(>update_fence->base, _data->base,
+   err = dma_fence_add_callback(>update_fence->base, 
_data->base,
 pvr_buffer_sync_check_data_cleanup);
if (err) {
/*
@@ -540,7 +540,7 @@ pvr_buffer_sync_append_finish(struct 
pvr_buffer_sync_append_data *data)
 * objects we can safely drop the extra reference we took in
 * pvr_buffer_sync_append_start.
 */
-   fence_put(>update_fence->base);
+   dma_fence_put(>update_fence->base);
 
pvr_buffer_sync_pmrs_unlock(data->nr_pmrs, data->pmrs);
 
@@ -567,7 +567,7 @@ pvr_buffer_sync_append_abort(struct 
pvr_buffer_sync_append_data *data)
 * reference taken in pvr_buffer_sync_append_start.
 */
pvr_fence_sync_sw_signal(data->update_fence);
-   fence_put(>update_fence->base);
+   dma_fence_put(>update_fence->base);
pvr_buffer_sync_pmrs_unlock(data->nr_pmrs, data->pmrs);
 
kfree(data->check_ufo_addresses);
@@ -606,7 +606,7 @@ pvr_buffer_sync_wait(PMR *pmr, bool intr, unsigned long 
timeout)
 {
struct reservation_object *resv;
struct reservation_object_list *resv_list = NULL;
-   struct fence *fence, *wait_fence = NULL;
+   struct dma_fence *fence, *wait_fence = NULL;
unsigned seq;
int i;
long lerr;
@@ -630,8 +630,8 @@ pvr_buffer_sync_wait(PMR *pmr, bool intr, unsigned long 
timeout)
for (i = 0; i < resv_list->shared_count; i++) {
fence = rcu_dereference(resv_list->shared[i]);

[Bug 101473] (SI) latest stable & cant boot - Invalid PCI ROM header structure: expecting 0xaa55, got 0x0000

[bugzilla-daemon]

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

--- Comment #2 from denisgolo...@yandex.ru ---
Same error in dmesg for me. Except that I can boot in graphic mode.
My hardware is XFX Radeon RX580.

desktop64 denis # lspci | grep VG
06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Device 67df (rev e7)

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

[POC 14/16] arm64: dts: mt8173: add CPU OPP tables

[Ulrich Hecht]

Adds CPU OPP tables for use with the generic cpufreq driver.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 90 
 1 file changed, 90 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index b99a273..f454efa33 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -51,6 +51,80 @@
mdp_wrot1 = _wrot1;
};
 
+   cluster0_opp: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+   opp@50700 {
+   opp-hz = /bits/ 64 <50700>;
+   opp-microvolt = <859000>;
+   };
+   opp@70200 {
+   opp-hz = /bits/ 64 <70200>;
+   opp-microvolt = <908000>;
+   };
+   opp@100100 {
+   opp-hz = /bits/ 64 <100100>;
+   opp-microvolt = <983000>;
+   };
+   opp@110500 {
+   opp-hz = /bits/ 64 <110500>;
+   opp-microvolt = <1009000>;
+   };
+   opp@120900 {
+   opp-hz = /bits/ 64 <120900>;
+   opp-microvolt = <1034000>;
+   };
+   opp@13 {
+   opp-hz = /bits/ 64 <13>;
+   opp-microvolt = <1057000>;
+   };
+   opp@150800 {
+   opp-hz = /bits/ 64 <150800>;
+   opp-microvolt = <1109000>;
+   };
+   opp@170300 {
+   opp-hz = /bits/ 64 <170300>;
+   opp-microvolt = <1125000>;
+   };
+   };
+
+   cluster1_opp: opp_table1 {
+   compatible = "operating-points-v2";
+   opp-shared;
+   opp@50700 {
+   opp-hz = /bits/ 64 <50700>;
+   opp-microvolt = <828000>;
+   };
+   opp@70200 {
+   opp-hz = /bits/ 64 <70200>;
+   opp-microvolt = <867000>;
+   };
+   opp@100100 {
+   opp-hz = /bits/ 64 <100100>;
+   opp-microvolt = <927000>;
+   };
+   opp@120900 {
+   opp-hz = /bits/ 64 <120900>;
+   opp-microvolt = <968000>;
+   };
+   opp@140400 {
+   opp-hz = /bits/ 64 <140400>;
+   opp-microvolt = <1007000>;
+   };
+   opp@161200 {
+   opp-hz = /bits/ 64 <161200>;
+   opp-microvolt = <1049000>;
+   };
+   opp@180700 {
+   opp-hz = /bits/ 64 <180700>;
+   opp-microvolt = <1089000>;
+   };
+   opp@210600 {
+   opp-hz = /bits/ 64 <210600>;
+   opp-microvolt = <1125000>;
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -81,6 +155,10 @@
reg = <0x000>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   #cooling-min-level = <0>;
+   #cooling-max-level = <7>;
};
 
cpu1: cpu@1 {
@@ -89,6 +167,10 @@
reg = <0x001>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   #cooling-min-level = <0>;
+   #cooling-max-level = <7>;
};
 
cpu2: cpu@100 {
@@ -97,6 +179,10 @@
reg = <0x100>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   #cooling-min-level = <0>;
+   #cooling-max-level = <7>;
};
 
cpu3: cpu@101 {
@@ -105,6 +191,10 @@
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <_SLEEP_0>;
+   operating-points-v2 = <_opp>;
+   #cooling-cells = <2>;
+   #cooling-min-level = <0>;
+   

[POC 10/16] drm/img-rogue: remove .set_busid methods from drm_driver

[Ulrich Hecht]

No longer required.

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/pvr_drm.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c 
b/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
index f72d382..7439a6f 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
+++ b/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
@@ -332,16 +332,6 @@ struct drm_driver sPVRDRMDriver =
},
 #endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(3,3,0)) */
 
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,18,0))
-#if defined(LDM_PCI)
-   .set_busid  = drm_pci_set_busid,
-#elif defined(LDM_PLATFORM)
-   .set_busid  = drm_platform_set_busid,
-#else
-#error "LDM_PLATFORM or LDM_PCI must be defined"
-#endif
-#endif /* (LINUX_VERSION_CODE >= KERNEL_VERSION(3,18,0)) */
-
.name   = PVR_DRM_NAME,
.desc   = PVR_DRM_DESC,
.date   = PVR_DRM_DATE,
-- 
2.7.4

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

Re: [PATCH 1/1] drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable

[Mirza Krak]

2017-11-15 9:17 GMT+01:00 Mirza Krak :
> In the case of the the binds gets defered we would end up with a
> un-balanced runtime PM enable call.
>
> Fix this by simply moving the pm_runtime_enable call to the end of
> the bind function when all paths have succeeded.
>
> Signed-off-by: Mirza Krak 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Re-sent the patch due to initial typos in commit message. Sorry.

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

[POC 07/16] drm/img-rogue: __GFP_WAIT is now __GFP_RECLAIM

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/physmem_osmem_linux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/physmem_osmem_linux.c 
b/drivers/gpu/drm/img-rogue/1.6/physmem_osmem_linux.c
index f5353e3..7b55904 100644
--- a/drivers/gpu/drm/img-rogue/1.6/physmem_osmem_linux.c
+++ b/drivers/gpu/drm/img-rogue/1.6/physmem_osmem_linux.c
@@ -1528,7 +1528,7 @@ _AllocOSPages_Fast(struct _PMR_OSPAGEARRAY_DATA_ 
*psPageArrayData,
 
unsigned int gfp_flags = _GetGFPFlags(psPageArrayData);
IMG_UINT32 ui32GfpFlags;
-   IMG_UINT32 ui32HighOrderGfpFlags = ((gfp_flags & ~__GFP_WAIT) | 
__GFP_NORETRY);
+   IMG_UINT32 ui32HighOrderGfpFlags = ((gfp_flags & ~__GFP_RECLAIM) | 
__GFP_NORETRY);
 
struct page **ppsPageArray = psPageArrayData->pagearray;
 
-- 
2.7.4

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

Re: etnaviv: PHYS_OFFSET usage

[Alexey Brodkin]

Hi Lucas,

On Wed, 2017-11-15 at 17:44 +0100, Lucas Stach wrote:
> Hi Alexey,
> 
> Am Mittwoch, den 15.11.2017, 16:24 + schrieb Alexey Brodkin:
> > 
> > Hi Lucas,
> > 
> > As we discussed on ELCE last month in Prague we have Vivante GPU
> > built-in our new ARC HSDK development board.
> > 
> > And even though [thanks to your suggestions] I got Etnaviv driver
> > working perfectly fine on our board I faced one quite a tricky
> > situation [which I dirty worked-around for now].
> > 
> > Etnaviv driver uses some PHYS_OFFSET define which is not very
> > usual across all architectures and platforms supported by Linux kernel.
> > 
> > In fact for ARC we don't have PHYS_OFFSET defined [yet].
> > And I'm wondering how to get this resolved.
> > 
> > Essentially we have 2 options:
> >  1. Define PHYS_OFFSET for ARC (and later for other arches once needed)
> >  2. Replace PHYS_OFFSET with something else in etnaviv sources.
> > 
> > Even though (1) seems to be the simplest solution is doesn't look very nice
> > because it seems to be quite ARM-specific but not something really generic
> > and portable.
> > 
> > As for (2) frankly I din't quite understand why do we really care about
> > DDR start offset in the GPU driver. If some more light could be shed on this
> > topic probably we'll figure out what would be more elegant solution.
> 
> Basically the GPU has a linear address window which is 2GB in size and
> all GPU command buffers must be mapped through this window. The window
> has a base offset, so we can move it to point to different locations in
> the physical address space of the system.

Wow, what a design decision :)

> Etnaviv uses the PHYS_OFFSET to find out where in the physical address
> space the RAM starts. If the start of RAM is above the 2GB mark we
> _must_ use the linear window in order to make the command buffers
> available to the GPU.

Well that looks not super safe and versatile solution to me.
What if used RAM is much more than 2Gb? I guess in that case it's
possible to to set PHYS_OFFSET to say 0 and then kernel might allocate
command buffer above 2Gb which will make that buffer not visible for
GPU I guess.

> I'm not aware of any other kernel API that would allow us to find the
> start of RAM. If there is I would be happy to replace the PHYS_OFFSET
> stuff. If you don't like to copy the PHYS_OFFSET stuff to ARC, you
> would need to introduce some new API, which allows us to retrieve this
> information.

I'd say we may use so-called "reserved memory" here as a nice an elegant 
solution.
In device tree we describe this memory area like this:
-->8---
gpu_3d: gpu@9 {
compatible = "vivante,gc";
reg = <0x9 0x4000>;
interrupts = <28>;
memory-region = <_memory>;
};

reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
gpu_memory: gpu_memory@be00 {
compatible = "shared-dma-pool";
reg = <0xbe00 0x200>;
no-map;
};
};
-->8---

And then in the driver code we just need to do 2 things:
 1) Start using this memory for allocations in the driver
    with help of of_reserved_mem_device_init()
 2) Get the region start. Not sure what's the best way to do it
    but I guess we'll be able to get "reg" property of the "gpu_memory"
    node in the worst case. And then use that base instead of PHYS_OFFSET.

If of any interest I'll be willing to send you an RFC shortly so you
may see real implementation in details.

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

Re: [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

[Johan Hovold]

On Wed, Nov 15, 2017 at 02:32:11PM +, Lee Jones wrote:
> On Wed, 15 Nov 2017, Johan Hovold wrote:
> 
> > On Tue, Nov 14, 2017 at 07:48:09PM +, Daniel Thompson wrote:
> > > On 14/11/17 18:05, Johan Hovold wrote:
> > > > On Mon, Nov 13, 2017 at 02:16:09PM +, Daniel Thompson wrote:
> > > >> On 13/11/17 10:20, Johan Hovold wrote:
> > > >>> Fix child-node lookup during probe, which ended up searching the whole
> > > >>> device tree depth-first starting at the parent rather than just 
> > > >>> matching
> > > >>> on its children.
> > > >>>
> > > >>> To make things worse, the parent mfd node was also prematurely freed.
> > > >>>
> > > >>> Note that the nodes returned from the two calls to of_parse_phandle()
> > > >>> are also leaking, but fixing that is a bit more involved as pointers 
> > > >>> to
> > > >>> node fields are being stored for later use.
> > > >>
> > > >> Is using a devm_kstrdup() to remember the full_name sufficient so get
> > > >> each of the FIXMEs cleaned up as well?
> > > > 
> > > > Yeah, that may be sufficient, but looking closer at this now, it seems
> > > > the name pointers (su1_fb and su2_fb) are only used as booleans, and the
> > > > fb_name pointer in struct as3711_bl_data is never used at all.
> > > > 
> > > > So cleaning that up somehow (e.g. and maybe even dropping non-dt
> > > > probing) would also work.
> > > > 
> > > > But since this is a separate, and less critical issue, I think it needs
> > > > to be done as a follow up to this one.
> > > 
> > > To be honest it was adding the separate and less critical FIXMEs into 
> > > the patches that attracted my attention in the first place. ;-)
> > 
> > Heh. Since I was touching those error paths, I at least wanted to record
> > somehow there were further issues to be addressed. But feel free to drop
> > the FIXMEs if you prefer.
> 
> In my experience FIXME's tend not to get addressed:
> 
> $ git grep -i fixme | wc -l
> 4431
> 
> Submit patches instead. :)

There may be some truth to that, but I still think it's better to mark
what is broken (especially since a leaked node is no big deal in this
case) than to just ignore and forget about it.

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

[POC 15/16] arm64: dts: mt8173: add GPU device

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 41 
 1 file changed, 41 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index f454efa33..43775a6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -279,6 +279,11 @@
cooling-device = < 0 0>;
contribution = <1024>;
};
+   map@2 {
+   trip = <>;
+   cooling-device = < 0 0>;
+   contribution = <2048>;
+   };
};
};
};
@@ -884,6 +889,42 @@
};
};
 
+   mfgsys: mfgsys@13fff000 {
+   compatible = "mediatek,mt8173-mfgsys", "syscon";
+   reg = <0 0x13fff000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   gpu: mfgsys-gpu@1300 {
+   compatible = "mediatek,mt8173-gpu";
+   reg = <0 0x1300 0 0x>, <0 0x13fff000 0 0x1000>;
+   power-domains = < MT8173_POWER_DOMAIN_MFG_ASYNC>,
+   < MT8173_POWER_DOMAIN_MFG_2D>,
+   < MT8173_POWER_DOMAIN_MFG>;
+   clocks = < CLK_APMIXED_MMPLL>,
+< CLK_TOP_MEM_MFG_IN_SEL>,
+< CLK_TOP_AXI_MFG_IN_SEL>,
+< CLK_TOP_AXI_SEL>,
+< CLK_TOP_MEM_SEL>,
+< CLK_TOP_MFG_SEL>,
+< CLK_TOP_MMPLL>,
+<>;
+   clock-names = "mmpll_clk",
+ "mfg_mem_in_sel",
+ "mfg_axi_in_sel",
+ "top_axi",
+ "top_mem",
+ "top_mfg",
+ "top_mmpll",
+ "clk26m";
+   interrupts = <0 217 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-names = "RGX";
+   status = "disabled";
+   #cooling-cells = <2>;
+   #cooling-min-level = <0>;
+   #cooling-max-level = <3>;
+   };
+
mmsys: clock-controller@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
-- 
2.7.4

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

[PATCH v2 3/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the "omapdss," prefix because the
omapdrm driver takes care of it.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
lcd: lcd@1 {
reg = <1>;  /* CS1 */
-   compatible ="omapdss,tpo,td043mtea1";
+   compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
-- 
2.12.2

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

[POC 11/16] drm/img-rogue: replace call to obsolete drm_platform_init()

[Ulrich Hecht]

Use drm_dev_alloc(), drm_dev_register() and remove the .load and .unload
methods from drm_driver.

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/mt8173/mtk_module.c | 14 +++--
 drivers/gpu/drm/img-rogue/1.6/pvr_drm.c   | 24 +--
 2 files changed, 13 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/mt8173/mtk_module.c 
b/drivers/gpu/drm/img-rogue/1.6/mt8173/mtk_module.c
index 5df3a15..1ef75bb 100644
--- a/drivers/gpu/drm/img-rogue/1.6/mt8173/mtk_module.c
+++ b/drivers/gpu/drm/img-rogue/1.6/mt8173/mtk_module.c
@@ -109,7 +109,7 @@ static struct platform_driver powervr_driver = {
 */
 int PVRSRVSystemInit(struct drm_device *pDrmDevice)
 {
-   struct platform_device *pDevice = pDrmDevice->platformdev;
+   struct platform_device *pDevice = to_platform_device(pDrmDevice->dev);
PVRSRV_ERROR err;
 
PVR_TRACE(("%s (pDevice=%p)", __func__, pDevice));
@@ -160,8 +160,10 @@ void PVRSRVSystemDeInit(struct platform_device *pDevice)
  @Return 0 for success or <0 for an error.
 
 */
+int PVRSRVDRMLoad(struct drm_device *dev, unsigned long flags);
 static int PVRSRVDriverProbe(struct platform_device *pDevice)
 {
+   struct drm_device *drm;
int result;
 
PVR_TRACE(("%s (pDevice=%p)", __func__, pDevice));
@@ -172,13 +174,21 @@ static int PVRSRVDriverProbe(struct platform_device 
*pDevice)
return result;
}
 
-   result = drm_platform_init(, pDevice);
+   drm = drm_dev_alloc(, >dev);
+if (IS_ERR(drm))
+   return PTR_ERR(drm);
+
+   platform_set_drvdata(pDevice, drm);
+
+   result = PVRSRVDRMLoad(drm, 0);
 
dma_set_mask(>dev, DMA_BIT_MASK(33));
 
if (result == 0)
PVRSRVDeviceInit();
 
+   result = drm_dev_register(drm, 0);
+
return result;
 }
 
diff --git a/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c 
b/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
index 7439a6f..36c5a76 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
+++ b/drivers/gpu/drm/img-rogue/1.6/pvr_drm.c
@@ -107,17 +107,12 @@ DECLARE_WAIT_QUEUE_HEAD(sWaitForInit);
 IMG_BOOL bInitComplete;
 IMG_BOOL bInitFailed;
 
-static int PVRSRVDRMLoad(struct drm_device *dev, unsigned long flags)
+int PVRSRVDRMLoad(struct drm_device *dev, unsigned long flags)
 {
int iRes;
 
PVR_TRACE(("PVRSRVDRMLoad"));
 
-#if defined(LDM_PLATFORM)
-   /* The equivalent is done for PCI modesetting drivers by 
drm_get_pci_dev() */
-   platform_set_drvdata(dev->platformdev, dev);
-#endif
-
/* Module initialisation */
iRes = PVRSRVSystemInit(dev);
if (iRes != 0)
@@ -141,21 +136,6 @@ static int PVRSRVDRMLoad(struct drm_device *dev, unsigned 
long flags)
return iRes;
 }
 
-static int PVRSRVDRMUnload(struct drm_device *dev)
-{
-#if defined(LDM_PLATFORM)
-   LDM_DEV *pDevice = dev->platformdev;
-#elif defined(LDM_PCI)
-   LDM_DEV *pDevice = dev->pdev;
-#endif
-
-   PVR_TRACE(("PVRSRVDRMUnload"));
-
-   PVRSRVSystemDeInit(pDevice);
-
-   return 0;
-}
-
 static int PVRSRVDRMOpen(struct drm_device *dev, struct drm_file *file)
 {
while (!bInitComplete)
@@ -306,8 +286,6 @@ struct drm_driver sPVRDRMDriver =
.driver_features= DRIVER_MODESET | DRIVER_RENDER,
 
.dev_priv_size  = 0,
-   .load   = PVRSRVDRMLoad,
-   .unload = PVRSRVDRMUnload,
.open   = PVRSRVDRMOpen,
.postclose  = PVRSRVRelease,
 
-- 
2.7.4

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

[POC 16/16] arm64: dts: mt8173-oak: enable GPU

[Ulrich Hecht]

Includes regulator and operating points definitions.

Signed-off-by: Ulrich Hecht 
---
 arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi
index 54a2500..dd656df 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi
@@ -1010,4 +1010,17 @@
status = "okay";
 };
 
+ {
+   mfgsys-power-supply = <_vgpu_reg>;
+   operating-points = <
+   253500 100
+   299000 100
+   396500 100
+   455000 100
+   494000 113
+   598000 113
+   >;
+   status = "okay";
+};
+
 #include "../../../../arm/boot/dts/cros-ec-keyboard.dtsi"
-- 
2.7.4

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

[POC 03/16] drm/img-rogue: change #include to

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/pvr_uaccess.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/pvr_uaccess.h 
b/drivers/gpu/drm/img-rogue/1.6/pvr_uaccess.h
index 53c8f0a..aab7eba 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pvr_uaccess.h
+++ b/drivers/gpu/drm/img-rogue/1.6/pvr_uaccess.h
@@ -50,7 +50,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #endif
 #endif
 
-#include 
+#include 
 
 static inline unsigned long pvr_copy_to_user(void __user *pvTo, const void 
*pvFrom, unsigned long ulBytes)
 {
-- 
2.7.4

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

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

[Nick Bowler]

Hi,

Any ideas on this issue?  Are there any additional tests I can perform
to help debug this?

On 2017-11-05 11:41 -0500, Nick Bowler wrote:
> I completed bisecting this issue.  See below.
> 
> On 2017-11-02, Nick Bowler  wrote:
> > ~50% of the time after a hotplug, there is a vertical pink bar on the
> > left of the display area and audio is not working at all.  According to
> > the sink device the display size is 1282x720 which seems pretty wrong
> > (normal and working situation is 1280x720).
> >
> > I posted photos of non-working versus working states here:
> >
> >   https://imgur.com/a/qhAZG
> >
> > Unplugging and plugging the cable again will correct the issue (it seems
> > to, for the most part, alternate between working and not-working states,
> > although not always).  It always works on power up with the cable initially
> > connected.
> >
> > This is a regression from 4.11, where hotplug works perfectly every time.
> 
> Bisection implicates the following commit:
> 
> 181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
> commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
> Author: Laurent Pinchart 
> Date:   Mon Mar 6 01:35:57 2017 +0200
> 
> drm: bridge: dw-hdmi: Fix the PHY power up sequence
> 
> When powering the PHY up we need to wait for the PLL to lock. This is
> done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
> (interrupt-based wait could be implemented as well but is likely
> overkill). The bit is asserted when the PLL locks, but the current code
> incorrectly waits for the bit to be deasserted. Fix it, and while at it,
> replace the udelay() with a sleep as the code never runs in
> non-sleepable context.
> 
> To be consistent with the power down implementation move the poll loop
> to the power off function.
> 
> Signed-off-by: Laurent Pinchart 
> 
> Tested-by: Neil Armstrong 
> Reviewed-by: Jose Abreu 
> Signed-off-by: Archit Taneja 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+rene...@ideasonboard.com
> 
> :04 04 0defad9d1a61c0355f49c679b18eebae2c4b9495
> 5d260e6db25d6abc1211d61ec3405be99e693a23 Mdrivers
> 
> This commit does not revert cleanly, but on top of latest master (which has
> the problem) I manually changed the relevant code back to its original state
> and the problem is fixed, like this:
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index bf14214fa464..6618aac95a51 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1100,37 +1100,34 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi 
> *hdmi)
> 
>  static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
>  {
> - const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> - unsigned int i;
> - u8 val;
> + u8 val, msec;
> 
> - if (phy->gen == 1) {
> - dw_hdmi_phy_enable_powerdown(hdmi, false);
> + dw_hdmi_phy_enable_powerdown(hdmi, false);
> 
> - /* Toggle TMDS enable. */
> - dw_hdmi_phy_enable_tmds(hdmi, 0);
> - dw_hdmi_phy_enable_tmds(hdmi, 1);
> - return 0;
> - }
> + /* toggle TMDS enable */
> + dw_hdmi_phy_enable_tmds(hdmi, 0);
> + dw_hdmi_phy_enable_tmds(hdmi, 1);
> 
> + /* gen2 tx power on */
>   dw_hdmi_phy_gen2_txpwron(hdmi, 1);
>   dw_hdmi_phy_gen2_pddq(hdmi, 0);
> 
>   /* Wait for PHY PLL lock */
> - for (i = 0; i < 5; ++i) {
> + msec = 5;
> + do {
>   val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
> - if (val)
> + if (!val)
>   break;
> 
> - usleep_range(1000, 2000);
> - }
> + if (msec == 0) {
> + dev_err(hdmi->dev, "PHY PLL not locked\n");
> + return -ETIMEDOUT;
> + }
> 
> - if (!val) {
> - dev_err(hdmi->dev, "PHY PLL failed to lock\n");
> - return -ETIMEDOUT;
> - }
> + udelay(1000);
> + msec--;
> + } while (1);
> 
> - dev_dbg(hdmi->dev, "PHY PLL locked %u iterations\n", i);
>   return 0;
>  }
> 

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

[POC 12/16] drm/img-rogue: remove locking around devfreq opp functions

[Ulrich Hecht]

Fixes "BUG: sleeping function called from invalid context".

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/pvr_dvfs_device.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/pvr_dvfs_device.c 
b/drivers/gpu/drm/img-rogue/1.6/pvr_dvfs_device.c
index be1919e..cadda55 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pvr_dvfs_device.c
+++ b/drivers/gpu/drm/img-rogue/1.6/pvr_dvfs_device.c
@@ -94,7 +94,6 @@ static IMG_INT32 devfreq_target(struct device *dev, long 
unsigned *requested_fre
IMG_UINT32  ui32Freq, ui32CurFreq, ui32Volt;
struct OPP_STRUCT   *opp;
 
-   rcu_read_lock();
opp = devfreq_recommended_opp(dev, requested_freq, flags);
if (IS_ERR(opp)) {
rcu_read_unlock();
@@ -104,7 +103,6 @@ static IMG_INT32 devfreq_target(struct device *dev, long 
unsigned *requested_fre
 
ui32Freq = OPP_GET_FREQ(opp);
ui32Volt = OPP_GET_VOLTAGE(opp);
-   rcu_read_unlock();
 
ui32CurFreq = psRGXTimingInfo->ui32CoreClockSpeed;
 
@@ -230,11 +228,9 @@ static int GetOPPValues(struct device *dev,
struct dev_pm_opp *opp;
 
/* Start RCU read-side critical section to access device opp_list. */
-   rcu_read_lock();
count = OPP_GET_OPP_COUNT(dev);
if (count < 0) {
dev_err(dev, "Could not fetch OPP count, %d\n", count);
-   rcu_read_unlock();
return count;
}
 
@@ -245,7 +241,6 @@ static int GetOPPValues(struct device *dev,
 #endif
 
if (!freq_table) {
-   rcu_read_unlock();
return -ENOMEM;
}
 
@@ -287,8 +282,6 @@ static int GetOPPValues(struct device *dev,
 
 exit:
 
-   rcu_read_unlock();
-
 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 8, 0))
if (!err)
{
-- 
2.7.4

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

Re: 4.1 EOL

[Tuncer Ayaz]

On 11/15/17, Jani Nikula  wrote:

> The freedesktop.org bugs you reference are for rather different
> platforms than yours. There's nothing there to indicate v4.1 being
> the last known good kernel like for you. There is no exact same
> report.

I don't follow why you think it's a different platform and how I might
have "more" definitely shown v4.1 to be good, but I'll trust your
judgement as a drm dev and not argue :).

> Please file the bug. Please run v4.14 or drm-tip branch from [1].
> Please remove all other module parameters, but add drm.debug=14, and
> attach the dmesg from boot to the problem. Please attach the GPU
> error state if you get a GPU hang. Please let us decide if we've
> seen the bug before or not.

Is the flip_done timeout on exit from Xorg a separate bug? That's one
of the symptoms.

The other symptom is GEM errors in dmesg followed by rcs0 gpu hangs
some time later.

In both cases the machine will be temporarily unresponsive or even
hang indefinitely.

I can't say when the bugs will be filed. Hopefully soon.

> We've been continuously improving our CI and test assets and
> expanding the hardware pool we run the tests on for years now. Even
> so, bugs obviously slip through. And it's really *really* hard to
> revert anything or fix regressions when we get the reports about two
> years or a dozen kernel releases after we've broken stuff. :(

Sure, but it's important to note that the rcs0 hangs have been very
visible in 4.13 and, if included, better hidden in older kernels.
Meaning, it didn't appear as easily in older kernels for me to take
notice and report.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/4] drm: omapdrm: Fix DPI on platforms using the DSI VDDS

[H. Nikolaus Schaller]

From: Laurent Pinchart 

Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
to dpi code") replaced usage of platform data version with SoC matching
to configure DPI VDDS. The SoC match entries were incorrect, they should
have matched on the machine name instead of the SoC family. Fix it.

The result was observed on OpenPandora with OMAP3530 where the panel only
had the Blue channel and Red were missing. It was not observed on
GTA04 with DM3730.

Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi 
code")
Signed-off-by: Laurent Pinchart 
Reported-by: H. Nikolaus Schaller 
Tested-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index 4ed5fde11313..a91e5f1a0490 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -566,8 +566,8 @@ static int dpi_verify_pll(struct dss_pll *pll)
 }
 
 static const struct soc_device_attribute dpi_soc_devices[] = {
-   { .family = "OMAP3[456]*" },
-   { .family = "[AD]M37*" },
+   { .machine = "OMAP3[456]*" },
+   { .machine = "[AD]M37*" },
{ /* sentinel */ }
 };
 
-- 
2.12.2

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

Re: [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

[Johan Hovold]

On Tue, Nov 14, 2017 at 07:48:09PM +, Daniel Thompson wrote:
> On 14/11/17 18:05, Johan Hovold wrote:
> > On Mon, Nov 13, 2017 at 02:16:09PM +, Daniel Thompson wrote:
> >> On 13/11/17 10:20, Johan Hovold wrote:
> >>> Fix child-node lookup during probe, which ended up searching the whole
> >>> device tree depth-first starting at the parent rather than just matching
> >>> on its children.
> >>>
> >>> To make things worse, the parent mfd node was also prematurely freed.
> >>>
> >>> Note that the nodes returned from the two calls to of_parse_phandle()
> >>> are also leaking, but fixing that is a bit more involved as pointers to
> >>> node fields are being stored for later use.
> >>
> >> Is using a devm_kstrdup() to remember the full_name sufficient so get
> >> each of the FIXMEs cleaned up as well?
> > 
> > Yeah, that may be sufficient, but looking closer at this now, it seems
> > the name pointers (su1_fb and su2_fb) are only used as booleans, and the
> > fb_name pointer in struct as3711_bl_data is never used at all.
> > 
> > So cleaning that up somehow (e.g. and maybe even dropping non-dt
> > probing) would also work.
> > 
> > But since this is a separate, and less critical issue, I think it needs
> > to be done as a follow up to this one.
> 
> To be honest it was adding the separate and less critical FIXMEs into 
> the patches that attracted my attention in the first place. ;-)

Heh. Since I was touching those error paths, I at least wanted to record
somehow there were further issues to be addressed. But feel free to drop
the FIXMEs if you prefer.

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

[POC 09/16] drm/img-rogue: translate pgprot_t to pgprot value for __pgprot_modify()

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/pmr_os.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/pmr_os.c 
b/drivers/gpu/drm/img-rogue/1.6/pmr_os.c
index 595f772..9526359 100644
--- a/drivers/gpu/drm/img-rogue/1.6/pmr_os.c
+++ b/drivers/gpu/drm/img-rogue/1.6/pmr_os.c
@@ -253,7 +253,7 @@ OSMMapPMRGeneric(PMR *psPMR, PMR_MMAP_DATA pOSMMapData)
ps_vma->vm_flags = ulNewFlags;
 
 #if defined (CONFIG_ARM64)
-   sPageProt = __pgprot_modify(ps_vma->vm_page_prot, 0, 
vm_get_page_prot(ulNewFlags));
+   sPageProt = __pgprot_modify(ps_vma->vm_page_prot, 0, 
pgprot_val(vm_get_page_prot(ulNewFlags)));
 #elif defined(CONFIG_ARM)
sPageProt = __pgprot_modify(ps_vma->vm_page_prot, L_PTE_MT_MASK, 
vm_get_page_prot(ulNewFlags));
 #elif defined(CONFIG_X86)
-- 
2.7.4

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

Re: [PATCH v2 1/4] omapdrm: fix compatible string for td028ttec1

[H. Nikolaus Schaller]

> Am 16.11.2017 um 13:32 schrieb Tomi Valkeinen :
> 
> On 16/11/17 10:50, H. Nikolaus Schaller wrote:
>> The vendor name was "toppoly" but other panels and the vendor list
>> have defined it as "tpo". So let's fix it in driver and bindings.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
> 
> 
>> -MODULE_ALIAS("spi:toppoly,td028ttec1");
>> +MODULE_ALIAS("spi:tpo,td028ttec1");
> 
> Doesn't this mean that the module won't load if you have old bindings?

Hm.

Well, I think it can load but doesn't automatically from DT strings which might
be unexpected.

> Can't we have two module aliases?

I think we can. Just a random example:
https://elixir.free-electrons.com/linux/latest/source/drivers/w1/slaves/w1_therm.c#L754

So we should keep both.

Should I submit a new version?

BR,
Nikolaus

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

[PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Vendor string is "tpo" and not "toppoly".

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
-- 
2.12.2

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

[PATCH v2 0/4] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent 
Pinchart
* keep previous compatibility option in panel driver to handle older device 
tree binaries

2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (3):
  omapdrm: fix compatible string for td028ttec1
  DTS: GTA04: fix panel compatibility string
  DTS: Pandora: fix panel compatibility string

Laurent Pinchart (1):
  drm: omapdrm: Fix DPI on platforms using the DSI VDDS

 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi| 2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi   | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 4 ++--
 drivers/gpu/drm/omapdrm/dss/dpi.c | 4 ++--
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 4 +++-
 6 files changed, 11 insertions(+), 9 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

-- 
2.12.2

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

[POC 01/16] drm/img-rogue: fix signatures of struct devfreq_cooling_power ops

[Ulrich Hecht]

Has a struct devfreq pointer now.

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/mt8173/mt8173_sysconfig.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/mt8173/mt8173_sysconfig.c 
b/drivers/gpu/drm/img-rogue/1.6/mt8173/mt8173_sysconfig.c
index 14f7dcc..bbda6ff 100644
--- a/drivers/gpu/drm/img-rogue/1.6/mt8173/mt8173_sysconfig.c
+++ b/drivers/gpu/drm/img-rogue/1.6/mt8173/mt8173_sysconfig.c
@@ -245,7 +245,8 @@ static u32 interpolate(int value, const int *x, const 
unsigned int *y, int len)
return ret;
 }
 
-static unsigned long mtk_mfg_get_static_power(unsigned long voltage)
+static unsigned long mtk_mfg_get_static_power(struct devfreq *devfreq,
+ unsigned long voltage)
 {
struct mtk_mfg *mfg = gsDevice.hSysData;
struct thermal_zone_device *tz = mfg->tz;
@@ -299,7 +300,8 @@ static unsigned long mtk_mfg_get_static_power(unsigned long 
voltage)
return power;
 }
 
-static unsigned long mtk_mfg_get_dynamic_power(unsigned long freq,
+static unsigned long mtk_mfg_get_dynamic_power(struct devfreq *devfreq,
+  unsigned long freq,
   unsigned long voltage)
 {
#define NUM_RANGE  ARRAY_SIZE(f_range)
-- 
2.7.4

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

etnaviv: PHYS_OFFSET usage

[Alexey Brodkin]

Hi Lucas,

As we discussed on ELCE last month in Prague we have Vivante GPU
built-in our new ARC HSDK development board.

And even though [thanks to your suggestions] I got Etnaviv driver
working perfectly fine on our board I faced one quite a tricky
situation [which I dirty worked-around for now].

Etnaviv driver uses some PHYS_OFFSET define which is not very
usual across all architectures and platforms supported by Linux kernel.

In fact for ARC we don't have PHYS_OFFSET defined [yet].
And I'm wondering how to get this resolved.

Essentially we have 2 options:
 1. Define PHYS_OFFSET for ARC (and later for other arches once needed)
 2. Replace PHYS_OFFSET with something else in etnaviv sources.

Even though (1) seems to be the simplest solution is doesn't look very nice
because it seems to be quite ARM-specific but not something really generic
and portable.

As for (2) frankly I din't quite understand why do we really care about
DDR start offset in the GPU driver. If some more light could be shed on this
topic probably we'll figure out what would be more elegant solution.

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

[PATCH 1/1 v2] drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable

[Mirza Krak]

In the case where the bind gets deferred we would end up with a
un-balanced runtime PM enable call.

Fix this by simply moving the pm_runtime_enable call to the end of
the bind function when all paths have succeeded.

Signed-off-by: Mirza Krak 
---

Changes in v2:
- typos in commit message

 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9a20b9d..f7fc652 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1275,8 +1275,6 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
goto err_pllref;
}
 
-   pm_runtime_enable(dev);
-
dsi->dsi_host.ops = _mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(>dsi_host);
@@ -1291,6 +1289,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
}
 
dev_set_drvdata(dev, dsi);
+   pm_runtime_enable(dev);
return 0;
 
 err_mipi_dsi_host:
-- 
2.1.4

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

[POC 06/16] drm/img-rogue: dma_ops->sync_single_for_*() -> dma_sync_single_for_*()

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/osfunc_arm64.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/osfunc_arm64.c 
b/drivers/gpu/drm/img-rogue/1.6/osfunc_arm64.c
index 84ae224..091806d 100644
--- a/drivers/gpu/drm/img-rogue/1.6/osfunc_arm64.c
+++ b/drivers/gpu/drm/img-rogue/1.6/osfunc_arm64.c
@@ -89,8 +89,8 @@ void OSFlushCPUCacheRangeKM(void *pvVirtStart,
IMG_CPU_PHYADDR 
sCPUPhysStart,
IMG_CPU_PHYADDR 
sCPUPhysEnd)
 {
-   dma_ops->sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
-   dma_ops->sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
+   dma_sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
+   dma_sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, sCPUPhysEnd.uiAddr 
- sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
 }
 
 void OSCleanCPUCacheRangeKM(void *pvVirtStart,
@@ -98,7 +98,7 @@ void OSCleanCPUCacheRangeKM(void *pvVirtStart,
IMG_CPU_PHYADDR 
sCPUPhysStart,
IMG_CPU_PHYADDR 
sCPUPhysEnd)
 {
-   dma_ops->sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
+   dma_sync_single_for_device(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_TO_DEVICE);
 }
 
 void OSInvalidateCPUCacheRangeKM(void *pvVirtStart,
@@ -106,7 +106,7 @@ void OSInvalidateCPUCacheRangeKM(void *pvVirtStart,
 
IMG_CPU_PHYADDR sCPUPhysStart,
 
IMG_CPU_PHYADDR sCPUPhysEnd)
 {
-   dma_ops->sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, 
sCPUPhysEnd.uiAddr - sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
+   dma_sync_single_for_cpu(NULL, sCPUPhysStart.uiAddr, sCPUPhysEnd.uiAddr 
- sCPUPhysStart.uiAddr, DMA_FROM_DEVICE);
 }
 
 void OSUserModeAccessToPerfCountersEn(void)
-- 
2.7.4

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

[POC 02/16] drm/img-rogue: convert pfn to pfn_t for vm_insert_mixed()

[Ulrich Hecht]

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/osfunc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/img-rogue/1.6/osfunc.c 
b/drivers/gpu/drm/img-rogue/1.6/osfunc.c
index 2631357..7a9255b0 100644
--- a/drivers/gpu/drm/img-rogue/1.6/osfunc.c
+++ b/drivers/gpu/drm/img-rogue/1.6/osfunc.c
@@ -69,6 +69,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #endif
 #include 
 #include 
+#include 
 
 #include "log2.h"
 #include "osfunc.h"
@@ -2381,7 +2382,7 @@ PVRSRV_ERROR OSChangeSparseMemCPUAddrMap(void 
**psPageArray,
 
if(bMixedMap )
{
-   eError = vm_insert_mixed(psVMA,uiCPUVirtAddr, 
uiPFN);
+   eError = vm_insert_mixed(psVMA,uiCPUVirtAddr, 
__pfn_to_pfn_t(uiPFN, PFN_DEV));
}
else
{
-- 
2.7.4

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

[POC 04/16] drm/img-rogue: #include in osfunc.c

[Ulrich Hecht]

Required for sched_clock()

Signed-off-by: Ulrich Hecht 
---
 drivers/gpu/drm/img-rogue/1.6/osfunc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/img-rogue/1.6/osfunc.c 
b/drivers/gpu/drm/img-rogue/1.6/osfunc.c
index 7a9255b0..4481381 100644
--- a/drivers/gpu/drm/img-rogue/1.6/osfunc.c
+++ b/drivers/gpu/drm/img-rogue/1.6/osfunc.c
@@ -69,6 +69,7 @@ CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE SOFTWARE.
 #endif
 #include 
 #include 
+#include 
 #include 
 
 #include "log2.h"
-- 
2.7.4

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