[PATCH v2] drm/panel: simple: Add support for AUO t215hvn01

[Emil Velikov]

On 10 October 2016 at 19:35, Haixia Shi  wrote:
> The AUO t215hvn01 is a 21.5" 1920x1080 panel.
>
> v2: fix alphabetical order
>
Thanks for this and dropping the CHOMIUM/Reviewed-on tags.

> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c

> @@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "auo,b133xtn01",
> .data = _b133xtn01,
> }, {
> +   .compatible = "auo,t215hvn01.0",
We haven't had any compatible strings which end with .0 (or any other
number for that matter) for drm panels. The DT binding documentation
should mention why, yet there doesn't seem to be a patch for that ?

You want one (be that separate patch or part of this one), regardless
if the simple panel driver is used or not.

If you want to be extra nice to Thierry/Rob H you can even add a link
to the spec/data sheet :-)

-Emil

[Intel-gfx] [PATCH] drm/crtc: constify drm_crtc_index parameter

[Ville Syrjälä]

On Mon, Oct 10, 2016 at 06:10:42PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 6:04 PM, Ville Syrjälä
>  wrote:
> > On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> >> Signed-off-by: Jani Nikula 
> >>
> >> ---
> >>
> >> I needed this for some stuff that turned out to be a dead end. But this
> >> seems to be the right thing to do anyway.
> >> ---
> >>  include/drm/drm_crtc.h | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index 61932f55f788..0aa292526567 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -1342,7 +1342,7 @@ extern void drm_crtc_cleanup(struct drm_crtc *crtc);
> >>   * Given a registered CRTC, return the index of that CRTC within a DRM
> >>   * device's list of CRTCs.
> >>   */
> >> -static inline unsigned int drm_crtc_index(struct drm_crtc *crtc)
> >> +static inline unsigned int drm_crtc_index(const struct drm_crtc *crtc)
> >>  {
> >>   return crtc->index;
> >
> > BTW speaking about the index stuff. It dawned on me recently that calling
> > drm_crtc_cleanup() & co. is totally not safe except maybe during the
> > final cleanup.
> >
> > If you would do something like:
> > a = drm_crtc_init();
> > b = drm_crtc_init();
> > drm_crtc_cleanup(a);
> > c = drm_crtc_init();
> >
> > b and c would end up with the same index.
> >
> >
> > Or if you would do just
> > a = drm_crtc_init();
> > b = drm_crtc_init();
> > drm_crtc_cleanup(a);
> >
> > We'd end up with num_crtc==1, but b->index==1, so we'd actually access
> > beyond the allocated arrays in a bunch of places.
> >
> > This would need to fixed somehow, or at least documented clearly that if
> > you have to call any of the cleanup functions during init, you have to
> > abort the entire thing.
> 
> You can't hotplug CRTCs, like you can't hotplug anything else than
> connectors. And for connectors we have an ida to make sure you never
> end up with duplicated indizes. So I think we're safe.

Except in i915 we don't abort the driver load if we would fail part
way into the crtc init. So we'd just keep going with bogus indexes
and whatnot. I think I wrote a patch to change that, but I'd have
find it again to be sure. Other drivers may or may not have the same
problem.

-- 
Ville Syrjälä
Intel OTC

[Intel-gfx] [PATCH] drm/crtc: constify drm_crtc_index parameter

[Daniel Vetter]

On Mon, Oct 10, 2016 at 6:30 PM, Ville Syrjälä
 wrote:
>> You can't hotplug CRTCs, like you can't hotplug anything else than
>> connectors. And for connectors we have an ida to make sure you never
>> end up with duplicated indizes. So I think we're safe.
>
> Except in i915 we don't abort the driver load if we would fail part
> way into the crtc init. So we'd just keep going with bogus indexes
> and whatnot. I think I wrote a patch to change that, but I'd have
> find it again to be sure. Other drivers may or may not have the same
> problem.

Hm, we should at least make sure we don't leave any partially
initialized modeset objects behind when the modeset part of the driver
fails to load.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/crtc: constify drm_crtc_index parameter

[Ville Syrjälä]

On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> I needed this for some stuff that turned out to be a dead end. But this
> seems to be the right thing to do anyway.
> ---
>  include/drm/drm_crtc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 61932f55f788..0aa292526567 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1342,7 +1342,7 @@ extern void drm_crtc_cleanup(struct drm_crtc *crtc);
>   * Given a registered CRTC, return the index of that CRTC within a DRM
>   * device's list of CRTCs.
>   */
> -static inline unsigned int drm_crtc_index(struct drm_crtc *crtc)
> +static inline unsigned int drm_crtc_index(const struct drm_crtc *crtc)
>  {
>   return crtc->index;

BTW speaking about the index stuff. It dawned on me recently that calling
drm_crtc_cleanup() & co. is totally not safe except maybe during the
final cleanup.

If you would do something like:
a = drm_crtc_init();
b = drm_crtc_init();
drm_crtc_cleanup(a);
c = drm_crtc_init();

b and c would end up with the same index.


Or if you would do just
a = drm_crtc_init();
b = drm_crtc_init();
drm_crtc_cleanup(a);

We'd end up with num_crtc==1, but b->index==1, so we'd actually access
beyond the allocated arrays in a bunch of places.

This would need to fixed somehow, or at least documented clearly that if
you have to call any of the cleanup functions during init, you have to
abort the entire thing.

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm/crtc: constify drm_crtc_index parameter

[Jani Nikula]

Signed-off-by: Jani Nikula 

---

I needed this for some stuff that turned out to be a dead end. But this
seems to be the right thing to do anyway.
---
 include/drm/drm_crtc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 61932f55f788..0aa292526567 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1342,7 +1342,7 @@ extern void drm_crtc_cleanup(struct drm_crtc *crtc);
  * Given a registered CRTC, return the index of that CRTC within a DRM
  * device's list of CRTCs.
  */
-static inline unsigned int drm_crtc_index(struct drm_crtc *crtc)
+static inline unsigned int drm_crtc_index(const struct drm_crtc *crtc)
 {
return crtc->index;
 }
-- 
2.1.4

[Intel-gfx] [PATCH] drm/crtc: constify drm_crtc_index parameter

[Daniel Vetter]

On Mon, Oct 10, 2016 at 6:04 PM, Ville Syrjälä
 wrote:
> On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
>> Signed-off-by: Jani Nikula 
>>
>> ---
>>
>> I needed this for some stuff that turned out to be a dead end. But this
>> seems to be the right thing to do anyway.
>> ---
>>  include/drm/drm_crtc.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 61932f55f788..0aa292526567 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1342,7 +1342,7 @@ extern void drm_crtc_cleanup(struct drm_crtc *crtc);
>>   * Given a registered CRTC, return the index of that CRTC within a DRM
>>   * device's list of CRTCs.
>>   */
>> -static inline unsigned int drm_crtc_index(struct drm_crtc *crtc)
>> +static inline unsigned int drm_crtc_index(const struct drm_crtc *crtc)
>>  {
>>   return crtc->index;
>
> BTW speaking about the index stuff. It dawned on me recently that calling
> drm_crtc_cleanup() & co. is totally not safe except maybe during the
> final cleanup.
>
> If you would do something like:
> a = drm_crtc_init();
> b = drm_crtc_init();
> drm_crtc_cleanup(a);
> c = drm_crtc_init();
>
> b and c would end up with the same index.
>
>
> Or if you would do just
> a = drm_crtc_init();
> b = drm_crtc_init();
> drm_crtc_cleanup(a);
>
> We'd end up with num_crtc==1, but b->index==1, so we'd actually access
> beyond the allocated arrays in a bunch of places.
>
> This would need to fixed somehow, or at least documented clearly that if
> you have to call any of the cleanup functions during init, you have to
> abort the entire thing.

You can't hotplug CRTCs, like you can't hotplug anything else than
connectors. And for connectors we have an ida to make sure you never
end up with duplicated indizes. So I think we're safe.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 98200] [radeon] kernel hangs during shutdown - drm-next-4.9-/+wip

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Arek Ruśniak  ---
I forgot mention this is VERDE chip.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/7a128a79/attachment-0001.html>

[PATCH v2] drm: Don't force all planes to be added to the state due to zpos

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i915 actually falls into this
category right now since we've not yet added zpos support).

Allow drivers more freedom by letting them deal with zpos
themselves instead of doing it in drm_atomic_helper_check_planes()
unconditionally. Let's just inline the required calls into all
the driver that currently depend on this.

v2: Inline the stuff into the drivers instead of adding another
helper, document things better (Daniel)

Cc: Daniel Vetter 
Cc: Marek Szyprowski 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Laurent Pinchart 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Lyude 
Cc: Maarten Lankhorst 
Cc: stable at vger.kernel.org
Fixes: 44d1240d006c ("drm: add generic zpos property")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 +
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 12 ++--
 drivers/gpu/drm/sti/sti_drv.c   | 22 +-
 include/drm/drm_plane.h |  8 +++-
 7 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c3f83476f996..21f992605541 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index def78c8c1780..f86e7c846678 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -262,6 +262,26 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
drm_atomic_state *state,
return 0;
 }

+int exynos_atomic_check(struct drm_device *dev,
+   struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+
 static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
 {
struct drm_exynos_file_private *file_priv;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d215149e737b..80c4d5b81689 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -301,6 +301,7 @@ static inline int exynos_dpi_bind(struct drm_device *dev,

 int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
+int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);


 extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 40ce841eb952..23cce0a3f5fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
*fb, int index)
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
-   .atomic_check = drm_atomic_helper_check,
+   .atomic_check = exynos_atomic_check,
.atomic_commit = exynos_atomic_commit,
 };

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index bd9c3bb9252c..392c7e6de042 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -231,8 +231,16 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_device *rcdu = dev->dev_private;
int ret;

-   ret = drm_atomic_helper_check(dev, state);
-   if (ret < 0)
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if 

[Bug 98200] [radeon] kernel hangs during shutdown - drm-next-4.9-/+wip

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98200
   Summary: [radeon] kernel hangs during shutdown -
drm-next-4.9-/+wip
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

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

Hi, 
I cannot restart or shutdown my PC since 26th or 27th sep. When I init
poweroff/restart always off with black screen, nothing happened.. I can only
press power or restart button.

When I start with radeon as second GPU, PC hangs on shutdown anyway but now i
can see on screen kernel panic msg. 


after reverted commit[1] everything works as before. 
[1]
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.9=a481daa88fd4d6b54f25348972bba10b5f6a84d0

I've only tested with next-drm-4.9 & -wip

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/de432b11/attachment.html>

[PATCH v2] drm: Don't force all planes to be added to the state due to zpos

[Daniel Vetter]

On Mon, Oct 10, 2016 at 05:50:56PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> updates to go through w/o throttling. Same holds for drivers
> that don't support zpos at all (i915 actually falls into this
> category right now since we've not yet added zpos support).
> 
> Allow drivers more freedom by letting them deal with zpos
> themselves instead of doing it in drm_atomic_helper_check_planes()
> unconditionally. Let's just inline the required calls into all
> the driver that currently depend on this.
> 
> v2: Inline the stuff into the drivers instead of adding another
> helper, document things better (Daniel)
> 
> Cc: Daniel Vetter 
> Cc: Marek Szyprowski 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Laurent Pinchart 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Lyude 
> Cc: Maarten Lankhorst 
> Cc: stable at vger.kernel.org
> Fixes: 44d1240d006c ("drm: add generic zpos property")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  4 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |  1 +
>  drivers/gpu/drm/exynos/exynos_drm_fb.c  |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 12 ++--
>  drivers/gpu/drm/sti/sti_drv.c   | 22 +-
>  include/drm/drm_plane.h |  8 +++-
>  7 files changed, 60 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c3f83476f996..21f992605541 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
>  
> - ret = drm_atomic_normalize_zpos(dev, state);
> - if (ret)
> - return ret;
> -
>   for_each_plane_in_state(state, plane, plane_state, i) {
>   const struct drm_plane_helper_funcs *funcs;
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index def78c8c1780..f86e7c846678 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -262,6 +262,26 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
> drm_atomic_state *state,
>   return 0;
>  }
>  
> +int exynos_atomic_check(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_normalize_zpos(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_helper_check_planes(dev, state);
> + if (ret)
> + return ret;
> +
> + return ret;
> +}
> +
>  static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
>  {
>   struct drm_exynos_file_private *file_priv;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index d215149e737b..80c4d5b81689 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -301,6 +301,7 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
>  
>  int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
> *state,
>bool nonblock);
> +int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
> *state);
>  
>  
>  extern struct platform_driver fimd_driver;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index 40ce841eb952..23cce0a3f5fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
> *fb, int index)
>  static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
>   .fb_create = exynos_user_fb_create,
>   .output_poll_changed = exynos_drm_output_poll_changed,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = exynos_atomic_check,
>   .atomic_commit = exynos_atomic_commit,
>  };
>  
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index bd9c3bb9252c..392c7e6de042 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -231,8 +231,16 @@ static int rcar_du_atomic_check(struct drm_device *dev,
>   struct rcar_du_device *rcdu = dev->dev_private;
>   int ret;
>  
> - ret = drm_atomic_helper_check(dev, state);
> - if (ret < 0)
> + ret = 

[Intel-gfx] [PATCH] drm/crtc: constify drm_crtc_index parameter

[Daniel Vetter]

On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> I needed this for some stuff that turned out to be a dead end. But this
> seems to be the right thing to do anyway.

Applied to drm-misc. There's also the connector and plane versions of
this, care to spin them too?
-Daniel

> ---
>  include/drm/drm_crtc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 61932f55f788..0aa292526567 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1342,7 +1342,7 @@ extern void drm_crtc_cleanup(struct drm_crtc *crtc);
>   * Given a registered CRTC, return the index of that CRTC within a DRM
>   * device's list of CRTCs.
>   */
> -static inline unsigned int drm_crtc_index(struct drm_crtc *crtc)
> +static inline unsigned int drm_crtc_index(const struct drm_crtc *crtc)
>  {
>   return crtc->index;
>  }
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 1/2] dt-bindings: add bindings doc for ZTE VOU display controller

[Rob Herring]

On Sun, Oct 09, 2016 at 03:49:10PM +0800, Shawn Guo wrote:
> On Mon, Oct 03, 2016 at 12:44:29PM -0500, Rob Herring wrote:
> > > +Example:
> > > +
> > > +vou: vou at 144 {
> > > + compatible = "zte,zx296718-vou";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + reg = <0x144 0x1>;
> > > + ranges;
> > 
> > You still have overlapping addresses. Explicitly list the sub ranges in 
> > reg here used by the VOU driver if the driver usage doesn't overlap. If 
> > there is overlap (2 drivers accessing the same range), then you need 
> > some APIs between the components (or possibly regmap).
> 
> The driver matching "zte,zx296718-vou" doesn't map or access the any
> 'reg' address.  The 'reg' property here is more like a hint telling
> that the VOU block covers the address space of all child devices.
> 
> I will simply drop the 'reg' property here.
> 
> > Also, don't do an empty ranges here. Fill it in so the child nodes are 
> > just offsets of 0x144
> 
> Okay.  I thought that empty 'ranges' is fine as long as parent and child
> address spaces are identical (1:1 mapping).

It is fine, but it's just better policy to limit the scope of things.

> So with your suggestion, I made the changes below.  Let me know if this
> is still not what you are asking for.

Looks fine. With that,

Acked-by: Rob Herring 

> 
> Shawn
> 
> -8<-
> 
> diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt 
> b/Documentation/devicetree/bindings/display/zte,vou.txt
> index d03ba4c4810c..6bb4ab2517ef 100644
> --- a/Documentation/devicetree/bindings/display/zte,vou.txt
> +++ b/Documentation/devicetree/bindings/display/zte,vou.txt
> @@ -56,14 +56,13 @@ vou: vou at 144 {
> compatible = "zte,zx296718-vou";
> #address-cells = <1>;
> #size-cells = <1>;
> -   reg = <0x144 0x1>;
> -   ranges;
> +   ranges = <0 0x144 0x1>;
>  
> -   dpc: dpc at 144 {
> +   dpc: dpc at 0 {
> compatible = "zte,zx296718-dpc";
> -   reg = <0x144 0x1000>, <0x1441000 0x1000>,
> - <0x1445000 0x1000>, <0x1446000 0x1000>,
> - <0x144a000 0x1000>;
> +   reg = <0x 0x1000>, <0x1000 0x1000>,
> + <0x5000 0x1000>, <0x6000 0x1000>,
> + <0xa000 0x1000>;
> reg-names = "osd", "timing_ctrl",
> "dtrc", "vou_ctrl",
> "otfppu";
> @@ -74,9 +73,9 @@ vou: vou at 144 {
>   "main_wclk", "aux_wclk";
> };
>  
> -   hdmi: hdmi at 144c000 {
> +   hdmi: hdmi at c000 {
> compatible = "zte,zx296718-hdmi";
> -   reg = <0x144c000 0x4000>;
> +   reg = <0xc000 0x4000>;
> interrupts = ;
> 

[Intel-gfx] [PATCH] drm/crtc: constify drm_crtc_index parameter

[Chris Wilson]

On Mon, Oct 10, 2016 at 06:26:10PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula 

Plus equivalents in drm_plane.h, drm_encoder.h ...

Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Ville Syrjälä]

On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
>  wrote:
> >> I think the
> >> proper way is to keep track of a per-plane zpos changed (or compute
> >> that ad-hoc, we have both states). And only grab more planes if a zpos
> >> value changed.
> >
> > Doesn't work with normalized zpos. The plane's actual zpos may be
> > unchanged even if the normalized zpos changes.
> 
> Well I meant to do a first loop to check for any zpos changes, and
> only then add all the planes. If no one touched zpos, then also no
> normalized zpos can change. I think at least ... Or what am I missing?

Enabling planes can change zpos. Which is what's currently causing all
the planes to be added to the state every time the cursor is
enabled/disabled on i915. Which isn't nice.

And anyway adding all the planes to the state when some zpos change
happens is entirely pointless on i915. There's no need to run through
any of .check_plane() hooks in this case. The only thing we need to
do is rewrite the sprite control registers (+ base addresses of course
to arm the update). So we could just add the sprite planes to state
after the .check_plane() stuff has been done so that we'll just get the
.commit_plane(). So knowing somehting about the hardware allows us to
do a much better job of this.

-- 
Ville Syrjälä
Intel OTC

[PATCH v3] drm/panel: simple: Add support for AUO t215hvn01

[Haixia Shi]

The AUO t215hvn01 is a 21.5" 1920x1080 panel.

Link to spec: http://www.udmgroup.com/ftp/T215HVN01.0.pdf

v2: fix alphabetical order
v3: remove minor revision suffix ".0" and add link to spec

Signed-off-by: Haixia Shi 
Tested-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
Cc: Emil Velikov 
Cc: Thierry Reding 
---
 drivers/gpu/drm/panel/panel-simple.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..256c201 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -555,6 +555,33 @@ static const struct panel_desc auo_b133htn01 = {
},
 };

+static const struct drm_display_mode auo_t215hvn01_mode = {
+   .clock = 148800,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 88,
+   .hsync_end = 1920 + 88 + 44,
+   .htotal = 1920 + 88 + 44 + 148,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 4,
+   .vsync_end = 1080 + 4 + 5,
+   .vtotal = 1080 + 4 + 5 + 36,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_t215hvn01 = {
+   .modes = _t215hvn01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 430,
+   .height = 270,
+   },
+   .delay = {
+   .disable = 5,
+   .unprepare = 1000,
+   }
+};
+
 static const struct drm_display_mode avic_tm070ddh03_mode = {
.clock = 51200,
.hdisplay = 1024,
@@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
+   .compatible = "auo,t215hvn01",
+   .data = _t215hvn01,
+   }, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
-- 
2.8.0.rc3.226.g39d4020

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Ville Syrjälä]

On Mon, Oct 10, 2016 at 02:46:35PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:19 PM,   wrote:
> > From: Ville Syrjälä 
> >
> > We don't want all planes to be added to the state whenever a
> > plane with fixed zpos gets enabled/disabled. This is true
> > especially for eg. cursor planes on i915, as we want cursor
> > updates to go through w/o throttling. Same holds for drivers
> > that don't support zpos at all (i915 actually falls into this
> > category right now since we've not yet added zpos support).
> >
> > Allow drivers more freedom by letting them deal with zpos
> > themselves instead of doing it in drm_atomic_helper_check_planes()
> > unconditionally. Easiest solution seems to be to move the call
> > up to drm_atomic_helper_check(). But as some drivers might want
> > to use that function without the zpos handling, let's provide
> > two variants: the normal one, and one that deals with zpos.
> >
> > Cc: Marek Szyprowski 
> > Cc: Benjamin Gaignard 
> > Cc: Vincent Abriou 
> > Cc: Laurent Pinchart 
> > Cc: Inki Dae 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: Kyungmin Park 
> > Cc: Lyude 
> > Cc: Maarten Lankhorst 
> > Cc: stable at vger.kernel.org
> > Fixes: 44d1240d006c ("drm: add generic zpos property")
> > Signed-off-by: Ville Syrjälä 
> 
> Seems a bit fragile, and then drivers still need to not overshot when
> they do zpos (which we want eventually in i915 too).

The only platform where we can do it is pre-g4x, and vlv/chv. And I'm
thinking I can do a better job of it in the driver.

> I think the
> proper way is to keep track of a per-plane zpos changed (or compute
> that ad-hoc, we have both states). And only grab more planes if a zpos
> value changed.

Doesn't work with normalized zpos. The plane's actual zpos may be
unchanged even if the normalized zpos changes.

> 
> That would fix the issue at the source, also work for us in the
> future, and it should be contained to just the helper function itself.
> Win all around ;-)
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Daniel Vetter]

On Mon, Oct 10, 2016 at 3:32 PM, Ville Syrjälä
 wrote:
> On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
>>  wrote:
>> >> I think the
>> >> proper way is to keep track of a per-plane zpos changed (or compute
>> >> that ad-hoc, we have both states). And only grab more planes if a zpos
>> >> value changed.
>> >
>> > Doesn't work with normalized zpos. The plane's actual zpos may be
>> > unchanged even if the normalized zpos changes.
>>
>> Well I meant to do a first loop to check for any zpos changes, and
>> only then add all the planes. If no one touched zpos, then also no
>> normalized zpos can change. I think at least ... Or what am I missing?
>
> Enabling planes can change zpos. Which is what's currently causing all
> the planes to be added to the state every time the cursor is
> enabled/disabled on i915. Which isn't nice.
>
> And anyway adding all the planes to the state when some zpos change
> happens is entirely pointless on i915. There's no need to run through
> any of .check_plane() hooks in this case. The only thing we need to
> do is rewrite the sprite control registers (+ base addresses of course
> to arm the update). So we could just add the sprite planes to state
> after the .check_plane() stuff has been done so that we'll just get the
> .commit_plane(). So knowing somehting about the hardware allows us to
> do a much better job of this.

Ok, I buy it ;-)

So we only need this if we have a driver that's using
plane_state->normalized_zpos. Having all combinatorials of
atomic_check_with_featureA_featureB will get ugly. I think it'd be
better to just split it out and dump it only into drivers's
atomic_check that need it. Plus add a very big warning to
drm_plane_state->normalized_zpos that without calling that helper it
will be invalid. Bit more copypaste, but I think that's actually good
(since we don't want to support all combinatorial variations with
pre-made helpers imo).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 2/2] drm/etnaviv: block 64K of address space behind each cmdstream

[Lucas Stach]

To make sure we don't place anything there which might confuse
the FE prefetcher. This gets rid of another case of FE MMU faults
when the address space gets crowded before triggering the reaper.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index d3796ed8d8c5..169ac96e8f08 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -330,7 +330,8 @@ u32 etnaviv_iommu_get_cmdbuf_va(struct etnaviv_gpu *gpu,
return (u32)buf->vram_node.start;

mutex_lock(>lock);
-   ret = etnaviv_iommu_find_iova(mmu, >vram_node, buf->size);
+   ret = etnaviv_iommu_find_iova(mmu, >vram_node,
+ buf->size + SZ_64K);
if (ret < 0) {
mutex_unlock(>lock);
return 0;
-- 
2.9.3

[PATCH 1/2] drm/etnaviv: ensure write caches are flushed at end of user cmdstream

[Lucas Stach]

If the GPU is done with one user command stream the buffers referenced
by this command stream may go away and get unmapped from the MMU. If
the write caches are still dirty at this point later evictions will run
into MMU faults, killing the GPU.

Make sure the write caches are flushed before signaling completion
of the user command stream.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index cb86c7e5495c..d9230132dfbc 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -329,20 +329,34 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
unsigned int event,
/*
 * Append a LINK to the submitted command buffer to return to
 * the ring buffer.  return_target is the ring target address.
-* We need three dwords: event, wait, link.
+* We need at most 7 dwords in the return target: 2 cache flush +
+* 2 semaphore stall + 1 event + 1 wait + 1 link.
 */
-   return_dwords = 3;
+   return_dwords = 7;
return_target = etnaviv_buffer_reserve(gpu, buffer, return_dwords);
CMD_LINK(cmdbuf, return_dwords, return_target);

/*
-* Append event, wait and link pointing back to the wait
-* command to the ring buffer.
+* Append a cache flush, stall, event, wait and link pointing back to
+* the wait command to the ring buffer.
 */
+   if (gpu->exec_state == ETNA_PIPE_2D) {
+   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_CACHE,
+  VIVS_GL_FLUSH_CACHE_PE2D);
+   } else {
+   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_CACHE,
+  VIVS_GL_FLUSH_CACHE_DEPTH |
+  VIVS_GL_FLUSH_CACHE_COLOR);
+   CMD_LOAD_STATE(buffer, VIVS_TS_FLUSH_CACHE,
+  VIVS_TS_FLUSH_CACHE_FLUSH);
+   }
+   CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+   CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
CMD_LOAD_STATE(buffer, VIVS_GL_EVENT, VIVS_GL_EVENT_EVENT_ID(event) |
   VIVS_GL_EVENT_FROM_PE);
CMD_WAIT(buffer);
-   CMD_LINK(buffer, 2, return_target + 8);
+   CMD_LINK(buffer, 2, etnaviv_iommu_get_cmdbuf_va(gpu, buffer) +
+   buffer->user_size - 4);

if (drm_debug & DRM_UT_DRIVER)
pr_info("stream link to 0x%08x @ 0x%08x %p\n",
-- 
2.9.3

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i915 actually falls into this
category right now since we've not yet added zpos support).

Allow drivers more freedom by letting them deal with zpos
themselves instead of doing it in drm_atomic_helper_check_planes()
unconditionally. Easiest solution seems to be to move the call
up to drm_atomic_helper_check(). But as some drivers might want
to use that function without the zpos handling, let's provide
two variants: the normal one, and one that deals with zpos.

Cc: Marek Szyprowski 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: Laurent Pinchart 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Lyude 
Cc: Maarten Lankhorst 
Cc: stable at vger.kernel.org
Fixes: 44d1240d006c ("drm: add generic zpos property")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic_helper.c| 46 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  2 +-
 drivers/gpu/drm/sti/sti_drv.c  |  2 +-
 include/drm/drm_atomic_helper.h|  2 ++
 5 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c3f83476f996..cd19281cdefb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

-   ret = drm_atomic_normalize_zpos(dev, state);
-   if (ret)
-   return ret;
-
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;

@@ -673,6 +669,48 @@ int drm_atomic_helper_check(struct drm_device *dev,
 }
 EXPORT_SYMBOL(drm_atomic_helper_check);

+/**
+ * drm_atomic_helper_check_with_zpos - validate state object, dealing with zpos
+ * @dev: DRM device
+ * @state: the driver state object
+ *
+ * Check the state object to see if the requested state is physically possible.
+ * Only crtcs and planes have check callbacks, so for any additional (global)
+ * checking that a driver needs it can simply wrap that around this function.
+ * Drivers without such needs can directly use this as their ->atomic_check()
+ * callback.
+ *
+ * This just wraps the two parts of the state checking for planes and modeset
+ * state in the default order: First it calls 
drm_atomic_helper_check_modeset(),
+ * followed by drm_atomic_normalize_zpos(), and finally
+ * drm_atomic_helper_check_planes(). The assumption is that the
+ * ->atomic_check functions depend upon an updated adjusted_mode.clock to
+ * e.g. properly compute watermarks.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_atomic_helper_check_with_zpos(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
+   ret = drm_atomic_helper_check_planes(dev, state);
+   if (ret)
+   return ret;
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_with_zpos);
+
 static void
 disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
 {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 40ce841eb952..5c0930af01fa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
*fb, int index)
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
-   .atomic_check = drm_atomic_helper_check,
+   .atomic_check = drm_atomic_helper_check_with_zpos,
.atomic_commit = exynos_atomic_commit,
 };

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index bd9c3bb9252c..2cfd35f3f2f6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -231,7 +231,7 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_device *rcdu = dev->dev_private;
int ret;

-   ret = drm_atomic_helper_check(dev, state);
+   ret = drm_atomic_helper_check_with_zpos(dev, state);
if (ret < 0)
return ret;

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 

[Bug 98196] [amdgpu SI] "gpu fault detect" in Tomb Raider

[bugzilla-dae...@freedesktop.org]

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

Arek Ruśniak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Arek Ruśniak  ---
I've reported it twice.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/57604e2b/attachment.html>

[PATCH 02/11] drm/etnaviv: Remove manual call to reservation_object_test_signaled_rcu before wait

[Lucas Stach]

Am Mittwoch, den 05.10.2016, 21:45 +0530 schrieb Sumit Semwal:
> Hi Lucas,
> 
> On 23 September 2016 at 18:25, Daniel Vetter  wrote:
> > On Mon, Aug 29, 2016 at 08:08:25AM +0100, Chris Wilson wrote:
> >> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> >> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
> >> need to handle such conversion in the caller. The only challenge are
> >> those callers that wish to differentiate the error code between the
> >> nonblocking busy check and potentially blocking wait.
> >>
> >> Signed-off-by: Chris Wilson 
> >> Cc: Lucas Stach 
> >> Cc: Russell King 
> >> Cc: Christian Gmeiner 
> >
> > Reviewed-by: Daniel Vetter 
> >
> Could you please let me know if this is in your tree already, or would
> you like me to take it via drm-misc (in which case, an Acked-by would
> be fabulous!)
> 
I haven't picked it up yet. If you are going to take the series through
drm-misc feel free to add:

Acked-by: Lucas Stach 

Regards,
Lucas

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Daniel Vetter]

On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
 wrote:
>> I think the
>> proper way is to keep track of a per-plane zpos changed (or compute
>> that ad-hoc, we have both states). And only grab more planes if a zpos
>> value changed.
>
> Doesn't work with normalized zpos. The plane's actual zpos may be
> unchanged even if the normalized zpos changes.

Well I meant to do a first loop to check for any zpos changes, and
only then add all the planes. If no one touched zpos, then also no
normalized zpos can change. I think at least ... Or what am I missing?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 98197] [amdgpu SI] "gpu fault detect" in Tomb Raider

[bugzilla-dae...@freedesktop.org]

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

Christian König  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Christian König  ---


*** This bug has been marked as a duplicate of bug 98183 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/b6a0e6de/attachment-0001.html>

[Bug 98183] [amdgpu SI] "gpu fault detect" in Alien: Isolation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Christian König  ---
*** Bug 98197 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/1b038c82/attachment.html>

[Bug 98197] [amdgpu SI] "gpu fault detect" in Tomb Raider

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Arek Ruśniak  ---
Created attachment 127182
  --> https://bugs.freedesktop.org/attachment.cgi?id=127182=edit
kernel log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/d2364e66/attachment.html>

[Bug 98197] [amdgpu SI] "gpu fault detect" in Tomb Raider

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98197
   Summary: [amdgpu SI] "gpu fault detect" in Tomb Raider
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears in the menu, benchmark and gameplay as well but not
always. 
One of trigger I found in gameplay is compfire. 

Probably this problem doesn't performance impact, frame rate is the same as for
radeon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/c205e4bc/attachment.html>

[Bug 98196] [amdgpu SI] "gpu fault detect" in Tomb Raider

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98196
   Summary: [amdgpu SI] "gpu fault detect" in Tomb Raider
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127181
  --> https://bugs.freedesktop.org/attachment.cgi?id=127181=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears in the menu, benchmark and gameplay as well but not
always. 
One of trigger I found in gameplay is compfire. 

Probably this problem doesn't performance impact, frame rate is the same as for
radeon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/8a889c7d/attachment.html>

[PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support

[Archit Taneja]

On 10/10/2016 12:45 PM, Laurent Pinchart wrote:
> Hi Archit,
>
> On Monday 10 Oct 2016 11:05:10 Archit Taneja wrote:
>> On 10/07/2016 02:44 PM, Maxime Ripard wrote:
>>> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>
> [snip]
>
 If no one has any more objections within the next day, I'll pull in
 Maxime's v5 RGB to VGA bridge driver, and change the compatible to
 "dumb-vga-dac".
>>>
>>> That works for me. You'll probably want to update the Kconfig and file
>>> name to match though.
>>
>> Queued to drm-misc, with the changes suggested by you and Laurent.
>
> Those changes would have been worth a repost. I've had a look at the patch
> you've committed and it looks OK to me, so no harm done (the commit message is
> a bit inaccurate, but it's not the end of the world). Could you please make
> sure you repost patches in the future when you change them in non-trivial ways
> ?

Sorry about that. Will repost from now onwards if the changes are too
significant.

Archit

>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v10 0/3] Secure Memory Allocation Framework

[John Einar Reitan]

On Fri, Oct 07, 2016 at 10:42:17AM -0400, Rob Clark wrote:
> probably should keep the discussion on github (USAGE.md was updated a
> bit more and merged into https://github.com/cubanismo/allocator so
> look there for the latest)..
> 
> but briefly:
> 
> 1) my expectation is if the user is implementing some use-case, it
> knows what devices and APIs are involved, otherwise it wouldn't be
> able to pass a buffer to that device/API..

As I described at Linaro Connect late-connected devices could cause new
constrains to appear. I.e. some (additonal) HDMI connection or WiFi Display etc.
Including all the might-happen devices might lead to unoptimal buffers
just to be able to handle some rarely-happen events.

I guess the easy resolve here is for the user to do a reallocation with
the new constraints added and replace the buffer(s) in question, but
with a slight lag in enabling the new device.

John

[PATCH 3/3] drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12

[Liu Ying]

Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's
relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which
are the two YUV pixel formats we support only), otherwise, we are likely to
trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixel format is
probably not YU12 or YV12.

Link: https://bugs.freedesktop.org/show_bug.cgi?id=98150
Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Cc: stable at vger.kernel.org # 4.8
Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index e33110e..a691892 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -359,7 +359,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if ((ubo > 0xf8) || (vbo > 0xf8))
return -EINVAL;

-   if (old_fb) {
+   if (old_fb && old_fb->pixel_format == fb->pixel_format) {
old_ubo = drm_plane_state_to_ubo(old_state);
old_vbo = drm_plane_state_to_vbo(old_state);
if (ubo != old_ubo || vbo != old_vbo)
-- 
2.7.4

[PATCH 2/3] drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset

[Liu Ying]

We added active plane reconfiguration support by forcing a full modeset
operation.  So, looking at old_plane_state->fb to determine whether we need
to set u/v offset(aka, u/vbo for IPUv3) in ipu_plane_atomic_set_base()
or not is no more correct.  Instead, we should do that only when we don't
need modeset.

Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Cc: stable at vger.kernel.org # 4.8
Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 9ca5739..e33110e 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -103,8 +103,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
   (state->src_x >> 16) / 2 - eba;
 }

-static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane,
- struct drm_plane_state *old_state)
+static void ipu_plane_atomic_set_base(struct ipu_plane *ipu_plane)
 {
struct drm_plane *plane = _plane->base;
struct drm_plane_state *state = plane->state;
@@ -118,7 +117,7 @@ static void ipu_plane_atomic_set_base(struct ipu_plane 
*ipu_plane,
switch (fb->pixel_format) {
case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
-   if (old_state->fb)
+   if (!drm_atomic_crtc_needs_modeset(crtc_state))
break;

/*
@@ -397,7 +396,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
struct drm_crtc_state *crtc_state = state->crtc->state;

if (!crtc_state->mode_changed) {
-   ipu_plane_atomic_set_base(ipu_plane, old_state);
+   ipu_plane_atomic_set_base(ipu_plane);
return;
}

@@ -444,7 +443,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(ipu_plane->ipu_ch, state->fb->pitches[0]);
-   ipu_plane_atomic_set_base(ipu_plane, old_state);
+   ipu_plane_atomic_set_base(ipu_plane);
ipu_plane_enable(ipu_plane);
 }

-- 
2.7.4

[PATCH 1/3] drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset

[Liu Ying]

We added active plane reconfiguration support by forcing a full modeset
operation.  So, looking at old_plane_state->fb to determine whether we need to
switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base()
or not is no more correct.  Instead, we should do that only when we don't need
modeset, otherwise, we initialize the two EBA buffers with the buffer address.

Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Cc: stable at vger.kernel.org # 4.8
Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 29423e75..9ca5739 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -108,6 +108,7 @@ static void ipu_plane_atomic_set_base(struct ipu_plane 
*ipu_plane,
 {
struct drm_plane *plane = _plane->base;
struct drm_plane_state *state = plane->state;
+   struct drm_crtc_state *crtc_state = state->crtc->state;
struct drm_framebuffer *fb = state->fb;
unsigned long eba, ubo, vbo;
int active;
@@ -149,7 +150,7 @@ static void ipu_plane_atomic_set_base(struct ipu_plane 
*ipu_plane,
break;
}

-   if (old_state->fb) {
+   if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
-- 
2.7.4

[Bug 98183] [amdgpu SI] "gpu fault detect" in Alien: Isolation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Laurent carlier  ---
*** Bug 98193 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bcf3b2ca/attachment-0001.html>

[Bug 98193] [amdgpu SI] "gpu fault detect" in Talos of Principle (opengl)

[bugzilla-dae...@freedesktop.org]

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Laurent carlier  ---


*** This bug has been marked as a duplicate of bug 98183 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/dee597f8/attachment-0001.html>

[Bug 98193] [amdgpu SI] "gpu fault detect" in Talos of Principle (opengl)

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Arek Ruśniak  ---
...and this is never happened on vulkan (radv)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/8970703a/attachment.html>

[Bug 98189] [amdgpu SI] "gpu fault detect" in Left 4 Dead 2

[bugzilla-dae...@freedesktop.org]

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

Laurent carlier  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Laurent carlier  ---


*** This bug has been marked as a duplicate of bug 98183 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/47f457fb/attachment.html>

[Bug 98190] [amdgpu SI] "gpu fault detect" in Serious Sam 3

[bugzilla-dae...@freedesktop.org]

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

Laurent carlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Laurent carlier  ---


*** This bug has been marked as a duplicate of bug 98183 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/a0a23026/attachment.html>

[Bug 98183] [amdgpu SI] "gpu fault detect" in Alien: Isolation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Laurent carlier  ---
*** Bug 98190 has been marked as a duplicate of this bug. ***

--- Comment #3 from Laurent carlier  ---
*** Bug 98189 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/b8b6d44f/attachment.html>

[Bug 98186] [amdgpu SI] "gpu fault detect" in Half Life: Source

[bugzilla-dae...@freedesktop.org]

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

Laurent carlier  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Laurent carlier  ---


*** This bug has been marked as a duplicate of bug 98183 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/d5d64b27/attachment.html>

[Bug 98183] [amdgpu SI] "gpu fault detect" in Alien: Isolation

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Laurent carlier  ---
*** Bug 98186 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/2ca6a4b1/attachment-0001.html>

[PATCH] drm: Don't force all planes to be added to the state due to zpos

[Daniel Vetter]

On Mon, Oct 10, 2016 at 2:19 PM,   wrote:
> From: Ville Syrjälä 
>
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> updates to go through w/o throttling. Same holds for drivers
> that don't support zpos at all (i915 actually falls into this
> category right now since we've not yet added zpos support).
>
> Allow drivers more freedom by letting them deal with zpos
> themselves instead of doing it in drm_atomic_helper_check_planes()
> unconditionally. Easiest solution seems to be to move the call
> up to drm_atomic_helper_check(). But as some drivers might want
> to use that function without the zpos handling, let's provide
> two variants: the normal one, and one that deals with zpos.
>
> Cc: Marek Szyprowski 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Laurent Pinchart 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Lyude 
> Cc: Maarten Lankhorst 
> Cc: stable at vger.kernel.org
> Fixes: 44d1240d006c ("drm: add generic zpos property")
> Signed-off-by: Ville Syrjälä 

Seems a bit fragile, and then drivers still need to not overshot when
they do zpos (which we want eventually in i915 too). I think the
proper way is to keep track of a per-plane zpos changed (or compute
that ad-hoc, we have both states). And only grab more planes if a zpos
value changed.

That would fix the issue at the source, also work for us in the
future, and it should be contained to just the helper function itself.
Win all around ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 98193] [amdgpu SI] "gpu fault detect" in Talos of Principle (opengl)

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98193
   Summary: [amdgpu SI] "gpu fault detect" in Talos of Principle
(opengl)
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127180
  --> https://bugs.freedesktop.org/attachment.cgi?id=127180=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears everywhere and everytime: gameplay, loading all the time. 
This is log from loading game and benchmark (60s), i had to trim the log
because didn't fit :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/4f4cd686/attachment.html>

[PATCH v2] drm/panel: simple: Add support for AUO t215hvn01

[Sean Paul]

On Mon, Oct 10, 2016 at 2:35 PM, Haixia Shi  wrote:
> The AUO t215hvn01 is a 21.5" 1920x1080 panel.
>
> v2: fix alphabetical order
>
> Signed-off-by: Haixia Shi 
> Tested-by: Haixia Shi 
> Reviewed-by: Stéphane Marchesin 


Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 113db3c..54dbb98 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -555,6 +555,33 @@ static const struct panel_desc auo_b133htn01 = {
> },
>  };
>
> +static const struct drm_display_mode auo_t215hvn01_mode = {
> +   .clock = 148800,
> +   .hdisplay = 1920,
> +   .hsync_start = 1920 + 88,
> +   .hsync_end = 1920 + 88 + 44,
> +   .htotal = 1920 + 88 + 44 + 148,
> +   .vdisplay = 1080,
> +   .vsync_start = 1080 + 4,
> +   .vsync_end = 1080 + 4 + 5,
> +   .vtotal = 1080 + 4 + 5 + 36,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_desc auo_t215hvn01 = {
> +   .modes = _t215hvn01_mode,
> +   .num_modes = 1,
> +   .bpc = 8,
> +   .size = {
> +   .width = 430,
> +   .height = 270,
> +   },
> +   .delay = {
> +   .disable = 5,
> +   .unprepare = 1000,
> +   }
> +};
> +
>  static const struct drm_display_mode avic_tm070ddh03_mode = {
> .clock = 51200,
> .hdisplay = 1024,
> @@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "auo,b133xtn01",
> .data = _b133xtn01,
> }, {
> +   .compatible = "auo,t215hvn01.0",
> +   .data = _t215hvn01,
> +   }, {
> .compatible = "avic,tm070ddh03",
> .data = _tm070ddh03,
> }, {
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98190] [amdgpu SI] "gpu fault detect" in Serious Sam 3

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98190
   Summary: [amdgpu SI] "gpu fault detect" in Serious Sam 3
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127171
  --> https://bugs.freedesktop.org/attachment.cgi?id=127171=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears only when game is loading. Menu, loading levels,
gameplay(~15min) are ok.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/3c2b2770/attachment.html>

[Bug 98189] [amdgpu SI] "gpu fault detect" in Left 4 Dead 2

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98189
   Summary: [amdgpu SI] "gpu fault detect" in Left 4 Dead 2
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127170
  --> https://bugs.freedesktop.org/attachment.cgi?id=127170=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears everywhere and everytime: gameplay, loading all the time. 
This is log from loading game and less than 1min of gameplay :)

I don't see any performance regression.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bceb50dc/attachment.html>

[Bug 98186] [amdgpu SI] "gpu fault detect" in Half Life: Source

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98186
   Summary: [amdgpu SI] "gpu fault detect" in Half Life: Source
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127169
  --> https://bugs.freedesktop.org/attachment.cgi?id=127169=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears everywhere and everytime: gameplay, loading all the time. 
This is log from loading game and 2s of gameplay :)

I don't know if it's performance impact, probably not, works really fast.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/64369bf5/attachment-0001.html>

[PATCH v11 2/4] drm: Add API for capturing frame CRCs

[Emil Velikov]

On 6 October 2016 at 16:21, Tomeu Vizoso  wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
>
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
>
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
>
> v10:
> - Don't let debugfs failures interrupt CRTC registration (Emil
>   Velikov)
>
> v11:
> - Remove extra brace that broke compilation. Sorry!
>
> Signed-off-by: Tomeu Vizoso 

Reviewed-by: Emil Velikov 

Emil

[Bug 98183] [amdgpu SI] "gpu fault detect" in Alien: Isolation

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 98183
   Summary: [amdgpu SI] "gpu fault detect" in Alien: Isolation
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: arek.rusi at gmail.com

Created attachment 127168
  --> https://bugs.freedesktop.org/attachment.cgi?id=127168=edit
kernel log

Hi, 
kernel - drm-next-4.9-wip + drm/amdgpu: disable CRTCs before teardown
mesa,libdrm,amdgpu,llvm form git/svn
This is not regression, this happened since dpm is workable. 

GPU/VM faults appears during loading game only, menu/gameplay(20min) looks
normal. 
Probably this problem doesn't performance impact, frame rate is the same as for
radeon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bdfe5968/attachment.html>

[PATCH v11 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adding Benjamin Gaignard to CC in case he wants to comment on the
usage of the registration functions, as suggested by Daniel Vetter.

Regards,

Tomeu

On 6 October 2016 at 17:21, Tomeu Vizoso  wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
>
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
>
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
>
> v10:
> - Don't let debugfs failures interrupt CRTC registration (Emil
>   Velikov)
>
> v11:
> - Remove extra brace that broke compilation. Sorry!
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
>  Documentation/gpu/drm-uapi.rst|   6 +
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
> ++
>  drivers/gpu/drm/drm_internal.h|  16 ++
>  include/drm/drm_crtc.h|  41 +
>  include/drm/drm_debugfs_crc.h |  73 
>  8 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>  create mode 100644 include/drm/drm_debugfs_crc.h
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 1ba301cebe16..de3ac9f90f8f 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 25c720454017..74579d2e796e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> drm_scatter.o drm_pci.o \
> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> -   drm_info.o drm_debugfs.o drm_encoder_slave.o \
> +   drm_info.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> drm_rect.o drm_vma_manager.o drm_flip_work.o \
> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 2d7bedf28647..60403bf7a4ff 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,7 +40,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -122,6 +122,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
> int ret = 0;
>
> drm_for_each_crtc(crtc, dev) {
> +   

[Bug 98166] [vulkan, radv] make install regenerates radv_timestamp.h and rebuilds radv_device.lo

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Emil Velikov  ---
(In reply to Vedran Miletić from comment #0)
> Would be much if it was regenerated/rebuilt only on make and not on make
> install.

much better ? Indeed it would.

Sadly given the constrains I cannot think of anything nicer I'm afraid. The
gist is that the file must be updated on incremental builds and we cannot
ensure that not files are changed/rebuild between build and install stage. For
the experiments and a lot more context check the git history, and mailing list,
for anv_timestamp.h.

One 'workaround' is to use SOURCE_DATE_EPOCH as described here [1].
[1] https://reproducible-builds.org/specs/source-date-epoch/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/bbae90ab/attachment.html>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Takashi Iwai]

On Mon, 10 Oct 2016 10:28:31 +0200,
Jani Nikula wrote:
> 
> On Mon, 10 Oct 2016, "Sun, Jing A"  wrote:
> > Dear Maintainers,
> >
> > Please kindly review my patch as below. It's based on the mainline branch.
> >
> > From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 2001
> > From: Jing SUN 
> > Date: Mon, 10 Oct 2016 14:06:54 +0800
> > Subject: [PATCH 1/1] drm: change DRM_MIPI_DSI module type from "bool" to
> >  "tristate".
> >
> > A lot of drm driver modules, which are designed
> > to be loadable, select DRM_MIPI_DSI, while that
> > being "bool" prevents those from getting reloaded.
> 
> You're missing some lists and people from distribution, added now.
> 
> See the discussion starting at [1]. I don't know if anything has
> happened since then. Takashi?

Unfortunately, nothing seems to have happened since my last patch due
to little interest.  I'd be glad if the patch is revived.

(BTW, I'm traveling in these two weeks, so the further reply will be
 delayed.)


thanks,

Takashi


> 
> BR,
> Jani.
> 
> 
> [1] http://lkml.kernel.org/r/s5hh9bhvj7j.wl-tiwai at suse.de
> 
> 
> >
> > Signed-off-by: Jing SUN 
> > ---
> >  drivers/gpu/drm/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index fc35731..67668a0 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -22,7 +22,7 @@ menuconfig DRM
> >   (/dev/agpgart) support if it is available for your platform.
> >  
> >  config DRM_MIPI_DSI
> > -   bool
> > +   tristate
> > depends on DRM
> >  
> >  config DRM_DP_AUX_CHARDEV
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> 

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from nucrap at hotmail.com ---
Thanks, would you be so kind and compose me a patch with all commits that I
need and that I can apply on top of the kernel v4.8 sources (which I am
currently using)? So that I can test if the issue is fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/b880cdd4/attachment.html>

[PATCH v2] drm/panel: simple: Add support for AUO t215hvn01

[Haixia Shi]

The AUO t215hvn01 is a 21.5" 1920x1080 panel.

v2: fix alphabetical order

Signed-off-by: Haixia Shi 
Tested-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..54dbb98 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -555,6 +555,33 @@ static const struct panel_desc auo_b133htn01 = {
},
 };

+static const struct drm_display_mode auo_t215hvn01_mode = {
+   .clock = 148800,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 88,
+   .hsync_end = 1920 + 88 + 44,
+   .htotal = 1920 + 88 + 44 + 148,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 4,
+   .vsync_end = 1080 + 4 + 5,
+   .vtotal = 1080 + 4 + 5 + 36,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_t215hvn01 = {
+   .modes = _t215hvn01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 430,
+   .height = 270,
+   },
+   .delay = {
+   .disable = 5,
+   .unprepare = 1000,
+   }
+};
+
 static const struct drm_display_mode avic_tm070ddh03_mode = {
.clock = 51200,
.hdisplay = 1024,
@@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
+   .compatible = "auo,t215hvn01.0",
+   .data = _t215hvn01,
+   }, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
-- 
2.8.0.rc3.226.g39d4020

[PATCH] CHROMIUM: drm/panel: simple: Add support for AUO t215hvn01

[Haixia Shi]

The AUO t215hvn01 is a 21.5" 1920x1080 panel.

Signed-off-by: Haixia Shi 
Reviewed-on: https://chromium-review.googlesource.com/394328
Tested-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
---
 drivers/gpu/drm/panel/panel-simple.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c..bab1951 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,33 @@ static const struct panel_desc avic_tm070ddh03 = {
},
 };

+static const struct drm_display_mode auo_t215hvn01_mode = {
+   .clock = 148800,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 88,
+   .hsync_end = 1920 + 88 + 44,
+   .htotal = 1920 + 88 + 44 + 148,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 4,
+   .vsync_end = 1080 + 4 + 5,
+   .vtotal = 1080 + 4 + 5 + 36,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc auo_t215hvn01 = {
+   .modes = _t215hvn01_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 430,
+   .height = 270,
+   },
+   .delay = {
+   .disable = 5,
+   .unprepare = 1000,
+   }
+};
+
 static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1575,6 +1602,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = _b133xtn01,
}, {
+   .compatible = "auo,t215hvn01.0",
+   .data = _t215hvn01,
+   }, {
.compatible = "avic,tm070ddh03",
.data = _tm070ddh03,
}, {
-- 
2.8.0.rc3.226.g39d4020

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

[Jani Nikula]

On Mon, 10 Oct 2016, "Sun, Jing A"  wrote:
> Dear Maintainers,
>
> Please kindly review my patch as below. It's based on the mainline branch.
>
> From b401009f79883ac5e9d41525c9d54b800ece2e22 Mon Sep 17 00:00:00 2001
> From: Jing SUN 
> Date: Mon, 10 Oct 2016 14:06:54 +0800
> Subject: [PATCH 1/1] drm: change DRM_MIPI_DSI module type from "bool" to
>  "tristate".
>
> A lot of drm driver modules, which are designed
> to be loadable, select DRM_MIPI_DSI, while that
> being "bool" prevents those from getting reloaded.

You're missing some lists and people from distribution, added now.

See the discussion starting at [1]. I don't know if anything has
happened since then. Takashi?

BR,
Jani.


[1] http://lkml.kernel.org/r/s5hh9bhvj7j.wl-tiwai at suse.de


>
> Signed-off-by: Jing SUN 
> ---
>  drivers/gpu/drm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index fc35731..67668a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -22,7 +22,7 @@ menuconfig DRM
> (/dev/agpgart) support if it is available for your platform.
>  
>  config DRM_MIPI_DSI
> - bool
> + tristate
>   depends on DRM
>  
>  config DRM_DP_AUX_CHARDEV

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/amdgpu: use .early_unregister hook to remove DP AUX i2c

[Daniel Vetter]

On Sun, Oct 09, 2016 at 08:28:19PM +0300, Grazvydas Ignotas wrote:
> When DisplayPort AUX channel i2c adapter is registered, drm_connector's
> kdev member is used as a parent, so we get sysfs structure like:
>   /drm/card1/card1-DP-2/i2c-12
> Because of that, there is a problem when drm core (and not the driver)
> calls drm_connector_unregister(), it removes parent sysfs entries
> ('card1-DP-2' in our example) while the i2c adapter is still registered.
> Later we get a WARN when we try to unregister the i2c adapter:
> 
>   WARNING: CPU: 3 PID: 1374 at fs/sysfs/group.c:243 
> sysfs_remove_group+0x14c/0x150
>   sysfs group 82911e40 not found for kobject 'i2c-12'
> 
> To fix it, we can use the .early_unregister hook to unregister the i2c
> adapter before drm_connector's sysfs is torn down.
> 
> Signed-off-by: Grazvydas Ignotas 

would be nice to also split things up on the register side, for symmetry.
Just as one small step towards demidlayering amdgpu.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 76a7830..09b76a8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -765,7 +765,7 @@ amdgpu_connector_lvds_detect(struct drm_connector 
> *connector, bool force)
>   return ret;
>  }
>  
> -static void amdgpu_connector_destroy(struct drm_connector *connector)
> +static void amdgpu_connector_unregister(struct drm_connector *connector)
>  {
>   struct amdgpu_connector *amdgpu_connector = 
> to_amdgpu_connector(connector);
>  
> @@ -773,6 +773,12 @@ static void amdgpu_connector_destroy(struct 
> drm_connector *connector)
>   drm_dp_aux_unregister(_connector->ddc_bus->aux);
>   amdgpu_connector->ddc_bus->has_aux = false;
>   }
> +}
> +
> +static void amdgpu_connector_destroy(struct drm_connector *connector)
> +{
> + struct amdgpu_connector *amdgpu_connector = 
> to_amdgpu_connector(connector);
> +
>   amdgpu_connector_free_edid(connector);
>   kfree(amdgpu_connector->con_priv);
>   drm_connector_unregister(connector);
> @@ -826,6 +832,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_lvds_funcs = {
>   .dpms = drm_helper_connector_dpms,
>   .detect = amdgpu_connector_lvds_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
> + .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .set_property = amdgpu_connector_set_lcd_property,
>  };
> @@ -936,6 +943,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_vga_funcs = {
>   .dpms = drm_helper_connector_dpms,
>   .detect = amdgpu_connector_vga_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
> + .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .set_property = amdgpu_connector_set_property,
>  };
> @@ -1203,6 +1211,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_dvi_funcs = {
>   .detect = amdgpu_connector_dvi_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .set_property = amdgpu_connector_set_property,
> + .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .force = amdgpu_connector_dvi_force,
>  };
> @@ -1493,6 +1502,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_dp_funcs = {
>   .detect = amdgpu_connector_dp_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .set_property = amdgpu_connector_set_property,
> + .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .force = amdgpu_connector_dvi_force,
>  };
> @@ -1502,6 +1512,7 @@ static const struct drm_connector_funcs 
> amdgpu_connector_edp_funcs = {
>   .detect = amdgpu_connector_dp_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .set_property = amdgpu_connector_set_lcd_property,
> + .early_unregister = amdgpu_connector_unregister,
>   .destroy = amdgpu_connector_destroy,
>   .force = amdgpu_connector_dvi_force,
>  };
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: use the right function name in documentation

[Daniel Vetter]

On Sun, Oct 09, 2016 at 08:07:00PM +0300, Grazvydas Ignotas wrote:
> There is no late_unregister(), it looks like the comment meant
> late_register(). Also fix a typo while at it.
> 
> Signed-off-by: Grazvydas Ignotas 

Applied to drm-misc, thanks.
-Daniel

> ---
>  include/drm/drm_connector.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 51a15de..43c5cd7 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -345,7 +345,7 @@ struct drm_connector_funcs {
>*
>* This optional hook should be used to unregister the additional
>* userspace interfaces attached to the connector from
> -  * late_unregister(). It is called from drm_connector_unregister(),
> +  * late_register(). It is called from drm_connector_unregister(),
>* early in the driver unload sequence to disable userspace access
>* before data structures are torndown.
>*/
> @@ -365,7 +365,7 @@ struct drm_connector_funcs {
>* @atomic_duplicate_state:
>*
>* Duplicate the current atomic state for this connector and return it.
> -  * The core and helpers gurantee that any atomic state duplicated with
> +  * The core and helpers guarantee that any atomic state duplicated with
>* this hook and still owned by the caller (i.e. not transferred to the
>* driver by calling ->atomic_commit() from struct
>* _mode_config_funcs) will be cleaned up by calling the
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: Release resources with a safer function

[Daniel Vetter]

On Fri, Oct 07, 2016 at 09:27:41AM +0200, Christophe JAILLET wrote:
> We should use 'ida_simple_remove()' instead of 'ida_remove()' when freeing
> resources allocated with 'ida_simple_get()'.
> 
> Signed-off-by: Christophe JAILLET 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_connector.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2e7430283043..2db7fb510b6c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -341,11 +341,11 @@ void drm_connector_cleanup(struct drm_connector 
> *connector)
>   list_for_each_entry_safe(mode, t, >modes, head)
>   drm_mode_remove(connector, mode);
>  
> - ida_remove(_connector_enum_list[connector->connector_type].ida,
> -connector->connector_type_id);
> + 
> ida_simple_remove(_connector_enum_list[connector->connector_type].ida,
> +   connector->connector_type_id);
>  
> - ida_remove(>mode_config.connector_ida,
> -connector->index);
> + ida_simple_remove(>mode_config.connector_ida,
> +   connector->index);
>  
>   kfree(connector->display_info.bus_formats);
>   drm_mode_object_unregister(dev, >base);
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support

[Archit Taneja]

On 10/07/2016 02:44 PM, Maxime Ripard wrote:
> On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:
>>
>>
>> On 10/07/2016 02:34 AM, Laurent Pinchart wrote:
>>> Hi Sean,
>>>
>>> On Thursday 06 Oct 2016 15:53:28 Sean Paul wrote:
 On Thu, Oct 6, 2016 at 1:27 PM, Laurent Pinchart wrote:
> On Thursday 06 Oct 2016 17:09:57 Archit Taneja wrote:
>> On 10/06/2016 12:51 PM, Maxime Ripard wrote:
>>> On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
 On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> Some boards have an entirely passive RGB to VGA bridge, based on
> either DACs or resistor ladders.
>
> Those might or might not have an i2c bus routed to the VGA connector
> in order to access the screen EDIDs.
>
> Add a bridge that doesn't do anything but expose the modes available
> on the screen, either based on the EDIDs if available, or based on
> the XGA standards.
>
> Acked-by: Rob Herring 
> Signed-off-by: Maxime Ripard 
> ---
> .../bindings/display/bridge/rgb-to-vga-bridge.txt  |  48 +
> drivers/gpu/drm/bridge/Kconfig |   7 +
> drivers/gpu/drm/bridge/Makefile|   1 +
> drivers/gpu/drm/bridge/rgb-to-vga.c| 229 +
> 4 files changed, 285 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.tx
> t
> create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> txt
> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> txt
> new file mode 100644
> index ..a8375bc1f9cb
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.
> tx
> t @@ -0,0 +1,48 @@
> +Dumb RGB to VGA bridge
> +--
> +
> +This binding is aimed for dumb RGB to VGA bridges that do not
> require
> +any configuration.
> +
> +Required properties:
> +
> +- compatible: Must be "rgb-to-vga-bridge"

 I'd talked to Laurent on IRC if he's okay with this. And I guess you
 to had discussed it during XDC too. He's suggested that it'd be better
 to have the compatible string as "simple-vga-dac".
>>>
>>> I just wished this bikeshedding had taken place publicly and be
>>> actually part of that discussion, but yeah, ok.
>>
>> Sorry about that. I'd pinged him for an Ack, the discussion went
>> more than that :)
>>
 Some of the reasons behind having this:

 - We don't need to specify "rgb" in the compatible string since most
 simple VGA DACs can only work with an RGB input.
>>>
>>> Ok.
>>>
 - Also, with "dac" specified in the string, we don't need to
 specifically mention "bridge" in the string. Also, bridge is a drm
 specific term.

 - "simple" is considered because it's an unconfigurable bridge, and it
 might be misleading for other VGA DACs to not use "vga-dac".
>>>
>>> All those "simple" bindings are just the biggest lie we ever
>>> told. It's simple when you introduce it, and then grows into something
>>> much more complicated than a non-simple implementation.
>>
>> "simple" here is supposed to mean that it's an unconfigurable RGB to
>> VGA DAC. This isn't supposed to follow the simple-panel model, where
>> you add the "simple-panel" string in the compatible node, along with
>> you chip specific compatible string.
>
> I agree with Maxime, I don't like the word "simple". My preference would
> be "vga-dac" for a lack of a better qualifier than "simple" to describe
> the fact that the device requires no configuration. My only concern with
> "vga-dac" is that we would restrict usage of that compatible string for a
> subset of VGA DACs, with more complex devices not being compatible with
> "vga-dac" even though they are VGA DACs. That's a problem I can live with
> though.

 While we're bikeshedding (feel free to ignore my input on this), I
 think Maxime's initial "dumb" qualifier was better than "simple".
>>>
>>> I think I agree.
>>>
 I think "passive" also gets the point across better than "simple", which
 we've already established as something else in drm.
>>>
>>> To my electrical engineer's ear, passive refers to a component or 
>>> combination
>>> of components that is not capable of power gain. The resistors ladder VGA 
>>> DAC
>>> that Maxime is trying to support is a passive system, but the ADV7123 VGA 
>>> DAC
>>> that equally requires no 

gma500: color distortion on framebuffer console unbind

[Baruch Siach]

Hi Patrik,

I am using the gma500 driver of the latest stable kernel, 4.8.1. My hardware
is Atom N2600 processor integrated graphics controller, PCI PID: 0x0be1. 
Output is LVDS. The system starts with framebuffer console enabled. Later in 
the boot process I unbind the console with the following command:

  echo 0 > /sys/class/vtconsole/vtcon1/bind

Immediately as the console is unbound some colors on the screen appear
distorted. The links below show the output of 'fb-test'
(https://github.com/prpplague/fb-test-app) before and after unbind.

  http://filebin.ca/2xxwlwtBBzBN/display-good.jpg
  http://filebin.ca/2xxxTyIboJnR/display-bad.jpg

Suggestions are welcome.

Thanks,
baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[PATCH v3] drm: tilcdc: add a workaround for failed clk_set_rate()

[Jyri Sarha]

On 09/29/16 19:43, Bartosz Golaszewski wrote:
> Some architectures don't use the common clock framework and don't
> implement all the clk interfaces for every clock. This is the case
> for da850-lcdk where clk_set_rate() only works for PLL0 and PLL1.
> 
> Trying to set the clock rate for the LCDC clock results in -EINVAL
> being returned.
> 
> As a workaround for that: if the call to clk_set_rate() fails, fall
> back to adjusting the clock divider instead. Proper divider value is
> calculated by dividing the current clock rate by the required pixel
> clock rate in HZ.
> 
> This code is based on a hack initially developed internally for
> baylibre by Karl Beldan .
> 
> Tested with a da850-lcdk with an LCD display connected over VGA.
> 
> Signed-off-by: Bartosz Golaszewski 

Forgot to mention, but I've picked this up too, but I won't send a pull
request for 4.9 anymore.

BR,
Jyri

> ---
> v1 -> v2:
> - rebased on top of current drm-next
> - removed unnecessary error messages
> - removed an extra newline
> - added a warning if the effective pixel clock rate differs much from
>   the requested rate
> 
> v2 -> v3:
> - removed WARN_ONCE() in favor of dev_warn()
> - added the real and calculated clock rates to the warning message
> - tweaked the variable names
> - used a local variable to remove redundant 'crtc->mode.clock * 1000'
> 
> Retested with
> 
>   modetest -M tilcdc -s 26:800x600 at RG16
>   modetest -M tilcdc -s 26:1024x768 at RG16
> 
> using some additional work-in-progress changes on top of this patch.
> 
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 57 
> 
>  1 file changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 52ebe8f..87cfde9 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -320,23 +320,68 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc 
> *crtc,
>   return true;
>  }
>  
> +/*
> + * Calculate the percentage difference between the requested pixel clock rate
> + * and the effective rate resulting from calculating the clock divider value.
> + */
> +static unsigned int tilcdc_pclk_diff(unsigned long rate,
> +  unsigned long real_rate)
> +{
> + int r = rate / 100, rr = real_rate / 100;
> +
> + return (unsigned int)(abs(((rr - r) * 100) / r));
> +}
> +
>  static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct tilcdc_drm_private *priv = dev->dev_private;
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> - const unsigned clkdiv = 2; /* using a fixed divider of 2 */
> + unsigned long clk_rate, real_rate, req_rate;
> + unsigned int clkdiv;
>   int ret;
>  
> + clkdiv = 2; /* first try using a standard divider of 2 */
> +
>   /* mode.clock is in KHz, set_rate wants parameter in Hz */
> - ret = clk_set_rate(priv->clk, crtc->mode.clock * 1000 * clkdiv);
> + req_rate = crtc->mode.clock * 1000;
> +
> + ret = clk_set_rate(priv->clk, req_rate * clkdiv);
> + clk_rate = clk_get_rate(priv->clk);
>   if (ret < 0) {
> - dev_err(dev->dev, "failed to set display clock rate to: %d\n",
> - crtc->mode.clock);
> - return;
> + /*
> +  * If we fail to set the clock rate (some architectures don't
> +  * use the common clock framework yet and may not implement
> +  * all the clk API calls for every clock), try the next best
> +  * thing: adjusting the clock divider, unless clk_get_rate()
> +  * failed as well.
> +  */
> + if (!clk_rate) {
> + /* Nothing more we can do. Just bail out. */
> + dev_err(dev->dev,
> + "failed to set the pixel clock - unable to read 
> current lcdc clock rate\n");
> + return;
> + }
> +
> + clkdiv = DIV_ROUND_CLOSEST(clk_rate, req_rate);
> +
> + /*
> +  * Emit a warning if the real clock rate resulting from the
> +  * calculated divider differs much from the requested rate.
> +  *
> +  * 5% is an arbitrary value - LCDs are usually quite tolerant
> +  * about pixel clock rates.
> +  */
> + real_rate = clkdiv * req_rate;
> +
> + if (tilcdc_pclk_diff(clk_rate, real_rate) > 5) {
> + dev_warn(dev->dev,
> +  "effective pixel clock rate (%luHz) differs 
> from the calculated rate (%luHz)\n",
> +  clk_rate, real_rate);
> + }
>   }
>  
> - tilcdc_crtc->lcd_fck_rate = clk_get_rate(priv->clk);
> + tilcdc_crtc->lcd_fck_rate = clk_rate;
>  
>   DBG("lcd_clk=%u, mode clock=%d, div=%u",
>   

[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Ernst Sjöstrand  ---
I have never been able to reproduce the problem with self-compiled 4.8-rc8 from
that workspace so I think my local builds are working at least.
drm/amd/amdgpu: enable clockgating only after late init
sounded like it could be similar to my problem but it didn't help.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/02c8d32d/attachment.html>

[PATCH] drm/vc4: Fix memory leak of the CRTC state.

[Eric Anholt]

The underscores variant frees the pointers inside, while the
no-underscores variant calls underscores and then frees the struct.

Signed-off-by: Eric Anholt 
Fixes: d8dbf44f13b9 ("drm/vc4: Make the CRTCs cooperate on allocating display 
lists.")
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 7f08d681a74b..d544ff9b0d46 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -832,7 +832,7 @@ static void vc4_crtc_destroy_state(struct drm_crtc *crtc,

}

-   __drm_atomic_helper_crtc_destroy_state(state);
+   drm_atomic_helper_crtc_destroy_state(crtc, state);
 }

 static const struct drm_crtc_funcs vc4_crtc_funcs = {
-- 
2.9.3

[PATCH v6 1/5] drm/sun4i: rgb: Remove the bridge enable/disable functions

[Maxime Ripard]

On Thu, Oct 06, 2016 at 03:43:21PM -0400, Sean Paul wrote:
> On Thu, Oct 6, 2016 at 3:57 AM, Maxime Ripard
>  wrote:
> > The atomic helpers already call the drm_bridge_enable on our behalf,
> > there's no need to do it a second time.
> >
> > Reported-by: Sean Paul 
> 
> Reviewed-by: Sean Paul 

Thanks, I just queued it in my fixes for 4.9.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/65bef188/attachment.sig>

[PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support

[Laurent Pinchart]

Hi Archit,

On Monday 10 Oct 2016 11:05:10 Archit Taneja wrote:
> On 10/07/2016 02:44 PM, Maxime Ripard wrote:
> > On Fri, Oct 07, 2016 at 10:27:31AM +0530, Archit Taneja wrote:

[snip]

> >> If no one has any more objections within the next day, I'll pull in
> >> Maxime's v5 RGB to VGA bridge driver, and change the compatible to
> >> "dumb-vga-dac".
> > 
> > That works for me. You'll probably want to update the Kconfig and file
> > name to match though.
> 
> Queued to drm-misc, with the changes suggested by you and Laurent.

Those changes would have been worth a repost. I've had a look at the patch 
you've committed and it looks OK to me, so no harm done (the commit message is 
a bit inaccurate, but it's not the end of the world). Could you please make 
sure you repost patches in the future when you change them in non-trivial ways 
?

-- 
Regards,

Laurent Pinchart

[PATCH v3] drm: tilcdc: add a da850-specific compatible string

[Jyri Sarha]

On 10/03/16 18:45, Bartosz Golaszewski wrote:
> Due to some potential tweaks for the da850 LCDC (for example: the
> required memory bandwith settings) we need a separate compatible
> for the IP present on the da850 boards.
> 
> Suggested-by: Sekhar Nori 
> Signed-off-by: Bartosz Golaszewski 

Thanks,
I pick this up, but I won't send it for 4.9 any more. The LCDC rev1
support is not yet complete in 4.9 anyway.

BR,
Jyri

> ---
> v1 -> v2:
> - added the new compatible to the bindings documentation
> 
> v2 -> v3:
> - made the documentation more detailed
> 
>  Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 6 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
> b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> index a83abd7..6fddb4f 100644
> --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> @@ -1,7 +1,9 @@
>  Device-Tree bindings for tilcdc DRM driver
>  
>  Required properties:
> - - compatible: value should be "ti,am33xx-tilcdc".
> + - compatible: value should be one of the following:
> +- "ti,am33xx-tilcdc" for AM335x based boards
> +- "ti,da850-tilcdc" for DA850/AM18x/OMAP-L138 based boards
>   - interrupts: the interrupt number
>   - reg: base address and size of the LCDC device
>  
> @@ -51,7 +53,7 @@ Optional nodes:
>  Example:
>  
>   fb: fb at 4830e000 {
> - compatible = "ti,am33xx-tilcdc";
> + compatible = "ti,am33xx-tilcdc", "ti,da850-tilcdc";
>   reg = <0x4830e000 0x1000>;
>   interrupt-parent = <>;
>   interrupts = <36>;
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index a694977..231f2c7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -723,6 +723,7 @@ static int tilcdc_pdev_remove(struct platform_device 
> *pdev)
>  
>  static struct of_device_id tilcdc_of_match[] = {
>   { .compatible = "ti,am33xx-tilcdc", },
> + { .compatible = "ti,da850-tilcdc", },
>   { },
>  };
>  MODULE_DEVICE_TABLE(of, tilcdc_of_match);
> 

[PATCH 5/9] drm/sun4i: Add compatible strings for A31/A31s display pipelines

[Rob Herring]

On Fri, Oct 07, 2016 at 12:06:25AM +0800, Chen-Yu Tsai wrote:
> The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It
> also has new display enhancement blocks, such as the DRC (Dynamic Range
> Controller), the DEU (Display Enhancement Unit), and the CMU (Color
> Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels.
> 
> The A31s display pipeline is almost the same, just without MIPI DSI.
> Only the TCON seems to be different, due to the missing mux for MIPI
> DSI.
> 
> Add compatible strings for both of them.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +++
>  3 files changed, 8 insertions(+)

Acked-by: Rob Herring 

[PATCH 1/9] drm/sun4i: sun6i-drc: Support DRC on A31 and A31s

[Rob Herring]

On Fri, Oct 07, 2016 at 12:06:21AM +0800, Chen-Yu Tsai wrote:
> The A31 and A31s also have the DRC as part of the display pipeline.
> As we know virtually nothing about them, just add compatible strings
> for both SoCs to the stub driver.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
>  drivers/gpu/drm/sun4i/sun6i_drc.c | 2 ++
>  2 files changed, 4 insertions(+)

Acked-by: Rob Herring 

[PATCH v5 3/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

Signed-off-by: Andrzej Hajda 
---
v5:
  - added static version of sii8620_write_seq_static,
  - use lowercase for i2c_device_id
v4:
  - updated mhl.h location
v3:
  - modified driver description,
  - removed dummy bridge callbacks,
  - removed locking from driver remove function.
---
 drivers/gpu/drm/bridge/Kconfig   |7 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/sil-sii8620.c | 1563 ++
 drivers/gpu/drm/bridge/sil-sii8620.h | 1517 +
 4 files changed, 3088 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
 create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e67..e7fb179 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,13 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_SIL_SII8620
+   tristate "Silicon Image SII8620 HDMI/MHL bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Silicon Image SII8620 HDMI/MHL bridge chip driver.
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e..304cf9d 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
new file mode 100644
index 000..4be72c3
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -0,0 +1,1563 @@
+/*
+ * Silicon Image SiI8620 HDMI/MHL bridge driver
+ *
+ * Copyright (C) 2015, Samsung Electronics Co., Ltd.
+ * Andrzej Hajda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sil-sii8620.h"
+
+#define VAL_RX_HDMI_CTRL2_DEFVAL   VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
+
+enum sii8620_mode {
+   CM_DISCONNECTED,
+   CM_DISCOVERY,
+   CM_MHL1,
+   CM_MHL3,
+   CM_ECBUS_S
+};
+
+enum sii8620_sink_type {
+   SINK_NONE,
+   SINK_HDMI,
+   SINK_DVI
+};
+
+enum sii8620_mt_state {
+   MT_STATE_READY,
+   MT_STATE_BUSY,
+   MT_STATE_DONE
+};
+
+struct sii8620 {
+   struct drm_bridge bridge;
+   struct device *dev;
+   struct clk *clk_xtal;
+   struct gpio_desc *gpio_reset;
+   struct gpio_desc *gpio_int;
+   struct regulator_bulk_data supplies[2];
+   struct mutex lock; /* context lock, protects fields below */
+   int error;
+   enum sii8620_mode mode;
+   enum sii8620_sink_type sink_type;
+   u8 cbus_status;
+   u8 stat[MHL_DST_SIZE];
+   u8 xstat[MHL_XDS_SIZE];
+   u8 devcap[MHL_DCAP_SIZE];
+   u8 xdevcap[MHL_XDC_SIZE];
+   u8 avif[19];
+   struct edid *edid;
+   unsigned int gen2_write_burst:1;
+   enum sii8620_mt_state mt_state;
+   struct list_head mt_queue;
+};
+
+struct sii8620_mt_msg;
+
+typedef void (*sii8620_mt_msg_cb)(struct sii8620 *ctx,
+ struct sii8620_mt_msg *msg);
+
+struct sii8620_mt_msg {
+   struct list_head node;
+   u8 reg[4];
+   u8 ret;
+   sii8620_mt_msg_cb send;
+   sii8620_mt_msg_cb recv;
+};
+
+static const u8 sii8620_i2c_page[] = {
+   0x39, /* Main System */
+   0x3d, /* TDM and HSIC */
+   0x49, /* TMDS Receiver, MHL EDID */
+   0x4d, /* eMSC, HDCP, HSIC */
+   0x5d, /* MHL Spec */
+   0x64, /* MHL CBUS */
+   0x59, /* Hardware TPI (Transmitter Programming Interface) */
+   0x61, /* eCBUS-S, eCBUS-D */
+};
+
+static void sii8620_fetch_edid(struct sii8620 *ctx);
+static void sii8620_set_upstream_edid(struct sii8620 *ctx);
+static void sii8620_enable_hpd(struct sii8620 *ctx);
+static void sii8620_mhl_disconnected(struct sii8620 *ctx);
+
+static int sii8620_clear_error(struct sii8620 *ctx)
+{
+

[PATCH v4 3/3] drm/bridge: add Silicon Image SiI8620 driver

[Andrzej Hajda]

Hi Laurent,

Thanks for review.

On 07.10.2016 16:58, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Friday 07 Oct 2016 09:02:42 Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0.
>> It is controlled via I2C bus. Its interaction with other
>> devices in video pipeline is performed mainly on HW level.
>> The only interaction it does on device driver level is
>> filtering-out unsupported video modes, it exposes drm_bridge
>> interface to perform this operation.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> v4:
>>   - updated mhl.h location
>> v3:
>>   - modified driver description,
>>   - removed dummy bridge callbacks,
>>   - removed locking from driver remove function.
>> ---
>>  drivers/gpu/drm/bridge/Kconfig   |7 +
>>  drivers/gpu/drm/bridge/Makefile  |1 +
>>  drivers/gpu/drm/bridge/sil-sii8620.c | 1557 +++
>>  drivers/gpu/drm/bridge/sil-sii8620.h | 1517 ++
>>  4 files changed, 3082 insertions(+)
>>  create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.c
>>  create mode 100644 drivers/gpu/drm/bridge/sil-sii8620.h
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index b590e67..e7fb179 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -50,6 +50,13 @@ config DRM_PARADE_PS8622
>>  ---help---
>>Parade eDP-LVDS bridge chip driver.
>>
>> +config DRM_SIL_SII8620
>> +tristate "Silicon Image SII8620 HDMI/MHL bridge"
>> +depends on OF
>> +select DRM_KMS_HELPER
> Shouldn't you depend on I2C ?

It is under DRM_BRIDGE, which depends on DRM, which
selects I2C.

>
>> +help
>> +  Silicon Image SII8620 HDMI/MHL bridge chip driver.
>> +
>>  config DRM_SII902X
>>  tristate "Silicon Image sii902x RGB/HDMI bridge"
>>  depends on OF
> [snip]
>
>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
>> b/drivers/gpu/drm/bridge/sil-sii8620.c new file mode 100644
>> index 000..7f053a5
>> --- /dev/null
>> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> [snip]
>
>> +static void sii8620_write_buf(struct sii8620 *ctx, u16 addr, const u8 *buf,
>> +  int len)
>> +{
>> +struct device *dev = ctx->dev;
>> +struct i2c_client *client = to_i2c_client(dev);
>> +u8 data[2];
>> +struct i2c_msg msg = {
>> +.addr = sii8620_i2c_page[addr >> 8],
>> +.flags = client->flags,
>> +.len = len + 1,
>> +};
>> +int ret;
>> +
>> +if (ctx->error)
>> +return;
>> +
>> +if (len > 1) {
>> +msg.buf = kmalloc(len + 1, GFP_KERNEL);
> As len is 2 at most this seems overkill...

Hmm, it is used multiple times with bigger buffers, see
sii8620_set_dev_cap, or edid related code.

>
>> +if (!msg.buf) {
>> +ctx->error = -ENOMEM;
>> +return;
>> +}
>> +memcpy(msg.buf + 1, buf, len);
>> +} else {
>> +msg.buf = data;
>> +msg.buf[1] = *buf;
>> +}
>> +
>> +msg.buf[0] = addr;
>> +
>> +ret = i2c_transfer(client->adapter, , 1);
>> +dev_dbg(dev, "write at %04x: %*ph, %d\n", addr, len, buf, ret);
>> +
>> +if (ret != 1) {
>> +dev_err(dev, "Write at %#06x of %*ph failed with code %d.\n",
>> +addr, len, buf, ret);
>> +ctx->error = ret ?: -EIO;
>> +}
>> +
>> +if (len > 1)
>> +kfree(msg.buf);
>> +}
>> +
>> +#define sii8620_write(ctx, addr, arr...) \
>> +({\
>> +u8 d[] = { arr }; \
>> +sii8620_write_buf(ctx, addr, d, ARRAY_SIZE(d)); \
>> +})
>> +
>> +static void __sii8620_write_seq(struct sii8620 *ctx, u16 *seq, int len)
>> +{
>> +int i;
>> +
>> +for (i = 0; i < len; i += 2)
>> +sii8620_write(ctx, seq[i], seq[i + 1]);
>> +}
>> +
>> +#define sii8620_write_seq(ctx, seq...) \
>> +({\
>> +u16 d[] = { seq }; \
> You can make this const. Furthermore, given that there's quite a few calls to 
> this macro with lots of compile-time static arguments, a static const version 
> of the macro would be useful.

You are right.

>
>> +__sii8620_write_seq(ctx, d, ARRAY_SIZE(d)); \
>> +})
> [snip]
>
>> +static const struct of_device_id sii8620_dt_match[] = {
>> +{ .compatible = "sil,sii8620" },
>> +{ },
>> +};
>> +MODULE_DEVICE_TABLE(of, sii8620_dt_match);
>> +
>> +static const struct i2c_device_id sii8620_id[] = {
>> +{ "SII8620", 0 },
> Don't I2C IDs usually use lower case in the kernel ?

OK.

Regards
Andrzej

>
>> +{ },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(i2c, sii8620_id);

[Bug 98146] DRI_PRIME=1 and fullscreen issues

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Mike Lothian  ---
I think it was first added as DRI3 when the DRI option was added to bring it
inline with other drivers

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/5d803573/attachment.html>

[PATCH] drm/amd/powerplay: don't give up if DPM is already running

[Edward O'Callaghan]

Reviewed-by: Edward O'Callaghan 

On 10/10/2016 06:23 AM, Grazvydas Ignotas wrote:
> Currently the driver crashes if smu7_enable_dpm_tasks() returns early,
> which it does if DPM is already active. It seems to be better just to
> continue anyway, at least I haven't noticed any ill effects. It's also
> unclear at what state the hardware was left by the previous driver, so
> IMO it's better to always fully initialize.
> 
> Way to reproduce:
> $ modprobe amdgpu
> $ rmmod amdgpu
> $ modprobe amdgpu
> ...
> DPM is already running right now, no need to enable DPM!
> ...
> failed to send message 18b ret is 0
> BUG: unable to handle kernel paging request at ed01fc9ab21f
> Call Trace:
>  smu7_set_power_state_tasks+0x499/0x1940 [amdgpu]
>  phm_set_power_state+0xcb/0x120 [amdgpu]
>  psm_adjust_power_state_dynamic+0x11e/0x1b0 [amdgpu]
>  pem_task_adjust_power_state+0xb9/0xd0 [amdgpu]
>  pem_excute_event_chain+0x7d/0xe0 [amdgpu]
>  pem_handle_event_unlocked+0x49/0x60 [amdgpu]
>  pem_handle_event+0xe/0x10 [amdgpu]
>  pp_dpm_dispatch_tasks+0xe0/0x190 [amdgpu]
>  amdgpu_pm_compute_clocks+0x10c/0xc60 [amdgpu]
>  dce_v11_0_crtc_dpms+0x7d/0x150 [amdgpu]
>  dce_v11_0_crtc_disable+0x90/0x4a0 [amdgpu]
>  drm_helper_disable_unused_functions+0x67/0x80 [drm_kms_helper]
>  amdgpu_fbdev_init+0x13e/0x170 [amdgpu]
>  amdgpu_device_init+0x1aeb/0x2490 [amdgpu]
> 
> Signed-off-by: Grazvydas Ignotas 
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> index f6afa6a..327030b 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1166,8 +1166,8 @@ static int smu7_enable_dpm_tasks(struct pp_hwmgr *hwmgr)
>  
>   tmp_result = (!smum_is_dpm_running(hwmgr)) ? 0 : -1;
>   PP_ASSERT_WITH_CODE(tmp_result == 0,
> - "DPM is already running right now, no need to enable 
> DPM!",
> - return 0);
> + "DPM is already running",
> + );
>  
>   if (smu7_voltage_control(hwmgr)) {
>   tmp_result = smu7_enable_voltage_control(hwmgr);
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/0af7d6a6/attachment.sig>

[PATCH v4 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings

[Andrzej Hajda]

On 07.10.2016 16:44, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Friday 07 Oct 2016 09:02:41 Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
>> via I2C bus.
>>
>> Signed-off-by: Andrzej Hajda 
>> Acked-by: Rob Herring 
>> ---
>>  .../bindings/video/bridge/sil-sii8620.txt  | 33 +++
>>  1 file changed, 33 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>> b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt new file
>> mode 100644
>> index 000..9409d9c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>> @@ -0,0 +1,33 @@
>> +Silicon Image SiI8620 HDMI/MHL bridge bindings
>> +
>> +Required properties:
>> +- compatible: "sil,sii8620"
>> +- reg: i2c address of the bridge
>> +- cvcc10-supply: Digital Core Supply Voltage (1.0V)
>> +- iovcc18-supply: I/O Supply Voltage (1.8V)
>> +- interrupts, interrupt-parent: interrupt specifier of INT pin
>> +- reset-gpios: gpio specifier of RESET pin
>> +- clocks, clock-names: specification and name of "xtal" clock
>> +- video interfaces: Device node can contain video interface port
>> +node for HDMI encoder according to [1].
>> +
>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>> +
>> +Example:
>> +sii8620 at 39 {
>> +reg = <0x39>;
>> +compatible = "sil,sii8620";
>> +cvcc10-supply = <_reg>;
>> +iovcc18-supply = <_reg>;
>> +interrupt-parent = <>;
>> +interrupts = <2 0>;
>> +reset-gpio = < 0 0>;
>> +clocks = <_system_controller 0>;
>> +clock-names = "xtal";
>> +
>> +port {
>> +mhl_to_hdmi: endpoint {
>> +remote-endpoint = <_to_mhl>;
>> +};
>> +};
> A bridge, by definition, has two ports, an input port and an output port. You 
> should model that in DT.

It was discussed already. Output goes to usb connector,
which can be used also as usb or charging connector. Since it is not yet
clear how to handle it, output part was postponed, see for example[1].

[1]:
https://lists.freedesktop.org/archives/dri-devel/2015-December/096756.html

Regards
Andrzej

>
>> +};

[PATCH 1/1] gpu: drm: gma500: Use vma_pages()

[Shyam Saini]

On Mon, 2016-10-10 at 01:46 +0200, Patrik Jakobsson wrote:
> On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini 
> wrote:
> > 
> > Replace explicit computation of vma page count by a call to
> > vma_pages()
> Hi, I already have this patch in the "queue" from:
> Muhammad Falak R Wani 
> 
> Will include that one when I get around to sending out a PR.
> 
> Thanks
> Patrik
> 
> > 
> > 
> > Signed-off-by: Shyam Saini 
> > ---
> >  drivers/gpu/drm/gma500/framebuffer.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> > b/drivers/gpu/drm/gma500/framebuffer.c
> > index 3a44e70..0fde850 100644
> > --- a/drivers/gpu/drm/gma500/framebuffer.c
> > +++ b/drivers/gpu/drm/gma500/framebuffer.c
> > @@ -124,7 +124,7 @@ static int psbfb_vm_fault(struct vm_area_struct
> > *vma, struct vm_fault *vmf)
> >         unsigned long phys_addr = (unsigned long)dev_priv-
> > >stolen_base +
> >                                   
> > psbfb->gtt->offset;
> > 
> > -       page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> > +       page_num = vma_pages(vma);
> >         address = (unsigned long)vmf->virtual_address - (vmf->pgoff 
> > << PAGE_SHIFT);
> > 
> >         vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > --
> > 2.7.4
> > 

No issue.

Thanks

[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Sandeep  ---
I am using the AMDGPU driver for my card, and it works quite well. Much more
stable, no hangs now and performance also seems better.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/c1554b7a/attachment.html>

[PATCH 1/1] gpu: drm: gma500: Use vma_pages()

[Shyam Saini]

Replace explicit computation of vma page count by a call to
vma_pages()

Signed-off-by: Shyam Saini 
---
 drivers/gpu/drm/gma500/framebuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 3a44e70..0fde850 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -124,7 +124,7 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
  psbfb->gtt->offset;

-   page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+   page_num = vma_pages(vma);
address = (unsigned long)vmf->virtual_address - (vmf->pgoff << 
PAGE_SHIFT);

vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-- 
2.7.4

[PATCH 1/1] gpu: drm: gma500: Use vma_pages()

[Patrik Jakobsson]

On Mon, Oct 10, 2016 at 1:07 AM, Shyam Saini  wrote:
> Replace explicit computation of vma page count by a call to
> vma_pages()

Hi, I already have this patch in the "queue" from:
Muhammad Falak R Wani 

Will include that one when I get around to sending out a PR.

Thanks
Patrik

>
> Signed-off-by: Shyam Saini 
> ---
>  drivers/gpu/drm/gma500/framebuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 3a44e70..0fde850 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -124,7 +124,7 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, 
> struct vm_fault *vmf)
> unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
>   psbfb->gtt->offset;
>
> -   page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
> +   page_num = vma_pages(vma);
> address = (unsigned long)vmf->virtual_address - (vmf->pgoff << 
> PAGE_SHIFT);
>
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> --
> 2.7.4
>

[Bug 98176] External HDMI monitor not woken from sleep/power saving mode when coming back from idle

[bugzilla-dae...@freedesktop.org]

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

Jean-François Fortin Tam  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Jean-François Fortin Tam  ---
Actually no, I am mistaken... I didn't look closely enough: the nvidia card
just doesn't truly blank the screen, so the monitor does not go into power save
mode. An intel GPU had the same behavior as the radeonsi, so the monitor is
really the cause of the problem, probably not radeonsi.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/667e5c5b/attachment-0001.html>

[Bug 98167] [vulkan, radv] missing libgcrypt and openssl devel results in linker error in libvulkan_common

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Vedran Miletić  ---
Indeed it does. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/7bd4970b/attachment.html>

[Bug 98167] [vulkan, radv] missing libgcrypt and openssl devel results in linker error in libvulkan_common

[bugzilla-dae...@freedesktop.org]

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

Dave Airlie  changed:

   What|Removed |Added

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/95cd4f6e/attachment.html>

[Bug 98167] [vulkan, radv] missing libgcrypt and openssl devel results in linker error in libvulkan_common

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Dave Airlie  ---
Should be fixed in master now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161010/5ca80808/attachment.html>