[PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access
2016ë
08ì 16ì¼ 01:02ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding rendering (or just query the current status of
>> rendering). The dma-buf sync ioctl allows userspace to prepare the
>> dma-buf for CPU access, which should include waiting upon rendering.
>> (Some drivers may need to do more work to ensure that the dma-buf mmap
>> is coherent as well as complete.)
>>
>> v2: Always wait upon the reservation object implicitly. We choose to do
>> it after the native handler in case it can do so more efficiently.
>>
>> Testcase: igt/prime_vgem
>> Testcase: igt/gem_concurrent_blit # *vgem*
>> Signed-off-by: Chris Wilson
>> Cc: Sumit Semwal
>> Cc: Daniel Vetter
>> Cc: Eric Anholt
>> Cc: linux-media at vger.kernel.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: linaro-mm-sig at lists.linaro.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>> drivers/dma-buf/dma-buf.c | 23 +++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index ddaee60ae52a..cf04d249a6a4 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
>> *attach,
>> }
>> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>
>> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> + enum dma_data_direction direction)
>> +{
>> +bool write = (direction == DMA_BIDIRECTIONAL ||
>> + direction == DMA_TO_DEVICE);
>> +struct reservation_object *resv = dmabuf->resv;
>> +long ret;
>> +
>> +/* Wait on any implicit rendering fences */
>> +ret = reservation_object_wait_timeout_rcu(resv, write, true,
>> + MAX_SCHEDULE_TIMEOUT);
>> +if (ret < 0)
>> +return ret;
>> +
>> +return 0;
>> +}
>>
>> /**
>> * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf
>> from the
>> @@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> if (dmabuf->ops->begin_cpu_access)
>> ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
>>
>> +/* Ensure that all fences are waited upon - but we first allow
>> + * the native handler the chance to do so more efficiently if it
>> + * chooses. A double invocation here will be reasonably cheap no-op.
>> + */
>> +if (ret == 0)
>> +ret = __dma_buf_begin_cpu_access(dmabuf, direction);
>
> Not sure we should wait first and the flush or the other way round. But I
> don't think it'll matter for any current dma-buf exporter, so meh.
>
Sorry for late comment. I wonder there is no problem in case that GPU or other
DMA device tries to access this dma buffer after dma_buf_begin_cpu_access call.
I think in this case, they - GPU or DMA devices - would make a mess of the dma
buffer while CPU is accessing the buffer.
This patch is in mainline already so if this is real problem then I think we
sould choose,
1. revert this patch from mainline
2. make sure to prevent other DMA devices to try to access the buffer while CPU
is accessing the buffer.
Thanks.
> Reviewed-by: Daniel Vetter
>
> Sumits, can you pls pick this one up and put into drm-misc?
> -Daniel
>
>> +
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>> --
>> 2.8.1
>>
>
[Bug 99138] Xorg can't be restarted gracefully running CEDAR graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=99138 Michel Dänzer changed: What|Removed |Added QA Contact|xorg-team at lists.x.org | Component|Driver/Radeon |DRM/Radeon Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|DRI --- Comment #1 from Michel Dänzer --- You mentioned on IRC that a "radeon_cs:0 process" prevents the system from rebooting. I assume that's the radeonsi command stream submission thread of the Xorg process being stuck somewhere in the kernel due to the GPU hang. If you try rebooting and wait for a few minutes, do backtraces of the stuck task show up in dmesg? If so, please attach those here. (It may be possible to get backtraces without waiting via some Sysrq key combination) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/4a292871/attachment.html>
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 John Brooks changed: What|Removed |Added CC||bugs.freedesktop at fastquake. ||com --- Comment #1 from John Brooks --- Created attachment 128536 --> https://bugs.freedesktop.org/attachment.cgi?id=128536&action=edit Bisect log I just bisected the regression that has been affecting my R9 290 for a long time. I ended up at the same commit as Furkan: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7050c6ef5f0e9bc5e6bf9eb035320b70f731b919 I also observed the same radeon_pm_info debug output: On good commits: uvddisabled vcedisabled power level avgsclk: 10 mclk: 126000 On bad commits: uvddisabled vcedisabled power level avgsclk: 10 mclk: 15000 Please let me know if you need any more information, or if you want me to test something for you. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/f2b1564a/attachment.html>
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 John Brooks changed: What|Removed |Added Attachment #128536|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/d6407f7c/attachment.html>
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 --- Comment #2 from John Brooks --- Commenting out http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/radeon_uvd.c?id=7050c6ef5f0e9bc5e6bf9eb035320b70f731b919#n130 or removing /lib/firmware/radeon/bonaire_uvd.bin fixes the problem on my system. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/932d3934/attachment-0001.html>
[PATCH 1/2] drm: exynos: Perform initialization/cleanup at probe/remove time
2016ë 12ì 18ì¼ 07:12ì Laurent Pinchart ì´(ê°) ì´ ê¸: > Hello Inki, > > On Saturday 17 Dec 2016 09:33:31 Inki Dae wrote: >> HI, >> >> Thanks for patch. Reasonable to me and go to misc excepting below one thing. >> Please check my comment. >> >> 2016-12-14 4:34 GMT+09:00 Laurent Pinchart: >>> From: Laurent Pinchart >>> >>> The drm driver .load() operation is prone to race conditions as it >>> initializes the driver after registering the device nodes. Its usage is >>> deprecated, inline it in the probe function and call drm_dev_alloc() and >>> drm_dev_register() explicitly. >>> >>> For consistency inline the .unload() handler in the remove function as >>> well. >>> >>> Signed-off-by: Laurent Pinchart >>> --- >>> >>> drivers/gpu/drm/exynos/exynos_dp.c | 1 - >>> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 1 - >>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 245 - >>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 - >>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 1 - >>> drivers/gpu/drm/exynos/exynos_hdmi.c | 1 - >>> 6 files changed, 127 insertions(+), 123 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c >>> b/drivers/gpu/drm/exynos/exynos_dp.c index 528229faffe4..b839f065f4b3 >>> 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_dp.c >>> +++ b/drivers/gpu/drm/exynos/exynos_dp.c >>> @@ -102,7 +102,6 @@ static int exynos_dp_bridge_attach(struct >>> analogix_dp_plat_data *plat_data,> >>> struct drm_encoder *encoder = &dp->encoder; >>> int ret; >>> >>> - drm_connector_register(connector); >> >> You removed above function from encoder and connector drivers.Is >> removing this required? >> And is this related to this patch? If not so, it seems this change >> should go to another patch with the reason to remove this function >> call. > > When using the .load() callback, driver initialization is performed from > drm_dev_register() after the DRM device gets registered with sysfs. With this > patch driver initialization is moved before drm_dev_register(), and > registering connectors manually would then trigger a WARN due to the sysfs > parent not being registered yet. > > The connectors are registered by the DRM core (drm_modeset_register_all() > called from drm_dev_register()), so there's no need to register them manually > after drm_dev_register(), we can just drop that code. > Acked-by: Inki Dae Thanks, Inki Dae
[PATCH 0/6] diagrams for drm docs
Hi all, So this is my first stab at doing some overview diagrams for drm. Pretty much like what it looks like, both input and output. Well there's one layout issue where I couldn't convince DOT to do what I want it to do. All based on Markus' kernel-figures script. I think the script needs a bit more work&polish, but I'm probably not the best one to do that. I can take a stab at improving things a bit, but I think better if Jani/Jon/Markus help out here. Cheers, Daniel Daniel Vetter (5): HACKS: pass stderr along in kfigure.py drm/doc: Add KMS overview graphs drm/doc: Consistent kerneldoc include order drm/doc: diagram for mode objects and properties drm/doc: atomic overview, with graph Markus Heiser (1): docs-rst: automatically convert Graphviz and SVG images Documentation/conf.py | 2 +- Documentation/doc-guide/hello.dot | 3 + Documentation/doc-guide/sphinx.rst| 90 +- Documentation/doc-guide/svg_image.svg | 10 + Documentation/gpu/drm-internals.rst | 6 +- Documentation/gpu/drm-kms-helpers.rst | 28 +- Documentation/gpu/drm-kms.rst | 269 -- Documentation/gpu/drm-mm.rst | 24 +- Documentation/process/changes.rst | 8 +- Documentation/sphinx/kfigure.py | 511 ++ 10 files changed, 903 insertions(+), 48 deletions(-) create mode 100644 Documentation/doc-guide/hello.dot create mode 100644 Documentation/doc-guide/svg_image.svg create mode 100644 Documentation/sphinx/kfigure.py -- 2.11.0
[PATCH 2/6] HACKS: pass stderr along in kfigure.py
Some addition comments on the implementation: - Also needs to be hacked up for svg conversion. - Inline kernel-render creates temp files and caches them, doesn't seem that good an idea. Probably should switch over to using pipes. - Reimplements sphinx' depency tracking. Might be fixable if we just use pipes (and using the sphinx functions to open/read files). - Linenumbers are off, but no idea how to fix that. - Script looks a bit complicated to me, but I don't have python clue. Signed-off-by: Daniel Vetter --- Documentation/sphinx/kfigure.py | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 76425b461a40..d6819337edf6 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -50,6 +50,7 @@ import os from os import path import subprocess from hashlib import sha1 +import sys from docutils import nodes from docutils.statemachine import ViewList @@ -278,11 +279,16 @@ def dot2format(dot_fname, out_fname): """ out_format = path.splitext(out_fname)[1][1:] -cmd = [dot_cmd, '-T%s' % out_format, dot_fname] +cmd = [dot_cmd, '-T%s' % out_format, dot_fname, '-v'] exit_code = 42 with open(out_fname, "w") as out: -exit_code = subprocess.call( +p = subprocess.Popen( cmd, stdout = out, stderr = subprocess.PIPE ) +meh, err = p.communicate() + +sys.stderr.write(err) + +exit_code = p.returncode out.flush() return bool(exit_code == 0) -- 2.11.0
[PATCH] drm/doc: atomic overview, with graph
I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.
One thing I failed at is getting DOT to layout the overview graph how
I want it. The highlevel structure I want is:
Free-standing State
Current State
i.e. one over the other. Currently it lays it out side-by-side, but
not even that really - "Current State" is somewhat offset below. Makes
the graph look like garbage, and also way too wide for proper
rendering. Ideas appreciated.
Cc: Laurent Pinchart
Cc: Harry Wentland
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 2 +
Documentation/gpu/drm-kms.rst | 85 ++-
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 050ebe81d256..ac53c0b893f6 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -42,6 +42,8 @@ Modeset Helper Reference for Common Vtables
.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
:internal:
+.. _drm_atomic_helper:
+
Atomic Modeset Helper Functions Reference
=
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 07d288fa37b2..35c41cf84a1b 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -189,8 +189,91 @@ multiple times to different objects using
:c:func:`drm_object_attach_property()
.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
:export:
+Atomic Mode Setting
+===
+
+
+.. FIXME: The I want the below graph to be laid out so that the 2 subgraph
+ clusters are below each another. But I failed.
+
+.. kernel-render:: DOT
+ :alt: Mode Objects and Properties
+ :caption: Mode Objects and Properties
+
+ digraph {
+ node [shape=box]
+
+ subgraph cluster_state {
+ style=dashed
+ label="Free-standing state"
+
+ "drm_atomic_state" -> "duplicated drm_plane_state A"
+ "drm_atomic_state" -> "duplicated drm_plane_state B"
+ "drm_atomic_state" -> "duplicated drm_crtc_state"
+ "drm_atomic_state" -> "duplicated drm_connector_state"
+ "drm_atomic_state" -> "duplicated driver private state"
+ }
+
+ subgraph cluster_current {
+ style=dashed
+ label="Current state"
+
+ "drm_device" -> "drm_plane A"
+ "drm_device" -> "drm_plane B"
+ "drm_device" -> "drm_crtc"
+ "drm_device" -> "drm_connector"
+ "drm_device" -> "driver private object"
+
+ "drm_plane A" -> "drm_plane_state A"
+ "drm_plane B" -> "drm_plane_state B"
+ "drm_crtc" -> "drm_crtc_state"
+ "drm_connector" -> "drm_connector_state"
+ "driver private object" -> "driver private state"
+ }
+
+ "drm_atomic_state" -> "drm_device" [label="atomic_commit"]
+ }
+
+Essentially atomic is transactional modeset (including planes) updates, but
+compared to the usual transactional approach of try-commit and rollback on
+failure atomic modesetting is a bit different:
+
+- Firstly, no hardware changes are allowed when the commit would fail. This
+ allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
+ userspace to explore whether certain configurations would work or not.
+
+- This would still allows setting and rollback of just the software state,
+ simplifying conversion of existing drivers. But auditing drivers for
+ correctness of the atomic_check code because really hard with that.
+
+- Lastly, for backwards compatibility and to support all use-cases, atomic
+ updates need to be incremental and be able to execute in parallel. Hardware
+ doesn't always allow it, but where possible plane updates on different CRTCs
+ should not interfere, and not get stalled due to output routing changing on
+ different CRTCs.
+
+Taken all together there's two consequence for the atomic design:
+
+- The overall state is split up into per-object state structures:
+ :c:type:`struct drm_plane_state ` for planes,
:c:type:`struct
+ drm_crtc_state ` for CRTCs and :c:type:`struct
+ drm_connector_state `
+ container. Again drivers can subclass that container for their own state
+ structure tracking needs. Only when a state is commit is it applied to the
+ driver and modeset objects. This way rolling back an update boils down to
+ releasing memory and unreference objects like framebuffers.
+
+Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
+coverage of specific topics.
+
Atomic Mode Setting Function Reference
-==
+--
.. kernel-doc:: include/drm/drm_atomic.h
:internal:
--
2.11.0
[PATCH 4/6] drm/doc: Consistent kerneldoc include order
First overview text (if there is any), then headers (since generally you want to start out with the data structures), then all the other stuff with functions. Most of this is pre-shpinx, since with the old docbook only the overview stuff was pulled in directly. Everything else was put in a per-section index, so include order didn't really matter. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst | 6 +++--- Documentation/gpu/drm-kms-helpers.rst | 22 +++--- Documentation/gpu/drm-kms.rst | 30 +++--- Documentation/gpu/drm-mm.rst | 24 4 files changed, 41 insertions(+), 41 deletions(-) diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index e35920db1f4c..29d6bf7bb1ac 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -140,12 +140,12 @@ Device Instance and Driver Handling .. kernel-doc:: drivers/gpu/drm/drm_drv.c :doc: driver instance overview -.. kernel-doc:: drivers/gpu/drm/drm_drv.c - :export: - .. kernel-doc:: include/drm/drm_drv.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_drv.c + :export: + Driver Load --- diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 012b6ff3ec3f..050ebe81d256 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -37,10 +37,10 @@ Modeset Helper Reference for Common Vtables === .. kernel-doc:: include/drm/drm_modeset_helper_vtables.h - :internal: + :doc: overview .. kernel-doc:: include/drm/drm_modeset_helper_vtables.h - :doc: overview + :internal: Atomic Modeset Helper Functions Reference = @@ -84,27 +84,27 @@ Legacy CRTC/Modeset Helper Functions Reference Simple KMS Helper Reference === +.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c + :doc: overview + .. kernel-doc:: include/drm/drm_simple_kms_helper.h :internal: .. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c :export: -.. kernel-doc:: drivers/gpu/drm/drm_simple_kms_helper.c - :doc: overview - fbdev Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c :doc: fbdev helpers -.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c - :export: - .. kernel-doc:: include/drm/drm_fb_helper.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_fb_helper.c + :export: + Framebuffer CMA Helper Functions Reference == @@ -146,15 +146,15 @@ Bridge Helper Reference Panel Helper Reference == +.. kernel-doc:: drivers/gpu/drm/drm_panel.c + :doc: drm panel + .. kernel-doc:: include/drm/drm_panel.h :internal: .. kernel-doc:: drivers/gpu/drm/drm_panel.c :export: -.. kernel-doc:: drivers/gpu/drm/drm_panel.c - :doc: drm panel - Display Port Helper Functions Reference === diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 2bdd266da4a9..05a346492e07 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -152,12 +152,12 @@ panels are still in-flux and not really fully sorted out yet. KMS Core Structures and Functions = -.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c - :export: - .. kernel-doc:: include/drm/drm_mode_config.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c + :export: + Modeset Base Object Abstraction === @@ -170,21 +170,21 @@ Modeset Base Object Abstraction Atomic Mode Setting Function Reference == -.. kernel-doc:: drivers/gpu/drm/drm_atomic.c - :export: - .. kernel-doc:: include/drm/drm_atomic.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_atomic.c + :export: + CRTC Abstraction -.. kernel-doc:: drivers/gpu/drm/drm_crtc.c - :export: - .. kernel-doc:: include/drm/drm_crtc.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :export: + Frame Buffer Abstraction @@ -194,12 +194,12 @@ Frame Buffer Abstraction Frame Buffer Functions Reference -.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c - :export: - .. kernel-doc:: include/drm/drm_framebuffer.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_framebuffer.c + :export: + DRM Format Handling === @@ -502,8 +502,8 @@ operation handler. Vertical Blanking and Interrupt Handling Functions Reference -.. kernel-doc:: drivers/gpu/drm/drm_irq.c - :export: - .. kernel-doc:: include/drm/drm_irq.h :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_irq.c + :export: diff --
[PATCH 1/6] docs-rst: automatically convert Graphviz and SVG images
From: Markus Heiser
This patch brings scalable figure, image handling and a concept to
embed *render* markups:
* DOT (http://www.graphviz.org)
* SVG
For image handling use the 'image' replacement::
.. kernel-image:: svg_image.svg
:alt:simple SVG image
For figure handling use the 'figure' replacement::
.. kernel-figure:: svg_image.svg
:alt:simple SVG image
SVG image example
Embed *render* markups (or languages) like Graphviz's **DOT** is
provided by the *render* directive.::
.. kernel-render:: DOT
:alt: foobar digraph
:caption: Embedded **DOT** (Graphviz) code.
digraph foo {
"bar" -> "baz";
}
The *render* directive is a concept to integrate *render* markups and
languages, yet supported markups:
* DOT: render embedded Graphviz's **DOT**
* SVG: render embedded Scalable Vector Graphics (**SVG**)
v2: s/DOC/DOT/ in a few places.
Cc: Jonathan Corbet
Cc: linux-doc at vger.kernel.org
Cc: Jani Nikula
Cc: Mauro Carvalho Chehab
Signed-off-by: Markus Heiser (v1)
Signed-off-by: Daniel Vetter
---
Documentation/conf.py | 2 +-
Documentation/doc-guide/hello.dot | 3 +
Documentation/doc-guide/sphinx.rst| 90 +-
Documentation/doc-guide/svg_image.svg | 10 +
Documentation/process/changes.rst | 8 +-
Documentation/sphinx/kfigure.py | 505 ++
6 files changed, 612 insertions(+), 6 deletions(-)
create mode 100644 Documentation/doc-guide/hello.dot
create mode 100644 Documentation/doc-guide/svg_image.svg
create mode 100644 Documentation/sphinx/kfigure.py
diff --git a/Documentation/conf.py b/Documentation/conf.py
index bb5a9082598d..23f291a8f857 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure']
# The name of the math extension changed on Sphinx 1.4
if major == 1 and minor > 3:
diff --git a/Documentation/doc-guide/hello.dot
b/Documentation/doc-guide/hello.dot
new file mode 100644
index ..504621dfc595
--- /dev/null
+++ b/Documentation/doc-guide/hello.dot
@@ -0,0 +1,3 @@
+graph G {
+ Hello -- World
+}
diff --git a/Documentation/doc-guide/sphinx.rst
b/Documentation/doc-guide/sphinx.rst
index 532d65b70500..b902744ce7dd 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -34,8 +34,10 @@ format-specific subdirectories under
``Documentation/output``.
To generate documentation, Sphinx (``sphinx-build``) must obviously be
installed. For prettier HTML output, the Read the Docs Sphinx theme
-(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is
also
-needed. All of these are widely available and packaged in distributions.
+(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
+``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively ``convert(1)``
+from ImageMagick (https://www.imagemagick.org). All of these are widely
+available and packaged in distributions.
To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose
@@ -232,3 +234,87 @@ Rendered as:
* .. _`last row`:
- column 3
+
+
+Figures & Images
+
+
+If you want to add an image, you should use the ``kernel-figure`` and
+``kernel-image`` directives. E.g. to insert a figure with a scalable
+image format use SVG::
+
+.. kernel-figure:: svg_image.svg
+ :alt:simple SVG image
+
+ SVG image example
+
+.. kernel-figure:: svg_image.svg
+ :alt:simple SVG image
+
+ SVG image example
+
+The kernel figure (and image) directive support **DOT** formated files, see
+
+* DOT: http://graphviz.org/pdf/dotguide.pdf
+* Graphviz: http://www.graphviz.org/content/dot-language
+
+A simple example::
+
+ .. kernel-figure:: hello.dot
+ :alt:hello world
+
+ DOT's hello world example
+
+.. kernel-figure:: hello.dot
+ :alt:hello world
+
+ DOT's hello world example
+
+Embed *render* markups (or languages) like Graphviz's **DOT** is provided by
the
+``kernel-render`` directives.::
+
+ .. kernel-render:: DOT
+ :alt: foobar digraph
+ :caption: Embedded **DOT** (Graphviz) code.
+
+ digraph foo {
+ "bar" -> "baz";
+ }
+
+How this will be rendered depends on the installed tools. If Graphviz is
+installed, you will see an vector image. If not the raw markup is inserted as
+*literal-block*.
+
+.. kernel-render:: DOT
+ :alt: foobar digraph
+ :caption: Embedded **DOT** (Graphviz) code.
+
+ digraph foo {
+ "bar" -> "baz";
+ }
+
+The *render* directive has all the option
[PATCH 5/6] drm/doc: diagram for mode objects and properties
Resulted in confusion a few times in the past.
Cc: Laurent Pinchart
Cc: Manasi Navare
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms.rst | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 05a346492e07..07d288fa37b2 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -161,6 +161,28 @@ KMS Core Structures and Functions
Modeset Base Object Abstraction
===
+.. kernel-render:: DOT
+ :alt: Mode Objects and Properties
+ :caption: Mode Objects and Properties
+
+ digraph {
+ node [shape=box]
+
+ "drm_property A" -> "drm_mode_object A"
+ "drm_property A" -> "drm_mode_object B"
+ "drm_property B" -> "drm_mode_object A"
+ }
+
+The base structure for all KMS objects is :c:type:`struct drm_mode_object
+`. One of the base services is provides is tracking
properties,
+which are especially important for the atomic IOCTL (see `Atomic Mode
+Setting`_). The somewhat surprising part here is that properties are not
+directly instantiated on each object, but free-standing mode objects
themselves,
+represented by :c:type:`struct drm_property `, which only specify
+the type and value range of a property. Any given property can be attached
+multiple times to different objects using :c:func:`drm_object_attach_property()
+`.
+
.. kernel-doc:: include/drm/drm_mode_object.h
:internal:
--
2.11.0
[PATCH 6/6] drm/doc: atomic overview, with graph
I want to split up a few more things and document some details better
(like how exactly to subclass drm_atomic_state). And maybe also split
up the helpers a bit per-topic, but this should be a ok-ish start for
better atomic overview.
One thing I failed at is getting DOT to layout the overview graph how
I want it. The highlevel structure I want is:
Free-standing State
Current State
i.e. one over the other. Currently it lays it out side-by-side, but
not even that really - "Current State" is somewhat offset below. Makes
the graph look like garbage, and also way too wide for proper
rendering. Ideas appreciated.
Cc: Laurent Pinchart
Cc: Harry Wentland
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 2 +
Documentation/gpu/drm-kms.rst | 85 ++-
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 050ebe81d256..ac53c0b893f6 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -42,6 +42,8 @@ Modeset Helper Reference for Common Vtables
.. kernel-doc:: include/drm/drm_modeset_helper_vtables.h
:internal:
+.. _drm_atomic_helper:
+
Atomic Modeset Helper Functions Reference
=
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 07d288fa37b2..35c41cf84a1b 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -189,8 +189,91 @@ multiple times to different objects using
:c:func:`drm_object_attach_property()
.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
:export:
+Atomic Mode Setting
+===
+
+
+.. FIXME: The I want the below graph to be laid out so that the 2 subgraph
+ clusters are below each another. But I failed.
+
+.. kernel-render:: DOT
+ :alt: Mode Objects and Properties
+ :caption: Mode Objects and Properties
+
+ digraph {
+ node [shape=box]
+
+ subgraph cluster_state {
+ style=dashed
+ label="Free-standing state"
+
+ "drm_atomic_state" -> "duplicated drm_plane_state A"
+ "drm_atomic_state" -> "duplicated drm_plane_state B"
+ "drm_atomic_state" -> "duplicated drm_crtc_state"
+ "drm_atomic_state" -> "duplicated drm_connector_state"
+ "drm_atomic_state" -> "duplicated driver private state"
+ }
+
+ subgraph cluster_current {
+ style=dashed
+ label="Current state"
+
+ "drm_device" -> "drm_plane A"
+ "drm_device" -> "drm_plane B"
+ "drm_device" -> "drm_crtc"
+ "drm_device" -> "drm_connector"
+ "drm_device" -> "driver private object"
+
+ "drm_plane A" -> "drm_plane_state A"
+ "drm_plane B" -> "drm_plane_state B"
+ "drm_crtc" -> "drm_crtc_state"
+ "drm_connector" -> "drm_connector_state"
+ "driver private object" -> "driver private state"
+ }
+
+ "drm_atomic_state" -> "drm_device" [label="atomic_commit"]
+ }
+
+Essentially atomic is transactional modeset (including planes) updates, but
+compared to the usual transactional approach of try-commit and rollback on
+failure atomic modesetting is a bit different:
+
+- Firstly, no hardware changes are allowed when the commit would fail. This
+ allows us to implement the DRM_MODE_ATOMIC_TEST_ONLY mode, which allows
+ userspace to explore whether certain configurations would work or not.
+
+- This would still allows setting and rollback of just the software state,
+ simplifying conversion of existing drivers. But auditing drivers for
+ correctness of the atomic_check code because really hard with that.
+
+- Lastly, for backwards compatibility and to support all use-cases, atomic
+ updates need to be incremental and be able to execute in parallel. Hardware
+ doesn't always allow it, but where possible plane updates on different CRTCs
+ should not interfere, and not get stalled due to output routing changing on
+ different CRTCs.
+
+Taken all together there's two consequence for the atomic design:
+
+- The overall state is split up into per-object state structures:
+ :c:type:`struct drm_plane_state ` for planes,
:c:type:`struct
+ drm_crtc_state ` for CRTCs and :c:type:`struct
+ drm_connector_state `
+ container. Again drivers can subclass that container for their own state
+ structure tracking needs. Only when a state is commit is it applied to the
+ driver and modeset objects. This way rolling back an update boils down to
+ releasing memory and unreference objects like framebuffers.
+
+Read on in this chapter, and also in :ref:`drm_atomic_helper` for more detailed
+coverage of specific topics.
+
Atomic Mode Setting Function Reference
-==
+--
.. kernel-doc:: include/drm/drm_atomic.h
:internal:
--
2.11.0
[PATCH 3/6] drm/doc: Add KMS overview graphs
Oh, the shiny and pretties!
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 4 ++
Documentation/gpu/drm-kms.rst | 132 ++
2 files changed, 136 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa14fe8..012b6ff3ec3f 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -114,6 +114,8 @@ Framebuffer CMA Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_fb_cma_helper.c
:export:
+.. _drm_bridges:
+
Bridges
===
@@ -139,6 +141,8 @@ Bridge Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:
+.. _drm_panel_helper:
+
Panel Helper Reference
==
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 0c9abdc0ee31..2bdd266da4a9 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -17,6 +17,138 @@ be setup by initializing the following fields.
Mode Configuration
+Overview
+
+
+.. kernel-render:: DOT
+ :alt: KMS Display Pipeline
+ :caption: KMS Display Pipeline Overview
+
+ digraph "KMS" {
+ node [shape=box]
+
+ subgraph cluster_static {
+ style=dashed
+ label="Static Objects"
+
+ node [bgcolor=grey style=filled]
+ "drm_plane A" -> "drm_crtc"
+ "drm_plane B" -> "drm_crtc"
+ "drm_crtc" -> "drm_encoder A"
+ "drm_crtc" -> "drm_encoder B"
+ }
+
+ subgraph cluster_user_created {
+ style=dashed
+ label="Userspace-Created"
+
+ node [shape=oval]
+ "drm_framebuffer 1" -> "drm_plane A"
+ "drm_framebuffer 2" -> "drm_plane B"
+ }
+
+ subgraph cluster_connector {
+ style=dashed
+ label="Hotpluggable"
+
+ "drm_encoder A" -> "drm_connector A"
+ "drm_encoder B" -> "drm_connector B"
+ }
+ }
+
+The basic object structure KMS presents to userspace is fairly simple.
+Framebuffers (represented by :c:type:`struct drm_framebuffer
`,
+see `Frame Buffer Abstraction`_) feed into planes. Multiple (or just one, or
+even no) planes feed their pixel data into a CRTC (represented by
+:c:type:`struct drm_crtc `, see `CRTC Abstraction`_) for blending.
The
+precise blending step is explained in more detail in `Plane Composition
+Properties`_ and related chapter.
+
+For the output routing the first step are Encoders (represented by
+:c:type:`struct drm_encoder `, see `Encoder Abstraction`_). Those
+are really just internal artifacts of the helper libraries used to implement
KMS
+drivers. But unfortunately encoders have been exposed to userspace. Besides
that
+they make it unecessarily more complicated for userspace to figure out which
+connections between a CRTC and a connector, and what kind of cloning is
+supported, they serve no purpose in the userspace API. Futhermore the exposed
+restrictions are often wrongly set by drivers, and in many cases not powerful
+enough to express the real restrictions. A CRTC can be connected to multiple
+Encoders, but for an active CRTC there must be at least one encoder.
+
+The final, and real, endpoint in the display chain is the connector
(represented
+by :c:type:`struct drm_connector `, see `Connector
+Abstraction`_). Connectors can have different possible encoders, but the kernel
+driver does this selection. The use case is DVI, which could switch between an
+analog and a digital encoder. There is only ever one active connector for any
+encoder.
+
+Internally the output pipeline is a bit more complex and matches todays
hardware
+more closely:
+
+.. kernel-render:: DOT
+ :alt: KMS Output Pipeline
+ :caption: KMS Output Pipeline
+
+ digraph "Output Pipeline" {
+ node [shape=box]
+
+ subgraph {
+ "drm_crtc" [bgcolor=grey style=filled]
+ }
+
+ subgraph cluster_internal {
+ style=dashed
+ label="Internal Pipeline"
+ {
+ node [bgcolor=grey style=filled]
+ "drm_encoder A";
+ "drm_encoder B";
+ "drm_encoder C";
+ }
+
+ {
+ node [bgcolor=grey style=filled]
+ "drm_encoder B" -> "drm_bridge B"
+ "drm_encoder C" -> "drm_bridge C1"
+ "drm_bridge C1" -> "drm_bridge C2";
+ }
+ }
+
+ "drm_crtc" -> "drm_encoder A"
+ "drm_crtc" -> "drm_encoder B"
+ "drm_crtc" -> "drm_encoder C"
+
+
+ subgraph cluster_output {
+ style=dashed
+ label="Outputs"
+
+ "drm_encoder A" -> "drm_connector A";
+ "drm_bridge B" -> "drm_connector B";
+ "drm_bridge C2" -> "drm_connector C";
+
+ "drm_panel"
+ }
+ }
+
+Internally two additional helper objects come into play. First, to be able to
+share code for encoders (sometimes on the same SoC, sometimes off-chip)
[PATCH v2 2/3] drm/edid: Implement SCDC support detection
Thanks Thierry and Daniel for concluding this discussion, while I was on vacation. Here are the next steps, which I am planning to go for (Please correct me if my understanding is not right) - Shashank to review first of the SCDC patch, and give comments or R-B. - Shashank to work on Thierry's review comments on HF-VSDB parsing patch (including creation of a sub-class nested drm_hdmi_info within drm_display_info) and publish V2 - Thierry/Daniel to review V2 and give comments or R-B Regards Shashank -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Tuesday, December 6, 2016 1:49 PM To: Thierry Reding Cc: Daniel Vetter ; Sharma, Shashank ; Jose Abreu ; dri-devel at lists.freedesktop.org Subject: Re: [PATCH v2 2/3] drm/edid: Implement SCDC support detection On Mon, Dec 05, 2016 at 06:11:44PM +0100, Thierry Reding wrote: > On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote: > > On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote: > > > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote: > > > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote: > > > > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote: > > > > > > Hi Thierry, > > > > > > > > > > > > If you can please have a look on this patch, I had written one to > > > > > > parse HF-VSDB, which was covering SCDC detection too. > > > > > > https://patchwork.kernel.org/patch/9452259/ > > > > > > > > > > I think there had been pushback before about caching > > > > > capabilities from EDID, so from that point of view my patch is > > > > > more inline with existing EDID parsing API. > > > > > > > > Hm, where was that pushback? We do have a bit a mess between > > > > explicitly parsing stuff (e.g. eld) and stuffing parsed data into > > > > drm_display_info. > > > > > > You did object to a very similar patch some time ago that did a > > > similar thing for DPCD stuff. And also Villa had commented on an > > > earlier patch from Jose about concerns of bloating core structures: > > > > > > https://patchwork.freedesktop.org/patch/104806/ > > > > DPCD I complained about because somehow we ended up with 2 sets of > > helpers, one filling a struct and the others returning directly. I > > objected to the fact that there's 2 (and imo your patch duplicated > > even more), not that I think one approach is clearly inferior to the other. > > My recollection is that I had proposed that I do the work of > transitioning users of the parsers to the cached information but you > had said that it wasn't worth the churn and that we should just go > with the existing scheme of passing around the DPCD buffer and > extending the parsers as necessary. Hm, I guess it wasn't clear to me that you've offered to do all the conversions. Doing that would be awesome I think (but quite a bit of work), and if we bother with it, parsing into a struct is imo the better idea long-term. > From that I inferred that the same would be true for EDID and since we > already have a couple of helpers that operate on struct edid * and > which return features, continuing that scheme was preferred. > > Anyway, I don't really care either way. Maybe you and Ville can duke > it out whether or not we want all of the fields parsed, irrespective > of whether or not they will be used. Then I'll go with whatever you decide. > > > Demanding that there's some real users is also a valid point. > > > > > > I think long-term stuffing it into drm_display_info is probably > > > > better, since then we only have 1 interaction point between the > > > > probe code and the atomic_check code. That should be useful for > > > > eventually fixing the lack of locking between the two, if I ever > > > > get around to that ;-) > > > > > > I don't really have objections to caching the results of parsing, > > > it's what I had proposed and what seemed most natural back when I > > > was working on the DPCD helpers. But if we now agree that this is > > > the preferred way to do things, then we should at least agree that > > > it applies to all areas for the sake of consistency. > > > > > > Also, it might be worth looking into improving the structures, and > > > maybe adding new ones to order things more conveniently or at > > > least group them in some logical way. In my opinion some of our > > > data structures are becoming somewhat... unwieldy. > > > > We're pretty good at consuming fairly invasive refactorings in drm-misc. > > So it just boils down to get some agreement on what things should > > look like (+1 from my side to parsing stuff into structs as a > > general idea), and then massaging all the existing users of the > > "wrong" interface using cocci and sed. > > > > Unfortunately "just" ;-) > > I think by now it would be useful to have a nested structure within > struct drm_display_info that contains HDMI specific bits. We already > have a numb
[PATCH] drm: Remove the struct drm_device platformdev field
On 12/18/16 00:39, Laurent Pinchart wrote: > The field contains a pointer to the parent platform device of the DRM > device. As struct drm_device also contains a dev pointer to the struct > device embedded in the platform_device structure, the platformdev field > is redundant. Remove it and use the dev pointer directly. > > Signed-off-by: Laurent Pinchart Acked-by: Jyri Sarha > --- > drivers/gpu/drm/armada/armada_drv.c | 3 +-- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 5 ++--- > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 -- > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c| 2 +- > drivers/gpu/drm/msm/msm_drv.c | 1 - > drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +-- > drivers/gpu/drm/sti/sti_drv.c | 2 -- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - > include/drm/drmP.h | 1 - > 11 files changed, 7 insertions(+), 17 deletions(-)
[PATCH v4.1 14/22] drm: omapdrm: Keep vblank interrupt enabled while CRTC is active
On 18/12/16 04:12, Laurent Pinchart wrote: > Instead of going through a complicated private IRQ registration > mechanism, handle the vblank interrupt activation with the standard > drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let > the DRM core keep the vblank interrupt enabled as long as needed to > update the frame counter. > > Signed-off-by: Laurent Pinchart > --- > Changes since v4: > > - Fix race condition between .atomic_flush() and vblank IRQ > - Make sure WARN_ON() don't have side effects > --- > drivers/gpu/drm/omapdrm/omap_crtc.c | 79 > - > drivers/gpu/drm/omapdrm/omap_drv.h | 1 + > drivers/gpu/drm/omapdrm/omap_irq.c | 4 +- > 3 files changed, 37 insertions(+), 47 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/64911a0f/attachment.sig>
[PATCH v2 1/4] DRM: add help to get ELD speaker allocation
On Wed, 14 Dec 2016, Arnaud Pouliquen wrote:
> Add helper to allow users to retrieve the speaker allocations without
> knowledge of the ELD structure.
>
> Signed-off-by: Arnaud Pouliquen
For this one patch,
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_edid.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 919933d..0706cc6 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -245,6 +245,7 @@ struct detailed_timing {
> # define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
>
> #define DRM_ELD_SPEAKER 7
> +# define DRM_ELD_SPEAKER_MASK0x7f
> # define DRM_ELD_SPEAKER_RLRC(1 << 6)
> # define DRM_ELD_SPEAKER_FLRC(1 << 5)
> # define DRM_ELD_SPEAKER_RC (1 << 4)
> @@ -412,6 +413,18 @@ static inline int drm_eld_size(const uint8_t *eld)
> }
>
> /**
> + * drm_eld_get_spk_alloc - Get speaker allocation
> + * @eld: pointer to an ELD memory structure
> + *
> + * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
> + * field definitions to identify speakers.
> + */
> +static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
> +{
> + return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
> +}
> +
> +/**
> * drm_eld_get_conn_type - Get device type hdmi/dp connected
> * @eld: pointer to an ELD memory structure
> *
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v4.1 22/22] drm: omapdrm: Perform initialization/cleanup at probe/remove time
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart
---
Changes since v4:
- Dropped drm_vblank_cleanup() in probe error path
- Removed a duplicate call to omap_crtc_pre_uninit() in probe
Changes since v1:
- Call drm_kms_helper_poll_fini() before omap_fbdev_free() in the remove
handler.
- Keep storing drm_device in the platform device private data.
---
drivers/gpu/drm/omapdrm/omap_connector.c | 2 -
drivers/gpu/drm/omapdrm/omap_drv.c | 211 +++
2 files changed, 105 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 691cffebb76e..f90e2d22c5ec 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -240,8 +240,6 @@ struct drm_connector *omap_connector_init(struct drm_device
*dev,
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
- drm_connector_register(connector);
-
return connector;
fail:
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 0a2d461d62cf..00aa214b7560 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -493,11 +493,6 @@ static int omap_modeset_init(struct drm_device *dev)
return 0;
}
-static void omap_modeset_free(struct drm_device *dev)
-{
- drm_mode_config_cleanup(dev);
-}
-
/*
* drm ioctl funcs
*/
@@ -633,95 +628,6 @@ static const struct drm_ioctl_desc ioctls[DRM_COMMAND_END
- DRM_COMMAND_BASE] =
* drm driver funcs
*/
-/**
- * load - setup chip and create an initial config
- * @dev: DRM device
- * @flags: startup flags
- *
- * The driver load routine has to do several things:
- * - initialize the memory manager
- * - allocate initial config memory
- * - setup the DRM framebuffer with the allocated memory
- */
-static int dev_load(struct drm_device *dev, unsigned long flags)
-{
- struct omap_drm_platform_data *pdata = dev->dev->platform_data;
- struct omap_drm_private *priv;
- unsigned int i;
- int ret;
-
- DBG("load: dev=%p", dev);
-
- priv = kzalloc(sizeof(*priv), GFP_KERNEL);
- if (!priv)
- return -ENOMEM;
-
- priv->omaprev = pdata->omaprev;
-
- dev->dev_private = priv;
-
- priv->wq = alloc_ordered_workqueue("omapdrm", 0);
- init_waitqueue_head(&priv->commit.wait);
- spin_lock_init(&priv->commit.lock);
-
- spin_lock_init(&priv->list_lock);
- INIT_LIST_HEAD(&priv->obj_list);
-
- omap_gem_init(dev);
-
- ret = omap_modeset_init(dev);
- if (ret) {
- dev_err(dev->dev, "omap_modeset_init failed: ret=%d\n", ret);
- dev->dev_private = NULL;
- kfree(priv);
- return ret;
- }
-
- /* Initialize vblank handling, start with all CRTCs disabled. */
- ret = drm_vblank_init(dev, priv->num_crtcs);
- if (ret)
- dev_warn(dev->dev, "could not init vblank\n");
-
- for (i = 0; i < priv->num_crtcs; i++)
- drm_crtc_vblank_off(priv->crtcs[i]);
-
- priv->fbdev = omap_fbdev_init(dev);
-
- /* store off drm_device for use in pm ops */
- dev_set_drvdata(dev->dev, dev);
-
- drm_kms_helper_poll_init(dev);
-
- return 0;
-}
-
-static int dev_unload(struct drm_device *dev)
-{
- struct omap_drm_private *priv = dev->dev_private;
-
- DBG("unload: dev=%p", dev);
-
- drm_kms_helper_poll_fini(dev);
-
- if (priv->fbdev)
- omap_fbdev_free(dev);
-
- omap_modeset_free(dev);
- omap_gem_deinit(dev);
-
- destroy_workqueue(priv->wq);
-
- drm_vblank_cleanup(dev);
- omap_drm_irq_uninstall(dev);
-
- kfree(dev->dev_private);
- dev->dev_private = NULL;
-
- dev_set_drvdata(dev->dev, NULL);
-
- return 0;
-}
-
static int dev_open(struct drm_device *dev, struct drm_file *file)
{
file->driver_priv = NULL;
@@ -806,8 +712,6 @@ static const struct file_operations omapdriver_fops = {
static struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
DRIVER_ATOMIC,
- .load = dev_load,
- .unload = dev_unload,
.open = dev_open,
.lastclose = dev_lastclose,
.get_vblank_counter = drm_vblank_no_hw_counter,
@@ -837,30 +741,125 @@ static struct drm_driver omap_drm_driver = {
.patchlevel = DRIVER_PATCHLEVEL,
};
-static int pdev_probe(struct platform_device *device)
+static int pdev_probe(struct platform_device *pdev)
{
- int r;
+ struct omap_drm_pla
[PATCH v4.1 22/22] drm: omapdrm: Perform initialization/cleanup at probe/remove time
On 19/12/16 11:15, Laurent Pinchart wrote: > The drm driver .load() operation is prone to race conditions as it > initializes the driver after registering the device nodes. Its usage is > deprecated, inline it in the probe function and call drm_dev_alloc() and > drm_dev_register() explicitly. > > For consistency inline the .unload() handler in the remove function as > well. > > Signed-off-by: Laurent Pinchart > --- > Changes since v4: > > - Dropped drm_vblank_cleanup() in probe error path > - Removed a duplicate call to omap_crtc_pre_uninit() in probe > > Changes since v1: > > - Call drm_kms_helper_poll_fini() before omap_fbdev_free() in the remove > handler. > - Keep storing drm_device in the platform device private data. > --- > drivers/gpu/drm/omapdrm/omap_connector.c | 2 - > drivers/gpu/drm/omapdrm/omap_drv.c | 211 > +++ > 2 files changed, 105 insertions(+), 108 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/ddfcd371/attachment.sig>
[PATCH v2] drm: exynos: Perform initialization/cleanup at probe/remove time
Hi Laurent, On 17 December 2016 at 22:29, Laurent Pinchart wrote: > The drm driver .load() operation is prone to race conditions as it > initializes the driver after registering the device nodes. Its usage is > deprecated, inline it in the probe function and call drm_dev_alloc() and > drm_dev_register() explicitly. > > For consistency inline the .unload() handler in the remove function as > well. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sean Paul > Reviewed-by: Daniel Vetter > Reviewed-by: Daniel Stone > --- > Changes since v1: > > - Use drm_device.dev instead of drm_device.platformdev in > exynos_drm_fbdev_create() as the platformdev field isn't set anymore Yeah, that looks good. That was what I was getting at with my last mail, but after a few roundtrips through LAVA trying to figure out which extra config options I needed to get the panel to light up, and being sick as well, I'd lost the will to live and didn't feel much like figuring that one out myself. ;) Thanks! Cheers, Daniel
[PATCH v2 1/4] DRM: add help to get ELD speaker allocation
On Mon, Dec 19, 2016 at 11:09:55AM +0200, Jani Nikula wrote:
> On Wed, 14 Dec 2016, Arnaud Pouliquen wrote:
> > Add helper to allow users to retrieve the speaker allocations without
> > knowledge of the ELD structure.
> >
> > Signed-off-by: Arnaud Pouliquen
>
> For this one patch,
>
> Reviewed-by: Jani Nikula
Takashi, do you want a topic branch pull request for this one here for
merging through the sound tree?
-Daniel
>
> > ---
> > include/drm/drm_edid.h | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 919933d..0706cc6 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -245,6 +245,7 @@ struct detailed_timing {
> > # define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
> >
> > #define DRM_ELD_SPEAKER7
> > +# define DRM_ELD_SPEAKER_MASK 0x7f
> > # define DRM_ELD_SPEAKER_RLRC (1 << 6)
> > # define DRM_ELD_SPEAKER_FLRC (1 << 5)
> > # define DRM_ELD_SPEAKER_RC(1 << 4)
> > @@ -412,6 +413,18 @@ static inline int drm_eld_size(const uint8_t *eld)
> > }
> >
> > /**
> > + * drm_eld_get_spk_alloc - Get speaker allocation
> > + * @eld: pointer to an ELD memory structure
> > + *
> > + * The returned value is the speakers mask. User has to use
> > %DRM_ELD_SPEAKER
> > + * field definitions to identify speakers.
> > + */
> > +static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
> > +{
> > + return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
> > +}
> > +
> > +/**
> > * drm_eld_get_conn_type - Get device type hdmi/dp connected
> > * @eld: pointer to an ELD memory structure
> > *
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm: drm_probe_helper: Fix output_poll_work scheduling
On Wed, 31 Aug 2016, Daniel Vetter wrote:
> On Wed, Aug 31, 2016 at 02:09:05PM +0300, Peter Ujfalusi wrote:
>> drm_kms_helper_poll_enable_locked() should check if we have delayed event
>> pending and if we have, schedule the work to run without delay.
>>
>> Currently the output_poll_work is only scheduled if any of the connectors
>> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
>> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
>> already registered to be handled. The detection will be delayd by
>> DRM_OUTPUT_POLL_PERIOD in any case.
>> Furthermore if none of the connectors are marked as POLL_CONNECT or
>> POLL_DISCONNECT because all connectors are either POLL_HPD or they are
>> always connected: the output_poll_work will not run at all even if we
>> have delayed event marked.
>>
>> When none of the connectors require polling, their initial status change
>> from unknown to connected/disconnected is not going to be handled until
>> the first kms application starts or if we have fb console enabled.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> Hi,
>>
>> Changes since v1:
>> - dropped the last paragraph from the commit message.
>
> I added a few more words to the commit message to explain when exactly
> this is a problem and applied your patch to drm-misc.
Hi Peter, sadly looks like this regresses users out there [1]. Seems to
be a reliable bisect. We need to have this fixed or reverted.
BR,
Jani.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=98690
>
> Thanks, Daniel
>>
>> Regards,
>> Peter
>>
>> drivers/gpu/drm/drm_probe_helper.c | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index a0df377d7d1c..f6b64d7d3528 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -129,6 +129,7 @@ void drm_kms_helper_poll_enable_locked(struct drm_device
>> *dev)
>> {
>> bool poll = false;
>> struct drm_connector *connector;
>> +unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
>>
>> WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>>
>> @@ -141,8 +142,13 @@ void drm_kms_helper_poll_enable_locked(struct
>> drm_device *dev)
>> poll = true;
>> }
>>
>> +if (dev->mode_config.delayed_event) {
>> +poll = true;
>> +delay = 0;
>> +}
>> +
>> if (poll)
>> -schedule_delayed_work(&dev->mode_config.output_poll_work,
>> DRM_OUTPUT_POLL_PERIOD);
>> +schedule_delayed_work(&dev->mode_config.output_poll_work,
>> delay);
>> }
>> EXPORT_SYMBOL(drm_kms_helper_poll_enable_locked);
>>
>> --
>> 2.9.3
>>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH 0/6] drm/msm/mdp5: Encoder related cleanups
The MDP5 and DSI drivers created 2 drm_encoders for a DSI interface (one for each mode of operation). This patch fixes that. Now, with the # encoders equal to the # of displays, we can create the right # of CRTCs. We previously created LM # of CRTCs, which ate up too many primary planes. Archit Taneja (6): drm/msm: Construct only one encoder for DSI drm/msm: Set encoder's mode of operation using a kms func drm/msm/mdp5: Prepare for merging video and command encoders drm/msm/mdp5: Create single encoder per interface (INTF) drm/msm/mdp5: cfg: Change count to unsigned int drm/msm/mdp5: Create only as many CRTCs as we need drivers/gpu/drm/msm/dsi/dsi.c | 17 ++- drivers/gpu/drm/msm/dsi/dsi.h | 5 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 + drivers/gpu/drm/msm/dsi/dsi_manager.c | 34 +++--- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 135 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 77 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 86 --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 37 +-- drivers/gpu/drm/msm/msm_drv.h | 9 +- drivers/gpu/drm/msm/msm_kms.h | 3 + 12 files changed, 195 insertions(+), 240 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/6] drm/msm: Construct only one encoder for DSI
We currently create 2 encoders for DSI interfaces, one for command
mode and other for video mode operation. This isn't needed as we
can't really use both the encoders at the same time. It also makes
connecting bridges harder.
Switch to creating a single encoder. For now, we assume that the
encoder is configured only in video mode. Later, the same encoder
would be usable in both modes.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.c | 17 ++---
drivers/gpu/drm/msm/dsi/dsi.h | 4 ++--
drivers/gpu/drm/msm/dsi/dsi_manager.c | 22 --
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 28
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 20 ++--
drivers/gpu/drm/msm/msm_drv.h | 9 ++---
6 files changed, 32 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index ec572f8..4214dea 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -18,9 +18,7 @@ struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi
*msm_dsi)
if (!msm_dsi || !msm_dsi_device_connected(msm_dsi))
return NULL;
- return (msm_dsi->device_flags & MIPI_DSI_MODE_VIDEO) ?
- msm_dsi->encoders[MSM_DSI_VIDEO_ENCODER_ID] :
- msm_dsi->encoders[MSM_DSI_CMD_ENCODER_ID];
+ return msm_dsi->encoder;
}
static int dsi_get_phy(struct msm_dsi *msm_dsi)
@@ -187,14 +185,13 @@ void __exit msm_dsi_unregister(void)
}
int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,
- struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM])
+struct drm_encoder *encoder)
{
struct msm_drm_private *priv = dev->dev_private;
struct drm_bridge *ext_bridge;
- int ret, i;
+ int ret;
- if (WARN_ON(!encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
- !encoders[MSM_DSI_CMD_ENCODER_ID]))
+ if (WARN_ON(!encoder))
return -EINVAL;
msm_dsi->dev = dev;
@@ -213,10 +210,8 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct
drm_device *dev,
goto fail;
}
- for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
- encoders[i]->bridge = msm_dsi->bridge;
- msm_dsi->encoders[i] = encoders[i];
- }
+ encoder->bridge = msm_dsi->bridge;
+ msm_dsi->encoder = encoder;
/*
* check if the dsi encoder output is connected to a panel or an
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 03f115f..ddcda8c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -73,8 +73,8 @@ struct msm_dsi {
struct device *phy_dev;
bool phy_enabled;
- /* the encoders we are hooked to (outside of dsi block) */
- struct drm_encoder *encoders[MSM_DSI_ENCODER_NUM];
+ /* the encoder we are hooked to (outside of dsi block) */
+ struct drm_encoder *encoder;
int id;
};
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 2bd8dad..19da23d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -540,7 +540,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
struct drm_connector *connector = NULL;
struct dsi_connector *dsi_connector;
- int ret, i;
+ int ret;
dsi_connector = kzalloc(sizeof(*dsi_connector), GFP_KERNEL);
if (!dsi_connector)
@@ -566,9 +566,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id)
connector->interlace_allowed = 0;
connector->doublescan_allowed = 0;
- for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
- drm_mode_connector_attach_encoder(connector,
- msm_dsi->encoders[i]);
+ drm_mode_connector_attach_encoder(connector, msm_dsi->encoder);
return connector;
}
@@ -591,13 +589,7 @@ struct drm_bridge *msm_dsi_manager_bridge_init(u8 id)
dsi_bridge->id = id;
- /*
-* HACK: we may not know the external DSI bridge device's mode
-* flags here. We'll get to know them only when the device
-* attaches to the dsi host. For now, assume the bridge supports
-* DSI video mode
-*/
- encoder = msm_dsi->encoders[MSM_DSI_VIDEO_ENCODER_ID];
+ encoder = msm_dsi->encoder;
bridge = &dsi_bridge->base;
bridge->funcs = &dsi_mgr_bridge_funcs;
@@ -628,13 +620,7 @@ struct drm_connector *msm_dsi_manager_ext_bridge_init(u8
id)
ext_bridge = msm_dsi->external_bridge =
msm_dsi_host_get_bridge(msm_dsi->host);
- /*
-* HACK: we may not know the external DSI bridge device's mode
-* flags here. We'll get to know them only when the device
-* atta
[PATCH 3/6] drm/msm/mdp5: Prepare for merging video and command encoders
Rename the mdp5_encoder_* ops for active displays to
mdp5_vid_encoder_* ops.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 31 ++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 3 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 4 ++--
3 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 1e7c991..63f4135 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -112,9 +112,9 @@ static void mdp5_encoder_destroy(struct drm_encoder
*encoder)
.destroy = mdp5_encoder_destroy,
};
-static void mdp5_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static void mdp5_vid_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
{
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_kms *mdp5_kms = get_kms(encoder);
@@ -221,7 +221,7 @@ static void mdp5_encoder_mode_set(struct drm_encoder
*encoder,
mdp5_encoder->ctl);
}
-static void mdp5_encoder_disable(struct drm_encoder *encoder)
+static void mdp5_vid_encoder_disable(struct drm_encoder *encoder)
{
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_kms *mdp5_kms = get_kms(encoder);
@@ -256,7 +256,7 @@ static void mdp5_encoder_disable(struct drm_encoder
*encoder)
mdp5_encoder->enabled = false;
}
-static void mdp5_encoder_enable(struct drm_encoder *encoder)
+static void mdp5_vid_encoder_enable(struct drm_encoder *encoder)
{
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_kms *mdp5_kms = get_kms(encoder);
@@ -279,6 +279,23 @@ static void mdp5_encoder_enable(struct drm_encoder
*encoder)
mdp5_encoder->enabled = true;
}
+static void mdp5_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ mdp5_vid_encoder_mode_set(encoder, mode, adjusted_mode);
+}
+
+static void mdp5_encoder_disable(struct drm_encoder *encoder)
+{
+ mdp5_vid_encoder_disable(encoder);
+}
+
+static void mdp5_encoder_enable(struct drm_encoder *encoder)
+{
+ mdp5_vid_encoder_enable(encoder);
+}
+
static const struct drm_encoder_helper_funcs mdp5_encoder_helper_funcs = {
.mode_set = mdp5_encoder_mode_set,
.disable = mdp5_encoder_disable,
@@ -303,8 +320,8 @@ u32 mdp5_encoder_get_framecount(struct drm_encoder *encoder)
return mdp5_read(mdp5_kms, REG_MDP5_INTF_FRAME_COUNT(intf));
}
-int mdp5_encoder_set_split_display(struct drm_encoder *encoder,
- struct drm_encoder *slave_encoder)
+int mdp5_vid_encoder_set_split_display(struct drm_encoder *encoder,
+ struct drm_encoder *slave_encoder)
{
struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
struct mdp5_encoder *mdp5_slave_enc = to_mdp5_encoder(slave_encoder);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index cca4e38..27f67eb 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -154,7 +154,8 @@ static int mdp5_set_split_display(struct msm_kms *kms,
return mdp5_cmd_encoder_set_split_display(encoder,
slave_encoder);
else
- return mdp5_encoder_set_split_display(encoder, slave_encoder);
+ return mdp5_vid_encoder_set_split_display(encoder,
+ slave_encoder);
}
static void mdp5_set_encoder_mode(struct msm_kms *kms,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index b9d1d76..d720d66 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -248,8 +248,8 @@ struct drm_crtc *mdp5_crtc_init(struct drm_device *dev,
struct drm_encoder *mdp5_encoder_init(struct drm_device *dev,
struct mdp5_interface *intf, struct mdp5_ctl *ctl);
-int mdp5_encoder_set_split_display(struct drm_encoder *encoder,
- struct drm_encoder *slave_encoder);
+int mdp5_vid_encoder_set_split_display(struct drm_encoder *encoder,
+ struct drm_encoder *slave_encoder);
void mdp5_encoder_set_intf_mode(struct drm_encoder *encoder, bool cmd_mode);
int mdp5_encoder_get_linecount(struct drm_encoder *encoder);
u32 mdp5_encoder_get_framecount(struct drm_
[PATCH 2/6] drm/msm: Set encoder's mode of operation using a kms func
The mdp5 kms driver currently sets up multiple encoders per interface
(INTF), one for each kind of mode of operation it supports.
We create 2 drm_encoders for DSI, one for video mode and the other
for command mode operation. The reason behind this approach could have
been that we aren't aware of the DSI device's mode of operation when
we create the encoders.
This makes things a bit complicated, since these encoders have to
be further attached to the same DSI bridge. The easier way out is
to create a single encoder, and make the DSI driver set its mode
of operation when we know what the DSI device's mode flags are.
Start with providing a way to set the mdp5_intf_mode using a kms
func.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
drivers/gpu/drm/msm/dsi/dsi_manager.c | 12
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 17 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 8
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
drivers/gpu/drm/msm/msm_kms.h | 3 +++
7 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index ddcda8c..81971b3 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -90,6 +90,7 @@ int msm_dsi_manager_phy_enable(int id,
void msm_dsi_manager_phy_disable(int id);
int msm_dsi_manager_cmd_xfer(int id, const struct mipi_dsi_msg *msg);
bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len);
+void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 3819fde..eb0903d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1482,6 +1482,8 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
msm_host->format = dsi->format;
msm_host->mode_flags = dsi->mode_flags;
+ msm_dsi_manager_attach_dsi_device(msm_host->id, dsi->mode_flags);
+
/* Some gpios defined in panel DT need to be controlled by host */
ret = dsi_host_init_panel_gpios(msm_host, &dsi->dev);
if (ret)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 19da23d..e14882d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -773,6 +773,18 @@ bool msm_dsi_manager_cmd_xfer_trigger(int id, u32
dma_base, u32 len)
return true;
}
+void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags)
+{
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct msm_drm_private *priv = msm_dsi->dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+ struct drm_encoder *encoder = msm_dsi_get_encoder(msm_dsi);
+
+ if (encoder && kms->funcs->set_encoder_mode)
+ if (!(device_flags & MIPI_DSI_MODE_VIDEO))
+ kms->funcs->set_encoder_mode(kms, encoder, true);
+}
+
int msm_dsi_manager_register(struct msm_dsi *msm_dsi)
{
struct msm_dsi_manager *msm_dsim = &msm_dsim_glb;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index fe0c222..1e7c991 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -342,6 +342,23 @@ int mdp5_encoder_set_split_display(struct drm_encoder
*encoder,
return 0;
}
+void mdp5_encoder_set_intf_mode(struct drm_encoder *encoder, bool cmd_mode)
+{
+ struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
+ struct mdp5_interface *intf = &mdp5_encoder->intf;
+
+ /* TODO: Expand this to set writeback modes too */
+ if (cmd_mode) {
+ WARN_ON(intf->type != INTF_DSI);
+ intf->mode = MDP5_INTF_DSI_MODE_COMMAND;
+ } else {
+ if (intf->type == INTF_DSI)
+ intf->mode = MDP5_INTF_DSI_MODE_VIDEO;
+ else
+ intf->mode = MDP5_INTF_MODE_NONE;
+ }
+}
+
/* initialize encoder */
struct drm_encoder *mdp5_encoder_init(struct drm_device *dev,
struct mdp5_interface *intf, struct mdp5_ctl *ctl)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index fcbde9b..cca4e38 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -157,6 +157,13 @@ static int mdp5_set_split_display(struct msm_kms *kms,
return mdp5_encoder_set_split_display(encoder, slave_encoder);
}
+static void mdp5_set_encoder_mode(struct msm_kms *kms,
+ struct drm_encoder *encoder,
+ bool cmd_mode)
+{
+ mdp5_encoder_set_intf_
[PATCH 5/6] drm/msm/mdp5: cfg: Change count to unsigned int
Count can't be non-zero. Changing to uint will also prevent future
warnings.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 050e161..bd4fe81 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -32,7 +32,7 @@
typedef DECLARE_BITMAP(mdp5_smp_state_t, MAX_SMP_BLOCKS);
#define MDP5_SUB_BLOCK_DEFINITION \
- int count; \
+ unsigned int count; \
uint32_t base[MAX_BASES]
struct mdp5_sub_block {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 4/6] drm/msm/mdp5: Create single encoder per interface (INTF)
For the DSI interfaces, the mdp5_kms core creates 2 encoders for video
and command modes.
Create only a single encoder per interface. When creating the encoder, set
the interface type to MDP5_INTF_MODE_NONE. It's the bridge (DSI/HDMI/eDP)
driver's responsibility to set a different interface type. It can use the
the kms func op set_encoder_mode to change the mode of operation, which
in turn would configure the interface type for the INTF.
In mdp5_cmd_encoder.c, we remove the redundant code, and make the commmand
mode funcs as helpers that are used in mdp5_encoder.c
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 135 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 35 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 20 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 32 --
4 files changed, 66 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
index c627ab6..df1c8ad 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c
@@ -16,16 +16,6 @@
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
-struct mdp5_cmd_encoder {
- struct drm_encoder base;
- struct mdp5_interface intf;
- bool enabled;
- uint32_t bsc;
-
- struct mdp5_ctl *ctl;
-};
-#define to_mdp5_cmd_encoder(x) container_of(x, struct mdp5_cmd_encoder, base)
-
static struct mdp5_kms *get_kms(struct drm_encoder *encoder)
{
struct msm_drm_private *priv = encoder->dev->dev_private;
@@ -36,47 +26,8 @@ static struct mdp5_kms *get_kms(struct drm_encoder *encoder)
#include
#include
#include
-#define MDP_BUS_VECTOR_ENTRY(ab_val, ib_val) \
- { \
- .src = MSM_BUS_MASTER_MDP_PORT0,\
- .dst = MSM_BUS_SLAVE_EBI_CH0, \
- .ab = (ab_val), \
- .ib = (ib_val), \
- }
-
-static struct msm_bus_vectors mdp_bus_vectors[] = {
- MDP_BUS_VECTOR_ENTRY(0, 0),
- MDP_BUS_VECTOR_ENTRY(20, 20),
-};
-static struct msm_bus_paths mdp_bus_usecases[] = { {
- .num_paths = 1,
- .vectors = &mdp_bus_vectors[0],
-}, {
- .num_paths = 1,
- .vectors = &mdp_bus_vectors[1],
-} };
-static struct msm_bus_scale_pdata mdp_bus_scale_table = {
- .usecase = mdp_bus_usecases,
- .num_usecases = ARRAY_SIZE(mdp_bus_usecases),
- .name = "mdss_mdp",
-};
-
-static void bs_init(struct mdp5_cmd_encoder *mdp5_cmd_enc)
-{
- mdp5_cmd_enc->bsc = msm_bus_scale_register_client(
- &mdp_bus_scale_table);
- DBG("bus scale client: %08x", mdp5_cmd_enc->bsc);
-}
-
-static void bs_fini(struct mdp5_cmd_encoder *mdp5_cmd_enc)
-{
- if (mdp5_cmd_enc->bsc) {
- msm_bus_scale_unregister_client(mdp5_cmd_enc->bsc);
- mdp5_cmd_enc->bsc = 0;
- }
-}
-static void bs_set(struct mdp5_cmd_encoder *mdp5_cmd_enc, int idx)
+static void bs_set(struct mdp5_encoder *mdp5_cmd_enc, int idx)
{
if (mdp5_cmd_enc->bsc) {
DBG("set bus scaling: %d", idx);
@@ -89,14 +40,12 @@ static void bs_set(struct mdp5_cmd_encoder *mdp5_cmd_enc,
int idx)
}
}
#else
-static void bs_init(struct mdp5_cmd_encoder *mdp5_cmd_enc) {}
-static void bs_fini(struct mdp5_cmd_encoder *mdp5_cmd_enc) {}
-static void bs_set(struct mdp5_cmd_encoder *mdp5_cmd_enc, int idx) {}
+static void bs_set(struct mdp5_encoder *mdp5_cmd_enc, int idx) {}
#endif
#define VSYNC_CLK_RATE 1920
static int pingpong_tearcheck_setup(struct drm_encoder *encoder,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode)
{
struct mdp5_kms *mdp5_kms = get_kms(encoder);
struct device *dev = encoder->dev->dev;
@@ -176,23 +125,11 @@ static void pingpong_tearcheck_disable(struct drm_encoder
*encoder)
clk_disable_unprepare(mdp5_kms->vsync_clk);
}
-static void mdp5_cmd_encoder_destroy(struct drm_encoder *encoder)
-{
- struct mdp5_cmd_encoder *mdp5_cmd_enc = to_mdp5_cmd_encoder(encoder);
- bs_fini(mdp5_cmd_enc);
- drm_encoder_cleanup(encoder);
- kfree(mdp5_cmd_enc);
-}
-
-static const struct drm_encoder_funcs mdp5_cmd_encoder_funcs = {
- .destroy = mdp5_cmd_encoder_destroy,
-};
-
-static void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+void mdp5_cmd_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
{
- struct mdp5_cmd_encoder *mdp5_cmd_enc = to_mdp5_cmd_
[PATCH 6/6] drm/msm/mdp5: Create only as many CRTCs as we need
We currently create CRTCs equaling to the # of Layer Mixer blocks we
have on the MDP5 HW. This number is generally more than the # of encoders
(INTFs) we have in the MDSS HW. The number of encoders connected to
displays on the platform (as described by DT) would be even lesser.
Create only N drm_crtcs, where N is the number of drm_encoders
successfully registered. To do this, we call modeset_init_intf() before
we init the drm_crtcs and drm_planes.
Because of this change, setting encoder->possible_crtcs needs to be moved
from construct_encoder() to a later point when we know how many CRTCs we
have.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 39 -
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 646f160..84ec89d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -299,7 +299,6 @@ static struct drm_encoder *construct_encoder(struct
mdp5_kms *mdp5_kms,
return encoder;
}
- encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
priv->encoders[priv->num_encoders++] = encoder;
return encoder;
@@ -417,16 +416,35 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
const struct mdp5_cfg_hw *hw_cfg;
+ unsigned int num_crtcs;
int i, ret;
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
- /* Construct planes equaling the number of hw pipes, and CRTCs
-* for the N layer-mixers (LM). The first N planes become primary
+ /*
+* Construct encoders and modeset initialize connector devices
+* for each external display interface.
+*/
+ for (i = 0; i < ARRAY_SIZE(hw_cfg->intf.connect); i++) {
+ ret = modeset_init_intf(mdp5_kms, i);
+ if (ret)
+ goto fail;
+ }
+
+ /*
+* We should ideally have less number of encoders (set up by parsing
+* the MDP5 interfaces) than the number of layer mixers present in HW,
+* but let's be safe here anyway
+*/
+ num_crtcs = min(priv->num_encoders, mdp5_cfg->lm.count);
+
+ /*
+* Construct planes equaling the number of hw pipes, and CRTCs for the
+* N encoders set up by the driver. The first N planes become primary
* planes for the CRTCs, with the remainder as overlay planes:
*/
for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
- bool primary = i < mdp5_cfg->lm.count;
+ bool primary = i < num_crtcs;
struct drm_plane *plane;
struct drm_crtc *crtc;
@@ -450,13 +468,14 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
priv->crtcs[priv->num_crtcs++] = crtc;
}
- /* Construct encoders and modeset initialize connector devices
-* for each external display interface.
+ /*
+* Now that we know the number of crtcs we've created, set the possible
+* crtcs for the encoders
*/
- for (i = 0; i < ARRAY_SIZE(hw_cfg->intf.connect); i++) {
- ret = modeset_init_intf(mdp5_kms, i);
- if (ret)
- goto fail;
+ for (i = 0; i < priv->num_encoders; i++) {
+ struct drm_encoder *encoder = priv->encoders[i];
+
+ encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
}
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH v6] lib: Add a simple prime number generator
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwind on module exit, add to kselftests
v6: Tidy computation of bitmap size
Signed-off-by: Chris Wilson
Cc: Lukas Wunner
---
include/linux/prime_numbers.h| 23 +++
lib/Kconfig | 7 +
lib/Makefile | 2 +
lib/prime_numbers.c | 266 +++
tools/testing/selftests/lib/prime_numbers.sh | 15 ++
5 files changed, 313 insertions(+)
create mode 100644 include/linux/prime_numbers.h
create mode 100644 lib/prime_numbers.c
create mode 100755 tools/testing/selftests/lib/prime_numbers.sh
diff --git a/include/linux/prime_numbers.h b/include/linux/prime_numbers.h
new file mode 100644
index ..6ba642c3f95d
--- /dev/null
+++ b/include/linux/prime_numbers.h
@@ -0,0 +1,23 @@
+#ifndef __LINUX_PRIME_NUMBERS_H
+#define __LINUX_PRIME_NUMBERS_H
+
+#include
+
+bool is_prime_number(unsigned long x);
+unsigned long next_prime_number(unsigned long x);
+
+/**
+ * for_each_prime_number - iterate over each prime upto a value
+ * @prime: the current prime number in this iteration
+ * @max: the upper limit
+ *
+ * Starting from 1 (which is only considered prime for convenience
+ * of using for_each_prime_number(), a useful white lie), iterate over each
+ * prime number up to the @max value. On each iteration, @prime is set to the
+ * current prime number. @max should be less than ULONG_MAX to ensure
+ * termination.
+ */
+#define for_each_prime_number(prime, max) \
+ for (prime = 1; prime <= (max); prime = next_prime_number(prime))
+
+#endif /* !__LINUX_PRIME_NUMBERS_H */
diff --git a/lib/Kconfig b/lib/Kconfig
index 260a80e313b9..1788a1f50d28 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -550,4 +550,11 @@ config STACKDEPOT
config SBITMAP
bool
+config PRIME_NUMBERS
+ tristate "Prime number generator"
+ default n
+ help
+ Provides a helper module to generate prime numbers. Useful for writing
+ test code, especially when checking multiplication and divison.
+
endmenu
diff --git a/lib/Makefile b/lib/Makefile
index 50144a3aeebd..c664143fd917 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -197,6 +197,8 @@ obj-$(CONFIG_ASN1) += asn1_decoder.o
obj-$(CONFIG_FONT_SUPPORT) += fonts/
+obj-$(CONFIG_PRIME_NUMBERS) += prime_numbers.o
+
hostprogs-y:= gen_crc32table
clean-files:= crc32table.h
diff --git a/lib/prime_numbers.c b/lib/prime_numbers.c
new file mode 100644
index ..02795aa0e820
--- /dev/null
+++ b/lib/prime_numbers.c
@@ -0,0 +1,266 @@
+#define pr_fmt(fmt) "prime numbers: " fmt "\n"
+
+#include
+#include
+#include
+#include
+
+#define bitmap_size(nbits) (BITS_TO_LONGS(nbits) * sizeof(unsigned long))
+
+struct primes {
+ struct rcu_head rcu;
+ unsigned long last, sz;
+ unsigned long primes[];
+};
+
+#if BITS_PER_LONG == 64
+static const struct primes small_primes = {
+ .last = 61,
+ .sz = 64,
+ .primes = { 0x28208a20a08a28acUL }
+};
+#elif BITS_PER_LONG == 32
+static const struct primes small_primes = {
+ .last = 31,
+ .sz = 32,
+ .primes = { 0xa08a28acUL }
+};
+#else
+#error "unhandled BITS_PER_LONG"
+#endif
+
+static DEFINE_MUTEX(lock);
+static const struct primes __rcu *primes = RCU_INITIALIZER(&small_primes);
+
+static unsigned long selftest_max;
+
+static bool slow_is_prime_number(unsigned long x)
+{
+ unsigned long y = int_sqrt(x);
+
+ while (y > 1) {
+ if ((x % y) == 0)
+ break;
+ y--;
+ }
+
+ return y == 1;
+}
+
+static unsigned long slow_next_prime_number(unsigned long x)
+{
+ while (x < ULONG_MAX && !slow_is_prime_number(++x))
+ ;
+
+ return x;
+}
+
+static unsigned long mark_multiples(unsigned long x,
+ unsigned long *p,
+ unsigned long start,
+ unsigned long end)
+{
+ unsigned long m;
+
+ m = 2 * x;
+ if (m < start)
+ m = roundup(start, x);
+
+ while (m < end) {
+ __clear_bit(m, p);
+ m += x;
+ }
+
+ return x;
+}
+
+static const struct primes *expand_to_next_prime(unsigned long x)
+{
+ const struct primes *p;
+ struct primes *new;
+ unsigned long sz, y;
+
+ rcu_read_unlock();
+
+ /* Betrand's Theorem states:
+* For all n > 1, there exists a prime p: n < p <= 2*n.
+*/
+ sz = 2 * x + 1;
+ if (sz < x)
+ return NULL;
+
+ sz = round_up(sz, BITS_PER_LONG);
+ new = kmalloc(sizeof(*new) + bitmap_size(sz), GFP_K
[PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access
On Mon, Dec 19, 2016 at 10:40:41AM +0900, Inki Dae wrote:
>
>
> 2016ë
08ì 16ì¼ 01:02ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> >> Rendering operations to the dma-buf are tracked implicitly via the
> >> reservation_object (dmabuf->resv). This is used to allow poll() to
> >> wait upon outstanding rendering (or just query the current status of
> >> rendering). The dma-buf sync ioctl allows userspace to prepare the
> >> dma-buf for CPU access, which should include waiting upon rendering.
> >> (Some drivers may need to do more work to ensure that the dma-buf mmap
> >> is coherent as well as complete.)
> >>
> >> v2: Always wait upon the reservation object implicitly. We choose to do
> >> it after the native handler in case it can do so more efficiently.
> >>
> >> Testcase: igt/prime_vgem
> >> Testcase: igt/gem_concurrent_blit # *vgem*
> >> Signed-off-by: Chris Wilson
> >> Cc: Sumit Semwal
> >> Cc: Daniel Vetter
> >> Cc: Eric Anholt
> >> Cc: linux-media at vger.kernel.org
> >> Cc: dri-devel at lists.freedesktop.org
> >> Cc: linaro-mm-sig at lists.linaro.org
> >> Cc: linux-kernel at vger.kernel.org
> >> ---
> >> drivers/dma-buf/dma-buf.c | 23 +++
> >> 1 file changed, 23 insertions(+)
> >>
> >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> >> index ddaee60ae52a..cf04d249a6a4 100644
> >> --- a/drivers/dma-buf/dma-buf.c
> >> +++ b/drivers/dma-buf/dma-buf.c
> >> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct
> >> dma_buf_attachment *attach,
> >> }
> >> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> >>
> >> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> >> +enum dma_data_direction direction)
> >> +{
> >> + bool write = (direction == DMA_BIDIRECTIONAL ||
> >> +direction == DMA_TO_DEVICE);
> >> + struct reservation_object *resv = dmabuf->resv;
> >> + long ret;
> >> +
> >> + /* Wait on any implicit rendering fences */
> >> + ret = reservation_object_wait_timeout_rcu(resv, write, true,
> >> +MAX_SCHEDULE_TIMEOUT);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + return 0;
> >> +}
> >>
> >> /**
> >> * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf
> >> from the
> >> @@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
> >>if (dmabuf->ops->begin_cpu_access)
> >>ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
> >>
> >> + /* Ensure that all fences are waited upon - but we first allow
> >> + * the native handler the chance to do so more efficiently if it
> >> + * chooses. A double invocation here will be reasonably cheap no-op.
> >> + */
> >> + if (ret == 0)
> >> + ret = __dma_buf_begin_cpu_access(dmabuf, direction);
> >
> > Not sure we should wait first and the flush or the other way round. But I
> > don't think it'll matter for any current dma-buf exporter, so meh.
> >
>
> Sorry for late comment. I wonder there is no problem in case that GPU or
> other DMA device tries to access this dma buffer after
> dma_buf_begin_cpu_access call.
> I think in this case, they - GPU or DMA devices - would make a mess of the
> dma buffer while CPU is accessing the buffer.
>
> This patch is in mainline already so if this is real problem then I think we
> sould choose,
> 1. revert this patch from mainline
That scenario is irrespective of this patch. It just depends on there
being concurrent CPU access with destructive DMA access (or vice-versa).
> 2. make sure to prevent other DMA devices to try to access the buffer while
> CPU is accessing the buffer.
Is the safeguard you want, and the one employed elsewhere, which you could
accomplish by adding a fence to the reservation object for the CPU access
in begin_access and signaling from end_access. It would need to be an
autosignaled fence because userspace may forget to end its access
(or otherwise be terminated whilst holding the fence).
Everyone using the mmap without begin/end can of course still reek havoc
on the buffer.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 2/6] drm/atomic: Unconditionally call prepare_fb.
Op 13-12-16 om 18:10 schreef Daniel Vetter:
> On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
>> Op 09-12-16 om 09:25 schreef Daniel Vetter:
>>> On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
Hi Daniel,
On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
>> Atomic drivers may set properties like rotation on the same fb, which
>> may require a call to prepare_fb even when framebuffer stays identical.
>>
>> Instead of handling all the special cases in the core, let the driver
>> decide when prepare_fb and cleanup_fb are noops.
>>
>> Signed-off-by: Maarten Lankhorst
> I think this makes sense, but would be really good to get a pile of acks
> from driver maintainers on this one. Rob, Eric, Laurent, others?
This is all very nice, but it will introduce at least a performance
regression, and possibly worse, until drivers get updated. There are 7
drivers
implementing the .prepare_fb() callback (plus a bunch of drivers that
probably
should use drm_fb_cma_prepare_fb() but don't at the moment). I can't ack
this
patch before they get fixed.
>>> Maarten's commit message is insufficient, since this is defacto a revert
>>> of
>>>
>>> commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
>>> Author: Keith Packard
>>> Date: Sat Jun 4 01:16:22 2016 -0700
>>>
>>> drm: Don't prepare or cleanup unchanging frame buffers [v3]
>>>
>>> because that breaks stuff. We're simply going back to where we've been a
>>> few months ago. Since this is a regression fix, back to original
>>> behaviour, can you ack (assuming Maarten updates the commit message to
>>> reflect the nature of the commit here)?
>> Waiting on a reply, but what about this commit message for this patch?
>> ---
>> Atomic drivers may set properties like rotation on the same fb, which
>> may require a call to prepare_fb even when framebuffer stays identical.
>>
>> Instead of handling all the special cases in the core, let the driver
>> decide when prepare_fb and cleanup_fb are noops.
>>
>> This is a revert of:
>>
>> commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
>> Author: Keith Packard
>> Date: Sat Jun 4 01:16:22 2016 -0700
>>
>> drm: Don't prepare or cleanup unchanging frame buffers [v3]
>>
>> The original commit mentions that this prevents waiting in i915 on all
>> previous rendering during cursor updates, but there are better ways to
>> fix this.
>>
>> Signed-off-by: Maarten Lankhorst
> Yeah sounds good to me. Since we don't want to backport all the i915
> cursor patches no cc: stable on this. Also, this is only an issue for
> drivers which both have a cursor plane, and implement that cursor using
> universal planes (i.e. settting drm_crtc->cursor). Afaik the only two are
> vc4 and i915, and after this series both will have appropriate hacks (for
> now) to keep existing userspace happy.
> -Daniel
Same patch, reworded!
---8<---
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
This is a revert of:
commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
Author: Keith Packard
Date: Sat Jun 4 01:16:22 2016 -0700
drm: Don't prepare or cleanup unchanging frame buffers [v3]
The original commit mentions that this prevents waiting in i915 on all
previous rendering during cursor updates, but there are better ways to
fix this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 23767df72615..d19563651e07 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
funcs = plane->helper_private;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
if (funcs->prepare_fb) {
ret = funcs->prepare_fb(plane, plane_state);
if (ret)
@@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
if (j >= i)
continue;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
@@ -1952,9 +1946,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- if (!drm_atomic_he
[PATCH v2 2/6] drm/atomic: Unconditionally call prepare_fb.
Hi Maarten,
Thank you for the patch.
On Monday 19 Dec 2016 12:08:16 Maarten Lankhorst wrote:
> Op 13-12-16 om 18:10 schreef Daniel Vetter:
> > On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
> >> Op 09-12-16 om 09:25 schreef Daniel Vetter:
> >>> On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
> On Thursday 08 Dec 2016 16:41:04 Daniel Vetter wrote:
> > On Thu, Dec 08, 2016 at 02:45:25PM +0100, Maarten Lankhorst wrote:
> >> Atomic drivers may set properties like rotation on the same fb, which
> >> may require a call to prepare_fb even when framebuffer stays
> >> identical.
> >>
> >> Instead of handling all the special cases in the core, let the driver
> >> decide when prepare_fb and cleanup_fb are noops.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >
> > I think this makes sense, but would be really good to get a pile of
> > acks from driver maintainers on this one. Rob, Eric, Laurent, others?
>
> This is all very nice, but it will introduce at least a performance
> regression, and possibly worse, until drivers get updated. There are 7
> drivers implementing the .prepare_fb() callback (plus a bunch of
> drivers that probably should use drm_fb_cma_prepare_fb() but don't at
> the moment). I can't ack this patch before they get fixed.
> >>>
> >>> Maarten's commit message is insufficient, since this is defacto a revert
> >>> of
> >>>
> >>> commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
> >>> Author: Keith Packard
> >>> Date: Sat Jun 4 01:16:22 2016 -0700
> >>>
> >>> drm: Don't prepare or cleanup unchanging frame buffers [v3]
> >>>
> >>> because that breaks stuff. We're simply going back to where we've been a
> >>> few months ago. Since this is a regression fix, back to original
> >>> behaviour, can you ack (assuming Maarten updates the commit message to
> >>> reflect the nature of the commit here)?
> >>
> >> Waiting on a reply, but what about this commit message for this patch?
> >> ---
> >> Atomic drivers may set properties like rotation on the same fb, which
> >> may require a call to prepare_fb even when framebuffer stays identical.
> >>
> >> Instead of handling all the special cases in the core, let the driver
> >> decide when prepare_fb and cleanup_fb are noops.
> >>
> >> This is a revert of:
> >>
> >> commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
> >> Author: Keith Packard
> >> Date: Sat Jun 4 01:16:22 2016 -0700
> >>
> >> drm: Don't prepare or cleanup unchanging frame buffers [v3]
> >>
> >> The original commit mentions that this prevents waiting in i915 on all
> >> previous rendering during cursor updates, but there are better ways to
> >> fix this.
> >>
> >> Signed-off-by: Maarten Lankhorst
> >
> > Yeah sounds good to me. Since we don't want to backport all the i915
> > cursor patches no cc: stable on this. Also, this is only an issue for
> > drivers which both have a cursor plane, and implement that cursor using
> > universal planes (i.e. settting drm_crtc->cursor). Afaik the only two are
> > vc4 and i915, and after this series both will have appropriate hacks (for
> > now) to keep existing userspace happy.
> > -Daniel
>
> Same patch, reworded!
> ---8<---
> Atomic drivers may set properties like rotation on the same fb, which
> may require a call to prepare_fb even when framebuffer stays identical.
>
> Instead of handling all the special cases in the core, let the driver
> decide when prepare_fb and cleanup_fb are noops.
>
> This is a revert of:
>
> commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
> Author: Keith Packard
> Date: Sat Jun 4 01:16:22 2016 -0700
>
> drm: Don't prepare or cleanup unchanging frame buffers [v3]
>
> The original commit mentions that this prevents waiting in i915 on all
> previous rendering during cursor updates, but there are better ways to
> fix this.
>
> Signed-off-by: Maarten Lankhorst
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 23767df72615..d19563651e07
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1664,9 +1664,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev,
>
> funcs = plane->helper_private;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc)) - continue;
> -
> if (funcs->prepare_fb) {
> ret = funcs->prepare_fb(plane, plane_state);
> if (ret)
> @@ -1683,9 +1680,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
> *dev, if (j >= i)
> continue;
>
> - if (!drm_atomic_helper_framebuffer_changed(dev, state,
> plane_state->crtc)) - continue;
> -
> funcs = p
[PATCH 0/9] drm/msm/mdp5: Cursor plane stuff
This series does some mdp5_plane related clean ups (use plane helpers for clipping etc), adds MDP5 bits needed for cursor plane blocks, and then add cursor planes. On older MDP5 versions, we had cursor HW in Layer Mixer blocks, and that's implemented in mdp5_crtc.c. With newer hardware, the cursor blocks look exactly like MDP5 pipes (SSPPs). The "faster than vblank cursor position update stuff" has been copied from vc4 and the patches posted recently by Maarten for Intel: https://patchwork.kernel.org/patch/9466417/ I've tried this with some X11 UI and modetest -C, and it seems to work okay. Are there any tests that mix up atomic commits and legacy cursor updates a lot to identify issues? Archit Taneja (9): drm/msm/mdp5: cfg: Add pipe_cursor block drm/msm/mdp5: Update generated headers drm/msm/mdp5: Prepare CRTC/LM for empty stages drm/msm/mdp5: Use plane helpers to configure src/dst rectangles drm/msm/mdp5: Configure COLOR3_OUT propagation drm/msm/mdp5: Misc cursor plane bits drm/msm/mdp5: Refactor mdp5_plane_atomic_check HACK: drm/msm/mdp5: Add support for legacy cursor updates drm/msm/mdp5: Add cursor planes drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 30 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 10 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 1 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 73 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 14 ++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 4 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 38 +-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 8 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c | 8 ++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 181 ++ drivers/gpu/drm/msm/mdp/mdp_kms.h | 1 + drivers/gpu/drm/msm/msm_atomic.c | 26 +++-- 12 files changed, 334 insertions(+), 60 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/9] drm/msm/mdp5: Update generated headers
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index 27d5371..6db1b8b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -65,16 +65,19 @@ enum mdp5_intfnum {
};
enum mdp5_pipe {
- SSPP_VIG0 = 0,
- SSPP_VIG1 = 1,
- SSPP_VIG2 = 2,
- SSPP_RGB0 = 3,
- SSPP_RGB1 = 4,
- SSPP_RGB2 = 5,
- SSPP_DMA0 = 6,
- SSPP_DMA1 = 7,
- SSPP_VIG3 = 8,
- SSPP_RGB3 = 9,
+ SSPP_NONE = 0,
+ SSPP_VIG0 = 1,
+ SSPP_VIG1 = 2,
+ SSPP_VIG2 = 3,
+ SSPP_RGB0 = 4,
+ SSPP_RGB1 = 5,
+ SSPP_RGB2 = 6,
+ SSPP_DMA0 = 7,
+ SSPP_DMA1 = 8,
+ SSPP_VIG3 = 9,
+ SSPP_RGB3 = 10,
+ SSPP_CURSOR0 = 11,
+ SSPP_CURSOR1 = 12,
};
enum mdp5_ctl_mode {
@@ -532,6 +535,7 @@ static inline uint32_t MDP5_CTL_LAYER_EXT_REG_CURSOR1(enum
mdp_mixer_stage_id va
static inline uint32_t __offset_PIPE(enum mdp5_pipe idx)
{
switch (idx) {
+ case SSPP_NONE: return (INVALID_IDX(idx));
case SSPP_VIG0: return (mdp5_cfg->pipe_vig.base[0]);
case SSPP_VIG1: return (mdp5_cfg->pipe_vig.base[1]);
case SSPP_VIG2: return (mdp5_cfg->pipe_vig.base[2]);
@@ -542,6 +546,8 @@ static inline uint32_t __offset_PIPE(enum mdp5_pipe idx)
case SSPP_DMA1: return (mdp5_cfg->pipe_dma.base[1]);
case SSPP_VIG3: return (mdp5_cfg->pipe_vig.base[3]);
case SSPP_RGB3: return (mdp5_cfg->pipe_rgb.base[3]);
+ case SSPP_CURSOR0: return (mdp5_cfg->pipe_cursor.base[0]);
+ case SSPP_CURSOR1: return (mdp5_cfg->pipe_cursor.base[1]);
default: return INVALID_IDX(idx);
}
}
@@ -1073,6 +1079,10 @@ static inline uint32_t __offset_LM(uint32_t idx)
#define MDP5_LM_BLEND_COLOR_OUT_STAGE1_FG_ALPHA
0x0004
#define MDP5_LM_BLEND_COLOR_OUT_STAGE2_FG_ALPHA
0x0008
#define MDP5_LM_BLEND_COLOR_OUT_STAGE3_FG_ALPHA
0x0010
+#define MDP5_LM_BLEND_COLOR_OUT_STAGE4_FG_ALPHA
0x0020
+#define MDP5_LM_BLEND_COLOR_OUT_STAGE5_FG_ALPHA
0x0040
+#define MDP5_LM_BLEND_COLOR_OUT_STAGE6_FG_ALPHA
0x0080
+#define MDP5_LM_BLEND_COLOR_OUT_SPLIT_LEFT_RIGHT 0x8000
static inline uint32_t REG_MDP5_LM_OUT_SIZE(uint32_t i0) { return 0x0004 +
__offset_LM(i0); }
#define MDP5_LM_OUT_SIZE_HEIGHT__MASK 0x
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 1/9] drm/msm/mdp5: cfg: Add pipe_cursor block
Define the block in advance so that the generated mdp5.xml.h doesn't
break build.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index bd4fe81..b1c7daa 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -85,6 +85,7 @@ struct mdp5_cfg_hw {
struct mdp5_pipe_block pipe_vig;
struct mdp5_pipe_block pipe_rgb;
struct mdp5_pipe_block pipe_dma;
+ struct mdp5_pipe_block pipe_cursor;
struct mdp5_lm_block lm;
struct mdp5_sub_block dspp;
struct mdp5_sub_block ad;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 6/9] drm/msm/mdp5: Misc cursor plane bits
These are various changes in preparation for cursor planes:
- Add a pipe_cursor block for 8x96 in mdp5_cfg.
- Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we
assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR.
- Update mdp5_ctl_blend/ext_blend masks to incorporate cursor SSPPs.
- In mdp5_crtc_atomic_check, make sure that the cursor plane has the
highest zorder, and stage the cursor plane to the maximum stage #
present on the HW.
- Create drm_crtc_funcs that doesn't try to implement cursors using the
older LM cursor HW.
- Pass drm_plane_type in mdp5_plane_init instead of a bool telling
whether plane is primary or not.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 10 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 34 +++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 10 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 7 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c | 8
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 7 ---
drivers/gpu/drm/msm/mdp/mdp_kms.h | 1 +
8 files changed, 74 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 618b2ff..34ab553 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -421,6 +421,16 @@ struct mdp5_cfg_handler {
MDP_PIPE_CAP_SW_PIX_EXT |
0,
},
+ .pipe_cursor = {
+ .count = 2,
+ .base = { 0x34000, 0x36000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+
.lm = {
.count = 6,
.base = { 0x44000, 0x45000, 0x46000, 0x47000, 0x48000, 0x49000
},
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index fec9662..84fcb6e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -400,6 +400,7 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
struct plane_state pstates[STAGE_MAX + 1];
const struct mdp5_cfg_hw *hw_cfg;
const struct drm_plane_state *pstate;
+ bool cursor_plane = false;
int cnt = 0, base = 0, i;
DBG("%s: check", crtc->name);
@@ -409,6 +410,9 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].state = to_mdp5_plane_state(pstate);
cnt++;
+
+ if (plane->type == DRM_PLANE_TYPE_CURSOR)
+ cursor_plane = true;
}
/* assign a stage based on sorted zpos property */
@@ -420,6 +424,10 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
if ((cnt > 0) && !is_fullscreen(state, &pstates[0].state->base))
base++;
+ /* trigger a warning if cursor isn't the highest zorder */
+ WARN_ON(cursor_plane &&
+ (pstates[cnt - 1].plane->type != DRM_PLANE_TYPE_CURSOR));
+
/* verify that there are not too many planes attached to crtc
* and that we don't have conflicting mixer stages:
*/
@@ -431,7 +439,10 @@ static int mdp5_crtc_atomic_check(struct drm_crtc *crtc,
}
for (i = 0; i < cnt; i++) {
- pstates[i].state->stage = STAGE_BASE + i + base;
+ if (cursor_plane && (i == (cnt - 1)))
+ pstates[i].state->stage = hw_cfg->lm.nb_stages;
+ else
+ pstates[i].state->stage = STAGE_BASE + i + base;
DBG("%s: assign pipe %s on stage=%d", crtc->name,
pstates[i].plane->name,
pstates[i].state->stage);
@@ -642,6 +653,16 @@ static int mdp5_crtc_cursor_move(struct drm_crtc *crtc,
int x, int y)
.cursor_move = mdp5_crtc_cursor_move,
};
+static const struct drm_crtc_funcs mdp5_crtc_no_lm_cursor_funcs = {
+ .set_config = drm_atomic_helper_set_config,
+ .destroy = mdp5_crtc_destroy,
+ .page_flip = drm_atomic_helper_page_flip,
+ .set_property = drm_atomic_helper_crtc_set_property,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
static const struct drm_crtc_helper_funcs mdp5_crtc_helper_funcs = {
.mode_set_nofb = mdp5_crtc_mode_set_nofb,
.disable = mdp5_crtc_disable,
@@ -775,7 +796,8 @@ void mdp5_crtc_wait_for_commit_done(struct drm_crtc *crtc)
/* initialize crtc */
struct drm_crtc *mdp5_crtc_init(struct drm_device *dev,
- struct drm_plane *plane, int
[PATCH 4/9] drm/msm/mdp5: Use plane helpers to configure src/dst rectangles
The MDP5 plane's atomic_check ops doesn't perform clipping tests.
This didn't hurt us much in the past, but clipping becomes important
with cursor planes.
Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers
already do. Clipping requires knowledge of the crtc width and height.
This requires us to call drm_atomic_helper_check_modeset before
drm_atomic_helper_check_planes in the driver's atomic_check op,
because check_modetest will populate the mode for the crtc, needed
to populate the clip rectangle.
We also replace the plane_enabled(state) local helper with
state->visible, since they both represent the same thing (i.e, whether
state->fb and state->crtc are non-NULL or not).
One issue with the existing code is that we don't have a way to disable
the plane when it's completely clipped out. Until there isn't an update
on the crtc (which would de-stage the plane), we would still see the
plane in its last 'visible' configuration.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 59 +++
drivers/gpu/drm/msm/msm_atomic.c | 21 +++
2 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 72a9f98..929e58c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -29,10 +29,7 @@ struct mdp5_plane {
static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h);
+ struct drm_rect *src, struct drm_rect *dest);
static void set_scanout_locked(struct drm_plane *plane,
struct drm_framebuffer *fb);
@@ -275,6 +272,7 @@ static void mdp5_plane_cleanup_fb(struct drm_plane *plane,
msm_framebuffer_cleanup(fb, mdp5_kms->id);
}
+#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
static int mdp5_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
@@ -283,11 +281,20 @@ static int mdp5_plane_atomic_check(struct drm_plane
*plane,
struct mdp5_cfg *config = mdp5_cfg_get_config(get_kms(plane)->cfg);
bool new_hwpipe = false;
uint32_t max_width, max_height;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_rect clip;
+ int min_scale, max_scale;
uint32_t caps = 0;
+ int ret;
DBG("%s: check (%d -> %d)", plane->name,
plane_enabled(old_state), plane_enabled(state));
+ crtc = state->crtc ? state->crtc : plane->state->crtc;
+ if (!crtc)
+ return 0;
+
/* We don't allow faster-than-vblank updates.. if we did add this
* some day, we would need to disallow in cases where hwpipe
* changes
@@ -306,7 +313,23 @@ static int mdp5_plane_atomic_check(struct drm_plane *plane,
return -ERANGE;
}
- if (plane_enabled(state)) {
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->adjusted_mode.hdisplay;
+ clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ min_scale = FRAC_16_16(1, 8);
+ max_scale = FRAC_16_16(8, 1);
+
+ ret = drm_plane_helper_check_state(state, &clip, min_scale,
+ max_scale, true, true);
+ if (ret)
+ return ret;
+
+ if (state->visible) {
unsigned int rotation;
const struct mdp_format *format;
struct mdp5_kms *mdp5_kms = get_kms(plane);
@@ -376,15 +399,12 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
mdp5_state->pending = true;
- if (plane_enabled(state)) {
+ if (state->visible) {
int ret;
ret = mdp5_plane_mode_set(plane,
state->crtc, state->fb,
- state->crtc_x, state->crtc_y,
- state->crtc_w, state->crtc_h,
- state->src_x, state->src_y,
- state->src_w, state->src_h);
+ &state->src, &state->dst);
/* atomic_check should have ensured that this doesn't fail */
WARN_ON(ret < 0);
}
@@ -677,10 +697,7 @@ static void mdp5_write_pixel_ext(struct mdp5_kms
*mdp5_kms, enum mdp5_pipe pipe,
static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsi
[PATCH 5/9] drm/msm/mdp5: Configure COLOR3_OUT propagation
In MDP5 Layer Mixer HW, the blender output is only the blended color
components (i.e R, G and B, or COLOR0/1/2 in MDP5 HW terminology). This
is fed to the BG input of the next blender. We also need to provide an
alpha (COLOR3) value for the BG input at the next stage.
This is configured via using the REG_MDP5_LM_BLEND_COLOR_OUT register.
For each stage, we can propagate either the BG or FG alpha to the next
stage.
The approach taken by the driver is to propagate FG alpha, if the plane
staged on that blender has an alpha. If it doesn't, we try to propagate
the base layer's alpha.
This is borrowed from downstream MDP5 kernel driver. Without this, we
don't see any cursor plane content.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 7a47209..fec9662 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -177,6 +177,21 @@ static void mdp5_crtc_destroy(struct drm_crtc *crtc)
kfree(mdp5_crtc);
}
+static inline u32 mdp5_lm_use_fg_alpha_mask(enum mdp_mixer_stage_id stage)
+{
+ switch (stage) {
+ case STAGE0: return MDP5_LM_BLEND_COLOR_OUT_STAGE0_FG_ALPHA;
+ case STAGE1: return MDP5_LM_BLEND_COLOR_OUT_STAGE1_FG_ALPHA;
+ case STAGE2: return MDP5_LM_BLEND_COLOR_OUT_STAGE2_FG_ALPHA;
+ case STAGE3: return MDP5_LM_BLEND_COLOR_OUT_STAGE3_FG_ALPHA;
+ case STAGE4: return MDP5_LM_BLEND_COLOR_OUT_STAGE4_FG_ALPHA;
+ case STAGE5: return MDP5_LM_BLEND_COLOR_OUT_STAGE5_FG_ALPHA;
+ case STAGE6: return MDP5_LM_BLEND_COLOR_OUT_STAGE6_FG_ALPHA;
+ default:
+ return 0;
+ }
+}
+
/*
* blend_setup() - blend all the planes of a CRTC
*
@@ -197,6 +212,8 @@ static void blend_setup(struct drm_crtc *crtc)
unsigned long flags;
enum mdp5_pipe stage[STAGE_MAX + 1] = { SSPP_NONE };
int i, plane_cnt = 0;
+ bool bg_alpha_enabled = false;
+ u32 mixer_op_mode = 0;
#define blender(stage) ((stage) - STAGE0)
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
@@ -218,6 +235,11 @@ static void blend_setup(struct drm_crtc *crtc)
if (!pstates[STAGE_BASE]) {
ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
DBG("Border Color is enabled");
+ } else if (plane_cnt) {
+ format =
to_mdp_format(msm_framebuffer_format(pstates[STAGE_BASE]->base.fb));
+
+ if (format->alpha_enable)
+ bg_alpha_enabled = true;
}
/* The reset for blending */
@@ -232,6 +254,12 @@ static void blend_setup(struct drm_crtc *crtc)
MDP5_LM_BLEND_OP_MODE_BG_ALPHA(BG_CONST);
fg_alpha = pstates[i]->alpha;
bg_alpha = 0xFF - pstates[i]->alpha;
+
+ if (!format->alpha_enable && bg_alpha_enabled)
+ mixer_op_mode = 0;
+ else
+ mixer_op_mode |= mdp5_lm_use_fg_alpha_mask(i);
+
DBG("Stage %d fg_alpha %x bg_alpha %x", i, fg_alpha, bg_alpha);
if (format->alpha_enable && pstates[i]->premultiplied) {
@@ -268,6 +296,8 @@ static void blend_setup(struct drm_crtc *crtc)
blender(i)), bg_alpha);
}
+ mdp5_write(mdp5_kms, REG_MDP5_LM_BLEND_COLOR_OUT(lm), mixer_op_mode);
+
mdp5_ctl_blend(mdp5_crtc->ctl, stage, plane_cnt, ctl_blend_flags);
out:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 7/9] drm/msm/mdp5: Refactor mdp5_plane_atomic_check
In mdp5_plane_atomic_check, we get crtc_state from
drm_plane_state.
Later, for cursor planes, we'll populate the update_plane()
func that takes a fast asynchronous path to implement cursor
movements. There, we would need to call a similar atomic_check
func to validate the plane state, but crtc_state would need to
be derived differently.
Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state
such that the latter takes crtc_state as an argument.
This is similar to what the intel driver has done for async cursor
updates.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 32 +++
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index c813ea7..107bb3a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -273,16 +273,15 @@ static void mdp5_plane_cleanup_fb(struct drm_plane *plane,
}
#define FRAC_16_16(mult, div)(((mult) << 16) / (div))
-static int mdp5_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+static int mdp5_plane_atomic_check_with_state(struct drm_crtc_state
*crtc_state,
+ struct drm_plane_state *state)
{
struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+ struct drm_plane *plane = state->plane;
struct drm_plane_state *old_state = plane->state;
struct mdp5_cfg *config = mdp5_cfg_get_config(get_kms(plane)->cfg);
bool new_hwpipe = false;
uint32_t max_width, max_height;
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
struct drm_rect clip;
int min_scale, max_scale;
uint32_t caps = 0;
@@ -291,10 +290,6 @@ static int mdp5_plane_atomic_check(struct drm_plane *plane,
DBG("%s: check (%d -> %d)", plane->name,
plane_enabled(old_state), plane_enabled(state));
- crtc = state->crtc ? state->crtc : plane->state->crtc;
- if (!crtc)
- return 0;
-
/* We don't allow faster-than-vblank updates.. if we did add this
* some day, we would need to disallow in cases where hwpipe
* changes
@@ -313,10 +308,6 @@ static int mdp5_plane_atomic_check(struct drm_plane *plane,
return -ERANGE;
}
- crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
- if (WARN_ON(!crtc_state))
- return -EINVAL;
-
clip.x1 = 0;
clip.y1 = 0;
clip.x2 = crtc_state->adjusted_mode.hdisplay;
@@ -392,6 +383,23 @@ static int mdp5_plane_atomic_check(struct drm_plane *plane,
return 0;
}
+static int mdp5_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+
+ crtc = state->crtc ? state->crtc : plane->state->crtc;
+ if (!crtc)
+ return 0;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ return mdp5_plane_atomic_check_with_state(crtc_state, state);
+}
+
static void mdp5_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 3/9] drm/msm/mdp5: Prepare CRTC/LM for empty stages
Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for
the drm_plane. Returning '0' means we are returning VIG0 pipe.
Also, use the mdp5_pipe enum to pass around the stage array. Initialize
the stage to SSPP_NONE by default.
We do the above because 1) Cursor plane has to be staged at the topmost
blender of the LM, which can result in empty stages in between 2) In
the future, when we support multiple LMs per CRTC. We could have stages
which don't have any pipe assigned to them.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 1ce8a01..7a47209 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -195,7 +195,7 @@ static void blend_setup(struct drm_crtc *crtc)
uint32_t lm = mdp5_crtc->lm;
uint32_t blend_op, fg_alpha, bg_alpha, ctl_blend_flags = 0;
unsigned long flags;
- uint8_t stage[STAGE_MAX + 1];
+ enum mdp5_pipe stage[STAGE_MAX + 1] = { SSPP_NONE };
int i, plane_cnt = 0;
#define blender(stage) ((stage) - STAGE0)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index d021edc..ab339ce 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -351,8 +351,8 @@ static u32 mdp_ctl_blend_ext_mask(enum mdp5_pipe pipe,
}
}
-int mdp5_ctl_blend(struct mdp5_ctl *ctl, u8 *stage, u32 stage_cnt,
- u32 ctl_blend_op_flags)
+int mdp5_ctl_blend(struct mdp5_ctl *ctl, enum mdp5_pipe *stage, u32 stage_cnt,
+ u32 ctl_blend_op_flags)
{
unsigned long flags;
u32 blend_cfg = 0, blend_ext_cfg = 0;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
index 96148c6..fda00d3 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h
@@ -56,8 +56,8 @@ int mdp5_ctl_set_pipeline(struct mdp5_ctl *ctl, struct
mdp5_interface *intf,
* (call mdp5_ctl_commit() with mdp_ctl_flush_mask_ctl() mask)
*/
#define MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT BIT(0)
-int mdp5_ctl_blend(struct mdp5_ctl *ctl, u8 *stage, u32 stage_cnt,
- u32 ctl_blend_op_flags);
+int mdp5_ctl_blend(struct mdp5_ctl *ctl, enum mdp5_pipe *stage, u32 stage_cnt,
+ u32 ctl_blend_op_flags);
/**
* mdp_ctl_flush_mask...() - Register FLUSH masks
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 75247ea..72a9f98 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -836,7 +836,7 @@ enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane)
struct mdp5_plane_state *pstate = to_mdp5_plane_state(plane->state);
if (WARN_ON(!pstate->hwpipe))
- return 0;
+ return SSPP_NONE;
return pstate->hwpipe->pipe;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
This code has been more or less picked up from the vc4 and intel
implementations of update_plane() funcs for cursor planes.
The update_plane() func is usually the drm_atomic_helper_update_plane
func that will issue an atomic commit with the plane updates. Such
commits are not intended to be done faster than the vsync rate.
The legacy cursor userspace API, on the other hand, expects the kernel
to handle cursor updates immediately.
Create a fast path in update_plane, which updates the cursor registers
and flushes the configuration. The fast path is taken when there is only
a change in the cursor's position in the crtc, or a change in the
cursor's crop co-ordinates. For anything else, we go via the slow path.
We take the slow path even whenever the fb changes, and even when there
is currently no fb tied to the plane. This should hopefully ensure that
we always take a slow path for every new fb. The slow path will ensure
that the fb is prepared/pinned etc.
Cc:
Signed-off-by: Archit Taneja
---
- Don't know what to do for locking here :/
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 7 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 109 +-
3 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 84fcb6e..d0c8b38 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -778,6 +778,13 @@ void mdp5_crtc_set_pipeline(struct drm_crtc *crtc,
mdp5_ctl_set_pipeline(ctl, intf, lm);
}
+struct mdp5_ctl *mdp5_crtc_get_ctl(struct drm_crtc *crtc)
+{
+ struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
+
+ return mdp5_crtc->ctl;
+}
+
int mdp5_crtc_get_lm(struct drm_crtc *crtc)
{
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 5be50c7..d3b728b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -250,6 +250,7 @@ void mdp5_plane_complete_commit(struct drm_plane *plane,
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum drm_plane_type type);
+struct mdp5_ctl *mdp5_crtc_get_ctl(struct drm_crtc *crtc);
uint32_t mdp5_crtc_vblank(struct drm_crtc *crtc);
int mdp5_crtc_get_lm(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 107bb3a..728dad7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,6 +31,14 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
+static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h);
+
static void set_scanout_locked(struct drm_plane *plane,
struct drm_framebuffer *fb);
@@ -246,6 +254,19 @@ static void mdp5_plane_destroy_state(struct drm_plane
*plane,
.atomic_print_state = mdp5_plane_atomic_print_state,
};
+static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
+ .update_plane = mdp5_update_cursor_plane_legacy,
+ .disable_plane = drm_atomic_helper_disable_plane,
+ .destroy = mdp5_plane_destroy,
+ .set_property = drm_atomic_helper_plane_set_property,
+ .atomic_set_property = mdp5_plane_atomic_set_property,
+ .atomic_get_property = mdp5_plane_atomic_get_property,
+ .reset = mdp5_plane_reset,
+ .atomic_duplicate_state = mdp5_plane_duplicate_state,
+ .atomic_destroy_state = mdp5_plane_destroy_state,
+ .atomic_print_state = mdp5_plane_atomic_print_state,
+};
+
static int mdp5_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -873,6 +894,81 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
return ret;
}
+static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
+ struct drm_crtc *crtc, struct drm_framebuffer *fb,
+ int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ struct drm_plane_state *plane_state, *new_plane_state;
+ struct mdp5_plane_state *mdp5_pstate;
+ struct drm_crtc_state *crtc_state = crtc->state;
+
[PATCH 9/9] drm/msm/mdp5: Add cursor planes
Register cursor drm_planes. The loop in modeset_init that inits the
planes and crtcs has to be refactored a bit. We first iterate all the
hwpipes to find the cursor planes. Then, we loop again to create
crtcs.
In msm_atomic_wait_for_commit_done, remove the check which bypasses
waiting for vsyncs if state->legacy_cursor_updates is true. We've created
a fast path for cursor position changes in the cursor plane's update_plane
func that doesn't go via the regular atomic commit path. For rest of
cursor related updates, we have to wait for the vsyncs, so ignore the
legacy_cursor_updates flag.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 32 +---
drivers/gpu/drm/msm/msm_atomic.c| 5 -
2 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 2bebbc2..dce9c23 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -417,7 +417,9 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
struct msm_drm_private *priv = dev->dev_private;
const struct mdp5_cfg_hw *hw_cfg;
unsigned int num_crtcs;
- int i, ret;
+ int i, ret, pi = 0, ci = 0;
+ struct drm_plane *primary[6] = { NULL };
+ struct drm_plane *cursor[6] = { NULL };
hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
@@ -444,13 +446,14 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
* planes for the CRTCs, with the remainder as overlay planes:
*/
for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
- bool primary = i < num_crtcs;
+ struct mdp5_hw_pipe *hwpipe = mdp5_kms->hwpipes[i];
struct drm_plane *plane;
- struct drm_crtc *crtc;
enum drm_plane_type type;
- if (primary)
+ if (i < num_crtcs)
type = DRM_PLANE_TYPE_PRIMARY;
+ else if (hwpipe->caps & MDP_PIPE_CAP_CURSOR)
+ type = DRM_PLANE_TYPE_CURSOR;
else
type = DRM_PLANE_TYPE_OVERLAY;
@@ -462,10 +465,16 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
priv->planes[priv->num_planes++] = plane;
- if (!primary)
- continue;
+ if (type == DRM_PLANE_TYPE_PRIMARY)
+ primary[pi++] = plane;
+ if (type == DRM_PLANE_TYPE_CURSOR)
+ cursor[ci++] = plane;
+ }
+
+ for (i = 0; i < num_crtcs; i++) {
+ struct drm_crtc *crtc;
- crtc = mdp5_crtc_init(dev, plane, NULL, i);
+ crtc = mdp5_crtc_init(dev, primary[i], cursor[i], i);
if (IS_ERR(crtc)) {
ret = PTR_ERR(crtc);
dev_err(dev->dev, "failed to construct crtc %d (%d)\n",
i, ret);
@@ -797,6 +806,9 @@ static int hwpipe_init(struct mdp5_kms *mdp5_kms)
static const enum mdp5_pipe dma_planes[] = {
SSPP_DMA0, SSPP_DMA1,
};
+ static const enum mdp5_pipe cursor_planes[] = {
+ SSPP_CURSOR0, SSPP_CURSOR1,
+ };
const struct mdp5_cfg_hw *hw_cfg;
int ret;
@@ -820,6 +832,12 @@ static int hwpipe_init(struct mdp5_kms *mdp5_kms)
if (ret)
return ret;
+ /* Construct cursor pipes: */
+ ret = construct_pipes(mdp5_kms, hw_cfg->pipe_cursor.count,
cursor_planes,
+ hw_cfg->pipe_cursor.base, hw_cfg->pipe_cursor.caps);
+ if (ret)
+ return ret;
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 6924fa2..9633a68b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -93,11 +93,6 @@ static void msm_atomic_wait_for_commit_done(struct
drm_device *dev,
if (!crtc->state->enable)
continue;
- /* Legacy cursor ioctls are completely unsynced, and userspace
-* relies on that (by doing tons of cursor updates). */
- if (old_state->legacy_cursor_update)
- continue;
-
kms->funcs->wait_for_crtc_commit_done(kms, crtc);
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
i915 regression in kernel 4.10
On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote: > With recent 4.10 kernel the graphics isn't coming up under Xen. First > failure message is: > > [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes) Do we get a silent failure? i915_gem_gtt_prepare_pages() is where we call dma_map_sg() and pass the sg to swiotlb (in this case) for remapping, and we do check for an error value of 0. After that error, SWIOTLB_MAP_ERROR is propagated back and converted to 0 for dma_map_sg(). That looks valid, and we should report ENOMEM back to the caller. > Later I see splats like: > > [ 49.393583] general protection fault: [#1] SMP What was the faulting address? RAX is particularly non-pointer-like so I wonder if we walked onto an uninitialised portion of the sgtable. We may have tripped over a bug in our sg_page iterator. The attached patch should prevent an early ENOMEM following the swiotlb allocation failure. But I suspect that we will still be tripping up the failure in the sg walker when binding to the GPU. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-i915-Fallback-to-single-PAGE_SIZE-segments-for-D.patch Type: text/x-diff Size: 2486 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/68ef548d/attachment.patch>
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
Op 19-12-16 om 13:08 schreef Archit Taneja: > This code has been more or less picked up from the vc4 and intel > implementations of update_plane() funcs for cursor planes. > > The update_plane() func is usually the drm_atomic_helper_update_plane > func that will issue an atomic commit with the plane updates. Such > commits are not intended to be done faster than the vsync rate. > > The legacy cursor userspace API, on the other hand, expects the kernel > to handle cursor updates immediately. > > Create a fast path in update_plane, which updates the cursor registers > and flushes the configuration. The fast path is taken when there is only > a change in the cursor's position in the crtc, or a change in the > cursor's crop co-ordinates. For anything else, we go via the slow path. > > We take the slow path even whenever the fb changes, and even when there > is currently no fb tied to the plane. This should hopefully ensure that > we always take a slow path for every new fb. The slow path will ensure > that the fb is prepared/pinned etc. > > Cc: > Signed-off-by: Archit Taneja > --- > - Don't know what to do for locking here :/ Shouldn't patch 9 be done first before 8? ~Maarten
[PATCH v3 01/38] drm/i915: Use the MRU stack search after evicting
On Fri, Dec 16, 2016 at 07:25:13PM +, Chris Wilson wrote: > When we evict from the GTT to make room for an object, the hole we > create is put onto the MRU stack inside the drm_mm range manager. On the > next search pass, we can speed up a PIN_HIGH allocation by referencing > that stack for the new hole. > > v2: Pull together the 3 identical implements (ahem, a couple were > outdated) into a common routine for allocating a node and evicting as > necessary. On noes, I realized that I have used the correct spelling of colour. Needs a s/colour/color/ for consistency. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm: tilcdc: simplify the recovery from sync lost error on rev1
One comment bellow.
On 12/13/16 17:07, Bartosz Golaszewski wrote:
> Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
> caused by limited memory bandwidth may leave the picture shifted a
> couple pixels to the right.
>
> This issue has not been observed on revision 1, while the recovery
> mechanism introduces a different issue, where the END_OF_FRAME
> interrupt doesn't fire while drm is waiting for vblanks.
>
> On rev1: recover from sync lost errors by simply clearing the
> RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
> again as is suggested by the datasheet.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 24 +++-
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 9942b05..70e57a7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -921,17 +921,23 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
> dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
> __func__, stat);
> tilcdc_crtc->frame_intact = false;
> - if (tilcdc_crtc->sync_lost_count++ >
> - SYNC_LOST_COUNT_LIMIT) {
> - dev_err(dev->dev, "%s(0x%08x): Sync lost flood
> detected, recovering", __func__, stat);
> - queue_work(system_wq, &tilcdc_crtc->recover_work);
> - if (priv->rev == 1)
> - tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> - LCDC_V1_SYNC_LOST_INT_ENA);
> - else
> + if (priv->rev == 1) {
I would add here:
+ if ((tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
+ LCDC_RASTER_ENABLE)) {
> + tilcdc_clear(dev,
> + LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> + tilcdc_set(dev,
> +LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+ }
Just in case the interrupt is for some reason handled right after the
crtc is disabled.
With this addition I could send a pull request for this fix still today,
if you agree with the change.
> + } else {
> + if (tilcdc_crtc->sync_lost_count++ >
> + SYNC_LOST_COUNT_LIMIT) {
> + dev_err(dev->dev,
> + "%s(0x%08x): Sync lost flood detected,
> recovering",
> + __func__, stat);
> + queue_work(system_wq,
> +&tilcdc_crtc->recover_work);
> tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
>LCDC_SYNC_LOST);
> - tilcdc_crtc->sync_lost_count = 0;
> + tilcdc_crtc->sync_lost_count = 0;
> + }
> }
> }
>
>
[PATCH v2 1/3] drm: Add SCDC helpers
- dri-devel at lists.kernel.org + dri-devel at lists.freedesktop.org Regards Shashank -Original Message- From: Sharma, Shashank [mailto:shashank.sha...@intel.com] Sent: Monday, December 19, 2016 7:00 PM To: Thierry Reding ; dri-devel at lists.kernel.org Cc: Jani Nikula ; Ville Syrjälä ; Jose Abreu Subject: Re: [PATCH v2 1/3] drm: Add SCDC helpers Regards Shashank On 12/3/2016 12:52 AM, Thierry Reding wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access the SCDC and provides the > symbolic names for the various registers defined in the specification. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - indent register field definitions for readability (Ville Syrjälä) > - use GFP_TEMPORARY for temporary buffer allocation (Jani Nikula) > > Documentation/gpu/drm-kms-helpers.rst | 12 > drivers/gpu/drm/Kconfig | 4 ++ > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/drm_scdc_helper.c | 111 > include/drm/drm_scdc_helper.h | 132 > ++ > 5 files changed, 260 insertions(+) > create mode 100644 drivers/gpu/drm/drm_scdc_helper.c > create mode 100644 include/drm/drm_scdc_helper.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 03040aa14fe8..759275629fcf 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -217,6 +217,18 @@ EDID Helper Functions Reference > .. kernel-doc:: drivers/gpu/drm/drm_edid.c > :export: > > +SCDC Helper Functions Reference > +=== > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :doc: scdc helpers > + > +.. kernel-doc:: include/drm/drm_scdc_helper.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :export: > + > Rectangle Utilities Reference > = > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index > 95fc0410e129..d0031fe45bab 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -84,6 +84,10 @@ config DRM_FBDEV_EMULATION > > If in doubt, say "Y". > > +config DRM_SCDC > + bool > + depends on DRM_KMS_HELPER > + > config DRM_LOAD_EDID_FIRMWARE > bool "Allow to specify an EDID data set instead of probing for it" > depends on DRM_KMS_HELPER > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > 883f3e75cfbc..71c38b6dd546 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -31,6 +31,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_probe_helper.o \ > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \ > drm_simple_kms_helper.o drm_modeset_helper.o > > +drm_kms_helper-$(CONFIG_DRM_SCDC) += drm_scdc_helper.o > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o > drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o > diff --git a/drivers/gpu/drm/drm_scdc_helper.c > b/drivers/gpu/drm/drm_scdc_helper.c > new file mode 100644 > index ..fe0e1211e873 > --- /dev/null > +++ b/drivers/gpu/drm/drm_scdc_helper.c > @@ -0,0 +1,111 @@ > +/* > + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved. 2016 Now in copyright notice ? > + * > + * Permission is hereby granted, free of charge, to any person > + obtaining a > + * copy of this software and associated documentation files (the > + "Software"), > + * to deal in the Software without restriction, including without > + limitation > + * the rights to use, copy, modify, merge, publish, distribute, sub > + license, > + * and/or sell copies of the Software, and to permit persons to whom > + the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including > + the > + * next paragraph) shall be included in all copies or substantial > + portions > + * of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > + MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT > + SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES > + OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + OTHER > + * DEALINGS IN THE SOFTWARE. > + */ > + > +#include > + > +#include > + > +/** > + * DOC: scdc helpers > + * > + * Status and Control Data Channel (SCDC) is a mechanism introduced > +by the > + * HDMI
[Bug 99049] Machine freeze when clock are set to defaults
https://bugs.freedesktop.org/show_bug.cgi?id=99049 Maxime Daniel changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/283ec744/attachment.html>
[Bug 99049] Machine freeze when clock are set to defaults
https://bugs.freedesktop.org/show_bug.cgi?id=99049 Maxime Daniel changed: What|Removed |Added Severity|normal |major Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/e508806a/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #4 from Dorota Czaplejewicz --- Created attachment 128544 --> https://bugs.freedesktop.org/attachment.cgi?id=128544&action=edit Dmesg log with applied patch from comment #3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/9ff831b1/attachment.html>
[Bug 99049] Machine freeze when clocks are set to defaults
https://bugs.freedesktop.org/show_bug.cgi?id=99049 Maxime Daniel changed: What|Removed |Added Summary|Machine freeze when clock |Machine freeze when clocks |are set to defaults |are set to defaults -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/e3d4c95d/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #5 from Dorota Czaplejewicz --- The same config option triggers failures in a similar way in: igt/gem_sync/basic-each igt/gem_sync/basic-store-each -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/4e52966a/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #6 from Dorota Czaplejewicz --- Created attachment 128545 --> https://bugs.freedesktop.org/attachment.cgi?id=128545&action=edit igt/gem_sync/basic-each log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/3de77b98/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #7 from Dorota Czaplejewicz --- Created attachment 128546 --> https://bugs.freedesktop.org/attachment.cgi?id=128546&action=edit igt/gem_sync/basic-each - dmesg (truncated beginning) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/ebc24d09/attachment-0001.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #8 from Dorota Czaplejewicz --- Created attachment 128547 --> https://bugs.freedesktop.org/attachment.cgi?id=128547&action=edit igt/gem_sync/basic-store-each - log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/0f23eb48/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #9 from Dorota Czaplejewicz --- Created attachment 128548 --> https://bugs.freedesktop.org/attachment.cgi?id=128548&action=edit igt/gem_sync/basic-store-each - dmesg (truncated beginning) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/06d87208/attachment.html>
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #10 from Chris Wilson --- [ 154.074065] [drm:drm_ioctl] pid=2323, dev=0xe200, auth=1, I915_GEM_WAIT [ 154.074748] i915_gem_wait_ioctl: timeout 0.5 -> 0.43351 [ 154.075390] [drm:drm_ioctl] ret = -512 ... [ 155.072528] [drm:drm_ioctl] pid=2323, dev=0xe200, auth=1, I915_GEM_WAIT [ 155.073234] i915_gem_wait_ioctl: timeout 0.488539596 -> 0.488535373 [ 155.073916] [drm:drm_ioctl] ret = -512 [ 155.074605] [drm:drm_ioctl] pid=2323, dev=0xe200, auth=1, I915_GEM_WAIT [ 155.075307] i915_gem_wait_ioctl: timeout 0.488535373 -> 0.488532529 Walltime of 1s, but actual wait time of ~12ms. Each ioctl is taking ~1.4ms (inside drmIoctl) with a further interval of ~0.7ms between ioctls. And we account for 3us. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/d2e5133a/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 #143 from Harald Judt --- I have merged https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.10-wip into 4.9 and am now using amdgpu with the r9 390, and everything works great so far except that the cursor is no longer visible after hibernating and resuming, but switching to SWCursor resolves this, so this is a viable workaround. I will open another bug for this, but it is only a minor issue for me. With radeon, DPM still fails to resume properly for the 390 after hibernation. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/d7fce248/attachment.html>
[Bug 99143] r9 390: Hardware cursor invisible after hibernate/resume
https://bugs.freedesktop.org/show_bug.cgi?id=99143 Bug ID: 99143 Summary: r9 390: Hardware cursor invisible after hibernate/resume Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: h.judt at gmx.at I have merged https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.10-wip into 4.9, as this solves the failures to hibernate/resume on my machine with the r9 390. The only problem with hibernation left now is that the HW cursor vanishes after hibernating and resuming. Widgets still get focused, only the cursor is no longer visible. Switching to software cursor as a workaround solves this. lspci: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290/390] (rev 80) 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii HDMI Audio [Radeon R9 290/290X / 390/390X] Using xorg-server-1.18.4, libdrm-git, mesa-git and xf86-video-amdgpu-git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/6d2d7acc/attachment.html>
[PATCH] drm: tilcdc: simplify the recovery from sync lost error on rev1
2016-12-19 14:09 GMT+01:00 Jyri Sarha :
> One comment bellow.
>
> On 12/13/16 17:07, Bartosz Golaszewski wrote:
>> Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
>> caused by limited memory bandwidth may leave the picture shifted a
>> couple pixels to the right.
>>
>> This issue has not been observed on revision 1, while the recovery
>> mechanism introduces a different issue, where the END_OF_FRAME
>> interrupt doesn't fire while drm is waiting for vblanks.
>>
>> On rev1: recover from sync lost errors by simply clearing the
>> RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
>> again as is suggested by the datasheet.
>>
>> Signed-off-by: Bartosz Golaszewski
>> ---
>> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 24 +++-
>> 1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>> index 9942b05..70e57a7 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
>> @@ -921,17 +921,23 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
>> dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
>> __func__, stat);
>> tilcdc_crtc->frame_intact = false;
>> - if (tilcdc_crtc->sync_lost_count++ >
>> - SYNC_LOST_COUNT_LIMIT) {
>> - dev_err(dev->dev, "%s(0x%08x): Sync lost flood
>> detected, recovering", __func__, stat);
>> - queue_work(system_wq, &tilcdc_crtc->recover_work);
>> - if (priv->rev == 1)
>> - tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
>> - LCDC_V1_SYNC_LOST_INT_ENA);
>> - else
>> + if (priv->rev == 1) {
>
> I would add here:
> + if ((tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
> + LCDC_RASTER_ENABLE)) {
>
>> + tilcdc_clear(dev,
>> + LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
>> + tilcdc_set(dev,
>> +LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> + }
>
> Just in case the interrupt is for some reason handled right after the
> crtc is disabled.
>
> With this addition I could send a pull request for this fix still today,
> if you agree with the change.
I'm not sure this can really happen, but it won't hurt either, so I'll
send a v2.
Thanks,
Bartosz
[PATCH] drm: parse hf-vsdb
nfo->scrambling = true;
>> +if (db[6] & DRM_HFVSDB_INDEPENDENT_VIEW)
>> +info->independent_view_3d = true;
>> +if (db[6] & DRM_HFVSDB_DUAL_VIEW)
>> +info->dual_view_3d = true;
>> +if (db[6] & DRM_HFVSDB_3D_OSD)
>> +info->osd_disparity_3d = true;
>> +
>> +drm_parse_yuv420_deep_color_info(connector, db);
>> +}
>> +
>> static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
>> const u8 *hdmi)
>> {
>> @@ -3881,6 +3952,8 @@ static void drm_parse_cea_ext(struct drm_connector
>> *connector,
>>
>> if (cea_db_is_hdmi_vsdb(db))
>> drm_parse_hdmi_vsdb_video(connector, db);
>> +if (cea_db_is_hf_vsdb(db))
>> +drm_parse_hf_vsdb(connector, db);
>> }
>> }
>>
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 34f9741..d011dd5 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -167,6 +167,46 @@ struct drm_display_info {
>> */
>> u32 bus_flags;
>>
>> +#define DRM_HFVSDB_SCDC_SUPPORT (1<<7)
>> +#define DRM_HFVSDB_SCDC_RR_CAP (1<<6)
>> +#define DRM_HFVSDB_SCRAMBLING (1<<3)
>> +#define DRM_HFVSDB_INDEPENDENT_VIEW (1<<2)
>> +#define DRM_HFVSDB_DUAL_VIEW(1<<1)
>> +#define DRM_HFVSDB_3D_OSD (1<<0)
> This looks to me like the wrong place for these defines. They should
> probably go into include/drm/drm_edid.h instead.
I saw few other defines in this same structure, like
DRM_COLOR_FORMAT_RGB444 etc, so thought this would
be the right place.
>
>> +
>> +/**
>> + * @scdc_supported: Sink supports SCDC functionality.
>> + */
>> +bool scdc_supported;
>> +
>> +/**
>> + * @scdc_rr_cap: Sink has SCDC read request capability.
>> + */
>> +bool scdc_rr_cap;
>> +
>> +/**
>> + * @scrambling: Sync supports scrambling for <=340 Mcsc TMDS
>> + * char rates. Above 340 Mcsc rates, scrambling is always reqd.
>> + */
>> +bool scrambling;
>> +
>> +/**
>> + * @independent_view_3d: Sink supports 3d independent view signaling
>> + * in HF-VSIF.
>> + */
>> +bool independent_view_3d;
>> +
>> +/**
>> + * @dual_view_3d: Sink supports 3d dual view signaling in HF-VSIF.
>> + */
>> +bool dual_view_3d;
>> +
>> +/**
>> + * @osd_disparity_3d: Sink supports 3d osd disparity indication
>> + * in HF-VSIF.
>> + */
>> +bool osd_disparity_3d;
>> +
>> /**
>> * @max_tmds_clock: Maximum TMDS clock rate supported by the
>> * sink in kHz. 0 means undefined.
>> @@ -185,6 +225,14 @@ struct drm_display_info {
>> u8 edid_hdmi_dc_modes;
>>
>> /**
>> + * @edid_yuv420_dc_modes: bpc for deep color yuv420 encoding.
>> + * various sinks can support 10/12/16 bit per channel deep
>> + * color encoding. edid_yuv420_dc_modes = 0 means sink doesn't
>> + * support deep color yuv420 encoding.
>> + */
>> +u8 edid_yuv420_dc_modes;
> Why not store the additional formats in the edid_hdmi_dc_modes field?
Now, as per our discussion in mail thread, I will create nested
drm_hdmi_info within drm_display_info and add it there.
>
>> +
>> +/**
>> * @cea_rev: CEA revision of the HDMI sink.
>> */
>> u8 cea_rev;
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> index 38eabf6..5df8b9c 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -212,6 +212,11 @@ struct detailed_timing {
>> #define DRM_EDID_HDMI_DC_30 (1 << 4)
>> #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
>>
>> +/* YUV 420 deep color modes */
>> +#define DRM_EDID_YUV420_DC_48 (1 << 6)
>> +#define DRM_EDID_YUV420_DC_36 (1 << 5)
>> +#define DRM_EDID_YUV420_DC_30 (1 << 5)
> 36- and 30-bit depths have the same value. That probably wasn't
> intended.
Oops, thanks for pointing this out.
> Thierry
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/b9038b63/attachment-0001.html>
[PATCH v2] drm: tilcdc: simplify the recovery from sync lost error on rev1
Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
caused by limited memory bandwidth may leave the picture shifted a
couple pixels to the right.
This issue has not been observed on revision 1, while the recovery
mechanism introduces a different issue, where the END_OF_FRAME
interrupt doesn't fire while drm is waiting for vblanks.
On rev1: recover from sync lost errors by simply clearing the
RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
again as is suggested by the datasheet.
Signed-off-by: Bartosz Golaszewski
---
v1 -> v2:
- add a check to see if the RASTER_ENABLE bit is set before clearing it
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 9942b05..2004107 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -856,7 +856,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
- uint32_t stat;
+ uint32_t stat, reg;
stat = tilcdc_read_irqstatus(dev);
tilcdc_clear_irqstatus(dev, stat);
@@ -921,17 +921,26 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
__func__, stat);
tilcdc_crtc->frame_intact = false;
- if (tilcdc_crtc->sync_lost_count++ >
- SYNC_LOST_COUNT_LIMIT) {
- dev_err(dev->dev, "%s(0x%08x): Sync lost flood
detected, recovering", __func__, stat);
- queue_work(system_wq, &tilcdc_crtc->recover_work);
- if (priv->rev == 1)
+ if (priv->rev == 1) {
+ reg = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
+ if (reg & LCDC_RASTER_ENABLE) {
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
-LCDC_V1_SYNC_LOST_INT_ENA);
- else
+LCDC_RASTER_ENABLE);
+ tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
+ LCDC_RASTER_ENABLE);
+ }
+ } else {
+ if (tilcdc_crtc->sync_lost_count++ >
+ SYNC_LOST_COUNT_LIMIT) {
+ dev_err(dev->dev,
+ "%s(0x%08x): Sync lost flood detected,
recovering",
+ __func__, stat);
+ queue_work(system_wq,
+ &tilcdc_crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
LCDC_SYNC_LOST);
- tilcdc_crtc->sync_lost_count = 0;
+ tilcdc_crtc->sync_lost_count = 0;
+ }
}
}
--
2.9.3
[PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote: >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote: >> > On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote: >> >> On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote: >> >>> On Monday 21 Nov 2016 10:48:15 Rob Herring wrote: >> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote: >> > Document properties common to several display panels in a central >> > location that can be referenced by the panel device tree bindings. >> >> Looks good. Just one comment... >> >> [...] >> >> > +Connectivity >> > + >> > + >> > +- ports: Panels receive video data through one or multiple >> > connections. While >> > + the nature of those connections is specific to the panel type, the >> > + connectivity is expressed in a standard fashion using ports as >> > specified in >> > + the device graph bindings defined in >> > + Documentation/devicetree/bindings/graph.txt. >> >> We allow panels to either use graph binding or be a child of the >> display controller. >> >>> >> >>> I knew that some display controllers use a phandle to the panel (see >> >>> the fsl,panel and nvidia,panel properties), but I didn't know we had >> >>> panels as children of display controller nodes. I don't think we should >> >>> allow that for anything but DSI panels, as the DT hierarchy is based on >> >>> control buses. Are you sure we have other panels instantiated through >> >>> that mechanism ? >> > >> > Some panels have no control bus, so were do we place them? >> >> I'd say under the root node, like all similar control-less devices. >> >> > I would say the hierarchy is based on buses with a preference for the >> > control bus when there are multiple buses. I'm not a fan of just sticking >> > things are the top level. >> >> OK, so much for my comment a few lines up :-) >> >> The problem with placing non-DSI panels as children of the display >> controller and not using OF graph is that the panel bindings become >> dependent of the display controller being used. A display controller using >> OF graph would require the panel to do the same, while a display controller >> expecting a panel child node (with a specific name) would require DT >> properties for the panel node. Not sure I follow. They become dependent on the controller driver to probe the panel, but the contents of the panel node would not be controller dependent. >> I'm also not sure the complexity of OF graph is really that prohibitive if >> you compare it to panels as child nodes. To get the panel driver to bind to >> the panel DT node the display controller driver would need to create a >> platform device for the panel and register it. That's not very difficult, >> but parsing a single port and endpoint isn't either (and we could even >> provide a helper function for that, a version of of_drm_find_panel() that >> would take as an argument the display controller device node instead of the >> panel device node). > > Ping ? > > I'd like to standardize on one model for panel DT bindings, but I'm not sure > that can be achieved given that we already have multiple competing models. In > any case, is that blocking to merge this patch ? I only describe one > connectivity model here as that's what my panel driver needs, but I have no > issue adding more models later when needed. I believe this patch is a good > step forward already. It is an improvement which I appreciate, so yes I guess we can address it later when needed. Rob
[PATCH 0/9] drm/msm/mdp5: Cursor plane stuff
On Mon, Dec 19, 2016 at 05:38:49PM +0530, Archit Taneja wrote: > This series does some mdp5_plane related clean ups (use plane helpers > for clipping etc), adds MDP5 bits needed for cursor plane blocks, and > then add cursor planes. > > On older MDP5 versions, we had cursor HW in Layer Mixer blocks, and > that's implemented in mdp5_crtc.c. With newer hardware, the cursor > blocks look exactly like MDP5 pipes (SSPPs). > > The "faster than vblank cursor position update stuff" has been > copied from vc4 and the patches posted recently by Maarten for Intel: > > https://patchwork.kernel.org/patch/9466417/ > > I've tried this with some X11 UI and modetest -C, and it seems to > work okay. Are there any tests that mix up atomic commits and legacy > cursor updates a lot to identify issues? kms_legacy_cursor mixes cursor updates with page_flips (and if you use atomic for those, atomic flips ofcourse). But the test is a bit too oveager and even expects cursor updates vs. modesets to not block. Not sure Maarten fixed that already. -Daniel > > Archit Taneja (9): > drm/msm/mdp5: cfg: Add pipe_cursor block > drm/msm/mdp5: Update generated headers > drm/msm/mdp5: Prepare CRTC/LM for empty stages > drm/msm/mdp5: Use plane helpers to configure src/dst rectangles > drm/msm/mdp5: Configure COLOR3_OUT propagation > drm/msm/mdp5: Misc cursor plane bits > drm/msm/mdp5: Refactor mdp5_plane_atomic_check > HACK: drm/msm/mdp5: Add support for legacy cursor updates > drm/msm/mdp5: Add cursor planes > > drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 30 +++-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 10 ++ > drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 1 + > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 73 +++- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 14 ++- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 4 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 38 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 8 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c | 8 ++ > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 181 > ++ > drivers/gpu/drm/msm/mdp/mdp_kms.h | 1 + > drivers/gpu/drm/msm/msm_atomic.c | 26 +++-- > 12 files changed, 334 insertions(+), 60 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
On Mon, Dec 19, 2016 at 05:38:57PM +0530, Archit Taneja wrote:
> This code has been more or less picked up from the vc4 and intel
> implementations of update_plane() funcs for cursor planes.
>
> The update_plane() func is usually the drm_atomic_helper_update_plane
> func that will issue an atomic commit with the plane updates. Such
> commits are not intended to be done faster than the vsync rate.
>
> The legacy cursor userspace API, on the other hand, expects the kernel
> to handle cursor updates immediately.
>
> Create a fast path in update_plane, which updates the cursor registers
> and flushes the configuration. The fast path is taken when there is only
> a change in the cursor's position in the crtc, or a change in the
> cursor's crop co-ordinates. For anything else, we go via the slow path.
>
> We take the slow path even whenever the fb changes, and even when there
> is currently no fb tied to the plane. This should hopefully ensure that
> we always take a slow path for every new fb. The slow path will ensure
> that the fb is prepared/pinned etc.
>
> Cc:
> Signed-off-by: Archit Taneja
I wonder whether it's time to extract this pattern into some helpers. I
think a combo of async_check and async_flip callbacks on planes should do
the trick and integrate somewhat into atomic overall. amdgpu also needs
this for async flips on the primary plane.
Both async_check and async_flip would take only (struct drm_plane *plane,
struct drm_plane_state *state) as arguments. Maybe we should even wrap
that up into an struct drm_async_flip so that we can add more stuff in the
future.
But all still a bit unclear to me.
> ---
> - Don't know what to do for locking here :/
>
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 7 ++
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 109
> +-
> 3 files changed, 114 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index 84fcb6e..d0c8b38 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -778,6 +778,13 @@ void mdp5_crtc_set_pipeline(struct drm_crtc *crtc,
> mdp5_ctl_set_pipeline(ctl, intf, lm);
> }
>
> +struct mdp5_ctl *mdp5_crtc_get_ctl(struct drm_crtc *crtc)
> +{
> + struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
> +
> + return mdp5_crtc->ctl;
> +}
> +
> int mdp5_crtc_get_lm(struct drm_crtc *crtc)
> {
> struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> index 5be50c7..d3b728b 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> @@ -250,6 +250,7 @@ void mdp5_plane_complete_commit(struct drm_plane *plane,
> struct drm_plane *mdp5_plane_init(struct drm_device *dev,
> enum drm_plane_type type);
>
> +struct mdp5_ctl *mdp5_crtc_get_ctl(struct drm_crtc *crtc);
> uint32_t mdp5_crtc_vblank(struct drm_crtc *crtc);
>
> int mdp5_crtc_get_lm(struct drm_crtc *crtc);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 107bb3a..728dad7 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -31,6 +31,14 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> struct drm_crtc *crtc, struct drm_framebuffer *fb,
> struct drm_rect *src, struct drm_rect *dest);
>
> +static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
> + struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> + uint32_t src_x, uint32_t src_y,
> + uint32_t src_w, uint32_t src_h);
> +
> static void set_scanout_locked(struct drm_plane *plane,
> struct drm_framebuffer *fb);
>
> @@ -246,6 +254,19 @@ static void mdp5_plane_destroy_state(struct drm_plane
> *plane,
> .atomic_print_state = mdp5_plane_atomic_print_state,
> };
>
> +static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
> + .update_plane = mdp5_update_cursor_plane_legacy,
> + .disable_plane = drm_atomic_helper_disable_plane,
> + .destroy = mdp5_plane_destroy,
> + .set_property = drm_atomic_helper_plane_set_property,
> + .atomic_set_property = mdp5_plane_atomic_set_property,
> + .atomic_get_property = mdp5_plane_atomic_get_property,
> + .reset = mdp5_plane_reset,
> + .atomic_duplicate_state = mdp5_plane_duplicate_state,
> + .atomic_destroy_state = mdp5_plane_destroy_state,
> + .atomic_print_state = mdp5_plane_atomic_print_state,
> +};
> +
> static int mdp5_plane_
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 leoxsliu at gmail.com changed: What|Removed |Added CC||leoxsliu at gmail.com --- Comment #3 from leoxsliu at gmail.com --- Created attachment 128558 --> https://bugs.freedesktop.org/attachment.cgi?id=128558&action=edit Bonaire UVD firmware Please try attached Bonaire UVD firmware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/868f4301/attachment.html>
[PATCH] drm: tilcdc: simplify the recovery from sync lost error on rev1
On 12/19/16 16:19, Bartosz Golaszewski wrote:
>> I would add here:
>> + if ((tilcdc_read(dev, LCDC_RASTER_CTRL_REG) &
>> + LCDC_RASTER_ENABLE)) {
>>
>>> + tilcdc_clear(dev,
>>> + LCDC_RASTER_CTRL_REG,
>>> LCDC_RASTER_ENABLE);
>>> + tilcdc_set(dev,
>>> +LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
>> + }
>>
>> Just in case the interrupt is for some reason handled right after the
>> crtc is disabled.
>>
>> With this addition I could send a pull request for this fix still today,
>> if you agree with the change.
> I'm not sure this can really happen, but it won't hurt either, so I'll
> send a v2.
Well, in theory it is quite possible. If the driver clears the raster
enable at the same time when sync lost interrupt is generated, then the
irq routine handles the irq before the interrupts are disabled. Then it
happens that rastere remains on but the driver thinks it has already
turned it off.
In practice this is of course terribly unlikely, but a race is a race
and should be avoided.
Anyway, my vacation has already been started so I won't send a pull
request now. I do not like the idea of doing something like that and
then vanishing for two weeks. I hope they still take fixes for 4.10 in
4th Jan.
Best regards,
Jyri
[RFC 8/9] HACK: drm/msm/mdp5: Add support for legacy cursor updates
On Mon, Dec 19, 2016 at 05:00:49PM +0100, Daniel Vetter wrote:
> On Mon, Dec 19, 2016 at 05:38:57PM +0530, Archit Taneja wrote:
> > @@ -873,6 +894,81 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> > return ret;
> > }
> >
> > +static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
> > + struct drm_crtc *crtc, struct drm_framebuffer *fb,
> > + int crtc_x, int crtc_y,
> > + unsigned int crtc_w, unsigned int crtc_h,
> > + uint32_t src_x, uint32_t src_y,
> > + uint32_t src_w, uint32_t src_h)
> > +{
> > + struct drm_plane_state *plane_state, *new_plane_state;
> > + struct mdp5_plane_state *mdp5_pstate;
> > + struct drm_crtc_state *crtc_state = crtc->state;
> > + int ret;
> > +
> > + if (!crtc_state->active || drm_atomic_crtc_needs_modeset(crtc_state))
>
> Until you do some kind of normal flip on the primary after a modeset no
> one will ever change the needs_modeset(crtc_state) if you only ever do
> async flips. Sounds like a bug, and vc4 doesn't check for it. Why do you
> need this?
Self-correct: The slow-path will duplicate the crtc state also and clear
needs_modeset, which means only the very first cursor move after a modeset
will be slow. I think that's ok.
But this kind of trickery is a good reason to try to extract this logic a
bit better I think.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 01/13] devicetree/bindings: display: Document common panel properties
Hi Rob, On Monday 19 Dec 2016 09:38:49 Rob Herring wrote: > On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote: > > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote: > >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote: > >>> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote: > On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote: > > On Monday 21 Nov 2016 10:48:15 Rob Herring wrote: > >> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote: > >>> Document properties common to several display panels in a central > >>> location that can be referenced by the panel device tree bindings. > >> > >> Looks good. Just one comment... > >> > >> [...] > >> > >>> +Connectivity > >>> + > >>> + > >>> +- ports: Panels receive video data through one or multiple > >>> connections. While > >>> + the nature of those connections is specific to the panel type, > >>> the > >>> + connectivity is expressed in a standard fashion using ports as > >>> specified in > >>> + the device graph bindings defined in > >>> + Documentation/devicetree/bindings/graph.txt. > >> > >> We allow panels to either use graph binding or be a child of the > >> display controller. > > > > I knew that some display controllers use a phandle to the panel (see > > the fsl,panel and nvidia,panel properties), but I didn't know we had > > panels as children of display controller nodes. I don't think we > > should allow that for anything but DSI panels, as the DT hierarchy is > > based on control buses. Are you sure we have other panels instantiated > > through that mechanism ? > >>> > >>> Some panels have no control bus, so were do we place them? > >> > >> I'd say under the root node, like all similar control-less devices. > >> > >>> I would say the hierarchy is based on buses with a preference for the > >>> control bus when there are multiple buses. I'm not a fan of just > >>> sticking things are the top level. > >> > >> OK, so much for my comment a few lines up :-) > >> > >> The problem with placing non-DSI panels as children of the display > >> controller and not using OF graph is that the panel bindings become > >> dependent of the display controller being used. A display controller > >> using OF graph would require the panel to do the same, while a display > >> controller expecting a panel child node (with a specific name) would > >> require DT properties for the panel node. > > Not sure I follow. Sorry, I meant "would not requite DT properties". > They become dependent on the controller driver to probe the panel, but the > contents of the panel node would not be controller dependent. If a display controller uses OF graph then the panel DT node has to declare ports. If the display controller doesn't use OF graph but instead expects the panel to be a direct subnode, or points to the panel using a property such as fsl,panel, then the panel DT node will not have ports. > >> I'm also not sure the complexity of OF graph is really that prohibitive > >> if you compare it to panels as child nodes. To get the panel driver to > >> bind to the panel DT node the display controller driver would need to > >> create a platform device for the panel and register it. That's not very > >> difficult, but parsing a single port and endpoint isn't either (and we > >> could even provide a helper function for that, a version of > >> of_drm_find_panel() that would take as an argument the display controller > >> device node instead of the panel device node). > > > > Ping ? > > > > I'd like to standardize on one model for panel DT bindings, but I'm not > > sure that can be achieved given that we already have multiple competing > > models. In any case, is that blocking to merge this patch ? I only > > describe one connectivity model here as that's what my panel driver > > needs, but I have no issue adding more models later when needed. I > > believe this patch is a good step forward already. > > It is an improvement which I appreciate, so yes I guess we can address > it later when needed. Thank you. Can I get your ack then ? :-) -- Regards, Laurent Pinchart
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 --- Comment #4 from John Brooks --- (In reply to leoxsliu from comment #3) > Created attachment 128558 [details] > Bonaire UVD firmware > > Please try attached Bonaire UVD firmware. This appears to fix the problem for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/aa957e5f/attachment.html>
[PATCH] fbdev: remove current maintainer
On Mon, 19 Dec 2016 14:34:12 +0100 Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: > > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen > > wrote: > > > > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. > > > > > > ... > > > > > > I just don't have time to even pretend I maintain fbdev, so mark it as > > > Orphan. > > > > > > Anyone want to pick fbdev maintainership? > > http://marc.info/?l=linux-fbdev&m=148181317415549&w=2 > > > I'll keep an eye on the mailing list, try to ensure that things keep > > ticking along. > > Andrew, do you want to manage patches yourself or should I step > in and try to do it? No, please go ahead.
[PATCH] drm/amdgpu: Don't save new cursor size before updating CUR_SIZE register.
On Sun, Dec 18, 2016 at 8:46 AM, Daniel Vetter wrote:
> On Sat, Dec 17, 2016 at 04:35:09PM +, 'Liviu Dudau' wrote:
>> On Fri, Dec 16, 2016 at 07:16:25PM +, Deucher, Alexander wrote:
>> > > -Original Message-
>> > > From: Liviu Dudau [mailto:liviu at dudau.co.uk]
>> > > Sent: Friday, December 16, 2016 2:11 PM
>> > > To: Daenzer, Michel; Deucher, Alexander
>> > > Cc: Koenig, Christian; David Airlie; dri-devel at lists.freedesktop.org;
>> > > amd-
>> > > gfx at lists.freedesktop.org; Liviu Dudau
>> > > Subject: [PATCH] drm/amdgpu: Don't save new cursor size before updating
>> > > CUR_SIZE register.
>> > >
>> > > Commit 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register
>> > > when
>> > > necessary") did not cleanup correctly the old code for DCE v6 and v8.
>> > > As a consequence, cursor updates stopped working for my Radeon R9
>> > > 1002:67b0
>> > > dual-monitor setup.
>> > >
>> > > Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register
>> > > when necessary")
>> > > Signed-off-by: Liviu Dudau
>> >
>> > Already fixed:
>> > https://lists.freedesktop.org/archives/amd-gfx/2016-December/003985.html
>>
>> Sorry, I've only checked the dri-devel list, I've only noticed there is an
>> amd-gfx one while preparing the patch for sending.
>
> Hm yeah, MAINTAINERS is not updated to include the new list. Alex, can you
> pls fix that?
Patch on the way.
Alex
[PATCH] MAINTAINERS: Update mailing list for radeon and amdgpu
amdgpu and radeon development has moved to this list. Signed-off-by: Alex Deucher --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1a7a7731..3e21c61 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4066,7 +4066,7 @@ F:drivers/gpu/drm/cirrus/ RADEON and AMDGPU DRM DRIVERS M: Alex Deucher M: Christian König -L: dri-devel at lists.freedesktop.org +L: amd-gfx at lists.freedesktop.org T: git git://people.freedesktop.org/~agd5f/linux S: Supported F: drivers/gpu/drm/radeon/ -- 2.5.5
[PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding
On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote: > The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. > > Signed-off-by: Caesar Wang > --- > > Changes in v3: None > Changes in v2: None > > .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 > +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt Acked-by: Rob Herring
[PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> ---
> .../bindings/display/panel/samsung,s6e3ha2.txt | 52 ++
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 756
> +
> 4 files changed, 815 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> new file mode 100644
> index 000..1f41f24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> @@ -0,0 +1,52 @@
> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
> +
> +Required properties:
> + - compatible: "samsung,s6e3ha2"
> + - reg: the virtual channel number of a DSI peripheral
> + - vdd3-supply: core voltage supply
> + - vci-supply: voltage supply for analog circuits
> + - reset-gpios: a GPIO spec for the reset pin
> + - enable-gpios: a GPIO spec for the panel enable pin
> + - te-gpios: a GPIO spec for the tearing effect synchronization signal gpio
> pin
Need to specify the GPIOs as active high or low.
> +
> +Optional properties:
> + - display-timings: timings for the connected panel as described by [1]
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + panel at 0 {
> + compatible = "samsung,s6e3ha2";
> + reg = <0>;
reg doesn't really work here unless this node is a child of the DSI
controller node. But if it is a child node, then you don't need the OF
graph.
> + vdd3-supply = <&ldo27_reg>;
> + vci-supply = <&ldo28_reg>;
> + reset-gpios = <&gpg0 0 GPIO_ACTIVE_HIGH>;
> + enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
> + te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
> +
> + display-timings {
> + timing-0 {
> + clock-frequency = <0>;
> + hactive = <1440>;
> + vactive = <2560>;
> + hfront-porch = <1>;
> + hback-porch = <1>;
> + hsync-len = <1>;
> + vfront-porch = <1>;
> + vback-porch = <15>;
> + vsync-len = <1>;
> + };
> + };
> +
> + port {
> + dsi_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> + };
[Bug 99150] Shader issue for "The Cave" comparing Mesa13 to AMDGPU-PRO
https://bugs.freedesktop.org/show_bug.cgi?id=99150 Bug ID: 99150 Summary: Shader issue for "The Cave" comparing Mesa13 to AMDGPU-PRO Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: johnz at lunarg.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128565 --> https://bugs.freedesktop.org/attachment.cgi?id=128565&action=edit Image differences of "The Cave" using Mesa13 vs AMDGPU-PRO Overview: There are some possible shader issues when comparing screen shots of "The Cave" with Mesa13 to AMD's AMDGPU-PRO. Hardware and versions: The images were captured Using the Mesa 13.0 branch and AMD's AMDGPU-PRO's 16.30 driver. These image differences were observed on both AMD's Rx470 and R9 Fury graphic cards. Attached Images: Attached are the captured images. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/bd176f42/attachment.html>
[Bug 99151] Shader issue for "Space Run" comparing Mesa13 to AMDGPU-PRO
https://bugs.freedesktop.org/show_bug.cgi?id=99151 Bug ID: 99151 Summary: Shader issue for "Space Run" comparing Mesa13 to AMDGPU-PRO Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: johnz at lunarg.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128566 --> https://bugs.freedesktop.org/attachment.cgi?id=128566&action=edit Image differences of "Space Run" using Mesa13 vs AMDGPU-PRO Image differences of "Space Run" using Mesa13 vs AMDGPU-PRO Overview: There are some possible shader issues when comparing screen shots of "Space Run" with Mesa13 to AMD's AMDGPU-PRO. Hardware and versions: The images were captured Using the Mesa 13.0 branch and AMD's AMDGPU-PRO's 16.30 driver. These image differences were observed on both AMD's Rx470 and R9 Fury graphic cards. Attached Images: Attached are the captured images. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/c15c6934/attachment.html>
[Bug 99152] Shader issue for "Trine 2" comparing Mesa13 to AMDGPU-PRO
https://bugs.freedesktop.org/show_bug.cgi?id=99152 Bug ID: 99152 Summary: Shader issue for "Trine 2" comparing Mesa13 to AMDGPU-PRO Product: Mesa Version: 13.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: johnz at lunarg.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 128567 --> https://bugs.freedesktop.org/attachment.cgi?id=128567&action=edit Image differences of "Trine 2" using Mesa13 vs AMDGPU-PRO Image differences of "Trine 2" using Mesa13 vs AMDGPU-PRO Overview: There are some possible shader issues when comparing screen shots of "Trine 2" with Mesa13 to AMD's AMDGPU-PRO. Hardware and versions: The images were captured Using the Mesa 13.0 branch and AMD's AMDGPU-PRO's 16.30 driver. These image differences were observed on both AMD's Rx470 and R9 Fury graphic cards. Attached Images: Attached are the captured images. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/baa9db20/attachment-0001.html>
[PATCH] drm: rcar-du: enable VSPDs on R8A7791
Hi Sergei, On Monday 19 Dec 2016 22:58:57 Sergei Shtylyov wrote: > On 12/14/2016 11:55 PM, Laurent Pinchart wrote: > >> We're going to use R8A7791 VSPDs to control DU, so set the corresponding > >> flag. > >> > >> Signed-off-by: Sergei Shtylyov > > > > For the same reason I nacked the corresponding patch to the VSP1 driver, I > > have to nack this one as well. The Gen2 DU has native planes, this patch > > would prevent using them. I don't see a good reason to do so. > > One of the reasons is that these patches kill the horizontal noise when > playing video in Weston... What horizontal noise ? :-) -- Regards, Laurent Pinchart
[PATCH] drm/vmwgfx: use designated initializers
Reviewed-by: Sinclair Yeh
thanks!
On Fri, Dec 16, 2016 at 05:04:02PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> index 170b61be1e4e..fec7348cea2c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
> @@ -164,9 +164,9 @@ static void vmw_gmrid_man_debug(struct
> ttm_mem_type_manager *man,
> }
>
> const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
> - vmw_gmrid_man_init,
> - vmw_gmrid_man_takedown,
> - vmw_gmrid_man_get_node,
> - vmw_gmrid_man_put_node,
> - vmw_gmrid_man_debug
> + .init = vmw_gmrid_man_init,
> + .takedown = vmw_gmrid_man_takedown,
> + .get_node = vmw_gmrid_man_get_node,
> + .put_node = vmw_gmrid_man_put_node,
> + .debug = vmw_gmrid_man_debug
> };
> --
> 2.7.4
>
>
> --
> Kees Cook
> Nexus Security
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 --- Comment #5 from John Brooks --- The firmware from comment #3 was distributed in linux-firmware starting with commit 5e6165a8705613646c9a5a282f0a7243fe5dafdc (https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=5e6165a8705613646c9a5a282f0a7243fe5dafdc). Which corresponds to Ubuntu's linux-firmware package version 1.158, released on May 6, 2016. People who already had this firmware would not experience the regression, which could explain the mixed reports of reproducibility. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/db7ac126/attachment.html>
[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
https://bugs.freedesktop.org/show_bug.cgi?id=98988 --- Comment #6 from Alex Deucher --- What is the md5sum of the bonaire_uvd.bin file on your system? For the latest file in git (http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/radeon/bonaire_uvd.bin) I get 3106157934a8feb55145c4f5de3128e2 which matches the md5sum in the firmware Leo attached in attachment 128558. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161219/049d5ab2/attachment.html>
[RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem
From: Swati Dhingra Currently, we don't have a stable ABI which can be used for the purpose of providing output debug/loggging/crc and other such data from DRM. The ABI in current use (filesystems, ioctls, et al.) have their own constraints and are intended to output a particular type of data. Few cases in point: sysfs - stable ABI, but constrained to one textual value per file debugfs - unstable ABI, free-for-all ioctls - not as suitable to many single purpose continuous data dumping, we would very quickly run out ioctl space; requires more userspace support than "cat" device nodes - a real possibilty, kernel instantiation is more tricky, requires udev (+udev.rules) or userspace discovery of the dynamic major:minor (via sysfs) [mounting a registered filesystem is easy in comparison] netlink - stream based, therefore involves numerous copies. Debugfs is the lesser among the evils here, thereby we have grown used to the convenience and flexibility in presentation that debugfs gives us (including relayfs inodes) that we want some of that hierachy in stable user ABI form. Due to these limitations, there is a need for a new pseudo filesytem, that would act as a stable 'free-for-all' ABI, with the heirarchial structure and thus convenience of debugfs. This will be managed by drm, thus named 'drmfs'. DRM would register this filesystem to manage a canonical mountpoint, but this wouldn't limit everyone to only using that pseudofs underneath. This can serve to hold various kinds of output data from Linux DRM subsystems, for the files which can't truely fit anywhere else with existing ABI's but present so, for the lack of a better place. In this patch series, we have introduced a pseudo filesystem named as 'drmfs' for now. The filesystem is introduced in the first patch, and the subsequent patches make use of the filesystem interfaces, in drm driver, and making them available for use by the drm subsystem components, one of which is i915. We've moved the location of i915 GuC logs from debugfs to drmfs in the last patch. Subsequently, more such files such as pipe_crc, error states, memory stats, etc. can be move to this filesystem, if the idea introduced here is acceptable per se. The filesystem introduced is being used to house the data generated by i915 driver in this patch series, but will hopefully be generic enough to provide scope for usage by any other drm subsystem component. The patch series is being floated as RFC to gather feedback on the idea and infrastructure proposed here and it's suitability to address the specific problem statement/use case. v2: fix the bat failures caused due to missing config check v3: Changes made: - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris) - Moving config checks to header (Chris,Daniel) v4: Added the kernel Documentaion (using Sphinx). Sourab Gupta (4): drm: Introduce drmfs pseudo filesystem interfaces drm: Register drmfs filesystem from drm init drm: Create driver specific root directory inside drmfs drm/i915: Creating guc log file in drmfs instead of debugfs Documentation/gpu/drm-uapi.rst | 76 drivers/gpu/drm/Kconfig| 9 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_drv.c | 26 ++ drivers/gpu/drm/drmfs.c| 566 + drivers/gpu/drm/i915/i915_guc_submission.c | 33 +- include/drm/drm_drv.h | 3 + include/drm/drmfs.h| 77 include/uapi/linux/magic.h | 3 + 9 files changed, 773 insertions(+), 21 deletions(-) create mode 100644 drivers/gpu/drm/drmfs.c create mode 100644 include/drm/drmfs.h -- 2.7.4
[PATCH v3 0/4] Generic HDMI codec: Add channel mapping control
Aim of this patch is to add 'Playback Channel Map' control to export audio capabilities in term of HDMI sink speakers allocation. V3: - "ASoC: hdmi-codec: add channel mapping control": => Minor fixes: - select stereo speaker config by default if HDMI cable unplugged - fix compilation warning. - "DRM: add help to get ELD speaker allocation" => No delta vs V2. - "ALSA pcm: allow non constant snd_pcm_chmap_elem" => No delta vs V2. - "ASoC: core: add optional pcm_new callback for DAI driver" => No delta vs V2. V2: In this version I use chmap helper functions from pcm_lib.c. It is quite tricky to use it from ASoC due to the relation chip of the controls with the pcm runtime. After several tries, my conclusion is that it must be handled in ASoC DAI driver. Main reason is that the DAI driver can not provide snd_pcm_chmap struct through kcontrol structure. But this induces that soc-core provides pcm runtime structure to DAI driver during probe. Base on this conclusion. I reworked my patches by adding 2 new patches in patch-set 1) ALSA pcm: allow non constant snd_pcm_chmap_elem This patch allows to handle non constant channel mapping. As ELD information can change during runtime it is mandatory to properly handle the feature. In term of compatibility with legacy it should be straightforward, as update just consists in suppressing the 'const' constraint. 2) ASoC: core: add optional pcm_new callback for DAI driver This is the only way i found to be able to use snd_pcm_add_chmap_ctls and associated controls helper functions. From my point of view, this is the more simple way to add relationship between DAI and associated pcm devices. Notice that this patch, if accepted, makes the following one obsolete, as it also answer to the associated topic: [PATCH v5 0/2] ALSA controls management using index/device/sub-devices fields (http://www.spinics.net/lists/alsa-devel/msg57639.html). If you estimate that this it not reasonable i will come back to my first version. V1: This patch follows discussion initiate here: [RFC] ASOC: HDMI audio info frame speaker allocation http://www.spinics.net/lists/alsa-devel/msg57363.html The code is fully inspired from HDA driver. On hw_param, HDMI sink speaker capabilities are exported via TLV ops and a CEA allocation is choson, based on ELD information and the number of channels requested by user. Mains differences with HDA implementation are: - Control is read only - Channel swap is not supported. Consequence is that unused channel in the mid of CEA audio infoframe channel mapping are considered as active. example for channel allocation 0x02: FL, FR, 0, FC) This configuration is only available for a 4 channels stream. - Channel allocation table has been reordered and HDMI 2.0 is not supported. Arnaud Pouliquen (4): DRM: add help to get ELD speaker allocation ALSA pcm: allow non constant snd_pcm_chmap_elem ASoC: core: add optional pcm_new callback for DAI driver ASoC: hdmi-codec: add channel mapping control include/drm/drm_edid.h| 13 ++ include/sound/pcm.h | 4 +- include/sound/soc-dai.h | 3 + sound/core/pcm_lib.c | 6 +- sound/soc/codecs/hdmi-codec.c | 313 +- sound/soc/soc-core.c | 28 6 files changed, 361 insertions(+), 6 deletions(-) -- 1.9.1
[PATCH v2] drm: drm_probe_helper: Fix output_poll_work scheduling
On 12/19/2016 11:54 AM, Jani Nikula wrote: > On Wed, 31 Aug 2016, Daniel Vetter wrote: >> On Wed, Aug 31, 2016 at 02:09:05PM +0300, Peter Ujfalusi wrote: >>> drm_kms_helper_poll_enable_locked() should check if we have delayed event >>> pending and if we have, schedule the work to run without delay. >>> >>> Currently the output_poll_work is only scheduled if any of the connectors >>> have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with >>> DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event >>> already registered to be handled. The detection will be delayd by >>> DRM_OUTPUT_POLL_PERIOD in any case. >>> Furthermore if none of the connectors are marked as POLL_CONNECT or >>> POLL_DISCONNECT because all connectors are either POLL_HPD or they are >>> always connected: the output_poll_work will not run at all even if we >>> have delayed event marked. >>> >>> When none of the connectors require polling, their initial status change >>> from unknown to connected/disconnected is not going to be handled until >>> the first kms application starts or if we have fb console enabled. >>> >>> Signed-off-by: Peter Ujfalusi >>> --- >>> Hi, >>> >>> Changes since v1: >>> - dropped the last paragraph from the commit message. >> >> I added a few more words to the commit message to explain when exactly >> this is a problem and applied your patch to drm-misc. > > Hi Peter, sadly looks like this regresses users out there [1]. Seems to > be a reliable bisect. We need to have this fixed or reverted. When I sent the patch I did booted my laptop (with Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)) and my old desktop with some nVidia Quadro using nouveau stack and seen no issue. But with 4.9 now on my Dell laptop I see lots of warnings during boot: [0.573119] [ cut here ] [0.573127] WARNING: CPU: 3 PID: 874 at drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1d5/0x210 [0.573132] WARN_ON(!msg->buffer != !msg->size) [0.573134] Modules linked in: [0.573140] CPU: 3 PID: 874 Comm: kworker/u8:3 Not tainted 4.9.0-gentoo #1 [0.573143] Hardware name: Dell Inc. Latitude E7440/06MFX3, BIOS A14 02/02/2015 [0.573150] Workqueue: events_unbound async_run_entry_fn [0.573154] c900021afaf0 813c3bad c900021afb40 [0.573160] c900021afb30 8106a596 042614b82908 c900021afc00 [0.573166] 8802144040e0 0003 880214404158 [0.573172] Call Trace: [0.573178] [] dump_stack+0x4f/0x72 [0.573182] [] __warn+0xc6/0xe0 [0.573185] [] warn_slowpath_fmt+0x4a/0x50 [0.573189] [] ? intel_dp_aux_transfer+0xc9/0x210 [0.573193] [] intel_dp_aux_transfer+0x1d5/0x210 [0.573198] [] ? _raw_write_unlock_irqrestore+0x13/0x30 [0.573202] [] ? _raw_spin_unlock_irqrestore+0x9/0x10 [0.573207] [] drm_dp_dpcd_access+0x58/0xf0 [0.573210] [] drm_dp_dpcd_write+0x16/0x20 [0.573214] [] intel_dp_start_link_train+0x2b3/0x4a0 [0.573218] [] intel_dp_check_link_status+0xb2/0xf0 [0.573222] [] intel_dp_detect+0x7d6/0xb40 [0.573226] [] drm_helper_probe_single_connector_modes+0x41b/0x4e0 [0.573233] [] drm_fb_helper_initial_config+0x7c/0x3f0 [0.573237] [] ? _raw_spin_unlock_irq+0x9/0x10 [0.573242] [] intel_fbdev_initial_config+0x13/0x30 [0.573245] [] async_run_entry_fn+0x32/0xe0 [0.573249] [] process_one_work+0x148/0x4c0 [0.573253] [] worker_thread+0x43/0x4e0 [0.573257] [] ? process_one_work+0x4c0/0x4c0 [0.573260] [] ? process_one_work+0x4c0/0x4c0 [0.573264] [] ? call_usermodehelper_exec_async+0x137/0x140 [0.573269] [] kthread+0xc5/0xe0 [0.573273] [] ? kthread_park+0x60/0x60 [0.573277] [] ? umh_complete+0x40/0x40 [0.573280] [] ret_from_fork+0x22/0x30 [0.573285] ---[ end trace a544f5d689389b41 ]--- If I revert the patch in question I have tons of: [0.569127] [ cut here ] [0.569136] WARNING: CPU: 3 PID: 564 at drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1d5/0x210 [0.569141] WARN_ON(!msg->buffer != !msg->size) [0.569143] Modules linked in: [0.569149] CPU: 3 PID: 564 Comm: kworker/3:2 Not tainted 4.9.0-gentoo #2 [0.569152] Hardware name: Dell Inc. Latitude E7440/06MFX3, BIOS A14 02/02/2015 [0.569159] Workqueue: events i915_hotplug_work_func [0.569164] c90001a93ba0 813c3bad c90001a93bf0 [0.569174] c90001a93be0 8106a596 042614b12908 c90001a93cb0 [0.569184] 88021482b0e0 0003 88021482b158 [0.569191] Call Trace: [0.569198] [] dump_stack+0x4f/0x72 [0.569205] [] __warn+0xc6/0xe0 [0.569210] [] warn_slowpath_fmt+0x4a/0x50 [0.569214] [] ? intel_dp_aux_transfer+0xc9/0x210 [0.569218] [] intel_dp_aux_transfer+0x1d5/0x210 [0.569223] [] ? _raw_w
[RFC 3/4] drm: Create driver specific root directory inside drmfs
From: Sourab Gupta
A driver specific directory is created inside drmfs root, and dentry of
this directory is saved for subsequent use by the driver (e.g. i915).
The driver can then create files/directories inside this root directory
directly.
In case of i915 driver, the top directory is created at '/sys/kernel/drm/i915'.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/drm_drv.c | 6 ++
include/drm/drm_drv.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 298013c..4c32cf8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -671,6 +671,11 @@ EXPORT_SYMBOL(drm_dev_unref);
int drm_dev_register(struct drm_device *dev, unsigned long flags)
{
int ret;
+ struct dentry *drmfs_root;
+
+ drmfs_root = drmfs_create_dir(dev->driver->name, NULL);
+ if (!IS_ERR(drmfs_root))
+ dev->driver->drmfs_root = drmfs_root;
mutex_lock(&drm_global_mutex);
@@ -742,6 +747,7 @@ void drm_dev_unregister(struct drm_device *dev)
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
drm_minor_unregister(dev, DRM_MINOR_CONTROL);
+ drmfs_remove(dev->driver->drmfs_root);
}
EXPORT_SYMBOL(drm_dev_unregister);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index c4fc495..d646296 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -405,6 +405,9 @@ struct drm_driver {
/* List of devices hanging off this driver with stealth attach. */
struct list_head legacy_dev_list;
+
+ /* drmfs parent directory dentry for this driver */
+ struct dentry *drmfs_root;
};
extern __printf(6, 7)
--
2.7.4
[PATCH] drm/i915/debugfs: use rb_entry()
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b77b53b..e04d9a1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -686,7 +686,7 @@ static void i915_ring_seqno_info(struct seq_file *m,
spin_lock_irq(&b->lock);
for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
- struct intel_wait *w = container_of(rb, typeof(*w), node);
+ struct intel_wait *w = rb_entry(rb, typeof(*w), node);
seq_printf(m, "Waiting (%s): %s [%d] on %x\n",
engine->name, w->tsk->comm, w->tsk->pid, w->seqno);
@@ -1336,7 +1336,7 @@ static int i915_hangcheck_info(struct seq_file *m, void
*unused)
&dev_priv->gpu_error.missed_irq_rings)));
spin_lock_irq(&b->lock);
for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
- struct intel_wait *w = container_of(rb, typeof(*w),
node);
+ struct intel_wait *w = rb_entry(rb, typeof(*w), node);
seq_printf(m, "\t%s [%d] waiting for %x\n",
w->tsk->comm, w->tsk->pid, w->seqno);
@@ -3252,7 +3252,7 @@ static int i915_engine_info(struct seq_file *m, void
*unused)
spin_lock_irq(&b->lock);
for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
- struct intel_wait *w = container_of(rb, typeof(*w),
node);
+ struct intel_wait *w = rb_entry(rb, typeof(*w), node);
seq_printf(m, "\t%s [%d] waiting for %x\n",
w->tsk->comm, w->tsk->pid, w->seqno);
--
2.9.3
[PATCH v3 1/4] DRM: add help to get ELD speaker allocation
Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.
Signed-off-by: Arnaud Pouliquen
---
include/drm/drm_edid.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d44..de93543 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -248,6 +248,7 @@ struct detailed_timing {
# define DRM_ELD_AUD_SYNCH_DELAY_MAX 0xfa/* 500 ms */
#define DRM_ELD_SPEAKER7
+# define DRM_ELD_SPEAKER_MASK 0x7f
# define DRM_ELD_SPEAKER_RLRC (1 << 6)
# define DRM_ELD_SPEAKER_FLRC (1 << 5)
# define DRM_ELD_SPEAKER_RC(1 << 4)
@@ -415,6 +416,18 @@ static inline int drm_eld_size(const uint8_t *eld)
}
/**
+ * drm_eld_get_spk_alloc - Get speaker allocation
+ * @eld: pointer to an ELD memory structure
+ *
+ * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
+ * field definitions to identify speakers.
+ */
+static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
+{
+ return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
+}
+
+/**
* drm_eld_get_conn_type - Get device type hdmi/dp connected
* @eld: pointer to an ELD memory structure
*
--
1.9.1
[kbuild-all] [Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter
On 12/16, Fengguang Wu wrote:
>Hi Daniel,
>
>On Fri, Dec 16, 2016 at 08:29:43AM +0100, Daniel Vetter wrote:
>>Hi Kbuild folks
>>
>>So yeah this doesn't apply because it's just 1 patch resent out of a
>>big patch series, in-reply-to the patch it replaces. So applying this
>>alone and telling me (and all the mailing lists) that it doesn't apply
>>isn't all that useful.
>>
>>And it shouldn't be too hard to detect this, since the fdo patchwork
>>instance does catch most of these partial resends successfully and
>>correctly, and will retest the entire patch series.
>
>Good point! CC Xiaolong. This scenario seems happen frequent enough in
>LKML to worth the efforts to add auto detect logic for.
Got it, I'll add auto detect logic to handle it.
Thanks,
Xiaolong
>
>Thanks,
>Fengguang
>
>>On Thu, Dec 15, 2016 at 11:59 PM, kbuild test robot wrote:
>>>Hi Daniel,
>>>
>>>[auto build test ERROR on drm/drm-next]
>>>[also build test ERROR on next-20161215]
>>>[cannot apply to v4.9]
>>>[if your patch is applied to the wrong git tree, please drop us a note to
>>>help improve the system]
>>>
>>>url:
>>>https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all-helpers-to-drm_connector_list_iter/20161216-061508
>>>base: git://people.freedesktop.org/~airlied/linux.git drm-next
>>>config: i386-randconfig-x003-201650 (attached as .config)
>>>compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
>>>reproduce:
>>># save the attached .config to linux build tree
>>>make ARCH=i386
>>>
>>>All error/warnings (new ones prefixed by >>):
>>>
>>> drivers/gpu/drm/drm_crtc_helper.c: In function
>>> 'drm_helper_encoder_in_use':
>drivers/gpu/drm/drm_crtc_helper.c:91:33: error: storage size of
>'conn_iter' isn't known
>>> struct drm_connector_list_iter conn_iter;
>>>^
>drivers/gpu/drm/drm_crtc_helper.c:104:2: error: implicit declaration of
>function 'drm_connector_list_iter_get'
>[-Werror=implicit-function-declaration]
>>> drm_connector_list_iter_get(dev, &conn_iter);
>>> ^~~
>drivers/gpu/drm/drm_crtc_helper.c:105:2: error: implicit declaration of
>function 'drm_for_each_connector_iter'
>[-Werror=implicit-function-declaration]
>>> drm_for_each_connector_iter(connector, &conn_iter) {
>>> ^~~
>drivers/gpu/drm/drm_crtc_helper.c:105:53: error: expected ';' before '{'
>token
>>> drm_for_each_connector_iter(connector, &conn_iter) {
>>>^
>>> drivers/gpu/drm/drm_crtc_helper.c:91:33: warning: unused variable
>>> 'conn_iter' [-Wunused-variable]
>>> struct drm_connector_list_iter conn_iter;
>>>^
>>> drivers/gpu/drm/drm_crtc_helper.c: In function 'drm_crtc_helper_disable':
>>> drivers/gpu/drm/drm_crtc_helper.c:446:34: error: storage size of
>>> 'conn_iter' isn't known
>>> struct drm_connector_list_iter conn_iter;
>>> ^
>>> drivers/gpu/drm/drm_crtc_helper.c:452:54: error: expected ';' before '{'
>>> token
>>> drm_for_each_connector_iter(connector, &conn_iter) {
>>> ^
>>> drivers/gpu/drm/drm_crtc_helper.c:446:34: warning: unused variable
>>> 'conn_iter' [-Wunused-variable]
>>> struct drm_connector_list_iter conn_iter;
>>> ^
>>> drivers/gpu/drm/drm_crtc_helper.c: In function
>>> 'drm_crtc_helper_set_config':
>>> drivers/gpu/drm/drm_crtc_helper.c:521:33: error: storage size of
>>> 'conn_iter' isn't known
>>> struct drm_connector_list_iter conn_iter;
>>>^
>drivers/gpu/drm/drm_crtc_helper.c:588:3: error: expected ';' before
>'save_connector_encoders'
>>> save_connector_encoders[count++] = connector->encoder;
>>> ^~~
>drivers/gpu/drm/drm_crtc_helper.c:589:2: error: implicit declaration of
>function 'drm_connector_list_iter_put'
>[-Werror=implicit-function-declaration]
>>> drm_connector_list_iter_put(&conn_iter);
>>> ^~~
>>> drivers/gpu/drm/drm_crtc_helper.c:633:53: error: expected ';' before '{'
>>> token
>>> drm_for_each_connector_iter(connector, &conn_iter) {
>>>^
>>> drivers/gpu/drm/drm_crtc_helper.c:675:53: error: expected ';' before '{'
>>> token
>>> drm_for_each_connector_iter(connector, &conn_iter) {
>>>^
>drivers/gpu/drm/drm_crtc_helper.c:767:3: error: expected ';' before
>'connector'
>>> connector->encoder = save_connector_encoders[count++];
>>> ^
>>> drivers/gpu/drm/drm_crtc_helper.c:521:33: warning: unused variable
>>> 'conn_iter' [-Wunused-variable]
>>> struct drm_connector_list_iter conn_iter
[alsa-devel] [PATCH v3 2/4] ALSA pcm: allow non constant snd_pcm_chmap_elem
I had a doubt...this confirms that my arm compiler is too permissive :( This patch in pcm_lib has to be abandoned. I will propose a V4 with one/some constant table(s) defined in hdmi-codec... Regards Arnaud On 12/19/2016 05:31 PM, kbuild test robot wrote: > Hi Arnaud, > > [auto build test WARNING on asoc/for-next] > [also build test WARNING on v4.9 next-20161219] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/Generic-HDMI-codec-Add-channel-mapping-control/20161219-235923 > base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > for-next > config: x86_64-acpi-redef (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All warnings (new ones prefixed by >>): > >sound/pci/atiixp.c: In function 'snd_atiixp_pcm_new': >>> sound/pci/atiixp.c:1298:10: warning: passing argument 3 of >>> 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target >>> type [-Wdiscarded-qualifiers] > snd_pcm_alt_chmaps, chip->max_channels, 0, > ^~ >In file included from sound/pci/atiixp.c:31:0: >include/sound/pcm.h:1389:5: note: expected 'struct snd_pcm_chmap_elem *' > but argument is of type 'const struct snd_pcm_chmap_elem *' > int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream, > ^~ > -- >sound/pci/cmipci.c: In function 'snd_cmipci_pcm_spdif_new': >>> sound/pci/cmipci.c:1966:10: warning: passing argument 3 of >>> 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target >>> type [-Wdiscarded-qualifiers] > snd_pcm_alt_chmaps, cm->max_channels, 0, > ^~ >In file included from sound/pci/cmipci.c:35:0: >include/sound/pcm.h:1389:5: note: expected 'struct snd_pcm_chmap_elem *' > but argument is of type 'const struct snd_pcm_chmap_elem *' > int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream, > ^~ > -- >sound/pci/ens1370.c: In function 'snd_ensoniq_pcm': >>> sound/pci/ens1370.c:1297:10: warning: passing argument 3 of >>> 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target >>> type [-Wdiscarded-qualifiers] > surround_map, 2, 0, NULL); > ^~~~ >In file included from sound/pci/ens1370.c:41:0: >include/sound/pcm.h:1389:5: note: expected 'struct snd_pcm_chmap_elem *' > but argument is of type 'const struct snd_pcm_chmap_elem *' > int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream, > ^~ >sound/pci/ens1370.c: In function 'snd_ensoniq_pcm2': >sound/pci/ens1370.c:1329:10: warning: passing argument 3 of > 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target type > [-Wdiscarded-qualifiers] > snd_pcm_std_chmaps, 2, 0, NULL); > ^~ >In file included from sound/pci/ens1370.c:41:0: >include/sound/pcm.h:1389:5: note: expected 'struct snd_pcm_chmap_elem *' > but argument is of type 'const struct snd_pcm_chmap_elem *' > int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream, > ^~ > -- >In file included from sound/pci/au88x0/au8810.c:9:0: >sound/pci/au88x0/au88x0_pcm.c: In function 'snd_vortex_new_pcm': >>> sound/pci/au88x0/au88x0_pcm.c:659:11: warning: passing argument 3 of >>> 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target >>> type [-Wdiscarded-qualifiers] > snd_pcm_std_chmaps, > ^~ >In file included from sound/pci/au88x0/au88x0.h:23:0, > from sound/pci/au88x0/au8810.c:2: >include/sound/pcm.h:1389:5: note: expected 'struct snd_pcm_chmap_elem *' > but argument is of type 'const struct snd_pcm_chmap_elem *' > int snd_pcm_add_chmap_ctls(struct snd_pcm *pcm, int stream, > ^~ >In file included from sound/pci/au88x0/au8810.c:9:0: >sound/pci/au88x0/au88x0_pcm.c:665:11: warning: passing argument 3 of > 'snd_pcm_add_chmap_ctls' discards 'const' qualifier from pointer target type > [-Wdiscarded-qualifiers] >
[RFC 4/4] drm/i915: Creating guc log file in drmfs instead of debugfs
From: Sourab Gupta
In the current scenario, the relay API fit well only with debugfs, due to
availability of parent dentry. Any other existing filesystem was not feasible
for
holding guc logs, due to incompatibility with relay. But this makes the guc_log
file unavailable on the production kernels.
GuC log file can therefore be one of candidates for movement to the drmfs
filesystem, which can satisfy all the requirements needed by relay API, and can
house any relayfs based output file.
The patch moves the parent directory of guc 'log_dir' from debugfs_root to
drmfs_root, while using the drmfs api's to create the requisite files.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/i915/i915_guc_submission.c | 33 +++---
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 5841380..3f5978a 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -22,8 +22,8 @@
*
*/
#include
-#include
#include
+#include
#include "i915_drv.h"
#include "intel_uc.h"
@@ -812,7 +812,7 @@ static int subbuf_start_callback(struct rchan_buf *buf,
}
/*
- * file_create() callback. Creates relay file in debugfs.
+ * file_create() callback. Creates relay file.
*/
static struct dentry *create_buf_file_callback(const char *filename,
struct dentry *parent,
@@ -838,17 +838,19 @@ static struct dentry *create_buf_file_callback(const char
*filename,
* dentry of the file associated with the channel buffer and that file's
* name need not be same as the filename passed as an argument.
*/
- buf_file = debugfs_create_file("guc_log", mode,
+
+ buf_file = drmfs_create_file("guc_log", mode,
parent, buf, &relay_file_operations);
+
return buf_file;
}
/*
- * file_remove() default callback. Removes relay file in debugfs.
+ * file_remove() default callback. Removes relay file.
*/
static int remove_buf_file_callback(struct dentry *dentry)
{
- debugfs_remove(dentry);
+ drmfs_remove(dentry);
return 0;
}
@@ -898,22 +900,11 @@ static int guc_log_create_relay_file(struct intel_guc
*guc)
struct dentry *log_dir;
int ret;
- /* For now create the log file in /sys/kernel/debug/dri/0 dir */
- log_dir = dev_priv->drm.primary->debugfs_root;
-
- /* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
-* not mounted and so can't create the relay file.
-* The relay API seems to fit well with debugfs only, for availing relay
-* there are 3 requirements which can be met for debugfs file only in a
-* straightforward/clean manner :-
-* i) Need the associated dentry pointer of the file, while opening
the
-* relay channel.
-* ii) Should be able to use 'relay_file_operations' fops for the file.
-* iii) Set the 'i_private' field of file's inode to the pointer of
-* relay channel buffer.
-*/
+ /* Create the log file in drmfs dir: /sys/kernel/drm/i915/ */
+ log_dir = dev_priv->drm.driver->drmfs_root;
+
if (!log_dir) {
- DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
+ DRM_ERROR("Root dir not available yet for GuC log file\n");
return -ENODEV;
}
@@ -1154,7 +1145,7 @@ static int guc_log_create_extras(struct intel_guc *guc)
if (!guc->log.relay_chan) {
/* Create a relay channel, so that we have buffers for storing
* the GuC firmware logs, the channel will be linked with a file
-* later on when debugfs is registered.
+* later on when drmfs is registered.
*/
ret = guc_log_create_relay_channel(guc);
if (ret)
--
2.7.4
[RFC 1/4] drm: Introduce drmfs pseudo filesystem interfaces
From: Sourab Gupta The patch introduces a new pseudo filesystem type, named 'drmfs' which is intended to house the files for the data generated by drm subsystem that cannot be accommodated by any of the existing filesystems. The filesystem is modelled on the lines of existing pseudo-filesystems such as debugfs/tracefs, and borrows ideas from their implementation. This filesystem will be appearing at sys/kernel/drm. A new config 'CONFIG_DRMFS' is introduced to enable/disable the filesystem, which is dependent on CONFIG_DRM. The filesystem will not be registered standalone during kernel init time, instead it is intended to be initialized/registered during drm initialization. The intent for introduction of the filesystem is to act as a location to hold various kinds of data output from Linux DRM subsystems, which can't really fit anywhere else into the existing filesystems such as debugfs/sysfs etc. All these filesystems have their own constraints and are intended to output a particular type of data such as attributes and small debug parameter data. Due to these constraints, there is a need for a new pseudo filesytem, customizable to DRM specific requirements and catering to the needs to DRM subsystem components Signed-off-by: Sourab Gupta Signed-off-by: Swati Dhingra --- Documentation/gpu/drm-uapi.rst | 76 ++ drivers/gpu/drm/Kconfig| 9 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drmfs.c| 566 + include/drm/drmfs.h| 77 ++ include/uapi/linux/magic.h | 3 + 6 files changed, 732 insertions(+) create mode 100644 drivers/gpu/drm/drmfs.c create mode 100644 include/drm/drmfs.h diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index de3ac9f..be9540c 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -222,3 +222,79 @@ Testing and validation .. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c :doc: CRC ABI + +DRMFS += + +Overview + + +Drmfs is stable ABI for housing data generated by drm subsystem components. + +The ABI in current use (debugfs/sysfs/ioctls) have their own constraints and +are designed to output their own particular data types. + +Few cases in point:: + + sysfs - stable ABI, but constrained to one textual value per file + debugfs - unstable ABI, free-for-all + ioctls - not as suitable to many single purpose continuous data + dumping, we would very quickly run out ioctl space; require + more userspace support than "cat" + device nodes - a real possibilty, kernel instantiation is more tricky, + requires udev (+udev.rules) or userspace discovery of + the dynamic major:minor (via sysfs) [mounting a + registered filesystem is easy in comparison] + netlink - stream based, therefore involves numerous copies + +Debugfs is the lesser among the evils here, thereby we have grown used to the +convenience and flexibility in presentation that debugfs gives us (including +relayfs inodes) that we want some of that hierarchy in stable user ABI form. + +Due to these limitations, a new pseudo filesytem is needed that would act as a +stable âfree-for-allâ ABI, with the heirarchial structure and thus provide +convenience of debugfs. This to be managed by drm, thus named **drmfs**. The +filesystem is modelled on the lines of existing pseudo-filesystems such as +debugfs/tracefs, and borrows ideas from their implementation. DRM would register +this filesystem to manage a canonical mountpoint, but this wouldnât limit +everyone to only use that pseudofs underneath. + +One of the usecase is to hold the GuC (micro-controller) logs.Currently, relayfs +is being used to provide these logs to userspace. Relayfs needs a parent dentry +to be associated with log file, and also these logs should be available in +production kernels. In absence of any other suitable candidate, debugfs is used +currently, since it provides the hierarchial VFS structures available (dentry et al.). +Instead, drmfs provides a suitable stable ABI for GuC logs, which is modelled on +the lines of debugfs but controlled fully by drm. + +This can serve to hold various kinds of output data from Linux DRM subsystems, +for the files which canât truly fit anywhere else with existing ABIâs but present +so, for the lack of a better place. For e.g. i915 GuC logs, pipe_crc, error +states, memory stats. + +Interfaces +-- + +This section covers the infrastructure of drmfs pseudo filesystem. It introduces +interfaces to create/remove files and directories. + +.. kernel-doc:: drivers/gpu/drm/drmfs.c + :functions: drmfs_create_file + +.. kernel-doc:: drivers/gpu/drm/drmfs.c + :functions: drmfs_create_dir + +.. kernel-doc:: drivers/gpu/drm/drmfs.c + :functions: drmfs_remove + +.. kernel-doc:: drivers/gpu/drm/drmfs.c + :functions:
[STLinux Kernel] [PATCH v2 4/4] ASoC: hdmi-codec: add channel mapping control
I detected 2 issues in this version, details below.
V3 is following.
Sorry for the inconvenience...
Regards
Arnaud
On 12/14/2016 04:16 PM, Arnaud Pouliquen wrote:
> +static unsigned long hdmi_codec_spk_mask_from_alloc(int spk_alloc)
> +{
> + int i;
> + const unsigned long hdmi_codec_eld_spk_alloc_bits[] = {
> + [0] = FL | FR, [1] = LFE, [2] = FC, [3] = RL | RR,
> + [4] = RC, [5] = FLC | FRC, [6] = RLC | RRC,
> + };
> + unsigned long spk_mask;
Missing initialization that generates warning during compilation
> +
> + for (i = 0; i < ARRAY_SIZE(hdmi_codec_eld_spk_alloc_bits); i++) {
> + if (spk_alloc & (1 << i))
> + spk_mask |= hdmi_codec_eld_spk_alloc_bits[i];
> + }
> +
> + return spk_mask;
> +}
> +
> +/* From speaker bit mask to ALSA API channel position */
> +static int snd_hdac_spk_to_chmap(int spk)
> +{
> + const struct hdmi_codec_channel_map_table *t = hdmi_codec_map_table;
> +
> + for (; t->map; t++) {
> + if (t->spk_mask == spk)
> + return t->map;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * hdmi_codec_cea_init_channel_alloc:
> + * Compute derived values in hdmi_codec_channel_alloc[].
> + * spk_na_mask is used to store unused channels in mid of the channel
> + * allocations. These particular channels are then considered as active
> channels
> + * For instance:
> + *CA_ID 0x02: CA = (FL, FR, 0, FC) => spk_na_mask = 0x04, channels = 4
> + *CA_ID 0x04: CA = (FL, FR, 0, 0, RC) => spk_na_mask = 0x03C, channels
> = 5
> + */
> +static void hdmi_codec_cea_init_channel_alloc(void)
> +{
> + int i, j, k, last;
> + struct hdmi_codec_cea_spk_alloc *p;
> +
> + /* Test if not already done by another instance */
> + if (hdmi_codec_channel_alloc[0].channels)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(hdmi_codec_channel_alloc); i++) {
> + p = hdmi_codec_channel_alloc + i;
> + p->spks_mask = 0;
> + p->spk_na_mask = 0;
> + last = HDMI_MAX_SPEAKERS;
> + for (j = 0, k = 7; j < HDMI_MAX_SPEAKERS; j++, k--) {
> + if (p->speakers[j]) {
> + p->spks_mask |= p->speakers[j];
> + if (last == HDMI_MAX_SPEAKERS)
> + last = j;
> + } else if (last != HDMI_MAX_SPEAKERS) {
> + p->spk_na_mask |= 1 << k;
> + }
> + }
> + p->channels = 8 - last;
> + }
> +}
> +
> +static int hdmi_codec_get_ch_alloc_table_idx(struct hdmi_codec_priv *hcp,
> + unsigned char channels)
> +{
> + int i;
> + u8 spk_alloc;
> + unsigned long spk_mask;
> + struct hdmi_codec_cea_spk_alloc *cap = hdmi_codec_channel_alloc;
> +
> + spk_alloc = drm_eld_get_spk_alloc(hcp->eld);
> + spk_mask = hdmi_codec_spk_mask_from_alloc(spk_alloc);
> +
> + for (i = 0; i < ARRAY_SIZE(hdmi_codec_channel_alloc); i++, cap++) {
> + if (cap->channels != channels)
> + continue;
> + if (!(cap->spks_mask == (spk_mask & cap->spks_mask)))
> + continue;
> + return i;
> + }
> +
If HDMI cable not plugged, ELD is empty. In this case this function
returns an error. For backward compatible, it should not return an error
but a default allocation that should be stereo.
> + return -EINVAL;
> +}
> +
> +static void hdmi_cea_alloc_to_tlv_spks(struct hdmi_codec_cea_spk_alloc *cap,
> +unsigned char *chmap)
> +{
> + int count = 0;
> + int c, spk;
> +
> + /* Detect unused channels in cea caps, tag them as N/A channel in TLV */
> + for (c = 0; c < HDMI_MAX_SPEAKERS; c++) {
> + spk = cap->speakers[7 - c];
> + if (cap->spk_na_mask & BIT(c))
> + chmap[count++] = SNDRV_CHMAP_NA;
> + else
> + chmap[count++] = snd_hdac_spk_to_chmap(spk);
> + }
> +}
> +
> +static void hdmi_cea_alloc_to_tlv_chmap(struct hdmi_codec_priv *hcp,
> + struct hdmi_codec_cea_spk_alloc *cap)
> +{
> + unsigned int chs, count = 0;
> + struct snd_pcm_chmap *info = hcp->chmap_info;
> + struct snd_pcm_chmap_elem *chmap = info->chmap;
> + unsigned long max_chs = info->max_channels;
> + int num_ca = ARRAY_SIZE(hdmi_codec_channel_alloc);
> + int spk_alloc, spk_mask;
> +
> + spk_alloc = drm_eld_get_spk_alloc(hcp->eld);
> + spk_mask = hdmi_codec_spk_mask_from_alloc(spk_alloc);
> +
> + for (chs = 2; chs <= max_chs; chs++) {
> + int i;
> + struct hdmi_codec_cea_spk_alloc *cap;
> +
> + cap = hdmi_codec_channel_alloc;
> + for (i = 0; i < num_ca; i++, cap++) {
> + if (cap->channels != chs)
> +
[RFC 2/4] drm: Register drmfs filesystem from drm init
From: Sourab Gupta
The drmfs filesystem will not be registered standalone during kernel init time,
instead it is intended to be initialized/registered during drm initialization.
This again is dependent on CONFIG_DRMFS being defined.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/drm_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f74b7d0..298013c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -828,6 +829,7 @@ static void drm_core_exit(void)
{
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
+ drmfs_fini();
drm_sysfs_destroy();
idr_destroy(&drm_minors_idr);
drm_connector_ida_destroy();
@@ -848,6 +850,10 @@ static int __init drm_core_init(void)
goto error;
}
+ ret = drmfs_init();
+ if (ret < 0)
+ DRM_ERROR("Cannot create DRM FS: %d\n", ret);
+
drm_debugfs_root = debugfs_create_dir("dri", NULL);
if (!drm_debugfs_root) {
ret = -ENOMEM;
--
2.7.4
[PATCH v3 4/4] ASoC: hdmi-codec: add channel mapping control
Add user interface to provide channel mapping.
In a first step this control is read only.
As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When control is called before the number of the channel is specified
(i.e. hw_params is set), it returns all channels set to UNKNOWN.
Signed-off-by: Arnaud Pouliquen
---
sound/soc/codecs/hdmi-codec.c | 313 +-
1 file changed, 312 insertions(+), 1 deletion(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 90b5948..e2ccc2b 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -33,6 +34,124 @@ struct hdmi_device {
LIST_HEAD(hdmi_device_list);
#define DAI_NAME_SIZE 16
+#define HDMI_MAX_SPEAKERS 8
+
+struct hdmi_codec_channel_map_table {
+ unsigned char map; /* ALSA API channel map position */
+ unsigned long spk_mask; /* speaker position bit mask */
+};
+
+/*
+ * CEA speaker placement for HDMI 1.4:
+ *
+ * FL FLC FC FRC FR FRW
+ *
+ * LFE
+ *
+ * RL RLC RC RRC RR
+ *
+ * Speaker placement has to be extended to support HDMI 2.0
+ */
+enum hdmi_codec_cea_spk_placement {
+ FL = BIT(0), /* Front Left */
+ FC = BIT(1), /* Front Center */
+ FR = BIT(2), /* Front Right */
+ FLC = BIT(3), /* Front Left Center*/
+ FRC = BIT(4), /* Front Right Center */
+ RL = BIT(5), /* Rear Left*/
+ RC = BIT(6), /* Rear Center */
+ RR = BIT(7), /* Rear Right */
+ RLC = BIT(8), /* Rear Left Center */
+ RRC = BIT(9), /* Rear Right Center*/
+ LFE = BIT(10), /* Low Frequency Effect */
+};
+
+static const struct hdmi_codec_channel_map_table hdmi_codec_map_table[] = {
+ { SNDRV_CHMAP_FL, FL },
+ { SNDRV_CHMAP_FR, FR },
+ { SNDRV_CHMAP_RL, RL },
+ { SNDRV_CHMAP_RR, RR },
+ { SNDRV_CHMAP_LFE, LFE },
+ { SNDRV_CHMAP_FC, FC },
+ { SNDRV_CHMAP_RLC, RLC },
+ { SNDRV_CHMAP_RRC, RRC },
+ { SNDRV_CHMAP_RC, RC },
+ { SNDRV_CHMAP_FLC, FLC },
+ { SNDRV_CHMAP_FRC, FRC },
+ {} /* terminator */
+};
+
+/*
+ * cea Speaker allocation structure
+ */
+struct hdmi_codec_cea_spk_alloc {
+ const int ca_id;
+ const unsigned long speakers[HDMI_MAX_SPEAKERS];
+
+ /* Derived values, computed during init */
+ unsigned int channels;
+ unsigned long spks_mask;
+ unsigned long spk_na_mask;
+};
+
+/* default HDMI channel maps is stereo */
+const struct snd_pcm_chmap_elem hdmi_codec_stereo_chmaps[] = {
+ { .channels = 2,
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+ { }
+};
+
+/*
+ * hdmi_codec_channel_alloc: speaker configuration available for CEA
+ *
+ * This is an ordered list!
+ * The preceding ones have better chances to be selected by
+ * hdmi_codec_get_ch_alloc_table_idx().
+ */
+static struct hdmi_codec_cea_spk_alloc hdmi_codec_channel_alloc[] = {
+{ .ca_id = 0x00, .speakers = { 0,0, 0, 0, 0,0, FR, FL } },
+/* 2.1 */
+{ .ca_id = 0x01, .speakers = { 0,0, 0, 0, 0, LFE, FR, FL } },
+/* Dolby Surround */
+{ .ca_id = 0x02, .speakers = { 0,0, 0, 0, FC,0, FR, FL } },
+/* surround51 */
+{ .ca_id = 0x0b, .speakers = { 0,0, RR, RL, FC, LFE, FR, FL } },
+/* surround40 */
+{ .ca_id = 0x08, .speakers = { 0,0, RR, RL, 0,0, FR, FL } },
+/* surround41 */
+{ .ca_id = 0x09, .speakers = { 0,0, RR, RL, 0, LFE, FR, FL } },
+/* surround50 */
+{ .ca_id = 0x0a, .speakers = { 0,0, RR, RL, FC,0, FR, FL } },
+/* 6.1 */
+{ .ca_id = 0x0f, .speakers = { 0, RC, RR, RL, FC, LFE, FR, FL } },
+/* surround71 */
+{ .ca_id = 0x13, .speakers = { RRC, RLC, RR, RL, FC, LFE, FR, FL } },
+
+{ .ca_id = 0x03, .speakers = { 0,0, 0, 0, FC, LFE, FR, FL } },
+{ .ca_id = 0x04, .speakers = { 0,0, 0, RC, 0,0, FR, FL } },
+{ .ca_id = 0x05, .speakers = { 0,0, 0, RC, 0, LFE, FR, FL } },
+{ .ca_id = 0x06, .speakers = { 0,0, 0, RC, FC,0, FR, FL } },
+{ .ca_id = 0x07, .speakers = { 0,0, 0, RC, FC, LFE, FR, FL } },
+{ .ca_id = 0x0c, .speakers = { 0, RC, RR, RL, 0,0, FR, FL } },
+{ .ca_id = 0x0d, .speakers = { 0, RC, RR, RL, 0, LFE, FR, FL } },
+{ .ca_id = 0x0e, .speakers = { 0, RC, RR, RL, FC,0, FR, FL } },
+{ .ca_id = 0x10, .speakers = { RRC, RLC, RR, RL, 0,0, FR, FL } },
+{ .ca_id = 0x11, .speakers = { RRC, RLC, RR, RL, 0, LFE, FR, FL } },
[PATCH] fbdev: remove current maintainer
Hi, On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen > wrote: > > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. > > > > ... > > > > I just don't have time to even pretend I maintain fbdev, so mark it as > > Orphan. > > > > Anyone want to pick fbdev maintainership? http://marc.info/?l=linux-fbdev&m=148181317415549&w=2 > I'll keep an eye on the mailing list, try to ensure that things keep > ticking along. Andrew, do you want to manage patches yourself or should I step in and try to do it? Tomi, in case I would end up handling patches your help would be still greatly appreciated (I'm not much a fbdev expert so any non-obvious stuff will likely take some time to be processed).. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
[PATCH] drm: rcar-du: enable VSPDs on R8A7791
Hello! On 12/14/2016 11:55 PM, Laurent Pinchart wrote: >> We're going to use R8A7791 VSPDs to control DU, so set the corresponding >> flag. >> >> Signed-off-by: Sergei Shtylyov > > For the same reason I nacked the corresponding patch to the VSP1 driver, I > have to nack this one as well. The Gen2 DU has native planes, this patch would > prevent using them. I don't see a good reason to do so. One of the reasons is that these patches kill the horizontal noise when playing video in Weston... WBR, Sergei
[Intel-gfx] [PATCH 0/2] drm: link status property and DP link training failure handling
On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote: > On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote: > > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote: > > > On Fri, 16 Dec 2016, Daniel Vetter wrote: > > > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote: > > > >> The two remaining patches from [1], rebased. > > > >> > > > >> BR, > > > >> Jani. > > > >> > > > >> > > > >> [1] > > > >> http://mid.mail-archive.com/1480984058-552-1-git-send-email-manasi.d.navare > > > >> at intel.com > > > > > > > > Just for the record, I think the only thing missing here is the Xorg > > > > review on the -modesetting patch. As soon as we have that I can vacuum > > > > this up (probably best through drm-misc, but not sure). > > > > > > Yeah I rebased this (and provided a debug hack privately) so Martin can > > > test the modesetting changes. > > > > > > BR, > > > Jani. > > > > > > > > > > I tested the -modesetting patch, which Martin had provided to Manasi, > > with a compliance testing device (DPR-120) that can simulate link > > training failure. The link rate correctly lowered after the link_status > > property was set to BAD by the kernel and the userspace responded with a > > modeset. > > > > One thing that was not straight forward to figure out was I had to boot > > with i915.nuclear_pageflip=1. Is it documented somewhere that the > > property needs DRIVER_ATOMIC to be set, or is it implicit? > > It should work without DRIVER_ATOMIC. At least the property should be > exposed ... If this does only work with DRIVER_ATOMIC set then we have a > bug somewhere. Can you pls try to figure out why it doesn't work? > The property is exposed even without DRIVER_ATOMIC set, but the value is always GOOD (0). We set connector->state->link_status to BAD when link training fails but the getconnector() ioctl ends up reading obj->properties->values[i] if DRIVER_ATOMIC is NOT set. But with DRIVER_ATOMIC set, getconnector() calls into drm_atomic_connector_get_property() and retrieves the value stored in connector->state->link_status. > > The other thing I had trouble with -modesetting was, there was no > > modeset following a long pulse from the sink at the begging of the test. > > I had to force a modeset by changing the resolution so that the link > > training path is executed. However, the link training failure induced a > > modeset without any intervention. > > Sounds roughly like how it's supposed to work. For real mode configuration > changes the desktop environment is supposed to set the mode it wants, by > listening to the xrandr hotplug event. That's not the same as the udev > hotplug event. You can listen for the xrandr hotplug event using > > $ xev -event randr > Got it, -modesetting does indeed send out the hotplug events upon hotplug. -DK > Cheers, Daniel > > > > > -DK > > > > > > > > -Daniel > > > > > > > >> > > > >> > > > >> Manasi Navare (2): > > > >> drm: Add a new connector atomic property for link status > > > >> drm/i915: Implement Link Rate fallback on Link training failure > > > >> > > > >> drivers/gpu/drm/drm_atomic.c | 16 + > > > >> drivers/gpu/drm/drm_atomic_helper.c | 15 > > > >> drivers/gpu/drm/drm_connector.c | 52 > > > >> +++ > > > >> drivers/gpu/drm/i915/intel_dp.c | 27 ++ > > > >> drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++-- > > > >> drivers/gpu/drm/i915/intel_drv.h | 3 ++ > > > >> include/drm/drm_connector.h | 19 ++ > > > >> include/drm/drm_mode_config.h | 5 +++ > > > >> include/uapi/drm/drm_mode.h | 4 +++ > > > >> 9 files changed, 161 insertions(+), 2 deletions(-) > > > >> > > > >> -- > > > >> 2.1.4 > > > >> > > > >> ___ > > > >> dri-devel mailing list > > > >> dri-devel at lists.freedesktop.org > > > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > >
