[Bug 194559] amdgpu problems loading 2 firmwares on multi-smp system

[bugzilla-daemon]

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

--- Comment #3 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
it works! attached my config file of your drm-next kernel
I don't know what needs to be done for you developers to integrate drm-next
into the mainline kernel, but thank you!!!

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

[bug report] drm/exynos/decon5433: configure sysreg in case of hardware trigger

[Dan Carpenter]

Hello Andrzej Hajda,

The patch b93c2e8b5d9d: "drm/exynos/decon5433: configure sysreg in
case of hardware trigger" from Feb 1, 2017, leads to the following
static checker warning:

drivers/gpu/drm/exynos/exynos5433_drm_decon.c:132 decon_setup_trigger()
'0x2001 | 0x1' has '0x1' set on both sides

drivers/gpu/drm/exynos/exynos5433_drm_decon.c
   125  static void decon_setup_trigger(struct decon_context *ctx)
   126  {
   127  if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
   128  return;
   129  
   130  if (!(ctx->out_type & I80_HW_TRG)) {
   131  writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
   132 | TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,

The mask is repeated twice.  No idea what was intended.

   133 ctx->addr + DECON_TRIGCON);
   134  return;
   135  }
   136  
   137  writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | 
TRIGCON_HWTRIGMASK
   138 | TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
   139  
   140  if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
   141 DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
   142  DRM_ERROR("Cannot update sysreg.\n");
   143  }

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

[patch] drm/exynos/decon5433: & vs | typo

[Dan Carpenter]

"&" was obviously intended instead of "|".  The original condition is
always true.

Fixes: b93c2e8b5d9d ("drm/exynos/decon5433: configure sysreg in case of 
hardware trigger")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 0fd6f7a18364..cca32a4fdab3 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -678,7 +678,7 @@ static int exynos5433_decon_probe(struct platform_device 
*pdev)
ctx->out_type |= IFTYPE_I80;
}
 
-   if (ctx->out_type | I80_HW_TRG) {
+   if (ctx->out_type & I80_HW_TRG) {
ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
"samsung,disp-sysreg");
if (IS_ERR(ctx->sysreg)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

fin4...@hotmail.com changed:

   What|Removed |Added

 CC||fin4...@hotmail.com

--- Comment #2 from fin4...@hotmail.com ---
There is very little amdgpu driver code in the stock kernels, see kernel.org
and diff column. See other amdgpu bug reports how to create a custom kernel
with this code:
git clone -b drm-next-4.11-wip git://people.freedesktop.org/~agd5f/linux

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

[Bug 194559] amdgpu problems loading 2 firmwares on multi-smp system

[bugzilla-daemon]

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

--- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Dear fin4478,
thank you for the tips, I will try them asap,
but I am confused: I have nothing with debian, and the system is headless
(running as OpenCL accelerator).  Does this matter to you?

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

[PATCH v2] drm/amd/dc: dm_types: fix semicolon.cocci warnings

[Julia Lawall]

Remove unneeded semicolons.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

v2: make subject line unique

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver

 amdgpu_dm_types.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c
@@ -890,11 +890,11 @@ static void copy_crtc_timing_for_drm_dis
dst_mode->crtc_hsync_end = src_mode->crtc_hsync_end;
dst_mode->crtc_htotal = src_mode->crtc_htotal;
dst_mode->crtc_hskew = src_mode->crtc_hskew;
-   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;;
-   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;;
-   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;;
-   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;;
-   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;;
+   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;
+   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;
+   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;
+   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;
+   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;
 }

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

[PATCH v2] drm/amd/dc: resource: fix semicolon.cocci warnings (fwd)

[Julia Lawall]

Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

v2: make subject line unique

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver

 dc_resource.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
@@ -135,7 +135,7 @@ static void update_num_audio(
break;
default:
DC_ERR("DC: unexpected audio fuse!\n");
-   };
+   }
 }

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

[PATCH] drm/amd/dc: hw_sequencer: fix semicolon.cocci warnings

[Julia Lawall]

Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver

 dce110_hw_sequencer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_hw_sequencer.c
@@ -1643,7 +1643,7 @@ static void init_hw(struct core_dc *dc)
true);
}

-   dce_clock_gating_power_up(dc->hwseq, false);;
+   dce_clock_gating_power_up(dc->hwseq, false);
/***/

for (i = 0; i < dc->link_count; i++) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/dc: fix semicolon.cocci warnings

[Julia Lawall]

Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver

 dc_resource.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c
@@ -135,7 +135,7 @@ static void update_num_audio(
break;
default:
DC_ERR("DC: unexpected audio fuse!\n");
-   };
+   }
 }

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

[PATCH] drm/amd/dc: fix semicolon.cocci warnings

[Julia Lawall]

Remove unneeded semicolons.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Harry Wentland 
Signed-off-by: Julia Lawall 
Signed-off-by: Fengguang Wu 
---

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9
head:   79d2de1bcb650296adff1cb08bfbf1501a6e6e14
commit: bad4c165a6986a131cdd1455507ba3857baaa561 [201/657] drm/amd/dc: Add
dc display driver

 amdgpu_dm_types.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_types.c
@@ -890,11 +890,11 @@ static void copy_crtc_timing_for_drm_dis
dst_mode->crtc_hsync_end = src_mode->crtc_hsync_end;
dst_mode->crtc_htotal = src_mode->crtc_htotal;
dst_mode->crtc_hskew = src_mode->crtc_hskew;
-   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;;
-   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;;
-   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;;
-   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;;
-   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;;
+   dst_mode->crtc_vblank_start = src_mode->crtc_vblank_start;
+   dst_mode->crtc_vblank_end = src_mode->crtc_vblank_end;
+   dst_mode->crtc_vsync_start = src_mode->crtc_vsync_start;
+   dst_mode->crtc_vsync_end = src_mode->crtc_vsync_end;
+   dst_mode->crtc_vtotal = src_mode->crtc_vtotal;
 }

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

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/AMDgpu
Product|xorg|DRI
 CC||harry.wentl...@amd.com
 QA Contact|xorg-t...@lists.x.org   |
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org

--- Comment #11 from Michel Dänzer  ---
Anyway, this is likely a kernel driver issue.

Harry / DC folks, can you take a look?

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

[Bug 65968] Massive memory corruption in Planetary Annihilation Alpha

[bugzilla-daemon]

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

--- Comment #10 from Timothy Arceri  ---
(In reply to Timothy Arceri from comment #9)
> (In reply to Timothy Arceri from comment #8)
> > Actually no I take that back it is using core profile.
> 
> It's requesting a core profile and using compat features.

Actually I'm not sure that's true either. Anyway here is a trace (warning its
3.6GB).

https://drive.google.com/open?id=0B-f68fD4PtpBenBiekxITllIbzg

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

[Bug 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly

[bugzilla-daemon]

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

--- Comment #4 from Timothy Arceri  ---
(In reply to Timothy Arceri from comment #3)
> The game requests a compatibility profile but its using OpenGL features from
> 3.1+. Overriding the version doesn't fix the issue, so may be related, may
> not.

Umm. I'm not sure what made me think this is using 3.1+ but I don't think that
is correct.

Also running the trace on i965 produces correct output.

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

[Bug 97003] [d3dadapter+radeonsi] Dragon's Dogma: video memory leak with precompiled shaders

[bugzilla-daemon]

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

--- Comment #8 from Timothy Arceri  ---
(In reply to Roland Scheidegger from comment #7)
> 0x36 looks like a segment override (ss segment) prefix (0x89 would be a
> mov), so nothing new.
> This looks like a valgrind bug to me:
> https://bugs.kde.org/show_bug.cgi?id=344139 which seems old, in particular
> no updates since over a year (and specifically mentions wine is using such
> segment override prefixes).

Looks like a fix has been merged into valgringd git.

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

[Bug 92806] 1 second freezes during new effects UT4

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |t_arc...@yahoo.com.au
   |.org|

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

[Bug 97340] [radeonsi] POSTAL 2 freezes during shader compilation

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |t_arc...@yahoo.com.au
   |.org|

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

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #27 from Michel Dänzer  ---
(In reply to Reimar Imhof from comment #26)
> Together with comment #24 there is a render bug in kernel 4.8 that shows up
> at 100% cpu load.
> With kernel 4.9 this same bug shows up at 0% / idle cpu load.
> 
> With 
> af79ad2b1f337a00aa150b993635b10bc68dc842
> Merge branch 'sched-core-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> it changed from "bug shows at 100% load" to "bug shows at 0% load". And the
> change is something about the scheduler.
> To me this seems likely.

Not really. That commit is a pure merge commit, which makes it unlikely that it
behaves any differently from either of its parent commits. So git bisect should
have identified one of its ancestor commits instead. The fact that it
identified a pure merge commit indicates that the result is incorrect, most
likely because at least one commit along the way was incorrectly classified as
good (or bad).

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

Re: [PATCH libdrm 0/4] libdrm: add new GPU sensor interface for AMDGPU

[Emil Velikov]

On 14 February 2017 at 00:08, Samuel Pitoiset  wrote:
> Hi,
>
> This series implements a new GPU sensor interface which will allow to
> query the current temperature and the shader/memory clocks via the
> GALLIUM_HUD. This adds the same functionality as the Radeon driver.
>
> The first patch of the series syncs amdgpu_drm.h with kernel headers.
>
> Branch is here:
> https://cgit.freedesktop.org/~hakzsam/drm/log/?h=si_clocks_temp
>
> Please review.
> Thanks!
>
> Samuel Pitoiset (4):
>   amdgpu: sync amdgpu_drm.h with the kernel
Samuel,

Please read through drm/include/drm/README in particular "When and how
to update these files".
JFYI multiple people are trying to get various UABI in, so do keep an
eye open for fireworks.

>   amdgpu: add new GPU sensor related interface
>   amdgpu: allow to query GPU sensor related information
You'll need to add the new interface(s) to the symbols test. `make
check' must pass.

>   Bump version for 2.4.76 release
>
Skim through RELEASING for details on how to roll one.

Pardon, if I'm flocking up a dead horse here.

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #90 from Marek Olšák  ---
(In reply to Tobias Droste from comment #89)
> So today came a game update and I can also confirm that the long pauses at
> the beginning are gone. But there's still a small pause (<1s) every 2 or 3s
> now and not only at the beginning. 
> 
> Do you think it's a separate issue? (Mesa git from today)

You can find that out by yourself with Gallium HUD queries such as
num-compilations for the shader compiler and num-bytes-moved, which is TTM
activity.

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

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > 
> > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > > > 
> > > > Having a ->atomic_release callback is useful to release shared
> > > > resources
> > > > that get allocated in compute_config(). This function is expected
> > > > to
> > > > be
> > > > called in the atomic_check() phase before new resources are
> > > > acquired.
> > > > 
> > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > 
> > > > Suggested-by: Daniel Vetter 
> > > > Signed-off-by: Dhinakaran Pandiyan  > > > >
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > +++
> > > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> > > >  2 files changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 8795088..92bd741 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > drm_device *dev,
> > > > }
> > > > }
> > > >  
> > > > +   for_each_connector_in_state(state, connector,
> > > > connector_state, i) {
> > > > +   const struct drm_connector_helper_funcs
> > > > *conn_funcs;
> > > > +   struct drm_crtc_state *crtc_state;
> > > > +
> > > > +   conn_funcs = connector->helper_private;
> > > > +   if (!conn_funcs->atomic_release)
> > > > +   continue;
> > > > +
> > > > +   if (!connector->state->crtc)
> > > > +   continue;
> > > > +
> > > > +   crtc_state =
> > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > >crtc);
> > > > +
> > > > +   if (crtc_state->connectors_changed ||
> > > > +   crtc_state->mode_changed ||
> > > > +   (crtc_state->active_changed && !crtc_state-
> > > > > 
> > > > > active))
> > > > +   conn_funcs->atomic_release(connector,
> > > > connector_state);
> > > > +   }
> > > 
> > > Could we deal with the VCPI state separately in
> > > intel_modeset_checks,
> > > like we do with dpll?
> > 
> > We'd want to release the VCPI slots before they are acquired in
> > ->compute_config(). intel_modeset_checks() will be too late to
> > release
> > them. Are you suggesting both acquiring and releasing slots should be
> > done in intel_modeset_checks()?
> 
> That makes things a bit more nasty. Maybe add a
> conn_funcs->atomic_check that always gets called, something like I did
> below?
> 
> I'd love to use it for some atomic connector properties too.


Adding and unconditionally calling conn_funcs->atomic_check() should be
doable. It also follows the pattern we have for encoders and CRTCs. But
I'll have to move the connector->state->crtc state checks inside the
function.

-DK
> > > 
> > > 
> > > Maybe implementing the relevant VCPI state could be done as an
> > > atomic
> > > helper function too, so other atomic drivers can just plug it in.
> > > 
> > The idea was to reduce boilerplate in the drivers and use the
> > private_obj state for different object types.
> > 
> > 
> > > 
> > > Not sure how doable this is, but if it's not too hard, then it's
> > > probably cleaner :)
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [linux-sunxi] Re: [PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

[Priit Laes]

On Mon, 2017-02-13 at 17:20 +0800, Chen-Yu Tsai wrote:
> On Mon, Feb 13, 2017 at 5:16 PM, Maxime Ripard
>  wrote:
> > Hi,
> > 
> > On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
> > > Added basic display pipeline consisting of tcon, display backend
> > > and
> > > frontend blocks.
> > > 
> > > Signed-off-by: Priit Laes 
> > > ---
> > >  arch/arm/boot/dts/sun4i-a10.dtsi | 104
> > > +++
> > >  1 file changed, 104 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > index ba20b48..70991c9 100644
> > > --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> > > +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> > > @@ -779,6 +779,45 @@
> > >   #size-cells = <0>;
> > >   };
> > > 
> > > + tcon0: lcd-controller@1c0c000 {
> > > + compatible = "allwinner,sun5i-a13-tcon";
> > 
> > There's a few bits here and there that need to be setup differently
> > in
> > A10, so you cannot reuse that compatible (same thing for the
> > other).
> > 
> > Also, I'd really like to have all the blocks listed here, and not
> > only
> > the first pipeline. Ideally, on the A10, the two pipelines should
> > be
> > enabled too.
> 
> The display pipeline driver has to be fixed before that can happen
> though. And I haven't started to work on what I proposed yet. Though
> if someone wants to take over I can forward any design plans I have.

Well, my plan was to get at least minimum bits mainlined and then build
additional features on top.

Wens, it would be cool though, if you could share your plans.

Unfortunately I have only single A10 device (with LVDS and mini-HDMI)
but I don't actually have other LVDS-displays I could easily use with
A20 devices (I have CubieTruck and A20-Olinuxino Micro).

Päikest,
Priit :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Pandiyan, Dhinakaran]

On Mon, 2017-02-13 at 21:26 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > > 
> > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > > > > 
> > > > > Having a ->atomic_release callback is useful to release shared
> > > > > resources
> > > > > that get allocated in compute_config(). This function is expected
> > > > > to
> > > > > be
> > > > > called in the atomic_check() phase before new resources are
> > > > > acquired.
> > > > > 
> > > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > > 
> > > > > Suggested-by: Daniel Vetter 
> > > > > Signed-off-by: Dhinakaran Pandiyan  > > > > >
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > > +++
> > > > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> > > > >  2 files changed, 32 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > index 8795088..92bd741 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > > drm_device *dev,
> > > > >   }
> > > > >   }
> > > > >  
> > > > > + for_each_connector_in_state(state, connector,
> > > > > connector_state, i) {
> > > > > + const struct drm_connector_helper_funcs
> > > > > *conn_funcs;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > +
> > > > > + conn_funcs = connector->helper_private;
> > > > > + if (!conn_funcs->atomic_release)
> > > > > + continue;
> > > > > +
> > > > > + if (!connector->state->crtc)
> > > > > + continue;
> > > > > +
> > > > > + crtc_state =
> > > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > > >crtc);
> > > > > +
> > > > > + if (crtc_state->connectors_changed ||
> > > > > + crtc_state->mode_changed ||
> > > > > + (crtc_state->active_changed && !crtc_state-
> > > > > > 
> > > > > > active))
> > > > > + conn_funcs->atomic_release(connector,
> > > > > connector_state);
> > > > > + }
> > > > 
> > > > Could we deal with the VCPI state separately in
> > > > intel_modeset_checks,
> > > > like we do with dpll?
> > > 
> > > We'd want to release the VCPI slots before they are acquired in
> > > ->compute_config(). intel_modeset_checks() will be too late to
> > > release
> > > them. Are you suggesting both acquiring and releasing slots should be
> > > done in intel_modeset_checks()?
> > 
> > That makes things a bit more nasty. Maybe add a
> > conn_funcs->atomic_check that always gets called, something like I did
> > below?
> > 
> > I'd love to use it for some atomic connector properties too.
> 
> 
> Adding and unconditionally calling conn_funcs->atomic_check() should be
> doable. It also follows the pattern we have for encoders and CRTCs. But
> I'll have to move the connector->state->crtc state checks inside the
> function.
> 
> -DK


This is what I mean -https://pastebin.ubuntu.com/23991405/
But, I do have one concern with calling this conn_func->atomic_check().
We are not validating the new connector_state like atomic_check() seems
to do generally but only cleaning up vcpi resources for compute_config()
to later acquire. Let me know if I am wrong in my understanding what
atomic_check() is expected to do.


-DK
> > > > 
> > > > 
> > > > Maybe implementing the relevant VCPI state could be done as an
> > > > atomic
> > > > helper function too, so other atomic drivers can just plug it in.
> > > > 
> > > The idea was to reduce boilerplate in the drivers and use the
> > > private_obj state for different object types.
> > > 
> > > 
> > > > 
> > > > Not sure how doable this is, but if it's not too hard, then it's
> > > > probably cleaner :)
> > > > ___
> > > > Intel-gfx mailing list
> > > > intel-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH RESEND 1/1] media: platform: Renesas IMR driver

[Konstantin Kozhevnikov]

Hello Laurent,

regarding your main question, I think the name "image renderer" is 
misguiding. This IP-block has nothing to do with rendering per se, it is 
rather an image processing module, designed specifically for image 
undistortion (lens correction). We use that as a plain memory-to-memory 
device, and it fits well into V4L2 framework. More complex 
implementation (the one we thought of, but had no capacity to implement) 
would allow integration of VIN (as well as other modules like 
H.264/MPEG4 decoders) and IMR engines into a single processing pipeline 
(so it would not look like a M2M device but would be a sort of 
"smart-VIN"). From that perspective it is no more DRM device driver than 
VSP, which resides in the same "drivers/platform/media" directory.


Sincerely,
Kostya

On 02/12/2017 06:51 PM, Laurent Pinchart wrote:

Hi Sergei,

(CC'ing the dri-evel mailing list)

Thank you for the patch.

On Saturday 11 Feb 2017 23:02:01 Sergei Shtylyov wrote:

From: Konstantin Kozhevnikov 

The image renderer light extended 4 (IMR-LX4) or the distortion correction
engine is a drawing processor with a simple  instruction system capable of
referencing data on an external memory as 2D texture data and performing
texture mapping and drawing with respect to any shape that is split into
triangular objects.

This V4L2 memory-to-memory device driver only supports image renderer found
in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

Let's start with the main question : given that this is a rendering engine, it
looks like it should use the DRM subsystem.


[Sergei: merged 2 original patches, added the patch description, removed
unrelated parts,  added the binding document, ported the driver to the
modern kernel, renamed the UAPI header file and the guard  macros to match
the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
leading  dots and fixed grammar in the comments, fixed up indentation to
use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
separated the register offset/bit #define's, removed *inline* from .c file,
fixed lines over 80 columns, removed useless parens, operators, casts,
braces, variables, #include's, (commented out) statements, and even
function, inserted empty line after desclaration, removed extra empty
lines, reordered some local variable desclarations, removed calls to
4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
avoided code duplication in the IRQ handler, used '__packed' for the UAPI
structures, enclosed the macro parameters in parens, exchanged the values
of IMR_MAP_AUTO[SD]G macros.]

Signed-off-by: Konstantin Kozhevnikov
 Signed-off-by: Sergei Shtylyov


---
This patch is against the 'media_tree.git' repo's 'master' branch.

  Documentation/devicetree/bindings/media/rcar_imr.txt |   23
  drivers/media/platform/Kconfig   |   13
  drivers/media/platform/Makefile  |1
  drivers/media/platform/rcar_imr.c| 1923 +++
  include/uapi/linux/rcar_imr.h|   94
  5 files changed, 2054 insertions(+)



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

Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

[Vernon Mauery]

On 26-Jan-2017 01:45 AM, YC Chen wrote:
> From: "Y.C. Chen" 
> 
> The original ast driver will access some BMC configuration through P2A bridge
> that can be disabled since AST2300 and after.
> It will cause system hanged if P2A bridge is disabled.
> Here is the update to fix it.
> 
> Signed-off-by: Y.C. Chen 

This change worked for me on my system when I had the P2A bridge 
disabled.

Tested-by: Vernon Mauery 

--Vernon

> ---
>  drivers/gpu/drm/ast/ast_drv.h  |   1 +
>  drivers/gpu/drm/ast/ast_main.c | 156 
> ++---
>  drivers/gpu/drm/ast/ast_post.c |  18 +++--
>  3 files changed, 96 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 908011d..7abda94 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -113,6 +113,7 @@ struct ast_private {
> struct ttm_bo_kmap_obj cache_kmap;
> int next_cursor;
> bool support_wide_screen;
> +   bool DisableP2A;
> 
> enum ast_tx_chip tx_chip_type;
> u8 dp501_maxclk;
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index f75c642..c374685 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -124,6 +124,11 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
> } else
> *need_post = false;
> 
> +   /* Check P2A Access */
> +   ast->DisableP2A = true;
> +   data = ast_read32(ast, 0xf004);
> +   if (data != 0x) ast->DisableP2A = false;
> +
> /* Check if we support wide screen */
> switch (ast->chip) {
> case AST1180:
> @@ -140,15 +145,17 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
> ast->support_wide_screen = true;
> else {
> ast->support_wide_screen = false;
> -   /* Read SCU7c (silicon revision register) */
> -   ast_write32(ast, 0xf004, 0x1e6e);
> -   ast_write32(ast, 0xf000, 0x1);
> -   data = ast_read32(ast, 0x1207c);
> -   data &= 0x300;
> -   if (ast->chip == AST2300 && data == 0x0) /* ast1300 */
> -   ast->support_wide_screen = true;
> -   if (ast->chip == AST2400 && data == 0x100) /* ast1400 
> */
> -   ast->support_wide_screen = true;
> +   if (ast->DisableP2A == false) {
> +   /* Read SCU7c (silicon revision register) */
> +   ast_write32(ast, 0xf004, 0x1e6e);
> +   ast_write32(ast, 0xf000, 0x1);
> +   data = ast_read32(ast, 0x1207c);
> +   data &= 0x300;
> +   if (ast->chip == AST2300 && data == 0x0) /* 
> ast1300 */
> +   ast->support_wide_screen = true;
> +   if (ast->chip == AST2400 && data == 0x100) /* 
> ast1400 */
> +   ast->support_wide_screen = true;
> +   }
> }
> break;
> }
> @@ -216,80 +223,81 @@ static int ast_get_dram_info(struct drm_device *dev)
> uint32_t data, data2;
> uint32_t denum, num, div, ref_pll;
> 
> -   ast_write32(ast, 0xf004, 0x1e6e);
> -   ast_write32(ast, 0xf000, 0x1);
> -
> -
> -   ast_write32(ast, 0x1, 0xfc600309);
> -
> -   do {
> -   if (pci_channel_offline(dev->pdev))
> -   return -EIO;
> -   } while (ast_read32(ast, 0x1) != 0x01);
> -   data = ast_read32(ast, 0x10004);
> -
> -   if (data & 0x40)
> +   if (ast->DisableP2A)
> +   {
> ast->dram_bus_width = 16;
> +   ast->dram_type = AST_DRAM_1Gx16;
> +   ast->mclk = 396;
> +   }
> else
> -   ast->dram_bus_width = 32;
> +   {
> +   ast_write32(ast, 0xf004, 0x1e6e);
> +   ast_write32(ast, 0xf000, 0x1);
> +   data = ast_read32(ast, 0x10004);
> +
> +   if (data & 0x40)
> +   ast->dram_bus_width = 16;
> +   else
> +   ast->dram_bus_width = 32;
> +
> +   if (ast->chip == AST2300 || ast->chip == AST2400) {
> +   switch (data & 0x03) {
> +   case 0:
> +   ast->dram_type = AST_DRAM_512Mx16;
> +   break;
> +   default:
> +   case 1:
> +   ast->dram_type = AST_DRAM_1Gx16;
> +   break;
> +  

Re: [PATCH] drm: ensure atomic messages consistently include the name of the component

[Russell King - ARM Linux]

On Mon, Feb 13, 2017 at 02:37:31PM +0100, Maarten Lankhorst wrote:
> All for it, looks sane. The last hunk fails to apply because it's based on
> an older version of page_flip, but easy enough to fix.

Yes, it's based on v4.10-rc7.

Thanks.

-- 
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 2/4] amdgpu: add new GPU sensor related interface

[Samuel Pitoiset]

This will be used to expose the current GPU temperature, the
shader clock and eventually the memory clock (for non-APUs).

Signed-off-by: Samuel Pitoiset 
---
 include/drm/amdgpu_drm.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 2be8b8dc..cd9c8223 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -534,6 +534,14 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_VBIOS_IMAGE 0x2
 /* Query UVD handles */
 #define AMDGPU_INFO_NUM_HANDLES0x1C
+/* Query GPU sensor related information */
+#define AMDGPU_INFO_GPU_SENSOR 0x1D
+   /* Query the current shader clock */
+   #define AMDGPU_INFO_GPU_SENSOR_SCLK 0x1
+   /* Query the current memory clock */
+   #define AMDGPU_INFO_GPU_SENSOR_MCLK 0x2
+   /* Query the current temperature */
+   #define AMDGPU_INFO_GPU_SENSOR_TEMP 0x3
 
 #define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
 #define AMDGPU_INFO_MMR_SE_INDEX_MASK  0xff
@@ -597,6 +605,10 @@ struct drm_amdgpu_info {
uint32_t type;
uint32_t offset;
} vbios_info;
+
+   struct {
+   uint32_t type;
+   } gpu_sensor_info;
};
 };
 
-- 
2.11.1

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

[PATCH libdrm 1/4] amdgpu: sync amdgpu_drm.h with the kernel

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 include/drm/amdgpu_drm.h | 123 +++
 1 file changed, 123 insertions(+)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index d8f24976..2be8b8dc 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -50,6 +50,8 @@ extern "C" {
 #define DRM_AMDGPU_WAIT_CS 0x09
 #define DRM_AMDGPU_GEM_OP  0x10
 #define DRM_AMDGPU_GEM_USERPTR 0x11
+#define DRM_AMDGPU_WAIT_FENCES 0x12
+#define DRM_AMDGPU_FREESYNC0x14
 
 #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
 #define DRM_IOCTL_AMDGPU_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -63,6 +65,8 @@ extern "C" {
 #define DRM_IOCTL_AMDGPU_WAIT_CS   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_WAIT_CS, union drm_amdgpu_wait_cs)
 #define DRM_IOCTL_AMDGPU_GEM_OPDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_OP, struct drm_amdgpu_gem_op)
 #define DRM_IOCTL_AMDGPU_GEM_USERPTR   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
+#define DRM_IOCTL_AMDGPU_WAIT_FENCES   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
+#define DRM_IOCTL_AMDGPU_FREESYNC  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_FREESYNC, struct drm_amdgpu_freesync)
 
 #define AMDGPU_GEM_DOMAIN_CPU  0x1
 #define AMDGPU_GEM_DOMAIN_GTT  0x2
@@ -79,6 +83,10 @@ extern "C" {
 #define AMDGPU_GEM_CREATE_CPU_GTT_USWC (1 << 2)
 /* Flag that the memory should be in VRAM and cleared */
 #define AMDGPU_GEM_CREATE_VRAM_CLEARED (1 << 3)
+/* Flag that create shadow bo(GTT) while allocating vram bo */
+#define AMDGPU_GEM_CREATE_SHADOW   (1 << 4)
+/* Flag that allocating the BO should use linear VRAM */
+#define AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS  (1 << 5)
 
 struct drm_amdgpu_gem_create_in  {
/** the requested memory size */
@@ -303,6 +311,32 @@ union drm_amdgpu_wait_cs {
struct drm_amdgpu_wait_cs_out out;
 };
 
+struct drm_amdgpu_fence {
+   uint32_t ctx_id;
+   uint32_t ip_type;
+   uint32_t ip_instance;
+   uint32_t ring;
+   uint64_t seq_no;
+};
+
+struct drm_amdgpu_wait_fences_in {
+   /** This points to uint64_t * which points to fences */
+   uint64_t fences;
+   uint32_t fence_count;
+   uint32_t wait_all;
+   uint64_t timeout_ns;
+};
+
+struct drm_amdgpu_wait_fences_out {
+   uint32_t status;
+   uint32_t first_signaled;
+};
+
+union drm_amdgpu_wait_fences {
+   struct drm_amdgpu_wait_fences_in in;
+   struct drm_amdgpu_wait_fences_out out;
+};
+
 #define AMDGPU_GEM_OP_GET_GEM_CREATE_INFO  0
 #define AMDGPU_GEM_OP_SET_PLACEMENT1
 
@@ -329,6 +363,8 @@ struct drm_amdgpu_gem_op {
 #define AMDGPU_VM_PAGE_WRITEABLE   (1 << 2)
 /* executable mapping, new for VI */
 #define AMDGPU_VM_PAGE_EXECUTABLE  (1 << 3)
+/* partially resident texture */
+#define AMDGPU_VM_PAGE_PRT (1 << 4)
 
 struct drm_amdgpu_gem_va {
/** GEM object handle */
@@ -434,6 +470,7 @@ struct drm_amdgpu_cs_chunk_data {
  *
  */
 #define AMDGPU_IDS_FLAGS_FUSION 0x1
+#define AMDGPU_IDS_FLAGS_PREEMPTION 0x2
 
 /* indicate if acceleration can be working */
 #define AMDGPU_INFO_ACCEL_WORKING  0x00
@@ -483,6 +520,20 @@ struct drm_amdgpu_cs_chunk_data {
 #define AMDGPU_INFO_DEV_INFO   0x16
 /* visible vram usage */
 #define AMDGPU_INFO_VIS_VRAM_USAGE 0x17
+/* number of TTM buffer evictions */
+#define AMDGPU_INFO_NUM_EVICTIONS  0x18
+/* Query memory about VRAM and GTT domains */
+#define AMDGPU_INFO_MEMORY 0x19
+/* Query vce clock table */
+#define AMDGPU_INFO_VCE_CLOCK_TABLE0x1A
+/* Query vbios related information */
+#define AMDGPU_INFO_VBIOS  0x1B
+   /* Subquery id: Query vbios size */
+   #define AMDGPU_INFO_VBIOS_SIZE  0x1
+   /* Subquery id: Query vbios image */
+   #define AMDGPU_INFO_VBIOS_IMAGE 0x2
+/* Query UVD handles */
+#define AMDGPU_INFO_NUM_HANDLES0x1C
 
 #define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
 #define AMDGPU_INFO_MMR_SE_INDEX_MASK  0xff
@@ -541,6 +592,11 @@ struct drm_amdgpu_info {
} read_mmr_reg;
 
struct drm_amdgpu_query_fw query_fw;
+
+   struct {
+   uint32_t type;
+   uint32_t offset;
+   } vbios_info;
};
 };
 
@@ -568,6 +624,34 @@ struct drm_amdgpu_info_vram_gtt {
uint64_t gtt_size;
 };
 
+struct drm_amdgpu_heap_info {
+   /** max. physical memory */
+   uint64_t total_heap_size;
+
+   /** Theoretical max. available memory in the given heap */
+   uint64_t usable_heap_size;
+
+   /**
+* 

[PATCH libdrm 4/4] Bump version for 2.4.76 release

[Samuel Pitoiset]

For AMDGPU GPU sensor interface.

Signed-off-by: Samuel Pitoiset 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 8e593324..8b2db691 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
 
 AC_PREREQ([2.63])
 AC_INIT([libdrm],
-[2.4.75],
+[2.4.76],
 [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI],
 [libdrm])
 
-- 
2.11.1

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

[PATCH libdrm 3/4] amdgpu: allow to query GPU sensor related information

[Samuel Pitoiset]

This exposes amdgpu_query_gpu_sensor_info().

Signed-off-by: Samuel Pitoiset 
---
 amdgpu/amdgpu.h  | 19 +++
 amdgpu/amdgpu_gpu_info.c | 15 +++
 2 files changed, 34 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 7b26a04c..b040f6ab 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1059,6 +1059,25 @@ int amdgpu_query_gds_info(amdgpu_device_handle dev,
struct amdgpu_gds_resource_info *gds_info);
 
 /**
+ * Query information about GPU sensor.
+ *
+ * The return size is query-specific and depends on the "sensor_type"
+ * parameter. No more than "size" bytes is returned.
+ *
+ * \param   dev - \c [in] Device handle. See 
#amdgpu_device_initialize()
+ * \param   sensor_type - \c [in] AMDGPU_INFO_GPU_SENSOR_*
+ * \param   size- \c [in] Size of the returned value.
+ * \param   value   - \c [out] Pointer to the return value.
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_query_gpu_sensor_info(amdgpu_device_handle dev,
+unsigned sensor_type,
+unsigned size, void *value);
+
+/**
  * Read a set of consecutive memory-mapped registers.
  * Not all registers are allowed to be read by userspace.
  *
diff --git a/amdgpu/amdgpu_gpu_info.c b/amdgpu/amdgpu_gpu_info.c
index 66c7e0e1..778c2ee1 100644
--- a/amdgpu/amdgpu_gpu_info.c
+++ b/amdgpu/amdgpu_gpu_info.c
@@ -314,3 +314,18 @@ int amdgpu_query_gds_info(amdgpu_device_handle dev,
 
return 0;
 }
+
+int amdgpu_query_gpu_sensor_info(amdgpu_device_handle dev, unsigned 
sensor_type,
+unsigned size, void *value)
+{
+   struct drm_amdgpu_info request;
+
+   memset(, 0, sizeof(request));
+   request.return_pointer = (uintptr_t)value;
+   request.return_size = size;
+   request.query = AMDGPU_INFO_GPU_SENSOR;
+   request.gpu_sensor_info.type = sensor_type;
+
+   return drmCommandWrite(dev->fd, DRM_AMDGPU_INFO, ,
+  sizeof(struct drm_amdgpu_info));
+}
-- 
2.11.1

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

[PATCH libdrm 0/4] libdrm: add new GPU sensor interface for AMDGPU

[Samuel Pitoiset]

Hi,

This series implements a new GPU sensor interface which will allow to
query the current temperature and the shader/memory clocks via the
GALLIUM_HUD. This adds the same functionality as the Radeon driver.

The first patch of the series syncs amdgpu_drm.h with kernel headers.

Branch is here:
https://cgit.freedesktop.org/~hakzsam/drm/log/?h=si_clocks_temp

Please review.
Thanks!

Samuel Pitoiset (4):
  amdgpu: sync amdgpu_drm.h with the kernel
  amdgpu: add new GPU sensor related interface
  amdgpu: allow to query GPU sensor related information
  Bump version for 2.4.76 release

 amdgpu/amdgpu.h  |  19 +++
 amdgpu/amdgpu_gpu_info.c |  15 ++
 configure.ac |   2 +-
 include/drm/amdgpu_drm.h | 135 +++
 4 files changed, 170 insertions(+), 1 deletion(-)

-- 
2.11.1

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #89 from Tobias Droste  ---
So today came a game update and I can also confirm that the long pauses at the
beginning are gone. But there's still a small pause (<1s) every 2 or 3s now and
not only at the beginning. 

Do you think it's a separate issue? (Mesa git from today)

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

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Manasi Navare]

On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> Martin Peres  writes:
> 
> > On 06/02/17 17:50, Martin Peres wrote:
> >> On 03/02/17 10:04, Daniel Vetter wrote:
> >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
>  On 01/02/17 22:05, Manasi Navare wrote:
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >> Jani Nikula  writes:
> >>
> >>> On Tue, 31 Jan 2017, Eric Anholt  wrote:
>  Martin Peres  writes:
> 
> > Despite all the careful planing of the kernel, a link may become
> > insufficient to handle the currently-set mode. At this point, the
> > kernel should mark this particular configuration as being broken
> > and potentially prune the mode before setting the offending
> > connector's
> > link-status to BAD and send the userspace a hotplug event. This may
> > happen right after a modeset or later on.
> >
> > When available, we should use the link-status information to reset
> > the wanted mode.
> >
> > Signed-off-by: Martin Peres 
>  If I understand this right, there are two failure modes being
>  handled:
> 
>  1) A mode that won't actually work because the link isn't good
>  enough.
> 
>  2) A mode that should work, but link parameters were too
>  optimistic and
>  if we just ask the kernel to set the mode again it'll use more
>  conservative parameters that work.
> 
>  This patch seems good for 2).  For 1), the drmmode_set_mode_major is
>  going to set our old mode back.  Won't the modeset then fail to link
>  train again, and bring us back into this loop?  The only escape
>  that I
>  see would be some other userspace responding to the advertised
>  mode list
>  changing, and then asking X to modeset to something new.
> 
>  To avoid that failure busy loop, should we re-fetching modes at this
>  point, and only re-setting if our mode still exists?
> >>> Disclaimer: I don't know anything about the internals of the
> >>> modesetting
> >>> driver.
> >>>
> >>> Perhaps we can identify the two cases now, but I'd put this more
> >>> generally: if the link status has gone bad, it's an indicator to
> >>> userspace that the circumstances may have changed, and userspace
> >>> should
> >>> query the kernel for the list of available modes again. It should no
> >>> longer trust information obtained prior to getting the bad link
> >>> status,
> >>> including the current mode.
> >>>
> >>> But specifically, I think you're right, and AFAICT asking for the
> >>> list
> >>> of modes again is the only way for the userspace to distinguish
> >>> between
> >>> the two cases. I don't think there's a shortcut for deciding the
> >>> current
> >>> mode is still valid.
> >> To avoid the busy-loop problem, I think I'd like this patch to
> >> re-query
> >> the kernel to ask about the current mode list, and only try to re-set
> >> the mode if our mode is still there.
> >>
> >> If the mode isn't there, then it's up to the DE to take action in
> >> response to the notification of new modes.  If you don't have a DE to
> >> take appropriate action, you're kind of out of luck.
> >>
> >> As far as the ABI goes, this seems fine to me.  The only concern I had
> >> about ABI was having to walk all the connectors on every uevent to see
> >> if any had gone bad -- couldn't we have a flag of some sort about what
> >> the uevent indicates?  But uevents should be super rare, so I'd say
> >> the
> >> kernel could go ahead with the current plan.
> > Yes I agree. The kernel sets the link status BAD as soona s link
> > training fails
> > but does not prune the modes until a new modelist is requested by
> > the userspace.
> > So this patch should re query the mode list as soon as it sees the
> > link status
> > BAD in order for the kernel to validate the modes again based on new
> > link
> > paarmeters and send a new mode list back.
>  Seems like a bad behaviour from the kernel, isn't it? It should return
>  immediatly
>  if the mode is gonna be pruned :s
> >>> The mode list pruning isn't relevant for modeesets, the kernel doesn't
> >>> validate requested modes against that. The mode list is purely for
> >>> userspace's information. Which means updating it only when userspace asks
> >>> for it is fine.
> >>
> >> Hmm, ok. Fair enough!
> >>
> >>> I also thought some more about the loop when we're stuck on BAD, and I
> >>> think it shouldn't happen: When the link goes BAD we update the link
> 

[Bug 99762] "Black Mesa" not launching

[bugzilla-daemon]

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

--- Comment #3 from Bronson  ---
ok i found a linux script to launch the game under linux in the folder.
This is the error log i get from the command line:

libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
X Error of failed request:  BadValue (integer parameter out of range for
operation)
  Major opcode of failed request:  155 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Value in failed request:  0x0
  Serial number of failed request:  94
  Current serial number in output stream:  95

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

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Eric Anholt]

Martin Peres  writes:

> On 06/02/17 17:50, Martin Peres wrote:
>> On 03/02/17 10:04, Daniel Vetter wrote:
>>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote:
 On 01/02/17 22:05, Manasi Navare wrote:
> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
>> Jani Nikula  writes:
>>
>>> On Tue, 31 Jan 2017, Eric Anholt  wrote:
 Martin Peres  writes:

> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode before setting the offending
> connector's
> link-status to BAD and send the userspace a hotplug event. This may
> happen right after a modeset or later on.
>
> When available, we should use the link-status information to reset
> the wanted mode.
>
> Signed-off-by: Martin Peres 
 If I understand this right, there are two failure modes being
 handled:

 1) A mode that won't actually work because the link isn't good
 enough.

 2) A mode that should work, but link parameters were too
 optimistic and
 if we just ask the kernel to set the mode again it'll use more
 conservative parameters that work.

 This patch seems good for 2).  For 1), the drmmode_set_mode_major is
 going to set our old mode back.  Won't the modeset then fail to link
 train again, and bring us back into this loop?  The only escape
 that I
 see would be some other userspace responding to the advertised
 mode list
 changing, and then asking X to modeset to something new.

 To avoid that failure busy loop, should we re-fetching modes at this
 point, and only re-setting if our mode still exists?
>>> Disclaimer: I don't know anything about the internals of the
>>> modesetting
>>> driver.
>>>
>>> Perhaps we can identify the two cases now, but I'd put this more
>>> generally: if the link status has gone bad, it's an indicator to
>>> userspace that the circumstances may have changed, and userspace
>>> should
>>> query the kernel for the list of available modes again. It should no
>>> longer trust information obtained prior to getting the bad link
>>> status,
>>> including the current mode.
>>>
>>> But specifically, I think you're right, and AFAICT asking for the
>>> list
>>> of modes again is the only way for the userspace to distinguish
>>> between
>>> the two cases. I don't think there's a shortcut for deciding the
>>> current
>>> mode is still valid.
>> To avoid the busy-loop problem, I think I'd like this patch to
>> re-query
>> the kernel to ask about the current mode list, and only try to re-set
>> the mode if our mode is still there.
>>
>> If the mode isn't there, then it's up to the DE to take action in
>> response to the notification of new modes.  If you don't have a DE to
>> take appropriate action, you're kind of out of luck.
>>
>> As far as the ABI goes, this seems fine to me.  The only concern I had
>> about ABI was having to walk all the connectors on every uevent to see
>> if any had gone bad -- couldn't we have a flag of some sort about what
>> the uevent indicates?  But uevents should be super rare, so I'd say
>> the
>> kernel could go ahead with the current plan.
> Yes I agree. The kernel sets the link status BAD as soona s link
> training fails
> but does not prune the modes until a new modelist is requested by
> the userspace.
> So this patch should re query the mode list as soon as it sees the
> link status
> BAD in order for the kernel to validate the modes again based on new
> link
> paarmeters and send a new mode list back.
 Seems like a bad behaviour from the kernel, isn't it? It should return
 immediatly
 if the mode is gonna be pruned :s
>>> The mode list pruning isn't relevant for modeesets, the kernel doesn't
>>> validate requested modes against that. The mode list is purely for
>>> userspace's information. Which means updating it only when userspace asks
>>> for it is fine.
>>
>> Hmm, ok. Fair enough!
>>
>>> I also thought some more about the loop when we're stuck on BAD, and I
>>> think it shouldn't happen: When the link goes BAD we update the link
>>> parameter values to the new limits, and the kernel will reject any mode
>>> that won't fit anymore. Of course you might be unlucky, and the new link
>>> limits are also not working, but eventually you're stuck at the "you're
>>> link is broken, sry" stage, 

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #88 from freedesk...@bremsspur.org ---
(In reply to Andreas Hartmetz from comment #87)
> For the record, the game side fix has NOT been shipped by Steam yet, at
> least for me, in Germany, not on a beta program. In case anyone else gets
> confused.

it's not public yet https://steamdb.info/app/252950/depots/

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

Re: [RFC simple allocator v2 0/2] Simple allocator

[Laura Abbott]

On 02/13/2017 10:18 AM, Mark Brown wrote:
> On Mon, Feb 13, 2017 at 03:45:04PM +0100, Benjamin Gaignard wrote:
> 
>> An other question is: do we have others memory regions that could be 
>> interested
>> by this new framework ? I have in mind that some title memory regions could 
>> use
>> it or replace ION heaps (system, carveout, etc...).
>> Maybe it only solve CMA allocation issue, in this case there is no need to 
>> create
>> a new framework but only a dedicated ioctl.
> 
> The software defined networking people seemed to think they had a use
> case for this as well.  They're not entirely upstream of course but
> still...
> 

This is the first I've heard of anything like this. Do you have any more
details/reading?

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

[bug report] drm/amdgpu: refine uvd4.2 init/stop code.

[Dan Carpenter]

Hello Rex Zhu,

The patch 8b55d17eeea7: "drm/amdgpu: refine uvd4.2 init/stop code."
from Jan 20, 2017, leads to the following static checker warning:

drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:397 uvd_v4_2_stop()
info: ignoring unreachable code.

drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:407 uvd_v4_2_stop()
info: ignoring unreachable code.

drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:420 uvd_v4_2_stop()
info: ignoring unreachable code.


drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c
   390  static void uvd_v4_2_stop(struct amdgpu_device *adev)
   391  {
   392  uint32_t i, j;
   393  uint32_t status;
   394  
   395  WREG32(mmUVD_RBC_RB_CNTL, 0x11010101);
   396  
   397  for (i = 0; i < 10; ++i) {
   398  for (j = 0; j < 100; ++j) {
   399  status = RREG32(mmUVD_STATUS);
   400  if (status & 2)
   401  break;
   402  mdelay(1);
   403  }
   404  break;

This i < 10 loops don't make sense because we break after the first
iteration...  What is intended?

   405  }
   406  
   407  for (i = 0; i < 10; ++i) {
   408  for (j = 0; j < 100; ++j) {
   409  status = RREG32(mmUVD_LMI_STATUS);
   410  if (status & 0xf)
   411  break;
   412  mdelay(1);
   413  }
   414  break;
^^
   415  }
   416  
   417  /* Stall UMC and register bus before resetting VCPU */
   418  WREG32_P(mmUVD_LMI_CTRL2, 1 << 8, ~(1 << 8));
   419  
   420  for (i = 0; i < 10; ++i) {
   421  for (j = 0; j < 100; ++j) {
   422  status = RREG32(mmUVD_LMI_STATUS);
   423  if (status & 0x240)
   424  break;
   425  mdelay(1);
   426  }
   427  break;
^^
   428  }
   429  

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

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #26 from Reimar Imhof  ---
According comment #15: Things are properly tested.

Together with comment #24 there is a render bug in kernel 4.8 that shows up at
100% cpu load.
With kernel 4.9 this same bug shows up at 0% / idle cpu load.

With 
af79ad2b1f337a00aa150b993635b10bc68dc842
Merge branch 'sched-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
it changed from "bug shows at 100% load" to "bug shows at 0% load". And the
change is something about the scheduler.
To me this seems likely.

In summery the word "regression" might be wrong.

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

Re: [RFC simple allocator v2 0/2] Simple allocator

[Mark Brown]

On Mon, Feb 13, 2017 at 03:45:04PM +0100, Benjamin Gaignard wrote:

> An other question is: do we have others memory regions that could be 
> interested
> by this new framework ? I have in mind that some title memory regions could 
> use
> it or replace ION heaps (system, carveout, etc...).
> Maybe it only solve CMA allocation issue, in this case there is no need to 
> create
> a new framework but only a dedicated ioctl.

The software defined networking people seemed to think they had a use
case for this as well.  They're not entirely upstream of course but
still...


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

[PATCH] drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support

[ville . syrjala]

From: Ville Syrjälä 

Check that the sink really declared 12bpc support before we enable it.
This should not actually never happen since it's mandatory for HDMI
sinks to support 12bpc if they support any deep color modes. But
reality disagrees with the theory and there are actually sinks in
the wild that violate the spec.

v2: Fix the output_types check
Update commit message to state that these things are in fact real

Cc: sta...@vger.kernel.org
Cc: Nicholas Sielicki 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99250
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a580de80d2b5..2bf5915284aa 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1298,16 +1298,34 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
 
 static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
 {
-   struct drm_device *dev = crtc_state->base.crtc->dev;
+   struct drm_i915_private *dev_priv =
+   to_i915(crtc_state->base.crtc->dev);
+   struct drm_atomic_state *state = crtc_state->base.state;
+   struct drm_connector_state *connector_state;
+   struct drm_connector *connector;
+   int i;
 
-   if (HAS_GMCH_DISPLAY(to_i915(dev)))
+   if (HAS_GMCH_DISPLAY(dev_priv))
return false;
 
/*
 * HDMI 12bpc affects the clocks, so it's only possible
 * when not cloning with other encoder types.
 */
-   return crtc_state->output_types == 1 << INTEL_OUTPUT_HDMI;
+   if (crtc_state->output_types != 1 << INTEL_OUTPUT_HDMI)
+   return false;
+
+   for_each_connector_in_state(state, connector, connector_state, i) {
+   const struct drm_display_info *info = >display_info;
+
+   if (connector_state->crtc != crtc_state->base.crtc)
+   continue;
+
+   if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
+   return false;
+   }
+
+   return true;
 }
 
 bool intel_hdmi_compute_config(struct intel_encoder *encoder,
-- 
2.10.2

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

Re: [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

[Sean Paul]

On Mon, Feb 13, 2017 at 3:59 AM, Chris Wilson  wrote:
> On Mon, Feb 13, 2017 at 08:41:10AM +0100, Thierry Reding wrote:
>> On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote:
>> > The warnings from parsing the EDID are not driver errors, but the
>> > "normal but significant" conditions from the external device. As such,
>> > they do not need the ferocity of an *ERROR*, but can use the less harsh
>> > DRM_NOTE instead.
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  drivers/gpu/drm/drm_edid.c | 15 ---
>> >  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> The below are all conditions that happen when the EDID is bad. I'm not
>> sure that really qualifies as "normal".
>
> Often it is - a bad EDID on the monitor will always be bad. The
> challenge is distinguishing that from silent data corruption during the
> read - a reported read failure are trivial.
>
>> From a quick look through the code we don't always trigger an error from
>> the below failure paths at higher levels, so decreasing the level here
>> has the potential to let this kind of exceptional condition go
>> unnoticed.
>
> The messages are not gone, they are higher than the default loglevel,
> but now below the level at which they are printed to a terminal. The
> bad EDID is either expected or recoverable, and definitely not fatal
> so I don't think an *ERROR* is justified.

I tend to agree.

The description for the KERN_NOTICE level is "normal but significant
condition". I might argue that the presence of these EDID messages
represents a normal *or* significant condition (depending on why the
EDID is bad), but I don't think it's unreasonable to expect people to
check their logs if the display/mode is not working properly.

Sean



> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 9/9] drm/i915: Add render decompression support

[Ville Syrjälä]

On Tue, Feb 07, 2017 at 05:37:44PM +0200, Imre Deak wrote:
> On Thu, Jan 05, 2017 at 05:14:54PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engine
> > the location of the color control surfae (CCS) which describes
> > which parts of the main surface are compressed and which are not. The
> > location of CCS is provided by userspace as just another plane with its
> > own offset.
> > 
> > Add the required stuff to validate the user provided AUX plane metadata
> > and convert the user provided linear offset into something the hardware
> > can consume.
> > 
> > Due to hardware limitations we require that the main surface and
> > the AUX surface (CCS) be part of the same bo. The hardware also
> > makes life hard by not allowing you to provide separate x/y offsets
> > for the main and AUX surfaces (excpet with NV12), so finding suitable
> > offsets for both requires a bit of work. Assuming we still want keep
> > playing tricks with the offsets. I've just gone with a dumb "search
> > backward for suitable offsets" approach, which is far from optimal,
> > but it works.
> > 
> > Also not all planes will be capable of scanning out compressed surfaces,
> > and eg. 90/270 degree rotation is not supported in combination with
> > decompression either.
> > 
> > This patch may contain work from at least the following people:
> > * Vandana Kannan 
> > * Daniel Vetter 
> > * Ben Widawsky 
> > 
> > v2: Deal with display workarounds 0390, 0531, 1125 (Paulo)
> > 
> > Cc: Paulo Zanoni 
> > Cc: Vandana Kannan 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  23 
> >  drivers/gpu/drm/i915/intel_display.c | 234 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c  |  29 -
> >  drivers/gpu/drm/i915/intel_sprite.c  |   5 +
> >  4 files changed, 274 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 00970aa77afa..6849ba93f1d9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6209,6 +6209,28 @@ enum {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A),   \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >  
> > +#define PLANE_AUX_DIST_1_A 0x701c0
> > +#define PLANE_AUX_DIST_2_A 0x702c0
> > +#define PLANE_AUX_DIST_1_B 0x711c0
> > +#define PLANE_AUX_DIST_2_B 0x712c0
> > +#define _PLANE_AUX_DIST_1(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B)
> > +#define _PLANE_AUX_DIST_2(pipe) \
> > +   _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B)
> > +#define PLANE_AUX_DIST(pipe, plane) \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe))
> > +
> > +#define PLANE_AUX_OFFSET_1_A   0x701c4
> > +#define PLANE_AUX_OFFSET_2_A   0x702c4
> > +#define PLANE_AUX_OFFSET_1_B   0x711c4
> > +#define PLANE_AUX_OFFSET_2_B   0x712c4
> > +#define _PLANE_AUX_OFFSET_1(pipe)   \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B)
> > +#define _PLANE_AUX_OFFSET_2(pipe)   \
> > +   _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B)
> > +#define PLANE_AUX_OFFSET(pipe, plane)   \
> > +   _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe))
> > +
> >  /* legacy palette */
> >  #define _LGC_PALETTE_A   0x4a000
> >  #define _LGC_PALETTE_B   0x4a800
> > @@ -6433,6 +6455,7 @@ enum {
> >  # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
> >  
> >  #define CHICKEN_PAR1_1 _MMIO(0x42080)
> > +#define  SKL_RC_HASH_OUTSIDE   (1 << 15)
> >  #define  DPA_MASK_VBLANK_SRD   (1 << 15)
> >  #define  FORCE_ARB_IDLE_PLANES (1 << 14)
> >  #define  SKL_EDP_PSR_FIX_RDWRAP(1 << 3)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 38de9df0ec60..2236abebd8bc 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2064,11 +2064,19 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> > *fb, int plane)
> > return 128;
> > else
> > return 512;
> > +   case I915_FORMAT_MOD_Y_TILED_CCS:
> > +   if (plane == 1)
> > +   return 64;
> > +   /* fall through */
> > case I915_FORMAT_MOD_Y_TILED:
> > if 

[Bug 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

--- Comment #22 from Grazvydas Ignotas  ---
(In reply to cosiekvfj from comment #21)
> Can you explain this bug and patch to my? :) What now?
The patch has been rejected (more or less), see the mailing list for details:
https://lists.freedesktop.org/archives/mesa-dev/2017-February/144118.html

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

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #1 from Thore Bödecker (m...@foxxx0.de) ---
Created attachment 254731
  --> https://bugzilla.kernel.org/attachment.cgi?id=254731=edit
dmesg including backtrace

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

[Bug 194579] New: AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

Bug ID: 194579
   Summary: AMDGPU: Possible size overflow detected by PaX in
ttm_bo_handle_move_mem
(drivers/gpu/drm/ttm/ttm_bo.c:388)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9.9
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: m...@foxxx0.de
Regression: No

While trying out the experimental amdgpu support for Southern Islands radeon
cards, I stumpled upon this issue due to using the grsec patchset.

It seems there is a size overflow:

kernel: PAX: size overflow detected in function ttm_bo_handle_move_mem
drivers/gpu/drm/ttm/ttm_bo.c:388 cicus.459_185 max, count: 5, decl: offset;
num: 0; context: ttm_buffer_object;


After addings a debug printk():

kernel: PAX start:7fff type:1 offset:8000


Would be great if someone could provide some insight and confirm that it is
undesired behaviour.


Best,
Thore

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

[PATCH] drm: mali-dp: add atomic_print_state for planes

[Mihail Atanassov]

Print all the extra fields of malidp_plane_state.

Signed-off-by: Mihail Atanassov 
---
 drivers/gpu/drm/arm/malidp_planes.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 414aada..3879dc5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "malidp_hw.h"
 #include "malidp_drv.h"
@@ -88,6 +89,17 @@ static void malidp_destroy_plane_state(struct drm_plane 
*plane,
kfree(m_state);
 }
 
+static void malidp_plane_atomic_print_state(struct drm_printer *p,
+   const struct drm_plane_state *state)
+{
+   struct malidp_plane_state *ms = to_malidp_plane_state(state);
+   struct malidp_plane *mp = to_malidp_plane(state->plane);
+
+   drm_printf(p, "\trotmem_size=%u\n", ms->rotmem_size);
+   drm_printf(p, "\tformat_id=%u\n", ms->format);
+   drm_printf(p, "\tn_planes=%u\n", ms->n_planes);
+}
+
 static const struct drm_plane_funcs malidp_de_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -96,6 +108,7 @@ static void malidp_destroy_plane_state(struct drm_plane 
*plane,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = malidp_duplicate_plane_state,
.atomic_destroy_state = malidp_destroy_plane_state,
+   .atomic_print_state = malidp_plane_atomic_print_state,
 };
 
 static int malidp_de_plane_check(struct drm_plane *plane,
-- 
1.9.1

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

[Bug 194561] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs (blank screen happens after launching directx app through wine)

[bugzilla-daemon]

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

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

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
This is a GPU hang.  Most likely a bug in wine or mesa.  The atombios error is
just a symptom of the GPU hang.

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

[RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

This is the core of simple allocator module.
It aim to offert one common ioctl to allocate specific memory.

version 2:
- rebased on 4.10-rc7

Signed-off-by: Benjamin Gaignard 
---
 Documentation/simple-allocator.txt  |  81 +++
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/simpleallocator/Kconfig |  10 ++
 drivers/simpleallocator/Makefile|   1 +
 drivers/simpleallocator/simple-allocator-priv.h |  33 +
 drivers/simpleallocator/simple-allocator.c  | 180 
 include/uapi/linux/simple-allocator.h   |  35 +
 8 files changed, 343 insertions(+)
 create mode 100644 Documentation/simple-allocator.txt
 create mode 100644 drivers/simpleallocator/Kconfig
 create mode 100644 drivers/simpleallocator/Makefile
 create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
 create mode 100644 drivers/simpleallocator/simple-allocator.c
 create mode 100644 include/uapi/linux/simple-allocator.h

diff --git a/Documentation/simple-allocator.txt 
b/Documentation/simple-allocator.txt
new file mode 100644
index 000..89ba883
--- /dev/null
+++ b/Documentation/simple-allocator.txt
@@ -0,0 +1,81 @@
+Simple Allocator Framework
+
+Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
+on dedicated memory regions and export them as a dmabuf file descriptor.
+Using dmabuf file descriptor allow to share this memory between processes
+and/or import it into other frameworks like v4l2 or drm/kms (prime).
+When userland wants to free the memory only a call to close() in needed
+so it could done even without knowing that buffer has been allocated by
+simple allocator ioctl.
+
+Each memory regions will be seen as a filein /dev/.
+For example CMA regions will exposed has /dev/cmaX.
+
+Implementing a simple allocator
+---
+
+Simple Allocator provide helpers functions to register/unregister an
+allocator:
+- simple_allocator_register(struct sa_device *sadev)
+  Register simple_allocator_device using sa_device structure where name,
+  owner and allocate fields must be set.
+
+- simple_allocator_unregister(struct sa_device *sadev)
+  Unregister a simple allocator device.
+
+Using Simple Allocator /dev interface example
+-
+
+This example of code allocate a buffer on the first CMA region (/dev/cma0)
+before mmap and close it.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "simple-allocator.h"
+
+#define LENGTH 1024*16
+
+void main (void)
+{
+   struct simple_allocate_data data;
+   int fd = open("/dev/cma0", O_RDWR, 0);
+   int ret;
+   void *mem;
+
+   if (fd < 0) {
+   printf("Can't open /dev/cma0\n");
+   return;
+   }
+
+   memset(, 0, sizeof(data));
+
+   data.length = LENGTH;
+   data.flags = O_RDWR | O_CLOEXEC;
+
+   ret = ioctl(fd, SA_IOC_ALLOC, );
+   if (ret) {
+   printf("Buffer allocation failed\n");
+   goto end;
+   }
+
+   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
+   if (mem == MAP_FAILED) {
+   printf("mmap failed\n");
+   }
+
+   memset(mem, 0xFF, LENGTH);
+   munmap(mem, LENGTH);
+
+   printf("test simple allocator CMA OK\n");
+end:
+   close(fd);
+}
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066..a6d8828 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/simpleallocator/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 060026a..5081eb8 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
 obj-$(CONFIG_ANDROID)  += android/
 obj-$(CONFIG_NVMEM)+= nvmem/
 obj-$(CONFIG_FPGA) += fpga/
+obj-$(CONFIG_SIMPLE_ALLOCATOR) += simpleallocator/
diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
new file mode 100644
index 000..c6fc2e3
--- /dev/null
+++ b/drivers/simpleallocator/Kconfig
@@ -0,0 +1,10 @@
+menu "Simple Allocator"
+
+config SIMPLE_ALLOCATOR
+   tristate "Simple Alllocator Framework"
+   select DMA_SHARED_BUFFER
+   ---help---
+  The Simple Allocator Framework adds an API to allocate and share
+  memory in userland.
+
+endmenu
diff --git a/drivers/simpleallocator/Makefile b/drivers/simpleallocator/Makefile
new file mode 100644
index 000..e27c6ad
--- /dev/null
+++ b/drivers/simpleallocator/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SIMPLE_ALLOCATOR) += simple-allocator.o
diff --git a/drivers/simpleallocator/simple-allocator-priv.h 
b/drivers/simpleallocator/simple-allocator-priv.h
new file 

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Ville Syrjälä]

On Mon, Feb 13, 2017 at 11:35:18AM +0100, Maxime Ripard wrote:
> Hi Ville,
> 
> On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> > > From: Stefan Christ 
> > > 
> > > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> > > framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> > > based OpenGL(ES)/EGL implementations may require the ioctl to
> > > synchronize drawing or buffer flip for double buffering. It is tested on
> > > the i.MX6.
> > > 
> > > Code is based on
> > > 
> > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> > > 
> > > Signed-off-by: Stefan Christ 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  drivers/gpu/drm/drm_fb_helper.c | 55 ++-
> > >  include/drm/drm_fb_helper.h |  5 ++-
> > >  2 files changed, 59 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index e934b541feea..39a3532e311c 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> > > struct fb_info *info)
> > >  EXPORT_SYMBOL(drm_fb_helper_setcmap);
> > >  
> > >  /**
> > > + * drm_fb_helper_ioctl - legacy ioctl implementation
> > > + * @info: fbdev registered by the helper
> > > + * @cmd: ioctl command
> > > + * @arg: ioctl argument
> > > + *
> > > + * A helper to implement the standard fbdev ioctl. Only
> > > + * FBIO_WAITFORVSYNC is implemented for now.
> > > + */
> > > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> > > long arg)
> > > +{
> > > + struct drm_fb_helper *fb_helper = info->par;
> > > + struct drm_device *dev = fb_helper->dev;
> > > + unsigned int i;
> > > + int ret = 0;
> > > +
> > > + drm_modeset_lock_all(dev);
> > > + if (!drm_fb_helper_is_bound(fb_helper)) {
> > > + drm_modeset_unlock_all(dev);
> > > + return -EBUSY;
> > > + }
> > > +
> > > + switch (cmd) {
> > > + case FBIO_WAITFORVSYNC:
> > > + for (i = 0; i < fb_helper->crtc_count; i++) {
> > 
> > FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
> > to do this for all the crtcs. Though what that crtc means for fb is
> > rather poorly defined.
> 
> I guess I could just use that index to retrieve only the right CRTC in
> fb_helper->crtc_info.
> 
> > 
> > > + struct drm_mode_set *mode_set;
> > > + struct drm_crtc *crtc;
> > > +
> > > + mode_set = _helper->crtc_info[i].mode_set;
> > > + crtc = mode_set->crtc;
> > > +
> > > + /*
> > > +  * Only call drm_crtc_wait_one_vblank for crtcs that
> > > +  * are currently enabled.
> > > +  */
> > > + if (!crtc->enabled)
> > > + continue;
> > > +
> > > + ret = drm_crtc_vblank_get(crtc);
> > > + if (!ret) {
> > > + drm_crtc_wait_one_vblank(crtc);
> > > + drm_crtc_vblank_put(crtc);
> > > + }
> > 
> > This looks quite sub-optimal. It should rather do something along the
> > lines of what drm_atomic_helper_wait_for_vblanks() does.
> 
> How is that suboptimal?

You're serializing the waits rather than doing them in parallel.

Let's look at a simple three crtc example (|=vblank):

time -->
CRTC 1: | | | |
CRTC 2:   | | | |
CRTC 3: | | | |

Your code waits until here:
|   |   |
1   2   3
^

Optimal code would wait until here:
|
^
 
-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC simple allocator v2 2/2] add CMA simple allocator module

[Benjamin Gaignard]

This patch add simple allocator for CMA regions.

version 2:
- fix size and page count computation

Signed-off-by: Benjamin Gaignard 
---
 drivers/simpleallocator/Kconfig|   7 +
 drivers/simpleallocator/Makefile   |   1 +
 drivers/simpleallocator/simple-allocator-cma.c | 187 +
 3 files changed, 195 insertions(+)
 create mode 100644 drivers/simpleallocator/simple-allocator-cma.c

diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
index c6fc2e3..788fb0b 100644
--- a/drivers/simpleallocator/Kconfig
+++ b/drivers/simpleallocator/Kconfig
@@ -7,4 +7,11 @@ config SIMPLE_ALLOCATOR
   The Simple Allocator Framework adds an API to allocate and share
   memory in userland.
 
+config SIMPLE_ALLOCATOR_CMA
+   tristate "Simple Allocator CMA"
+   select SIMPLE_ALLOCATOR
+   depends on DMA_CMA
+   ---help---
+  Select this option to enable Simple Allocator on CMA area.
+
 endmenu
diff --git a/drivers/simpleallocator/Makefile b/drivers/simpleallocator/Makefile
index e27c6ad..4e11611 100644
--- a/drivers/simpleallocator/Makefile
+++ b/drivers/simpleallocator/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_SIMPLE_ALLOCATOR) += simple-allocator.o
+obj-$(CONFIG_SIMPLE_ALLOCATOR_CMA) += simple-allocator-cma.o
diff --git a/drivers/simpleallocator/simple-allocator-cma.c 
b/drivers/simpleallocator/simple-allocator-cma.c
new file mode 100644
index 000..07cbf5b
--- /dev/null
+++ b/drivers/simpleallocator/simple-allocator-cma.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright (C) Linaro 2017
+ *
+ * Author: Benjamin Gaignard 
+ *
+ * License terms:  GNU General Public License (GPL)
+ */
+
+#include 
+#include 
+#include 
+
+#include "simple-allocator-priv.h"
+#include "../mm/cma.h"
+
+struct sa_cma_device {
+   struct sa_device parent;
+   struct cma *cma;
+};
+
+struct sa_cma_buffer_info {
+   void *vaddr;
+   size_t count;
+   size_t size;
+   struct page *pages;
+   struct sa_cma_device *sa_cma;
+};
+
+static struct sa_cma_device *sa_cma[MAX_CMA_AREAS];
+
+static inline struct sa_cma_device *to_sa_cma(struct sa_device *sadev)
+{
+   return container_of(sadev, struct sa_cma_device, parent);
+}
+
+static struct sg_table *sa_cma_map_dma_buf(struct dma_buf_attachment *attach,
+  enum dma_data_direction direction)
+{
+   struct dma_buf *dmabuf = attach->dmabuf;
+   struct sa_cma_buffer_info *info = dmabuf->priv;
+   struct sg_table *sgt;
+   int ret;
+
+   ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+   if (unlikely(ret))
+   return NULL;
+
+   sg_set_page(sgt->sgl, info->pages, info->size, 0);
+   sg_dma_address(sgt->sgl) = (dma_addr_t) page_address(info->pages);
+   sg_dma_len(sgt->sgl) = info->size;
+
+   return sgt;
+}
+
+static void sa_cma_unmap_dma_buf(struct dma_buf_attachment *attach,
+struct sg_table *sgt,
+enum dma_data_direction dir)
+{
+   kfree(sgt);
+}
+
+static int sa_cma_mmap_dma_buf(struct dma_buf *dmabuf,
+  struct vm_area_struct *vma)
+{
+   struct sa_cma_buffer_info *info = dmabuf->priv;
+   unsigned long user_count = vma_pages(vma);
+   unsigned long count = info->count;
+   unsigned long pfn = page_to_pfn(info->pages);
+   unsigned long off = vma->vm_pgoff;
+   int ret = -ENXIO;
+
+   if (off < count && user_count <= (count - off)) {
+   ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+   }
+
+   return ret;
+}
+
+static void sa_cma_release_dma_buf(struct dma_buf *dmabuf)
+{
+   struct sa_cma_buffer_info *info = dmabuf->priv;
+
+   cma_release(info->sa_cma->cma, info->pages, info->count);
+
+   kfree(info);
+}
+
+static void *sa_cma_kmap_dma_buf(struct dma_buf *dmabuf, unsigned long offset)
+{
+   struct sa_cma_buffer_info *info = dmabuf->priv;
+
+   return page_address(info->pages) + offset;
+}
+
+static struct dma_buf_ops sa_dma_buf_ops = {
+   .map_dma_buf = sa_cma_map_dma_buf,
+   .unmap_dma_buf = sa_cma_unmap_dma_buf,
+   .mmap = sa_cma_mmap_dma_buf,
+   .release = sa_cma_release_dma_buf,
+   .kmap_atomic = sa_cma_kmap_dma_buf,
+   .kmap = sa_cma_kmap_dma_buf,
+};
+
+static struct dma_buf *sa_cma_allocate(struct sa_device *sadev,
+  u64 length, u32 flags)
+{
+   DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   struct sa_cma_buffer_info *info;
+   struct dma_buf *dmabuf;
+
+   info = kzalloc(sizeof(*info), GFP_KERNEL);
+   if (!info)
+   return NULL;
+
+   info->size = round_up(length, PAGE_SIZE);
+   info->count = 

[RFC simple allocator v2 0/2] Simple allocator

[Benjamin Gaignard]

version 2:
- rebase code on 4.10-rc7
- fix bug in CMA allocator
- do more tests with wayland dmabuf protocol:
  https://git.linaro.org/people/benjamin.gaignard/simple_allocator.git

The goal of this RFC is to understand if a common ioctl for specific memory
regions allocations is needed/welcome.

Obviously it will not replace allocation done in linux kernel frameworks like
v4l2, drm/kms or others, but offer an alternative when you don't want/need to
use them for buffer allocation.
To keep a compatibility with what already exist allocated buffers are exported
in userland as dmabuf file descriptor (like ION is doing).

"Unix Device Memory Allocator" project [1] wants to create a userland library
which may allow to select, depending of the devices constraint, the best
back-end for allocation. With this RFC I would to propose to have common ioctl
for a maximum of allocators to avoid to duplicated back-ends for this library.

One of the issues that lead me to propose this RFC it is that since the 
beginning
it is a problem to allocate contiguous memory (CMA) without using v4l2 or
drm/kms so the first allocator available in this RFC use CMA memory.

An other question is: do we have others memory regions that could be interested
by this new framework ? I have in mind that some title memory regions could use
it or replace ION heaps (system, carveout, etc...).
Maybe it only solve CMA allocation issue, in this case there is no need to 
create
a new framework but only a dedicated ioctl.

Maybe the first thing to do is to change the name and the location of this 
module, suggestions are welcome.

I have testing this code with the following program:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "simple-allocator.h"

#define LENGTH 1024*16

void main (void)
{
struct simple_allocate_data data;
int fd = open("/dev/cma0", O_RDWR, 0);
int ret;
void *mem;

if (fd < 0) {
printf("Can't open /dev/cma0\n");
return;
}

memset(, 0, sizeof(data));

data.length = LENGTH;
data.flags = O_RDWR | O_CLOEXEC;

ret = ioctl(fd, SA_IOC_ALLOC, );
if (ret) {
printf("Buffer allocation failed\n");
goto end;
}

mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
if (mem == MAP_FAILED) {
printf("mmap failed\n");
}

memset(mem, 0xFF, LENGTH);
munmap(mem, LENGTH);

printf("test simple allocator CMA OK\n");
end:
close(fd);
}

[1] https://github.com/cubanismo/allocator


Benjamin Gaignard (2):
  Create Simple Allocator module
  add CMA simple allocator module

 Documentation/simple-allocator.txt  |  81 ++
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/simpleallocator/Kconfig |  17 +++
 drivers/simpleallocator/Makefile|   2 +
 drivers/simpleallocator/simple-allocator-cma.c  | 187 
 drivers/simpleallocator/simple-allocator-priv.h |  33 +
 drivers/simpleallocator/simple-allocator.c  | 180 +++
 include/uapi/linux/simple-allocator.h   |  35 +
 9 files changed, 538 insertions(+)
 create mode 100644 Documentation/simple-allocator.txt
 create mode 100644 drivers/simpleallocator/Kconfig
 create mode 100644 drivers/simpleallocator/Makefile
 create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
 create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
 create mode 100644 drivers/simpleallocator/simple-allocator.c
 create mode 100644 include/uapi/linux/simple-allocator.h

-- 
1.9.1

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #87 from Andreas Hartmetz  ---
For the record, the game side fix has NOT been shipped by Steam yet, at least
for me, in Germany, not on a beta program. In case anyone else gets confused.

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

[Bug 118701] x86_64 GMA500 reports /dev/dri/card0: failed to set DRM interface version 1.4: Inappropriate ioctl for device

[bugzilla-daemon]

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

--- Comment #7 from Patrik Jakobsson (patrik.r.jakobs...@gmail.com) ---
Hi Stuart,

The fix is available now in most stable kernels. Can you confirm and close the
bug if everything is fine?

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

Re: [PATCH 3/8] mm: cma: Export a few symbols

[Maxime Ripard]

Hi Michal,

On Thu, Feb 09, 2017 at 08:20:47PM +0100, Michal Hocko wrote:
> [CC CMA people]
> 
> On Thu 09-02-17 17:39:17, Maxime Ripard wrote:
> > Modules might want to check their CMA pool size and address for debugging
> > and / or have additional checks.
> > 
> > The obvious way to do this would be through dev_get_cma_area and
> > cma_get_base and cma_get_size, that are currently not exported, which
> > results in a build failure.
> > 
> > Export them to prevent such a failure.
> 
> Who actually uses those exports. None of the follow up patches does
> AFAICS.

This is for the ARM Mali GPU driver that is out of tree, unfortunately.

In one case (using the legacy fbdev API), the driver wants to (and
probably should) validate that the buffer as indeed been allocated
from the memory allocation pool.

Rob suggested that instead of hardcoding it to cover the whole RAM
(which defeats the purpose of that check in the first place), we used
the memory-region bindings in the DT and follow that, which does work
great, but we still have to retrieve the base address and size of that
region, hence why this patches are needed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm: ensure atomic messages consistently include the name of the component

[Maarten Lankhorst]

Op 13-02-17 om 13:27 schreef Russell King:
> Most DRM messages include three pieces of information: the type of the
> component (CRTC, ENCODER, CONNECTOR etc), the DRM object ID of the
> component, and the component name.  However, there are some messages
> which omit the last piece of identifying information.  This makes it
> harder to debug failures when these messages are printed, because the
> DRM object ID doesn't supply enough information to know which piece of
> hardware had a problem.
>
> Update the atomic modeset code to always print the component name along
> with the type and DRM object ID.
>
> Fixes: 4cba68507cf5 ("drm/atomic-helper: Reject legacy flips on a disabled 
> pipe")
> Fixes: 8d4d0d700dda ("drm/atomic-helper: Print an error if vblank wait times 
> out")
> Fixes: 5481c8fb1da2 ("drm/atomic-helper: Check encoder/crtc constraints")
> Fixes: 99cf4a29fa24 ("drm/atomic: Add current-mode blob to CRTC state")
> Fixes: cc4ceb484b37 ("drm: Global atomic state handling")
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/drm_atomic.c|  9 +
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  2 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index fdfb1ec17e66..70d31f800410 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -628,8 +628,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_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
> +  crtc->base.id, crtc->name);
>   return -EINVAL;
>   }
>  
> @@ -1039,8 +1039,9 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
> *state,
>   state->connectors[index].ptr = connector;
>   connector_state->state = state;
>  
> - DRM_DEBUG_ATOMIC("Added [CONNECTOR:%d] %p state to %p\n",
> -  connector->base.id, connector_state, state);
> + DRM_DEBUG_ATOMIC("Added [CONNECTOR:%d:%s] %p state to %p\n",
> +  connector->base.id, connector->name,
> +  connector_state, state);
>  
>   if (connector_state->crtc) {
>   struct drm_crtc_state *crtc_state;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4594477dee00..fc4434fe28e8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -315,10 +315,11 @@ update_connector_routing(struct drm_atomic_state *state,
>   }
>  
>   if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
> - DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> [CRTC:%d]\n",
> + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
> [CRTC:%d:%s]\n",
>new_encoder->base.id,
>new_encoder->name,
> -  connector_state->crtc->base.id);
> +  connector_state->crtc->base.id,
> +  connector_state->crtc->name);
>   return -EINVAL;
>   }
>  
> @@ -1146,7 +1147,8 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device 
> *dev,
>   drm_crtc_vblank_count(crtc),
>   msecs_to_jiffies(50));
>  
> - WARN(!ret, "[CRTC:%d] vblank wait timed out\n", crtc->base.id);
> + WARN(!ret, "[CRTC:%d:%s] vblank wait timed out\n",
> +  crtc->base.id, crtc->name);
>  
>   drm_crtc_vblank_put(crtc);
>   }
> @@ -2783,8 +2785,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
>   /* Make sure we don't accidentally do a full modeset. */
>   state->allow_modeset = false;
>   if (!crtc_state->active) {
> - DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> -  crtc->base.id);
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled, rejecting legacy 
> flip\n",
> +  crtc->base.id, crtc->name);
>   ret = -EINVAL;
>   goto fail;
>   }

All for it, looks sane. The last hunk fails to apply because it's based on
an older version of page_flip, but easy enough to fix.

Reviewed-by: Maarten Lankhorst 

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #86 from Marek Olšák  ---
In that case, Michel is right.

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

Re: [PATCH] drm: ensure atomic messages consistently include the name of the component

[Thierry Reding]

On Mon, Feb 13, 2017 at 12:27:03PM +, Russell King wrote:
> Most DRM messages include three pieces of information: the type of the
> component (CRTC, ENCODER, CONNECTOR etc), the DRM object ID of the
> component, and the component name.  However, there are some messages
> which omit the last piece of identifying information.  This makes it
> harder to debug failures when these messages are printed, because the
> DRM object ID doesn't supply enough information to know which piece of
> hardware had a problem.
> 
> Update the atomic modeset code to always print the component name along
> with the type and DRM object ID.
> 
> Fixes: 4cba68507cf5 ("drm/atomic-helper: Reject legacy flips on a disabled 
> pipe")
> Fixes: 8d4d0d700dda ("drm/atomic-helper: Print an error if vblank wait times 
> out")
> Fixes: 5481c8fb1da2 ("drm/atomic-helper: Check encoder/crtc constraints")
> Fixes: 99cf4a29fa24 ("drm/atomic: Add current-mode blob to CRTC state")
> Fixes: cc4ceb484b37 ("drm: Global atomic state handling")
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/drm_atomic.c|  9 +
>  drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
>  2 files changed, 12 insertions(+), 9 deletions(-)

Looks good:

Acked-by: Thierry Reding 


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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #85 from Jani Kärkkäinen  ---
Well this is confusing. The client update hasn't rolled out to me on steam yet
(the last modified date of the RocketLeague -binary is 31st of January, so
about 2 weeks old), but by updating to a more recent mesa (where the buffer fix
is inplace) the game's lag spikes have been definitely fixed. Also, the lag
spikes were gone only after updating the drivers.

It can't be the client, so it must be the drivers, right?

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

[PATCH v2] drm: mali-dp: Add CTM support

[Mihail Atanassov]

All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.

Signed-off-by: Mihail Atanassov 
---

Link to v1: https://lkml.org/lkml/2017/2/1/254

Changes since v1:
 - Rebased and fixed conflicts
 - Improved clarity of overflow check (+comment)
 - Moved call to malidp_atomic_commit_update_coloradj in the existing crtc
 for-each loop

This patch depends on "[PATCH v3 2/2] drm: mali-dp: enable gamma support", sent
out on 7 Feb (https://lkml.org/lkml/2017/2/7/547).

 drivers/gpu/drm/arm/malidp_crtc.c | 58 +--
 drivers/gpu/drm/arm/malidp_drv.c  | 36 +++-
 drivers/gpu/drm/arm/malidp_drv.h  |  1 +
 drivers/gpu/drm/arm/malidp_regs.h |  2 ++
 4 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 6a46520..7414540 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -192,6 +192,58 @@ static int malidp_crtc_atomic_check_gamma(struct drm_crtc 
*crtc,
return 0;
 }
 
+/*
+ * Check if there is a new CTM and if it contains valid input. Valid here means
+ * that the number is inside the representable range for a Q3.12 number,
+ * excluding truncating the fractional part of the input data.
+ *
+ * The COLORADJ registers can be changed atomically.
+ */
+static int malidp_crtc_atomic_check_ctm(struct drm_crtc *crtc,
+   struct drm_crtc_state *state)
+{
+   struct malidp_crtc_state *mc = to_malidp_crtc_state(state);
+   struct drm_color_ctm *ctm;
+   int i;
+
+   if (!state->color_mgmt_changed)
+   return 0;
+
+   if (!state->ctm)
+   return 0;
+
+   if (crtc->state->ctm && (crtc->state->ctm->base.id ==
+state->ctm->base.id))
+   return 0;
+
+   /*
+* The size of the ctm is checked in
+* drm_atomic_replace_property_blob_from_id.
+*/
+   ctm = (struct drm_color_ctm *)state->ctm->data;
+   for (i = 0; i < ARRAY_SIZE(ctm->matrix); ++i) {
+   /* Convert from S31.32 to Q3.12. */
+   s64 val = ctm->matrix[i];
+   u32 mag = u64)val) & ~BIT_ULL(63)) >> 20) &
+ GENMASK_ULL(14, 0);
+
+   /*
+* Convert to 2s complement and check the destination's top bit
+* for overflow. NB: Can't check before converting or it'd
+* incorrectly reject the case:
+* sign == 1
+* mag == 0x2000
+*/
+   if (val & BIT_ULL(63))
+   mag = ~mag + 1;
+   if (!!(val & BIT_ULL(63)) != !!(mag & BIT(14)))
+   return -EINVAL;
+   mc->coloradj_coeffs[i] = mag;
+   }
+
+   return 0;
+}
+
 static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -269,6 +321,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
}
 
ret = malidp_crtc_atomic_check_gamma(crtc, state);
+   ret = ret ? ret : malidp_crtc_atomic_check_ctm(crtc, state);
 
return ret;
 }
@@ -288,6 +341,7 @@ static struct drm_crtc_state 
*malidp_crtc_duplicate_state(struct drm_crtc *crtc)
 
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
memcpy(state->gamma_coeffs, cs->gamma_coeffs, 
sizeof(state->gamma_coeffs));
+   memcpy(state->coloradj_coeffs, cs->coloradj_coeffs, 
sizeof(state->coloradj_coeffs));
 
return >base;
 }
@@ -358,8 +412,8 @@ int malidp_crtc_init(struct drm_device *drm)
 
drm_crtc_helper_add(>crtc, _crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(>crtc, MALIDP_GAMMA_LUT_SIZE);
-   /* No inverse-gamma and color adjustments yet. */
-   drm_crtc_enable_color_mgmt(>crtc, 0, false, 
MALIDP_GAMMA_LUT_SIZE);
+   /* No inverse-gamma: it is per-plane. */
+   drm_crtc_enable_color_mgmt(>crtc, 0, true, 
MALIDP_GAMMA_LUT_SIZE);
return 0;
 
 crtc_cleanup_planes:
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ce741c3..15f0f91 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -77,6 +77,37 @@ static void malidp_atomic_commit_update_gamma(struct 
drm_crtc *crtc,
}
 }
 
+static
+void malidp_atomic_commit_update_coloradj(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+   struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+   struct malidp_hw_device *hwdev = malidp->dev;
+   int i;
+
+   if (!crtc->state->color_mgmt_changed)
+   return;
+
+   if (!crtc->state->ctm) {
+   malidp_hw_clearbits(hwdev, 

Re: imxdrm issue on Hummingboard with LVDS enabled

[Russell King - ARM Linux]

On Mon, Feb 13, 2017 at 09:17:49AM +0100, Thierry Reding wrote:
> Of course, the above still requires that the core messages output the
> name along with the ID.

Thankfully, that's not a very big patch.  I'll post it later today.

-- 
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 7/7] ARM: configs: stm32: ADD LDTC support

[Alexandre Torgue]

Hi Yannick

On 02/10/2017 04:24 PM, Yannick Fertre wrote:

Signed-off-by: Yannick Fertre 


Please add a commit message.


---
 arch/arm/configs/stm32_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index e995209..d6a00b8 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -70,3 +70,8 @@ CONFIG_MAGIC_SYSRQ=y
 # CONFIG_FTRACE is not set
 CONFIG_CRC_ITU_T=y
 CONFIG_CRC7=y
+CONFIG_DRM=y
+CONFIG_DRM_ST=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y


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

[PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction

[zain wang]

The analogix_dp_transfer() will return -EBUSY if num_transferred is zero.
But sometimes we will send a bare address packet to start the transaction,
like drm_dp_i2c_xfer() show:
..
/* Send a bare address packet to start the transaction.
 * Zero sized messages specify an address only (bare
 * address) transaction.
 */
msg.buffer = NULL;
msg.size = 0;
err = drm_dp_i2c_do_msg(aux, );
..

In this case, the msg->size is zero, so the num_transferred will be zero too.
We can't return -EBUSY here, let's we return num_transferred if num_transferred
equals msg->size.

Signed-off-by: zain wang 
---
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 303083a..5384aca 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1162,5 +1162,5 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 (msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_READ)
msg->reply = DP_AUX_NATIVE_REPLY_ACK;
 
-   return num_transferred > 0 ? num_transferred : -EBUSY;
+   return (num_transferred == msg->size) ? num_transferred : -EBUSY;
 }
-- 
1.9.1


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

Re: imxdrm issue on SABRE Lite

[Russell King - ARM Linux]

On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote:
> On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote:
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 21f992605541..46668d071d6a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1201,9 +1201,8 @@ static void commit_tail(struct drm_atomic_state 
> > *state)
> > else
> > drm_atomic_helper_commit_tail(state);
> >  
> > -   drm_atomic_helper_commit_cleanup_done(state);
> > -
> > -   drm_atomic_state_free(state);
> > +   if (drm_atomic_helper_commit_cleanup_done(state) == 0)
> > +   drm_atomic_state_free(state);
> 
> Chris (Cc'ed) added reference counting to atomic state for v4.10, maybe
> that already fixes the issue?

No.  It's not the atomic state that's referenced, it's only a completion
within the drm_crtc_commit structure, which is completely separate from
the atomic state.  Moreover, the event code has no knowledge of commits,
so it can't "put" a reference count on it.  See:

void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e)
{
assert_spin_locked(>event_lock);

if (e->completion) {
/* ->completion might disappear as soon as it signalled. */
complete_all(e->completion);
e->completion = NULL;
}

vs the setup of the event done in drm_atomic_helper_setup_commit():

if (!crtc_state->event) {
commit->event = kzalloc(sizeof(*commit->event),
GFP_KERNEL);
if (!commit->event)
return -ENOMEM;

crtc_state->event = commit->event;
}

crtc_state->event->base.completion = >flip_done;

"commit" gets freed before drm_send_event_locked() is called (hence
the timeout message) and when drm_send_event_locked() is eventually
called via drm_vblank_off(), this causes a use-after-free bug.

-- 
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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

[Chen-Yu Tsai]

On Mon, Feb 13, 2017 at 5:16 PM, Maxime Ripard
 wrote:
> Hi,
>
> On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
>> Added basic display pipeline consisting of tcon, display backend and
>> frontend blocks.
>>
>> Signed-off-by: Priit Laes 
>> ---
>>  arch/arm/boot/dts/sun4i-a10.dtsi | 104 
>> +++
>>  1 file changed, 104 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
>> b/arch/arm/boot/dts/sun4i-a10.dtsi
>> index ba20b48..70991c9 100644
>> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
>> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
>> @@ -779,6 +779,45 @@
>>   #size-cells = <0>;
>>   };
>>
>> + tcon0: lcd-controller@1c0c000 {
>> + compatible = "allwinner,sun5i-a13-tcon";
>
> There's a few bits here and there that need to be setup differently in
> A10, so you cannot reuse that compatible (same thing for the other).
>
> Also, I'd really like to have all the blocks listed here, and not only
> the first pipeline. Ideally, on the A10, the two pipelines should be
> enabled too.

The display pipeline driver has to be fixed before that can happen
though. And I haven't started to work on what I proposed yet. Though
if someone wants to take over I can forward any design plans I have.

ChenYu

>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: imxdrm issue on SABRE Lite

[Russell King - ARM Linux]

On Mon, Feb 13, 2017 at 08:55:53AM +, Chris Wilson wrote:
> On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote:
> > On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote:
> > > On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote:
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 21f992605541..46668d071d6a 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -1201,9 +1201,8 @@ static void commit_tail(struct drm_atomic_state 
> > > *state)
> > >   else
> > >   drm_atomic_helper_commit_tail(state);
> > >  
> > > - drm_atomic_helper_commit_cleanup_done(state);
> > > -
> > > - drm_atomic_state_free(state);
> > > + if (drm_atomic_helper_commit_cleanup_done(state) == 0)
> > > + drm_atomic_state_free(state);
> > 
> > Chris (Cc'ed) added reference counting to atomic state for v4.10, maybe
> > that already fixes the issue?
> 
> I'm not confident it will, as there is not an independent ref on the
> state for the phases, and so a forced timeout still leaves a dangling
> pointer. The above chunk goes the opposite way and leaks the state to
> avoid the invalid deref, what we need is a ref around its existence on
> the dependency queue if that is outside the lifetime of the commit.

I said as much in my email - unfortunately, Thierry cut all that context.

Right now, we oops the kernel, which causes:

(a) the death of the calling process
(b) leaking of all memory associated with the modeset

What I'm proposing for the -stable kernels is to _improve_ the situation
by eliminating part of the problem, so it's possible to get a better
idea of which bit went wrong and which outputs have failed.

Fixing it properly is likely to be very invasive, since you'll need to
add reference counting to the drm_crtc_commit structure, a pointer
to that in the drm_pending_event structure, and ensure that the
reference count gets incremented at the appropriate time.  Incrementing
the reference count in drm_atomic_helper_setup_commit() certainly isn't
the right place, that would be at the sites which queue the event, but
they are scattered amongst all the atomic modeset drivers.

For reference, here's my complete patch I posted yesterday:

 drivers/gpu/drm/drm_atomic_helper.c | 15 +--
 include/drm/drm_atomic_helper.h |  2 +-
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 21f992605541..46668d071d6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1201,9 +1201,8 @@ static void commit_tail(struct drm_atomic_state *state)
else
drm_atomic_helper_commit_tail(state);
 
-   drm_atomic_helper_commit_cleanup_done(state);
-
-   drm_atomic_state_free(state);
+   if (drm_atomic_helper_commit_cleanup_done(state) == 0)
+   drm_atomic_state_free(state);
 }
 
 static void commit_work(struct work_struct *work)
@@ -1591,12 +1590,12 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_hw_done);
  * This is part of the atomic helper support for nonblocking commits, see
  * drm_atomic_helper_setup_commit() for an overview.
  */
-void drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state)
+int drm_atomic_helper_commit_cleanup_done(struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_crtc_commit *commit;
-   int i;
+   int i, failed = 0;
long ret;
 
for_each_crtc_in_state(state, crtc, crtc_state, i) {
@@ -1621,15 +1620,19 @@ void drm_atomic_helper_commit_cleanup_done(struct 
drm_atomic_state *state)
 * not hold a reference of its own. */
ret = wait_for_completion_timeout(>flip_done,
  10*HZ);
-   if (ret == 0)
-   DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
+   if (ret == 0) {
+   DRM_ERROR("[CRTC:%d:%s] flip_done timed out, memory 
leaked\n",
  crtc->base.id, crtc->name);
+   failed = -ETIMEDOUT;
+   }
 
spin_lock(>commit_lock);
 del_commit:
list_del(>commit_entry);
spin_unlock(>commit_lock);
}
+
+   return failed;
 }
 EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
 
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 7ff92b09fd9c..ee3d642c1feb 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -88,7 +88,7 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state 
*state,
   bool nonblock);
 void drm_atomic_helper_wait_for_dependencies(struct drm_atomic_state *state);
 void 

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Boris Brezillon]

On Thu,  9 Feb 2017 13:05:57 -0600
Rob Herring  wrote:

> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> ---
> v2:
> - fix wrong node ptr in imx-ldb
> - build fixes in kirin and imx drivers
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--
>  14 files changed, 88 insertions(+), 397 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 6119b5085501..4614048a4935 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -22,7 +22,7 @@
>  #include 
> 
>  #include 
> -#include 
> +#include 
> 
>  #include "atmel_hlcdc_dc.h"
> 
> @@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
> atmel_hlcdc_panel_connector_funcs = {
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
> 
> -static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
> -   const struct of_endpoint *ep)
> -{
> - struct device_node *np;
> - void *obj;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - obj = of_drm_find_panel(np);
> - if (!obj)
> - obj = of_drm_find_bridge(np);
> -
> - of_node_put(np);
> -
> - return obj ? 0 : -EPROBE_DEFER;
> -}
> -
>  static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
> -const struct of_endpoint *ep)
> +const struct device_node *np)
>  {
>   struct atmel_hlcdc_dc *dc = dev->dev_private;
>   struct atmel_hlcdc_rgb_output *output;
> - struct device_node *np;
>   struct drm_panel *panel;
>   struct drm_bridge *bridge;
>   int ret;
> @@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>   output->encoder.possible_crtcs = 0x1;
> 
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - ret = -EPROBE_DEFER;
> + ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
> + if (ret)
> + return ret;
> 
> - panel = of_drm_find_panel(np);
>   if (panel) {
> - of_node_put(np);
>   output->connector.dpms = DRM_MODE_DPMS_OFF;
>   output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
>   drm_connector_helper_add(>connector,
> @@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
> *dev,
>   return 0;
>   }
> 
> - bridge = of_drm_find_bridge(np);
> - of_node_put(np);
> -
>   if (bridge) {
>   output->encoder.bridge = bridge;
>   bridge->encoder = >encoder;
> @@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct 
> drm_device *dev,
> 
>  int atmel_hlcdc_create_outputs(struct drm_device *dev)
>  {
> - struct device_node *ep_np = NULL;
> - struct of_endpoint ep;
> + struct device_node *remote;
>   int ret;
> 
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_check_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> -
> - for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
> - ret = of_graph_parse_endpoint(ep_np, );
> - if (!ret)
> - ret = atmel_hlcdc_attach_endpoint(dev, );
> -
> - if (ret) {
> - of_node_put(ep_np);
> - return ret;
> - }
> - }
> + remote = 

Re: [PATCH v2 3/6] drm: of: introduce drm_of_find_panel_or_bridge

[Archit Taneja]

On 02/10/2017 12:35 AM, Rob Herring wrote:

Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.

Signed-off-by: Rob Herring 
Acked-by: Philipp Zabel 
---
v2:
- Reworked code flow
- Added note that at least one of panel or bridge must not be NULL.

 drivers/gpu/drm/drm_of.c | 52 
 include/drm/drm_of.h | 13 
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 47848ed8ca48..86b8b959587a 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -3,7 +3,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 

 static void drm_release_of(struct device *dev, void *data)
@@ -207,3 +209,53 @@ int drm_of_encoder_active_endpoint(struct device_node 
*node,
return -EINVAL;
 }
 EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
+
+/*
+ * drm_of_find_panel_or_bridge - return connected panel or bridge device
+ * @np: device tree node containing encoder input ports


Should this be 'encoder output ports'? It's the encoder's output port(s) that
contain the endpoint corresponding to the bridge/panel input port.

Thanks,
Archit


+ * @panel: pointer to hold returned drm_panel
+ * @bridge: pointer to hold returned drm_bridge
+ *
+ * Given a DT node's port and endpoint number, find the connected node and
+ * return either the associated struct drm_panel or drm_bridge device. Either
+ * @panel or @bridge must not be NULL.
+ *
+ * Returns zero if successful, or one of the standard error codes if it fails.
+ */
+int drm_of_find_panel_or_bridge(const struct device_node *np,
+   int port, int endpoint,
+   struct drm_panel **panel,
+   struct drm_bridge **bridge)
+{
+   int ret = -EPROBE_DEFER;
+   struct device_node *remote;
+
+   if (!panel && !bridge)
+   return -EINVAL;
+
+   remote = of_graph_get_remote_node(np, port, endpoint);
+   if (!remote)
+   return -ENODEV;
+
+   if (panel) {
+   *panel = of_drm_find_panel(remote);
+   if (*panel)
+   ret = 0;
+   }
+
+   /* No panel found yet, check for a bridge next. */
+   if (bridge) {
+   if (ret) {
+   *bridge = of_drm_find_bridge(remote);
+   if (*bridge)
+   ret = 0;
+   } else {
+   *bridge = NULL;
+   }
+
+   }
+
+   of_node_put(remote);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge);
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index 26a64805cc15..f86507f0599b 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -8,6 +8,8 @@ struct component_match;
 struct device;
 struct drm_device;
 struct drm_encoder;
+struct drm_panel;
+struct drm_bridge;
 struct device_node;

 #ifdef CONFIG_OF
@@ -23,6 +25,10 @@ extern int drm_of_component_probe(struct device *dev,
 extern int drm_of_encoder_active_endpoint(struct device_node *node,
  struct drm_encoder *encoder,
  struct of_endpoint *endpoint);
+extern int drm_of_find_panel_or_bridge(const struct device_node *np,
+  int port, int endpoint,
+  struct drm_panel **panel,
+  struct drm_bridge **bridge);
 #else
 static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
  struct device_node *port)
@@ -52,6 +58,13 @@ static inline int drm_of_encoder_active_endpoint(struct 
device_node *node,
 {
return -EINVAL;
 }
+static inline int drm_of_find_panel_or_bridge(const struct device_node *np,
+ int port, int endpoint,
+ struct drm_panel **panel,
+ struct drm_bridge **bridge)
+{
+   return -EINVAL;
+}
 #endif

 static inline int drm_of_encoder_active_endpoint_id(struct device_node *node,
--
2.10.1



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node

[Hoegeun Kwon]

diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0be6d65..93ebb12133e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -228,29 +228,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool 
enable)
writel(reg, mic->reg + MIC_OP);
  }

-static struct device_node *get_remote_node(struct device_node *from, int reg)
-{
-   struct device_node *endpoint = NULL, *remote_node = NULL;
-
-   endpoint = of_graph_get_endpoint_by_regs(from, reg, -1);
-   if (!endpoint) {
-   DRM_ERROR("mic: Failed to find remote port from %s",
-   from->full_name);
-   goto exit;
-   }
-
-   remote_node = of_graph_get_remote_port_parent(endpoint);
-   if (!remote_node) {
-   DRM_ERROR("mic: Failed to find remote port parent from %s",
-   from->full_name);
-   goto exit;
-   }
-
-exit:
-   of_node_put(endpoint);
-   return remote_node;
-}
-
  static int parse_dt(struct exynos_mic *mic)
  {
int ret = 0, i, j;
@@ -262,7 +239,7 @@ static int parse_dt(struct exynos_mic *mic)
 * The first node must be for decon and the second one must be for dsi.
 */
for (i = 0, j = 0; i < NUM_ENDPOINTS; i++) {
-   remote_node = get_remote_node(mic->dev->of_node, i);
+   remote_node = of_graph_get_remote_node(mic->dev->of_node, i, 0);
if (!remote_node) {
ret = -EPIPE;
goto exit;
@@ -279,7 +256,7 @@ static int parse_dt(struct exynos_mic *mic)
break;
case ENDPOINT_DSI_NODE:


Dear Rob,

I have tested this patch, rebase these patches on samsung soc tree[1]
and drm exynos tree[2]. But 4/6 patch can not be applied. Because
there is a conflict with the already merged [3] patch.

Best Regards,
Hoegeun

[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ 
(for-next branch)
[2] https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ 
(exynos_drm_next branch)

[3] drm/exynos: mic: Fix parse_dt function (cc2b0225)


/* panel node */
-   remote_node = get_remote_node(remote_node, 1);
+   remote_node = of_graph_get_remote_node(remote_node, 1, 
0);
if (!remote_node) {
ret = -EPIPE;
goto exit;
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index ebd5f4fe4c23..18d6570e057d 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -247,34 +247,6 @@ static const struct component_master_ops kirin_drm_ops = {
.unbind = kirin_drm_unbind,
  };




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

Re: [linux-sunxi] [PATCH 1/8] ARM: sunxi_defconfig: Enable simple panel

[Chen-Yu Tsai]

On Sun, Feb 12, 2017 at 1:43 AM, Priit Laes  wrote:
> From: Jonathan Liu 
>

This needs a commit message about why these need to be enabled, like

"Most Allwinner tablets use the same design of a dumb LCD panel coupled
 with a PWM controlled backlight."

Also the subject does not mention CONFIG_BACKLIGHT_PWM being enabled.

> Signed-off-by: Jonathan Liu 

Since you are resending the patch, you must also add your SoB.

ChenYu

> ---
>  arch/arm/configs/sunxi_defconfig | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index da92c25..7abe6a4 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -153,3 +153,7 @@ CONFIG_NLS_ISO8859_1=y
>  CONFIG_PRINTK_TIME=y
>  CONFIG_DEBUG_FS=y
>  CONFIG_CRYPTO_DEV_SUN4I_SS=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_BACKLIGHT_PWM=y
> +CONFIG_DRM_PANEL_SIMPLE=y
> --
> 2.9.3
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Lankhorst, Maarten]

Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > 
> > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > > 
> > > Having a ->atomic_release callback is useful to release shared
> > > resources
> > > that get allocated in compute_config(). This function is expected
> > > to
> > > be
> > > called in the atomic_check() phase before new resources are
> > > acquired.
> > > 
> > > v2: Moved the caller hunk to this patch (Daniel)
> > > 
> > > Suggested-by: Daniel Vetter 
> > > Signed-off-by: Dhinakaran Pandiyan  > > >
> > > ---
> > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > +++
> > >  include/drm/drm_modeset_helper_vtables.h | 13 +
> > >  2 files changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 8795088..92bd741 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > drm_device *dev,
> > >   }
> > >   }
> > >  
> > > + for_each_connector_in_state(state, connector,
> > > connector_state, i) {
> > > + const struct drm_connector_helper_funcs
> > > *conn_funcs;
> > > + struct drm_crtc_state *crtc_state;
> > > +
> > > + conn_funcs = connector->helper_private;
> > > + if (!conn_funcs->atomic_release)
> > > + continue;
> > > +
> > > + if (!connector->state->crtc)
> > > + continue;
> > > +
> > > + crtc_state =
> > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > >crtc);
> > > +
> > > + if (crtc_state->connectors_changed ||
> > > + crtc_state->mode_changed ||
> > > + (crtc_state->active_changed && !crtc_state-
> > > > 
> > > > active))
> > > + conn_funcs->atomic_release(connector,
> > > connector_state);
> > > + }
> > 
> > Could we deal with the VCPI state separately in
> > intel_modeset_checks,
> > like we do with dpll?
> 
> We'd want to release the VCPI slots before they are acquired in
> ->compute_config(). intel_modeset_checks() will be too late to
> release
> them. Are you suggesting both acquiring and releasing slots should be
> done in intel_modeset_checks()?

That makes things a bit more nasty. Maybe add a
conn_funcs->atomic_check that always gets called, something like I did
below?

I'd love to use it for some atomic connector properties too.
> > 
> > 
> > Maybe implementing the relevant VCPI state could be done as an
> > atomic
> > helper function too, so other atomic drivers can just plug it in.
> > 
> The idea was to reduce boilerplate in the drivers and use the
> private_obj state for different object types.
> 
> 
> > 
> > Not sure how doable this is, but if it's not too hard, then it's
> > probably cleaner :)
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 39cbacd8cd07..1e5f0a95c685 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -381,11 +381,24 @@ mode_fixup(struct drm_atomic_state *state)
 
 	for_each_new_connector_in_state(state, connector, conn_state, i) {
 		const struct drm_encoder_helper_funcs *funcs;
+		const struct drm_connector_helper_funcs *conn_funcs;
 		struct drm_encoder *encoder;
 
+		conn_funcs = connector->helper_private;
+
 		WARN_ON(!!conn_state->best_encoder != !!conn_state->crtc);
 
-		if (!conn_state->crtc || !conn_state->best_encoder)
+		if (!conn_state->crtc || !conn_state->best_encoder) {
+			if (conn_funcs && conn_funcs->atomic_check) {
+ret = conn_funcs->atomic_check(connector, conn_state);
+
+if (ret) {
+	DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] check failed\n",
+			 connector->base.id, connector->name);
+	return ret;
+}
+			}
+
 			continue;
 
 		crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
@@ -404,7 +417,15 @@ mode_fixup(struct drm_atomic_state *state)
 			return -EINVAL;
 		}
 
-		if (funcs && funcs->atomic_check) {
+		if (conn_funcs && conn_funcs->atomic_check) {
+			ret = conn_funcs->atomic_check(connector, conn_state);
+
+			if (ret) {
+DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] check failed\n",
+		  connector->base.id, connector->name);
+return ret;
+			}
+		} else if (funcs && funcs->atomic_check) {
 			ret = funcs->atomic_check(encoder, crtc_state,
 		  conn_state);
 			if (ret) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/6] drm: convert drivers to use drm_of_find_panel_or_bridge

[Archit Taneja]

On 02/10/2017 12:35 AM, Rob Herring wrote:

Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.


For the bridge drivers:

Reviewed-by: Archit Taneja 

Thanks,
Archit



Signed-off-by: Rob Herring 
---
v2:
- fix wrong node ptr in imx-ldb
- build fixes in kirin and imx drivers

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 64 -
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
 drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
 drivers/gpu/drm/bridge/tc358767.c| 27 +--
 drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 49 -
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
 drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
 drivers/gpu/drm/imx/parallel-display.c   | 36 ++
 drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
 drivers/gpu/drm/mxsfb/mxsfb_out.c| 36 ++
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
 drivers/gpu/drm/sun4i/sun4i_rgb.c| 13 ++--
 drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 ++--
 14 files changed, 88 insertions(+), 397 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 6119b5085501..4614048a4935 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -22,7 +22,7 @@
 #include 

 #include 
-#include 
+#include 

 #include "atmel_hlcdc_dc.h"

@@ -152,29 +152,11 @@ static const struct drm_connector_funcs 
atmel_hlcdc_panel_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

-static int atmel_hlcdc_check_endpoint(struct drm_device *dev,
- const struct of_endpoint *ep)
-{
-   struct device_node *np;
-   void *obj;
-
-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   obj = of_drm_find_panel(np);
-   if (!obj)
-   obj = of_drm_find_bridge(np);
-
-   of_node_put(np);
-
-   return obj ? 0 : -EPROBE_DEFER;
-}
-
 static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
-  const struct of_endpoint *ep)
+  const struct device_node *np)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
struct atmel_hlcdc_rgb_output *output;
-   struct device_node *np;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
@@ -195,13 +177,11 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

output->encoder.possible_crtcs = 0x1;

-   np = of_graph_get_remote_port_parent(ep->local_node);
-
-   ret = -EPROBE_DEFER;
+   ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
+   if (ret)
+   return ret;

-   panel = of_drm_find_panel(np);
if (panel) {
-   of_node_put(np);
output->connector.dpms = DRM_MODE_DPMS_OFF;
output->connector.polled = DRM_CONNECTOR_POLL_CONNECT;
drm_connector_helper_add(>connector,
@@ -226,9 +206,6 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,
return 0;
}

-   bridge = of_drm_find_bridge(np);
-   of_node_put(np);
-
if (bridge) {
output->encoder.bridge = bridge;
bridge->encoder = >encoder;
@@ -245,31 +222,14 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device 
*dev,

 int atmel_hlcdc_create_outputs(struct drm_device *dev)
 {
-   struct device_node *ep_np = NULL;
-   struct of_endpoint ep;
+   struct device_node *remote;
int ret;

-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_check_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
-
-   for_each_endpoint_of_node(dev->dev->of_node, ep_np) {
-   ret = of_graph_parse_endpoint(ep_np, );
-   if (!ret)
-   ret = atmel_hlcdc_attach_endpoint(dev, );
-
-   if (ret) {
-   of_node_put(ep_np);
-   return ret;
-   }
-   }
+   remote = of_graph_get_remote_node(dev->dev->of_node, 0, 0);
+   if (!remote)
+   return -ENODEV;

-   return 0;
+  

Re: [PATCH v2 4/6] drm: convert drivers to use of_graph_get_remote_node

[Archit Taneja]

On 02/10/2017 12:35 AM, Rob Herring wrote:

Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.

This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.


For the msm and adv75xx driver:

Tested by: Archit Taneja 



Signed-off-by: Rob Herring 
Acked-by: Neil Armstrong 
Acked-by: Philipp Zabel 
Tested-by: Liviu Dudau 
Tested-by: Eric Anholt 
---
v2:
- tilcdc fix (Jyri Sarha)
- Dropped an incomplete meson change.

 drivers/gpu/drm/arm/hdlcd_drv.c | 22 ++--
 drivers/gpu/drm/arm/malidp_drv.c| 28 ++
 drivers/gpu/drm/bridge/adv7511/adv7533.c| 12 +
 drivers/gpu/drm/bridge/dumb-vga-dac.c   | 15 ++
 drivers/gpu/drm/bridge/ti-tfp410.c  | 15 ++
 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 16 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 ++---
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 27 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 30 +--
 drivers/gpu/drm/mediatek/mtk_dpi.c  | 12 ++---
 drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++
 drivers/gpu/drm/meson/meson_venc_cvbs.c | 19 ++-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  3 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 18 +++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c| 12 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c| 68 +++--
 drivers/gpu/drm/vc4/vc4_dpi.c   | 15 ++
 18 files changed, 55 insertions(+), 324 deletions(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e5f4f4a6546d..0f70f5fe9970 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -430,29 +430,13 @@ static int compare_dev(struct device *dev, void *data)

 static int hdlcd_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

-   if (!pdev->dev.of_node)
-   return -ENODEV;
-
/* there is only one output port inside each device, find it */
-   ep = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
-   if (!ep)
-   return -ENODEV;
-
-   if (!of_device_is_available(ep)) {
-   of_node_put(ep);
+   port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
+   if (!port)
return -ENODEV;
-   }
-
-   /* add the remote encoder port as component */
-   port = of_graph_get_remote_port_parent(ep);
-   of_node_put(ep);
-   if (!port || !of_device_is_available(port)) {
-   of_node_put(port);
-   return -EAGAIN;
-   }

drm_of_component_match_add(>dev, , compare_dev, port);
of_node_put(port);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..47b552f1337c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -262,7 +262,6 @@ static int malidp_bind(struct device *dev)
 {
struct resource *res;
struct drm_device *drm;
-   struct device_node *ep;
struct malidp_drm *malidp;
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
@@ -360,12 +359,7 @@ static int malidp_bind(struct device *dev)
goto init_fail;

/* Set the CRTC's port so that the encoder component can find it */
-   ep = of_graph_get_next_endpoint(dev->of_node, NULL);
-   if (!ep) {
-   ret = -EINVAL;
-   goto port_fail;
-   }
-   malidp->crtc.port = of_get_next_parent(ep);
+   malidp->crtc.port = of_graph_get_port_by_id(dev->of_node, 0);

ret = component_bind_all(dev, drm);
if (ret) {
@@ -420,7 +414,6 @@ static int malidp_bind(struct device *dev)
 bind_fail:
of_node_put(malidp->crtc.port);
malidp->crtc.port = NULL;
-port_fail:
malidp_fini(drm);
 init_fail:
drm->dev_private = NULL;
@@ -478,29 +471,16 @@ static int malidp_compare_dev(struct device *dev, void 
*data)

 static int malidp_platform_probe(struct platform_device *pdev)
 {
-   struct device_node *port, *ep;
+   struct device_node *port;
struct component_match *match = NULL;

if 

[PATCH] drm: ensure atomic messages consistently include the name of the component

[Russell King]

Most DRM messages include three pieces of information: the type of the
component (CRTC, ENCODER, CONNECTOR etc), the DRM object ID of the
component, and the component name.  However, there are some messages
which omit the last piece of identifying information.  This makes it
harder to debug failures when these messages are printed, because the
DRM object ID doesn't supply enough information to know which piece of
hardware had a problem.

Update the atomic modeset code to always print the component name along
with the type and DRM object ID.

Fixes: 4cba68507cf5 ("drm/atomic-helper: Reject legacy flips on a disabled 
pipe")
Fixes: 8d4d0d700dda ("drm/atomic-helper: Print an error if vblank wait times 
out")
Fixes: 5481c8fb1da2 ("drm/atomic-helper: Check encoder/crtc constraints")
Fixes: 99cf4a29fa24 ("drm/atomic: Add current-mode blob to CRTC state")
Fixes: cc4ceb484b37 ("drm: Global atomic state handling")
Signed-off-by: Russell King 
---
 drivers/gpu/drm/drm_atomic.c|  9 +
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index fdfb1ec17e66..70d31f800410 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -628,8 +628,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_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
+crtc->base.id, crtc->name);
return -EINVAL;
}
 
@@ -1039,8 +1039,9 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
state->connectors[index].ptr = connector;
connector_state->state = state;
 
-   DRM_DEBUG_ATOMIC("Added [CONNECTOR:%d] %p state to %p\n",
-connector->base.id, connector_state, state);
+   DRM_DEBUG_ATOMIC("Added [CONNECTOR:%d:%s] %p state to %p\n",
+connector->base.id, connector->name,
+connector_state, state);
 
if (connector_state->crtc) {
struct drm_crtc_state *crtc_state;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 4594477dee00..fc4434fe28e8 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -315,10 +315,11 @@ update_connector_routing(struct drm_atomic_state *state,
}
 
if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
-   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
[CRTC:%d]\n",
+   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] incompatible with 
[CRTC:%d:%s]\n",
 new_encoder->base.id,
 new_encoder->name,
-connector_state->crtc->base.id);
+connector_state->crtc->base.id,
+connector_state->crtc->name);
return -EINVAL;
}
 
@@ -1146,7 +1147,8 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
drm_crtc_vblank_count(crtc),
msecs_to_jiffies(50));
 
-   WARN(!ret, "[CRTC:%d] vblank wait timed out\n", crtc->base.id);
+   WARN(!ret, "[CRTC:%d:%s] vblank wait timed out\n",
+crtc->base.id, crtc->name);
 
drm_crtc_vblank_put(crtc);
}
@@ -2783,8 +2785,8 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
/* Make sure we don't accidentally do a full modeset. */
state->allow_modeset = false;
if (!crtc_state->active) {
-   DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
-crtc->base.id);
+   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled, rejecting legacy 
flip\n",
+crtc->base.id, crtc->name);
ret = -EINVAL;
goto fail;
}
-- 
2.7.4

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

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Daniel Stone]

Hi Maxime,

On 13 February 2017 at 10:54, Maxime Ripard
 wrote:
> On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
>> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
>> > This patch add a config to support to create multi buffer for cma fbdev.
>> > Such as double buffer and triple buffer.
>> >
>> > Cma fbdev is convient to add a legency fbdev. And still many Android
>> > devices use fbdev now and at least double buffer is needed for these
>> > Android devices, so that a buffer flip can be operated. It will need
>> > some time for Android device vendors to abondon legency fbdev. So multi
>> > buffer for fbdev is needed.
>>
>> How exactly do we expect Android to move away from fbdev if we add features 
>> to
>> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is 
>> a
>> thing from the past and that they'd better migrate now.
>
> If your point is that merging this patch will slow down the Android
> move away from fbdev, I disagree with that (obviously).
>
> I don't care at all about Android on my platform of choice, but don't
> see how that merging this patch will change anything.
>
> Let's be honest, Android trees typically have thousands of patches on
> top of mainline. Do you think a simple, 15 LoC, patch will make any
> difference to vendors? If they want to stay on fbdev and have that
> feature, they'll just merge this patch, done.

So, in that case, why not just let them do that? They'd already have
to add patches to use this, surely; we don't have anything in mainline
kernels which allows people to actually use this larger allocation.
Apart from software mmap() and using panning to do flips, but I'm
taking it as a given that people shipping Android on their devices
aren't using software rendering.

> However, what I do see is that three different people/organisations
> have now expressed interest in that feature, on three different
> SoCs. If that patch needed a significant rework of the fbdev layer,
> then yes, I might agree that it's not worth it. But in this case, it's
> pretty trivial.
>
> The only people you're "punishing" here with that kind of concern are
> the people who actually play fair and want not to have any patches and
> everything upstream.

I would hazard a guess that most users of this have out-of-tree GPU drivers.

> I guess a much better strategy would be to provide an incentive to
> moving to KMS. And I truely think there's one already, so it's just a
> matter of time before people switch over. Fbdev emulation or not.

The concern makes sense, but on the other hand, fbdev is deprecated:
no new drivers, and no new features.

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

[Bug 99762] "Black Mesa" not launching

[bugzilla-daemon]

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

smoki  changed:

   What|Removed |Added

  Component|Drivers/Gallium/radeonsi|Drivers/Gallium/r600

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

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Maxime Ripard]

Hi Laurent,

On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
> 
> Thank you for the patch.
> 
> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> > From: Xinliang Liu 
> > 
> > This patch add a config to support to create multi buffer for cma fbdev.
> > Such as double buffer and triple buffer.
> > 
> > Cma fbdev is convient to add a legency fbdev. And still many Android
> > devices use fbdev now and at least double buffer is needed for these
> > Android devices, so that a buffer flip can be operated. It will need
> > some time for Android device vendors to abondon legency fbdev. So multi
> > buffer for fbdev is needed.
> 
> How exactly do we expect Android to move away from fbdev if we add features 
> to 
> the fbdev compat layer ? I'd much rather make it clear to them that fbdev is 
> a 
> thing from the past and that they'd better migrate now.

If your point is that merging this patch will slow down the Android
move away from fbdev, I disagree with that (obviously).

I don't care at all about Android on my platform of choice, but don't
see how that merging this patch will change anything.

Let's be honest, Android trees typically have thousands of patches on
top of mainline. Do you think a simple, 15 LoC, patch will make any
difference to vendors? If they want to stay on fbdev and have that
feature, they'll just merge this patch, done.

However, what I do see is that three different people/organisations
have now expressed interest in that feature, on three different
SoCs. If that patch needed a significant rework of the fbdev layer,
then yes, I might agree that it's not worth it. But in this case, it's
pretty trivial.

The only people you're "punishing" here with that kind of concern are
the people who actually play fair and want not to have any patches and
everything upstream.

I guess a much better strategy would be to provide an incentive to
moving to KMS. And I truely think there's one already, so it's just a
matter of time before people switch over. Fbdev emulation or not.

Ma

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC

[Maxime Ripard]

Hi Ville,

On Fri, Feb 10, 2017 at 04:06:05PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> > From: Stefan Christ 
> > 
> > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> > framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> > based OpenGL(ES)/EGL implementations may require the ioctl to
> > synchronize drawing or buffer flip for double buffering. It is tested on
> > the i.MX6.
> > 
> > Code is based on
> > 
> > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> > 
> > Signed-off-by: Stefan Christ 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 55 ++-
> >  include/drm/drm_fb_helper.h |  5 ++-
> >  2 files changed, 59 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index e934b541feea..39a3532e311c 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> > struct fb_info *info)
> >  EXPORT_SYMBOL(drm_fb_helper_setcmap);
> >  
> >  /**
> > + * drm_fb_helper_ioctl - legacy ioctl implementation
> > + * @info: fbdev registered by the helper
> > + * @cmd: ioctl command
> > + * @arg: ioctl argument
> > + *
> > + * A helper to implement the standard fbdev ioctl. Only
> > + * FBIO_WAITFORVSYNC is implemented for now.
> > + */
> > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
> > long arg)
> > +{
> > +   struct drm_fb_helper *fb_helper = info->par;
> > +   struct drm_device *dev = fb_helper->dev;
> > +   unsigned int i;
> > +   int ret = 0;
> > +
> > +   drm_modeset_lock_all(dev);
> > +   if (!drm_fb_helper_is_bound(fb_helper)) {
> > +   drm_modeset_unlock_all(dev);
> > +   return -EBUSY;
> > +   }
> > +
> > +   switch (cmd) {
> > +   case FBIO_WAITFORVSYNC:
> > +   for (i = 0; i < fb_helper->crtc_count; i++) {
> 
> FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
> to do this for all the crtcs. Though what that crtc means for fb is
> rather poorly defined.

I guess I could just use that index to retrieve only the right CRTC in
fb_helper->crtc_info.

> 
> > +   struct drm_mode_set *mode_set;
> > +   struct drm_crtc *crtc;
> > +
> > +   mode_set = _helper->crtc_info[i].mode_set;
> > +   crtc = mode_set->crtc;
> > +
> > +   /*
> > +* Only call drm_crtc_wait_one_vblank for crtcs that
> > +* are currently enabled.
> > +*/
> > +   if (!crtc->enabled)
> > +   continue;
> > +
> > +   ret = drm_crtc_vblank_get(crtc);
> > +   if (!ret) {
> > +   drm_crtc_wait_one_vblank(crtc);
> > +   drm_crtc_vblank_put(crtc);
> > +   }
> 
> This looks quite sub-optimal. It should rather do something along the
> lines of what drm_atomic_helper_wait_for_vblanks() does.

How is that suboptimal?

As far as I can see, they are both doing the same thing (except one
does for all the CRTCs, but I guess that would no longer be needed
with the change you suggested above):
  - drm_crtc_vblank_get
  - Wait for the vblank count to change
  - drm_crtc_vblank_put

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm/imx: lift 64x64 pixel minimum framebuffer size requirement

[Lucas Stach]

Am Montag, den 13.02.2017, 10:46 +0100 schrieb Philipp Zabel:
> There is no reason to limit framebuffer size to 64x64 pixels at a
> minimum on creation. The actual scanout limitations (width >= 13 for the
> base plane and height >= 2) are checked in atomic_check.
> 
> Signed-off-by: Philipp Zabel 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 33404295b447c..bef76cb0d05dc 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -357,8 +357,8 @@ static int imx_drm_bind(struct device *dev)
>* this value would be used to check framebuffer size limitation
>* at drm_mode_addfb().
>*/
> - drm->mode_config.min_width = 64;
> - drm->mode_config.min_height = 64;
> + drm->mode_config.min_width = 1;
> + drm->mode_config.min_height = 1;
>   drm->mode_config.max_width = 4096;
>   drm->mode_config.max_height = 4096;
>   drm->mode_config.funcs = _drm_mode_config_funcs;


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

[Bug 99762] "Black Mesa" not launching

[bugzilla-daemon]

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

--- Comment #2 from Samuel Pitoiset  ---
"Black Mesa" is working here, both with mesa 13.0.4 and mesa-git. Tested on
RX480.

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

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #26 from Samuel Pitoiset  ---
Can you upload the trace somewhere?

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

[PATCH] drm/imx: lift 64x64 pixel minimum framebuffer size requirement

[Philipp Zabel]

There is no reason to limit framebuffer size to 64x64 pixels at a
minimum on creation. The actual scanout limitations (width >= 13 for the
base plane and height >= 2) are checked in atomic_check.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 33404295b447c..bef76cb0d05dc 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -357,8 +357,8 @@ static int imx_drm_bind(struct device *dev)
 * this value would be used to check framebuffer size limitation
 * at drm_mode_addfb().
 */
-   drm->mode_config.min_width = 64;
-   drm->mode_config.min_height = 64;
+   drm->mode_config.min_width = 1;
+   drm->mode_config.min_height = 1;
drm->mode_config.max_width = 4096;
drm->mode_config.max_height = 4096;
drm->mode_config.funcs = _drm_mode_config_funcs;
-- 
2.11.0

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

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #84 from Marek Olšák  ---
Michel, the commit in master doesn't fix it. It was fixed in the game by using
mallocd memory for the upload process and then memcpy into the buffer.
Therefore, the game doesn't need to use the read flag and doesn't do
read-modify-write on mapped memory.

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

Re: [PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

[Maxime Ripard]

Hi,

On Sat, Feb 11, 2017 at 07:43:59PM +0200, Priit Laes wrote:
> Added basic display pipeline consisting of tcon, display backend and
> frontend blocks.
> 
> Signed-off-by: Priit Laes 
> ---
>  arch/arm/boot/dts/sun4i-a10.dtsi | 104 
> +++
>  1 file changed, 104 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index ba20b48..70991c9 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -779,6 +779,45 @@
>   #size-cells = <0>;
>   };
>  
> + tcon0: lcd-controller@1c0c000 {
> + compatible = "allwinner,sun5i-a13-tcon";

There's a few bits here and there that need to be setup differently in
A10, so you cannot reuse that compatible (same thing for the other).

Also, I'd really like to have all the blocks listed here, and not only
the first pipeline. Ideally, on the A10, the two pipelines should be
enabled too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

[Chris Wilson]

On Mon, Feb 13, 2017 at 08:41:10AM +0100, Thierry Reding wrote:
> On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote:
> > The warnings from parsing the EDID are not driver errors, but the
> > "normal but significant" conditions from the external device. As such,
> > they do not need the ferocity of an *ERROR*, but can use the less harsh
> > DRM_NOTE instead.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 15 ---
> >  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> The below are all conditions that happen when the EDID is bad. I'm not
> sure that really qualifies as "normal".

Often it is - a bad EDID on the monitor will always be bad. The
challenge is distinguishing that from silent data corruption during the
read - a reported read failure are trivial.
 
> From a quick look through the code we don't always trigger an error from
> the below failure paths at higher levels, so decreasing the level here
> has the potential to let this kind of exceptional condition go
> unnoticed.

The messages are not gone, they are higher than the default loglevel,
but now below the level at which they are printed to a terminal. The
bad EDID is either expected or recoverable, and definitely not fatal
so I don't think an *ERROR* is justified.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: imxdrm issue on SABRE Lite

[Chris Wilson]

On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote:
> On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote:
> > On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote:
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 21f992605541..46668d071d6a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1201,9 +1201,8 @@ static void commit_tail(struct drm_atomic_state 
> > *state)
> > else
> > drm_atomic_helper_commit_tail(state);
> >  
> > -   drm_atomic_helper_commit_cleanup_done(state);
> > -
> > -   drm_atomic_state_free(state);
> > +   if (drm_atomic_helper_commit_cleanup_done(state) == 0)
> > +   drm_atomic_state_free(state);
> 
> Chris (Cc'ed) added reference counting to atomic state for v4.10, maybe
> that already fixes the issue?

I'm not confident it will, as there is not an independent ref on the
state for the phases, and so a forced timeout still leaves a dangling
pointer. The above chunk goes the opposite way and leaks the state to
avoid the invalid deref, what we need is a ref around its existence on
the dependency queue if that is outside the lifetime of the commit.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/8] drm/sun4i: Add encoder type argument to sun4i_tcon0_mode_set

[Maxime Ripard]

On Sat, Feb 11, 2017 at 07:44:02PM +0200, Priit Laes wrote:
> Depending on the output type, we have to enable/disable some
> bits conditionally.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  | 2 +-
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
>  drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 ++-
>  3 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> index f5e86fe..3d4eb05 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -179,7 +179,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
> *encoder,
>   struct sun4i_drv *drv = rgb->drv;
>   struct sun4i_tcon *tcon = drv->tcon;
>  
> - sun4i_tcon0_mode_set(tcon, mode);
> + sun4i_tcon0_mode_set(tcon, mode, DRM_MODE_ENCODER_DAC);

This is not the proper encoder type. You can just use encoder_type in
drm_encoder.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: imxdrm issue on Hummingboard with LVDS enabled

[Thierry Reding]

On Sun, Feb 12, 2017 at 01:42:38PM +, Russell King - ARM Linux wrote:
> On Sun, Feb 12, 2017 at 01:18:54PM +, Russell King - ARM Linux wrote:
> > Hi,
> > 
> > Here's another issue with imxdrm.  I got this while trying to reproduce
> > Dan's problem by enabling the lvds output using the patch below
> > originally from Fabio, but updated a bit.  This doesn't occur if I leave
> > LVDS disabled.
> > 
> > The taint is due to the IMX capture modules from Steve, who chose to put
> > his code in drivers/staging/media rather than drivers/media.  However,
> > the last module to make the capture stuff active (imx-csi) which interfaces
> > the drivers/gpu/ipu-v3 code with the capture code has not been loaded.
> > 
> > [ cut here ]
> > WARNING: CPU: 1 PID: 1049 at 
> > /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 
> > drm_atomic_helper_wait_for_vblanks+0x218/0x224
> > [CRTC:29] vblank wait timed out
> 
> Can someone please explain to me how you go from something like
> "[CRTC:29]" to something meaningful, such as identifying which
> exact CRTC failed here?
> 
> Given that the ID numbers given out by DRM for individual components
> come from the dev->mode_config.crtc_idr IDR, without knowing in
> exact detail the precise registration order of these objects with
> drm_mode_object_get(), printing "[CRTC:29]" is utterly meaningless -
> it conveys zero useful information.  DRM might as well be printing
> random numbers instead.
> 
> At least the pre-atomic DRM code printed crtc->name as well, which
> would at least indicate which _CRTC_ in numeric order of registration
> was the cause, which is slightly easier to guess which hardware CRTC
> in question caused the problem.
> 
> Some consistency in DRM land would be nice...

I suppose we could add an optional struct device * to struct drm_crtc
(and possibly struct drm_encoder, struct drm_connector, ...) and take
the name from that to make it more obvious where this is coming from.

Alternatively, you can use the "name" parameter when calling
drm_crtc_init_with_planes() in order to provide a specific name rather
than using the crtc-%d fallback. You could pass dev_name(>dev),
or whatever, to make it clear.

Of course, the above still requires that the core messages output the
name along with the ID.

Thierry


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

Re: [PATCH 4/8] drm/sun4i: Add optional 'mode' property to TCON

[Maxime Ripard]

Hi,

On Sat, Feb 11, 2017 at 07:44:01PM +0200, Priit Laes wrote:
> Add variable to enable either 'rgb' or 'lvds' output.
> 
> Signed-off-by: Priit Laes 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index b82c004..c367ede 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -43,6 +43,9 @@ Required properties:
>   - reset-names: the reset names mentioned above
>   - clock-output-names: Name of the pixel clock created
>  
> +- mode: Defines which encoder will be enabled. Values are 'rgb', 'lvds'.
> +  Defaults to 'rgb' if not set.
> +

Unfortunately, this won't really work. You could very well have two
panels and switch from one to another by changing the pin muxing, so
we have to use an enpoint for that.

This is pretty much the same case that we have with the A10s where we
need to have two output endpoints for the TV Encoder and HDMI,
something we cannot support right now in our binding, since we assume
that we have the two channels that only have one user, which turned
out to be wrong.

I guess an easy way would be to have an extra property defining which
channel the endpoint is attached to.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 7/8] drm/sun4i: Add various bits and pieces to enable LVDS support on sun4i

[Maxime Ripard]

On Sat, Feb 11, 2017 at 07:44:04PM +0200, Priit Laes wrote:
> TODO: We still rely on u-boot for lvds reset bit setup :(

That needs to be figured out before merging :/

You also have a number of checkpatch warnings / errors that needs to
be fixed.

> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/gpu/drm/sun4i/sun4i_lvds.c | 29 
>  drivers/gpu/drm/sun4i/sun4i_tcon.c | 54 
> --
>  drivers/gpu/drm/sun4i/sun4i_tcon.h | 15 +++
>  3 files changed, 90 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> index 2ba4705..de738e5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> @@ -114,6 +114,35 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder 
> *encoder)
>   /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
>   drm_bridge_enable(encoder->bridge);
>  
> + /* Enable the LVDS */
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> +SUN4I_TCON0_LVDS_IF_ENABLE,
> +SUN4I_TCON0_LVDS_IF_ENABLE);
> +
> + /*
> +  * TODO: SUN4I_TCON0_LVDS_ANA0_REG_C and SUN4I_TCON0_LVDS_ANA0_PD
> +  * registers span 3 bits, but we only set upper 2 for both
> +  * of them based on values taken from Allwinner driver.
> +  */
> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
> +  SUN4I_TCON0_LVDS_ANA0_CK_EN |
> +  SUN4I_TCON0_LVDS_ANA0_REG_V |
> +  SUN4I_TCON0_LVDS_ANA0_REG_C |
> +  SUN4I_TCON0_LVDS_ANA0_EN_MB |
> +  SUN4I_TCON0_LVDS_ANA0_PD |
> +  SUN4I_TCON0_LVDS_ANA0_DCHS);
> +
> + udelay(2000);
> +
> + regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
> +  SUN4I_TCON0_LVDS_ANA1_INIT);
> +
> + udelay(1000);
> +
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
> +SUN4I_TCON0_LVDS_ANA1_UPDATE,
> +SUN4I_TCON0_LVDS_ANA1_UPDATE);
> +
>   sun4i_tcon_channel_enable(tcon, 0);

This should be merged in your patch 6.

>  }
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 71d0087..468a3ce 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -18,6 +18,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,7 @@
>  #include "sun4i_crtc.h"
>  #include "sun4i_dotclock.h"
>  #include "sun4i_drv.h"
> +#include "sun4i_lvds.h"
>  #include "sun4i_rgb.h"
>  #include "sun4i_tcon.h"
>  
> @@ -169,12 +171,29 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
>  
>   /* Set Hsync and Vsync length */
> - hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
> - vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
> - DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
> - regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
> -  SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
> -  SUN4I_TCON0_BASIC3_H_SYNC(hsync));
> + if (type != DRM_MODE_ENCODER_LVDS) {
> + // Not needed for LVDS?
> + hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
> + vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
> + DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
> + regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
> +  SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
> +  SUN4I_TCON0_BASIC3_H_SYNC(hsync));
> + }

This is your patch 5 (and it would be better to put the condition on
what we know rather than what we assume, we know that it's working for
RGB, but not for anything else).

> +
> + if (type == DRM_MODE_ENCODER_LVDS) {
> + /* Setup bit depth */
> + /* TODO: Figure out where to get display bit depth
> +  * val = (1: 18-bit, 0: 24-bit)
> +  * TODO: Should we set more registers:
> +  * BIT(28) - LVDS_DIRECTION
> +  * BIT(27) - LVDS_MODE
> +  * BIT(23) - LVDS_CORRECT_MODE
> +  */
> + regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
> +SUN4I_TCON0_LVDS_IF_BITWIDTH,
> +SUN4I_TCON0_LVDS_IF_BITWIDTH);
> + }

And this in your patch 6

>  
>   /* Setup the polarity of the various signals */
>   if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
> @@ -183,8 +202,15 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
>   if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
>   val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
>  
> +
> + /* Set proper DCLK phase value */
> + if (type == DRM_MODE_ENCODER_LVDS)

Re: imxdrm issue on SABRE Lite

[Thierry Reding]

On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote:
> On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote:
> > [   43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> > [CRTC:24:crtc-0] flip_done timed out
> > [   55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> > [CRTC:24:crtc-0] flip_done timed out
> 
> This seems to lay the foundation for the kernel to Oops itself later.
> The problem seems to be this:
> 
> drm_atomic_helper_commit(state->dev, state, false)
> - drm_atomic_helper_setup_commit(state, false)
>   - foreach crtc in state
> - commit->event = kzalloc()
> - crtc_state->event = commit->event
> - crtc_state->event->base.completion = >flip_done
> ...
> - commit_tail(state)
>   - funcs->atomic_commit_tail(state)
> ...
> - drm_atomic_helper_commit_planes(dev, state,
> DRM_PLANE_COMMIT_ACTIVE_ONLY |
> 
> DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODES$  - foreach active crtc in state
> - funcs->atomic_begin(crtc, old_crtc_state)
>   - ipu_crtc_atomic_begin()
> - drm_crtc_vblank_on()
> - if crtc->state->event
>   - drm_crtc_arm_vblank_event(crtc, crtc->state->event)
>   - crtc->state->event = NULL
> 
> At this point, the "commit->flip_done" completion is queued with the
> event onto the vblank list.
> ...
>   - drm_atomic_helper_commit_cleanup_done(state)
> - foreach crtc in state
>   - try_wait_for_completion(>hw_done)
>   - wait_for_completion_timeout(>flip_done, 10sec)
> 
> This is where we get the timeout message.
> 
>   - drm_atomic_state_free(state)
> 
> This "clears" the commit state (calling drm_crtc_commit_put() on it)
> which has the effect of kfree()'ing the structure containing the
> flip_done, but which is still on the vblank list.
> 
> The next time we try to set a mode, the result is that a call to
> drm_crtc_vblank_off() causes all queued events to be sent, including
> the now kfree()'d flip_done completion, resulting in the reported
> kernel oops.
> 
> It seems others are also suffering similar issues when the flip_done
> completion times out with other drivers:
> 
> https://lkml.org/lkml/2016/12/1/171
> https://bugs.freedesktop.org/show_bug.cgi?id=96781
> https://lists.opensuse.org/opensuse-bugs/2016-10/msg03011.html
> https://patchwork.kernel.org/patch/9280223/ (which is me...)
> 
> This is likely the same, although the timeout line was not captured:
> https://bugzilla.redhat.com/show_bug.cgi?id=1415180
> https://bodhi.fedoraproject.org/updates/kernel-4.8.7-200.fc24
> 
> So, can we please avoid killing the kernel when the hardware doesn't
> quite behave as we want it to?
> 
> Right now, when we oops the kernel, we're leaking all the memory
> associated with the atomic modeset, so if we stop oopsing the kernel
> but still leak the memory, surely that would be an improvement?
> Maybe something like the untested patch at the bottom of this mail?
> 
> It would give the opportunity to poke about on a failed system to
> work out what happened and maybe why the hardware misbehaved.
> 
> The real answer is for the hardware to behave, but we can't always
> have our cake.
> 
> Note - I can't reproduce Dan's problem here on 4.10-rc7 as I suspect
> it needs multiple CRTCs/outputs running in the IPU to trigger it,
> which Sabre lite has.  I'll try enabling the (disconnected) LVDS
> output tomorrow (I have Fabio's LVDS patch knocking about), but I
> suspect those with a deeper knowledge of the IPU need to investigate
> what's going on.
> 
> > [  214.765689] imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> > [  214.825688] Unable to handle kernel NULL pointer dereference at
> > virtual address 
> > [  214.833783] pgd = ed1b8000
> > [  214.836491] [] *pgd=4c974831
> > [  214.840084] Internal error: Oops: 17 [#1] SMP ARM
> > [  214.844789] Modules linked in: mousedev snd_soc_sgtl5000
> > snd_soc_fsl_ssi snd_soc_imx_sgtl5000 imx_pcm_fiq imx_pcm_dma
> > snd_soc_fsl_asrc snd_soc_fsl_asoc_card snd_soc_core dw_hdmi_ahb_audio
> > snd_pcm_dmaengine caam_jr imx_ipuv3_crtc snd_ac97_codec coda
> > v4l2_mem2mem videobuf2_dma_contig ac97_bus imx_ipu_v3
> > snd_soc_imx_audmux snd_pcm videobuf2_vmalloc videobuf2_memops
> > videobuf2_v4l2 videobuf2_core dw_hdmi_imx caam imx2_wdt ofpart spi_imx
> > evdev dw_hdmi etnaviv imx_ldb pwm_imx snd_timer parallel_display
> > uio_pdrv_genirq uio imxdrm sch_fq_codel ip_tables x_tables
> > [  214.894338] CPU: 2 PID: 316 Comm: Xorg Tainted: GW
> > 4.9.8-1-ARCH #1
> > [  214.901735] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > [  214.908264] task: ed2c4d00 task.stack: ed2a6000
> > [  214.912803] PC is at __wake_up_common+0x1c/0x80
> > [  214.917337] LR is at __wake_up_locked+0x14/0x1c
> > [  214.921871] pc : []lr : []psr: a0070093
> > [  214.921871] sp : ed2a7c68  ip :   fp : c0fa2a70
> > [