[PATCH 03/20] drm/atmel-hlcdc: Constify function pointer structs

[Boris Brezillon]

Hi Ville,

On Wed,  2 Sep 2015 13:44:01 +0300
ville.syrjala at linux.intel.com wrote:

> From: Ville Syrjälä 
> 
> Moves a bunch of junk to .rodata from .data.
> 
> drivers/gpu/drm/atmel-hlcdc/atmel-hlcdc-dc.ko:
> -.text   12488
> +.text   12480
> -.rodata  1696
> +.rodata  1760
> -.data 776
> +.data 712
> 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Alex Deucher 

Again, just for the record since Thierry already have this patch in his
DRM trivial tree:

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> index 067e4c1..250f69e 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
> @@ -146,7 +146,7 @@ atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder 
> *encoder,
>  cfg);
>  }
>  
> -static struct drm_encoder_helper_funcs 
> atmel_hlcdc_panel_encoder_helper_funcs = {
> +static const struct drm_encoder_helper_funcs 
> atmel_hlcdc_panel_encoder_helper_funcs = {
>   .mode_fixup = atmel_hlcdc_panel_encoder_mode_fixup,
>   .mode_set = atmel_hlcdc_rgb_encoder_mode_set,
>   .disable = atmel_hlcdc_panel_encoder_disable,
> @@ -192,7 +192,7 @@ atmel_hlcdc_rgb_best_encoder(struct drm_connector 
> *connector)
>   return >encoder;
>  }
>  
> -static struct drm_connector_helper_funcs 
> atmel_hlcdc_panel_connector_helper_funcs = {
> +static const struct drm_connector_helper_funcs 
> atmel_hlcdc_panel_connector_helper_funcs = {
>   .get_modes = atmel_hlcdc_panel_get_modes,
>   .mode_valid = atmel_hlcdc_rgb_mode_valid,
>   .best_encoder = atmel_hlcdc_rgb_best_encoder,



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

[PATCH 2/2] drm: Add DRM_DEBUG_VBL()

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

From: Ville Syrjälä 

Add a new debug class for _verbose_ debug message from the vblank code.
That is message we spew out potentially for every vblank interrupt.
Thierry already got annoyed at the spew, and now I managed to lock up
my box with these debug prints (seems serial console + a few debug
prints every vblank aren't a good combination).

Or should I maybe call it DRM_DEBUG_IRQ?

Cc: Thierry Reding 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_irq.c | 22 +++---
 include/drm/drmP.h| 11 ++-
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index bc2e7c6..eba6337 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -213,17 +213,17 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);

if (diff == 0 && flags & DRM_CALLED_FROM_VBLIRQ)
-   DRM_DEBUG("crtc %u: Redundant vblirq ignored."
- " diff_ns = %lld, framedur_ns = %d)\n",
- pipe, (long long) diff_ns, framedur_ns);
+   DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored."
+ " diff_ns = %lld, framedur_ns = %d)\n",
+ pipe, (long long) diff_ns, framedur_ns);
} else {
/* some kind of default for drivers w/o accurate vbl 
timestamping */
diff = (flags & DRM_CALLED_FROM_VBLIRQ) != 0;
}

-   DRM_DEBUG("updating vblank count on crtc %u:"
- " current=%u, diff=%u, hw=%u hw_last=%u\n",
- pipe, vblank->count, diff, cur_vblank, vblank->last);
+   DRM_DEBUG_VBL("updating vblank count on crtc %u:"
+ " current=%u, diff=%u, hw=%u hw_last=%u\n",
+ pipe, vblank->count, diff, cur_vblank, vblank->last);

if (diff == 0) {
WARN_ON_ONCE(cur_vblank != vblank->last);
@@ -800,11 +800,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
etime = ktime_sub_ns(etime, delta_ns);
*vblank_time = ktime_to_timeval(etime);

-   DRM_DEBUG("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
- pipe, vbl_status, hpos, vpos,
- (long)tv_etime.tv_sec, (long)tv_etime.tv_usec,
- (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
- duration_ns/1000, i);
+   DRM_DEBUG_VBL("crtc %u : v 0x%x p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, 
%d rep]\n",
+ pipe, vbl_status, hpos, vpos,
+ (long)tv_etime.tv_sec, (long)tv_etime.tv_usec,
+ (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
+ duration_ns/1000, i);

return ret;
 }
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3dc56d3..4d3b842 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -107,6 +107,9 @@ struct dma_buf_attachment;
  * ATOMIC: used in the atomic code.
  *   This is the category used by the DRM_DEBUG_ATOMIC() macro.
  *
+ * VBL: used for verbose debug message in the vblank code
+ *   This is the category used by the DRM_DEBUG_VBL() macro.
+ *
  * Enabling verbose debug messages is done through the drm.debug parameter,
  * each category being enabled by a bit.
  *
@@ -114,7 +117,7 @@ struct dma_buf_attachment;
  * drm.debug=0x2 will enable DRIVER messages
  * drm.debug=0x3 will enable CORE and DRIVER messages
  * ...
- * drm.debug=0xf will enable all messages
+ * drm.debug=0x3f will enable all messages
  *
  * An interesting feature is that it's possible to enable verbose logging at
  * run-time by echoing the debug value in its sysfs node:
@@ -125,6 +128,7 @@ struct dma_buf_attachment;
 #define DRM_UT_KMS 0x04
 #define DRM_UT_PRIME   0x08
 #define DRM_UT_ATOMIC  0x10
+#define DRM_UT_VBL 0x20

 extern __printf(2, 3)
 void drm_ut_debug_printk(const char *function_name,
@@ -217,6 +221,11 @@ void drm_err(const char *format, ...);
if (unlikely(drm_debug & DRM_UT_ATOMIC))\
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
+#define DRM_DEBUG_VBL(fmt, args...)\
+   do {\
+   if (unlikely(drm_debug & DRM_UT_VBL))   \
+   drm_ut_debug_printk(__func__, fmt, ##args); \
+   } while (0)

 /*@}*/

-- 
2.4.9

[PATCH 1/2] drm: Don't use '\' for string literal concatenation

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

From: Ville Syrjälä 

String literals get concatenated just fine on their own,
no need to use '\'.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 7bdf247..bc2e7c6 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1272,8 +1272,8 @@ void drm_vblank_off(struct drm_device *dev, unsigned int 
pipe)
list_for_each_entry_safe(e, t, >vblank_event_list, base.link) {
if (e->pipe != pipe)
continue;
-   DRM_DEBUG("Sending premature vblank event on disable: \
- wanted %d, current %d\n",
+   DRM_DEBUG("Sending premature vblank event on disable: "
+ "wanted %d, current %d\n",
  e->event.sequence, seq);
list_del(>base.link);
drm_vblank_put(dev, pipe);
-- 
2.4.9

[PATCH] drm: atmel-hlcdc: add support for sama5d2 SoCs

[Boris Brezillon]

Hi Nicolas,

Sorry for the late reply.

On Wed, 9 Sep 2015 15:47:15 +0200
Nicolas Ferre  wrote:

> As the hardware description for this chip is the same as the sama5d4, we use
> this SoC structures for layers and DC descriptions. Thus only 2 lines are 
> added
> to the atmel_hlcdc_of_match table.
> The compatible string is already documented in the parent MFD driver's 
> binding.
> 
> Signed-off-by: Nicolas Ferre 

Just for the record, since Thierry already applied it in his tree:

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 8bc62ec407f9..498add1e5e58 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -333,6 +333,10 @@ static const struct of_device_id atmel_hlcdc_of_match[] 
> = {
>   .data = _hlcdc_dc_at91sam9x5,
>   },
>   {
> + .compatible = "atmel,sama5d2-hlcdc",
> + .data = _hlcdc_dc_sama5d4,
> + },
> + {
>   .compatible = "atmel,sama5d3-hlcdc",
>   .data = _hlcdc_dc_sama5d3,
>   },



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

RFC: DRM trivial tree

[Boris Brezillon]

Hi Thierry,

On Wed, 7 Oct 2015 17:15:56 +0200
Thierry Reding  wrote:

> Hi everyone,
> 
> Lately I've noticed that a bunch of trivial patches have been posted
> across all drivers. We've also encountered situations in the past where
> (relatively trivial) subsystem-wide changes have been made but it ended
> up being very difficult to get patches merged (often because they had
> inter-dependencies and nobody felt responsible for merging them). Often
> Dave has been the last resort for this kind of patches. A side-effect
> has been that it often takes a lot of time for such patches to get
> merged (if at all) and they usually don't end up in linux-next and
> therefore see little testing before they are applied.
> 
> To remedy that situation I'd like to propose the addition of a tree to
> keep track of these kinds of patches. Note that the target here are
> trivial patches, such as coding style fixes, fixes for build warnings
> or errors, subsystem-wide API changes, etc. It also targets mostly the
> drivers that don't have a branch that feeds into linux-next. Patches
> against drivers that already feed into linux-next should go through the
> corresponding trees. One reasonable exception for this, in my opinion,
> are subsystem-wide changes, because applying them via different trees
> usually ends up being messy.
> 
> I pushed a branch[0] with a set of patches that I've picked up from
> patchwork and which seemed to match the above criteria. I've also Cc'ed
> a bunch of people (mostly a subset of what get_maintainer.pl reported
> for the patches in the branch).
> 
> Before going any further with this I'd like to get some feedback on the
> idea. Dave, do you think this is a good idea and would you be willing to
> give this a try?
> 
> Again, I'm not volunteering to be a maintainer for all of the smaller
> drivers. The goal here is to make it easier to get cleanup patches into
> linux-next, or provide a place where subsystem-wide changes can be
> coordinated. Driver maintainers should still review the patches and in
> many cases I'd want to wait for Acked-by or Reviewed-by tags before
> taking any patches into the trivial tree. Also, while I'll try to
> monitor the list as best I can, it will inevitably happen that I'll miss
> patches. When that happens, feel free to Cc me if you think the patches
> match the above criteria.

I'm perfectly fine with that (even if the question was not directly
asked to me :-)), except that in the tree you made, I see one patch [1]
that is directly related to the atmel-hlcdc driver and not a
transversal cleanup patch (though I don't have any problem letting you
take that patch).

> 
> For a while now it's also been difficult to find maintainers for drivers
> so I'd like to see more entries being added to MAINTAINERS to help
> identify the people that need to be involved and hopefully make this
> process easier.

Just sent a patch adding my name for the atmel-hlcdc driver.

Best Regards,

Boris

[1]http://cgit.freedesktop.org/tegra/linux/commit/?h=drm/trivial/for-next=52689f943fb46f560a2277c03debfe79110d0d1f

> 
> Thierry
> 
> [0]: http://cgit.freedesktop.org/tegra/linux/log/?h=drm/trivial/for-next



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

[PATCH] MAINTAINERS: add maintainer for the atmel-hlcdc DRM driver

[Boris Brezillon]

Add myself as the maintainer of the atmel-hlcdc DRM driver.

Signed-off-by: Boris Brezillon 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 797236b..11173b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3591,6 +3591,13 @@ F:   drivers/gpu/drm/i915/
 F: include/drm/i915*
 F: include/uapi/drm/i915*

+DRM DRIVERS FOR ATMEL_AT91
+M: Boris Brezillon 
+L: dri-devel at lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/atmel-hlcdc/
+F: Documentation/devicetree/bindings/drm/atmel/
+
 DRM DRIVERS FOR EXYNOS
 M: Inki Dae 
 M: Joonyoung Shim 
-- 
2.1.4

KMS, radeon hdmi audio troubles

[Sergei Sinyak]

Hello!

Want to provide more debug, but need help.

All investigations of problem provided in comment on kernel bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=85241#c3

After that report I had conversation on irc.freenode.net#radeon.

I asked about correct initialization speakers on radeon hdmi audio card
while kms. The question is about initialization without starting Xorg
server. From my point of view KMS should provide correct audio catd to
produce music with starting any DM based on Xorg. But result is not
positive. Currently I am using weston. And have to start and kill Xorg
server before using TV speakers. TV connectd via hdmi.

Should create yet one bug report to be garbaged on kernel.bugzilla? Should
I wait till kms will be improved? Should I toss out my laptop? Are there
any chances to fix it myself?

I'd like the last one option, but have experience problems. Can't even
provide helpful debug info for Alex Deucher.

Thanks for attention,
Sergei Sinyak
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151009/958157f1/attachment.html>

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #22 from Barto  ---
Hello Ilia Mirkin,

(In reply to Ilia Mirkin from comment #21)
> When you say "compiled with", do you mean "compiled by" or "linked to"? If
> you're using clang, try using gcc. People come into #nouveau every so often
> with totally random crashes in various packages, apparently related to using
> clang.
> 
> r600g only uses llvm directly for opencl and a few extremely rare things
> like GL_SELECT.

I don't use clang, I use gcc 5.2.0, mesa 11.0.2 is compiled with gcc, and
linked to libLLVM libs,

I use the official archlinux mesa package, here you can see exactly how the
mesa archlinux package is built :

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa

they use GCC, I tried also to compile myself mesa ( 11.0.2 and the git version
of mesa ) and I get the same result like the official archlinux mesa package : 

- Ok when mesa 11.0.2 is linked to llvm libs 3.6.2, no bugs in openGL programs

- bug when mesa 11.0.2 is linked to llvm libs 3.7.0 ( crash in flightgear 3.4,
and tunnel test program from mesa-demos, and it's impossible to use the
software mode "LIBGL_ALWAYS_SOFTWARE=1" )

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

[RFC 2/2] gallium: add tegra support

[Christian Gmeiner]

This commit adds tegra support, which uses the renderonly driver
library.

Signed-off-by: Christian Gmeiner 
---
 configure.ac   | 19 +++-
 src/gallium/Makefile.am|  6 +++
 .../auxiliary/target-helpers/inline_drm_helper.h   | 29 
 src/gallium/drivers/tegra/Automake.inc | 10 +
 src/gallium/drivers/tegra/Makefile.am  |  9 
 src/gallium/targets/dri/Makefile.am|  2 +
 src/gallium/winsys/tegra/drm/Android.mk| 34 +++
 src/gallium/winsys/tegra/drm/Makefile.am   | 33 ++
 src/gallium/winsys/tegra/drm/Makefile.sources  |  3 ++
 src/gallium/winsys/tegra/drm/tegra_drm_public.h| 31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c| 51 ++
 11 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Android.mk
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

diff --git a/configure.ac b/configure.ac
index ea485b1..9fb8244 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,6 +75,7 @@ LIBDRM_INTEL_REQUIRED=2.4.61
 LIBDRM_NVVIEUX_REQUIRED=2.4.33
 LIBDRM_NOUVEAU_REQUIRED=2.4.62
 LIBDRM_FREEDRENO_REQUIRED=2.4.65
+LIBDRM_TEGRA_REQUIRED=2.4.58
 DRI2PROTO_REQUIRED=2.6
 DRI3PROTO_REQUIRED=1.0
 PRESENTPROTO_REQUIRED=1.0
@@ -864,7 +865,7 @@ GALLIUM_DRIVERS_DEFAULT="r300,r600,svga,swrast"
 AC_ARG_WITH([gallium-drivers],
 [AS_HELP_STRING([--with-gallium-drivers@<:@=DIRS...@:>@],
 [comma delimited Gallium drivers list, e.g.
-"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,vc4"
+"i915,ilo,nouveau,r300,r600,radeonsi,freedreno,svga,swrast,tegra,vc4"
 @<:@default=r300,r600,svga,swrast@:>@])],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
@@ -2166,6 +2167,12 @@ if test -n "$with_gallium_drivers"; then
 HAVE_GALLIUM_LLVMPIPE=yes
 fi
 ;;
+xtegra)
+HAVE_GALLIUM_TEGRA=yes
+PKG_CHECK_MODULES([TEGRA], [libdrm_tegra >= 
$LIBDRM_TEGRA_REQUIRED])
+gallium_require_drm "tegra"
+gallium_require_drm_loader
+;;
 xvc4)
 HAVE_GALLIUM_VC4=yes
 gallium_require_drm "vc4"
@@ -2181,6 +2188,13 @@ if test -n "$with_gallium_drivers"; then
 done
 fi

+dnl We need to validate some needed dependencies for renderonly drivers.
+
+if test "x$HAVE_GALLIUM_NOUVEAU" != xyes -a "x$HAVE_GALLIUM_TEGRA" == xyes  ; 
then
+AC_ERROR([Building with tegra requires that nouveau])
+fi
+
+
 dnl Set LLVM_LIBS - This is done after the driver configuration so
 dnl that drivers can add additional components to LLVM_COMPONENTS.
 dnl Previously, gallium drivers were updating LLVM_LIBS directly
@@ -2245,6 +2259,7 @@ AM_CONDITIONAL(HAVE_GALLIUM_FREEDRENO, test 
"x$HAVE_GALLIUM_FREEDRENO" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_SOFTPIPE, test "x$HAVE_GALLIUM_SOFTPIPE" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_LLVMPIPE, test "x$HAVE_GALLIUM_LLVMPIPE" = xyes)
 AM_CONDITIONAL(HAVE_GALLIUM_VC4, test "x$HAVE_GALLIUM_VC4" = xyes)
+AM_CONDITIONAL(HAVE_GALLIUM_TEGRA, test "x$HAVE_GALLIUM_TEGRA" = xyes)

 AM_CONDITIONAL(HAVE_GALLIUM_STATIC_TARGETS, test 
"x$enable_shared_pipe_drivers" = xno)

@@ -2364,6 +2379,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/drivers/renderonly/Makefile
src/gallium/drivers/softpipe/Makefile
src/gallium/drivers/svga/Makefile
+   src/gallium/drivers/tegra/Makefile
src/gallium/drivers/trace/Makefile
src/gallium/drivers/vc4/Makefile
src/gallium/state_trackers/clover/Makefile
@@ -2406,6 +2422,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/winsys/sw/wrapper/Makefile
src/gallium/winsys/sw/xlib/Makefile
src/gallium/winsys/vc4/drm/Makefile
+   src/gallium/winsys/tegra/drm/Makefile
src/gbm/Makefile
src/gbm/main/gbm.pc
src/glsl/Makefile
diff --git a/src/gallium/Makefile.am b/src/gallium/Makefile.am
index a7c3606..7278300 100644
--- a/src/gallium/Makefile.am
+++ b/src/gallium/Makefile.am
@@ -82,6 +82,12 @@ if HAVE_GALLIUM_VC4
 SUBDIRS += drivers/vc4 winsys/vc4/drm
 endif

+## tegra
+if HAVE_GALLIUM_TEGRA
+SUBDIRS += drivers/tegra winsys/tegra/drm
+SUBDIRS += drivers/renderonly
+endif
+
 ## the sw winsys'
 SUBDIRS += winsys/sw/null

diff --git a/src/gallium/auxiliary/target-helpers/inline_drm_helper.h 
b/src/gallium/auxiliary/target-helpers/inline_drm_helper.h
index 

[RFC 1/2] gallium: add renderonly driver

[Christian Gmeiner]

This commit adds a generic renderonly driver library, which fullfille
the requirements for tegra and etnaviv. As a result it is possible to
run unmodified egl software directly (without any compositor) on
supported devices.

In every use case we import a dumb buffer from scanout gpu into
the renderonly gpu.

If the scanout hardware does support the used tiling format from the
renderonly gpu, a driver can define a function which is used to 'setup'
the needed tiling on that imported buffer. This functions gets called
during rendertarget resource creation.

If the scanout hardware does not support the used tiling format we need
to create an extra rendertarget resource for the renderonly gpu.
During XXX we blit the renderonly rendertarget onto the imported dumb
buffer.

We assume that the renderonly driver provides a blit function that is
capable of resolving the tilied into untiled one.

Signed-off-by: Christian Gmeiner 
---
 configure.ac   |   1 +
 src/gallium/drivers/renderonly/Makefile.am |  11 +
 src/gallium/drivers/renderonly/Makefile.sources|   4 +
 .../drivers/renderonly/renderonly_context.c| 721 +
 .../drivers/renderonly/renderonly_context.h|  80 +++
 .../drivers/renderonly/renderonly_resource.c   | 296 +
 .../drivers/renderonly/renderonly_resource.h   | 101 +++
 src/gallium/drivers/renderonly/renderonly_screen.c | 178 +
 src/gallium/drivers/renderonly/renderonly_screen.h |  55 ++
 9 files changed, 1447 insertions(+)
 create mode 100644 src/gallium/drivers/renderonly/Makefile.am
 create mode 100644 src/gallium/drivers/renderonly/Makefile.sources
 create mode 100644 src/gallium/drivers/renderonly/renderonly_context.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_context.h
 create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.h
 create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.h

diff --git a/configure.ac b/configure.ac
index 217281f..ea485b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2361,6 +2361,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/drivers/radeon/Makefile
src/gallium/drivers/radeonsi/Makefile
src/gallium/drivers/rbug/Makefile
+   src/gallium/drivers/renderonly/Makefile
src/gallium/drivers/softpipe/Makefile
src/gallium/drivers/svga/Makefile
src/gallium/drivers/trace/Makefile
diff --git a/src/gallium/drivers/renderonly/Makefile.am 
b/src/gallium/drivers/renderonly/Makefile.am
new file mode 100644
index 000..ff9041b
--- /dev/null
+++ b/src/gallium/drivers/renderonly/Makefile.am
@@ -0,0 +1,11 @@
+include Makefile.sources
+include $(top_srcdir)/src/gallium/Automake.inc
+
+AM_CPPFLAGS = \
+   $(LIBDRM_CFLAGS) \
+   $(GALLIUM_CFLAGS)
+
+noinst_LTLIBRARIES = librenderonly.la
+
+librenderonly_la_SOURCES = \
+   $(C_SOURCES)
diff --git a/src/gallium/drivers/renderonly/Makefile.sources 
b/src/gallium/drivers/renderonly/Makefile.sources
new file mode 100644
index 000..6262a70
--- /dev/null
+++ b/src/gallium/drivers/renderonly/Makefile.sources
@@ -0,0 +1,4 @@
+C_SOURCES := \
+   renderonly_context.c \
+   renderonly_resource.c \
+   renderonly_screen.c
diff --git a/src/gallium/drivers/renderonly/renderonly_context.c 
b/src/gallium/drivers/renderonly/renderonly_context.c
new file mode 100644
index 000..d5e410e
--- /dev/null
+++ b/src/gallium/drivers/renderonly/renderonly_context.c
@@ -0,0 +1,721 @@
+/*
+ * Copyright © 2014 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include 
+
+#include "util/u_debug.h"
+#include "util/u_inlines.h"
+
+#include "renderonly_context.h"

[RFC 0/2] Add renderonly gpu support

[Christian Gmeiner]

This patch set introduces a more generic renderonly driver library based on
"[RFC] tegra: Initial support" [0] from Thierry Reding.

I am re-using almost all of the existing code and extended it with a
struct renderonly_ops, which defines the wanted behavior for the
target hardware.

There are two different usage patterns, which are supported.
1) Set a required tiling on the scanout buffer (tegra)
2) Use an intermediate buffer and blit to dumb buffer (imx)

The setup of struct renderonly_ops happens in winsys. So it is possible
to support different configurations for different versions of an IP core,
which are using the same KMS driver.

I really hope to get some feedback as the bare metal EGL use case is important
as not everyone runs a compositor, which understands rendernodes.

This patch set was successfully tested on tegra and imx-drm (etnaviv based)
and runs kmscube.

The patch set is available directly via git:
https://github.com/austriancoder/mesa.git branch renderonly-rfc-1

[0] http://lists.freedesktop.org/archives/mesa-dev/2014-November/071521.html

Christian Gmeiner (2):
  gallium: add renderonly driver
  gallium: add tegra support

 configure.ac   |  20 +-
 src/gallium/Makefile.am|   6 +
 .../auxiliary/target-helpers/inline_drm_helper.h   |  29 +
 src/gallium/drivers/renderonly/Makefile.am |  11 +
 src/gallium/drivers/renderonly/Makefile.sources|   4 +
 .../drivers/renderonly/renderonly_context.c| 721 +
 .../drivers/renderonly/renderonly_context.h|  80 +++
 .../drivers/renderonly/renderonly_resource.c   | 296 +
 .../drivers/renderonly/renderonly_resource.h   | 101 +++
 src/gallium/drivers/renderonly/renderonly_screen.c | 178 +
 src/gallium/drivers/renderonly/renderonly_screen.h |  55 ++
 src/gallium/drivers/tegra/Automake.inc |  10 +
 src/gallium/drivers/tegra/Makefile.am  |   9 +
 src/gallium/targets/dri/Makefile.am|   2 +
 src/gallium/winsys/tegra/drm/Android.mk|  34 +
 src/gallium/winsys/tegra/drm/Makefile.am   |  33 +
 src/gallium/winsys/tegra/drm/Makefile.sources  |   3 +
 src/gallium/winsys/tegra/drm/tegra_drm_public.h|  31 +
 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c|  51 ++
 19 files changed, 1673 insertions(+), 1 deletion(-)
 create mode 100644 src/gallium/drivers/renderonly/Makefile.am
 create mode 100644 src/gallium/drivers/renderonly/Makefile.sources
 create mode 100644 src/gallium/drivers/renderonly/renderonly_context.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_context.h
 create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_resource.h
 create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.c
 create mode 100644 src/gallium/drivers/renderonly/renderonly_screen.h
 create mode 100644 src/gallium/drivers/tegra/Automake.inc
 create mode 100644 src/gallium/drivers/tegra/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Android.mk
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.am
 create mode 100644 src/gallium/winsys/tegra/drm/Makefile.sources
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_public.h
 create mode 100644 src/gallium/winsys/tegra/drm/tegra_drm_winsys.c

-- 
2.4.3

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #21 from Ilia Mirkin  ---
(In reply to Barto from comment #19)
> Created attachment 118783 [details]
> strace of "tunnel" ( from mesa-demos )
> 
> tunnel ( from mesa-demos ) always crashes at start ( "illegal instruction"
> error ) when I use mesa 11.0.2 compiled with LLVM 3.7,
> 
> here a strace file

When you say "compiled with", do you mean "compiled by" or "linked to"? If
you're using clang, try using gcc. People come into #nouveau every so often
with totally random crashes in various packages, apparently related to using
clang.

r600g only uses llvm directly for opencl and a few extremely rare things like
GL_SELECT.

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

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #20 from Barto  ---
Created attachment 118786
  --> https://bugs.freedesktop.org/attachment.cgi?id=118786=edit
backtrace of tunnel

the gdb backtrace of tunnel ( from mesa-demos ) with mesa 11.0.2/LLVM 3.7

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

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #19 from Barto  ---
Created attachment 118783
  --> https://bugs.freedesktop.org/attachment.cgi?id=118783=edit
strace of "tunnel" ( from mesa-demos )

tunnel ( from mesa-demos ) always crashes at start ( "illegal instruction"
error ) when I use mesa 11.0.2 compiled with LLVM 3.7,

here a strace file

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

[PATCH 09/20] i915: switch from acpi_os_ioremap to memremap

[Dan Williams]

i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
map it with memremap rather than the implied cache setting of
acpi_os_ioremap().

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h   |   12 +++--
 drivers/gpu/drm/i915/intel_bios.c |7 +--
 drivers/gpu/drm/i915/intel_opregion.c |   73 -
 drivers/gpu/drm/i915/intel_panel.c|2 -
 5 files changed, 47 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e3ec9049081f..15989cc16e92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1849,7 +1849,7 @@ static int i915_opregion(struct seq_file *m, void *unused)
goto out;

if (opregion->header) {
-   memcpy_fromio(data, opregion->header, OPREGION_SIZE);
+   memcpy(data, opregion->header, OPREGION_SIZE);
seq_write(m, data, OPREGION_SIZE);
}

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e1db8de52851..d8684634a31d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -444,14 +444,14 @@ struct opregion_swsci;
 struct opregion_asle;

 struct intel_opregion {
-   struct opregion_header __iomem *header;
-   struct opregion_acpi __iomem *acpi;
-   struct opregion_swsci __iomem *swsci;
+   struct opregion_header *header;
+   struct opregion_acpi *acpi;
+   struct opregion_swsci *swsci;
u32 swsci_gbda_sub_functions;
u32 swsci_sbcb_sub_functions;
-   struct opregion_asle __iomem *asle;
-   void __iomem *vbt;
-   u32 __iomem *lid_state;
+   struct opregion_asle *asle;
+   void *vbt;
+   u32 *lid_state;
struct work_struct asle_work;
 };
 #define OPREGION_SIZE(8*1024)
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index c19e669ffe50..1ee2f11d355d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1238,11 +1238,10 @@ static const struct bdb_header *validate_vbt(const void 
__iomem *_base,
 {
/*
 * This is the one place where we explicitly discard the address space
-* (__iomem) of the BIOS/VBT. (And this will cause a sparse complaint.)
-* From now on everything is based on 'base', and treated as regular
-* memory.
+* (__iomem) of the BIOS/VBT. From now on everything is based on
+* 'base', and treated as regular memory.
 */
-   const void *base = (const void *) _base;
+   const void *base = (const void __force *) _base;
size_t offset = _vbt - _base;
const struct vbt_header *vbt = base + offset;
const struct bdb_header *bdb;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index cb1c65739425..4f65cdb38e1b 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -239,7 +239,7 @@ struct opregion_asle {
 static int swsci(struct drm_device *dev, u32 function, u32 parm, u32 *parm_out)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct opregion_swsci __iomem *swsci = dev_priv->opregion.swsci;
+   struct opregion_swsci *swsci = dev_priv->opregion.swsci;
u32 main_function, sub_function, scic;
u16 pci_swsci;
u32 dslp;
@@ -264,7 +264,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
}

/* Driver sleep timeout in ms. */
-   dslp = ioread32(>dslp);
+   dslp = swsci->dslp;
if (!dslp) {
/* The spec says 2ms should be the default, but it's too small
 * for some machines. */
@@ -277,7 +277,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
}

/* The spec tells us to do this, but we are the only user... */
-   scic = ioread32(>scic);
+   scic = swsci->scic;
if (scic & SWSCI_SCIC_INDICATOR) {
DRM_DEBUG_DRIVER("SWSCI request already in progress\n");
return -EBUSY;
@@ -285,8 +285,8 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)

scic = function | SWSCI_SCIC_INDICATOR;

-   iowrite32(parm, >parm);
-   iowrite32(scic, >scic);
+   swsci->parm = parm;
+   swsci->scic = scic;

/* Ensure SCI event is selected and event trigger is cleared. */
pci_read_config_word(dev->pdev, PCI_SWSCI, _swsci);
@@ -301,7 +301,7 @@ static int swsci(struct drm_device *dev, u32 function, u32 
parm, u32 *parm_out)
pci_write_config_word(dev->pdev, PCI_SWSCI, pci_swsci);

/* Poll for the 

[PATCH 08/20] gma500: switch from acpi_os_ioremap to memremap

[Dan Williams]

gma500 expects the OpRegion to be cached (i.e. not __iomem), so
explicitly map it with memremap rather than the implied cache setting of
acpi_os_ioremap().

Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/gma500/opregion.c |8 
 drivers/gpu/drm/gma500/psb_drv.h  |2 +-
 drivers/gpu/drm/gma500/psb_lid.c  |8 
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/opregion.c 
b/drivers/gpu/drm/gma500/opregion.c
index ab696ca7eeec..7672ac4d4217 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/gpu/drm/gma500/opregion.c
@@ -297,7 +297,7 @@ void psb_intel_opregion_fini(struct drm_device *dev)
cancel_work_sync(>asle_work);

/* just clear all opregion memory pointers now */
-   iounmap(opregion->header);
+   memunmap(opregion->header);
opregion->header = NULL;
opregion->acpi = NULL;
opregion->swsci = NULL;
@@ -310,8 +310,8 @@ int psb_intel_opregion_setup(struct drm_device *dev)
struct drm_psb_private *dev_priv = dev->dev_private;
struct psb_intel_opregion *opregion = _priv->opregion;
u32 opregion_phy, mboxes;
-   void __iomem *base;
int err = 0;
+   void *base;

pci_read_config_dword(dev->pdev, PCI_ASLS, _phy);
if (opregion_phy == 0) {
@@ -322,7 +322,7 @@ int psb_intel_opregion_setup(struct drm_device *dev)
INIT_WORK(>asle_work, psb_intel_opregion_asle_work);

DRM_DEBUG("OpRegion detected at 0x%8x\n", opregion_phy);
-   base = acpi_os_ioremap(opregion_phy, 8*1024);
+   base = memremap(opregion_phy, 8*1024, MEMREMAP_WB);
if (!base)
return -ENOMEM;

@@ -351,7 +351,7 @@ int psb_intel_opregion_setup(struct drm_device *dev)
return 0;

 err_out:
-   iounmap(base);
+   memunmap(base);
return err;
 }

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index e38057b91865..189f57135d47 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -253,7 +253,7 @@ struct psb_intel_opregion {
struct opregion_swsci *swsci;
struct opregion_asle *asle;
void *vbt;
-   u32 __iomem *lid_state;
+   u32 *lid_state;
struct work_struct asle_work;
 };

diff --git a/drivers/gpu/drm/gma500/psb_lid.c b/drivers/gpu/drm/gma500/psb_lid.c
index 1d2ebb5e530f..6b1b9d0741df 100644
--- a/drivers/gpu/drm/gma500/psb_lid.c
+++ b/drivers/gpu/drm/gma500/psb_lid.c
@@ -28,14 +28,14 @@ static void psb_lid_timer_func(unsigned long data)
struct drm_psb_private * dev_priv = (struct drm_psb_private *)data;
struct drm_device *dev = (struct drm_device *)dev_priv->dev;
struct timer_list *lid_timer = _priv->lid_timer;
+   u32 *lid_state = dev_priv->opregion.lid_state;
unsigned long irq_flags;
-   u32 __iomem *lid_state = dev_priv->opregion.lid_state;
u32 pp_status;

-   if (readl(lid_state) == dev_priv->lid_last_state)
+   if (*lid_state == dev_priv->lid_last_state)
goto lid_timer_schedule;

-   if ((readl(lid_state)) & 0x01) {
+   if ((*lid_state) & 0x01) {
/*lid state is open*/
REG_WRITE(PP_CONTROL, REG_READ(PP_CONTROL) | POWER_TARGET_ON);
do {
@@ -58,7 +58,7 @@ static void psb_lid_timer_func(unsigned long data)
pp_status = REG_READ(PP_STATUS);
} while ((pp_status & PP_ON) == 0);
}
-   dev_priv->lid_last_state =  readl(lid_state);
+   dev_priv->lid_last_state =  *lid_state;

 lid_timer_schedule:
spin_lock_irqsave(_priv->lid_lock, irq_flags);

[PATCH 00/20] tree-wide convert to memremap()

[Dan Williams]

The memremap() api [1] was merged in 4.3 [2] with an initial
implementation for x86 and a conversion of the pmem driver. Complete the
conversion for the rest of the kernel.

Feel free to either ack or directly apply a conversion-patch as I will
defer the final removal patches until all the conversions have landed.

[1]: https://lwn.net/Articles/653585/
[2]: commit 92281dee825f arch: introduce memremap()

---

Dan Williams (20):
  x86: introduce arch_memremap()
  arm: introduce arch_memremap()
  ia64: introduce arch_memremap()
  sh: introduce arch_memremap()
  m68k: introduce arch_memremap()
  arm: switch from ioremap_cache to memremap
  x86: switch from ioremap_cache to memremap
  gma500: switch from acpi_os_ioremap to memremap
  i915: switch from acpi_os_ioremap to memremap
  acpi: switch from ioremap_cache to memremap
  sound, skylake: switch from ioremap_cache to memremap
  memconsole: fix __iomem mishandling, switch to memremap
  intel-iommu: switch from ioremap_cache to memremap
  pxa2xx-flash: switch from ioremap_cache to memremap
  sfi: switch from ioremap_cache to memremap
  fbdev: switch from ioremap_wt to memremap
  arch: kill ioremap_cached()
  arch: kill ioremap_fullcache()
  arch: remove ioremap_cache, replace with arch_memremap
  arch: remove ioremap_wt, optionally replace with arch_memremap


 Documentation/x86/pat.txt |6 +--
 arch/arc/include/asm/io.h |1 
 arch/arm/Kconfig  |1 
 arch/arm/include/asm/io.h |7 ---
 arch/arm/include/asm/xen/page.h   |4 +-
 arch/arm/mm/ioremap.c |   12 -
 arch/arm/mm/mmu.c |2 -
 arch/arm/mm/nommu.c   |   11 +++--
 arch/arm64/Kconfig|1 
 arch/arm64/include/asm/acpi.h |   11 -
 arch/arm64/include/asm/dmi.h  |8 ++--
 arch/arm64/include/asm/io.h   |2 -
 arch/arm64/kernel/efi.c   |9 ++--
 arch/arm64/kernel/smp_spin_table.c|   19 -
 arch/arm64/mm/ioremap.c   |   20 +++--
 arch/avr32/include/asm/io.h   |1 
 arch/frv/include/asm/io.h |   12 -
 arch/ia64/Kconfig |1 
 arch/ia64/include/asm/io.h|6 ---
 arch/ia64/mm/ioremap.c|   10 +
 arch/m32r/include/asm/io.h|1 
 arch/m68k/Kconfig |1 
 arch/m68k/include/asm/io_mm.h |   13 --
 arch/m68k/include/asm/io_no.h |   11 -
 arch/m68k/include/asm/raw_io.h|1 
 arch/m68k/mm/kmap.c   |   17 +++-
 arch/m68k/mm/sun3kmap.c   |7 +++
 arch/metag/include/asm/io.h   |6 ---
 arch/microblaze/include/asm/io.h  |2 -
 arch/mn10300/include/asm/io.h |1 
 arch/nios2/include/asm/io.h   |1 
 arch/s390/include/asm/io.h|1 
 arch/sh/Kconfig   |1 
 arch/sh/include/asm/io.h  |7 ---
 arch/sh/mm/ioremap.c  |9 
 arch/sparc/include/asm/io_32.h|1 
 arch/sparc/include/asm/io_64.h|1 
 arch/tile/include/asm/io.h|2 -
 arch/unicore32/include/asm/io.h   |4 --
 arch/unicore32/mm/ioremap.c   |8 
 arch/x86/Kconfig  |1 
 arch/x86/include/asm/efi.h|3 +
 arch/x86/include/asm/io.h |4 --
 arch/x86/kernel/crash_dump_64.c   |6 +--
 arch/x86/kernel/kdebugfs.c|8 ++--
 arch/x86/kernel/ksysfs.c  |   28 ++---
 arch/x86/mm/ioremap.c |   43 ---
 arch/xtensa/include/asm/io.h  |   12 -
 drivers/acpi/apei/einj.c  |9 ++--
 drivers/acpi/apei/erst.c  |6 +--
 drivers/acpi/nvs.c|6 +--
 drivers/acpi/osl.c|   70 +---
 drivers/firmware/google/memconsole.c  |7 ++-
 drivers/gpu/drm/gma500/opregion.c |8 ++--
 drivers/gpu/drm/gma500/psb_drv.h  |2 -
 drivers/gpu/drm/gma500/psb_lid.c  |8 ++--
 drivers/gpu/drm/i915/i915_debugfs.c   |2 -
 drivers/gpu/drm/i915/i915_drv.h   |   12 +++--
 drivers/gpu/drm/i915/intel_bios.c |7 +--
 drivers/gpu/drm/i915/intel_opregion.c |   73 -
 drivers/gpu/drm/i915/intel_panel.c|2 -
 drivers/iommu/intel-iommu.c   |   20 +
 drivers/iommu/intel_irq_remapping.c   |8 ++--
 drivers/mtd/maps/pxa2xx-flash.c   |6 +--
 drivers/nvdimm/Kconfig|2 -
 drivers/sfi/sfi_core.c|4 +-
 drivers/video/fbdev/Kconfig   |2 -
 drivers/video/fbdev/amifb.c   |5 +-
 drivers/video/fbdev/atafb.c   |5 +-
 drivers/video/fbdev/hpfb.c|6 +--
 include/acpi/acpi_io.h  

[Bug 105711] amdgpu: no monitor signal and kernel panic

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

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

--- Comment #2 from Lars W.  ---
Created attachment 189821
  --> https://bugzilla.kernel.org/attachment.cgi?id=189821=edit
kernel-4.3-rc4 config (gzip compressed)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 00/11] tda998x updates

[Jean-Francois Moine]

On Fri, 9 Oct 2015 14:25:26 +0100
Russell King - ARM Linux  wrote:

> > Here's my currently queued TDA998x development work for 4.4.  
> 
> As there have been no comments against this series, I'll send David a
> pull request later today.

It works fine for me. Thanks.

Tested-by: Jean-Francois Moine 

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 105711] amdgpu: no monitor signal and kernel panic

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

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

--- Comment #1 from Lars W.  ---
Created attachment 189811
  --> https://bugzilla.kernel.org/attachment.cgi?id=189811=edit
lspci -nnv

83:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Tonga PRO [Radeon R9 285/380] [1002:6939] (prog-if 00 [VGA
controller])
Subsystem: PC Partner Limited / Sapphire Technology Tonga PRO [Radeon
R9 285/380] [174b:e306]
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at b0e0 (64-bit, prefetchable) [size=2M]
I/O ports at 6000 [size=256]
Memory at b0b4 (32-bit, non-prefetchable) [size=256K]
[virtual] Expansion ROM at b0b2 [disabled] [size=128K]
Capabilities: [48] Vendor Specific Information: Len=08 
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel modules: amdgpu

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 105711] New: amdgpu: no monitor signal and kernel panic

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

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

Bug ID: 105711
   Summary: amdgpu: no monitor signal and kernel panic
   Product: Drivers
   Version: 2.5
Kernel Version: 4.3-rc4
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: polynomial-c at gmx.de
Regression: No

Created attachment 189801
  --> https://bugzilla.kernel.org/attachment.cgi?id=189801=edit
kernel dmesg output

As soon as the driver gets loaded the monitor looses the signal and doesn't get
it back. After a while the kernel panics so even network connections get lost:


[  751.713493] Task dump for CPU 7:
[  751.713496] modprobeR  running task0  2994   2968 0x000a
[  751.713506]  88063a72ae00 818809f9 88063a72ae00
0007
[  751.713513]  88063a72ae00  8800a6658000

[  751.713519]   8800a6658000 880634b2
818814b2
[  751.713525] Call Trace:
[  751.713532]  [] ? 0x818809f9
[  751.713536]  [] ? 0x818814b2
[  751.713539]  [] ? 0x81885180
[  751.713543]  [] ? 0xa00232ca
[  751.713547]  [] ? 0x814f6c8c
[  751.713550]  [] ? 0xa005933c
[  751.713553]  [] ? 0xa005c69e
[  751.713557]  [] ? 0xa0018cba
[  751.713560]  [] ? 0xa001a5c1
[  751.713563]  [] ? 0x815c7893
[  751.713566]  [] ? 0x815c9589
[  751.713569]  [] ? 0x81526b58
[  751.713572]  [] ? 0x81526abf
[  751.713575]  [] ? 0x81527193
[  751.713578]  [] ? 0x815e4334
[  751.713581]  [] ? 0x815e458d
[  751.713584]  [] ? 0x815e4500
[  751.713586]  [] ? 0x815e2585
[  751.713589]  [] ? 0x815e3af1
[  751.713592]  [] ? 0xa0088000
[  751.713595]  [] ? 0x815e4b42
[  751.713598]  [] ? 0xa0088000
[  751.713601]  [] ? 0x8100036b
[  751.713604]  [] ? 0x8113065c
[  751.713607]  [] ? 0x810fb8d4
[  751.713610]  [] ? 0x810f94d0
[  751.713615]  [] ? 0x810fbe42
[  751.713618]  [] ? 0x81884697
[  751.713626] rcu_preempt kthread starved for 24577 jiffies! g2247 c2246 f0x0
s3 ->state=0x0


Same problem happens with vanilla kernel-4.2.3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Suspend/Resume problems with radeon driver

[Joerg Roedel]

Hi Alex, Christian,

I recently tested v4.3-rc4 on one of my AMD IOMMU boxes with a radeon
GPU in it:

mars:~ # lspci -k -s 08:00.0
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Juniper XT [Radeon HD 5770]
Subsystem: PC Partner Limited / Sapphire Technology Device 1482
Kernel driver in use: radeon
Kernel modules: radeon

When the box is suspended-to-disk, I get a lot of IO_PAGE_FAULTs from
the IOMMU on dma-addresses that either the IOMMU driver would never
return (<4k and >4G) or that were not returned by the driver (I did some
tracing to verify that). This does _not_ happen on suspend-to-mem.

Any ideas what might causing this? Let me know if you need more
information.


Joerg

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #18 from Barto  ---
(In reply to Alex Deucher from comment #17)
> The r600 driver does not use llvm.

here is what I see with ldd :

$ ldd /usr/lib/xorg/modules/dri/r600_dri.so
linux-vdso.so.1 (0x7ffe8a9f7000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x7efe0af45000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x7efe0ad41000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x7efe0ab17000)
libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2
(0x7efe0a90f000)
libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0x7efe0a703000)
libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0x7efe0a4fb000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0x7efe0a2eb000)
libelf.so.1 => /usr/lib/libelf.so.1 (0x7efe0a0d5000)
libLLVM.so.3.7 => /usr/lib/libLLVM.so.3.7 (0x7efe079c3000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7efe0764)
libm.so.6 => /usr/lib/libm.so.6 (0x7efe07342000)
libc.so.6 => /usr/lib/libc.so.6 (0x7efe06f9e000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7efe06d87000)
/usr/lib64/ld-linux-x86-64.so.2 (0x5604503b7000)
libffi.so.6 => /usr/lib/../lib/libffi.so.6 (0x7efe06b7e000)
libedit.so.0 => /usr/lib/../lib/libedit.so.0 (0x7efe06941000)
libncursesw.so.6 => /usr/lib/../lib/libncursesw.so.6
(0x7efe066d4000)
libz.so.1 => /usr/lib/../lib/libz.so.1 (0x7efe064be000)


libLLVM.so.3.7 seems used by r600_dri.so file, 

$ pacman -Qo /usr/lib/xorg/modules/dri/r600_dri.so
/usr/lib/xorg/modules/dri/r600_dri.so is owned by mesa 11.0.2-1


in glxinfo I can see this :

OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits)

so what driver is really used by mesa 11.0.2 with my radeon HD4650 Pcie ?

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

[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

[Russell King - ARM Linux]

On Fri, Oct 09, 2015 at 01:02:11PM -0300, Fabio Estevam wrote:
> On Fri, Oct 9, 2015 at 1:00 PM, Russell King - ARM Linux
>  wrote:
> 
> >> Thanks, Russell!
> >>
> >> Got audio to play on my HDMI TV :-)
> >>
> >> For the entire series:
> >>
> >> Tested-by: Fabio Estevam 
> >
> > Just to confirm - that's for _all_ of these 8 patches, including the
> > changes to the ACR code in the last four patches, and you're happy that
> > I send all of these:
> >
> > drm: bridge/dw_hdmi-ahb-audio: add audio driver
> > drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
> > drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
> > drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
> > drm: bridge/dw_hdmi: avoid being recursive in N calculation
> > drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
> > drm: bridge/dw_hdmi: remove ratio support from ACR code
> > drm: bridge/dw_hdmi: replace CTS calculation for the ACR
> 
> That's correct. Thanks, Russell

Thanks.  I'll drop that set into linux-next tonight, along with the TDA998x
and Armada DRM patches that haven't seen an airing there yet - before asking
David to pull them next week (the timescale has slipped...)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

[Russell King - ARM Linux]

On Tue, Oct 06, 2015 at 05:25:16PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:54 PM, Russell King - ARM Linux
>  wrote:
> 
> > Make sure you have the ALSA config file, as alsalib won't get on
> > with dw-hdmi only accepting 24-bit audio without this.  A copy is
> > attached.  It also tells ALSA how to deal with multi-channel audio
> > as well.
> 
> Thanks, Russell!
> 
> Got audio to play on my HDMI TV :-)
> 
> For the entire series:
> 
> Tested-by: Fabio Estevam 

Just to confirm - that's for _all_ of these 8 patches, including the
changes to the ACR code in the last four patches, and you're happy that
I send all of these:

drm: bridge/dw_hdmi-ahb-audio: add audio driver
drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
drm: bridge/dw_hdmi: avoid being recursive in N calculation
drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
drm: bridge/dw_hdmi: remove ratio support from ACR code
drm: bridge/dw_hdmi: replace CTS calculation for the ACR

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #17 from Alex Deucher  ---
The r600 driver does not use llvm.

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

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #16 from Barto  ---
(In reply to Barto from comment #15)
> and of course the problem occurs only with LLVM 3.8 libs ( and at least with
> the r600 driver ), there is no problem with LLVM 3.6.2, 
> 
> it would be great if this bug can be solved before LLVM 3.8 will hit others
> linux distros ( like ubuntu )

of course the problem occurs with LLVM 3.7 ( not only LLVM 3.8 )

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

[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2

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

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

--- Comment #15 from Barto  ---
I didn't manage to find the faulty commit in llvm 3.8, the bisecting process is
very slow and difficult ( I have a slow PC and there are a lot of svn revision
to test ),


(In reply to Roland Scheidegger from comment #13)
> Does not necessarily mean it is a bug in llvm, maybe we're initializing it
> wrong or something (there were some recent patches to fix some threading
> issues in gallivm recently). Not my area of expertise, though...

in fact I think Roland is right, the problem could be mesa 11.0.2 and not LLVM
3.8 if some LLVM functions are used in a bad way by mesa 11.0.2,

it would be nice if someone who has a good knowledge in r600 driver can make
some investigations, we have a gdb backtrace, we know that the problem occurs
when a program uses the openGL function "glRasterPos2i()", and the problem
occurs also when we use the 100% software mode ( export LIBGL_ALWAYS_SOFTWARE=1
),

and of course the problem occurs only with LLVM 3.8 libs ( and at least with
the r600 driver ), there is no problem with LLVM 3.6.2, 

it would be great if this bug can be solved before LLVM 3.8 will hit others
linux distros ( like ubuntu )

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #12 from Alex Deucher  ---
(In reply to Ernst Sjöstrand from comment #10)
> No monitor section.
> During this time i've actually bought a second 4k monitor of a different
> brand.
> Attaching the xrandr with fglrx.

Does it work properly with amdgpu?

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #11 from Ernst Sjöstrand  ---
Created attachment 118780
  --> https://bugs.freedesktop.org/attachment.cgi?id=118780=edit
xrandr fglrx

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #10 from Ernst Sjöstrand  ---
No monitor section.
During this time i've actually bought a second 4k monitor of a different brand.
Attaching the xrandr with fglrx.

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

[PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Emil Velikov  writes:

> Hi Eric,
>
> On 9 October 2015 at 22:27, Eric Anholt  wrote:
>> Signed-off-by: Eric Anholt 
>> ---
>>
>> v2: Mark it Supported, not Maintained.
>>
>>  MAINTAINERS | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7ba7ab7..e331e46 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3653,6 +3653,12 @@ S:   Maintained
>>  F: drivers/gpu/drm/sti
>>  F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
>>
>> +DRM DRIVERS FOR VC4
>> +M: Eric Anholt 
>> +T: git git://github.com/anholt/linux
> You might want to add dri-devel as mailing list, at least initially.

I believe that's already implied by the general entry for dri-devel:

./scripts/get_maintainer.pl -f drivers/gpu/drm/vc4/vc4_drv.c
Eric Anholt  (supporter:DRM DRIVERS FOR VC4)
David Airlie  (maintainer:DRM DRIVERS)
dri-devel at lists.freedesktop.org (open list:DRM DRIVERS)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151009/312d8e77/attachment.sig>

[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley

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

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

--- Comment #30 from Mathias Tillman  ---
Just updated to latest drm-next-4.4-wip and mesa and reran the valley test.
Been running for two hours now without a hang (although there have been vm
faults). Will test more over the weekend, but it's looking good so far :)

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

[PATCH v4 1/2] drm/dp: Store the drm_connector device pointer on the helper.

[Rafael Antognolli]

On Tue, Sep 29, 2015 at 06:25:44PM +0200, Daniel Vetter wrote:
> On Tue, Sep 29, 2015 at 05:27:33PM +0200, Lukas Wunner wrote:
> > Hi Daniel,
> > 
> > On Tue, Sep 29, 2015 at 05:04:03PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 29, 2015 at 02:49:20PM +0200, Lukas Wunner wrote:
> > > > On Mon, Sep 28, 2015 at 04:45:35PM -0700, Rafael Antognolli wrote:
> > > > > This is useful to determine which connector owns this AUX channel.
> > > > 
> > > > WTF? I posted a patch in August which does exactly that:
> > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/088172.html
> > > > 
> > > > Can also be pulled in from this git repo:
> > > > https://github.com/l1k/linux/commit/b78b38d53fc0fc4fa0f6acf699b0fcad56ec1fe6
> > > > 
> > > > My patch has the advantage that it updates all the drivers which use
> > > > drm_dp_aux to fill that attribute. Yours only updates i915.
> > > > 
> > > > Daniel Vetter criticized storing a drm_connector pointer in drm_dp_aux,
> > > > quote:
> > > > 
> > > > "That will also clear up the confusion with drm_dp_aux, adding a
> > > > drm_connector there feels wrong since not every dp_aux line has a
> > > > connector (e.g. for dp mst). If we can lift this relation out into 
> > > > drivers
> > > > (where this is known) that seems cleaner."
> > > > 
> > > > So now Intel itself does precisely what Daniel criticized? Confusing!
> > > > 
> > > > Source:
> > > > http://lists.freedesktop.org/archives/dri-devel/2015-August/089108.html
> > > 
> > > Critism is still valid, and thinking about this again a cleaner solution
> > > would be to just have a correct parent/child relationship in the device
> > > hirarchy. I.e. add a struct device *parent to the aux channel structure
> > > which should point to the right connector.
> > 
> > We already have that:
> > 
> > struct drm_dp_aux {
> > const char *name;
> > struct i2c_adapter ddc;
> > struct device *dev; <---
> > struct mutex hw_mutex;
> > ssize_t (*transfer)(struct drm_dp_aux *aux,
> > struct drm_dp_aux_msg *msg);
> > unsigned i2c_nack_count, i2c_defer_count;
> > };
> > 
> > What Rafael is struggling with is that you cannot unambiguously
> > get from drm_dp_aux->dev to the drm_connector. (The drm_device
> > may have multiple drm_connectors with type
> > DRM_MODE_CONNECTOR_DisplayPort.)
> 
> What I meant to say is that we don't need that, if instead of filling in
> the overall dev in dp_aux->dev we fill in the connector sysfs device
> thing. The we have proper nesting, like with i2c buses. And then there's
> no need for a connector property in sysfs to show that link (which should
> be done with a proper sysfs link anyway).

OK, I sent a new version, which does not add a new *connector pointer,
and uses the dev pointer on the struct to store the drm_connector
device, instead of the drm_device device. Is that what you meant? In
any case, as I mention on the patch, it is already how some drivers do,
while others store the drm_device.

This leaves the aux device, for instance in my case, at:

/sys/class/drm/card0/card0-eDP-1/drm_dp_aux0

If this is what you wanted, I can send other patches to the proper
mailing lists, trying to update other drivers.

--
Rafael

> > 
> > > 
> > > Thanks for pointing out that I missed properly delayering this.
> > > -Daniel
> > > 
> > > > 
> > > > 
> > > > Best regards,
> > > > 
> > > > Lukas
> > > > 
> > > > 
> > > > > 
> > > > > Signed-off-by: Rafael Antognolli 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 1 +
> > > > >  include/drm/drm_dp_helper.h | 1 +
> > > > >  2 files changed, 2 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 77f7330..f90439d 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -1079,6 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, 
> > > > > struct intel_connector *connector)
> > > > >  
> > > > >   intel_dp->aux.name = name;
> > > > >   intel_dp->aux.dev = dev->dev;
> > > > > + intel_dp->aux.connector = connector->base.kdev;
> > > > >   intel_dp->aux.transfer = intel_dp_aux_transfer;
> > > > >  
> > > > >   DRM_DEBUG_KMS("registering %s bus for %s\n", name,
> > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > > > index 9ec4716..e009b5d 100644
> > > > > --- a/include/drm/drm_dp_helper.h
> > > > > +++ b/include/drm/drm_dp_helper.h
> > > > > @@ -702,6 +702,7 @@ struct drm_dp_aux {
> > > > >   const char *name;
> > > > >   struct i2c_adapter ddc;
> > > > >   struct device *dev;
> > > > > + struct device *connector;
> > > > >   struct mutex hw_mutex;
> > > > >   ssize_t (*transfer)(struct drm_dp_aux *aux,
> > > > >   struct drm_dp_aux_msg *msg);
> > > > > -- 
> > > > > 2.4.3
> > > > > 
> > > > > 

[PATCH v5 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

[Rafael Antognolli]

So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the drm_connector.

This also removes the need to add a sysfs link for the i2c device under
the connector, as it will already be there.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/intel_dp.c | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 18bcfbe..0acdf0f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1078,36 +1078,21 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct 
intel_connector *connector)
intel_dp->aux_ch_ctl_reg = intel_dp->output_reg + 0x10;

intel_dp->aux.name = name;
-   intel_dp->aux.dev = dev->dev;
+   intel_dp->aux.dev = connector->base.kdev;
intel_dp->aux.transfer = intel_dp_aux_transfer;

DRM_DEBUG_KMS("registering %s bus for %s\n", name,
  connector->base.kdev->kobj.name);

ret = drm_dp_aux_register(_dp->aux);
-   if (ret < 0) {
+   if (ret < 0)
DRM_ERROR("drm_dp_aux_register() for %s failed (%d)\n",
  name, ret);
-   return;
-   }
-
-   ret = sysfs_create_link(>base.kdev->kobj,
-   _dp->aux.ddc.dev.kobj,
-   intel_dp->aux.ddc.dev.kobj.name);
-   if (ret < 0) {
-   DRM_ERROR("sysfs_create_link() for %s failed (%d)\n", name, 
ret);
-   drm_dp_aux_unregister(_dp->aux);
-   }
 }

 static void
 intel_dp_connector_unregister(struct intel_connector *intel_connector)
 {
-   struct intel_dp *intel_dp = intel_attached_dp(_connector->base);
-
-   if (!intel_connector->mst_port)
-   sysfs_remove_link(_connector->base.kdev->kobj,
- intel_dp->aux.ddc.dev.kobj.name);
intel_connector_unregister(intel_connector);
 }

-- 
2.4.3

[PATCH v5 1/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Rafael Antognolli]

This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.

It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.

Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/Kconfig  |   8 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c | 373 +++
 drivers/gpu/drm/drm_dp_helper.c  |   7 +
 include/drm/drm_dp_aux_dev.h |  50 ++
 5 files changed, 439 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
 create mode 100644 include/drm/drm_dp_aux_dev.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..64fa0f4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -25,6 +25,14 @@ config DRM_MIPI_DSI
bool
depends on DRM

+config DRM_DP_AUX_CHARDEV
+   bool "DRM DP AUX Interface"
+   depends on DRM
+   help
+ Choose this option to enable a /dev/drm_dp_auxN node that allows to
+ read and write values to arbitrary DPCD registers on the DP aux
+ channel.
+
 config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e814517..e5bc0ca 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -28,6 +28,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
+drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o

 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o

diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
new file mode 100644
index 000..a2861e2
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -0,0 +1,373 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rafael Antognolli 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_dp_aux_dev {
+   unsigned index;
+   struct drm_dp_aux *aux;
+   struct device *dev;
+   struct kref refcount;
+   bool removed;
+   spinlock_t removed_lock;
+};
+
+#define DRM_AUX_MINORS 256
+#define AUX_MAX_OFFSET (1 << 20)
+static DEFINE_IDR(aux_idr);
+static DEFINE_SPINLOCK(aux_idr_lock);
+static struct class *drm_dp_aux_dev_class;
+static int drm_dev_major = -1;
+
+static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
+{
+   struct drm_dp_aux_dev *aux_dev = NULL;
+
+   spin_lock(_idr_lock);
+   aux_dev = idr_find(_idr, index);
+   if (!kref_get_unless_zero(_dev->refcount))
+   aux_dev = NULL;
+   spin_unlock(_idr_lock);
+
+   return aux_dev;
+}
+
+static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct drm_dp_aux *aux)
+{
+   struct drm_dp_aux_dev *aux_dev;
+   int index;
+
+
+   aux_dev = kzalloc(sizeof(*aux_dev), GFP_KERNEL);
+   if (!aux_dev)
+   return ERR_PTR(-ENOMEM);
+   aux_dev->aux = aux;
+   aux_dev->removed = false;
+   spin_lock_init(_dev->removed_lock);
+   kref_init(_dev->refcount);
+
+   idr_preload(GFP_KERNEL);
+   spin_lock(_idr_lock);
+   index = idr_alloc_cyclic(_idr, aux_dev, 0, DRM_AUX_MINORS,
+GFP_NOWAIT);
+   

[PATCH v5 0/2] Add drm_dp_aux chardev support.

[Rafael Antognolli]

This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.

v2:
 - lseek is used to select the register to read/write
 - read/write are used instead of ioctl
 - no blocking_notifier is used, just a direct callback

v3:
 - use drm_dp_aux_dev prefix for public functions
 - chardev is named drm_dp_auxN
 - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
   time
 - remove notifier list from the implementation
 - option on menuconfig is now a boolean
 - add inline stub functions to avoid breakage when this option is disabled

v4:
 - fix build system changes - actually disable this module when not selected.

v5:
 - Use kref to avoid device closing while still in use 
 - Don't use list, use an idr for storing aux_dev
 - Remove "connector" attribute
 - set aux.dev to the connector drm_connector device, instead of
   drm_device

Rafael Antognolli (2):
  drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.
  drm/dp: Set aux.dev to the drm_connector device, instead of
drm_device.

 drivers/gpu/drm/Kconfig  |   8 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c | 373 +++
 drivers/gpu/drm/drm_dp_helper.c  |   7 +
 drivers/gpu/drm/i915/intel_dp.c  |  14 +-
 include/drm/drm_dp_aux_dev.h |  50 ++
 6 files changed, 441 insertions(+), 12 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
 create mode 100644 include/drm/drm_dp_aux_dev.h

-- 
2.4.3

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #9 from Alex Deucher  ---
Please attach a copy of your vbios.

(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #8 from Alex Deucher  ---
Can you post your xorg config?  Do you have a monitor section that has sync
ranges that may be limiting what modes are added?  I can't reproduce this. 
E.g.,
Screen 0: minimum 320 x 200, current 5760 x 2160, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 connected primary 3840x2160+0+0 (normal left inverted right x
axis y axis) 621mm x 341mm
   3840x2160  60.0*+   30.0  
   2560x1600  60.0  
   2560x1440  60.0  
   1920x1080  60.0 60.0 50.0 59.9  
   1920x1080i 60.1 50.0 60.0  
   1680x1050  59.9  
   1280x1024  75.0 60.0  
   1440x900   59.9  
   1280x960   60.0  
   1152x864   75.0  
   1280x720   60.0 50.0 59.9  
   1440x576   50.0  
   1024x768   75.1 70.1 60.0  
   1440x480   60.0 59.9  
   832x62474.6  
   800x60072.2 75.0 60.3 56.2  
   720x57650.0  
   720x48060.0 59.9  
   640x48075.0 72.8 66.7 60.0 59.9  
   720x40070.1  
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 connected 1920x1200+3840+0 (normal left inverted right x axis y axis)
519mm x 324mm
   1920x1200  60.0*+
   1920x1080  60.0 59.9  
   1920x1080i 60.1 60.0  
   1600x1200  60.0  
   1280x1024  75.0 60.0  
   1152x864   75.0  
   1280x720   60.0 59.9  
   1024x768   75.1 60.0  
   800x60075.0 60.3  
   720x576i   50.1  
   720x48060.0 59.9  
   720x480i   60.1 60.1  
   640x48075.0 60.0 59.9  
   720x40070.1

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

[PATCH v3 7/7] ARM: bcm2835: Add VC4 to the device tree.

[Eric Anholt]

VC4 is the GPU (display and 3D) present on the 2835.

Signed-off-by: Eric Anholt 
---

v2: Sort by register address, mark HDMI as disabled by default in the
SoC file and enable it from -rpi.

v3: Add references to the pixel/HSM clocks for HDMI.  Rename
compatibility strings and clean up node names.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 42 ++
 2 files changed, 46 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..dcaaee2 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -56,6 +56,10 @@
status = "okay";
 };

+ {
+   status = "okay";
+};
+
  {
status = "okay";
bus-width = <4>;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 1e61eb7..21e354a9 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
 #include 
+#include 
 #include 
 #include "skeleton.dtsi"

@@ -149,6 +150,18 @@
status = "disabled";
};

+   pixelvalve at 7e206000 {
+   compatible = "brcm,bcm2835-pixelvalve0";
+   reg = <0x7e206000 0x100>;
+   interrupts = <2 13>; /* pwa2 */
+   };
+
+   pixelvalve at 7e207000 {
+   compatible = "brcm,bcm2835-pixelvalve1";
+   reg = <0x7e207000 0x100>;
+   interrupts = <2 14>; /* pwa1 */
+   };
+
sdhci: sdhci at 7e30 {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e30 0x100>;
@@ -157,6 +170,12 @@
status = "disabled";
};

+   hvs at 7e40 {
+   compatible = "brcm,bcm2835-hvs";
+   reg = <0x7e40 0x6000>;
+   interrupts = <2 1>;
+   };
+
i2c1: i2c at 7e804000 {
compatible = "brcm,bcm2835-i2c";
reg = <0x7e804000 0x1000>;
@@ -177,6 +196,25 @@
status = "disabled";
};

+   pixelvalve at 7e807000 {
+   compatible = "brcm,bcm2835-pixelvalve2";
+   reg = <0x7e807000 0x100>;
+   interrupts = <2 10>; /* pixelvalve */
+   };
+
+   hdmi: hdmi at 7e902000 {
+   compatible = "brcm,bcm2835-hdmi";
+   reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+   interrupts = <2 8>, <2 9>;
+   ddc = <>;
+   hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+   clocks = < BCM2835_PLLH_PIX>,
+< BCM2835_CLOCK_HSM>;
+   clock-names = "pixel", "hdmi";
+   status = "disabled";
+   };
+
usb at 7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
@@ -186,6 +224,10 @@
arm-pmu {
compatible = "arm,arm1176-pmu";
};
+
+   vc4: gpu at 7e4c {
+   compatible = "brcm,bcm2835-vc4";
+   };
};

clocks {
-- 
2.1.4

[PATCH v3 6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.

[Eric Anholt]

We need to use it for getting video modes over HDMI.

Signed-off-by: Eric Anholt 
Acked-by: Stephen Warren 
---

v2: Mark it as disabled by default, and enable it in bcm2835-rpi.

 arch/arm/boot/dts/bcm2835-rpi.dtsi |  4 
 arch/arm/boot/dts/bcm2835.dtsi | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ab5474e..3572f03 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -52,6 +52,10 @@
clock-frequency = <10>;
 };

+ {
+   status = "okay";
+};
+
  {
status = "okay";
bus-width = <4>;
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index a6a55b7..1e61eb7 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -167,6 +167,16 @@
status = "disabled";
};

+   i2c2: i2c at 7e805000 {
+   compatible = "brcm,bcm2835-i2c";
+   reg = <0x7e805000 0x1000>;
+   interrupts = <2 21>;
+   clocks = < BCM2835_CLOCK_VPU>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
usb at 7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
-- 
2.1.4

[PATCH v3 5/7] drm/vc4: Allow vblank to be disabled

[Eric Anholt]

From: Derek Foreman 

Signed-off-by: Derek Foreman 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ee3e004..2e5597d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -51,6 +51,7 @@ int vc4_kms_load(struct drm_device *dev)
dev->mode_config.max_height = 2048;
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.preferred_depth = 24;
+   dev->vblank_disable_allowed = true;

drm_mode_config_reset(dev);

-- 
2.1.4

[PATCH v3 4/7] drm/vc4: Use the fbdev_cma helpers

[Eric Anholt]

From: Derek Foreman 

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.

Signed-off-by: Derek Foreman 
Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 14 ++
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 3c3ccff..6e73060 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include "drm_fb_cma_helper.h"

 #include "vc4_drv.h"
 #include "vc4_regs.h"
@@ -49,6 +50,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct 
drm_file *file)
vc4_cancel_page_flip(crtc, file);
 }

+static void vc4_lastclose(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_restore_mode(vc4->fbdev);
+}
+
 static const struct file_operations vc4_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -71,6 +80,7 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_ATOMIC |
DRIVER_GEM |
DRIVER_PRIME),
+   .lastclose = vc4_lastclose,
.preclose = vc4_drm_preclose,

.enable_vblank = vc4_enable_vblank,
@@ -199,6 +209,10 @@ static void vc4_drm_unbind(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = platform_get_drvdata(pdev);
+   struct vc4_dev *vc4 = to_vc4_dev(drm);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_fini(vc4->fbdev);

drm_mode_config_cleanup(drm);

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c710e03..23e7bac2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
struct vc4_hdmi *hdmi;
struct vc4_hvs *hvs;
struct vc4_crtc *crtc[3];
+
+   struct drm_fbdev_cma *fbdev;
 };

 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index c241c8f..ee3e004 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
 #include "drm_fb_cma_helper.h"
 #include "vc4_drv.h"

+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+   if (vc4->fbdev)
+   drm_fbdev_cma_hotplug_event(vc4->fbdev);
+}
+
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
+   .output_poll_changed = vc4_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
.fb_create = drm_fb_cma_create,
@@ -29,6 +38,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs = {

 int vc4_kms_load(struct drm_device *dev)
 {
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;

ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
@@ -44,9 +54,11 @@ int vc4_kms_load(struct drm_device *dev)

drm_mode_config_reset(dev);

-   drm_fbdev_cma_init(dev, 32,
-  dev->mode_config.num_crtc,
-  dev->mode_config.num_connector);
+   vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+   dev->mode_config.num_crtc,
+   dev->mode_config.num_connector);
+   if (IS_ERR(vc4->fbdev))
+   vc4->fbdev = NULL;

drm_kms_helper_poll_init(dev);

-- 
2.1.4

[PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

This is enough for fbcon and bringing up X using
xf86-video-modesetting.  It doesn't support the 3D accelerator or
power management yet.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter 
---

v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
ordering instead of using the .load hook.  Structure registration
more like tegra's, but still using the typical "component" code.
Drop no-op hooks for atomic_begin and mode_fixup() now that
they're optional.  Drop sentinel in Makefile.  Fix minor style
nits I noticed on another reread.

v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
of having a fixed video mode.  Use exynos-style component driver
matching instead of devicetree nodes to list the component driver
instances.  Rename compatibility strings to say bcm2835, and
distinguish pv0/1/2.  Clean up some h/vsync code, and add in
interlaced mode setup.  Fix up probe/bind error paths.  Use
bitops.h macros for vc4_regs.h

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/vc4/Kconfig   |  13 +
 drivers/gpu/drm/vc4/Makefile  |  17 +
 drivers/gpu/drm/vc4/vc4_bo.c  |  52 +++
 drivers/gpu/drm/vc4/vc4_crtc.c| 675 ++
 drivers/gpu/drm/vc4/vc4_debugfs.c |  39 +++
 drivers/gpu/drm/vc4/vc4_drv.c | 284 
 drivers/gpu/drm/vc4/vc4_drv.h | 115 +++
 drivers/gpu/drm/vc4/vc4_hdmi.c| 588 +
 drivers/gpu/drm/vc4/vc4_hvs.c | 163 +
 drivers/gpu/drm/vc4/vc4_kms.c |  54 +++
 drivers/gpu/drm/vc4/vc4_plane.c   | 320 ++
 drivers/gpu/drm/vc4/vc4_regs.h| 570 
 14 files changed, 2893 insertions(+)
 create mode 100644 drivers/gpu/drm/vc4/Kconfig
 create mode 100644 drivers/gpu/drm/vc4/Makefile
 create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
 create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
 create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..c4bf9a1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"

 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/vc4/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719..0edc9e2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA) += mga/
 obj-$(CONFIG_DRM_I810) += i810/
 obj-$(CONFIG_DRM_I915)  += i915/
 obj-$(CONFIG_DRM_MGAG200) += mgag200/
+obj-$(CONFIG_DRM_VC4)  += vc4/
 obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
 obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
new file mode 100644
index 000..e810ef7
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -0,0 +1,13 @@
+config DRM_VC4
+   tristate "Broadcom VC4 Graphics"
+   depends on ARCH_BCM2835
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a system that has a Broadcom
+ VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
+
+ This driver requires that "avoid_warnings=2" be present in
+ the config.txt for the firmware, to keep it from smashing
+ our display setup.
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
new file mode 100644
index 000..32b4f9c
--- /dev/null
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -0,0 +1,17 @@
+ccflags-y := -Iinclude/drm
+
+# Please keep these build lists sorted!
+
+# core driver code
+vc4-y := \
+   vc4_bo.o \
+   vc4_crtc.o \
+   vc4_drv.o \
+   vc4_kms.o \
+   vc4_hdmi.o \
+   vc4_hvs.o \
+   vc4_plane.o
+
+vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
+
+obj-$(CONFIG_DRM_VC4)  += vc4.o
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
new file mode 100644
index 000..ab9f510
--- /dev/null
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -0,0 +1,52 @@
+/*
+ *  Copyright © 2015 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* DOC: VC4 GEM BO management support.
+ *
+ * The VC4 GPU architecture (both scanout and rendering) has direct
+ * access to system memory with no MMU in between.  To support it, we
+ * use 

[PATCH v3 2/7] MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.

[Eric Anholt]

Signed-off-by: Eric Anholt 
---

v2: Mark it Supported, not Maintained.

 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..e331e46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3653,6 +3653,12 @@ S:   Maintained
 F: drivers/gpu/drm/sti
 F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt

+DRM DRIVERS FOR VC4
+M: Eric Anholt 
+T: git git://github.com/anholt/linux
+S: Supported
+F: drivers/gpu/drm/vc4/*
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov 
 L: linux-media at vger.kernel.org
-- 
2.1.4

[PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

[Eric Anholt]

VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
other Broadcom SoCs.

This binding follows the model of msm, imx, sti, and others, where
there is a subsystem node for the whole GPU, with nodes for the
individual HW components within it.

Signed-off-by: Eric Anholt 
---

v2: Extend the commit message, fix several nits from Stephen Warren.
v3: Rename the compatibility strings, clean up node names, drop the
unnecessary lists of components.  Use compatibility strings for
choosing CRTC HVS channel numbers.  Document the HDMI clock usage.

 .../devicetree/bindings/gpu/brcm,bcm-vc4.txt   | 64 ++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 000..175bcde
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,64 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible:  Should be "brcm,bcm2835-vc4"
+
+Required properties for Pixel Valve:
+- compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
+   "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
+- reg: Physical base address and length of the PV's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible:  Should be "brcm,bcm2835-hvs"
+- reg: Physical base address and length of the HVS's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible:  Should be "brcm,bcm2835-hdmi"
+- reg: Physical base address and length of the two register ranges
+ ("HDMI" and "HD", in that order)
+- interrupts:  The interrupt numbers
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc: phandle of the I2C controller used for DDC EDID probing
+- clocks:  a) hdmi: The HDMI state machine clock
+   b) pixel: The pixel clock.
+
+Optional properties for HDMI:
+- hpd-gpio:The GPIO pin for HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller
+ itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+pixelvalve at 7e807000 {
+   compatible = "brcm,bcm2835-pixelvalve2";
+   reg = <0x7e807000 0x100>;
+   interrupts = <2 10>; /* pixelvalve */
+};
+
+hvs at 7e40 {
+   compatible = "brcm,bcm2835-hvs";
+   reg = <0x7e40 0x6000>;
+   interrupts = <2 1>;
+};
+
+hdmi: hdmi at 7e902000 {
+   compatible = "brcm,bcm2835-hdmi";
+   reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+   interrupts = <2 8>, <2 9>;
+   ddc = <>;
+   hpd-gpio = < 46 GPIO_ACTIVE_HIGH>;
+   clocks = < BCM2835_PLLH_PIX>,
+< BCM2835_CLOCK_HSM>;
+   clock-names = "pixel", "hdmi";
+};
+
+vc4: gpu at 7e4c {
+   compatible = "brcm,bcm2835-vc4";
+};
-- 
2.1.4

bcm2835 (Raspberry Pi) KMS driver

[Eric Anholt]

This is a respin of the Raspberry Pi KMS series.  Now that we've got a
real clock driver, I can actually set new video modes.  Also in this
version, most of the custom DT stuff from before is gone, thanks to
finding exynos's platform_driver component matching code (I have sent
separate patches to drivers/base to make helpers for doing it).

https://github.com/anholt/linux/tree/vc4-kms-squash-2

[PATCH 00/11] tda998x updates

[Russell King - ARM Linux]

On Tue, Sep 29, 2015 at 07:32:16PM +0100, Russell King - ARM Linux wrote:
> Hi,
> 
> Here's my currently queued TDA998x development work for 4.4.

As there have been no comments against this series, I'll send David a
pull request later today.

> 
> * Remove some useless NULL checks here variables can't be NULL.
> * Return IRQ_HANDLED only if we handled the IRQ, otherwise return
>   IRQ_NONE.  This avoids locking the system up if the IRQ gets stuck.
> * Re-implement a previous patch "Fix EDID read timeout on HDMI connect"
>   to be much more reliable: an attempt to read the EDID may come in
>   while we're delaying the HPD detect event, violating the critical
>   pause.
> * Use Linux types rather than C99 types.
> * Handle all outstanding interrupts, rather than only the first
>   interrupt that we discover pending.
> * Use more helpers from drivers/video/hdmi.c - this removes our own
>   infoframe checksumming code.
> * Remove DRM slave encoder support (which I think no one is using
>   anymore.)  This allows other tidy-ups, removing the abstractions
>   to allow slave encoder support to co-exist with component support.
> 
>  drivers/gpu/drm/i2c/tda998x_drv.c | 487 
> +++---
>  1 file changed, 185 insertions(+), 302 deletions(-)
> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 00/20] Armada DRM updates for 4.4

[Russell King - ARM Linux]

On Tue, Sep 29, 2015 at 07:08:43PM +0100, Russell King - ARM Linux wrote:
> Here are my queued changes for the Armada DRM driver, for the upcoming
> 4.4 merge window.

If there are no further comments (there was only one minor comment which
has been fixed), I'll send a pull request for this to David later today.

> 
> These changes are about updating the driver to some of the more recent
> DRM APIs, and removing the non-component support now that has
> stabilised.  This results in all of armada_output and armada_slave
> being removed, resulting in 460 lines of code removed from that change
> alone.
> 
> Other changes include:
> 
> * moving more towards supporting DRM planes in a more generic way,
>   thereby reducing the duplication between the primary and overlay
>   planes.
> * locking cleanups, more like locking removal, prefering inherently
>   atomic operations (eg, xchg) instead of spinlocking.  This ultimately
>   results in simpler and faster code.
> 
> I've been running these patches for a while and haven't noticed any ill
> effects.
> 
> Posted for comment, if nothing is forthcoming, I'll send a pull request
> to David in a week or so's time.  These patches are against v4.2, but
> rebase to 4.3-rc3 without any fuss.
> 
>  drivers/gpu/drm/armada/Kconfig  |   9 --
>  drivers/gpu/drm/armada/Makefile |   3 +-
>  drivers/gpu/drm/armada/armada_crtc.c| 258 
> +++-
>  drivers/gpu/drm/armada/armada_crtc.h|  34 +++--
>  drivers/gpu/drm/armada/armada_drm.h |  16 --
>  drivers/gpu/drm/armada/armada_drv.c | 148 +++---
>  drivers/gpu/drm/armada/armada_output.c  | 142 --
>  drivers/gpu/drm/armada/armada_output.h  |  33 
>  drivers/gpu/drm/armada/armada_overlay.c | 147 +-
>  drivers/gpu/drm/armada/armada_slave.c   | 139 -
>  drivers/gpu/drm/armada/armada_slave.h   |  26 
>  11 files changed, 297 insertions(+), 658 deletions(-)
>  delete mode 100644 drivers/gpu/drm/armada/armada_output.c
>  delete mode 100644 drivers/gpu/drm/armada/armada_output.h
>  delete mode 100644 drivers/gpu/drm/armada/armada_slave.c
>  delete mode 100644 drivers/gpu/drm/armada/armada_slave.h
> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Intel-gfx] [PATCH 1/3] drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

[Jani Nikula]

On Thu, 08 Oct 2015, Daniel Vetter  wrote:
> On Thu, Oct 08, 2015 at 12:22:31PM -0400, Adam Jackson wrote:
>> On Thu, 2015-10-08 at 11:43 +0300, ville.syrjala at linux.intel.com wrote:
>> > From: Ville Syrjälä 
>> > 
>> > EDID detailed timings have a resolution of 10kHz for the pixel clock, so
>> > they can't represent certain CEA/HDMI modes accurately. If we see a mode
>> > coming in via detailed timings which otherwise matches one of the
>> > CEA/HDMI modes except the clock is just a bit off, let's assume that the
>> > intention was for that mode to be one of the CEA/HDMI modes and go ahead
>> > and fix up the clock to match the CEA/HDMI spec exactly (well, as close
>> > as we can get with the 1 kHz resolution we use).
>> > 
>> > This should help code that's looking for an exact clock match (eg. i915
>> > audio N/CTS setup).
>> 
>> Looks like a sane set of changes.  Series is:
>> 
>> Reviewed-by: Adam Jackson 
>
> Merged the first two patches to drm-misc (the later one has conflicts with
> the lack of drm-intel-next, so can pull it in only after a rebase).

This is needed in v4.3.

BR,
Jani.

>
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

[Fabio Estevam]

On Fri, Oct 9, 2015 at 1:00 PM, Russell King - ARM Linux
 wrote:

>> Thanks, Russell!
>>
>> Got audio to play on my HDMI TV :-)
>>
>> For the entire series:
>>
>> Tested-by: Fabio Estevam 
>
> Just to confirm - that's for _all_ of these 8 patches, including the
> changes to the ACR code in the last four patches, and you're happy that
> I send all of these:
>
> drm: bridge/dw_hdmi-ahb-audio: add audio driver
> drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver
> drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio
> drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes
> drm: bridge/dw_hdmi: avoid being recursive in N calculation
> drm: bridge/dw_hdmi: adjust pixel clock values in N calculation
> drm: bridge/dw_hdmi: remove ratio support from ACR code
> drm: bridge/dw_hdmi: replace CTS calculation for the ACR

That's correct. Thanks, Russell

[Bug 92300] 0 A.D. 100% reproduceable AMD Hawaii (R390X) GPU lockup after a few seconds of running Sicilia map

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

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

MC Return  changed:

   What|Removed |Added

Summary|0 A.D. 100% reproduceable   |0 A.D. 100% reproduceable
   |AMD Hawaii (R390X) GPU  |AMD Hawaii (R390X) GPU
   |lockup after a few minutes  |lockup after a few seconds
   |playing on Sicilia map  |of running Sicilia map

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

[hsakmt] hsakmt organization and formal releases

[Alex Deucher]

On Tue, Oct 6, 2015 at 8:00 AM, Oded Gabbay  wrote:
> Hi,
>
> I had some time during the recent local holidays, so I thought I
> improve the hsakmt library in terms of releases:
>
> 1. I added automake/autoconf files to standardize the package to be
> created using configure/make/make install.
>
> 2. I created a very simple scheme of numbering so we could track releases.
>
> 3. I created a git repository under freedesktop.org amd's folder that
> will hold hsakmt code (instead of using my private git repo). You can
> clone the new repo from: git://anongit.freedesktop.org/amd/hsakmt
>
> 4. I created two new sub-components in freedesktop.org bugzilla, under
> DRI, for hsakmt and amdkfd, so bugs can be filed correctly.
>
> As part of point 1, I rearranged the layout of the source files a bit,
> although I kept the formation of the include files so it would be easy
> to use inside AMD :)
>
> I would like to get (positive) feedback on this, and then I will
> create the first official release and also F22, F23 and F24 (rawhide)
> rpm packages that will be part of the distribution.
>
> As a reminder, this repository will be used to manage only the
> upstream version of hsakmt. Private/non-yet-upstreamed releases of AMD
> are done in GitHub.

Looks good to me!  thanks,

Alex

>
> Thanks,
>
>Oded

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized

[Joerg Roedel]

On Tue, Oct 06, 2015 at 09:13:11PM +0800, Jiang Liu wrote:
>   We are on leave for Chinese National Holiday and has limited
> access to my working environment. It would be appreciated if you could
> help to send out a patch for it. Otherwise I will send out a patch
> within 2-3 days.

Okay, I just sent the patch.


Joerg

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

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

MC Return  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #16 from MC Return  ---
(In reply to Michel Dänzer from comment #14)
> 
> I use:
> 
> --host=i386-linux-gnu --with-llvm-prefix=[path to 32-bit llvm directory]
> 'CC=gcc -m32' 'CXX=g++ -m32'

I have no idea how to find out the "path to 32-bit llvm directory" and
searching for it did not bring up any results I could use.
Could you please tell me where this path is supposed to be and how it's name is
on a Ubuntu amd64 based system ?

I think this report can be closed for now - or should it stay open and be
renamed because of the log problems ?

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

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

core/materials/unigine_billboards.mat" 1 material 33 shaders 2ms
Loading "core/materials/unigine_volumes.mat" 5 materials 29 shaders 5ms
Loading "core/materials/unigine_guis.mat" 1 material 24 shaders 0ms
Loading "core/materials/unigine_water.mat" 1 material 63 shaders 8ms
Loading "core/materials/unigine_skies.mat" 1 material 19 shaders 10ms
Loading "core/materials/unigine_decals.mat" 1 material 69 shaders 3ms
Loading "core/properties/unigine.prop" 2 properties 0ms
Unigine~# world_load sanctuary
Loading "sanctuary.cpp" 42ms
Loading "sanctuary/sanctuary.mat" 54 materials 228ms
Loading "sanctuary.world" 5446ms
Unigine~# render_hdr 0 && render_srgb 0 && render_restart
GLShader::loadFragment(): error in
"core/shaders/render/fragment_occlusion_blur.shader" file
defines:
UNKNOWN,QUALITY_LOW,QUALITY_MEDIUM,QUALITY_HIGH,MULTISAMPLE_0,USE_INSTANCING,USE_TEXTURE_ARRAY,USE_DEFERRED,USE_TRANSLUCENT,USE_PARALLAX,USE_OCCLUSION,USE_REFLECTION,OPENGL,USE_PSEUDO_INSTANCING,USE_PSEUDO_TRANSFORM,USE_ARB_SAMPLE_SHADING,USE_ARB_TEXTURE_MULTISAMPLE,HAS_ARB_DRAW_INSTANCED
0:511(15): error: no function with name 'texelFetch2DOffset'
0:512(15): error: no function with name 'texelFetch2DOffset'
0:513(15): error: no function with name 'texelFetch2DOffset'
0:514(15): error: no function with name 'texelFetch2DOffset'
0:515(15): error: no function with name 'texelFetch2DOffset'
0:516(15): error: no function with name 'texelFetch2DOffset'
0:517(15): error: no function with name 'texelFetch2DOffset'
0:518(15): error: no function with name 'texelFetch2DOffset'
0:519(15): error: no function with name 'texelFetch2DOffset'
0:520(15): error: no function with name 'texelFetch2DOffset'
0:521(16): error: no function with name 'texelFetch2DOffset'
0:522(16): error: no function with name 'texelFetch2DOffset'
0:523(16): error: no function with name 'texelFetch2DOffset'
0:524(16): error: no function with name 'texelFetch2DOffset'
0:525(16): error: no function with name 'texelFetch2DOffset'
0:526(16): error: no function with name 'texelFetch2DOffset'
Unigine~# quit
Close "libopenal.so.1"
Close "libGL.so.1"
Memory usage: 64b
Allocations:  1
Shutdown

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

[Intel-gfx] [PATCH 05/11] drm/i915: Mark getparam ioctl as DRM_UNLOCKED

[Chris Wilson]

On Tue, Sep 08, 2015 at 01:56:25PM +0200, Daniel Vetter wrote:
> With kms all the data getparam looks at is actually invariant, and
> certainly not protected by the global kms mutex. With ums all the
> setup code is already racy as hell, so this won't make things any
> worse.

Correct.

> I've done this change so that all ioctl still used by kms drivers
> are marked as DRM_UNLOCKED, besides that we obviously don't need
> it any more in kms mode.
> 
> Signed-off-by: Daniel Vetter 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/amdgpu: rework sdma structures

[Christian König]

On 09.10.2015 00:15, Alex Deucher wrote:
> Rework the sdma structures in the driver to
> consolidate all of the sdma info into a single
> structure and allow for asics that may have
> different numbers of sdma instances.
>
> Signed-off-by: Alex Deucher 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  22 +--
>   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |   4 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|   7 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  10 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c  |   4 +-
>   drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 130 -
>   drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 156 ++--
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 166 
> +++---
>   9 files changed, 245 insertions(+), 258 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 6647fb2..afc9848 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1708,7 +1708,7 @@ struct amdgpu_vce {
>   /*
>* SDMA
>*/
> -struct amdgpu_sdma {
> +struct amdgpu_sdma_instance {
>   /* SDMA firmware */
>   const struct firmware   *fw;
>   uint32_tfw_version;
> @@ -1718,6 +1718,13 @@ struct amdgpu_sdma {
>   boolburst_nop;
>   };
>   
> +struct amdgpu_sdma {
> + struct amdgpu_sdma_instance instance[AMDGPU_MAX_SDMA_INSTANCES];
> + struct amdgpu_irq_src   trap_irq;
> + struct amdgpu_irq_src   illegal_inst_irq;
> + int num_instances;
> +};
> +
>   /*
>* Firmware
>*/
> @@ -2064,9 +2071,7 @@ struct amdgpu_device {
>   struct amdgpu_gfx   gfx;
>   
>   /* sdma */
> - struct amdgpu_sdma  sdma[AMDGPU_MAX_SDMA_INSTANCES];
> - struct amdgpu_irq_src   sdma_trap_irq;
> - struct amdgpu_irq_src   sdma_illegal_inst_irq;
> + struct amdgpu_sdma  sdma;
>   
>   /* uvd */
>   boolhas_uvd;
> @@ -2203,17 +2208,18 @@ static inline void amdgpu_ring_write(struct 
> amdgpu_ring *ring, uint32_t v)
>   ring->ring_free_dw--;
>   }
>   
> -static inline struct amdgpu_sdma * amdgpu_get_sdma_instance(struct 
> amdgpu_ring *ring)
> +static inline struct amdgpu_sdma_instance *
> +amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
>   {
>   struct amdgpu_device *adev = ring->adev;
>   int i;
>   
> - for (i = 0; i < AMDGPU_MAX_SDMA_INSTANCES; i++)
> - if (>sdma[i].ring == ring)
> + for (i = 0; i < adev->sdma.num_instances; i++)
> + if (>sdma.instance[i].ring == ring)
>   break;
>   
>   if (i < AMDGPU_MAX_SDMA_INSTANCES)
> - return >sdma[i];
> + return >sdma.instance[i];
>   else
>   return NULL;
>   }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> index dd2037b..0e13763 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> @@ -649,12 +649,12 @@ static uint16_t get_fw_version(struct kgd_dev *kgd, 
> enum kgd_engine_type type)
>   
>   case KGD_ENGINE_SDMA1:
>   hdr = (const union amdgpu_firmware_header *)
> - adev->sdma[0].fw->data;
> + 
> adev->sdma.instance[0].fw->data;
>   break;
>   
>   case KGD_ENGINE_SDMA2:
>   hdr = (const union amdgpu_firmware_header *)
> - adev->sdma[1].fw->data;
> + 
> adev->sdma.instance[1].fw->data;
>   break;
>   
>   default:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> index dfd1d50..79fa5c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
> @@ -523,12 +523,12 @@ static uint16_t get_fw_version(struct kgd_dev *kgd, 
> enum kgd_engine_type type)
>   
>   case KGD_ENGINE_SDMA1:
>   hdr = (const union amdgpu_firmware_header *)
> - adev->sdma[0].fw->data;
> + 
> adev->sdma.instance[0].fw->data;
>   break;
>   
>   case KGD_ENGINE_SDMA2:
>   hdr = (const union amdgpu_firmware_header *)
> - adev->sdma[1].fw->data;
> + 
> adev->sdma.instance[1].fw->data;
>   break;
>   
>  

As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

[Daniel Vetter]

Another regression for Jairo to track.
-Daniel

On Thu, Oct 08, 2015 at 11:43:39PM -0700, Doug Smythies wrote:
> 
> Hi,
> 
> This started somewhere between Kernel 4.2 and 4.3-rc1,
> but I only noticed it a day ago.
> 
> The first S3 suspend after a fresh boot works fine.
> Thereafter, suspends simply resume again immediately.
> 
> I get the following errors on my console:
> 
> [  152.697247] i915 :00:02.0: GEM idle failed, resume might fail
> [  152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11
> [  152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11
> [  152.697264] PM: Device :00:02.0 failed to suspend async: error -11
> [  152.697306] PM: Some devices failed to suspend, or early wake event 
> detected
> 
> The issue is not limited to my normal way of doing suspend, using 
> "pm-suspend".
> It also happens using the "echo mem > /sys/power/state" method.
> 
> The kernel was bisected, and the result was double checked by clean compiles
> of the first bad commit and the immediately preceding commit. Bisect results
> copied below:
> 
> $ git bisect good
> dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit
> commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2
> Author: John Harrison 
> Date:   Fri May 29 17:43:39 2015 +0100
> 
> drm/i915: Add explicit request management to i915_gem_init_hw()
> 
> Now that a single per ring loop is being done for all the different
> intialisation steps in i915_gem_init_hw(), it is possible to add proper 
> request
> management as well. The last remaining issue is that the context enable 
> call
> eventually ends up within *_render_state_init() and this does its own 
> private
> _i915_add_request() call.
> 
> This patch adds explicit request creation and submission to the top level 
> loop
> and removes the add_request() from deep within the sub-functions.
> 
> v2: Updated for removal of batch_obj from add_request call in previous 
> patch.
> 
> For: VIZ-5115
> Signed-off-by: John Harrison 
> Reviewed-by: Tomas Elf 
> Signed-off-by: Daniel Vetter 
> 
> :04 04 789c630ff3f5f07238a5df1bde79187c6c1251d0 
> 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M  drivers
> 
> 
> 

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

[Bug 92301] Unigine Sanctuary freeze-crashes R390X

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

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

--- Comment #14 from Michel Dänzer  ---
(In reply to MC Return from comment #12)
> I set those env vars, but the result was exactly the same - sanctuary
> crashed the machine after a few seconds running, but it showed these errors
> after changing screens to console mode:

Thanks, but as I said, we need to see the corresponding terminal / log output
from Sanctuary.

(In reply to MC Return from comment #13)
> Nope --enable-32-bit is no longer recognized and I could not find any
> instructions on how to ensure a 32bit build...
> What flags do I need to add to ./autogen.sh or what needs to be done to to
> get that accomplished ?

I use:

--host=i386-linux-gnu --with-llvm-prefix=[path to 32-bit llvm directory]
'CC=gcc -m32' 'CXX=g++ -m32'

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

[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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

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

--- Comment #7 from Ernst Sjöstrand  ---
Alex: are you going to wait for the DAL to fix this or what would you guess?

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

As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

[Doug Smythies]

Hi,

This started somewhere between Kernel 4.2 and 4.3-rc1,
but I only noticed it a day ago.

The first S3 suspend after a fresh boot works fine.
Thereafter, suspends simply resume again immediately.

I get the following errors on my console:

[  152.697247] i915 :00:02.0: GEM idle failed, resume might fail
[  152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11
[  152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11
[  152.697264] PM: Device :00:02.0 failed to suspend async: error -11
[  152.697306] PM: Some devices failed to suspend, or early wake event detected

The issue is not limited to my normal way of doing suspend, using "pm-suspend".
It also happens using the "echo mem > /sys/power/state" method.

The kernel was bisected, and the result was double checked by clean compiles
of the first bad commit and the immediately preceding commit. Bisect results
copied below:

$ git bisect good
dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit
commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2
Author: John Harrison 
Date:   Fri May 29 17:43:39 2015 +0100

drm/i915: Add explicit request management to i915_gem_init_hw()

Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper 
request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and this does its own 
private
_i915_add_request() call.

This patch adds explicit request creation and submission to the top level 
loop
and removes the add_request() from deep within the sub-functions.

v2: Updated for removal of batch_obj from add_request call in previous 
patch.

For: VIZ-5115
Signed-off-by: John Harrison 
Reviewed-by: Tomas Elf 
Signed-off-by: Daniel Vetter 

:04 04 789c630ff3f5f07238a5df1bde79187c6c1251d0 
2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M  drivers