[libdrm PATCH 2/2] configure.ac: don't detect disabled options dependencies
On Tue, Jan 19, 2016 at 10:26:16AM +0200, Emil Velikov wrote:
> Hi Marcin,
>
> On 9 January 2016 at 17:05, Marcin Ålusarz
> wrote:
> > Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
> > cunit, valgrind and cairo are still detected.
> >
> Doesn't this patch make 1/2 obsolete ?
Yes, more or less. Both patches fix the issue I was seeing.
>
> > Signed-off-by: Marcin Ålusarz
>
> Reviewed-by: Emil Velikov
>
> > ---
> > configure.ac | 36 ++--
> > 1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index c8c4ace..cc44e3f 100644
> > --- a/configure.ac
> > +++ b/configure.ac
>
> > @@ -400,7 +404,9 @@ AC_ARG_ENABLE([cairo-tests],
> >[AS_HELP_STRING([--enable-cairo-tests],
> >[Enable support for Cairo rendering in tests
> > (default: auto)])],
> >[CAIRO=$enableval], [CAIRO=auto])
> > -PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> > +if test "x$CAIRO" != xno; then
> > + PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> > +fi
> Namely: if we have disable-cairo-tests, the module will never be
> checked, thus CAIRO_{CFLAGS,LIBS} will be empty. Obviously the user
> can explicitly sets the CAIRO_* variables, in which case they're
> cutting the branch they're standing on.
>
> Please let me know if you'd prefer to have 1/2 regardless (or if I
> missed something)
I thought it would be better to have cairo build flags guarded by global
HAVE_CAIRO flag. If you want to apply just this patch, that's fine by me.
>
> Thank you for sorting these.
Thanks,
Marcin
[PATCH] Fix building on musl-libc
libdrm git master fails to compile due to undefined functions/constants on musl libc. The attached patches fix it. (I've attached them rather than included them in the message since gmail is really bad about ruining patch formatting.) I originally posted these to https://bugs.freedesktop.org/show_bug.cgi?id=93764 in a different form, and have modified them to Emil's comments on the bugzilla entry. commit 6ec5d220184e46135109923d252ae619068b7eb2 Author: Kylie McClain Date: Tue Jan 19 22:27:28 2016 -0500 tests: Include poll.h rather than sys/poll.h sys/poll.h is a non-standard location of the poll.h header, and is incorrect on non-glibc libcs. poll.h, however, is defined in SUS (v2) and is more portable. http://pubs.opengroup.org/onlinepubs/007908799/xsh/poll.h.html commit 6e7f12f1977bd13d10d99bc7826c54b692284c38 Author: Kylie McClain Date: Tue Jan 19 22:24:15 2016 -0500 kms-steal-crtc: Make use of sys/select.h if available On systems using musl libc, FD_ZERO, FD_SET, select, etc. are defined in sys/select.h. This behavior is defined in IEEE Std 1003.1, 2000, http://pubs.opengroup.org/onlinepubs/009696899/basedefs/sys/select.h.html and fixes building kms-steal-crtc on musl libc systems. -- next part -- A non-text attachment was scrubbed... Name: 0001-kms-steal-crtc-Make-use-of-sys-select.h-if-available.patch Type: text/x-patch Size: 1313 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/1fd2fc1e/attachment-0002.bin> -- next part -- A non-text attachment was scrubbed... Name: 0002-tests-Include-poll.h-rather-than-sys-poll.h.patch Type: text/x-patch Size: 1228 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/1fd2fc1e/attachment-0003.bin>
[RFC 00/29] De-stage android's sync framework
On Tue, Jan 19, 2016 at 06:10:40PM -0200, Gustavo Padovan wrote: > 2016-01-19 Daniel Vetter : > > - get_timeline_name and get_driver_name are imo too much indirection, just > > add ->(drv_)name field to each of these. > > I don't think is a good idea to change that now as there are other fence > users in the kernel using get_timeline_name and get_driver_name. What I > propose is try get rid of this when moving ops from fences to > fence_timeline. Makes sense. And yeah I only realized after sending that this wasn't added by your patches, just that your patches added the (core) users for it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 93761] A conditional discard in a fragment shader causes no depth writing at all
https://bugs.freedesktop.org/show_bug.cgi?id=93761 --- Comment #2 from Nicolai H�hnle --- Here's a fix: http://patchwork.freedesktop.org/patch/71068/ -- 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/20160119/9b888025/attachment.html>
[Bug 88861] [efi, i915, vgaswitcheroo, black screen, nouveau] Screen goes black when switching from dedicated nvidia graphics card (nouveau) to integrated
https://bugzilla.kernel.org/show_bug.cgi?id=88861 --- Comment #9 from Lukas Wunner --- Hi Jani, Paul Hordiienko, the reporter of this bug, successfully tested an earlier version (v2) of the patch set, see the Tested-by: tags on these patches: http://lists.freedesktop.org/archives/dri-devel/2015-August/thread.html#88156 The most recent version (v5) was tested on the following machines: Tested-by: Pierre Moreau [MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"] Tested-by: William Brown [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] Tested-by: Lukas Wunner [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] (The patches as posted miss the Tested-by: tags by Pierre and William since I posted them before getting their feedback.) The patch set worked just fine on my machine and William Brown's. On Pierre Moreau's machine the discrete GPU locks up when woken. It used to do that in the past as well but only after about 10 switches, now it's locking up every time. My guess is that this is a regression in nouveau on the G96 since it works fine on my GK107. Paul Hordiienko's machine is an MBP 6,2 2010 with intel ILK + nvidia GT216. So architecturally it is similar to my machine (integrated Intel and discrete Nvidia) and since v2 worked fine, I expect that v5 would work as well (FWIW). -- You are receiving this mail because: You are the assignee for the bug.
[RFC 00/29] De-stage android's sync framework
On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote: > 2016-01-19 John Harrison : > > > On 19/01/2016 15:23, Gustavo Padovan wrote: > > >Hi Daniel, > > > > > >2016-01-19 Daniel Vetter : > > > > > >>On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote: > > >>>From: Gustavo Padovan > > >>> > > >>>This patch series de-stage the sync framework, and in order to > > >>>accomplish that > > >>>a bunch of cleanups/improvements on the sync and fence were made. > > >>> > > >>>The sync framework contained some abstractions around struct fence and > > >>>those > > >>>were removed in the de-staging process among other changes: > > >>> > > >>>Userspace visible changes > > >>>- > > >>> > > >>> * The sw_sync file was moved from /dev/sw_sync to > > >>> /sync/sw_sync. No > > >>> other change. > > >>> > > >>>Kernel API changes > > >>>-- > > >>> > > >>> * struct sync_timeline is now struct fence_timeline > > >>> * sync_timeline_ops is now fence_timeline_ops and they now carry struct > > >>> fence as parameter instead of struct sync_pt > > >>> * a .cleanup() fence op was added to allow sync_fence to run a cleanup > > >>> when > > >>> the fence_timeline is destroyed > > >>> * added fence_add_used_data() to pass a private point to struct fence. > > >>> This > > >>> pointer is sent back on the .cleanup op. > > >>> * The sync timeline function were moved to be fence_timeline functions: > > >>> - sync_timeline_create() -> fence_timeline_create() > > >>> - sync_timeline_get() -> fence_timeline_get() > > >>> - sync_timeline_put() -> fence_timeline_put() > > >>> - sync_timeline_destroy() -> fence_timeline_destroy() > > >>> - sync_timeline_signal() -> fence_timeline_signal() > > >>> > > >>> * sync_pt_create() was replaced be fence_create_on_timeline() > > >>> > > >>>Internal changes > > >>> > > >>> > > >>> * fence_timeline_ops was removed in favor of direct use fence_ops > > >>> * fence default functions were created for fence_ops > > >>> * removed structs sync_pt, sw_sync_timeline and sw_sync_pt > > >>Bunch of fairly random comments all over: > > >> > > >>- include/uapi/linux/sw_sync.h imo should be dropped, it's just a private > > >> debugfs interface between fence fds and the testsuite. Since the plan > > >> is > > >> to have the testcases integrated into the kernel tree too we don't need > > >> a public header. > > >> > > >>- similar for include/linux/sw_sync.h Imo that should all be moved into > > >> sync_debug.c. Same for sw_sync.c, that should all land in sync_debug > > >> imo, and made optional with a Kconfig option. At least we should reuse > > >> CONFIG_DEBUGFS. > > >These two items sounds reasonable to me. > > > > I have just posted our in-progress IGT for testing i915 syncs (with a CC of > > Gustavo). It uses the sw_sync mechanisms. Can you take a quick look and see > > if it is the kind of thing you would expect us to be doing? Or is it using > > interfaces that you are planning to remove and/or make kernel only? > > > > I'm not sure having a kernel only test is the best way to go. Having user > > land tests like IGT would be much more versatile. > > I agree with you, we should allow IGT and other test tools to access > sw_sync. include/linux/sw_sync.h can be kept private, but the uapi one > needs wil be needed for testing, unless we replicate the header file > inside IGT, but not sure if it is a good idea. We replicate all the debugfs stuff in igt that igt needs. uapi really only should be stuff that's guaranteed to stick around, not debug interfaces we are ok with breaking (if needed). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #8 from Matthew Dawson --- What do you normally run to start minecraft from the terminal? I'll assume it's just minecraft, but if it is different just replace that part. Run: GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load,num-bytes-moved,buffer-wait-time,num-compilations+num-shaders-created minecraft If it works, you should see a bunch of graphs appears on the screen. -- 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/20160119/d2c0d482/attachment.html>
[Bug 93649] [radeonsi] Graphics lockup while playing tf2
https://bugs.freedesktop.org/show_bug.cgi?id=93649 --- Comment #3 from russianneuromancer at ya.ru --- There is other logs: https://github.com/ValveSoftware/Source-1-Games/issues/1943 -- 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/20160119/d7d5862c/attachment.html>
[RFC 00/29] De-stage android's sync framework
2016-01-19 Daniel Vetter :
> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This patch series de-stage the sync framework, and in order to accomplish
> > that
> > a bunch of cleanups/improvements on the sync and fence were made.
> >
> > The sync framework contained some abstractions around struct fence and those
> > were removed in the de-staging process among other changes:
> >
> > Userspace visible changes
> > -
> >
> > * The sw_sync file was moved from /dev/sw_sync to /sync/sw_sync.
> > No
> > other change.
> >
> > Kernel API changes
> > --
> >
> > * struct sync_timeline is now struct fence_timeline
> > * sync_timeline_ops is now fence_timeline_ops and they now carry struct
> > fence as parameter instead of struct sync_pt
> > * a .cleanup() fence op was added to allow sync_fence to run a cleanup when
> > the fence_timeline is destroyed
> > * added fence_add_used_data() to pass a private point to struct fence. This
> > pointer is sent back on the .cleanup op.
> > * The sync timeline function were moved to be fence_timeline functions:
> > - sync_timeline_create() -> fence_timeline_create()
> > - sync_timeline_get() -> fence_timeline_get()
> > - sync_timeline_put() -> fence_timeline_put()
> > - sync_timeline_destroy() -> fence_timeline_destroy()
> > - sync_timeline_signal() -> fence_timeline_signal()
> >
> > * sync_pt_create() was replaced be fence_create_on_timeline()
> >
> > Internal changes
> >
> >
> > * fence_timeline_ops was removed in favor of direct use fence_ops
> > * fence default functions were created for fence_ops
> > * removed structs sync_pt, sw_sync_timeline and sw_sync_pt
>
> Bunch of fairly random comments all over:
>
> - include/uapi/linux/sw_sync.h imo should be dropped, it's just a private
> debugfs interface between fence fds and the testsuite. Since the plan is
> to have the testcases integrated into the kernel tree too we don't need
> a public header.
>
> - similar for include/linux/sw_sync.h Imo that should all be moved into
> sync_debug.c. Same for sw_sync.c, that should all land in sync_debug
> imo, and made optional with a Kconfig option. At least we should reuse
> CONFIG_DEBUGFS.
>
> - fence_context and fence_timeline are really the same. timeline has some
> super-basic support for doing sw-only fence timelines, but imo that's
> not really worth keeping (and if so better to keep seperate in a
> sw-fence.c or similar, like seqno-fence.c). The other main thing
> timeline provides is support to clean up fences on a timeline. And imo
> that cleanup should be done by the core fence support, not by the add-on
> stuff.
>
> Interlude about fence cleanup on driver unload:
>
> Working drivers imo should never call timeline_destroy when there's still
> an unsignalled fence around for that timeline/context. That just means
> they're broken and failed to clean up all the pending work. So the problem
> really is only what to do with fences where the driver disappeared, and
> for that we essentially need a fence_revoke() function (which could be
> called internally from timeline_free). So here's what I think
> timeline_free should do:
>
> for_each_fence_on_timel() {
> WARN_ON(!fence_is_signalled());
>
> fence_revoke(fence);
> }
>
> Implementing fence_revoke is a bit tricky since we need to make sure the
> memory contained ->ops and similar stuff doesn't disappear. Simplest
> option might be to grab a temporary reference (using
> kref_get_unless_zero), and then exchange ->ops with one that has only a
> release function. We don't need anything else as long as all fence_*
> functions the kernel might call check for signalling correctly first
> (fence_wait is broken at least).
>
> Or we just give up (for now) and declare module unload as slightly racy.
> dma-buf is similar. An intermediate option might be to at least add a
> THIS_MODULE reference to each fence (but that's a bit expensive ...).
>
> - back to timeline vs. context: I have no idea how to best clean up this
> mess, but least painful option long-term is probably to switch over all
> current users of fence_context_alloc to timelines and remove the plain
> context interface.
>
> - Imo the interface in include/linux/sync.h is duplicating too much of
> fence.h. I think the only bits we need are the refcounting, creating,
> fd-install and that's it. Plus a macro to loop over all the fences in a
> sync_fence. With that drivers will only ever deal with a pile of
> struct fence, making implicit fencing (using the fence list in dma-buf)
> and explicit fencing (using the fence list in sync_fence) much more
> similar.
>
> And we can easily do that since no internal users ;-)
>
> - get_timeline_name and get_driver_name are imo too much indirection, just
> add ->(drv_)name field to eac
[PATCH v12.1 13/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Martinez Canillas
---
There is no new changes in v12.1, but just rebase the whole patches on
top of Dave's drm-next branch [0] (Heiko)
Changes in v12.1: None
Changes in v12: None
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
hpd when hpd detect failed.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 4 ++-
.../bindings/display/exynos/exynos_dp.txt | 1 +
.../display/rockchip/analogix_dp-rockchip.txt | 1 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 9 ++
6 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
+ -force-hpd:
+ Indicate driver need force hpd when hpd detect failed, this
+ is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
*
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
-
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
---
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 4fa8aca..ade5d8e 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -56,6 +56,7 @@ For the below properties, please refer to Analogix DP binding
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+force-hpd (optional)
Deprecated properties for DisplayPort:
-interlaced:deprecated prop that can parsed from drm_display_mode.
diff --git
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
---
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding
document:
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
+- force-hpd (optional)
---
Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a62e8d0..13986b7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -62,15 +62,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
{
int timeout_loop = 0;
- while (analogix_dp_get_plug_in_status(dp) != 0) {
+ while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+ if (analogix_dp_get_plug_in_status(dp) == 0)
+ return 0;
+
timeout_loop++;
- if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "failed to get hpd plug status\n");
- return -ETIMEDOUT;
- }
usleep_range(10, 11);
}
+ /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "force-hpd" would indicate whether driver need this.
+*/
+ if (!dp->force_hpd)
+ return -ETIMEDOUT;
+
+ /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we ne
[PATCH v12.1 07/17] drm: rockchip: dp: add rockchip platform dp driver
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Rebase the whole patches on top of Dave's drm-next branch [0] (Heiko)
Changes in v12.1:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
numbers in the example DT node, and remove the regulator iomux setting
in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.
Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
and leave "sclk_edp" to analogix dp core driver which name to "dp",
and leave "pclk_edp" to rockchip dp platform driver which name to
"pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.
Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
leave those clock to rockchip dp phy driver.
drivers/gpu/drm/rockchip/Kconfig| 9 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 384
include/drm/bridge/analogix_dp.h| 1 +
4 files changed, 395 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 8573985..9fe4e32 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -35,3 +35,12 @@ config ROCKCHIP_DW_MIPI_DSI
for the Synopsys DesignWare HDMI driver. If you want to
enable MIPI DSI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_ANALOGIX_DP
+ tristate "Rockchip specific extensions for Analogix DP driver"
+ depends on DRM_ROCKCHIP
+ select DRM_ANALOGIX_DP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index d1dc0f7..40d4c94 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..acedc98
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,384 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan
+ * Yakir Yang
+ * Jeff Chen
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm) container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+ struct drm_device*drm_dev;
+ struct device*dev;
+ struct drm_encoder encoder;
+ struct drm_display_mode mode;
+
+ struct clk *pclk;
+ struct regmap*grf;
+ struct reset
[PATCH v12.1 06/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.
Signed-off-by: Yakir Yang
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
There is no new changes in v12.1, but just rebase the whole patches on
top of Dave's drm-next branch [0] (Heiko)
Changes in v12.1: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
- hpd-gpio = <&gpx2 6 0>;
+ hpd-gpios = <&gpx2 6 0>;
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)
Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
7 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
&dp {
status = "okay";
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
&dp {
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408..ee94110 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
- samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
};
&ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f0..8baf40a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
- samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+ hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
- samsung,dynamic-range = <0>;
- samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
dif
[PATCH v12.1 05/17] dt-bindings: add document for analogix display port driver
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
There is no new changes in v12.1, but just rebase the whole patches on
top of Dave's drm-next branch [0] (Heiko)
Changes in v12.1: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring
Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth" &
"analogix,link-rate" & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high" & "interlaces"
Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.
Changes in v2: None
.../bindings/display/bridge/analogix_dp.txt| 50
.../bindings/display/exynos/exynos_dp.txt | 92 ++
2 files changed, 76 insertions(+), 66 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+ -compatible:
+ platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+ -reg:
+ physical base address of the controller and length
+ of memory mapped region.
+ -interrupts:
+ interrupt combiner values.
+ -clocks:
+ from common clock binding: handle to dp clock.
+ -clock-names:
+ from common clock binding: Shall be "dp".
+ -interrupt-parent:
+ phandle to Interrupt combiner node.
+ -phys:
+ from general PHY binding: the phandle for the PHY device.
+ -phy-names:
+ from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+ -hpd-gpios:
+ Hotplug detect GPIO.
+ Indicates which GPIO should be used for hotplug detection
+ -port@[X]: SoC specific port nodes with endpoint definitions as defined
+ in Documentation/devicetree/bindings/media/video-interfaces.txt,
+ please refer to the SoC specific binding document:
+ * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+ *
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+ dp-controller {
+ compatible = "samsung,exynos5-dp";
+ reg = <0x145b 0x1>;
+ interrupts = <10 3>;
+ interrupt-parent = <&combiner>;
+ clocks = <&clock 342>;
+ clock-names = "dp";
+
+ phys = <&dp_phy>;
+ phy-names = "dp";
+ };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index fe4a7a2..4fa8aca 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -1,20 +1,3 @@
-Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
-
-DisplayPort is industry standard to accommodate the growing board adoption
-of digital display technology within the PC and CE industries.
-It consolidates the internal and external connection methods to reduce device
-complexity and cost. It also supports necessary features for important cross
-industry applications and provides performance scalability to enable the next
-generation of displays that feature higher color depths, refresh rates, and
-display resolutions.
-
-eDP (embedded display port) device is compliant with Embedded DisplayPort
-standard as follows,
-- DisplayPort stand
[PATCH] drm/amdgpu: Use drm_calloc_large for VM page_tables array
From: Michel Dänzer
It can be big, depending on the VM address space size, which is tunable
via the vm_size module parameter.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index aefc668..9599f75 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1282,7 +1282,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
amdgpu_vm *vm)
{
const unsigned align = min(AMDGPU_VM_PTB_ALIGN_SIZE,
AMDGPU_VM_PTE_COUNT * 8);
- unsigned pd_size, pd_entries, pts_size;
+ unsigned pd_size, pd_entries;
int i, r;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
@@ -1300,8 +1300,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
amdgpu_vm *vm)
pd_entries = amdgpu_vm_num_pdes(adev);
/* allocate page table array */
- pts_size = pd_entries * sizeof(struct amdgpu_vm_pt);
- vm->page_tables = kzalloc(pts_size, GFP_KERNEL);
+ vm->page_tables = drm_calloc_large(pd_entries, sizeof(struct
amdgpu_vm_pt));
if (vm->page_tables == NULL) {
DRM_ERROR("Cannot allocate memory for page table array\n");
return -ENOMEM;
@@ -1361,7 +1360,7 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct
amdgpu_vm *vm)
for (i = 0; i < amdgpu_vm_num_pdes(adev); i++)
amdgpu_bo_unref(&vm->page_tables[i].entry.robj);
- kfree(vm->page_tables);
+ drm_free_large(vm->page_tables);
amdgpu_bo_unref(&vm->page_directory);
fence_put(vm->page_directory_fence);
--
2.7.0.rc3
[PATCH v12.1 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp_resume()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"
The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.
They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.
Signed-off-by: Yakir Yang
---
There is no new changes in v12.1, but just rebase the whole patches on
top of Dave's drm-next branch [0] (Heiko)
Changes in v12.1: None
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper(Heiko)
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
attch function. Cause once platform failed at attach, core driver should
still failed, so no need to init connector before platform attached
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)
Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell
drivers/gpu/drm/bridge/Kconfig |2 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/analogix/Kconfig|3 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
.../analogix/analogix_dp_core.c} | 816 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 277 +
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 1263
.../analogix/analogix_dp_reg.h}| 258 ++--
drivers/gpu/drm/exynos/Kconfig |3 +-
drivers/gpu/drm/exynos/Makefile|2 +-
drivers/gpu/drm/exynos/exynos_dp.c | 328 +
drivers/gpu/drm/exynos/exynos_dp_core.h| 282 -
drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263
include/drm/bridge/analogix_dp.h | 40 +
14 files changed, 2373 insertions(+), 2166 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
rename drivers/gpu/drm/{exynos/exynos_dp_core.c =>
bridge/analogix/analogix_dp_core.c} (52%)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
rename drivers/gpu/drm/{exynos/exynos_dp_reg.h =>
bridge/analogix/analogix_dp_reg.h} (64%)
create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
create mode 100644 include/drm/bridge/analogix_dp.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..efd94e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,6 @@ config DRM_PARADE_PS8622
---help---
Parade eDP-LVDS bridge chip driver.
+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..ff821f4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)
https://bugs.freedesktop.org/show_bug.cgi?id=93292 --- Comment #8 from Jan-Marek Glogowski --- working command line with patch to get the shader log: R600_SB_DSKIP_START=94 R600_SB_DSKIP_END=94 R600_SB_DSKIP_MODE=63 glretrace thea.trace working command line without the patch to verify shader bug: R600_SB_DSKIP_START=94 R600_SB_DSKIP_END=94 R600_SB_DSKIP_MODE=1 glretrace thea.trace In the end I'm just using the llvm backend (R600_DEBUG=llvm). I just see a minimal difference on this HW in game of ~0.5 frames (slower LLVM). Actually I had other small rendering glitches with the SB shader backend, which I didn't track down. (In reply to Ilia Mirkin from comment #2) > In case it's of any interest, I tested this on nouveau -- on nvc0 (GF108) > the trace replays seemingly fine. On nv50 (GT215), I also get a failure on > the map screen, but it's different -- everything is drawn except the > background, so it appears as though it's all black(ish), with trees/etc > drawn over it. The original (large) apitrace had ambient occlusion (AO) activated AFAIK, but I deleted it, so I don't know. AO was fixed for me with a patch in the last week. As my hardware is already slow (just 15fps in the game), enabling this renders the game unplayable, but now I get soft shadows at the price of ~50% frame drop. -- 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/20160119/4ccdda0e/attachment-0001.html>
[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)
https://bugs.freedesktop.org/show_bug.cgi?id=93292 --- Comment #7 from Jan-Marek Glogowski --- Created attachment 121139 --> https://bugs.freedesktop.org/attachment.cgi?id=121139&action=edit Shader without peephole optimize_CNDcc_op run Working shader -- 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/20160119/5221e70b/attachment.html>
[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)
https://bugs.freedesktop.org/show_bug.cgi?id=93292 --- Comment #6 from Jan-Marek Glogowski --- Created attachment 121138 --> https://bugs.freedesktop.org/attachment.cgi?id=121138&action=edit Shader with peephole optimize_CNDcc_op run -- 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/20160119/793941fa/attachment.html>
[Bug 93292] "Thea: The Awakening" world map textures not rendered (blue background)
https://bugs.freedesktop.org/show_bug.cgi?id=93292 --- Comment #5 from Jan-Marek Glogowski --- Created attachment 121137 --> https://bugs.freedesktop.org/attachment.cgi?id=121137&action=edit Additional debugging for the r600/sb shader compiler -- 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/20160119/f9e44be8/attachment.html>
PROBLEM: Intel HDMI output busticated on 4.4 (regression)
Hi,
Upgrading from 4.3 to 4.4 breaks my HDMI output on my G45 machine.
As soon as the intel driver is loaded, the monitor shuts off
(standby mode). Inspecting /sys/class/drm/card0-HDMI-A-1/status
reports "disconnected". When it is working, this attribute says
"connected".
There is nothing unusual printed to dmesg.
Bisection pinpoints the following:
237ed86c693d8a8e4db476976aeb30df4deac74b is the first bad commit
commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
[...]
Signed-off-by: Shashank Sharma
Signed-off-by: Sonika Jindal
Reviewed-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
The commit does not revert cleanly, but this patch resolves the issue:
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e6c035b0fc1c..8cefb9105f26 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1393,7 +1393,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_hdmi_unset_edid(connector);
- if (intel_hdmi_set_edid(connector, live_status)) {
+ if (intel_hdmi_set_edid(connector, true)) {
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
Let me know if you need any more info.
Thanks,
Nick
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #7 from andre35822 at yahoo.com --- (In reply to Michel D�nzer from comment #6) > Please run the game with the environment variable > GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load, > num-bytes-moved,buffer-wait-time,num-compilations+num-shaders-created and > attach a screenshot of the game window taken just after a freeze occurred. Um, my Linux knowledge is limited with this. I have minecraft-launcher in my /usr/bin folder, so what I did was I put the following in the terminal and hit enter /usr/share/minecraft/ GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load,num-bytes-moved,buffer-wait-time,num-compilations+num-shaders-created The game loaded up but I don't know if what you want is working. -- 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/20160119/bfbbd588/attachment.html>
[RFC 11/29] dma-buf/fence: move sync_timeline to fence_timeline
On 01/15/2016 06:55 AM, Gustavo Padovan wrote:
> /**
> + * fence_timeline_create - create a new fence_timeline
> + * @num: [in]amount of contexts to allocate
[...]
> + */
> +struct fence_timeline *fence_timeline_create(unsigned num,
> + struct fence_timeline_ops *ops,
> + int size, const char *name)
> +{
[...]
> + timeline->context = fence_context_alloc(1);
fence_context_alloc(num)
Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
when i boot the kernel and connect the HDMI cable after booting i can retrieve
4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs.
Possible relation with HPD?
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status typesize (mm) modes encoders
21 0 connected HDMI-A 0x0 4 20
modes:
name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
800x600 60 800 840 968 1056 600 601 605 628 flags: phsync, pvsync; type:
driver
800x600 56 800 824 896 1024 600 601 603 625 flags: phsync, pvsync; type:
driver
848x480 60 848 864 976 1088 480 486 494 517 flags: phsync, pvsync; type:
driver
640x480 60 640 656 752 800 480 490 492 525 flags: nhsync, nvsync; type: driver
props:
1 EDID:
flags: immutable blob
blobs:
value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
#
On 19-01-2016 16:03, Carlos Palminha wrote:
> Hi Xiang,
>
> Its returning 0 modes... :(
>
> Regards,
> C.Palminha
>
> # modetest -M drm-arcpgu -c
> Connectors:
> id encoder status typesize (mm) modes encoders
> 21 0 disconnectedHDMI-A 0x0 0 20
> props:
> 1 EDID:
> flags: immutable blob
> blobs:
>
> value:
> 2 DPMS:
> flags: enum
> enums: On=0 Standby=1 Suspend=2 Off=3
> value: 0
>
> #
>
> On 19-01-2016 03:38, Xinliang Liu wrote:
>> On 18 January 2016 at 22:45, Carlos Palminha > synopsys.com>
>> wrote:
>>
>>> I'm also getting a message from DRM saying can't find any crtc or
>>> sizes...i'm really missing something here.
>>> :(
>>>
>>> -- log --
>>> [drm] Initialized drm 1.1.0 20060810
>>> drm-arcpgu e0017000.pgu: No connectors reported connected with modes
>>> [drm] Cannot find any crtc or sizes - going 1024x768
>>> Console: switching to colour frame buffer device 128x48
>>> drm-arcpgu e0017000.pgu: fb0: frame buffer device
>>> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
>>> -- log ---
>>>
>>> Any help?
>>>
>>> Regards,
>>> C.Palminha
>>>
>>>
>>> On 18-01-2016 14:32, Carlos Palminha wrote:
Hi Xinliang,
My get_modes seems to be implemented as the rcar driver...
Probably still missing some init step?
Regards,
C.Palminha
static int arcpgu_drm_connector_get_modes(struct drm_connector
>>> *connector)
{
struct drm_encoder_slave *slave;
const struct drm_encoder_slave_funcs *sfuncs;
struct arcpgu_drm_connector * con =
container_of(connector, struct arcpgu_drm_connector, connector);
slave = con->encoder_slave;
if(slave == NULL) {
dev_err(connector->dev->dev,
"connector_get_modes: cannot find slave encoder for connector\n");
return 0;
}
sfuncs = slave->slave_funcs;
if(sfuncs->get_modes == NULL){
return 0;
}
return sfuncs->
>>> ââ
>>> get_modes(&slave->base,connector);
}
>>>
>>
>> âso, this will call adv7511 driver's â
>> â
>> get_modes call back.
>> I wonder if the system boot up, it can get modes or not.
>> You can test it with the modetest. i.e. $ modetest -M DRM_DRIVER_NAME -c
>>
>>
>>
>>
On 31-12-2015 02:19, Xinliang Liu wrote:
>
>
> On 31 December 2015 at 02:46, Carlos Palminha
> mailto:CARLOS.PALMINHA at synopsys.com>>
>>> wrote:
>
> Hi guys,
>
> I'm writing a DRM driver for a framebuffer embedded hardware that
> uses an i2c encoder (adv7511), following the basic steps suggested
> by Laurent in "anatomy of an embedded KMS driver":
> https://www.youtube.com/watch?v=Ja8fM7rTae4
>
> After initiliazing all kms, crtc, encoder, i2c, connector functions
> and structures i'm calling drm_fbdev_cma_init to create a fbdev.
>
> When booting i'm getting an error message saying "No connectors
> reported connected with modes", but the driver init is ok and i can
> find the /dev/dri/* and /dev/fb0 devices.
>
> Any clue what i might be missing during the driver load?
>
>
> âI think you should check on the 'get_modes'â call back of adv7511
> driver. (Or, if possible show us the code.)
>
> Best,
> -xinliang
>
>
> Thanks...
>
> Regards,
> C.Palminha
>
> --- boot log snippet ---
> [drm] Initialized drm 1.1.0 20060810
> drm-arcpgu e0017000.pgu: No connectors reported connected with modes
> [drm] Cannot find any crtc or sizes - going 1024x768
> Console: switching to colour frame buffer device 128x48
> drm-arcpgu e0017000.pgu: fb0: frame buffer device
> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
> --- bo
[linux-sunxi] [PATCH v2 16/26] drm: Add Allwinner A10 Display Engine support
Hi,
On Sat, Jan 16, 2016 at 05:11:44PM +0200, Priit Laes wrote:
> > +struct drm_fbdev_cma *sun4i_framebuffer_init(struct drm_device *drm)
> > +{
> > + drm_mode_config_reset(drm);
> > +
> > + drm->mode_config.max_width = 8192;
> > + drm->mode_config.max_height = 8192;
>
> Shouldn't these be 1920 x 1080 as per A10 User manual?
1080p is what the SoC can output. However, to create its output, it
uses a combination of planes of 8192x8192, that you'll obviously have
to crop. This is the size of the plane that we are exposing here, not
what we can output (which is listed in the various connectors).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/e2a63c5c/attachment.sig>
[GIT PULL] VC4 build fix.
Eric Anholt writes: > Merge tag 'drm-intel-next-fixes-2016-01-14' of > git://anongit.freedesktop.org/drm-intel into drm-next (2016-01-18 07:02:19 > +1000) > > are available in the git repository at: > > http://github.com/anholt/linux tags/drm-vc4-fixes-2015-01-19 > > for you to fetch changes up to 8483d152db61c5baf5452b844ef65b96ee9a6cfb: > > drm/vc4: Remove broken attempt at GPU reset using genpd. (2016-01-19 > 13:16:31 -0800) Apologies for the former subject, screwed up with my new pull-request scripts :/ -- 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/20160119/8bb7d72b/attachment.sig>
[GIT PULL x/y] SUBJECT HERE
Merge tag 'drm-intel-next-fixes-2016-01-14' of git://anongit.freedesktop.org/drm-intel into drm-next (2016-01-18 07:02:19 +1000) are available in the git repository at: http://github.com/anholt/linux tags/drm-vc4-fixes-2015-01-19 for you to fetch changes up to 8483d152db61c5baf5452b844ef65b96ee9a6cfb: drm/vc4: Remove broken attempt at GPU reset using genpd. (2016-01-19 13:16:31 -0800) This pull request just includes the !CONFIG_PM_SLEEP build fix for vc4. Eric Anholt (1): drm/vc4: Remove broken attempt at GPU reset using genpd. drivers/gpu/drm/vc4/vc4_v3d.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-)
[RFC 00/29] De-stage android's sync framework
2016-01-19 Daniel Vetter : > On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote: > > 2016-01-19 John Harrison : > > > > > On 19/01/2016 15:23, Gustavo Padovan wrote: > > > >Hi Daniel, > > > > > > > >2016-01-19 Daniel Vetter : > > > > > > > >>On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote: > > > >>>From: Gustavo Padovan > > > >>> > > > >>>This patch series de-stage the sync framework, and in order to > > > >>>accomplish that > > > >>>a bunch of cleanups/improvements on the sync and fence were made. > > > >>> > > > >>>The sync framework contained some abstractions around struct fence and > > > >>>those > > > >>>were removed in the de-staging process among other changes: > > > >>> > > > >>>Userspace visible changes > > > >>>- > > > >>> > > > >>> * The sw_sync file was moved from /dev/sw_sync to > > > >>> /sync/sw_sync. No > > > >>> other change. > > > >>> > > > >>>Kernel API changes > > > >>>-- > > > >>> > > > >>> * struct sync_timeline is now struct fence_timeline > > > >>> * sync_timeline_ops is now fence_timeline_ops and they now carry > > > >>> struct > > > >>> fence as parameter instead of struct sync_pt > > > >>> * a .cleanup() fence op was added to allow sync_fence to run a > > > >>> cleanup when > > > >>> the fence_timeline is destroyed > > > >>> * added fence_add_used_data() to pass a private point to struct > > > >>> fence. This > > > >>> pointer is sent back on the .cleanup op. > > > >>> * The sync timeline function were moved to be fence_timeline > > > >>> functions: > > > >>>- sync_timeline_create() -> fence_timeline_create() > > > >>>- sync_timeline_get() -> fence_timeline_get() > > > >>>- sync_timeline_put() -> fence_timeline_put() > > > >>>- sync_timeline_destroy() -> fence_timeline_destroy() > > > >>>- sync_timeline_signal() -> fence_timeline_signal() > > > >>> > > > >>> * sync_pt_create() was replaced be fence_create_on_timeline() > > > >>> > > > >>>Internal changes > > > >>> > > > >>> > > > >>> * fence_timeline_ops was removed in favor of direct use fence_ops > > > >>> * fence default functions were created for fence_ops > > > >>> * removed structs sync_pt, sw_sync_timeline and sw_sync_pt > > > >>Bunch of fairly random comments all over: > > > >> > > > >>- include/uapi/linux/sw_sync.h imo should be dropped, it's just a > > > >>private > > > >> debugfs interface between fence fds and the testsuite. Since the > > > >> plan is > > > >> to have the testcases integrated into the kernel tree too we don't > > > >> need > > > >> a public header. > > > >> > > > >>- similar for include/linux/sw_sync.h Imo that should all be moved into > > > >> sync_debug.c. Same for sw_sync.c, that should all land in sync_debug > > > >> imo, and made optional with a Kconfig option. At least we should > > > >> reuse > > > >> CONFIG_DEBUGFS. > > > >These two items sounds reasonable to me. > > > > > > I have just posted our in-progress IGT for testing i915 syncs (with a CC > > > of > > > Gustavo). It uses the sw_sync mechanisms. Can you take a quick look and > > > see > > > if it is the kind of thing you would expect us to be doing? Or is it using > > > interfaces that you are planning to remove and/or make kernel only? > > > > > > I'm not sure having a kernel only test is the best way to go. Having user > > > land tests like IGT would be much more versatile. > > > > I agree with you, we should allow IGT and other test tools to access > > sw_sync. include/linux/sw_sync.h can be kept private, but the uapi one > > needs wil be needed for testing, unless we replicate the header file > > inside IGT, but not sure if it is a good idea. > > We replicate all the debugfs stuff in igt that igt needs. uapi really only > should be stuff that's guaranteed to stick around, not debug interfaces we > are ok with breaking (if needed). Okay, that sounds quite good for me. Gustavo
[RFC 00/29] De-stage android's sync framework
On 19/01/2016 15:23, Gustavo Padovan wrote:
> Hi Daniel,
>
> 2016-01-19 Daniel Vetter :
>
>> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> This patch series de-stage the sync framework, and in order to accomplish
>>> that
>>> a bunch of cleanups/improvements on the sync and fence were made.
>>>
>>> The sync framework contained some abstractions around struct fence and those
>>> were removed in the de-staging process among other changes:
>>>
>>> Userspace visible changes
>>> -
>>>
>>> * The sw_sync file was moved from /dev/sw_sync to /sync/sw_sync.
>>> No
>>> other change.
>>>
>>> Kernel API changes
>>> --
>>>
>>> * struct sync_timeline is now struct fence_timeline
>>> * sync_timeline_ops is now fence_timeline_ops and they now carry struct
>>> fence as parameter instead of struct sync_pt
>>> * a .cleanup() fence op was added to allow sync_fence to run a cleanup
>>> when
>>> the fence_timeline is destroyed
>>> * added fence_add_used_data() to pass a private point to struct fence.
>>> This
>>> pointer is sent back on the .cleanup op.
>>> * The sync timeline function were moved to be fence_timeline functions:
>>> - sync_timeline_create() -> fence_timeline_create()
>>> - sync_timeline_get() -> fence_timeline_get()
>>> - sync_timeline_put() -> fence_timeline_put()
>>> - sync_timeline_destroy() -> fence_timeline_destroy()
>>> - sync_timeline_signal() -> fence_timeline_signal()
>>>
>>>* sync_pt_create() was replaced be fence_create_on_timeline()
>>>
>>> Internal changes
>>>
>>>
>>> * fence_timeline_ops was removed in favor of direct use fence_ops
>>> * fence default functions were created for fence_ops
>>> * removed structs sync_pt, sw_sync_timeline and sw_sync_pt
>> Bunch of fairly random comments all over:
>>
>> - include/uapi/linux/sw_sync.h imo should be dropped, it's just a private
>>debugfs interface between fence fds and the testsuite. Since the plan is
>>to have the testcases integrated into the kernel tree too we don't need
>>a public header.
>>
>> - similar for include/linux/sw_sync.h Imo that should all be moved into
>>sync_debug.c. Same for sw_sync.c, that should all land in sync_debug
>>imo, and made optional with a Kconfig option. At least we should reuse
>>CONFIG_DEBUGFS.
> These two items sounds reasonable to me.
I have just posted our in-progress IGT for testing i915 syncs (with a CC
of Gustavo). It uses the sw_sync mechanisms. Can you take a quick look
and see if it is the kind of thing you would expect us to be doing? Or
is it using interfaces that you are planning to remove and/or make
kernel only?
I'm not sure having a kernel only test is the best way to go. Having
user land tests like IGT would be much more versatile.
>> - fence_context and fence_timeline are really the same. timeline has some
>>super-basic support for doing sw-only fence timelines, but imo that's
>>not really worth keeping (and if so better to keep seperate in a
>>sw-fence.c or similar, like seqno-fence.c). The other main thing
>>timeline provides is support to clean up fences on a timeline. And imo
>>that cleanup should be done by the core fence support, not by the add-on
>>stuff.
> Yes, they are. But I currently doesn't know how to merge them best, so I
> decided to go for a RFC instead of trying some crazy solution touching
> all fence_context users.
>
>> Interlude about fence cleanup on driver unload:
>>
>> Working drivers imo should never call timeline_destroy when there's still
>> an unsignalled fence around for that timeline/context. That just means
>> they're broken and failed to clean up all the pending work. So the problem
>> really is only what to do with fences where the driver disappeared, and
>> for that we essentially need a fence_revoke() function (which could be
>> called internally from timeline_free). So here's what I think
>> timeline_free should do:
>>
>> for_each_fence_on_timel() {
>> WARN_ON(!fence_is_signalled());
>>
>> fence_revoke(fence);
>> }
>>
>> Implementing fence_revoke is a bit tricky since we need to make sure the
>> memory contained ->ops and similar stuff doesn't disappear. Simplest
>> option might be to grab a temporary reference (using
>> kref_get_unless_zero), and then exchange ->ops with one that has only a
>> release function. We don't need anything else as long as all fence_*
>> functions the kernel might call check for signalling correctly first
>> (fence_wait is broken at least).
>>
>> Or we just give up (for now) and declare module unload as slightly racy.
>> dma-buf is similar. An intermediate option might be to at least add a
>> THIS_MODULE reference to each fence (but that's a bit expensive ...).
> I'd say we just give up for now as we don't have any driver using
> timeline_destroy for now. So we could go for ot
Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status typesize (mm) modes encoders
21 0 disconnectedHDMI-A 0x0 0 20
props:
1 EDID:
flags: immutable blob
blobs:
value:
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
#
On 19-01-2016 03:38, Xinliang Liu wrote:
> On 18 January 2016 at 22:45, Carlos Palminha
> wrote:
>
>> I'm also getting a message from DRM saying can't find any crtc or
>> sizes...i'm really missing something here.
>> :(
>>
>> -- log --
>> [drm] Initialized drm 1.1.0 20060810
>> drm-arcpgu e0017000.pgu: No connectors reported connected with modes
>> [drm] Cannot find any crtc or sizes - going 1024x768
>> Console: switching to colour frame buffer device 128x48
>> drm-arcpgu e0017000.pgu: fb0: frame buffer device
>> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
>> -- log ---
>>
>> Any help?
>>
>> Regards,
>> C.Palminha
>>
>>
>> On 18-01-2016 14:32, Carlos Palminha wrote:
>>> Hi Xinliang,
>>>
>>> My get_modes seems to be implemented as the rcar driver...
>>> Probably still missing some init step?
>>>
>>> Regards,
>>> C.Palminha
>>>
>>>
>>> static int arcpgu_drm_connector_get_modes(struct drm_connector
>> *connector)
>>> {
>>> struct drm_encoder_slave *slave;
>>> const struct drm_encoder_slave_funcs *sfuncs;
>>> struct arcpgu_drm_connector * con =
>>> container_of(connector, struct arcpgu_drm_connector, connector);
>>>
>>> slave = con->encoder_slave;
>>> if(slave == NULL) {
>>> dev_err(connector->dev->dev,
>>> "connector_get_modes: cannot find slave encoder for connector\n");
>>> return 0;
>>> }
>>>
>>> sfuncs = slave->slave_funcs;
>>> if(sfuncs->get_modes == NULL){
>>> return 0;
>>> }
>>>
>>> return sfuncs->
>> ââ
>> get_modes(&slave->base,connector);
>>> }
>>>
>>
>
> âso, this will call adv7511 driver's â
> â
> get_modes call back.
> I wonder if the system boot up, it can get modes or not.
> You can test it with the modetest. i.e. $ modetest -M DRM_DRIVER_NAME -c
>
>
>
>
>>> On 31-12-2015 02:19, Xinliang Liu wrote:
On 31 December 2015 at 02:46, Carlos Palminha
mailto:CARLOS.PALMINHA at synopsys.com>>
>> wrote:
Hi guys,
I'm writing a DRM driver for a framebuffer embedded hardware that
uses an i2c encoder (adv7511), following the basic steps suggested
by Laurent in "anatomy of an embedded KMS driver":
https://www.youtube.com/watch?v=Ja8fM7rTae4
After initiliazing all kms, crtc, encoder, i2c, connector functions
and structures i'm calling drm_fbdev_cma_init to create a fbdev.
When booting i'm getting an error message saying "No connectors
reported connected with modes", but the driver init is ok and i can
find the /dev/dri/* and /dev/fb0 devices.
Any clue what i might be missing during the driver load?
âI think you should check on the 'get_modes'â call back of adv7511
driver. (Or, if possible show us the code.)
Best,
-xinliang
Thanks...
Regards,
C.Palminha
--- boot log snippet ---
[drm] Initialized drm 1.1.0 20060810
drm-arcpgu e0017000.pgu: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
Console: switching to colour frame buffer device 128x48
drm-arcpgu e0017000.pgu: fb0: frame buffer device
[drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
--- boot log snippet ---
--
To unsubscribe from this list: send the line "unsubscribe
linux-fbdev" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
[Bug 93761] A conditional discard in a fragment shader causes no depth writing at all
https://bugs.freedesktop.org/show_bug.cgi?id=93761 --- Comment #1 from Nicolai H�hnle --- Hi James, bug reports with attached test cases are awesome :) I can confirm the problem with latest Mesa and LLVM master and am going to investigate. -- 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/20160119/3c37f188/attachment.html>
[RFC 00/29] De-stage android's sync framework
2016-01-19 John Harrison : > On 19/01/2016 15:23, Gustavo Padovan wrote: > >Hi Daniel, > > > >2016-01-19 Daniel Vetter : > > > >>On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote: > >>>From: Gustavo Padovan > >>> > >>>This patch series de-stage the sync framework, and in order to accomplish > >>>that > >>>a bunch of cleanups/improvements on the sync and fence were made. > >>> > >>>The sync framework contained some abstractions around struct fence and > >>>those > >>>were removed in the de-staging process among other changes: > >>> > >>>Userspace visible changes > >>>- > >>> > >>> * The sw_sync file was moved from /dev/sw_sync to > >>> /sync/sw_sync. No > >>> other change. > >>> > >>>Kernel API changes > >>>-- > >>> > >>> * struct sync_timeline is now struct fence_timeline > >>> * sync_timeline_ops is now fence_timeline_ops and they now carry struct > >>> fence as parameter instead of struct sync_pt > >>> * a .cleanup() fence op was added to allow sync_fence to run a cleanup > >>> when > >>> the fence_timeline is destroyed > >>> * added fence_add_used_data() to pass a private point to struct fence. > >>> This > >>> pointer is sent back on the .cleanup op. > >>> * The sync timeline function were moved to be fence_timeline functions: > >>>- sync_timeline_create() -> fence_timeline_create() > >>>- sync_timeline_get() -> fence_timeline_get() > >>>- sync_timeline_put() -> fence_timeline_put() > >>>- sync_timeline_destroy() -> fence_timeline_destroy() > >>>- sync_timeline_signal() -> fence_timeline_signal() > >>> > >>> * sync_pt_create() was replaced be fence_create_on_timeline() > >>> > >>>Internal changes > >>> > >>> > >>> * fence_timeline_ops was removed in favor of direct use fence_ops > >>> * fence default functions were created for fence_ops > >>> * removed structs sync_pt, sw_sync_timeline and sw_sync_pt > >>Bunch of fairly random comments all over: > >> > >>- include/uapi/linux/sw_sync.h imo should be dropped, it's just a private > >> debugfs interface between fence fds and the testsuite. Since the plan is > >> to have the testcases integrated into the kernel tree too we don't need > >> a public header. > >> > >>- similar for include/linux/sw_sync.h Imo that should all be moved into > >> sync_debug.c. Same for sw_sync.c, that should all land in sync_debug > >> imo, and made optional with a Kconfig option. At least we should reuse > >> CONFIG_DEBUGFS. > >These two items sounds reasonable to me. > > I have just posted our in-progress IGT for testing i915 syncs (with a CC of > Gustavo). It uses the sw_sync mechanisms. Can you take a quick look and see > if it is the kind of thing you would expect us to be doing? Or is it using > interfaces that you are planning to remove and/or make kernel only? > > I'm not sure having a kernel only test is the best way to go. Having user > land tests like IGT would be much more versatile. I agree with you, we should allow IGT and other test tools to access sw_sync. include/linux/sw_sync.h can be kept private, but the uapi one needs wil be needed for testing, unless we replicate the header file inside IGT, but not sure if it is a good idea. Gustavo
[PATCH v2 09/10] dt-bindings: video: exynos5433-decon: add bindings for DECON-TV
2016ë 01ì 18ì¼ 19:12ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > On 01/18/2016 10:54 AM, Inki Dae wrote: >> >> 2016ë 01ì 18ì¼ 08:45ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸: >>> On 14.01.2016 19:49, Inki Dae wrote: + Rob Herring 2016ë 01ì 14ì¼ 19:36ì Andrzej Hajda ì´(ê°) ì´ ê¸: > Hi Inki, > > It seems this patch and 04/10 did not get picked up yet. > Could you merge it? Yes, I can. However, 04/10 is required for acked-by from dt or SoC maintainer. Krzysztof and Rob, could you give me acked-by? Thanks, Inki Dae >>> My ack is really not required, because this is a binding for a specific >>> driver from video subsystem. It does not fall into the arm/mach-exynos >>> nor the dts/*exynos*. >>> >>> Anyway I reviewed the patch on 28th of October and Rob acked it on 13th >>> of November. >> I meant 04/10 not 09/10 patch. :) > > There is document in kernel with clear explanation about the subject: > Documentation/devicetree/bindings/submitting-patches.txt. > See especially paragraph II.2 [1]. > > [1]: Documentation/devicetree/bindings/submitting-patches.txt#L50 Got it. The document says, "For driver (not subsystem) bindings: If you are comfortable with the binding, and it hasn't received an Acked-by from the devicetree maintainers after a few weeks, go ahead and take it." Thanks, Inki Dae > > Regards > Andrzej > >> >> Thanks, >> Inki Dae >> >>> Best regards, >>> Krzysztof >>> >>> > Regards > Andrzej > > On 10/26/2015 12:59 PM, Andrzej Hajda wrote: >> DECON-TV(Display and Enhancement Controller for TV) is a variation >> of DECON IP. Its main purpose is to produce video stream for HDMI IP. >> >> Signed-off-by: Andrzej Hajda >> --- >> Hi Krzysztof, >> >> I have decided to skip cleanup part as it would require more work, >> not related to this patchset. >> >> Regards >> Andrzej >> >> Documentation/devicetree/bindings/video/exynos5433-decon.txt | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git >> a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> index 3dff78b..c9fd7b3 100644 >> --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> +++ b/Documentation/devicetree/bindings/video/exynos5433-decon.txt >> @@ -5,7 +5,8 @@ Exynos series of SoCs which transfers the image data >> from a video memory >> buffer to an external LCD interface. >> >> Required properties: >> -- compatible: value should be "samsung,exynos5433-decon"; >> +- compatible: value should be one of: >> +"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; >> - reg: physical base address and length of the DECON registers set. >> - interrupts: should contain a list of all DECON IP block interrupts in >> the >>order: VSYNC, LCD_SYSTEM. The interrupt specifier format > -- > To unsubscribe from this list: send the line "unsubscribe > linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-samsung-soc" in >>> the body of a message to majordomo at vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
[Bug 80678] xrandr scaling / transform does not work with radeon
https://bugs.freedesktop.org/show_bug.cgi?id=80678 --- Comment #9 from Sebastian Wick --- It's working. Thanks, Michel! -- 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/20160119/fc5396ff/attachment.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #60 from Alex Deucher --- Can you see if disabling different dpm options helps? Try to narrow down which one(s) are problematic. E.g., this patch will disable all of them. diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 4a09947..60ed634 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -5707,10 +5707,10 @@ int ci_dpm_init(struct radeon_device *rdev) pi->mclk_activity_target = CISLAND_MCLK_TARGETACTIVITY_DFLT; - pi->sclk_dpm_key_disabled = 0; - pi->mclk_dpm_key_disabled = 0; - pi->pcie_dpm_key_disabled = 0; - pi->thermal_sclk_dpm_enabled = 0; + pi->sclk_dpm_key_disabled = 1; + pi->mclk_dpm_key_disabled = 1; + pi->pcie_dpm_key_disabled = 1; + pi->thermal_sclk_dpm_enabled = 1; /* mclk dpm is unstable on some R7 260X cards with the old mc ucode */ if ((rdev->pdev->device == 0x6658) && -- 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/20160119/86200512/attachment-0001.html>
[PATCH] drm: Promote drm_mm alignment to u64
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/gem_exec_alignment
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 37 +
include/drm/drm_mm.h | 16
2 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 66c993840f47..1095084947fa 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -93,12 +93,12 @@
static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm *mm,
u64 size,
- unsigned alignment,
+ u64 alignment,
unsigned long color,
enum drm_mm_search_flags flags);
static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct
drm_mm *mm,
u64 size,
- unsigned alignment,
+ u64 alignment,
unsigned long color,
u64 start,
u64 end,
@@ -172,7 +172,7 @@ static void drm_mm_interval_tree_add_node(struct
drm_mm_node *hole_node,
static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
-u64 size, unsigned alignment,
+u64 size, u64 alignment,
unsigned long color,
enum drm_mm_allocator_flags flags)
{
@@ -191,10 +191,9 @@ static void drm_mm_insert_helper(struct drm_mm_node
*hole_node,
adj_start = adj_end - size;
if (alignment) {
- u64 tmp = adj_start;
- unsigned rem;
+ u64 rem;
- rem = do_div(tmp, alignment);
+ div64_u64_rem(adj_start, alignment, &rem);
if (rem) {
if (flags & DRM_MM_CREATE_TOP)
adj_start -= rem;
@@ -308,7 +307,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
* 0 on success, -ENOSPC if there's no suitable hole.
*/
int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
enum drm_mm_search_flags sflags,
enum drm_mm_allocator_flags aflags)
@@ -327,7 +326,7 @@ EXPORT_SYMBOL(drm_mm_insert_node_generic);
static void drm_mm_insert_helper_range(struct drm_mm_node *hole_node,
struct drm_mm_node *node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
u64 start, u64 end,
enum drm_mm_allocator_flags flags)
@@ -352,10 +351,9 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
adj_start = adj_end - size;
if (alignment) {
- u64 tmp = adj_start;
- unsigned rem;
+ u64 rem;
- rem = do_div(tmp, alignment);
+ div64_u64_rem(adj_start, alignment, &rem);
if (rem) {
if (flags & DRM_MM_CREATE_TOP)
adj_start -= rem;
@@ -409,7 +407,7 @@ static void drm_mm_insert_helper_range(struct drm_mm_node
*hole_node,
* 0 on success, -ENOSPC if there's no suitable hole.
*/
int drm_mm_insert_node_in_range_generic(struct drm_mm *mm, struct drm_mm_node
*node,
- u64 size, unsigned alignment,
+ u64 size, u64 alignment,
unsigned long color,
u64 start, u64 end,
enum drm_mm_search_flags sflags,
@@ -473,16 +471,15 @@ void drm_mm_remove_node(struct drm_mm_node *node)
}
EXPORT_SYMBOL(drm_mm_remove_node);
-static int check_free_hole(u64 start, u64 end, u64 size, unsigned alignment)
+static int check_free_hole(u64 start, u64 end, u64 size, u64 alignment)
{
if (end - start < size)
return 0;
if (alignment) {
- u64 tmp = start;
- unsigned rem;
+ u64 re
[PATCH] drm/amdgpu: Use drm_calloc_large for VM page_tables array
Am 19.01.2016 um 09:59 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> It can be big, depending on the VM address space size, which is tunable
> via the vm_size module parameter.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721
> Signed-off-by: Michel Dänzer
I actually wanted to address this by reducing sizeof(struct
amdgpu_vm_pt), but once more never got the time to do so.
Patch is Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index aefc668..9599f75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -1282,7 +1282,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
> amdgpu_vm *vm)
> {
> const unsigned align = min(AMDGPU_VM_PTB_ALIGN_SIZE,
> AMDGPU_VM_PTE_COUNT * 8);
> - unsigned pd_size, pd_entries, pts_size;
> + unsigned pd_size, pd_entries;
> int i, r;
>
> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> @@ -1300,8 +1300,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct
> amdgpu_vm *vm)
> pd_entries = amdgpu_vm_num_pdes(adev);
>
> /* allocate page table array */
> - pts_size = pd_entries * sizeof(struct amdgpu_vm_pt);
> - vm->page_tables = kzalloc(pts_size, GFP_KERNEL);
> + vm->page_tables = drm_calloc_large(pd_entries, sizeof(struct
> amdgpu_vm_pt));
> if (vm->page_tables == NULL) {
> DRM_ERROR("Cannot allocate memory for page table array\n");
> return -ENOMEM;
> @@ -1361,7 +1360,7 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct
> amdgpu_vm *vm)
>
> for (i = 0; i < amdgpu_vm_num_pdes(adev); i++)
> amdgpu_bo_unref(&vm->page_tables[i].entry.robj);
> - kfree(vm->page_tables);
> + drm_free_large(vm->page_tables);
>
> amdgpu_bo_unref(&vm->page_directory);
> fence_put(vm->page_directory_fence);
Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver
> I think Graham summed it up pretty well :) Indeed, but there is a detail missing. The main problem for moving SI and CIK support from radeon to amdgpu is that we can't break existing userspace. Fortunately amdgpu wasn't designed from scratch, instead it's rather a evaluational successor of radeon. Because of that a lot of the internal interfaces are still the same. Additional to that I made the IOCTL numbers from Radeon and Amdgpu intentional disjoint. Amdgpu is using 0x00-0x12 and KMS on Radeon is using 0x1c-0x2d (we never supported UMS for SI/CIK). So in theory it would be possible that somebody implements a compatibility mode which provides the old Radeon IOCTLs for SI and CIK hardware generation in Amdgpu. This way we could support SI on Amdgpu as well and remove the support for SI and CIK from Radeon. The biggest differences are indeed in the multimedia area, e.g. UVD and VCE. But it's still mostly copying the Radeon code to Amdgpu (if somebody cares we could even move that into an independent module shared by both). Regards, Christian. Am 18.01.2016 um 23:19 schrieb Deucher, Alexander: >> -Original Message- >> From: Sellers, Graham >> Sent: Monday, January 18, 2016 10:38 AM >> To: alexandre.f.demers at gmail.com; Deucher, Alexander >> Cc: dri-devel >> Subject: RE: Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver >> >> Hi Alexandre, >> >> Yes, your understanding is correct. >> >> Frankly, Alex or one of the other guys on the open source team would be >> best positioned to answer your questions as to what would specifically need >> to be done. However, yes, the gap we have here is in the amdgpu kernel >> driver. I pretty much only work on the user-mode side of things. Think >> "libVulkan.so" or "vulkan.dll" - the bit that applications link to. We talk >> to our >> kernel drivers through standard interfaces. It's the kernel driver that deals >> with a lot of the differences between different parts of hardware. amdgpu is >> a ground-up redesign of our kernel solution for Linux. The closed-source >> kernel driver that we were using in our Catalyst packages has been put out to >> pasture. For the amdgpu project, given the number of engineers we have, >> we have to make a tough decision between supporting interesting new >> features of new GPUs, or sticking with pretty basic support but backporting >> to older GPUs. >> >> The differences in the graphics core itself between SI, CI and VI are >> actually >> pretty minimal (as far as the kernel driver is concerned, anyway). Where >> there are bigger differences are in things like the multimedia (video) >> engines, >> display controller, power management and so on. The radeon KMD has full >> support for all SI and CI (and earlier) "un-core" parts of the GPU. amdgpu >> has >> VI product support and some minimal (albeit disabled) support for CI, and >> basically nothing from SI. >> >> Our user-mode Vulkan driver (and closed source OpenGL driver, for that >> matter) can talk to the amdgpu kernel driver, but not to the radeon kernel >> driver. The interfaces are quite different, and honestly, the radeon kernel >> interface isn't a great fit for Vulkan. We had considered trying to support >> radeon KMD in our Vulkan driver, but it doesn't seem practical. So, it seems >> that the options would be really to port the non-core support from radeon >> KMD into amdgpu, or somehow port the new KMD interfaces to radeon >> KMD, which would allow our Vulkan drivers to run on it, but seems like a bit >> of a backwards step. >> >> There are other complications - such as it being frowned upon to have two >> kernel drivers for the same piece of hardware, so you'd need to port SI and >> CI stuff from radeon to amdgpu, and then somehow disable (or remove it) in >> the radeon KMD such that there was still only one driver for the GPU. It's >> non-trivial, but not insurmountable. Also, even though the code is there and >> working in radeon KMD, there are enough differences in the infrastructure >> that the ported support would need to be re-validated and all that stuff. >> >> If you think you're up for the challenge, we'd be appreciative of the input. >> One of the major reasons to open our code and support open source is to >> encourage involvement and contributions from the community. That's why >> we're doing the GPUOpen initiative and we will be opening a lot more of our >> software in the future. Many of the guys on our open source team initially >> got involved by contributing to the project before we hired them. That kind >> of thing looks really good on a resume. :) > I think Graham summed it up pretty well :) > > Alex > > >> Graham >> >> -Original Message- >> From: Alexandre Demers [mailto:alexandre.f.demers at gmail.com] >> Sent: Saturday, January 16, 2016 2:45 PM >> To: Deucher, Alexander; Sellers, Graham >> Cc: dri-devel >> Subject: Porting GCN pre-1.2 parts from radeon to amdgpu kernel driver >> >> Hello to both of you,
[RFC 00/29] De-stage android's sync framework
Hi Daniel,
2016-01-19 Daniel Vetter :
> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This patch series de-stage the sync framework, and in order to accomplish
> > that
> > a bunch of cleanups/improvements on the sync and fence were made.
> >
> > The sync framework contained some abstractions around struct fence and those
> > were removed in the de-staging process among other changes:
> >
> > Userspace visible changes
> > -
> >
> > * The sw_sync file was moved from /dev/sw_sync to /sync/sw_sync.
> > No
> > other change.
> >
> > Kernel API changes
> > --
> >
> > * struct sync_timeline is now struct fence_timeline
> > * sync_timeline_ops is now fence_timeline_ops and they now carry struct
> > fence as parameter instead of struct sync_pt
> > * a .cleanup() fence op was added to allow sync_fence to run a cleanup when
> > the fence_timeline is destroyed
> > * added fence_add_used_data() to pass a private point to struct fence. This
> > pointer is sent back on the .cleanup op.
> > * The sync timeline function were moved to be fence_timeline functions:
> > - sync_timeline_create() -> fence_timeline_create()
> > - sync_timeline_get() -> fence_timeline_get()
> > - sync_timeline_put() -> fence_timeline_put()
> > - sync_timeline_destroy() -> fence_timeline_destroy()
> > - sync_timeline_signal() -> fence_timeline_signal()
> >
> > * sync_pt_create() was replaced be fence_create_on_timeline()
> >
> > Internal changes
> >
> >
> > * fence_timeline_ops was removed in favor of direct use fence_ops
> > * fence default functions were created for fence_ops
> > * removed structs sync_pt, sw_sync_timeline and sw_sync_pt
>
> Bunch of fairly random comments all over:
>
> - include/uapi/linux/sw_sync.h imo should be dropped, it's just a private
> debugfs interface between fence fds and the testsuite. Since the plan is
> to have the testcases integrated into the kernel tree too we don't need
> a public header.
>
> - similar for include/linux/sw_sync.h Imo that should all be moved into
> sync_debug.c. Same for sw_sync.c, that should all land in sync_debug
> imo, and made optional with a Kconfig option. At least we should reuse
> CONFIG_DEBUGFS.
These two items sounds reasonable to me.
>
> - fence_context and fence_timeline are really the same. timeline has some
> super-basic support for doing sw-only fence timelines, but imo that's
> not really worth keeping (and if so better to keep seperate in a
> sw-fence.c or similar, like seqno-fence.c). The other main thing
> timeline provides is support to clean up fences on a timeline. And imo
> that cleanup should be done by the core fence support, not by the add-on
> stuff.
Yes, they are. But I currently doesn't know how to merge them best, so I
decided to go for a RFC instead of trying some crazy solution touching
all fence_context users.
>
> Interlude about fence cleanup on driver unload:
>
> Working drivers imo should never call timeline_destroy when there's still
> an unsignalled fence around for that timeline/context. That just means
> they're broken and failed to clean up all the pending work. So the problem
> really is only what to do with fences where the driver disappeared, and
> for that we essentially need a fence_revoke() function (which could be
> called internally from timeline_free). So here's what I think
> timeline_free should do:
>
> for_each_fence_on_timel() {
> WARN_ON(!fence_is_signalled());
>
> fence_revoke(fence);
> }
>
> Implementing fence_revoke is a bit tricky since we need to make sure the
> memory contained ->ops and similar stuff doesn't disappear. Simplest
> option might be to grab a temporary reference (using
> kref_get_unless_zero), and then exchange ->ops with one that has only a
> release function. We don't need anything else as long as all fence_*
> functions the kernel might call check for signalling correctly first
> (fence_wait is broken at least).
>
> Or we just give up (for now) and declare module unload as slightly racy.
> dma-buf is similar. An intermediate option might be to at least add a
> THIS_MODULE reference to each fence (but that's a bit expensive ...).
I'd say we just give up for now as we don't have any driver using
timeline_destroy for now. So we could go for other improvements first.
> - back to timeline vs. context: I have no idea how to best clean up this
> mess, but least painful option long-term is probably to switch over all
> current users of fence_context_alloc to timelines and remove the plain
> context interface.
Agreed.
>
> - Imo the interface in include/linux/sync.h is duplicating too much of
> fence.h. I think the only bits we need are the refcounting, creating,
> fd-install and that's it. Plus a macro to loop over all the fences in a
> sync_fence. With that drive
[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers
On 19.01.2016 01:05, Emil Velikov wrote: > > A few of those are already implicit with either Wall or Wextra. Both > of which, imho, are a must have for any serious project. I think -Wextra is generally too noisy for that, but I guess we're now deeply in arguing about taste territory. > But seriously - it makes me think that people are rushed to write the > code and get it out. Or perhaps a too strong "no warnings" policy ? > After all warnings are to hint that things can be improved/might be > wrong. If it looks trivial, just ignore it :-) One problem with that is that leaving trivial/irrelevant/incorrect warnings makes it easier to miss important warnings. That being said, I fully agree that one should resist the urge to just get rid of warnings in whatever way. (I tend to cringe whenever a commit log says something along the lines of "fix warning" â a change either fixes a problem which was pointed out by the warning, or it just silences the warning.) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/vmwgfx: respect 'nomodeset'
On Wed, Oct 15, 2014 at 5:06 PM, Thomas Hellstrom
wrote:
> On 10/15/2014 10:51 PM, Rob Clark wrote:
>> On Wed, Oct 15, 2014 at 4:44 PM, Thomas Hellstrom
>> wrote:
>>> On 10/15/2014 10:38 PM, Rob Clark wrote:
On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 4:17 PM, Thomas Hellstrom vmware.com> wrote:
>> On 10/15/2014 09:46 PM, Rob Clark wrote:
>>> On Wed, Oct 15, 2014 at 3:24 PM, Thomas Hellstrom >> vmware.com> wrote:
On 10/15/2014 09:00 PM, Rob Clark wrote:
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 18b54ac..f0267b8 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -25,6 +25,7 @@
> *
>
> **/
> #include
> +#include
>
> #include
> #include "vmwgfx_drv.h"
> @@ -1453,6 +1454,12 @@ static int vmw_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> static int __init vmwgfx_init(void)
> {
> int ret;
> +
> +#ifdef CONFIG_VGA_CONSOLE
> + if (vgacon_text_force())
> + return -EINVAL;
> +#endif
> +
Hmm,
From the function name vgacon_text_force() it sounds like this should
just stop the driver from initializing fbcon? Not refuse to load?
>>> yeah, the function is badly named.. it perhaps should be
>>> vgacon_is_text_forced() or something like that. But basically it
>>> returns whether we are forced to text mode.
>>>
>>> BR,
>>> -R
>> So then I guess it would be more correct to use the output of that
>> function when determining the value of dev_priv->enable_fb (vmwgfx can
>> enable the user-space modesetting API without turning on vmwgfx fbcon).
> well, other drivers, 'nomodeset' forces the driver not to load (to
> work around buggyness, etc).. I suppose for vmwgfx perhaps oddball
> "hardware" is less of a concern. Although it seems like it would be
> nice if vmwgfx behaved consistently with the other drivers.
>
> Most/all for the drivers have an additional module param that lets you
> override this and load the driver for UMS in case of 'nomodeset'..
> which would give you the behaviour you describe. But I think in the
> absence of an additional module param specified, the default
> 'nomodeset' behaviour should be that the driver does not load.
>
> But I can add such a module param if you think it is useful..
oh, wait.. you already have an 'enable_fbdev'.. although I guess that
is actually meaning "enable_kms"?
>>> It should actually have been "enable_fbcon_and_fbdev" instead of
>>> "enable_fbdev". KMS is always enabled with the vmwgfx driver, we have no
>>> UMS driver using DRM functionality.
>>>
>>> I think what confuses me is how "nomodeset" translates to
>>> "use_text_console", (sounds orthogonal to me) but if that's the way that
>>> parameter is presented to the drivers, I guess the correct way after all
>>> is to stop the driver from loading
>> the:
>>
>> __setup("nomodeset", text_mode);
>>
>> bit causes text_mode() to be called which sets vgacon_text_mode_force
>>
>> (assuming that was the question)
> Yes. Then IMHO whoever wrote that didn't do his homework since you can
> have user-space modesetting API and a text mode console working
> perfectly well together, but never mind.
>
>>At least users seem to expect that 'nomodeset' means don't load the
> modesetting driver, since I got a bug about it ;-) BR, -R
>
> I agree.
> Reviewed-by: Thomas Hellstrom .
>
> I'll include the patch in the next pull request.
>
btw, looks like this patch is still MIA..
BR,
-R
[PATCH] drm/amdgpu: Use drm_calloc_large for VM page_tables array
On Tue, Jan 19, 2016 at 8:03 AM, Christian König
wrote:
> Am 19.01.2016 um 09:59 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>>
>> It can be big, depending on the VM address space size, which is tunable
>> via the vm_size module parameter.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721
>> Signed-off-by: Michel Dänzer
>
>
> I actually wanted to address this by reducing sizeof(struct amdgpu_vm_pt),
> but once more never got the time to do so.
>
> Patch is Reviewed-by: Christian König
>
Applied. Thanks,
Alex
>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index aefc668..9599f75 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -1282,7 +1282,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm)
>> {
>> const unsigned align = min(AMDGPU_VM_PTB_ALIGN_SIZE,
>> AMDGPU_VM_PTE_COUNT * 8);
>> - unsigned pd_size, pd_entries, pts_size;
>> + unsigned pd_size, pd_entries;
>> int i, r;
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> @@ -1300,8 +1300,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm)
>> pd_entries = amdgpu_vm_num_pdes(adev);
>> /* allocate page table array */
>> - pts_size = pd_entries * sizeof(struct amdgpu_vm_pt);
>> - vm->page_tables = kzalloc(pts_size, GFP_KERNEL);
>> + vm->page_tables = drm_calloc_large(pd_entries, sizeof(struct
>> amdgpu_vm_pt));
>> if (vm->page_tables == NULL) {
>> DRM_ERROR("Cannot allocate memory for page table
>> array\n");
>> return -ENOMEM;
>> @@ -1361,7 +1360,7 @@ void amdgpu_vm_fini(struct amdgpu_device *adev,
>> struct amdgpu_vm *vm)
>> for (i = 0; i < amdgpu_vm_num_pdes(adev); i++)
>> amdgpu_bo_unref(&vm->page_tables[i].entry.robj);
>> - kfree(vm->page_tables);
>> + drm_free_large(vm->page_tables);
>> amdgpu_bo_unref(&vm->page_directory);
>> fence_put(vm->page_directory_fence);
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/atomic-helper: Export framebuffer_changed()
On Tue, Jan 19, 2016 at 10:46:58AM +, John Keeping wrote:
> The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
> because it has hardware counters for neither vblanks nor scanlines.
>
> In order to simplify re-implementing the functionality for this driver,
> export the framebuffer_changed() helper so it can be reused.
>
> Signed-off-by: John Keeping
> Reviewed-by: Daniel Vetter
Also ack for merging through rockchip git trees. I discussed this with
Dave Airlie, he's ok with that.
-Daniel
> ---
> Unchanged since v1.
>
> drivers/gpu/drm/drm_atomic_helper.c | 24
> include/drm/drm_atomic_helper.h | 4
> 2 files changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 268d37f..7449293 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -948,9 +948,23 @@ static void wait_for_fences(struct drm_device *dev,
> }
> }
>
> -static bool framebuffer_changed(struct drm_device *dev,
> - struct drm_atomic_state *old_state,
> - struct drm_crtc *crtc)
> +/**
> + * drm_atomic_helper_framebuffer_changed - check if framebuffer has changed
> + * @dev: DRM device
> + * @old_state: atomic state object with old state structures
> + * @crtc: DRM crtc
> + *
> + * Checks whether the framebuffer used for this CRTC changes as a result of
> + * the atomic update. This is useful for drivers which cannot use
> + * drm_atomic_helper_wait_for_vblanks() and need to reimplement its
> + * functionality.
> + *
> + * Returns:
> + * true if the framebuffer changed.
> + */
> +bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
> +struct drm_atomic_state *old_state,
> +struct drm_crtc *crtc)
> {
> struct drm_plane *plane;
> struct drm_plane_state *old_plane_state;
> @@ -967,6 +981,7 @@ static bool framebuffer_changed(struct drm_device *dev,
>
> return false;
> }
> +EXPORT_SYMBOL(drm_atomic_helper_framebuffer_changed);
>
> /**
> * drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
> @@ -1001,7 +1016,8 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> if (old_state->legacy_cursor_update)
> continue;
>
> - if (!framebuffer_changed(dev, old_state, crtc))
> + if (!drm_atomic_helper_framebuffer_changed(dev,
> + old_state, crtc))
> continue;
>
> ret = drm_crtc_vblank_get(crtc);
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index a286cce..74fce78 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -42,6 +42,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>struct drm_atomic_state *state,
>bool async);
>
> +bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
> +struct drm_atomic_state *old_state,
> +struct drm_crtc *crtc);
> +
> void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
> struct drm_atomic_state *old_state);
>
> --
> 2.7.0.226.gfe986fe
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v5] drm/rockchip: hdmi: add Innosilicon HDMI support
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Signed-off-by: Yakir Yang
---
Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)
Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)
Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode
Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
drivers/gpu/drm/rockchip/Kconfig | 8 +
drivers/gpu/drm/rockchip/Makefile| 1 +
drivers/gpu/drm/rockchip/inno_hdmi.c | 941 +++
drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++
4 files changed, 1312 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..a5014e0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,11 @@ config ROCKCHIP_DW_HDMI
for the Synopsys DesignWare HDMI driver. If you want to
enable HDMI on RK3288 based SoC, you should selet this
option.
+
+config ROCKCHIP_INNO_HDMI
+ tristate "Rockchip specific extensions for Innosilicon HDMI"
+depends on DRM_ROCKCHIP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI on RK3036 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 9e6e992..96b9db6 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
rockchip_drm_gem.o rockchip_drm_vop.o
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
new file mode 100644
index 000..4da3020
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -0,0 +1,941 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ *Yakir Yang
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "inno_hdmi.h"
+
+#define to_inno_hdmi(x)container_of(x, struct inno_hdmi, x)
+
+struct hdmi_data_info {
+ int vic;
+ bool sink_is_hdmi;
+ bool sink_has_audio;
+ unsigned int enc_in_format;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct inno_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+
+ struct mutex lock;
+ struct completion cmp;
+};
+
+struct inno_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+
+ int irq;
+ struct clk *pclk;
+ void __iomem *regs;
+
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct inno_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ unsigned int tmds_rate;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+enum {
+ CSC_ITU601_16_235_TO_RGB_0_255_8BIT,
+ CSC_ITU601_0_255_TO_RGB_0_255_8BIT,
+ CSC_ITU709_16_235_TO_RGB_0_255_8BIT,
+ CSC_RGB_0_255_TO_ITU601_16_235_8BIT,
+ CSC_RGB_0_255_TO_ITU709_16_235_8BIT,
+ CSC_RGB_0_255_TO_RGB_16_235_8BIT,
+};
+
+static const char coeff_csc[][24] = {
+ /*
+* YUV2RGB:601 SD mode(Y[16:235], UV[16:240], RGB[0:255]):
+* R = 1.164*Y + 1.596*V - 204
+* G = 1.164*Y - 0.3
[RFC 00/29] De-stage android's sync framework
On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This patch series de-stage the sync framework, and in order to accomplish that
> a bunch of cleanups/improvements on the sync and fence were made.
>
> The sync framework contained some abstractions around struct fence and those
> were removed in the de-staging process among other changes:
>
> Userspace visible changes
> -
>
> * The sw_sync file was moved from /dev/sw_sync to /sync/sw_sync. No
> other change.
>
> Kernel API changes
> --
>
> * struct sync_timeline is now struct fence_timeline
> * sync_timeline_ops is now fence_timeline_ops and they now carry struct
> fence as parameter instead of struct sync_pt
> * a .cleanup() fence op was added to allow sync_fence to run a cleanup when
> the fence_timeline is destroyed
> * added fence_add_used_data() to pass a private point to struct fence. This
> pointer is sent back on the .cleanup op.
> * The sync timeline function were moved to be fence_timeline functions:
>- sync_timeline_create() -> fence_timeline_create()
>- sync_timeline_get() -> fence_timeline_get()
>- sync_timeline_put() -> fence_timeline_put()
>- sync_timeline_destroy() -> fence_timeline_destroy()
>- sync_timeline_signal() -> fence_timeline_signal()
>
> * sync_pt_create() was replaced be fence_create_on_timeline()
>
> Internal changes
>
>
> * fence_timeline_ops was removed in favor of direct use fence_ops
> * fence default functions were created for fence_ops
> * removed structs sync_pt, sw_sync_timeline and sw_sync_pt
Bunch of fairly random comments all over:
- include/uapi/linux/sw_sync.h imo should be dropped, it's just a private
debugfs interface between fence fds and the testsuite. Since the plan is
to have the testcases integrated into the kernel tree too we don't need
a public header.
- similar for include/linux/sw_sync.h Imo that should all be moved into
sync_debug.c. Same for sw_sync.c, that should all land in sync_debug
imo, and made optional with a Kconfig option. At least we should reuse
CONFIG_DEBUGFS.
- fence_context and fence_timeline are really the same. timeline has some
super-basic support for doing sw-only fence timelines, but imo that's
not really worth keeping (and if so better to keep seperate in a
sw-fence.c or similar, like seqno-fence.c). The other main thing
timeline provides is support to clean up fences on a timeline. And imo
that cleanup should be done by the core fence support, not by the add-on
stuff.
Interlude about fence cleanup on driver unload:
Working drivers imo should never call timeline_destroy when there's still
an unsignalled fence around for that timeline/context. That just means
they're broken and failed to clean up all the pending work. So the problem
really is only what to do with fences where the driver disappeared, and
for that we essentially need a fence_revoke() function (which could be
called internally from timeline_free). So here's what I think
timeline_free should do:
for_each_fence_on_timel() {
WARN_ON(!fence_is_signalled());
fence_revoke(fence);
}
Implementing fence_revoke is a bit tricky since we need to make sure the
memory contained ->ops and similar stuff doesn't disappear. Simplest
option might be to grab a temporary reference (using
kref_get_unless_zero), and then exchange ->ops with one that has only a
release function. We don't need anything else as long as all fence_*
functions the kernel might call check for signalling correctly first
(fence_wait is broken at least).
Or we just give up (for now) and declare module unload as slightly racy.
dma-buf is similar. An intermediate option might be to at least add a
THIS_MODULE reference to each fence (but that's a bit expensive ...).
- back to timeline vs. context: I have no idea how to best clean up this
mess, but least painful option long-term is probably to switch over all
current users of fence_context_alloc to timelines and remove the plain
context interface.
- Imo the interface in include/linux/sync.h is duplicating too much of
fence.h. I think the only bits we need are the refcounting, creating,
fd-install and that's it. Plus a macro to loop over all the fences in a
sync_fence. With that drivers will only ever deal with a pile of
struct fence, making implicit fencing (using the fence list in dma-buf)
and explicit fencing (using the fence list in sync_fence) much more
similar.
And we can easily do that since no internal users ;-)
- get_timeline_name and get_driver_name are imo too much indirection, just
add ->(drv_)name field to each of these.
- struct sync_fence is a major confusion imo against struct fence. It
made much more sense in the pure-android world where fence == sync_pt.
Maybe we can rename sync_fence to sync_fence_fd (a bit long, and fd is a
bit
[PATCH v5 0/1] Introduce Innosilicon HDMI driver on Rockchip platforms
Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB - S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission (32-192kHz Fs) using IEC60958 and IEC 61937 - The EDID and CEC function are also supported by Innosilicon HDMI Transmitter Controlle Changes in v5: - Use hdmi_infoframe helper functions to packed the infoframe (Russell) - Remove the unused double wait_for_completion_timeout for ddc transfer (Russell) - Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell) Changes in v4: - Modify the commit title "drm/rockchip: hdmi: ..." (Mark) - Correct the "DKMS" to "DPMS" (Mark) - Fix over 80 characters problems (Mark) - Remove encoder .prepare/.commit helper functions, and move the vop mode configure function into encoder .enable helper functions. (Mark) Changes in v3: - Use encoder enable/disable function, and remove the encoder DPMS function - Keep HDMI PLL power on in standby mode Changes in v2: - Using DRM atomic helper functions for connector init (Mark) - Remove "hdmi->connector.encoder = encoder;" (Mark) Yakir Yang (1): drm/rockchip: hdmi: add Innosilicon HDMI support drivers/gpu/drm/rockchip/Kconfig | 8 + drivers/gpu/drm/rockchip/Makefile| 1 + drivers/gpu/drm/rockchip/inno_hdmi.c | 941 +++ drivers/gpu/drm/rockchip/inno_hdmi.h | 362 ++ 4 files changed, 1312 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h -- 1.9.1
[PATCH v4] drm/rockchip: hdmi: add Innosilicon HDMI support
Hi Russell,
Thanks for your comments :-D
On 01/19/2016 01:15 AM, Russell King - ARM Linux wrote:
> Hi,
>
> Some comments below...
>
> On Mon, Jan 18, 2016 at 10:42:20PM +0800, Yakir Yang wrote:
>> +static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi)
>> +{
>> +char info[HDMI_SIZE_AVI_INFOFRAME] = {0};
>> +int avi_color_mode;
>> +int i;
>> +
>> +hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_AVI);
>> +
>> +info[0] = 0x82;
>> +info[1] = 0x02;
>> +info[2] = 0x0D;
>> +info[3] = info[0] + info[1] + info[2];
>> +
>> +if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_RGB)
>> +avi_color_mode = AVI_COLOR_MODE_RGB;
>> +else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV444)
>> +avi_color_mode = AVI_COLOR_MODE_YCBCR444;
>> +else if (hdmi->hdmi_data.enc_out_format == HDMI_COLORSPACE_YUV422)
>> +avi_color_mode = AVI_COLOR_MODE_YCBCR422;
>> +else
>> +avi_color_mode = AVI_COLOR_MODE_RGB;
>> +
>> +info[4] = (avi_color_mode << 5);
>> +info[5] = (AVI_COLORIMETRY_NO_DATA << 6) |
>> + (AVI_CODED_FRAME_ASPECT_NO_DATA << 4) |
>> + ACTIVE_ASPECT_RATE_SAME_AS_CODED_FRAME;
>> +
>> +info[6] = 0;
>> +info[7] = hdmi->hdmi_data.vic;
>> +
>> +if (hdmi->hdmi_data.vic == 6 || hdmi->hdmi_data.vic == 7 ||
>> +hdmi->hdmi_data.vic == 21 || hdmi->hdmi_data.vic == 22)
>> +info[8] = 1;
>> +else
>> +info[8] = 0;
>> +
>> +/* Calculate avi info frame checKsum */
>> +for (i = 4; i < HDMI_SIZE_AVI_INFOFRAME; i++)
>> +info[3] += info[i];
>> +info[3] = 0x100 - info[3];
>> +
>> +for (i = 0; i < HDMI_SIZE_AVI_INFOFRAME; i++)
>> +hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i, info[i]);
>> +
>> +return 0;
> Is there a reason why the helpers in drivers/video/hdmi.c can't be used
> to generate this?
>
> hdmi_avi_infoframe_init / hdmi_avi_infoframe_pack and
> drm_hdmi_avi_infoframe_from_display_mode ?
Great, thanks for point out, it would make code much clean with those
helper functions.
>> +}
>> +
>> +static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi)
>> +{
>> +char info[HDMI_SIZE_VSI_INFOFRAME] = {0};
>> +int i;
>> +
>> +hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, m_PACKET_VSI_EN,
>> + v_PACKET_VSI_EN(0));
>> +
>> +hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_BUF_INDEX, INFOFRAME_VSI);
>> +
>> +/* Header Bytes */
>> +info[0] = 0x81;
>> +info[1] = 0x01;
>> +
>> +/* PB1 - PB3 contain the 24bit IEEE Registration Identifier */
>> +info[4] = 0x03;
>> +info[5] = 0x0c;
>> +info[6] = 0x00;
>> +
>> +/* PB4 - HDMI_Video_Format into bits 7:5 */
>> +info[7] = 0;
>> +
>> +/*
>> + * PB5 - Depending on the video format, this byte will contain
>> + * either the HDMI_VIC code in buts 7:0, OR the 3D_Structure in
>> + * bits 7:4.
>> + */
>> +info[2] = 0x06 - 2;
>> +info[8] = 0;
>> +info[9] = 0;
>> +
>> +info[3] = info[0] + info[1] + info[2];
>> +
>> +/* Calculate info frame checKsum */
>> +for (i = 4; i < HDMI_SIZE_VSI_INFOFRAME; i++)
>> +info[3] += info[i];
>> +info[3] = 0x100 - info[3];
>> +
>> +for (i = 0; i < HDMI_SIZE_VSI_INFOFRAME; i++)
>> +hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i, info[i]);
>> +
>> +hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, m_PACKET_VSI_EN,
>> + v_PACKET_VSI_EN(1));
>> +
>> +return 0;
> hdmi_vendor_infoframe_init / hdmi_vendor_infoframe_pack?
>
> You can probably use the same function to upload the control packet
> too - something like:
>
> static int inno_hdmi_upload_frame(struct inno_hdmi *hdmi, int setup_rc,
> union hdmi_infoframe *frame, u32 mask, u32 disable, u32 enable)
> {
> if (mask)
> hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, disable);
>
> if (setup_rc >= 0) {
> u8 packed_frame[YOUR_MAXIMUM_INFO_FRAME_SIZE];
> ssize_t rc, i;
>
> rc = hdmi_infoframe_pack(frame, packed_frame,
>sizeof(packed_frame));
> if (rc < 0)
> return rc;
>
> for (i = 0; i < rc; i++)
> hdmi_writeb(hdmi, HDMI_CONTROL_PACKET_ADDR + i, buf[i]);
>
> if (mask)
> hdmi_modb(hdmi, HDMI_PACKET_SEND_AUTO, mask, enable);
> }
>
> return setup_rc;
> }
>
> static int inno_hdmi_config_video_vsi(struct inno_hdmi *hdmi)
> {
> union hdmi_infoframe frame;
>
> rc = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
>the_drm_display_mode);
>
> return inno_hdmi_upload_frame(hdmi, rc, &frame, m_PACKET_VSI_EN,
> v_PACKET_VSI_EN(0), v_PACKET_VSI_EN(1));
> }
>
Ah appreciate for the code, it's great suggest, thanks.
Also
Whats missing in my new FB DRM driver... "No connectors reported connected with modes"?
On 18 January 2016 at 22:45, Carlos Palminha
wrote:
> I'm also getting a message from DRM saying can't find any crtc or
> sizes...i'm really missing something here.
> :(
>
> -- log --
> [drm] Initialized drm 1.1.0 20060810
> drm-arcpgu e0017000.pgu: No connectors reported connected with modes
> [drm] Cannot find any crtc or sizes - going 1024x768
> Console: switching to colour frame buffer device 128x48
> drm-arcpgu e0017000.pgu: fb0: frame buffer device
> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
> -- log ---
>
> Any help?
>
> Regards,
> C.Palminha
>
>
> On 18-01-2016 14:32, Carlos Palminha wrote:
> > Hi Xinliang,
> >
> > My get_modes seems to be implemented as the rcar driver...
> > Probably still missing some init step?
> >
> > Regards,
> > C.Palminha
> >
> >
> > static int arcpgu_drm_connector_get_modes(struct drm_connector
> *connector)
> > {
> > struct drm_encoder_slave *slave;
> > const struct drm_encoder_slave_funcs *sfuncs;
> > struct arcpgu_drm_connector * con =
> > container_of(connector, struct arcpgu_drm_connector, connector);
> >
> > slave = con->encoder_slave;
> > if(slave == NULL) {
> > dev_err(connector->dev->dev,
> > "connector_get_modes: cannot find slave encoder for connector\n");
> > return 0;
> > }
> >
> > sfuncs = slave->slave_funcs;
> > if(sfuncs->get_modes == NULL){
> > return 0;
> > }
> >
> > return sfuncs->
> ââ
> get_modes(&slave->base,connector);
> > }
> >
>
âso, this will call adv7511 driver's â
â
get_modes call back.
I wonder if the system boot up, it can get modes or not.
You can test it with the modetest. i.e. $ modetest -M DRM_DRIVER_NAME -c
> > On 31-12-2015 02:19, Xinliang Liu wrote:
> >>
> >>
> >> On 31 December 2015 at 02:46, Carlos Palminha
> >> mailto:CARLOS.PALMINHA at synopsys.com>>
> wrote:
> >>
> >> Hi guys,
> >>
> >> I'm writing a DRM driver for a framebuffer embedded hardware that
> >> uses an i2c encoder (adv7511), following the basic steps suggested
> >> by Laurent in "anatomy of an embedded KMS driver":
> >> https://www.youtube.com/watch?v=Ja8fM7rTae4
> >>
> >> After initiliazing all kms, crtc, encoder, i2c, connector functions
> >> and structures i'm calling drm_fbdev_cma_init to create a fbdev.
> >>
> >> When booting i'm getting an error message saying "No connectors
> >> reported connected with modes", but the driver init is ok and i can
> >> find the /dev/dri/* and /dev/fb0 devices.
> >>
> >> Any clue what i might be missing during the driver load?
> >>
> >>
> >> âI think you should check on the 'get_modes'â call back of adv7511
> >> driver. (Or, if possible show us the code.)
> >>
> >> Best,
> >> -xinliang
> >>
> >>
> >> Thanks...
> >>
> >> Regards,
> >> C.Palminha
> >>
> >> --- boot log snippet ---
> >> [drm] Initialized drm 1.1.0 20060810
> >> drm-arcpgu e0017000.pgu: No connectors reported connected with modes
> >> [drm] Cannot find any crtc or sizes - going 1024x768
> >> Console: switching to colour frame buffer device 128x48
> >> drm-arcpgu e0017000.pgu: fb0: frame buffer device
> >> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
> >> --- boot log snippet ---
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-fbdev" in
> >> the body of a message to majordomo at vger.kernel.org
> >> <mailto:majordomo at vger.kernel.org>
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/3a67df07/attachment-0001.html>
[PATCH 2/2] drm: etnaviv: add further minor features and varyings count
Hi Russell,
2016-01-19 10:18 GMT+01:00 Russell King :
> Export further minor feature bitmasks and the varyings count from
> the GPU specifications registers to userspace.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 57
> ++-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 9 ++
> include/uapi/drm/etnaviv_drm.h| 3 ++
> 3 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 483aa34fa990..74254721b446 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -72,6 +72,14 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.minor_features3;
> break;
>
> + case ETNAVIV_PARAM_GPU_FEATURES_5:
> + *value = gpu->identity.minor_features4;
> + break;
> +
> + case ETNAVIV_PARAM_GPU_FEATURES_6:
> + *value = gpu->identity.minor_features5;
> + break;
> +
> case ETNAVIV_PARAM_GPU_STREAM_COUNT:
> *value = gpu->identity.stream_count;
> break;
> @@ -112,6 +120,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.num_constants;
> break;
>
> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
> + *value = gpu->identity.varyings_count;
> + break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> @@ -124,10 +136,13 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> {
> if (gpu->identity.minor_features0 &
> chipMinorFeatures0_MORE_MINOR_FEATURES) {
> - u32 specs[2];
> + u32 specs[4];
> + unsigned int streams;
>
> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
> + specs[3] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_4);
>
> gpu->identity.stream_count =
> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
> @@ -160,6 +175,17 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> gpu->identity.num_constants =
> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
> +
> + gpu->identity.varyings_count =
> + (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> + >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
> +
> + /* This overrides the value from older register if non-zero */
> + streams =
> + (specs[3] & VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK)
> + >> VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT;
> + if (streams)
> + gpu->identity.stream_count = streams;
> }
>
> /* Fill in the stream count if not specified */
> @@ -242,6 +268,23 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>
> if (gpu->identity.num_constants == 0)
> gpu->identity.num_constants = 168;
> +
> + if (gpu->identity.varyings_count == 0) {
> + if (gpu->identity.minor_features1 & chipMinorFeatures1_HALTI0)
> + gpu->identity.varyings_count = 12;
> + else
> + gpu->identity.varyings_count = 8;
> + }
> +
> + /*
> +* For some cores, two varyings are consumed for position, so the
> +* maximum varying count needs to be reduced by one.
> +*/
> + if ((gpu->identity.model == chipModel_GC2000 &&
> +gpu->identity.revision == 0x5108) ||
> + (gpu->identity.model == chipModel_GC880 &&
> +gpu->identity.revision == 0x5106))
> + gpu->identity.varyings_count -= 1;
Should we not include the whole list of GPU cores with that special handling?
See:
https://github.com/Freescale/kernel-module-imx-gpu-viv/blob/master/kernel-module-imx-gpu-viv-src/hal/kernel/arch/gc_hal_kernel_hardware.c#L592
> }
>
> static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
> @@ -306,6 +349,8 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
> gpu->identity.minor_features1 = 0;
> gpu->identity.minor_features2 = 0;
> gpu->identity.minor_features3 = 0;
> + gpu->identity.minor_features4 = 0;
> + gpu->identity.minor_features5 = 0;
> } else
> gpu->identity.minor_features0 =
> gpu_read(gpu, VIVS_HI_CHIP_M
[PATCH 1/2] drm: etnaviv: update common and state_hi xml.h files
2016-01-19 10:18 GMT+01:00 Russell King : > Update the common and state_hi xml.h header files from the etnaviv > repository. > > Signed-off-by: Russell King > --- > drivers/gpu/drm/etnaviv/common.xml.h | 48 > -- > drivers/gpu/drm/etnaviv/state_hi.xml.h | 26 -- > 2 files changed, 64 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/etnaviv/common.xml.h > b/drivers/gpu/drm/etnaviv/common.xml.h > index 9e585d51fb78..adcb9b9b681a 100644 > --- a/drivers/gpu/drm/etnaviv/common.xml.h > +++ b/drivers/gpu/drm/etnaviv/common.xml.h > @@ -8,8 +8,8 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng > git clone git://0x04.net/rules-ng-ng > > The rules-ng-ng source files this header was generated from are: > -- state_vg.xml ( 5973 bytes, from 2015-03-25 11:26:01) > -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41) > +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53) > +- common.xml ( 18379 bytes, from 2015-12-12 09:02:53) > > Copyright (C) 2015 > */ > @@ -160,7 +160,7 @@ Copyright (C) 2015 > #define chipMinorFeatures2_UNK8 > 0x0100 > #define chipMinorFeatures2_UNK9 > 0x0200 > #define chipMinorFeatures2_UNK10 0x0400 > -#define chipMinorFeatures2_SAMPLERBASE_16 0x0800 > +#define chipMinorFeatures2_HALTI1 0x0800 > #define chipMinorFeatures2_UNK12 0x1000 > #define chipMinorFeatures2_UNK13 0x2000 > #define chipMinorFeatures2_UNK14 0x4000 > @@ -189,7 +189,7 @@ Copyright (C) 2015 > #define chipMinorFeatures3_UNK5 > 0x0020 > #define chipMinorFeatures3_UNK6 > 0x0040 > #define chipMinorFeatures3_UNK7 > 0x0080 > -#define chipMinorFeatures3_UNK8 > 0x0100 > +#define chipMinorFeatures3_FAST_MSAA 0x0100 > #define chipMinorFeatures3_UNK9 > 0x0200 > #define chipMinorFeatures3_BUG_FIXES10 0x0400 > #define chipMinorFeatures3_UNK11 0x0800 > @@ -199,7 +199,7 @@ Copyright (C) 2015 > #define chipMinorFeatures3_UNK15 0x8000 > #define chipMinorFeatures3_UNK16 0x0001 > #define chipMinorFeatures3_UNK17 0x0002 > -#define chipMinorFeatures3_UNK18 0x0004 > +#define chipMinorFeatures3_ACE 0x0004 > #define chipMinorFeatures3_UNK19 0x0008 > #define chipMinorFeatures3_UNK20 0x0010 > #define chipMinorFeatures3_UNK21 0x0020 > @@ -207,7 +207,7 @@ Copyright (C) 2015 > #define chipMinorFeatures3_UNK23 0x0080 > #define chipMinorFeatures3_UNK24 0x0100 > #define chipMinorFeatures3_UNK25 0x0200 > -#define chipMinorFeatures3_UNK26 0x0400 > +#define chipMinorFeatures3_NEW_HZ 0x0400 > #define chipMinorFeatures3_UNK27 0x0800 > #define chipMinorFeatures3_UNK28 0x1000 > #define chipMinorFeatures3_UNK29 0x2000 > @@ -229,9 +229,9 @@ Copyright (C) 2015 > #define chipMinorFeatures4_UNK13 0x2000 > #define chipMinorFeatures4_UNK14 0x4000 > #define chipMinorFeatures4_UNK15 0x8000 > -#define chipMinorFeatures4_UNK16 0x0001 > +#define chipMinorFeatures4_HALTI2 0x0001 > #define chipMinorFeatures4_UNK17 0x0002 > -#define chipMinorFeatures4_UNK18 0x0004 > +#define chipMinorFeatures4_SMALL_MSAA 0x0004 > #define chipMinorFeatures4_UNK19 0x0008 > #define chipMinorFeatures4_UNK20 0x0010 > #define chipMinorFeatures4_UNK21 0x0020 > @@ -245,5 +245,37 @@ Copyright (C) 2015 > #define chipMinorFeatures4_UNK29 0x2000 > #define chipMinorFeatures4_UNK30 0x4000 > #define chipMinorFeatures4_UNK31 0x8000 > +#define chipMinorFeatures5_UNK0 > 0x0001 > +#def
[PATCH v2 3/3] drm/rockchip: explain why we can't wait_for_vblanks
Signed-off-by: John Keeping
---
v2:
- Add more detail of the particular race that could happen if we used
drm_atomic_helper_wait_for_vblanks().
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 679d23a..cf0b7bd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -177,6 +177,21 @@ static void rockchip_crtc_wait_for_update(struct drm_crtc
*crtc)
crtc_funcs->wait_for_update(crtc);
}
+/*
+ * We can't use drm_atomic_helper_wait_for_vblanks() because rk3288 and rk3066
+ * have hardware counters for neither vblanks nor scanlines, which results in
+ * a race where:
+ * | <-- HW vsync irq and reg take effect
+ *plane_commit --> |
+ * get_vblank and wait --> |
+ * | <-- handle_vblank, vblank->count + 1
+ * cleanup_fb --> |
+ * iommu crash --> |
+ * | <-- HW vsync irq and reg take effect
+ *
+ * This function is equivalent but uses rockchip_crtc_wait_for_update() instead
+ * of waiting for vblank_count to change.
+ */
static void
rockchip_atomic_wait_for_complete(struct drm_device *dev, struct
drm_atomic_state *old_state)
{
--
2.7.0.226.gfe986fe
[PATCH v2 2/3] drm/rockchip: don't wait for vblank if fb hasn't changed
As commented in drm_atomic_helper_wait_for_vblanks(), userspace relies
on cursor ioctls being unsynced. Converting the rockchip driver to
atomic has significantly impacted cursor performance by making every
cursor update wait for vblank.
By skipping the vblank sync when the framebuffer has not changed (as is
done in drm_atomic_helper_wait_for_vblanks()) we can avoid this for the
common case of moving the cursor and only need to delay the cursor ioctl
when the cursor icon changes.
We cannot add the check on legacy_cursor_update since that results in
the cursor bo being unreferenced while the hardware may still be reading
it. Fully supporting unsynced cursor updates is left for the future
when the atomic helper framework supports async updates.
Signed-off-by: John Keeping
Tested-by: Heiko Stuebner
---
Unchanged since v1.
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index f784488..679d23a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -178,7 +178,7 @@ static void rockchip_crtc_wait_for_update(struct drm_crtc
*crtc)
}
static void
-rockchip_atomic_wait_for_complete(struct drm_atomic_state *old_state)
+rockchip_atomic_wait_for_complete(struct drm_device *dev, struct
drm_atomic_state *old_state)
{
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
@@ -194,6 +194,10 @@ rockchip_atomic_wait_for_complete(struct drm_atomic_state
*old_state)
if (!crtc->state->active)
continue;
+ if (!drm_atomic_helper_framebuffer_changed(dev,
+ old_state, crtc))
+ continue;
+
ret = drm_crtc_vblank_get(crtc);
if (ret != 0)
continue;
@@ -241,7 +245,7 @@ rockchip_atomic_commit_complete(struct
rockchip_atomic_commit *commit)
drm_atomic_helper_commit_planes(dev, state, true);
- rockchip_atomic_wait_for_complete(state);
+ rockchip_atomic_wait_for_complete(dev, state);
drm_atomic_helper_cleanup_planes(dev, state);
--
2.7.0.226.gfe986fe
[PATCH v2 1/3] drm/atomic-helper: Export framebuffer_changed()
The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
because it has hardware counters for neither vblanks nor scanlines.
In order to simplify re-implementing the functionality for this driver,
export the framebuffer_changed() helper so it can be reused.
Signed-off-by: John Keeping
Reviewed-by: Daniel Vetter
---
Unchanged since v1.
drivers/gpu/drm/drm_atomic_helper.c | 24
include/drm/drm_atomic_helper.h | 4
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 268d37f..7449293 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -948,9 +948,23 @@ static void wait_for_fences(struct drm_device *dev,
}
}
-static bool framebuffer_changed(struct drm_device *dev,
- struct drm_atomic_state *old_state,
- struct drm_crtc *crtc)
+/**
+ * drm_atomic_helper_framebuffer_changed - check if framebuffer has changed
+ * @dev: DRM device
+ * @old_state: atomic state object with old state structures
+ * @crtc: DRM crtc
+ *
+ * Checks whether the framebuffer used for this CRTC changes as a result of
+ * the atomic update. This is useful for drivers which cannot use
+ * drm_atomic_helper_wait_for_vblanks() and need to reimplement its
+ * functionality.
+ *
+ * Returns:
+ * true if the framebuffer changed.
+ */
+bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
+ struct drm_atomic_state *old_state,
+ struct drm_crtc *crtc)
{
struct drm_plane *plane;
struct drm_plane_state *old_plane_state;
@@ -967,6 +981,7 @@ static bool framebuffer_changed(struct drm_device *dev,
return false;
}
+EXPORT_SYMBOL(drm_atomic_helper_framebuffer_changed);
/**
* drm_atomic_helper_wait_for_vblanks - wait for vblank on crtcs
@@ -1001,7 +1016,8 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
if (old_state->legacy_cursor_update)
continue;
- if (!framebuffer_changed(dev, old_state, crtc))
+ if (!drm_atomic_helper_framebuffer_changed(dev,
+ old_state, crtc))
continue;
ret = drm_crtc_vblank_get(crtc);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index a286cce..74fce78 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -42,6 +42,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
struct drm_atomic_state *state,
bool async);
+bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
+ struct drm_atomic_state *old_state,
+ struct drm_crtc *crtc);
+
void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
struct drm_atomic_state *old_state);
--
2.7.0.226.gfe986fe
[PATCH v2 0/3] drm/rockchip: fix cursor performance with atomic
The first two patches are unchanged since v1 but the comment in the third has been expanded following Thierry's comments. John Keeping (3): drm/atomic-helper: Export framebuffer_changed() drm/rockchip: don't wait for vblank if fb hasn't changed drm/rockchip: explain why we can't wait_for_vblanks drivers/gpu/drm/drm_atomic_helper.c| 24 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 23 +-- include/drm/drm_atomic_helper.h| 4 3 files changed, 45 insertions(+), 6 deletions(-) -- 2.7.0.226.gfe986fe
[libdrm PATCH 2/2] configure.ac: don't detect disabled options dependencies
Hi Marcin,
On 9 January 2016 at 17:05, Marcin Ålusarz wrote:
> Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
> cunit, valgrind and cairo are still detected.
>
Doesn't this patch make 1/2 obsolete ?
> Signed-off-by: Marcin Ålusarz
Reviewed-by: Emil Velikov
> ---
> configure.ac | 36 ++--
> 1 file changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c8c4ace..cc44e3f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -400,7 +404,9 @@ AC_ARG_ENABLE([cairo-tests],
>[AS_HELP_STRING([--enable-cairo-tests],
>[Enable support for Cairo rendering in tests
> (default: auto)])],
>[CAIRO=$enableval], [CAIRO=auto])
> -PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> +if test "x$CAIRO" != xno; then
> + PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> +fi
Namely: if we have disable-cairo-tests, the module will never be
checked, thus CAIRO_{CFLAGS,LIBS} will be empty. Obviously the user
can explicitly sets the CAIRO_* variables, in which case they're
cutting the branch they're standing on.
Please let me know if you'd prefer to have 1/2 regardless (or if I
missed something)
Thank you for sorting these.
-Emil
[PATCH 2/2] drm: etnaviv: add further minor features and varyings count
On Tue, Jan 19, 2016 at 11:09:57AM +0100, Christian Gmeiner wrote: > Hi Russell, > > 2016-01-19 10:18 GMT+01:00 Russell King : > > + /* > > +* For some cores, two varyings are consumed for position, so the > > +* maximum varying count needs to be reduced by one. > > +*/ > > + if ((gpu->identity.model == chipModel_GC2000 && > > +gpu->identity.revision == 0x5108) || > > + (gpu->identity.model == chipModel_GC880 && > > +gpu->identity.revision == 0x5106)) > > + gpu->identity.varyings_count -= 1; > > Should we not include the whole list of GPU cores with that special handling? > See: > https://github.com/Freescale/kernel-module-imx-gpu-viv/blob/master/kernel-module-imx-gpu-viv-src/hal/kernel/arch/gc_hal_kernel_hardware.c#L592 I was debating about that - but I think we need to come up with a better way to do this sort of thing. At the very least, I've been wondering whether a macro such as: #define etnaviv_model_rev(gpu, mod, rev) \ ((gpu)->identity.model == chipModel_##mod && \ (gpu)->identity.revision == rev)) would help make some of this code more readable. The other thing I've been wondering is whether a table looked up by GPU model ID and/or revision ID quirks would simplify this. However, the downside with the tabular approach is that it becomes harder to compare what we have against the galcore sources. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH RFC 0/2] Add a display driver to the Allwinner H3
On Mon, 18 Jan 2016 11:18:27 +0100 Maxime Ripard wrote: > > Then, the DE2 sources contain only: > > > > All Winner Tech, All Right Reserved. 2014-2015 Copyright (c) > > > > Eventually, there is no copyright/author/history in the HDMI sources. > > That one is nasty though :/ > > It seems to be a GPL violation though, so we have two solutions: > > A) have a clean room implementation > B) Ask allwinner to comply with the license > > The former doesn't look likely to happen soon... Can you open an issue > on this on their linux github repo? Do you really think that I could have more luck than people of the linux-sunxi or pine64 teams? -- A galon | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH] drm: initialize default rotation value to DRM_ROTATE_0
On Tue, Jan 19, 2016 at 09:26:48AM +0100, Marek Szyprowski wrote:
> When no console framebuffer is enabled, the default plane state is
> defined by plane reset function. If driver uses generic helper, then
> rotation property is set to zero. This is not a valid value for that
> enum. This patch sets default rotation value to DRM_ROTATE_0.
>
> Signed-off-by: Marek Szyprowski
Applied to drm-misc.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 268d37f26960..d0d4b2ff7c21 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2526,8 +2526,10 @@ void drm_atomic_helper_plane_reset(struct drm_plane
> *plane)
> kfree(plane->state);
> plane->state = kzalloc(sizeof(*plane->state), GFP_KERNEL);
>
> - if (plane->state)
> + if (plane->state) {
> plane->state->plane = plane;
> + plane->state->rotation = BIT(DRM_ROTATE_0);
> + }
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
>
> --
> 1.9.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/2] etnaviv: add gpu param for number of varyings
2016-01-19 9:20 GMT+01:00 Lucas Stach : > Am Dienstag, den 19.01.2016, 08:05 +0100 schrieb Christian Gmeiner: >> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3. >> Userspace still needs to validate the returned values as it can be 0 >> like on the imx6q. >> > We already fix up some of those register values in the kernel if we know > they are wrong for a certain core implementation. I don't want to spread > the workarounds between kernel and userspace, but keep them in a single > place. As we already started to fix things up in the kernel, please > return the correct value for MX6Q to userspace. > I had that question too where to put that logic as there is currently some fixup logic in mesa. Will send a larger patch series later the day Greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[Bug 108221] amdgpu: mouse cursor flickers + black boxes
https://bugzilla.kernel.org/show_bug.cgi?id=108221 --- Comment #13 from Michel Dänzer --- (In reply to Fred Santos from comment #0) > The problem is present only since an update to the kernel 4.3.0-3, the first > versions of 4.3.x were OK for me. Can you find out what changed in 4.3.0-3 compared to the previous kernel you were using that worked OK? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm: initialize default rotation value to DRM_ROTATE_0
When no console framebuffer is enabled, the default plane state is
defined by plane reset function. If driver uses generic helper, then
rotation property is set to zero. This is not a valid value for that
enum. This patch sets default rotation value to DRM_ROTATE_0.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 268d37f26960..d0d4b2ff7c21 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2526,8 +2526,10 @@ void drm_atomic_helper_plane_reset(struct drm_plane
*plane)
kfree(plane->state);
plane->state = kzalloc(sizeof(*plane->state), GFP_KERNEL);
- if (plane->state)
+ if (plane->state) {
plane->state->plane = plane;
+ plane->state->rotation = BIT(DRM_ROTATE_0);
+ }
}
EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
--
1.9.2
[PATCH 1/2] etnaviv: add gpu param for number of varyings
Am Dienstag, den 19.01.2016, 08:05 +0100 schrieb Christian Gmeiner:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
We already fix up some of those register values in the kernel if we know
they are wrong for a certain core implementation. I don't want to spread
the workarounds between kernel and userspace, but keep them in a single
place. As we already started to fix things up in the kernel, please
return the correct value for MX6Q to userspace.
Thanks,
Lucas
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 37
> --
> include/uapi/drm/etnaviv_drm.h | 1 +
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 056a72e..e4f6008 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.num_constants;
> break;
>
> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
> + *value = gpu->identity.num_varyings;
> + break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> {
> if (gpu->identity.minor_features0 &
> chipMinorFeatures0_MORE_MINOR_FEATURES) {
> - u32 specs[2];
> + u32 specs[3];
>
> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>
> gpu->identity.stream_count =
> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> gpu->identity.num_constants =
> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
> +
> + gpu->identity.num_varyings =
> + (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> + >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
> }
>
> /* Fill in the stream count if not specified */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index c75d503..259012d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>
> /* Buffer size */
> u32 buffer_size;
> +
> + /* varyings count */
> + u32 num_varyings;
> };
>
> struct etnaviv_event {
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 0064f26..2dc7aa2 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
> git clone git://0x04.net/rules-ng-ng
>
> The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
> -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
> +- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
> +- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
> +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
> +- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
> +- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
> +- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
>
> Copyright (C) 2015
> */
> @@ -182,8 +186,25 @@ Copyright (C) 2015
>
> #define VIVS_HI_CHIP_MINOR_FEATURE_3 0x0088
>
> +#define VIVS_HI_CHIP_SPECS_3 0x008c
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK0x01f0
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x)
> << VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK0x0007
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x)
> << VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
> +
> #define VIVS_HI_CHIP_MINOR_FEATURE_4 0x0094
>
> +#define VIVS_HI_CHIP_SPECS_4
[PATCH 2/2] drm: etnaviv: add further minor features and varyings count
Export further minor feature bitmasks and the varyings count from
the GPU specifications registers to userspace.
Signed-off-by: Russell King
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 57 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 9 ++
include/uapi/drm/etnaviv_drm.h| 3 ++
3 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 483aa34fa990..74254721b446 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -72,6 +72,14 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
param, u64 *value)
*value = gpu->identity.minor_features3;
break;
+ case ETNAVIV_PARAM_GPU_FEATURES_5:
+ *value = gpu->identity.minor_features4;
+ break;
+
+ case ETNAVIV_PARAM_GPU_FEATURES_6:
+ *value = gpu->identity.minor_features5;
+ break;
+
case ETNAVIV_PARAM_GPU_STREAM_COUNT:
*value = gpu->identity.stream_count;
break;
@@ -112,6 +120,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
param, u64 *value)
*value = gpu->identity.num_constants;
break;
+ case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
+ *value = gpu->identity.varyings_count;
+ break;
+
default:
DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
return -EINVAL;
@@ -124,10 +136,13 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
{
if (gpu->identity.minor_features0 &
chipMinorFeatures0_MORE_MINOR_FEATURES) {
- u32 specs[2];
+ u32 specs[4];
+ unsigned int streams;
specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
+ specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
+ specs[3] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_4);
gpu->identity.stream_count =
(specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
@@ -160,6 +175,17 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
gpu->identity.num_constants =
(specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
+
+ gpu->identity.varyings_count =
+ (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
+ >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
+
+ /* This overrides the value from older register if non-zero */
+ streams =
+ (specs[3] & VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK)
+ >> VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT;
+ if (streams)
+ gpu->identity.stream_count = streams;
}
/* Fill in the stream count if not specified */
@@ -242,6 +268,23 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
if (gpu->identity.num_constants == 0)
gpu->identity.num_constants = 168;
+
+ if (gpu->identity.varyings_count == 0) {
+ if (gpu->identity.minor_features1 & chipMinorFeatures1_HALTI0)
+ gpu->identity.varyings_count = 12;
+ else
+ gpu->identity.varyings_count = 8;
+ }
+
+ /*
+* For some cores, two varyings are consumed for position, so the
+* maximum varying count needs to be reduced by one.
+*/
+ if ((gpu->identity.model == chipModel_GC2000 &&
+gpu->identity.revision == 0x5108) ||
+ (gpu->identity.model == chipModel_GC880 &&
+gpu->identity.revision == 0x5106))
+ gpu->identity.varyings_count -= 1;
}
static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
@@ -306,6 +349,8 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
gpu->identity.minor_features1 = 0;
gpu->identity.minor_features2 = 0;
gpu->identity.minor_features3 = 0;
+ gpu->identity.minor_features4 = 0;
+ gpu->identity.minor_features5 = 0;
} else
gpu->identity.minor_features0 =
gpu_read(gpu, VIVS_HI_CHIP_MINOR_FEATURE_0);
@@ -318,6 +363,10 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
gpu_read(gpu, VIVS_HI_CHIP_MINOR_FEATURE_2);
gpu->identity.minor_features3 =
gpu_read(gpu, VIVS_HI_CHIP_MINOR_FEATURE_3);
+ gpu->identity.minor_features4 =
+ gpu_read(gpu, VIVS_HI_CHIP_MINOR_FEATURE_4);
+ gpu->identity.minor_features5 =
+
[PATCH 1/2] drm: etnaviv: update common and state_hi xml.h files
Update the common and state_hi xml.h header files from the etnaviv repository. Signed-off-by: Russell King --- drivers/gpu/drm/etnaviv/common.xml.h | 48 -- drivers/gpu/drm/etnaviv/state_hi.xml.h | 26 -- 2 files changed, 64 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/common.xml.h b/drivers/gpu/drm/etnaviv/common.xml.h index 9e585d51fb78..adcb9b9b681a 100644 --- a/drivers/gpu/drm/etnaviv/common.xml.h +++ b/drivers/gpu/drm/etnaviv/common.xml.h @@ -8,8 +8,8 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng git clone git://0x04.net/rules-ng-ng The rules-ng-ng source files this header was generated from are: -- state_vg.xml ( 5973 bytes, from 2015-03-25 11:26:01) -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41) +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53) +- common.xml ( 18379 bytes, from 2015-12-12 09:02:53) Copyright (C) 2015 */ @@ -160,7 +160,7 @@ Copyright (C) 2015 #define chipMinorFeatures2_UNK8 0x0100 #define chipMinorFeatures2_UNK9 0x0200 #define chipMinorFeatures2_UNK10 0x0400 -#define chipMinorFeatures2_SAMPLERBASE_16 0x0800 +#define chipMinorFeatures2_HALTI1 0x0800 #define chipMinorFeatures2_UNK12 0x1000 #define chipMinorFeatures2_UNK13 0x2000 #define chipMinorFeatures2_UNK14 0x4000 @@ -189,7 +189,7 @@ Copyright (C) 2015 #define chipMinorFeatures3_UNK5 0x0020 #define chipMinorFeatures3_UNK6 0x0040 #define chipMinorFeatures3_UNK7 0x0080 -#define chipMinorFeatures3_UNK8 0x0100 +#define chipMinorFeatures3_FAST_MSAA 0x0100 #define chipMinorFeatures3_UNK9 0x0200 #define chipMinorFeatures3_BUG_FIXES10 0x0400 #define chipMinorFeatures3_UNK11 0x0800 @@ -199,7 +199,7 @@ Copyright (C) 2015 #define chipMinorFeatures3_UNK15 0x8000 #define chipMinorFeatures3_UNK16 0x0001 #define chipMinorFeatures3_UNK17 0x0002 -#define chipMinorFeatures3_UNK18 0x0004 +#define chipMinorFeatures3_ACE 0x0004 #define chipMinorFeatures3_UNK19 0x0008 #define chipMinorFeatures3_UNK20 0x0010 #define chipMinorFeatures3_UNK21 0x0020 @@ -207,7 +207,7 @@ Copyright (C) 2015 #define chipMinorFeatures3_UNK23 0x0080 #define chipMinorFeatures3_UNK24 0x0100 #define chipMinorFeatures3_UNK25 0x0200 -#define chipMinorFeatures3_UNK26 0x0400 +#define chipMinorFeatures3_NEW_HZ 0x0400 #define chipMinorFeatures3_UNK27 0x0800 #define chipMinorFeatures3_UNK28 0x1000 #define chipMinorFeatures3_UNK29 0x2000 @@ -229,9 +229,9 @@ Copyright (C) 2015 #define chipMinorFeatures4_UNK13 0x2000 #define chipMinorFeatures4_UNK14 0x4000 #define chipMinorFeatures4_UNK15 0x8000 -#define chipMinorFeatures4_UNK16 0x0001 +#define chipMinorFeatures4_HALTI2 0x0001 #define chipMinorFeatures4_UNK17 0x0002 -#define chipMinorFeatures4_UNK18 0x0004 +#define chipMinorFeatures4_SMALL_MSAA 0x0004 #define chipMinorFeatures4_UNK19 0x0008 #define chipMinorFeatures4_UNK20 0x0010 #define chipMinorFeatures4_UNK21 0x0020 @@ -245,5 +245,37 @@ Copyright (C) 2015 #define chipMinorFeatures4_UNK29 0x2000 #define chipMinorFeatures4_UNK30 0x4000 #define chipMinorFeatures4_UNK31 0x8000 +#define chipMinorFeatures5_UNK0 0x0001 +#define chipMinorFeatures5_UNK1 0x0002 +#define chipMinorFeatures5_UNK2 0x0004 +#define chipMinorFeatures5_UNK3
[PATCH 1/2] etnaviv: add gpu param for number of varyings
Co-incidentally, I also have a patch series along these same lines
created last night, only with all the review points already addressed.
I'll send it out momentarily.
Not quite fully tested because the VG core causes the kernel to oops
when reading /sys/kernel/debug/dri/1/gpu, but tested apart from that.
On Tue, Jan 19, 2016 at 08:05:09AM +0100, Christian Gmeiner wrote:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 37
> --
> include/uapi/drm/etnaviv_drm.h | 1 +
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 056a72e..e4f6008 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.num_constants;
> break;
>
> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
> + *value = gpu->identity.num_varyings;
> + break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> {
> if (gpu->identity.minor_features0 &
> chipMinorFeatures0_MORE_MINOR_FEATURES) {
> - u32 specs[2];
> + u32 specs[3];
>
> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>
> gpu->identity.stream_count =
> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> gpu->identity.num_constants =
> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
> +
> + gpu->identity.num_varyings =
> + (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> + >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
> }
>
> /* Fill in the stream count if not specified */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index c75d503..259012d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>
> /* Buffer size */
> u32 buffer_size;
> +
> + /* varyings count */
> + u32 num_varyings;
> };
>
> struct etnaviv_event {
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 0064f26..2dc7aa2 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
> git clone git://0x04.net/rules-ng-ng
>
> The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
> -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
> +- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
> +- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
> +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
> +- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
> +- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
> +- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
>
> Copyright (C) 2015
> */
> @@ -182,8 +186,25 @@ Copyright (C) 2015
>
> #define VIVS_HI_CHIP_MINOR_FEATURE_3 0x0088
>
> +#define VIVS_HI_CHIP_SPECS_3 0x008c
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK0x01f0
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x)
> << VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK0x0007
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x)
> << VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
> +
> #define VIVS_HI_CHIP_MINOR_FEATURE_4 0x0094
>
> +#define VIVS_HI_CHIP_SPECS_4 0x009c
> +#define VIVS_HI_CHIP_SPEC
[PATCH 2/2] etnaviv: use stream count from VIVS_HI_CHIP_SPECS_4
2016-01-19 8:05 GMT+01:00 Christian Gmeiner : > Freescales v5 kernel driver reads stream count from SPECS_4 register > and if that value is 0 it falls back to the value from CHIP_SPECS. > > Signed-off-by: Christian Gmeiner > --- > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > index e4f6008..926e369 100644 > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c > @@ -133,10 +133,17 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu) Here I am missing the specs array change - shame on me. > specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS); > specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2); > specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3); > + specs[3] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_4); > > gpu->identity.stream_count = > - (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK) > - >> VIVS_HI_CHIP_SPECS_STREAM_COUNT__SHIFT; > + (specs[3] & VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK) > + >> VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT; > + > + if (gpu->identity.stream_count == 0) > + gpu->identity.stream_count = > + (specs[0] & > VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK) > + >> > VIVS_HI_CHIP_SPECS_STREAM_COUNT__SHIFT; > + > gpu->identity.register_max = > (specs[0] & VIVS_HI_CHIP_SPECS_REGISTER_MAX__MASK) > >> VIVS_HI_CHIP_SPECS_REGISTER_MAX__SHIFT; Will send a V2 later the day. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner
[PATCH 1/2] etnaviv: add gpu param for number of varyings
2016-01-19 8:16 GMT+01:00 Ilia Mirkin :
> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
> wrote:
>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>> Userspace still needs to validate the returned values as it can be 0
>> like on the imx6q.
>>
>> Signed-off-by: Christian Gmeiner
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
>> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
>> drivers/gpu/drm/etnaviv/state_hi.xml.h | 37
>> --
>> include/uapi/drm/etnaviv_drm.h | 1 +
>> 4 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index 056a72e..e4f6008 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
>> param, u64 *value)
>> *value = gpu->identity.num_constants;
>> break;
>>
>> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
>> + *value = gpu->identity.num_varyings;
>> + break;
>> +
>> default:
>> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
>> return -EINVAL;
>> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>> {
>> if (gpu->identity.minor_features0 &
>> chipMinorFeatures0_MORE_MINOR_FEATURES) {
>> - u32 specs[2];
>> + u32 specs[3];
>>
>> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
>> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
>> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>>
>> gpu->identity.stream_count =
>> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
>> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>> gpu->identity.num_constants =
>> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
>> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
>> +
>> + gpu->identity.num_varyings =
>> + (specs[2] &
>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
>> + >>
>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
>> }
>>
>> /* Fill in the stream count if not specified */
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>> index c75d503..259012d 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>>
>> /* Buffer size */
>> u32 buffer_size;
>> +
>> + /* varyings count */
>> + u32 num_varyings;
>> };
>>
>> struct etnaviv_event {
>> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
>> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>> index 0064f26..2dc7aa2 100644
>> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
>> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
>> git clone git://0x04.net/rules-ng-ng
>>
>> The rules-ng-ng source files this header was generated from are:
>> -- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
>> -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
>> +- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
>> +- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
>> +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
>> +- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
>> +- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
>> +- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
>
> You guys should agree on a way of running headergen so that you don't
> keep adding/removing files here...
>
I have taken the updated file from https://github.com/etnaviv/etna_viv .
>>
>> Copyright (C) 2015
>> */
>> @@ -182,8 +186,25 @@ Copyright (C) 2015
>>
>> #define VIVS_HI_CHIP_MINOR_FEATURE_3 0x0088
>>
>> +#define VIVS_HI_CHIP_SPECS_3 0x008c
>> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK 0x01f0
>> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
>> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x) <<
>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) &
>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
>> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK 0x0007
>> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
>> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x) <<
>> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) &
>> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
>> +
>> #define VIVS_HI_CHIP_MINOR_FEATURE_4 0x0094
>>
>> +#define VIVS_HI_CHIP_SPECS_4
[PATCH RFC 1/2] clk: sunxi: Add sun8i display support
On Mon, 18 Jan 2016 20:09:04 +0100
Maxime Ripard wrote:
> > +static const struct clk_ops clk_sun8i_pll3_fact_ops = {
> > + .recalc_rate = sun8i_pll3_recalc_rate,
> > + .round_rate = sun8i_pll3_round_rate,
> > + .set_rate = sun8i_pll3_set_rate,
> > +};
>
> We have the clk-factors stuff to handle this easily, could you use
> that instead ?
No, the sun6i/8i pll3 offers direct 297MHz and 270MHz.
> As part of my DRM patches, I've added a clk-display clock that can
> handle that easily.
>
> And actually, as part of bringing up the display engine on the A33, I
> already did it:
> https://github.com/mripard/linux/commit/92b6843b5ee5b70cb2be3638df31d3eca28a4dba
> https://github.com/mripard/linux/commit/81e8ea74be5e72124eb584432bb79ff75f90d9ed
I don't remember any patch request from yours in the Linux
mailing-lists about these developments.
Otherwise, about this old RFC, Chen-Yu Tsai replied:
> > Add the clock types which are used by the sun8i family for video.
>
> These clocks first appeared in the A31.
>
> > Signed-off-by: Jean-Francois Moine
> > ---
> > drivers/clk/sunxi/Makefile| 1 +
> > drivers/clk/sunxi/clk-sun8i-display.c | 247
> > ++
>
> Please split this into 2 patches, and 2 files: one for PLL3, named
> clk-sun6i-pll3.c, and one for the display mod clocks, named
> clk-sun6i-display.c
My new patch series about the H3 display was sent 4 days ago
(but not sure it reached the list linux-clk at vger.kernel.org
because of some non-ASCII characters).
--
A galon | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #6 from Michel D�nzer --- Please run the game with the environment variable GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,GPU-load,num-bytes-moved,buffer-wait-time,num-compilations+num-shaders-created and attach a screenshot of the game window taken just after a freeze occurred. -- 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/20160119/febc192b/attachment.html>
[Bug 93764] [PATCH] Fix building on musl-libc
https://bugs.freedesktop.org/show_bug.cgi?id=93764 --- Comment #1 from Emil Velikov --- Hi Kylie, can you please send this to the dri-devel ML for review. I'm afraid that not many people search through bugzilla for patches. But before that please take a look at my comment [1] about select, and split off the poll change into a separate patch (rewording things alike "use the POSIX# header") Thanks P.S. Please CC me on the patches [1] http://lists.freedesktop.org/archives/dri-devel/2016-January/097833.html -- 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/20160119/ddc13b2f/attachment.html>
[PATCH 2/2] etnaviv: use stream count from VIVS_HI_CHIP_SPECS_4
Freescales v5 kernel driver reads stream count from SPECS_4 register and if that value is 0 it falls back to the value from CHIP_SPECS. Signed-off-by: Christian Gmeiner --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index e4f6008..926e369 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -133,10 +133,17 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu) specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS); specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2); specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3); + specs[3] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_4); gpu->identity.stream_count = - (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK) - >> VIVS_HI_CHIP_SPECS_STREAM_COUNT__SHIFT; + (specs[3] & VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK) + >> VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT; + + if (gpu->identity.stream_count == 0) + gpu->identity.stream_count = + (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK) + >> VIVS_HI_CHIP_SPECS_STREAM_COUNT__SHIFT; + gpu->identity.register_max = (specs[0] & VIVS_HI_CHIP_SPECS_REGISTER_MAX__MASK) >> VIVS_HI_CHIP_SPECS_REGISTER_MAX__SHIFT; -- 2.5.0
[PATCH 1/2] etnaviv: add gpu param for number of varyings
The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
Userspace still needs to validate the returned values as it can be 0
like on the imx6q.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
drivers/gpu/drm/etnaviv/state_hi.xml.h | 37 --
include/uapi/drm/etnaviv_drm.h | 1 +
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 056a72e..e4f6008 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
param, u64 *value)
*value = gpu->identity.num_constants;
break;
+ case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
+ *value = gpu->identity.num_varyings;
+ break;
+
default:
DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
return -EINVAL;
@@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
{
if (gpu->identity.minor_features0 &
chipMinorFeatures0_MORE_MINOR_FEATURES) {
- u32 specs[2];
+ u32 specs[3];
specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
+ specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
gpu->identity.stream_count =
(specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
@@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
gpu->identity.num_constants =
(specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
+
+ gpu->identity.num_varyings =
+ (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
+ >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
}
/* Fill in the stream count if not specified */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index c75d503..259012d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
/* Buffer size */
u32 buffer_size;
+
+ /* varyings count */
+ u32 num_varyings;
};
struct etnaviv_event {
diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
b/drivers/gpu/drm/etnaviv/state_hi.xml.h
index 0064f26..2dc7aa2 100644
--- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
+++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
@@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
git clone git://0x04.net/rules-ng-ng
The rules-ng-ng source files this header was generated from are:
-- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
-- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
+- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
+- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
+- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
+- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
+- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
+- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
Copyright (C) 2015
*/
@@ -182,8 +186,25 @@ Copyright (C) 2015
#define VIVS_HI_CHIP_MINOR_FEATURE_3 0x0088
+#define VIVS_HI_CHIP_SPECS_3 0x008c
+#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK 0x01f0
+#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
+#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x) <<
VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) &
VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
+#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK 0x0007
+#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
+#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x) <<
VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) &
VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
+
#define VIVS_HI_CHIP_MINOR_FEATURE_4 0x0094
+#define VIVS_HI_CHIP_SPECS_4 0x009c
+#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK
0x0001f000
+#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT 12
+#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT(x) (((x) <<
VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT) &
VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK)
+
+#define VIVS_HI_CHIP_MINOR_FEATURE_5 0x00a0
+
+#define VIVS_HI_CHIP_PRODUCT_ID
0x00a8
+
#define VIVS_PM
0x
#define
[Bug 93767] Glitches with soft shadows and MSAA in Knights of the Old Republic 2
https://bugs.freedesktop.org/show_bug.cgi?id=93767 Daniel Scharrer changed: What|Removed |Added Attachment #121127|text/plain |image/jpeg mime type|| -- 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/20160119/ac52e668/attachment.html>
[Bug 93767] Glitches with soft shadows and MSAA in Knights of the Old Republic 2
https://bugs.freedesktop.org/show_bug.cgi?id=93767 Bug ID: 93767 Summary: Glitches with soft shadows and MSAA in Knights of the Old Republic 2 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: daniel at constexpr.org QA Contact: dri-devel at lists.freedesktop.org Created attachment 121127 --> https://bugs.freedesktop.org/attachment.cgi?id=121127&action=edit Screenshot of the glitch When enabling both soft shadows and antialiasing in Knights of the Old Republic 2 [0], there are lines visible in addition to the shadows. Here is an apitrace showing the problem: http://constexpr.org/tmp/KotOR2-shadows-radeonsi.trace.xz (37 MiB) The same trace (and the game) render fine with Catalyst 15.12. Disabling either soft shadows or antialiasing also fixes the rendering. GPU: Radeon HD 7950 (TAHITI) Mesa 11.2.0-devel (git-d018619) LLVM r255414 >From what I can tell the problem first appears in e.g. draw call 1919333 in my trace - the stencil buffer has value 127 everywhere except for parts covered by the shadow volumes. The color buffer however contains jagged lines afterwards in addition to the pixels covered by the shadows. NB: The game also has fog issues like those worked around in the ATI_fs implementation [1] for the first KotOR game, but they are also present with Catalyst and even in one of the official screenshots [2] on the game's Steam store page. I think its fair to assume that that is a game bug, but if anyone wants to try it out with another driver / HW, here is another apitrace: http://constexpr.org/tmp/KotOR2-fog-radeonsi.trace.xz (35 MiB) [0] http://store.steampowered.com/app/208580/ [1] http://lists.freedesktop.org/archives/mesa-dev/2015-December/103263.html [2] http://cdn.akamai.steamstatic.com/steam/apps/208580/ss_e2043ae5d872d5576fd160acb3aa1169a5d0222c.1920x1080.jpg?t=1451421385 -- 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/20160119/e87ad644/attachment.html>
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #5 from andre35822 at yahoo.com --- (In reply to Alex Deucher from comment #4) > Those messages would not be triggered by an application. They can only be > triggered by manually changing the power state via sysfs or via a display > change event such as switching between single and multi display. I think I have messed with the power state once by following the Arch Linux wiki, though the wiki said the methods provided would not be permanent so it isn't anything that I did right? Are these errors responsible for the problems I am getting in OP? Thanks again! -- 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/20160119/71fd6aee/attachment.html>
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #4 from Alex Deucher --- Those messages would not be triggered by an application. They can only be triggered by manually changing the power state via sysfs or via a display change event such as switching between single and multi display. -- 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/20160119/3459265a/attachment.html>
[PATCH 1/2] etnaviv: add gpu param for number of varyings
On Tue, Jan 19, 2016 at 3:11 AM, Christian Gmeiner
wrote:
> 2016-01-19 8:16 GMT+01:00 Ilia Mirkin :
>> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
>> wrote:
>>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>>> Userspace still needs to validate the returned values as it can be 0
>>> like on the imx6q.
>>>
>>> Signed-off-by: Christian Gmeiner
>>> ---
>>> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
>>> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
>>> drivers/gpu/drm/etnaviv/state_hi.xml.h | 37
>>> --
>>> include/uapi/drm/etnaviv_drm.h | 1 +
>>> 4 files changed, 49 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> index 056a72e..e4f6008 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
>>> param, u64 *value)
>>> *value = gpu->identity.num_constants;
>>> break;
>>>
>>> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
>>> + *value = gpu->identity.num_varyings;
>>> + break;
>>> +
>>> default:
>>> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
>>> return -EINVAL;
>>> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>>> {
>>> if (gpu->identity.minor_features0 &
>>> chipMinorFeatures0_MORE_MINOR_FEATURES) {
>>> - u32 specs[2];
>>> + u32 specs[3];
>>>
>>> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
>>> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
>>> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>>>
>>> gpu->identity.stream_count =
>>> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
>>> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>>> gpu->identity.num_constants =
>>> (specs[1] &
>>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
>>> >>
>>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
>>> +
>>> + gpu->identity.num_varyings =
>>> + (specs[2] &
>>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
>>> + >>
>>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
>>> }
>>>
>>> /* Fill in the stream count if not specified */
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> index c75d503..259012d 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>>>
>>> /* Buffer size */
>>> u32 buffer_size;
>>> +
>>> + /* varyings count */
>>> + u32 num_varyings;
>>> };
>>>
>>> struct etnaviv_event {
>>> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> index 0064f26..2dc7aa2 100644
>>> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
>>> git clone git://0x04.net/rules-ng-ng
>>>
>>> The rules-ng-ng source files this header was generated from are:
>>> -- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
>>> -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
>>> +- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
>>> +- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
>>> +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
>>> +- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
>>> +- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
>>> +- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
>>
>> You guys should agree on a way of running headergen so that you don't
>> keep adding/removing files here...
>>
>
> I have taken the updated file from https://github.com/etnaviv/etna_viv .
I just mean that it was originally just generated for state_hi.xml,
while you have it with each file in there. It has to do with how you
run the headergen command. That's what I'm suggesting you standardize
on, so that you don't add state_2d/3d/vg and then the next commit
removes them, and then the next commit adds them, etc.
-ilia
[Bug 93748] [r600g]OpenCL driver causes ImageMagick to segfault
https://bugs.freedesktop.org/show_bug.cgi?id=93748 --- Comment #2 from nixscripter at gmail.com --- Created attachment 121124 --> https://bugs.freedesktop.org/attachment.cgi?id=121124&action=edit GenerateNoiseImage kernel Here is their kernel. It's rather ugly. It has a lot of macros (like ClamptoQuantum) and functions running on the host (mwcGenerateDifferentialNoise is elsewhere in the same file), but perhaps if it's an LLVM assembler bug those don't matter. The initialization code for the OpenCL context, by the way, is entirely separate and also rather ugly (I presume so they can load it early and "drop it in" when needed). Here is a link to the source of my exact version (which I know is old, sorry about that) so you can look at any surrounding context necessary: http://distfiles.icmpv6.org/distfiles/ImageMagick-6.9.2-6.tar.xz Note that this kernel can be found in magick/accelerate-private.h -- the error pointing to magick/accelerate.c is where the kernel is initialized. -- 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/20160119/2f9e6336/attachment.html>
[PATCH 1/2] etnaviv: add gpu param for number of varyings
On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
wrote:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3 +++
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 37
> --
> include/uapi/drm/etnaviv_drm.h | 1 +
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 056a72e..e4f6008 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32
> param, u64 *value)
> *value = gpu->identity.num_constants;
> break;
>
> + case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
> + *value = gpu->identity.num_varyings;
> + break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> {
> if (gpu->identity.minor_features0 &
> chipMinorFeatures0_MORE_MINOR_FEATURES) {
> - u32 specs[2];
> + u32 specs[3];
>
> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
> + specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>
> gpu->identity.stream_count =
> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> gpu->identity.num_constants =
> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
> +
> + gpu->identity.num_varyings =
> + (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> + >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
> }
>
> /* Fill in the stream count if not specified */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index c75d503..259012d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>
> /* Buffer size */
> u32 buffer_size;
> +
> + /* varyings count */
> + u32 num_varyings;
> };
>
> struct etnaviv_event {
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 0064f26..2dc7aa2 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
> git clone git://0x04.net/rules-ng-ng
>
> The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml ( 23420 bytes, from 2015-03-25 11:47:21)
> -- common.xml ( 18437 bytes, from 2015-03-25 11:27:41)
> +- state.xml( 18940 bytes, from 2015-12-12 08:59:16)
> +- common.xml ( 18379 bytes, from 2014-07-14 14:44:55)
> +- state_hi.xml ( 24309 bytes, from 2015-12-12 09:02:53)
> +- state_2d.xml ( 51520 bytes, from 2015-12-12 08:59:16)
> +- state_3d.xml ( 54570 bytes, from 2014-07-14 14:44:55)
> +- state_vg.xml ( 5942 bytes, from 2014-07-14 14:44:55)
You guys should agree on a way of running headergen so that you don't
keep adding/removing files here...
>
> Copyright (C) 2015
> */
> @@ -182,8 +186,25 @@ Copyright (C) 2015
>
> #define VIVS_HI_CHIP_MINOR_FEATURE_3 0x0088
>
> +#define VIVS_HI_CHIP_SPECS_3 0x008c
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK 0x01f0
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x) <<
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK 0x0007
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x) <<
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) &
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
> +
> #define VIVS_HI_CHIP_MINOR_FEATURE_4 0x0094
>
> +#define VIVS_HI_CHIP_SPECS_4 0x009c
> +#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK
> 0x0001f000
> +#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT 12
> +#define VIVS_HI_CHIP_SPECS_4_STREAM_COUN
[Bug 93762] Entire system stutters every so often when running proprietary game Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=93762 --- Comment #3 from andre35822 at yahoo.com --- (In reply to Nicolai H�hnle from comment #2) > Thanks for the report. Did the messages > > [43513.525167] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state > failed > [43982.380508] [drm:si_dpm_set_power_state [radeon]] *ERROR* > si_restrict_performance_levels_before_switch failed > > occur at the same time as the stutter? That would point at a kernel problem. No messages appeared on my screen, what I have noticed is that whenever this freezing occurs, so does my entire system essentially (I can still hear audio from Skype or Mumble but I can't interact with things)...however those messages seem familiar..ahh I know. I think I have seen those messages occasionally show up on my screen when I log out/log back in. I think I started getting this since the 4.1 kernels I am not really sure what I can do to further help you but please let me know! Although, this portion is offtopic. I have another machine with an AMD 6570 or something and those messages would occasionally show up on Linux Mint 17.1 and the kernel that one uses is 3.18. -- 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/20160119/cec43906/attachment.html>
[PATCH 1/3] of: Add United Radiant Technology Corporation vendor prefix
On 25.11.2015 16:07, Thierry Reding wrote: > On Wed, Oct 07, 2015 at 10:59:53PM +0200, Maciej S. Szmigiero wrote: >> This adds vendor prefix for United Radiant Technology Corporation, >> a provider of liquid crystal display technologies. >> >> Signed-off-by: Maciej Szmigiero >> --- >> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt >> b/Documentation/devicetree/bindings/vendor-prefixes.txt >> index 82d2ac9..01e3cee 100644 >> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt >> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt >> @@ -223,6 +223,7 @@ toshiba Toshiba Corporation >> toumaz Toumaz >> tplink TP-LINK Technologies Co., Ltd. >> truly Truly Semiconductors Limited >> +urt United Radiant Technology Corporation >> usi Universal Scientific Industrial Co., Ltd. >> v3 V3 Semiconductor >> variscite Variscite Ltd. > > Hi Rob, > > Acked-by on this? > > Thierry Is it possible to get ack/nak on this prefix? This change has been pending since last October... Best regards, Maciej Szmigiero
