[PATCH 3.5/6] drm/amd/powerplay: fix bugs of checking if dpm is running on Tonga

[Mike Lothian]

That did the trick thanks

On Fri, 13 May 2016 at 22:36 Alex Deucher  wrote:

> From: Eric Huang 
>
> Fixes OD failures on Tonga.
>
> Reviewed-by: Alex Deucher 
> Signed-off-by: Eric Huang 
> Signed-off-by: Alex Deucher 
> ---
>
> This fixes OD failures on Tonga in some cases.
>
>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
> index cb28335..7c3f82b 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
> @@ -5331,7 +5331,7 @@ static int tonga_freeze_sclk_mclk_dpm(struct
> pp_hwmgr *hwmgr)
> (data->need_update_smu7_dpm_table &
> (DPMTABLE_OD_UPDATE_SCLK + DPMTABLE_UPDATE_SCLK))) {
> PP_ASSERT_WITH_CODE(
> -   true == tonga_is_dpm_running(hwmgr),
> +   0 == tonga_is_dpm_running(hwmgr),
> "Trying to freeze SCLK DPM when DPM is disabled",
> );
> PP_ASSERT_WITH_CODE(
> @@ -5344,7 +5344,7 @@ static int tonga_freeze_sclk_mclk_dpm(struct
> pp_hwmgr *hwmgr)
> if ((0 == data->mclk_dpm_key_disabled) &&
> (data->need_update_smu7_dpm_table &
>  DPMTABLE_OD_UPDATE_MCLK)) {
> -   PP_ASSERT_WITH_CODE(true == tonga_is_dpm_running(hwmgr),
> +   PP_ASSERT_WITH_CODE(0 == tonga_is_dpm_running(hwmgr),
> "Trying to freeze MCLK DPM when DPM is disabled",
> );
> PP_ASSERT_WITH_CODE(
> @@ -5647,7 +5647,7 @@ static int tonga_unfreeze_sclk_mclk_dpm(struct
> pp_hwmgr *hwmgr)
> (data->need_update_smu7_dpm_table &
> (DPMTABLE_OD_UPDATE_SCLK + DPMTABLE_UPDATE_SCLK))) {
>
> -   PP_ASSERT_WITH_CODE(true == tonga_is_dpm_running(hwmgr),
> +   PP_ASSERT_WITH_CODE(0 == tonga_is_dpm_running(hwmgr),
> "Trying to Unfreeze SCLK DPM when DPM is disabled",
> );
> PP_ASSERT_WITH_CODE(
> @@ -5661,7 +5661,7 @@ static int tonga_unfreeze_sclk_mclk_dpm(struct
> pp_hwmgr *hwmgr)
> (data->need_update_smu7_dpm_table &
> DPMTABLE_OD_UPDATE_MCLK)) {
>
> PP_ASSERT_WITH_CODE(
> -   true == tonga_is_dpm_running(hwmgr),
> +   0 == tonga_is_dpm_running(hwmgr),
> "Trying to Unfreeze MCLK DPM when DPM is
> disabled",
> );
> PP_ASSERT_WITH_CODE(
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160513/54b8cc4e/attachment.html>

[PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array

[Muhammad Falak R Wani]

On Thu, May 12, 2016 at 12:53:48PM +0300, Jani Nikula wrote:
> On Wed, 11 May 2016, Muhammad Falak R Wani  wrote:
> > Use ARRAY_SIZE() for the size calculation of the array. Also move the
> > condition evaulation function out of the for loop.
> > Although, any respectable c-compiler would optimize this and evaluate
> > the function only once outside the loop, but the optimzation engine
> > of gcc is bit brain-dead, and at times needs some hand holding.
> 
> This just caught my eye. ARRAY_SIZE is a macro that expands to a compile
> time constant. Arguably adding the the local variable here gives GCC
> more chances to go wrong than keeping the ARRAY_SIZE in the loop
> condition.
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Muhammad Falak R Wani 
> > ---
> >  drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
> > b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > index da18f44..718a551 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > @@ -636,10 +636,11 @@ static int cz_smu_populate_firmware_entries(struct 
> > pp_smumgr *smumgr)
> > int ret;
> > enum cgs_ucode_id ucode_id;
> > struct cgs_firmware_info info = {0};
> > +   int n = ARRAY_SIZE(firmware_list);
> >  
> > cz_smu->driver_buffer_length = 0;
> >  
> > -   for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
> > +   for (i = 0; i < n; i++) {
> >  
> > firmware_type = cz_translate_firmware_enum_to_arg(smumgr,
> > firmware_list[i]);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
Should i send a new patch, with these modifications. Sorry for my
childish mistake, i got a little too carried away.

[PATCH 1/4] tests/amdgpu: expand write/copy tests to compute

[Christian König]

Am 13.05.2016 um 18:48 schrieb Alex Deucher:
> Uses same packets as gfx.
>
> Signed-off-by: Alex Deucher 

For the series Reviewed-by: Christian König 

> ---
>   tests/amdgpu/basic_tests.c | 9 ++---
>   1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 599c090..05ab145 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -813,7 +813,8 @@ static void 
> amdgpu_command_submission_write_linear_helper(unsigned ip_type)
>   pm4[i++] = sdma_write_length;
>   while(j++ < sdma_write_length)
>   pm4[i++] = 0xdeadbeaf;
> - } else if (ip_type == AMDGPU_HW_IP_GFX) {
> + } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
> +(ip_type == AMDGPU_HW_IP_COMPUTE)) {
>   pm4[i++] = PACKET3(PACKET3_WRITE_DATA, 2 + 
> sdma_write_length);
>   pm4[i++] = WRITE_DATA_DST_SEL(5) | WR_CONFIRM;
>   pm4[i++] = 0xfffc & bo_mc;
> @@ -911,7 +912,8 @@ static void 
> amdgpu_command_submission_const_fill_helper(unsigned ip_type)
>   pm4[i++] = (0x & bo_mc) >> 32;
>   pm4[i++] = 0xdeadbeaf;
>   pm4[i++] = sdma_write_length;
> - } else if (ip_type == AMDGPU_HW_IP_GFX) {
> + } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
> +(ip_type == AMDGPU_HW_IP_COMPUTE)) {
>   pm4[i++] = PACKET3(PACKET3_DMA_DATA, 5);
>   pm4[i++] = PACKET3_DMA_DATA_ENGINE(0) |
>   PACKET3_DMA_DATA_DST_SEL(0) |
> @@ -1030,7 +1032,8 @@ static void 
> amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
>   pm4[i++] = (0x & bo1_mc) >> 32;
>   pm4[i++] = 0x & bo2_mc;
>   pm4[i++] = (0x & bo2_mc) >> 32;
> - } else if (ip_type == AMDGPU_HW_IP_GFX) {
> + } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
> +(ip_type == AMDGPU_HW_IP_COMPUTE)) {
>   pm4[i++] = PACKET3(PACKET3_DMA_DATA, 5);
>   pm4[i++] = PACKET3_DMA_DATA_ENGINE(0) |
>   PACKET3_DMA_DATA_DST_SEL(0) |

[PATCH] drm: expand cea861 mode timing table

[Yang, Eric]

Hi Thierry Reding,

I will have to answer this question next week, the member of my team with a 
HDMI spec is not here today.

Hi Jani Nikula,
Thank you for noticing the formatting mistake, the checkpatch script did not 
catch this, I will prepare a new patch with the formatting fixed.

From: Thierry Reding 
Sent: Friday, May 13, 2016 11:28:39 AM
To: Yang, Eric
Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; 
tomi.valkeinen at ti.com; plagnioj at jcrosoft.com
Subject: Re: [PATCH] drm: expand cea861 mode timing table

On Thu, May 12, 2016 at 03:37:33PM -0400, Eric Yang wrote:
[...]
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index e974420..edbb4fc 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
>   HDMI_PICTURE_ASPECT_NONE,
>   HDMI_PICTURE_ASPECT_4_3,
>   HDMI_PICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,
>   HDMI_PICTURE_ASPECT_RESERVED,
>  };

Where did you get these from? I'm asking because I sent this patch last
year (or at least I wrote it and we discussed it on IRC, since I can't
find an email archive link to it), and back at the time the picture
aspect ratio was the big question mark. My recollection is that
CEA-861-F introduces these new picture aspect ratios in the mode tables
but never specifies their values. As a matter of fact, the AVI infoframe
where these values are used only has space for 4 values (none, 4:3, 16:9
and reserved).

Would you mind pointing me at the specification for these values?

Thanks,
Thierry

[PATCH 0/6] Initial sclk OD support for amdgpu

[Mike Lothian]

Hi

I gave this a spin but I just get:

[ 1073.096585] Trying to freeze SCLK DPM when DPM is disabled
[ 1073.097667] Trying to Unfreeze SCLK DPM when DPM is disabled
[ 1073.100118] Trying to freeze SCLK DPM when DPM is disabled
[ 1073.101618] Trying to Unfreeze SCLK DPM when DPM is disabled

DPM is enabled

Cheers

Mike

On Fri, 13 May 2016 at 19:56 Alex Deucher  wrote:

> On Fri, May 13, 2016 at 2:54 PM, Mike Lothian  wrote:
> > Sounds fancy but what does it do?
>
> Whoops, meant to define OD in the cover letter, the patches have the
> details.  OD = Overclocking.
>
> Alex
>
> >
> > On Fri, 13 May 2016 at 19:49 Alex Deucher  wrote:
> >>
> >> This adds initial OverDrive (OD) support for the gfx engine
> >> clock (sclk).  It's enabled by selecting a percentage (0-20)
> >> and writing it to a new sysfs file.  It's currently available
> >> on Tonga, Fiji, and Polaris.
> >>
> >> Eric Huang (6):
> >>   drm/amd/powerplay: fix a bug on updating sclk for Fiji
> >>   drm/amd/powerplay: fix a bug on updating sclk for Tonga
> >>   drm/amdgpu: add powerplay sclk OD support through sysfs
> >>   drm/amd/powerplay: add sclk OD support on Fiji
> >>   drm/amd/powerplay: add sclk OD support on Tonga
> >>   drm/amd/powerplay: add sclk OD support on Polaris10
> >>
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +++
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 49
> >> ++
> >>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 44
> >> +++
> >>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 45
> >> +++-
> >>  .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44
> >> +++
> >>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  | 46
> >> +++-
> >>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  |  2 +
> >>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +
> >>  8 files changed, 236 insertions(+), 2 deletions(-)
> >>
> >> --
> >> 2.5.5
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160513/4571a072/attachment.html>

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

--- Comment #19 from Alex Deucher  ---
Are things working any better with mesa from git without any patches?  Oded has
done a lot of fixes for r600g and Marek committed some fixes for r300g.

-- 
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/20160513/fe3b324b/attachment.html>

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

erhard_f at mailbox.org changed:

   What|Removed |Added

Version|git |11.2

--- Comment #18 from erhard_f at mailbox.org ---
Patch "fdo43698-vtxfmt-endianness.diff" applies against 11.2.2 via patch -p1,
the others do not.

-- 
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/20160513/8687e0b4/attachment.html>

[PATCH 0/6] Initial sclk OD support for amdgpu

[Mike Lothian]

Sounds fancy but what does it do?

On Fri, 13 May 2016 at 19:49 Alex Deucher  wrote:

> This adds initial OverDrive (OD) support for the gfx engine
> clock (sclk).  It's enabled by selecting a percentage (0-20)
> and writing it to a new sysfs file.  It's currently available
> on Tonga, Fiji, and Polaris.
>
> Eric Huang (6):
>   drm/amd/powerplay: fix a bug on updating sclk for Fiji
>   drm/amd/powerplay: fix a bug on updating sclk for Tonga
>   drm/amdgpu: add powerplay sclk OD support through sysfs
>   drm/amd/powerplay: add sclk OD support on Fiji
>   drm/amd/powerplay: add sclk OD support on Tonga
>   drm/amd/powerplay: add sclk OD support on Polaris10
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 49
> ++
>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 44
> +++
>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 45
> +++-
>  .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44
> +++
>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  | 46
> +++-
>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  |  2 +
>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +
>  8 files changed, 236 insertions(+), 2 deletions(-)
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160513/c521a7d6/attachment.html>

[PATCH] drm: expand cea861 mode timing table

[Eric Yang]

This patch expand the cea861 mode timing table to include vic 65
to 107. This allows more modes to be reported on newer displays,
including 4k at 60Hz on HDMI, which was previously only reported if
the display edid has a detailed timing descriptor block specifying
the exact timing

v2:
- fix formating of the added modes to match the existing onces

Signed-off-by: Eric Yang 
---
 drivers/gpu/drm/drm_edid.c | 215 +
 drivers/video/hdmi.c   |   4 +
 include/linux/hdmi.h   |   2 +
 3 files changed, 221 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 04cb487..4fb69ee 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -988,6 +988,221 @@ static const struct drm_display_mode edid_cea_modes[] = {
   2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720 at 24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59341, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720 at 25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720 at 30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720 at 50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720 at 60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720 at 100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720 at 120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148352, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080 at 24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080 at 25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080 at 30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080 at 50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080 at 60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148352, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 77 - 1920x1080 at 100Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | 

[PATCH] drm/atomic: Use DRM_DEBUG_KMS instead of DRM_DEBUG_ATOMIC in error paths

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

From: Ville Syrjälä 

DRM_DEBUG_ATOMIC generates a lot of noise that no one normally cares
about. However error paths everyone cares about, so hiding thea error
debugs under DRM_DEBUG_ATOMIC is a bad idea. Let's use DRM_DEBUG_KMS
for those instead.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic.c| 60 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 60 ++---
 2 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 86e89db02ed7..1479bfd8744b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -554,8 +554,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 */

if (state->active && !state->enable) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
-crtc->base.id, crtc->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] active without enabled\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}

@@ -564,15 +564,15 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 * be able to trigger. */
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(state->enable && !state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
-crtc->base.id, crtc->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] enabled without mode blob\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}

if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
WARN_ON(!state->enable && state->mode_blob)) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
-crtc->base.id, crtc->name);
+   DRM_DEBUG_KMS("[CRTC:%d:%s] disabled with mode blob\n",
+ crtc->base.id, crtc->name);
return -EINVAL;
}

@@ -587,8 +587,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
 * pipe.
 */
if (state->event && !state->active && !crtc->state->active) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] requesting event but off\n",
-crtc->base.id);
+   DRM_DEBUG_KMS("[CRTC:%d] requesting event but off\n",
+ crtc->base.id);
return -EINVAL;
}

@@ -802,10 +802,10 @@ static int drm_atomic_plane_check(struct drm_plane *plane,

/* either *both* CRTC and FB must be set, or neither */
if (WARN_ON(state->crtc && !state->fb)) {
-   DRM_DEBUG_ATOMIC("CRTC set but no FB\n");
+   DRM_DEBUG_KMS("CRTC set but no FB\n");
return -EINVAL;
} else if (WARN_ON(state->fb && !state->crtc)) {
-   DRM_DEBUG_ATOMIC("FB set but no CRTC\n");
+   DRM_DEBUG_KMS("FB set but no CRTC\n");
return -EINVAL;
}

@@ -815,15 +815,15 @@ static int drm_atomic_plane_check(struct drm_plane *plane,

/* Check whether this plane is usable on this CRTC */
if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
-   DRM_DEBUG_ATOMIC("Invalid crtc for plane\n");
+   DRM_DEBUG_KMS("Invalid crtc for plane\n");
return -EINVAL;
}

/* Check whether this plane supports the fb pixel format. */
ret = drm_plane_check_pixel_format(plane, state->fb->pixel_format);
if (ret) {
-   DRM_DEBUG_ATOMIC("Invalid pixel format %s\n",
-drm_get_format_name(state->fb->pixel_format));
+   DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(state->fb->pixel_format));
return ret;
}

@@ -832,9 +832,9 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
state->crtc_x > INT_MAX - (int32_t) state->crtc_w ||
state->crtc_h > INT_MAX ||
state->crtc_y > INT_MAX - (int32_t) state->crtc_h) {
-   DRM_DEBUG_ATOMIC("Invalid CRTC coordinates %ux%u+%d+%d\n",
-state->crtc_w, state->crtc_h,
-state->crtc_x, state->crtc_y);
+   DRM_DEBUG_KMS("Invalid CRTC coordinates %ux%u+%d+%d\n",
+ state->crtc_w, state->crtc_h,
+ state->crtc_x, state->crtc_y);
return -ERANGE;
}

@@ -846,18 +846,18 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
state->src_x > fb_width - state->src_w ||
state->src_h > fb_height ||
state->src_y > fb_height - state->src_h) {
-   DRM_DEBUG_ATOMIC("Invalid source coordinates "
- 

[Bug 84327] crash in gnome-shell when typing in the app view

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

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

Ray Strode [halfline]  changed:

   What|Removed |Added

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

--- Comment #4 from Ray Strode [halfline]  ---
i don't even remember this happening so i think we can close it out.

-- 
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/20160513/3b916616/attachment.html>

[PATCH 0/6] Initial sclk OD support for amdgpu

[Alex Deucher]

On Fri, May 13, 2016 at 3:45 PM, Mike Lothian  wrote:
> Hi
>
> I gave this a spin but I just get:
>
> [ 1073.096585] Trying to freeze SCLK DPM when DPM is disabled
> [ 1073.097667] Trying to Unfreeze SCLK DPM when DPM is disabled
> [ 1073.100118] Trying to freeze SCLK DPM when DPM is disabled
> [ 1073.101618] Trying to Unfreeze SCLK DPM when DPM is disabled
>
> DPM is enabled

Fixed in patch 3.5.

Alex

>
> Cheers
>
> Mike
>
> On Fri, 13 May 2016 at 19:56 Alex Deucher  wrote:
>>
>> On Fri, May 13, 2016 at 2:54 PM, Mike Lothian  wrote:
>> > Sounds fancy but what does it do?
>>
>> Whoops, meant to define OD in the cover letter, the patches have the
>> details.  OD = Overclocking.
>>
>> Alex
>>
>> >
>> > On Fri, 13 May 2016 at 19:49 Alex Deucher  wrote:
>> >>
>> >> This adds initial OverDrive (OD) support for the gfx engine
>> >> clock (sclk).  It's enabled by selecting a percentage (0-20)
>> >> and writing it to a new sysfs file.  It's currently available
>> >> on Tonga, Fiji, and Polaris.
>> >>
>> >> Eric Huang (6):
>> >>   drm/amd/powerplay: fix a bug on updating sclk for Fiji
>> >>   drm/amd/powerplay: fix a bug on updating sclk for Tonga
>> >>   drm/amdgpu: add powerplay sclk OD support through sysfs
>> >>   drm/amd/powerplay: add sclk OD support on Fiji
>> >>   drm/amd/powerplay: add sclk OD support on Tonga
>> >>   drm/amd/powerplay: add sclk OD support on Polaris10
>> >>
>> >>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +++
>> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 49
>> >> ++
>> >>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 44
>> >> +++
>> >>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 45
>> >> +++-
>> >>  .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44
>> >> +++
>> >>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  | 46
>> >> +++-
>> >>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  |  2 +
>> >>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +
>> >>  8 files changed, 236 insertions(+), 2 deletions(-)
>> >>
>> >> --
>> >> 2.5.5
>> >>
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3.5/6] drm/amd/powerplay: fix bugs of checking if dpm is running on Tonga

[Alex Deucher]

From: Eric Huang 

Fixes OD failures on Tonga.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---

This fixes OD failures on Tonga in some cases.

 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
index cb28335..7c3f82b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
@@ -5331,7 +5331,7 @@ static int tonga_freeze_sclk_mclk_dpm(struct pp_hwmgr 
*hwmgr)
(data->need_update_smu7_dpm_table &
(DPMTABLE_OD_UPDATE_SCLK + DPMTABLE_UPDATE_SCLK))) {
PP_ASSERT_WITH_CODE(
-   true == tonga_is_dpm_running(hwmgr),
+   0 == tonga_is_dpm_running(hwmgr),
"Trying to freeze SCLK DPM when DPM is disabled",
);
PP_ASSERT_WITH_CODE(
@@ -5344,7 +5344,7 @@ static int tonga_freeze_sclk_mclk_dpm(struct pp_hwmgr 
*hwmgr)
if ((0 == data->mclk_dpm_key_disabled) &&
(data->need_update_smu7_dpm_table &
 DPMTABLE_OD_UPDATE_MCLK)) {
-   PP_ASSERT_WITH_CODE(true == tonga_is_dpm_running(hwmgr),
+   PP_ASSERT_WITH_CODE(0 == tonga_is_dpm_running(hwmgr),
"Trying to freeze MCLK DPM when DPM is disabled",
);
PP_ASSERT_WITH_CODE(
@@ -5647,7 +5647,7 @@ static int tonga_unfreeze_sclk_mclk_dpm(struct pp_hwmgr 
*hwmgr)
(data->need_update_smu7_dpm_table &
(DPMTABLE_OD_UPDATE_SCLK + DPMTABLE_UPDATE_SCLK))) {

-   PP_ASSERT_WITH_CODE(true == tonga_is_dpm_running(hwmgr),
+   PP_ASSERT_WITH_CODE(0 == tonga_is_dpm_running(hwmgr),
"Trying to Unfreeze SCLK DPM when DPM is disabled",
);
PP_ASSERT_WITH_CODE(
@@ -5661,7 +5661,7 @@ static int tonga_unfreeze_sclk_mclk_dpm(struct pp_hwmgr 
*hwmgr)
(data->need_update_smu7_dpm_table & DPMTABLE_OD_UPDATE_MCLK)) {

PP_ASSERT_WITH_CODE(
-   true == tonga_is_dpm_running(hwmgr),
+   0 == tonga_is_dpm_running(hwmgr),
"Trying to Unfreeze MCLK DPM when DPM is 
disabled",
);
PP_ASSERT_WITH_CODE(
-- 
2.5.5

[PATCH v2 2/3] drm/mst: Fix error handling during MST sideband message reception

[Imre Deak]

Handle any error due to partial reads, timeouts etc. to avoid parsing
uninitialized data subsequently. Also bail out if the parsing itself
fails.

v2:
- Remove blank lines before returns to match the rest of file (Lyude)

CC: Dave Airlie 
Signed-off-by: Imre Deak 
Reviewed-by: Lyude 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a13edf5..9e64493 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2204,11 +2204,17 @@ static void drm_dp_get_one_sb_msg(struct 
drm_dp_mst_topology_mgr *mgr, bool up)
ret = drm_dp_dpcd_read(mgr->aux, basereg + curreply,
replyblock, len);
if (ret != len) {
-   DRM_DEBUG_KMS("failed to read a chunk\n");
+   DRM_DEBUG_KMS("failed to read a chunk (len %d, ret 
%d)\n",
+ len, ret);
+   return;
}
+
ret = drm_dp_sideband_msg_build(msg, replyblock, len, false);
-   if (ret == false)
+   if (!ret) {
DRM_DEBUG_KMS("failed to build sideband msg\n");
+   return;
+   }
+
curreply += len;
replylen -= len;
}
-- 
2.5.0

[PATCH] drm: expand cea861 mode timing table

[Thierry Reding]

On Thu, May 12, 2016 at 03:37:33PM -0400, Eric Yang wrote:
[...]
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index e974420..edbb4fc 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
>   HDMI_PICTURE_ASPECT_NONE,
>   HDMI_PICTURE_ASPECT_4_3,
>   HDMI_PICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,
>   HDMI_PICTURE_ASPECT_RESERVED,
>  };

Where did you get these from? I'm asking because I sent this patch last
year (or at least I wrote it and we discussed it on IRC, since I can't
find an email archive link to it), and back at the time the picture
aspect ratio was the big question mark. My recollection is that
CEA-861-F introduces these new picture aspect ratios in the mode tables
but never specifies their values. As a matter of fact, the AVI infoframe
where these values are used only has space for 4 values (none, 4:3, 16:9
and reserved).

Would you mind pointing me at the specification for these values?

Thanks,
Thierry
-- 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/20160513/404188f0/attachment.sig>

[PATCH] drm: expand cea861 mode timing table

[Jani Nikula]

On Thu, 12 May 2016, Eric Yang  wrote:
> This patch expand the cea861 mode timing table to include vic 65
> to 107. This allows more modes to be reported on newer displays,
> including 4k at 60Hz on HDMI, which was previously only reported if
> the display edid has a detailed timing descriptor block specifying
> the exact timing

Just a quick drive-by note, please don't change the indentation in the
middle of the table.

BR,
Jani.

>
> Signed-off-by: Eric Yang 
> ---
>  drivers/gpu/drm/drm_edid.c | 215 
> +
>  drivers/video/hdmi.c   |   4 +
>  include/linux/hdmi.h   |   2 +
>  3 files changed, 221 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 04cb487..34ed001 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -988,6 +988,221 @@ static const struct drm_display_mode edid_cea_modes[] = 
> {
>  2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720 at 24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59341, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720 at 25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720 at 30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720 at 50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720 at 60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720 at 100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720 at 120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148352, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080 at 24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080 at 25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080 at 30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080 at 50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 76 - 1920x1080 at 60Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148352, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 77 - 1920x1080 at 100Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> + .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 78 - 

[PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array

[Deucher, Alexander]

> -Original Message-
> From: Muhammad Falak R Wani [mailto:falakreyaz at gmail.com]
> Sent: Friday, May 13, 2016 1:17 PM
> To: Jani Nikula
> Cc: Koenig, Christian; Nils Wallménius; Zhou, Jammy; linux-
> kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; Deucher,
> Alexander; Zhu, Rex; Dan Carpenter
> Subject: Re: [PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of
> array
> 
> On Thu, May 12, 2016 at 12:53:48PM +0300, Jani Nikula wrote:
> > On Wed, 11 May 2016, Muhammad Falak R Wani 
> wrote:
> > > Use ARRAY_SIZE() for the size calculation of the array. Also move the
> > > condition evaulation function out of the for loop.
> > > Although, any respectable c-compiler would optimize this and evaluate
> > > the function only once outside the loop, but the optimzation engine
> > > of gcc is bit brain-dead, and at times needs some hand holding.
> >
> > This just caught my eye. ARRAY_SIZE is a macro that expands to a compile
> > time constant. Arguably adding the the local variable here gives GCC
> > more chances to go wrong than keeping the ARRAY_SIZE in the loop
> > condition.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Muhammad Falak R Wani 
> > > ---
> > >  drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > index da18f44..718a551 100644
> > > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > @@ -636,10 +636,11 @@ static int
> cz_smu_populate_firmware_entries(struct pp_smumgr *smumgr)
> > >   int ret;
> > >   enum cgs_ucode_id ucode_id;
> > >   struct cgs_firmware_info info = {0};
> > > + int n = ARRAY_SIZE(firmware_list);
> > >
> > >   cz_smu->driver_buffer_length = 0;
> > >
> > > - for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
> > > + for (i = 0; i < n; i++) {
> > >
> > >   firmware_type =
> cz_translate_firmware_enum_to_arg(smumgr,
> > >   firmware_list[i]);
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> Should i send a new patch, with these modifications. Sorry for my
> childish mistake, i got a little too carried away.

Yes, please send an updated patch.

Thanks,

Alex

[PULL] drm: UAPI extern C fixes

[Emil Velikov]

Hi Dave,

Here is the pull request for the extern C addition to our UAPI headers.

Many maintainers are in favour of the idea and considering the lack of
volunteers for the `make headers_install' route I'm hoping that we can get
these in and revert, if needed, at a later stage.

Thanks
Emil


The following changes since commit 95306975e9dd38ba2775dd96cb29987ecc7d9360:

  Merge tag 'drm/tegra/for-4.7-rc1' of 
git://anongit.freedesktop.org/tegra/linux into drm-next (2016-05-12 11:15:18 
+1000)

are available in the git repository at:

  https://github.com/evelikov/linux drm-uapi-extern-c-fixes

for you to fetch changes up to d3450e009f9038f3c7824f64695fa51ef2474e08:

  drm/vmwgfx: add extern C guard for the UAPI header (2016-05-13 14:06:21 +0100)


Emil Velikov (22):
  drm/amdgpu: add extern C guard for the UAPI header
  drm/armada: add extern C guard for the UAPI header
  drm: add extern C guard for the UAPI headers
  drm/etnaviv: add extern C guard for the UAPI header
  drm/exynos: add extern C guard for the UAPI header
  drm/i810: add extern C guard for the UAPI header
  drm/i915: add extern C guard for the UAPI header
  drm/mga: add extern C guard for the UAPI header
  drm/msm: add extern C guard for the UAPI header
  drm/nouveau: add extern C guard for the UAPI header
  drm/nouveau: drop drm/ prefix from include
  drm/omap: add extern C guard for the UAPI header
  drm/qxl: add extern C guard for the UAPI header
  drm/r128: add extern C guard for the UAPI header
  drm/radeon: add extern C guard for the UAPI header
  drm/savage: add extern C guard for the UAPI header
  drm/sis: add extern C guard for the UAPI header
  drm/tegra: add extern C guard for the UAPI header
  drm/vc4: add extern C guard for the UAPI header
  drm/via: add extern C guard for the UAPI header
  drm/virgl: add extern C guard for the UAPI header
  drm/vmwgfx: add extern C guard for the UAPI header

 include/uapi/drm/amdgpu_drm.h  |  8 
 include/uapi/drm/armada_drm.h  |  8 
 include/uapi/drm/drm.h | 16 
 include/uapi/drm/drm_fourcc.h  |  8 
 include/uapi/drm/drm_mode.h|  8 
 include/uapi/drm/drm_sarea.h   |  8 
 include/uapi/drm/etnaviv_drm.h |  8 
 include/uapi/drm/exynos_drm.h  |  8 
 include/uapi/drm/i810_drm.h|  8 
 include/uapi/drm/i915_drm.h|  8 
 include/uapi/drm/mga_drm.h |  8 
 include/uapi/drm/msm_drm.h |  8 
 include/uapi/drm/nouveau_drm.h | 10 +-
 include/uapi/drm/omap_drm.h|  8 
 include/uapi/drm/qxl_drm.h |  8 
 include/uapi/drm/r128_drm.h|  8 
 include/uapi/drm/radeon_drm.h  |  8 
 include/uapi/drm/savage_drm.h  |  8 
 include/uapi/drm/sis_drm.h |  8 
 include/uapi/drm/tegra_drm.h   |  8 
 include/uapi/drm/vc4_drm.h |  8 
 include/uapi/drm/via_drm.h |  8 
 include/uapi/drm/virtgpu_drm.h |  8 
 include/uapi/drm/vmwgfx_drm.h  |  9 +
 24 files changed, 202 insertions(+), 1 deletion(-)

[PATCH 0/6] Initial sclk OD support for amdgpu

[Alex Deucher]

On Fri, May 13, 2016 at 2:54 PM, Mike Lothian  wrote:
> Sounds fancy but what does it do?

Whoops, meant to define OD in the cover letter, the patches have the
details.  OD = Overclocking.

Alex

>
> On Fri, 13 May 2016 at 19:49 Alex Deucher  wrote:
>>
>> This adds initial OverDrive (OD) support for the gfx engine
>> clock (sclk).  It's enabled by selecting a percentage (0-20)
>> and writing it to a new sysfs file.  It's currently available
>> on Tonga, Fiji, and Polaris.
>>
>> Eric Huang (6):
>>   drm/amd/powerplay: fix a bug on updating sclk for Fiji
>>   drm/amd/powerplay: fix a bug on updating sclk for Tonga
>>   drm/amdgpu: add powerplay sclk OD support through sysfs
>>   drm/amd/powerplay: add sclk OD support on Fiji
>>   drm/amd/powerplay: add sclk OD support on Tonga
>>   drm/amd/powerplay: add sclk OD support on Polaris10
>>
>>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +++
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 49
>> ++
>>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 44
>> +++
>>  drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 45
>> +++-
>>  .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44
>> +++
>>  drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  | 46
>> +++-
>>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  |  2 +
>>  drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +
>>  8 files changed, 236 insertions(+), 2 deletions(-)
>>
>> --
>> 2.5.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/amd/powerplay: add sclk OD support on Polaris10

[Alex Deucher]

From: Eric Huang 

This implements sclk overdrive(OD) overclocking support for Polaris10,
and the maximum overdrive percentage is 20.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44 ++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index 4cef7a5..05cb9a0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -4899,6 +4899,48 @@ static int polaris10_get_fan_control_mode(struct 
pp_hwmgr *hwmgr)
CG_FDO_CTRL2, FDO_PWM_MODE);
 }

+static int polaris10_get_sclk_od(struct pp_hwmgr *hwmgr)
+{
+   struct polaris10_hwmgr *data = (struct polaris10_hwmgr 
*)(hwmgr->backend);
+   struct polaris10_single_dpm_table *sclk_table = 
&(data->dpm_table.sclk_table);
+   struct polaris10_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   int value;
+
+   value = (sclk_table->dpm_levels[sclk_table->count - 1].value -
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value) *
+   100 /
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return value;
+}
+
+static int polaris10_set_sclk_od(struct pp_hwmgr *hwmgr, uint32_t value)
+{
+   struct polaris10_hwmgr *data = (struct polaris10_hwmgr 
*)(hwmgr->backend);
+   struct polaris10_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   struct pp_power_state  *ps;
+   struct polaris10_power_state  *polaris10_ps;
+
+   if (value > 20)
+   value = 20;
+
+   ps = hwmgr->request_ps;
+
+   if (ps == NULL)
+   return -EINVAL;
+
+   polaris10_ps = cast_phw_polaris10_power_state(>hardware);
+
+   polaris10_ps->performance_levels[polaris10_ps->performance_level_count 
- 1].engine_clock =
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value *
+   value / 100 +
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return 0;
+}
+
 static const struct pp_hwmgr_func polaris10_hwmgr_funcs = {
.backend_init = _hwmgr_backend_init,
.backend_fini = _hwmgr_backend_fini,
@@ -4942,6 +4984,8 @@ static const struct pp_hwmgr_func polaris10_hwmgr_funcs = 
{
.force_clock_level = polaris10_force_clock_level,
.print_clock_levels = polaris10_print_clock_levels,
.enable_per_cu_power_gating = polaris10_phm_enable_per_cu_power_gating,
+   .get_sclk_od = polaris10_get_sclk_od,
+   .set_sclk_od = polaris10_set_sclk_od,
 };

 int polaris10_hwmgr_init(struct pp_hwmgr *hwmgr)
-- 
2.5.5

[PATCH 5/6] drm/amd/powerplay: add sclk OD support on Tonga

[Alex Deucher]

From: Eric Huang 

This implements sclk overdrive(OD) overclocking support for Tonga,
and the maximum overdrive percentage is 20.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
index cb28335..cf1fca4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
@@ -6194,6 +6194,48 @@ static int tonga_print_clock_levels(struct pp_hwmgr 
*hwmgr,
return size;
 }

+static int tonga_get_sclk_od(struct pp_hwmgr *hwmgr)
+{
+   struct tonga_hwmgr *data = (struct tonga_hwmgr *)(hwmgr->backend);
+   struct tonga_single_dpm_table *sclk_table = 
&(data->dpm_table.sclk_table);
+   struct tonga_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   int value;
+
+   value = (sclk_table->dpm_levels[sclk_table->count - 1].value -
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value) *
+   100 /
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return value;
+}
+
+static int tonga_set_sclk_od(struct pp_hwmgr *hwmgr, uint32_t value)
+{
+   struct tonga_hwmgr *data = (struct tonga_hwmgr *)(hwmgr->backend);
+   struct tonga_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   struct pp_power_state  *ps;
+   struct tonga_power_state  *tonga_ps;
+
+   if (value > 20)
+   value = 20;
+
+   ps = hwmgr->request_ps;
+
+   if (ps == NULL)
+   return -EINVAL;
+
+   tonga_ps = cast_phw_tonga_power_state(>hardware);
+
+   tonga_ps->performance_levels[tonga_ps->performance_level_count - 
1].engine_clock =
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value *
+   value / 100 +
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return 0;
+}
+
 static const struct pp_hwmgr_func tonga_hwmgr_funcs = {
.backend_init = _hwmgr_backend_init,
.backend_fini = _hwmgr_backend_fini,
@@ -6236,6 +6278,8 @@ static const struct pp_hwmgr_func tonga_hwmgr_funcs = {
.set_pp_table = tonga_set_pp_table,
.force_clock_level = tonga_force_clock_level,
.print_clock_levels = tonga_print_clock_levels,
+   .get_sclk_od = tonga_get_sclk_od,
+   .set_sclk_od = tonga_set_sclk_od,
 };

 int tonga_hwmgr_init(struct pp_hwmgr *hwmgr)
-- 
2.5.5

[PATCH 4/6] drm/amd/powerplay: add sclk OD support on Fiji

[Alex Deucher]

From: Eric Huang 

This implements sclk overdrive(OD) overclocking support for Fiji,
and the maximum overdrive percentage is 20.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 43 
 1 file changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
index 6f1bad4..bf7bf5f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
@@ -5274,6 +5274,47 @@ bool 
fiji_check_smc_update_required_for_display_configuration(struct pp_hwmgr *h
return is_update_required;
 }

+static int fiji_get_sclk_od(struct pp_hwmgr *hwmgr)
+{
+   struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
+   struct fiji_single_dpm_table *sclk_table = 
&(data->dpm_table.sclk_table);
+   struct fiji_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   int value;
+
+   value = (sclk_table->dpm_levels[sclk_table->count - 1].value -
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value) *
+   100 /
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return value;
+}
+
+static int fiji_set_sclk_od(struct pp_hwmgr *hwmgr, uint32_t value)
+{
+   struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);
+   struct fiji_single_dpm_table *golden_sclk_table =
+   &(data->golden_dpm_table.sclk_table);
+   struct pp_power_state  *ps;
+   struct fiji_power_state  *fiji_ps;
+
+   if (value > 20)
+   value = 20;
+
+   ps = hwmgr->request_ps;
+
+   if (ps == NULL)
+   return -EINVAL;
+
+   fiji_ps = cast_phw_fiji_power_state(>hardware);
+
+   fiji_ps->performance_levels[fiji_ps->performance_level_count - 
1].engine_clock =
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value *
+   value / 100 +
+   golden_sclk_table->dpm_levels[golden_sclk_table->count 
- 1].value;
+
+   return 0;
+}

 static const struct pp_hwmgr_func fiji_hwmgr_funcs = {
.backend_init = _hwmgr_backend_init,
@@ -5316,6 +5357,8 @@ static const struct pp_hwmgr_func fiji_hwmgr_funcs = {
.set_pp_table = fiji_set_pp_table,
.force_clock_level = fiji_force_clock_level,
.print_clock_levels = fiji_print_clock_levels,
+   .get_sclk_od = fiji_get_sclk_od,
+   .set_sclk_od = fiji_set_sclk_od,
 };

 int fiji_hwmgr_init(struct pp_hwmgr *hwmgr)
-- 
2.5.5

[PATCH 3/6] drm/amdgpu: add powerplay sclk OD support through sysfs

[Alex Deucher]

From: Eric Huang 

Add a new sysfs entry pp_sclk_od to support sclk overdrive(OD) overclocking,
the entry is read/write, the value of input/output is an integer which is the
over percentage of the highest sclk.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  6 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 49 +++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 44 
 drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h |  2 +
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |  2 +
 5 files changed, 103 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 992f00b..367dbc4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -2335,6 +2335,12 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
 #define amdgpu_dpm_force_clock_level(adev, type, level) \

(adev)->powerplay.pp_funcs->force_clock_level((adev)->powerplay.pp_handle, 
type, level)

+#define amdgpu_dpm_get_sclk_od(adev) \
+   (adev)->powerplay.pp_funcs->get_sclk_od((adev)->powerplay.pp_handle)
+
+#define amdgpu_dpm_set_sclk_od(adev, value) \
+   (adev)->powerplay.pp_funcs->set_sclk_od((adev)->powerplay.pp_handle, 
value)
+
 #define amdgpu_dpm_dispatch_task(adev, event_id, input, output)
\
(adev)->powerplay.pp_funcs->dispatch_tasks((adev)->powerplay.pp_handle, 
(event_id), (input), (output))

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 589b36e..f7ecaf4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -471,6 +471,46 @@ fail:
return count;
 }

+static ssize_t amdgpu_get_pp_sclk_od(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct drm_device *ddev = dev_get_drvdata(dev);
+   struct amdgpu_device *adev = ddev->dev_private;
+   uint32_t value = 0;
+
+   if (adev->pp_enabled)
+   value = amdgpu_dpm_get_sclk_od(adev);
+
+   return snprintf(buf, PAGE_SIZE, "%d\n", value);;
+}
+
+static ssize_t amdgpu_set_pp_sclk_od(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,
+   size_t count)
+{
+   struct drm_device *ddev = dev_get_drvdata(dev);
+   struct amdgpu_device *adev = ddev->dev_private;
+   int ret;
+   long int value;
+
+   ret = kstrtol(buf, 0, );
+
+   if (ret) {
+   count = -EINVAL;
+   goto fail;
+   }
+
+   if (adev->pp_enabled)
+   amdgpu_dpm_set_sclk_od(adev, (uint32_t)value);
+
+   amdgpu_dpm_dispatch_task(adev, AMD_PP_EVENT_READJUST_POWER_STATE, NULL, 
NULL);
+
+fail:
+   return count;
+}
+
 static DEVICE_ATTR(power_dpm_state, S_IRUGO | S_IWUSR, amdgpu_get_dpm_state, 
amdgpu_set_dpm_state);
 static DEVICE_ATTR(power_dpm_force_performance_level, S_IRUGO | S_IWUSR,
   amdgpu_get_dpm_forced_performance_level,
@@ -492,6 +532,9 @@ static DEVICE_ATTR(pp_dpm_mclk, S_IRUGO | S_IWUSR,
 static DEVICE_ATTR(pp_dpm_pcie, S_IRUGO | S_IWUSR,
amdgpu_get_pp_dpm_pcie,
amdgpu_set_pp_dpm_pcie);
+static DEVICE_ATTR(pp_sclk_od, S_IRUGO | S_IWUSR,
+   amdgpu_get_pp_sclk_od,
+   amdgpu_set_pp_sclk_od);

 static ssize_t amdgpu_hwmon_show_temp(struct device *dev,
  struct device_attribute *attr,
@@ -1125,6 +1168,11 @@ int amdgpu_pm_sysfs_init(struct amdgpu_device *adev)
DRM_ERROR("failed to create device file pp_dpm_pcie\n");
return ret;
}
+   ret = device_create_file(adev->dev, _attr_pp_sclk_od);
+   if (ret) {
+   DRM_ERROR("failed to create device file pp_sclk_od\n");
+   return ret;
+   }
}
ret = amdgpu_debugfs_pm_init(adev);
if (ret) {
@@ -1151,6 +1199,7 @@ void amdgpu_pm_sysfs_fini(struct amdgpu_device *adev)
device_remove_file(adev->dev, _attr_pp_dpm_sclk);
device_remove_file(adev->dev, _attr_pp_dpm_mclk);
device_remove_file(adev->dev, _attr_pp_dpm_pcie);
+   device_remove_file(adev->dev, _attr_pp_sclk_od);
}
 }

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index 8e345bf..e0f2440 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -530,6 +530,10 @@ int pp_dpm_dispatch_tasks(void *handle, enum amd_pp_event 
event_id, void *input,
case AMD_PP_EVENT_COMPLETE_INIT:
ret = pem_handle_event(pp_handle->eventmgr, event_id, );
break;

[PATCH 2/6] drm/amd/powerplay: fix a bug on updating sclk for Tonga

[Alex Deucher]

From: Eric Huang 

Update sclk smc table rather than mclk smc table for sclk updates.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
index 1faad92..cb28335 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
@@ -5445,7 +5445,7 @@ static int 
tonga_populate_and_upload_sclk_mclk_dpm_levels(struct pp_hwmgr *hwmgr
}

if (data->need_update_smu7_dpm_table & (DPMTABLE_OD_UPDATE_SCLK + 
DPMTABLE_UPDATE_SCLK)) {
-   result = tonga_populate_all_memory_levels(hwmgr);
+   result = tonga_populate_all_graphic_levels(hwmgr);
PP_ASSERT_WITH_CODE((0 == result),
"Failed to populate SCLK during 
PopulateNewDPMClocksStates Function!",
return result);
-- 
2.5.5

[PATCH 1/6] drm/amd/powerplay: fix a bug on updating sclk for Fiji

[Alex Deucher]

From: Eric Huang 

Update sclk smc table rather than mclk smc table for sclk updates.

Reviewed-by: Alex Deucher 
Signed-off-by: Eric Huang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
index 382223b..6f1bad4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
@@ -4314,7 +4314,7 @@ static int fiji_populate_and_upload_sclk_mclk_dpm_levels(

if (data->need_update_smu7_dpm_table &
(DPMTABLE_OD_UPDATE_SCLK + DPMTABLE_UPDATE_SCLK)) {
-   result = fiji_populate_all_memory_levels(hwmgr);
+   result = fiji_populate_all_graphic_levels(hwmgr);
PP_ASSERT_WITH_CODE((0 == result),
"Failed to populate SCLK during 
PopulateNewDPMClocksStates Function!",
return result);
-- 
2.5.5

[PATCH 0/6] Initial sclk OD support for amdgpu

[Alex Deucher]

This adds initial OverDrive (OD) support for the gfx engine
clock (sclk).  It's enabled by selecting a percentage (0-20)
and writing it to a new sysfs file.  It's currently available
on Tonga, Fiji, and Polaris.

Eric Huang (6):
  drm/amd/powerplay: fix a bug on updating sclk for Fiji
  drm/amd/powerplay: fix a bug on updating sclk for Tonga
  drm/amdgpu: add powerplay sclk OD support through sysfs
  drm/amd/powerplay: add sclk OD support on Fiji
  drm/amd/powerplay: add sclk OD support on Tonga
  drm/amd/powerplay: add sclk OD support on Polaris10

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 49 ++
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 44 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 45 +++-
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 44 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c  | 46 +++-
 drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  |  2 +
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +
 8 files changed, 236 insertions(+), 2 deletions(-)

-- 
2.5.5

[PATCH] drm/amdgpu: create fence slab once when amdgpu module init.

[Alex Deucher]

From: Rex Zhu 

This avoids problems with multiple GPUs.  For example,
if the first GPU failed before amdgpu_fence_init() was
called, amdgpu_fence_slab_ref is still 0 and it will
get decremented in amdgpu_fence_driver_fini().  This
will lead to a crash during init of the second GPU since
amdgpu_fence_slab_ref is not 0.

v2: add functions for init/exit instead of
moving the variables into the driver.

Signed-off-by: Rex Zhu 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 25 ++---
 3 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2a009c3..992f00b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -602,6 +602,8 @@ int amdgpu_sync_wait(struct amdgpu_sync *sync);
 void amdgpu_sync_free(struct amdgpu_sync *sync);
 int amdgpu_sync_init(void);
 void amdgpu_sync_fini(void);
+int amdgpu_fence_slab_init(void);
+void amdgpu_fence_slab_fini(void);

 /*
  * GART structures, functions & helpers
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0dee008..6ff5879 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -565,9 +565,12 @@ static struct pci_driver amdgpu_kms_pci_driver = {
.driver.pm = _pm_ops,
 };

+
+
 static int __init amdgpu_init(void)
 {
amdgpu_sync_init();
+   amdgpu_fence_slab_init();
if (vgacon_text_force()) {
DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
return -EINVAL;
@@ -578,7 +581,6 @@ static int __init amdgpu_init(void)
driver->driver_features |= DRIVER_MODESET;
driver->num_ioctls = amdgpu_max_kms_ioctl;
amdgpu_register_atpx_handler();
-
/* let modprobe override vga console setting */
return drm_pci_init(driver, pdriver);
 }
@@ -589,6 +591,7 @@ static void __exit amdgpu_exit(void)
drm_pci_exit(driver, pdriver);
amdgpu_unregister_atpx_handler();
amdgpu_sync_fini();
+   amdgpu_fence_slab_fini();
 }

 module_init(amdgpu_init);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index ba9c042..7eb2fca8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -55,8 +55,21 @@ struct amdgpu_fence {
 };

 static struct kmem_cache *amdgpu_fence_slab;
-static atomic_t amdgpu_fence_slab_ref = ATOMIC_INIT(0);

+int amdgpu_fence_slab_init(void)
+{
+   amdgpu_fence_slab = kmem_cache_create(
+   "amdgpu_fence", sizeof(struct amdgpu_fence), 0,
+   SLAB_HWCACHE_ALIGN, NULL);
+   if (!amdgpu_fence_slab)
+   return -ENOMEM;
+   return 0;
+}
+
+void amdgpu_fence_slab_fini(void)
+{
+   kmem_cache_destroy(amdgpu_fence_slab);
+}
 /*
  * Cast helper
  */
@@ -396,13 +409,6 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring *ring,
  */
 int amdgpu_fence_driver_init(struct amdgpu_device *adev)
 {
-   if (atomic_inc_return(_fence_slab_ref) == 1) {
-   amdgpu_fence_slab = kmem_cache_create(
-   "amdgpu_fence", sizeof(struct amdgpu_fence), 0,
-   SLAB_HWCACHE_ALIGN, NULL);
-   if (!amdgpu_fence_slab)
-   return -ENOMEM;
-   }
if (amdgpu_debugfs_fence_init(adev))
dev_err(adev->dev, "fence debugfs file creation failed\n");

@@ -441,9 +447,6 @@ void amdgpu_fence_driver_fini(struct amdgpu_device *adev)
kfree(ring->fence_drv.fences);
ring->fence_drv.initialized = false;
}
-
-   if (atomic_dec_and_test(_fence_slab_ref))
-   kmem_cache_destroy(amdgpu_fence_slab);
 }

 /**
-- 
2.5.5

[PATCH] drm/amd/powerplay: move asic unrelated function to hwmgr.c.

[Alex Deucher]

From: Rex Zhu 

It's generic and used by multiple asics.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c   | 37 +
 drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 38 ++
 .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c  | 36 
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  2 +-
 4 files changed, 40 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
index c94f9fa..382223b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c
@@ -3573,46 +3573,11 @@ static int fiji_force_dpm_highest(struct pp_hwmgr 
*hwmgr)
return 0;
 }

-static void fiji_apply_dal_min_voltage_request(struct pp_hwmgr *hwmgr)
-{
-   struct phm_ppt_v1_information *table_info =
-   (struct phm_ppt_v1_information *)hwmgr->pptable;
-   struct phm_clock_voltage_dependency_table *table =
-   table_info->vddc_dep_on_dal_pwrl;
-   struct phm_ppt_v1_clock_voltage_dependency_table *vddc_table;
-   enum PP_DAL_POWERLEVEL dal_power_level = hwmgr->dal_power_level;
-   uint32_t req_vddc = 0, req_volt, i;
-
-   if (!table && !(dal_power_level >= PP_DAL_POWERLEVEL_ULTRALOW &&
-   dal_power_level <= PP_DAL_POWERLEVEL_PERFORMANCE))
-   return;
-
-   for (i= 0; i < table->count; i++) {
-   if (dal_power_level == table->entries[i].clk) {
-   req_vddc = table->entries[i].v;
-   break;
-   }
-   }
-
-   vddc_table = table_info->vdd_dep_on_sclk;
-   for (i= 0; i < vddc_table->count; i++) {
-   if (req_vddc <= vddc_table->entries[i].vddc) {
-   req_volt = (((uint32_t)vddc_table->entries[i].vddc) * 
VOLTAGE_SCALE)
-   << VDDC_SHIFT;
-   smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
-   PPSMC_MSG_VddC_Request, req_volt);
-   return;
-   }
-   }
-   printk(KERN_ERR "DAL requested level can not"
-   " found a available voltage in VDDC DPM Table \n");
-}
-
 static int fiji_upload_dpmlevel_enable_mask(struct pp_hwmgr *hwmgr)
 {
struct fiji_hwmgr *data = (struct fiji_hwmgr *)(hwmgr->backend);

-   fiji_apply_dal_min_voltage_request(hwmgr);
+   phm_apply_dal_min_voltage_request(hwmgr);

if (!data->sclk_dpm_key_disabled) {
if (data->dpm_level_enable_mask.sclk_dpm_enable_mask)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index 7d69ed6..1c48917 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -30,6 +30,9 @@
 #include "pppcielanes.h"
 #include "pp_debug.h"
 #include "ppatomctrl.h"
+#include "ppsmc.h"
+
+#define VOLTAGE_SCALE   4

 extern int cz_hwmgr_init(struct pp_hwmgr *hwmgr);
 extern int tonga_hwmgr_init(struct pp_hwmgr *hwmgr);
@@ -566,3 +569,38 @@ uint32_t phm_get_lowest_enabled_level(struct pp_hwmgr 
*hwmgr, uint32_t mask)

return level;
 }
+
+void phm_apply_dal_min_voltage_request(struct pp_hwmgr *hwmgr)
+{
+   struct phm_ppt_v1_information *table_info =
+   (struct phm_ppt_v1_information *)hwmgr->pptable;
+   struct phm_clock_voltage_dependency_table *table =
+   table_info->vddc_dep_on_dal_pwrl;
+   struct phm_ppt_v1_clock_voltage_dependency_table *vddc_table;
+   enum PP_DAL_POWERLEVEL dal_power_level = hwmgr->dal_power_level;
+   uint32_t req_vddc = 0, req_volt, i;
+
+   if (!table || table->count <= 0
+   || dal_power_level < PP_DAL_POWERLEVEL_ULTRALOW
+   || dal_power_level > PP_DAL_POWERLEVEL_PERFORMANCE)
+   return;
+
+   for (i = 0; i < table->count; i++) {
+   if (dal_power_level == table->entries[i].clk) {
+   req_vddc = table->entries[i].v;
+   break;
+   }
+   }
+
+   vddc_table = table_info->vdd_dep_on_sclk;
+   for (i = 0; i < vddc_table->count; i++) {
+   if (req_vddc <= vddc_table->entries[i].vddc) {
+   req_volt = (((uint32_t)vddc_table->entries[i].vddc) * 
VOLTAGE_SCALE);
+   smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
+   PPSMC_MSG_VddC_Request, req_volt);
+   return;
+   }
+   }
+   printk(KERN_ERR "DAL requested level can not"
+   " found a available voltage in VDDC DPM Table \n");
+}
diff --git 

[PATCH] drm/amd/powerplay: fix NULL point check error

[Alex Deucher]

From: Rex Zhu 

&& was used instead of ||

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index 94b2a73..4115dd8 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -199,8 +199,9 @@ void phm_apply_dal_min_voltage_request(struct pp_hwmgr 
*hwmgr)
enum PP_DAL_POWERLEVEL dal_power_level = hwmgr->dal_power_level;
uint32_t req_vddc = 0, req_volt, i;

-   if (!table && !(dal_power_level >= PP_DAL_POWERLEVEL_ULTRALOW &&
-   dal_power_level <= PP_DAL_POWERLEVEL_PERFORMANCE))
+   if (!table || table-count <= 0
+   || dal_power_level < PP_DAL_POWERLEVEL_ULTRALOW
+   || dal_power_level > PP_DAL_POWERLEVEL_PERFORMANCE)
return;

for (i = 0; i < table->count; i++) {
-- 
2.5.5

[PATCH] drm/amd/powerplay: SCLK will have a big drop with low VDDC when PPlib was enabled.

[Alex Deucher]

From: Rex Zhu 

SMC uses CurrSclkPllRange structure to keep track of what range of
PLL SCLK is sitting on.  Driver overwrites this value to 0 because
it's part of DPM table and driver doesn't program this.
This change will set this field to 0xFF every time there's a
init SMC table call.

Signed-off-by: Rex Zhu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index 93768fa..94b2a73 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -2091,7 +2091,7 @@ static int polaris10_init_smc_table(struct pp_hwmgr 
*hwmgr)
"Failed to populate Clock Stretcher Data 
Table!",
return result);
}
-
+   table->CurrSclkPllRange = 0xff;
table->GraphicsVoltageChangeEnable  = 1;
table->GraphicsThermThrottleEnable  = 1;
table->GraphicsInterval = 1;
@@ -2184,6 +2184,7 @@ static int polaris10_init_smc_table(struct pp_hwmgr 
*hwmgr)
CONVERT_FROM_HOST_TO_SMC_UL(table->SmioMask1);
CONVERT_FROM_HOST_TO_SMC_UL(table->SmioMask2);
CONVERT_FROM_HOST_TO_SMC_UL(table->SclkStepSize);
+   CONVERT_FROM_HOST_TO_SMC_UL(table->CurrSclkPllRange);
CONVERT_FROM_HOST_TO_SMC_US(table->TemperatureLimitHigh);
CONVERT_FROM_HOST_TO_SMC_US(table->TemperatureLimitLow);
CONVERT_FROM_HOST_TO_SMC_US(table->VoltageResponseTime);
-- 
2.5.5

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

[Philipp Zabel]

Hi Lothar,

Am Freitag, den 13.05.2016, 12:33 +0200 schrieb Lothar Waßmann:
> Hi,
> 
> the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
> indeed fixes the autoloading issue, but completely breaks the driver in
> non-modular mode (at least with the parallel-display driver I didn't
> yet check with the imx-ldb driver.
> Can anyone confirm that the imx-drm driver in current linux-next
> (next-20160512) works for them with any i.MX6 or i.MX53 board?

I have sent a patch: https://patchwork.kernel.org/patch/9081661/
that I'd appreciate your input on.

regards
Philipp

[PATCH 4/4] tests/amdgpu: adapt to new polaris10/11 uvd fw

[Alex Deucher]

From: Sonny Jiang 

Signed-off-by: Sonny Jiang 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 tests/amdgpu/cs_tests.c | 48 ++--
 1 file changed, 42 insertions(+), 6 deletions(-)

diff --git a/tests/amdgpu/cs_tests.c b/tests/amdgpu/cs_tests.c
index c6930c0..a01ee48 100644
--- a/tests/amdgpu/cs_tests.c
+++ b/tests/amdgpu/cs_tests.c
@@ -43,6 +43,8 @@ static amdgpu_device_handle device_handle;
 static uint32_t major_version;
 static uint32_t minor_version;
 static uint32_t family_id;
+static uint32_t chip_rev;
+static uint32_t chip_id;

 static amdgpu_context_handle context_handle;
 static amdgpu_bo_handle ib_handle;
@@ -78,6 +80,9 @@ int suite_cs_tests_init(void)
return CUE_SINIT_FAILED;

family_id = device_handle->info.family_id;
+   /* VI asic POLARIS10/11 have specific external_rev_id */
+   chip_rev = device_handle->info.chip_rev;
+   chip_id = device_handle->info.chip_external_rev;

r = amdgpu_cs_ctx_create(device_handle, _handle);
if (r)
@@ -200,8 +205,17 @@ static void amdgpu_cs_uvd_create(void)
CU_ASSERT_EQUAL(r, 0);

memcpy(msg, uvd_create_msg, sizeof(uvd_create_msg));
-   if (family_id >= AMDGPU_FAMILY_VI)
+   if (family_id >= AMDGPU_FAMILY_VI) {
((uint8_t*)msg)[0x10] = 7;
+   /* chip polaris 10/11 */
+   if (chip_id == chip_rev+0x50 || chip_id == chip_rev+0x5A) {
+   /* dpb size */
+   ((uint8_t*)msg)[0x28] = 0x00;
+   ((uint8_t*)msg)[0x29] = 0x94;
+   ((uint8_t*)msg)[0x2A] = 0x6B;
+   ((uint8_t*)msg)[0x2B] = 0x00;
+   }
+   }

r = amdgpu_bo_cpu_unmap(buf_handle);
CU_ASSERT_EQUAL(r, 0);
@@ -230,8 +244,8 @@ static void amdgpu_cs_uvd_create(void)

 static void amdgpu_cs_uvd_decode(void)
 {
-   const unsigned dpb_size = 15923584, dt_size = 737280;
-   uint64_t msg_addr, fb_addr, bs_addr, dpb_addr, dt_addr, it_addr;
+   const unsigned dpb_size = 15923584, ctx_size = 5287680, dt_size = 
737280;
+   uint64_t msg_addr, fb_addr, bs_addr, dpb_addr, ctx_addr, dt_addr, 
it_addr;
struct amdgpu_bo_alloc_request req = {0};
amdgpu_bo_handle buf_handle;
amdgpu_va_handle va_handle;
@@ -269,8 +283,21 @@ static void amdgpu_cs_uvd_decode(void)
memcpy(ptr, uvd_decode_msg, sizeof(uvd_create_msg));
if (family_id >= AMDGPU_FAMILY_VI) {
ptr[0x10] = 7;
-   ptr[0x98] = 0xb0;
-   ptr[0x99] = 0x1;
+   ptr[0x98] = 0x00;
+   ptr[0x99] = 0x02;
+   /* chip polaris10/11 */
+   if (chip_id == chip_rev+0x50 || chip_id == chip_rev+0x5A) {
+   /*dpb size */
+   ptr[0x24] = 0x00;
+   ptr[0x25] = 0x94;
+   ptr[0x26] = 0x6B;
+   ptr[0x27] = 0x00;
+   /*ctx size */
+   ptr[0x2C] = 0x00;
+   ptr[0x2D] = 0xAF;
+   ptr[0x2E] = 0x50;
+   ptr[0x2F] = 0x00;
+   }
}

ptr += 4*1024;
@@ -301,6 +328,12 @@ static void amdgpu_cs_uvd_decode(void)
} else
bs_addr = fb_addr + 4*1024;
dpb_addr = ALIGN(bs_addr + sizeof(uvd_bitstream), 4*1024);
+
+   if ((family_id >= AMDGPU_FAMILY_VI) &&
+   (chip_id == chip_rev+0x50 || chip_id == chip_rev+0x5A)) {
+   ctx_addr = ALIGN(dpb_addr + 0x006B9400, 4*1024);
+   }
+
dt_addr = ALIGN(dpb_addr + dpb_size, 4*1024);

i = 0;
@@ -309,8 +342,11 @@ static void amdgpu_cs_uvd_decode(void)
uvd_cmd(dt_addr, 0x2, );
uvd_cmd(fb_addr, 0x3, );
uvd_cmd(bs_addr, 0x100, );
-   if (family_id >= AMDGPU_FAMILY_VI)
+   if (family_id >= AMDGPU_FAMILY_VI) {
uvd_cmd(it_addr, 0x204, );
+   if (chip_id == chip_rev+0x50 || chip_id == chip_rev+0x5A)
+   uvd_cmd(ctx_addr, 0x206, );
+}
ib_cpu[i++] = 0x3BC6;
ib_cpu[i++] = 0x1;
for (; i % 16; ++i)
-- 
2.5.5

[PATCH 3/4] tests/amdgpu: add interface to adapt firmware requirement

[Alex Deucher]

From: Leo Liu 

Signed-off-by: Leo Liu 
Reviewed-by: Alex Deucher 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 tests/amdgpu/cs_tests.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/amdgpu/cs_tests.c b/tests/amdgpu/cs_tests.c
index dfbf5af..c6930c0 100644
--- a/tests/amdgpu/cs_tests.c
+++ b/tests/amdgpu/cs_tests.c
@@ -266,9 +266,12 @@ static void amdgpu_cs_uvd_decode(void)
r = amdgpu_bo_cpu_map(buf_handle, (void **));
CU_ASSERT_EQUAL(r, 0);

-   memcpy(ptr, uvd_decode_msg, sizeof(uvd_decode_msg));
-   if (family_id >= AMDGPU_FAMILY_VI)
+   memcpy(ptr, uvd_decode_msg, sizeof(uvd_create_msg));
+   if (family_id >= AMDGPU_FAMILY_VI) {
ptr[0x10] = 7;
+   ptr[0x98] = 0xb0;
+   ptr[0x99] = 0x1;
+   }

ptr += 4*1024;
memset(ptr, 0, 4*1024);
-- 
2.5.5

[PATCH 2/4] tests/amdgpu: expand write/copy tests to compute

[Alex Deucher]

Signed-off-by: Alex Deucher 
---
 tests/amdgpu/basic_tests.c | 41 ++---
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 05ab145..e512bda 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -445,17 +445,17 @@ static void amdgpu_command_submission_gfx_shared_ib(void)
CU_ASSERT_EQUAL(r, 0);
 }

-static void amdgpu_command_submission_cp_write_data(void)
+static void amdgpu_command_submission_gfx_cp_write_data(void)
 {
amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_GFX);
 }

-static void amdgpu_command_submission_cp_const_fill(void)
+static void amdgpu_command_submission_gfx_cp_const_fill(void)
 {
amdgpu_command_submission_const_fill_helper(AMDGPU_HW_IP_GFX);
 }

-static void amdgpu_command_submission_cp_copy_data(void)
+static void amdgpu_command_submission_gfx_cp_copy_data(void)
 {
amdgpu_command_submission_copy_linear_helper(AMDGPU_HW_IP_GFX);
 }
@@ -463,11 +463,11 @@ static void amdgpu_command_submission_cp_copy_data(void)
 static void amdgpu_command_submission_gfx(void)
 {
/* write data using the CP */
-   amdgpu_command_submission_cp_write_data();
+   amdgpu_command_submission_gfx_cp_write_data();
/* const fill using the CP */
-   amdgpu_command_submission_cp_const_fill();
+   amdgpu_command_submission_gfx_cp_const_fill();
/* copy data using the CP */
-   amdgpu_command_submission_cp_copy_data();
+   amdgpu_command_submission_gfx_cp_copy_data();
/* separate IB buffers for multi-IB submission */
amdgpu_command_submission_gfx_separate_ibs();
/* shared IB buffer for multi-IB submission */
@@ -602,7 +602,7 @@ static void amdgpu_semaphore_test(void)
CU_ASSERT_EQUAL(r, 0);
 }

-static void amdgpu_command_submission_compute(void)
+static void amdgpu_command_submission_compute_nop(void)
 {
amdgpu_context_handle context_handle;
amdgpu_bo_handle ib_result_handle;
@@ -673,6 +673,33 @@ static void amdgpu_command_submission_compute(void)
CU_ASSERT_EQUAL(r, 0);
 }

+static void amdgpu_command_submission_compute_cp_write_data(void)
+{
+   amdgpu_command_submission_write_linear_helper(AMDGPU_HW_IP_COMPUTE);
+}
+
+static void amdgpu_command_submission_compute_cp_const_fill(void)
+{
+   amdgpu_command_submission_const_fill_helper(AMDGPU_HW_IP_COMPUTE);
+}
+
+static void amdgpu_command_submission_compute_cp_copy_data(void)
+{
+   amdgpu_command_submission_copy_linear_helper(AMDGPU_HW_IP_COMPUTE);
+}
+
+static void amdgpu_command_submission_compute(void)
+{
+   /* write data using the CP */
+   amdgpu_command_submission_compute_cp_write_data();
+   /* const fill using the CP */
+   amdgpu_command_submission_compute_cp_const_fill();
+   /* copy data using the CP */
+   amdgpu_command_submission_compute_cp_copy_data();
+   /* nop test */
+   amdgpu_command_submission_compute_nop();
+}
+
 /*
  * caller need create/release:
  * pm4_src, resources, ib_info, and ibs_request
-- 
2.5.5

[PATCH 1/4] tests/amdgpu: expand write/copy tests to compute

[Alex Deucher]

Uses same packets as gfx.

Signed-off-by: Alex Deucher 
---
 tests/amdgpu/basic_tests.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 599c090..05ab145 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -813,7 +813,8 @@ static void 
amdgpu_command_submission_write_linear_helper(unsigned ip_type)
pm4[i++] = sdma_write_length;
while(j++ < sdma_write_length)
pm4[i++] = 0xdeadbeaf;
-   } else if (ip_type == AMDGPU_HW_IP_GFX) {
+   } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
+  (ip_type == AMDGPU_HW_IP_COMPUTE)) {
pm4[i++] = PACKET3(PACKET3_WRITE_DATA, 2 + 
sdma_write_length);
pm4[i++] = WRITE_DATA_DST_SEL(5) | WR_CONFIRM;
pm4[i++] = 0xfffc & bo_mc;
@@ -911,7 +912,8 @@ static void 
amdgpu_command_submission_const_fill_helper(unsigned ip_type)
pm4[i++] = (0x & bo_mc) >> 32;
pm4[i++] = 0xdeadbeaf;
pm4[i++] = sdma_write_length;
-   } else if (ip_type == AMDGPU_HW_IP_GFX) {
+   } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
+  (ip_type == AMDGPU_HW_IP_COMPUTE)) {
pm4[i++] = PACKET3(PACKET3_DMA_DATA, 5);
pm4[i++] = PACKET3_DMA_DATA_ENGINE(0) |
PACKET3_DMA_DATA_DST_SEL(0) |
@@ -1030,7 +1032,8 @@ static void 
amdgpu_command_submission_copy_linear_helper(unsigned ip_type)
pm4[i++] = (0x & bo1_mc) >> 32;
pm4[i++] = 0x & bo2_mc;
pm4[i++] = (0x & bo2_mc) >> 32;
-   } else if (ip_type == AMDGPU_HW_IP_GFX) {
+   } else if ((ip_type == AMDGPU_HW_IP_GFX) ||
+  (ip_type == AMDGPU_HW_IP_COMPUTE)) {
pm4[i++] = PACKET3(PACKET3_DMA_DATA, 5);
pm4[i++] = PACKET3_DMA_DATA_ENGINE(0) |
PACKET3_DMA_DATA_DST_SEL(0) |
-- 
2.5.5

[GIT PULL] drm-vc4-next-2016-05-13

[Eric Anholt]

Here are a few late bugfixes for vc4.  I figure it's best to bring
them in through -next since 4.6 is about done.  I've based them late
in your -next branch to avoid needing conflict resolution.

The following changes since commit bafb86f5bc3173479002555dea7f31d943b12332:

  Merge tag 'v4.6-rc7' into drm-next (2016-05-09 13:49:56 +1000)

are available in the git repository at:

  https://github.com/anholt/linux tags/drm-vc4-next-2016-05-13

for you to fetch changes up to efea172891fc32928291a633c17a146338a73ba9:

  drm/vc4: Return -EBUSY if there's already a pending flip event. (2016-05-09 
18:31:33 -0700)


This pull request brings in a few fixes for vc4 pageflipping.


Mario Kleiner (2):
  drm/vc4: Fix get_vblank_counter with proper no-op for Linux 4.4+
  drm/vc4: Fix drm_vblank_put/get imbalance in page flip path.

Robert Foss (1):
  drm/vc4: Return -EBUSY if there's already a pending flip event.

 drivers/gpu/drm/vc4/vc4_crtc.c |  4 
 drivers/gpu/drm/vc4/vc4_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c  | 16 
 3 files changed, 17 insertions(+), 5 deletions(-)

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

[Lothar Waßmann]

Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
indeed fixes the autoloading issue, but completely breaks the driver in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?

I'm always very suspicious when seeing code moving of_node's from
one device to another or assigning of_node's to platform devices that
weren't instantiated via DT.


Lothar Waßmann

[RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Thu, 2016-05-12 at 19:49 +0800, yt.shen at mediatek.com wrote:
> From: YT Shen 
> 
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701, and we have shadow
> register support here.
> 
> Signed-off-by: YT Shen 
> ---

> @@ -385,12 +422,16 @@ static void mtk_drm_crtc_atomic_begin(struct drm_crtc 
> *crtc,
>   mtk_crtc->event = state->base.event;
>   state->base.event = NULL;
>   }
> +
> + if (priv->data->shadow_register)
> + mtk_disp_mutex_acquire(mtk_crtc->mutex);
>  }
>  
> @@ -409,6 +450,11 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   }
>   if (pending_planes)
>   mtk_crtc->pending_planes = true;
> +
> + if (priv->data->shadow_register) {
> + mtk_crtc_ddp_config(crtc);
> + mtk_disp_mutex_release(mtk_crtc->mutex);
> + }
>  }
>  

I think it's better to call mtk_disp_mutex_acquire() and
mtk_disp_mutex_release() as near as possible to prevent mutex locked for
a long time. All HW register access of this atomic setting is in
mtk_crtc_ddp_config(), so it's better to move mtk_disp_mutex_acquire()
just before mtk_crtc_ddp_config().

Regards,
CK

[PATCH v2 1/2] PM / Domains: Allow genpd to power on during the system PM phase

[Kevin Hilman]

Ulf Hansson  writes:

> On 11 May 2016 at 23:25, Rafael J. Wysocki  wrote:
>> On Wed, May 11, 2016 at 10:00 AM, Ulf Hansson  
>> wrote:
>>> If the PM domain is powered off when the first device in the domain starts
>>> its system PM prepare phase, genpd prevents any further attempts to power
>>> on the PM domain during the system PM phase. This constraint affects not
>>> only the current device which is being prepared, but all devices within
>>> the same PM domain.
>>
>> What exactly do you mean by "the system PM phase"?
>
> In between system PM device prepare and system PM device complete.
>
> Do you want me to clarify this in a better way in the change log?

It might be more clear if you something like "during system suspend/resume"

Kevin

Small vc4 kms fixes and some questions.

[Eric Anholt]

Mario Kleiner  writes:

> On 05/09/2016 09:38 PM, Eric Anholt wrote:
>> Mario Kleiner  writes:
>>
>>> Hi Eric and all,
>>>
>>> two small fixes against vc4 kms, built and tested agains the
>>> Raspberry Pi foundations 4.4.8 kernel tree on RPi2B.
>>>
>>> I'm tinkering with a Rpi 2B a bit to see if your vc4 work can
>>> already make the Pi useful as a device for some serious but low
>>> cost neuro-science applications.
>>>
>>> Eric:
>>>
>>> Is there any public documentation about the HVS hardware video scaler
>>> or the pixel valves? I could find other docs about Videocore's 3d
>>> part, but nothing about hvs or the pixel valves? Or are the register
>>> definitions inside the vc4 already all that exists in the hw?
>>
>> Nope, docs for display never got released.  I've got docs internally,
>> and I'm happy to try to answer questions.
>>
>
> Ah good. My questions are around making the pageflip completion events 
> and vblank timestamps as precise and reliable as possible.
>
> Atm. i'm working on a patch to the flip completion handling to make it 
> more robust. The current code in my stress tests with 1 flips sends 
> out flip completions too early in about 1-2% of the trials.
>
> My current patch reduces these to 0 failures in my test. I'll send the 
> patch out later after some more tweaking and cleanup.
>
> E.g., for crtc/pixelvalve 1 the patch checks if the SCALER_DISPLIST1 and 
> SCALER_DISPLACT1 registers in the HVS match, and only then sends out the 
> pageflip completion event, otherwise waits for the next vblank. I assume 
> SCALER_DISPLACT1 is the true current value for start of active display 
> list whereas SCALER_DISPLIST1 is the value that got latched and then 
> gets committed at the next vblank after writing to the reg. This seems 
> to work well according to my special measurement equipment which can 
> timestamp the true start of display of a new framebuffer.

Oh, interesting.  The docs had said that the display lists were
re-parsed on every line, so I assumed that also meant that the reparsing
started from the head pointer every line.  I've confirmed in the
hardware what you've found: the head pointer is only latched at VSTART
or INIT signal to the display fifo (that start signal comes from the
pixel valve).

> However i don't know if this already perfect, or just strongly reduced 
> error rate, so i need to know when the value gets committed (start of 
> vblank, end of vblank, vsync)? And when does the vblank irq fire for the 
> different possible settings of:
>
> # define PV_INT_VID_IDLEBIT(9)
> # define PV_INT_VFP_END BIT(8)
> # define PV_INT_VFP_START   BIT(7)
> # define PV_INT_VACT_START  BIT(6)
> # define PV_INT_VBP_START   BIT(5)
> # define PV_INT_VSYNC_START BIT(4)
>
> Currently the driver uses PV_INT_VFP_START.

OK, looks like the PV timing state is:

IDLE
START
(vfp lines)
VSYNC
(vsw lines)
VBP
(vbp lines)
VACT
(vact lines)
VFP
(jump to waiting for vfp lines)

The normal timing loop after START does its transitions at HFP, and
those transitions are when you get the VFP/VBP/VSYNC START/END
interrupts.

You'll jump back to IDLE almost right away if VID_EN is dropped.

The VSTART signal to the HVS is when PV does IDLE -> START or on the
last pixel of the active scanout.  Note, this is *not* the PV's START
signal, which looks like it's basically unused.  Also, I think it's an
interesting note that we don't have VFP_START on our first frame, as far
as I've found.

The PV requests that the HVS generate the next line at the last pixel of
each HACTIVE when we're either at end of VBP or VACTIVE-but-not-its-end.

> The second question is if the HVS or pixelvalves have some kind of 
> scanline register that reports the currently scanned out scanline? I'd 
> like to implement scanout position queries, so we can get instant high 
> precision vblank timestamps if possible like we have for intel, amd and 
> nouveau, so we'd have precise timestamps, a vblank counter and also 
> additional power savings. Or lacking that are there other regs that 
> could be used to timestamp vblanks or updates of display lists in the 
> hardware?

HVS has bits 0:11 of DISPSTATx for the Y line being generated.  That
will be in a different clock domain from the PV, but it's probably good
enough, right?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160513/d8d07273/attachment.sig>

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

[Russell King - ARM Linux]

On Fri, May 13, 2016 at 12:33:36PM +0200, Lothar Waßmann wrote:
> I'm always very suspicious when seeing code moving of_node's from
> one device to another or assigning of_node's to platform devices that
> weren't instantiated via DT.

It's completely wrong to add an of_node to a device on the same bus
that already has a device with the same of_node - doing so means
that the bus matching code will match the same device driver to both
devices, which may not be what you want to happen.

Just don't do it, it's a bug waiting to happen.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] MAINTAINERS: add entry for the Sync File Framework

[Gustavo Padovan]

From: Gustavo Padovan 

Add Gustavo as maintainer for the Sync File Framework. Sumit is
co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
tree as base.

Signed-off-by: Gustavo Padovan 
Acked-by: Sumit Semwal 
Acked-by: Maarten Lankhorst 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c10b4c..71c4e7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3677,6 +3677,17 @@ F:   include/linux/*fence.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

+SYNC FILE FRAMEWORK
+M: Sumit Semwal 
+R: Gustavo Padovan 
+S: Maintained
+L: linux-media at vger.kernel.org
+L: dri-devel at lists.freedesktop.org
+F: drivers/dma-buf/sync_file.c
+F: include/linux/sync_file.h
+F: Documentation/sync_file.txt
+T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
+
 DMA GENERIC OFFLOAD ENGINE SUBSYSTEM
 M: Vinod Koul 
 L: dmaengine at vger.kernel.org
-- 
2.5.5

[PATCH v3 4/4] drm: rcar: use generic code for managing zpos plane property

[Benjamin Gaignard]

This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Laurent Pinchart 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
 5 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..28d2cb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index e70a4f3..4ace0aa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 8460ae1..4764afc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -656,7 +656,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -674,8 +674,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -694,8 +692,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -767,8 +763,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
-- 
1.9.1

[PATCH v3 3/4] drm/exynos: use generic code for managing zpos plane property

[Benjamin Gaignard]

From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 50185ac..bbaf6d3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private 

[PATCH v3 2/4] drm: sti: use generic zpos for plane

[Benjamin Gaignard]

remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_mixer.c |  9 ++---
 drivers/gpu/drm/sti/sti_plane.c | 80 +++--
 drivers/gpu/drm/sti/sti_plane.h |  2 --
 3 files changed, 31 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index e7425c3..d93f537 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -245,13 +245,10 @@ static void sti_mixer_set_background_area(struct 
sti_mixer *mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;

-   if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
-   return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -284,8 +281,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer, 
struct sti_plane *plane)
break;
}

-   mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
-   plane_id = plane_id << (3 * (depth - 1));
+   mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+   plane_id = plane_id << (3 * depth);

DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
 sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index f10c98d..0e447d9 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -114,69 +105,54 @@ static void sti_plane_destroy(struct drm_plane *drm_plane)
drm_plane_cleanup(drm_plane);
 }

-static int sti_plane_set_property(struct drm_plane *drm_plane,
- struct drm_property *property,
- uint64_t val)
+static int sti_plane_get_default_zpos(enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (property == private->plane_zorder_property) {
-   plane->zorder = val;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
return 0;
+   case DRM_PLANE_TYPE_OVERLAY:
+   return 1;
+   case DRM_PLANE_TYPE_CURSOR:
+   return 7;
}
+   return 0;
+}

-   return -EINVAL;
+static void sti_plane_reset(struct drm_plane *plane)
+{
+   drm_atomic_helper_plane_reset(plane);
+   plane->state->zpos = sti_plane_get_default_zpos(plane->type);
 }

-static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
+static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane,
+enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-   struct drm_property *prop;
-
-   prop = private->plane_zorder_property;
-   if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 1,
-GAM_MIXER_NB_DEPTH_LEVEL);
-   if (!prop)
-   return;
-
-   private->plane_zorder_property = prop;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
+   case DRM_PLANE_TYPE_OVERLAY:
+   drm_plane_create_zpos_property(drm_plane, 0, 6);
+   break;
+   case DRM_PLANE_TYPE_CURSOR:
+   drm_plane_create_zpos_immutable_property(drm_plane, 7, 7);
+   break;
}
-
-   drm_object_attach_property(_plane->base, prop, plane->zorder);
 }

 void sti_plane_init_property(struct sti_plane *plane,
 enum drm_plane_type type)
 {
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(sti_plane_default_zorder); i++)
-   if (sti_plane_default_zorder[i] == plane->desc)
-   

[PATCH v3 1/4] drm: add generic zpos property

[Benjamin Gaignard]

From: Marek Szyprowski 

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 Documentation/DocBook/gpu.tmpl  |  10 ++
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_atomic.c|   4 +
 drivers/gpu/drm/drm_atomic_helper.c |   6 +
 drivers/gpu/drm/drm_blend.c | 226 
 drivers/gpu/drm/drm_crtc_internal.h |   3 +
 include/drm/drm_crtc.h  |  28 +
 7 files changed, 278 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9dd48f7..0df6abb 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
the underlying hardware).


+"zpos" 
+   RANGE
+   Min= driver dependent, Max= driver dependent
+   Plane
+   Plane's 'z' position during blending operation (0 for 
background, highest for frontmost).
+   If two planes assigned to same CRTC have equal zpos values, the 
plane with higher plane
+   id is treated as closer to front. Can be IMMUTABLE if driver 
doesn't support changing
+   planes' order. Exact value range is driver dependent.
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..df88253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 86e89db..bd457ca 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -700,6 +700,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == plane->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -756,6 +758,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == plane->zpos_property) {
+   *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 997fd21..f10652f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 

+#include "drm_crtc_internal.h"
+
 /**
  * DOC: overview
  *
@@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

+   ret = drm_atomic_helper_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/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644

[PATCH v3 0/4] Generic zpos property

[Benjamin Gaignard]

version 3:
use kmalloc_array instead of kmalloc.
Correct normalize_zpos computation (comeback to Mareck original code)

version 2:
add a zpos property into drm_plane structure to simplify code.
This allow to get/set zpos value in core and not in drivers code.
Fix various remarks.

version 1:
refactor Marek's patches to have per plane zpos property instead of only
one in core.

Benjamin Gaignard (2):
  drm: sti: use generic zpos for plane
  drm: rcar: use generic code for managing zpos plane property

Marek Szyprowski (2):
  drm: add generic zpos property
  drm/exynos: use generic code for managing zpos plane property

 Documentation/DocBook/gpu.tmpl|  10 ++
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_atomic.c  |   4 +
 drivers/gpu/drm/drm_atomic_helper.c   |   6 +
 drivers/gpu/drm/drm_blend.c   | 226 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  67 ++---
 drivers/gpu/drm/exynos/exynos_mixer.c |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |   1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   |   9 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   |   2 -
 drivers/gpu/drm/sti/sti_mixer.c   |   9 +-
 drivers/gpu/drm/sti/sti_plane.c   |  80 ---
 drivers/gpu/drm/sti/sti_plane.h   |   2 -
 include/drm/drm_crtc.h|  28 
 18 files changed, 325 insertions(+), 139 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
-- 
1.9.1

[PATCH radeon] Change the default to PCI on PowerPC

[Mathieu Malaterre]

AGP mode is unstable on PowerPC

Signed-off-by: Mathieu Malaterre 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index ccd4ad4..402cf85 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -170,7 +170,12 @@ int radeon_no_wb;
 int radeon_modeset = -1;
 int radeon_dynclks = -1;
 int radeon_r4xx_atom = 0;
+#ifdef __powerpc__
+/* Default to PCI on PowerPC (fdo #95017) */
+int radeon_agpmode = -1;
+#else
 int radeon_agpmode = 0;
+#endif
 int radeon_vram_limit = 0;
 int radeon_gart_size = -1; /* auto */
 int radeon_benchmarking = 0;
-- 
2.1.4

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

A bunch of radeon displayport mode setting fixes, and some misc
i915 fixes. There is one revert, the MST audio code in i915 was causing
some oopses, so we've decided just to drop it until next kernel when
we can fix it properly.

Thanks,
Dave.

The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99:

  Linux 4.6-rc7 (2016-05-08 14:38:32 -0700)

are available in the git repository at:

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

for you to fetch changes up to e02aacb6dec0c656379f0c1ff06c5bbb2bcb1e53:

  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-05-13 16:03:39 +1000)


Alex Deucher (2):
  drm/radeon: fix DP mode validation
  drm/amdgpu: fix DP mode validation

Arindam Nath (1):
  drm/radeon: fix DP link training issue with second 4K monitor

Daniel Vetter (1):
  drm/i915: Bail out of pipe config compute loop on LPT

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2016-05-11' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Imre Deak (1):
  drm/i915/bdw: Add missing delay during L3 SQC credit programming

Jani Nikula (1):
  drm/i915/lvds: separate border enable readout from panel fitter

Lucas Stach (1):
  drm/radeon: fix PLL sharing on DCE6.1 (v2)

Lyude (1):
  Revert "drm/i915: start adding dp mst audio"

Ville Syrjälä (1):
  drm/i915: Update CDCLK_FREQ register on BDW after changing cdclk frequency

 drivers/gpu/drm/amd/amdgpu/atombios_dp.c |  4 ++--
 drivers/gpu/drm/i915/i915_debugfs.c  | 16 
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_audio.c   |  9 +++--
 drivers/gpu/drm/i915/intel_crt.c |  8 +++-
 drivers/gpu/drm/i915/intel_ddi.c | 24 +---
 drivers/gpu/drm/i915/intel_display.c |  5 ++---
 drivers/gpu/drm/i915/intel_dp_mst.c  | 22 --
 drivers/gpu/drm/i915/intel_drv.h |  2 --
 drivers/gpu/drm/i915/intel_lvds.c|  4 
 drivers/gpu/drm/i915/intel_pm.c  |  6 ++
 drivers/gpu/drm/radeon/atombios_crtc.c   | 10 ++
 drivers/gpu/drm/radeon/atombios_dp.c |  4 ++--
 drivers/gpu/drm/radeon/radeon_dp_auxch.c |  2 +-
 14 files changed, 44 insertions(+), 74 deletions(-)

Small vc4 kms fixes and some questions.

[Mario Kleiner]

On 05/09/2016 09:38 PM, Eric Anholt wrote:
> Mario Kleiner  writes:
>
>> Hi Eric and all,
>>
>> two small fixes against vc4 kms, built and tested agains the
>> Raspberry Pi foundations 4.4.8 kernel tree on RPi2B.
>>
>> I'm tinkering with a Rpi 2B a bit to see if your vc4 work can
>> already make the Pi useful as a device for some serious but low
>> cost neuro-science applications.
>>
>> Eric:
>>
>> Is there any public documentation about the HVS hardware video scaler
>> or the pixel valves? I could find other docs about Videocore's 3d
>> part, but nothing about hvs or the pixel valves? Or are the register
>> definitions inside the vc4 already all that exists in the hw?
>
> Nope, docs for display never got released.  I've got docs internally,
> and I'm happy to try to answer questions.
>

Ah good. My questions are around making the pageflip completion events 
and vblank timestamps as precise and reliable as possible.

Atm. i'm working on a patch to the flip completion handling to make it 
more robust. The current code in my stress tests with 1 flips sends 
out flip completions too early in about 1-2% of the trials.

My current patch reduces these to 0 failures in my test. I'll send the 
patch out later after some more tweaking and cleanup.

E.g., for crtc/pixelvalve 1 the patch checks if the SCALER_DISPLIST1 and 
SCALER_DISPLACT1 registers in the HVS match, and only then sends out the 
pageflip completion event, otherwise waits for the next vblank. I assume 
SCALER_DISPLACT1 is the true current value for start of active display 
list whereas SCALER_DISPLIST1 is the value that got latched and then 
gets committed at the next vblank after writing to the reg. This seems 
to work well according to my special measurement equipment which can 
timestamp the true start of display of a new framebuffer.

However i don't know if this already perfect, or just strongly reduced 
error rate, so i need to know when the value gets committed (start of 
vblank, end of vblank, vsync)? And when does the vblank irq fire for the 
different possible settings of:

# define PV_INT_VID_IDLEBIT(9)
# define PV_INT_VFP_END BIT(8)
# define PV_INT_VFP_START   BIT(7)
# define PV_INT_VACT_START  BIT(6)
# define PV_INT_VBP_START   BIT(5)
# define PV_INT_VSYNC_START BIT(4)

Currently the driver uses PV_INT_VFP_START.

The second question is if the HVS or pixelvalves have some kind of 
scanline register that reports the currently scanned out scanline? I'd 
like to implement scanout position queries, so we can get instant high 
precision vblank timestamps if possible like we have for intel, amd and 
nouveau, so we'd have precise timestamps, a vblank counter and also 
additional power savings. Or lacking that are there other regs that 
could be used to timestamp vblanks or updates of display lists in the 
hardware?

thanks,
-mario


>> Is the drm-next tree supposed to boot and work on the Pi already.
>> To me it's a bit confusing against which tree i should actually
>> work and test if i play with patches for vc4? drm-next, one of
>> your many branches, RPi foundation? So far i was unsuccessful in
>> booting kernels i built myself following tutorials. Building worked
>> without error or warning, but booting never made it beyond the Pi's
>> firmware startup splash.
>
> drm-next won't have the devicetree necessary, but linux-next does.  I've
> been doing a lot of my development off of linux-next these days.
>
> I've been using u-boot with all of my upstream kernel development
> (netbooting, since swapping SD cards around is awful).  Apparently for
> non-uboot there was some weirdness with the firmware where you needed to
> do non-standard things to the kernel image to get it to boot, which
> u-boot's kernel included, and then u-boot could load a normal linux
> kernel.  I think that's been changed in the firmware in the last couple
> of weeks, though, so you might not need the weird scripting any more.
>

XDC 2016 : Call for paper

[Martin Peres]

Hello,

I have the pleasure to announce that the X.org Developer Conference 2016
will be held in Helsinki from September 21 to September 23. The venue is
located at Haaga-Helia university[0], next to the Pasila station.

The official page for the event is http://www.x.org/wiki/Events/XDC2016
while the call for paper is at http://www.x.org/wiki/Other/Press/CFP2016/

As usual, we are open to talks across the layers of the graphics stack, from
the kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. If you're not sure
if something might fit, mail me or add it to the ideas list found in the
program page.

The conference is free of charge and opened to the general public. If
you plan on coming, please add yourself to the attendees list. We'll
use this list to make badges and plan for the catering, so if you are
attending please add your name as early as possible.

I am looking forward to seeing you there, if you have any
inquiries/questions, please send them to me (please also CC: board at
foundation.x.org).

Martin Peres

[0] 
https://www.google.fi/maps/place/Ratapihantie+13,+00520+Helsinki/@60.2013725,24.931852,17z/data=!3m1!4b1!4m5!3m4!1s0x469209921fdba137:0x841c90a2862185af!8m2!3d60.2013725!4d24.9340407

[PATCH] xf86drm: ensure proper alignment of pointers in drmProcessPciDevice

[Nicolai Hähnle]

From: Nicolai Hähnle 

Previously, (*device)->businfo.pci would end up misaligned, which results
in undefined behavior.

Signed-off-by: Nicolai Hähnle 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 5f587d9..94efc08 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3000,7 +3000,7 @@ static int drmProcessPciDevice(drmDevicePtr *device, 
const char *d_name,
const char *node, int node_type,
int maj, int min, bool fetch_deviceinfo)
 {
-const int max_node_str = drmGetMaxNodeName();
+const int max_node_str = ALIGN(drmGetMaxNodeName(), sizeof(void *));
 int ret, i;
 char *addr;

-- 
2.7.4

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

I kinda hoped that I could still sneak in Noralf's
drm_simple_display_pipe, since there's intereset by others now (for tilcdc
at least). But it wasn't ready by a hair. Oh well.

Otherwise random stuff plus prep patches from Noralf.

Cheers, Daniel


The following changes since commit 8863dc7f5642737e49ff681cbb842d2c614bdcf4:

  drm/i915: Correctly refcount connectors in hw state readou (2016-05-06 
16:09:12 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-05-13

for you to fetch changes up to 9ecb549867d7f642f0379f574f0e52870009a8bf:

  drm/atomic: Add drm_atomic_helper_best_encoder() (2016-05-11 18:55:16 +0200)


Arnd Bergmann (1):
  drm/sti: include linux/seq_file.h where needed

Daniel Vetter (2):
  drm/exynos: Use lockless gem BO free callback
  drm/tegra: Use lockless gem BO free callback

Noralf Trønnes (5):
  drm: Make drm_encoder_helper_funcs optional
  drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs
  drm/fb-cma-helper: Hook up to DocBook and fix some docs
  drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
  drm/atomic: Add drm_atomic_helper_best_encoder()

 Documentation/DocBook/gpu.tmpl  |  5 
 drivers/gpu/drm/drm_atomic_helper.c | 49 +++--
 drivers/gpu/drm/drm_crtc_helper.c   | 41 +--
 drivers/gpu/drm/drm_fb_cma_helper.c |  8 ++
 drivers/gpu/drm/drm_fb_helper.c | 16 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  2 +-
 drivers/gpu/drm/sti/sti_cursor.c|  2 ++
 drivers/gpu/drm/sti/sti_gdp.c   |  1 +
 drivers/gpu/drm/sti/sti_hda.c   |  1 +
 drivers/gpu/drm/sti/sti_hqvdp.c |  1 +
 drivers/gpu/drm/sti/sti_mixer.c |  1 +
 drivers/gpu/drm/sti/sti_tvout.c |  1 +
 drivers/gpu/drm/sti/sti_vid.c   |  1 +
 drivers/gpu/drm/tegra/drm.c |  2 +-
 include/drm/drm_atomic_helper.h |  2 ++
 15 files changed, 95 insertions(+), 38 deletions(-)

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

[PATCH 1/4] drm: add generic zpos property

[Ville Syrjälä]

On Thu, May 12, 2016 at 11:15:42PM +0300, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Thursday 12 May 2016 22:46:05 Ville Syrjälä wrote:
> > On Thu, May 12, 2016 at 10:20:12PM +0300, Laurent Pinchart wrote:
> > > On Thursday 12 May 2016 14:51:55 Ville Syrjälä wrote:
> > >> On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> > >>> From: Marek Szyprowski 
> > >>> 
> > >>> This patch adds support for generic plane's zpos property property
> > >>> with well-defined semantics:
> > >>> - added zpos properties to plane and plane state structures
> > >>> - added helpers for normalizing zpos properties of given set of planes
> > >>> - well defined semantics: planes are sorted by zpos values and then
> > >>>   plane id value if zpos equals
> > >>> 
> > >>> Normalized zpos values are calculated automatically when generic
> > >>> muttable zpos property has been initialized. Drivers can simply use
> > >>> plane_state->normalized_zpos in their atomic_check and/or plane_update
> > >>> callbacks without any additional calls to DRM core.
> > >>> 
> > >>> Signed-off-by: Marek Szyprowski 
> > >>> 
> > >>> Compare to Marek's original patch zpos property is now specific to
> > >>> each plane and no more to the core.
> > >>> Normalize function take care of the range of per plane defined range
> > >>> before set normalized_zpos.
> > >>> 
> > >>> Signed-off-by: Benjamin Gaignard 
> > >>> 
> > >>> Cc: Inki Dae 
> > >>> Cc: Daniel Vetter 
> > >>> Cc: Ville Syrjala 
> > >>> Cc: Joonyoung Shim 
> > >>> Cc: Seung-Woo Kim 
> > >>> Cc: Andrzej Hajda 
> > >>> Cc: Krzysztof Kozlowski 
> > >>> Cc: Bartlomiej Zolnierkiewicz 
> > >>> Cc: Tobias Jakobi 
> > >>> Cc: Gustavo Padovan 
> > >>> Cc: vincent.abriou at st.com
> > >>> Cc: fabien.dessenne at st.com
> > >>> Cc: Laurent Pinchart 
> > >>> ---
> > >>> 
> > >>>  Documentation/DocBook/gpu.tmpl  |  10 ++
> > >>>  drivers/gpu/drm/Makefile|   2 +-
> > >>>  drivers/gpu/drm/drm_atomic.c|   4 +
> > >>>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> > >>>  drivers/gpu/drm/drm_blend.c | 229 
> > >>>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
> > >>>  include/drm/drm_crtc.h  |  28 +
> > >>>  7 files changed, 281 insertions(+), 1 deletion(-)
> > >>>  create mode 100644 drivers/gpu/drm/drm_blend.c
> > > 
> > > [snip]
> > > 
> > >>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > >>> new file mode 100644
> > >>> index 000..eef59bb
> > >>> --- /dev/null
> > >>> +++ b/drivers/gpu/drm/drm_blend.c
> > >>> @@ -0,0 +1,229 @@
> > > 
> > > [snip]
> > > 
> > >>> +static int drm_atomic_state_zpos_cmp(const void *a, const void *b)
> > >>> +{
> > >>> +   const struct drm_plane_state *sa = *(struct drm_plane_state 
> > >>> **)a;
> > >>> +   const struct drm_plane_state *sb = *(struct drm_plane_state 
> > >>> **)b;
> > >>> +
> > >>> +   if (sa->zpos != sb->zpos)
> > >>> +   return sa->zpos - sb->zpos;
> > >>> +   else
> > >>> +   return sa->plane->base.id - sb->plane->base.id;
> > >>> +}
> > >> 
> > >> Still not really convinced this normalization is a good idea when we
> > >> have atomic. It made sense before atomic since otherwise you might not
> > >> be able to swap the zpos of two planes without shutting one of them
> > >> down, but it makes interpreting the zpos prop values more confusing. And
> > >> with atomic we don't actually need it AFAICS. Or do we have an actual
> > >> use case for this behaviour?
> > > 
> > > Speaking selfishly about my use case (rcar-du-drm), I need to sort planes
> > > in display order from 0 to N-1 as that's how the hardware is programmed.
> > > Normalization gives me an array of sorted planes, which is exactly what I
> > > need. I expect other drivers to have similar requirements, so
> > > normalization in the core will allow code sharing.
> > 
> > It just eliminates duplicate zpos values. It won't re-sort your plane
> > states magically or anything like that. Nor does it guarantee that
> > the zpos values for the actually visible planes are even contiguous.
> 
> To make normalization useful in my case I need contiguous values starting at 
> 0.

Contigious values for all the planes on the whole device or on one crtc?
And what about the visible vs. not plane issue? Is it OK to have an
invisible plane somewhere in the middle of the zpos sequence?

> 
> > > Now, is your concern that allowing two planes to have the same zpos isn't
> > > needed with the atomic API ? I agree with that, but it would also make it
> > > impossible to swap two planes using the legacy API implemented on top of
> > > atomic drivers. I'll let others decide whether this is considered as a
> > > concern.
> 
> Any opinion on this ?

Not really. I already asked if we had a good use case for it. Dunno if
anyone has one.

> 
> > > While at it, Benjamin told me that you've requested configurable min/max
> > > values per plane, what are your use cases 

[PATCH 1/4] drm: add generic zpos property

[Laurent Pinchart]

Hi Ville,

On Thursday 12 May 2016 22:46:05 Ville Syrjälä wrote:
> On Thu, May 12, 2016 at 10:20:12PM +0300, Laurent Pinchart wrote:
> > On Thursday 12 May 2016 14:51:55 Ville Syrjälä wrote:
> >> On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> >>> From: Marek Szyprowski 
> >>> 
> >>> This patch adds support for generic plane's zpos property property
> >>> with well-defined semantics:
> >>> - added zpos properties to plane and plane state structures
> >>> - added helpers for normalizing zpos properties of given set of planes
> >>> - well defined semantics: planes are sorted by zpos values and then
> >>>   plane id value if zpos equals
> >>> 
> >>> Normalized zpos values are calculated automatically when generic
> >>> muttable zpos property has been initialized. Drivers can simply use
> >>> plane_state->normalized_zpos in their atomic_check and/or plane_update
> >>> callbacks without any additional calls to DRM core.
> >>> 
> >>> Signed-off-by: Marek Szyprowski 
> >>> 
> >>> Compare to Marek's original patch zpos property is now specific to
> >>> each plane and no more to the core.
> >>> Normalize function take care of the range of per plane defined range
> >>> before set normalized_zpos.
> >>> 
> >>> Signed-off-by: Benjamin Gaignard 
> >>> 
> >>> Cc: Inki Dae 
> >>> Cc: Daniel Vetter 
> >>> Cc: Ville Syrjala 
> >>> Cc: Joonyoung Shim 
> >>> Cc: Seung-Woo Kim 
> >>> Cc: Andrzej Hajda 
> >>> Cc: Krzysztof Kozlowski 
> >>> Cc: Bartlomiej Zolnierkiewicz 
> >>> Cc: Tobias Jakobi 
> >>> Cc: Gustavo Padovan 
> >>> Cc: vincent.abriou at st.com
> >>> Cc: fabien.dessenne at st.com
> >>> Cc: Laurent Pinchart 
> >>> ---
> >>> 
> >>>  Documentation/DocBook/gpu.tmpl  |  10 ++
> >>>  drivers/gpu/drm/Makefile|   2 +-
> >>>  drivers/gpu/drm/drm_atomic.c|   4 +
> >>>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> >>>  drivers/gpu/drm/drm_blend.c | 229 
> >>>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
> >>>  include/drm/drm_crtc.h  |  28 +
> >>>  7 files changed, 281 insertions(+), 1 deletion(-)
> >>>  create mode 100644 drivers/gpu/drm/drm_blend.c
> > 
> > [snip]
> > 
> >>> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >>> new file mode 100644
> >>> index 000..eef59bb
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/drm_blend.c
> >>> @@ -0,0 +1,229 @@
> > 
> > [snip]
> > 
> >>> +static int drm_atomic_state_zpos_cmp(const void *a, const void *b)
> >>> +{
> >>> + const struct drm_plane_state *sa = *(struct drm_plane_state **)a;
> >>> + const struct drm_plane_state *sb = *(struct drm_plane_state **)b;
> >>> +
> >>> + if (sa->zpos != sb->zpos)
> >>> + return sa->zpos - sb->zpos;
> >>> + else
> >>> + return sa->plane->base.id - sb->plane->base.id;
> >>> +}
> >> 
> >> Still not really convinced this normalization is a good idea when we
> >> have atomic. It made sense before atomic since otherwise you might not
> >> be able to swap the zpos of two planes without shutting one of them
> >> down, but it makes interpreting the zpos prop values more confusing. And
> >> with atomic we don't actually need it AFAICS. Or do we have an actual
> >> use case for this behaviour?
> > 
> > Speaking selfishly about my use case (rcar-du-drm), I need to sort planes
> > in display order from 0 to N-1 as that's how the hardware is programmed.
> > Normalization gives me an array of sorted planes, which is exactly what I
> > need. I expect other drivers to have similar requirements, so
> > normalization in the core will allow code sharing.
> 
> It just eliminates duplicate zpos values. It won't re-sort your plane
> states magically or anything like that. Nor does it guarantee that
> the zpos values for the actually visible planes are even contiguous.

To make normalization useful in my case I need contiguous values starting at 
0.

> > Now, is your concern that allowing two planes to have the same zpos isn't
> > needed with the atomic API ? I agree with that, but it would also make it
> > impossible to swap two planes using the legacy API implemented on top of
> > atomic drivers. I'll let others decide whether this is considered as a
> > concern.

Any opinion on this ?

> > While at it, Benjamin told me that you've requested configurable min/max
> > values per plane, what are your use cases for that ? On the same topic,
> > please see below.
> > 
> >>> +
> >>> +/**
> >>> + * drm_atomic_helper_crtc_normalize_zpos - calculate normalized zpos
> >>> values
> >>> + * @crtc: crtc with planes, which have to be considered for
> >>> normalization
> >>> + * @crtc_state: new atomic state to apply
> >>> + *
> >>> + * This function checks new states of all planes assigned to given
> >>> crtc and
> >>> + * calculates normalized zpos value for them. Planes are compared
> >>> first by their
> >>> + * zpos values, then by plane id (if zpos equals). Plane with lowest
> >>> zpos value
> >>> + * is at the bottom. The