[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Linus Torvalds]

On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o  wrote:
>
> It's here:  https://goo.gl/photos/xHjn2Z97JQEw6k2C9

You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's almost guaranteed to be
that

   crtc->dev

access as part of list_for_each_entry(), with crtc being NULL. And
yes, "->dev" is the very first field, so the offset is zero too (while
the "->mode_config" list access would not be at offset zero).

And it looks like it is called from drm_atomic_helper_check_modeset():
the reason it has a question mark in the backtrace is because the
fault happens before the stack frame has even been set up.

There are multiple calls to "drm_crtc_index()" from that function, I
can't tell which one it is. Looking at the code generation I get, I
think it's because update_connector_routing() gets inlined, and that
one does several calls. Most of them look like this:

if (connector->state->crtc) {
idx = drm_crtc_index(connector->state->crtc);

ie they check that the crtc is non-NULL, but that last one does not:

connector_state->best_encoder = new_encoder;
idx = drm_crtc_index(connector_state->crtc);

crtc_state = state->crtc_states[idx];
crtc_state->mode_changed = true;

and I suspect the fix might be something like the attached. Totally
untested. Ted?

This whole "atomic modeset" series has been one royal fuck-up, guys.
We've had too many of these kinds of crap issues.

   Linus
-- next part --
 drivers/gpu/drm/drm_atomic_helper.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5b59d5ad7d1c..aac212297b49 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -230,10 +230,12 @@ update_connector_routing(struct drm_atomic_state *state, 
int conn_idx)
}

connector_state->best_encoder = new_encoder;
-   idx = drm_crtc_index(connector_state->crtc);
+   if (connector_state->crtc) {
+   idx = drm_crtc_index(connector_state->crtc);

-   crtc_state = state->crtc_states[idx];
-   crtc_state->mode_changed = true;
+   crtc_state = state->crtc_states[idx];
+   crtc_state->mode_changed = true;
+   }

DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on 
[CRTC:%d]\n",
 connector->base.id,

[PATCH v2 0/22] On-demand device probing

[Rob Herring]

On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
 wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
>
> While reading the thread [1] that Alexander Holler started with his
> series to make probing order deterministic, it occurred to me that it
> should be possible to achieve the same by probing devices as they are
> referenced by other devices.
>
> This basically reuses the information that is already implicit in the
> probe() implementations, saving us from refactoring existing drivers or
> adding information to DTBs.
>
> During review of v1 of this series Linus Walleij suggested that it
> should be the device driver core to make sure that dependencies are
> ready before probing a device. I gave this idea a try [2] but Mark Brown
> pointed out to the logic duplication between the resource acquisition
> and dependency discovery code paths (though I think it's fairly minor).
>
> To address that code duplication I experimented with Arnd's devm_probe
> [3] concept of having drivers declare their dependencies instead of
> acquiring them during probe, and while it worked [4], I don't think we
> end up winning anything when compared to just probing devices on-demand
> from resource getters.
>
> One remaining objection is to the "sprinkling" of calls to
> fwnode_ensure_device() in the resource getters of each subsystem, but I
> think it's the right thing to do given that the storage of resources is
> currently subsystem-specific.

Seems like a minor change to me.

> We could avoid the above by moving resource storage into the core, but I
> don't think there's a compelling case for that.
>
> I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
> and these patches were enough to eliminate all the deferred probes
> (except one in PandaBoard because omap_dma_system doesn't have a
> firmware node as of yet).
>
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.

Generally, I think this looks pretty good. It is simple and the error
path is simply falling back to deferred probe.

One overall comment is I'm not so sure if fwnode_ensure_device
shouldn't just be of_ensure_device. At least currently, it looks like
all the calling locations are DT specific functions anyway. There's
very little logic within the function to really benefit sharing with
ACPI. It is basically just a call to of_platform_device_find and then
bus_probe_device. I expect the get functions will always call into
DT/ACPI specific functions which can then call the firmware specific
device find function.

Rob

[PATCH] drm: panel-simple: add URT UMSH-8596MD-xT panel support

[Maciej S. Szmigiero]

This patch adds support for United Radiant Technology
UMSH-8596MD-xT 7.0" WVGA TFT LCD panels
(both LVDS and parallel versions) to DRM
panel-simple driver.

Signed-off-by: Maciej Szmigiero 
---
 .../devicetree/bindings/panel/urt,umsh-8596md.txt  |   11 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/gpu/drm/panel/panel-simple.c   |   42 
 3 files changed, 54 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt

diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt 
b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
new file mode 100644
index 000..2990e6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
@@ -0,0 +1,11 @@
+United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
+
+Supported are LVDS versions (-11T, -19T) and parallel ones
+(-T, -1T, -7T, -20T).
+
+Required properties:
+- compatible: should be "urt,umsh-8596md-lvds" for LVDS versions,
+  "urt,umsh-8596md-parallel" for parallel ones.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d247994..f2bb617 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -212,6 +212,7 @@ toshiba Toshiba Corporation
 toumaz Toumaz
 tplink TP-LINK Technologies Co., Ltd.
 truly  Truly Semiconductors Limited
+urtUnited Radiant Technology Corporation
 usiUniversal Scientific Industrial Co., Ltd.
 v3 V3 Semiconductor
 variscite  Variscite Ltd.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..be47fd7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = 
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };

+static const struct display_timing urt_umsh_8596md_timing = {
+   .pixelclock = { 3326, 3326, 3326 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 41, 41, 41 },
+   .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+   .hsync_len = { 71, 128, 128 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 10, 10, 10 },
+   .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+   .vsync_len = { 2, 2, 2 },
+   .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+   DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+   .timings = _umsh_8596md_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1125,6 +1161,12 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
}, {
+   .compatible = "urt,umsh-8596md-lvds",
+   .data = _umsh_8596md_lvds,
+   }, {
+   .compatible = "urt,umsh-8596md-parallel",
+   .data = _umsh_8596md_parallel,
+   }, {
/* sentinel */
}
 };

[PATCH v2] drm/exynos: clear channels only when iommu is enabled

[Inki Dae]

+ samsung-soc

On 2015년 07월 28일 17:51, Joonyoung Shim wrote:
> This is simplest solution about reported problem[1]. It's no problem to
> clear channel only when iommu is enabled, if we consider that we cannot
> recognize iommu errors when iommu is disabled and it have been valid
> until now. But this cannot be nice solution.
> 
> [1] https://lkml.org/lkml/2015/7/21/404
> 
> Reported-by: Krzysztof Kozlowski 
> Signed-off-by: Joonyoung Shim 
> ---
> v2: add Reported-by.
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 8d362b9..337af02 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -956,7 +956,8 @@ static int fimd_bind(struct device *dev, struct device 
> *master, void *data)
>   if (ctx->display)
>   exynos_drm_create_enc_conn(drm_dev, ctx->display);
>  
> - fimd_clear_channels(ctx->crtc);
> + if (is_drm_iommu_supported(drm_dev))
> + fimd_clear_channels(ctx->crtc);
>  
>   ret = drm_iommu_attach_device(drm_dev, dev);
>   if (ret)
> 

[Bug 91136] [tahiti xt] portal2/dota2 glitchy without R600_DEBUG=switch_on_eop

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

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

--- Comment #5 from Sylvain BERTRAND  ---
I was wrong, vsync makes the remaining glitches more rare, but still around.

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

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Richard Harman]

(long time lurker, first time poster)

This (because the dock has a DP MST hub built in) reminds me of this
crash w/ my W540 - which I think are pretty similar hardware:

https://bugzilla.redhat.com/show_bug.cgi?id=1180747

Not enough of a coder to really troubleshoot, but I've got a dock, a MST
hub, and I'm willing to compile & test patches.  I've mostly left the HW
... disused because I was disgusted that my W530 could drive four
displays at once, and the W540 appears incapable due to the Intel chip
only supporting 3 CRTCs.

How can I help?

On 07/29/15 21:39, Theodore Ts'o wrote:
> On Wed, Jul 29, 2015 at 08:49:37PM -0400, Theodore Ts'o wrote:
>> Unfortunately the failure causes a series of recursive faults and I
>> haven't been able to capture the stack trace, but on 4.2-rcX kernels,
>> I can reliably cause the system to crash if my T540p is booted with
>> the docking station attached.
>>
>> It will also crash if I boot the system first, and then insert the
>> laptop into the dockstation.
>>
>> Unfortunately, I can't get a stack trace because there are a huge
>> number of recursive/double faults, and the system dies so quickly that
>> nothing ends up in the log files.  If you really need a stack dump I
>> can try to rig something, but modern Laptops don't have serial
>> consoles any more, alas, so it's bit of a pain.
> The bad news is that I tried to use kdump to capture a crashdump and
> hopefully get more information, and kdump utterly wedged on the panic.
> The good news is because it wedged the system, I was able to get the
> console stackdump before it scrolled off due to a whole series of
> recursive oops messages.
>
> It's here:  https://goo.gl/photos/xHjn2Z97JQEw6k2C9
>
> Hopefully tihs is useful.  It's not obvious how to revert this change,
> since there were a large number of changes to i915 after this.  If
> someone could help me with a revert, I'd be happy to test it.
>
> Thanks,
>
>   - Ted
>   
>
>
>> I was able to bisect it down to this commit, however: 8c7b5ccb72987:
>> "drm/i915: Use atomic helpers for computing changed flags:"
>>
>> Is there any chance Intel could add a Lenovo Dockstation with a
>> Multistream DP output to part of your test hardware?  Unfortunately it
>> seems pretty common that I see regressions with my particular
>> hardware.  Maybe there aren't enough people using Thinkpads any more?  :-(
>>
>>- Ted
>>
>>
>> P.S.  The git bisect log
>>
>> git bisect start
>> # bad: [421d125c06c4be4c5005cb69840206bd09b71dd6] builddeb: sign the modules 
>> after splitting out the debuginfo files
>> git bisect bad 421d125c06c4be4c5005cb69840206bd09b71dd6
>> # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
>> git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345
>> # good: [aeaa2122af4e53f3bfd28e8f294557bb95af43fc] drm/i915/skl: Add the 
>> INIT power domain to the MISC I/O power well
>> git bisect good aeaa2122af4e53f3bfd28e8f294557bb95af43fc
>> # bad: [4d70f38a760ad2879d2ebd84001c92980180f630] drm/i915/bios: remove a 
>> redundant NULL pointer check
>> git bisect bad 4d70f38a760ad2879d2ebd84001c92980180f630
>> # bad: [27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25] drm/i915/bxt: Enable 
>> WaEnableYV12BugFixInHalfSliceChicken7 for Broxton
>> git bisect bad 27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25
>> # good: [4be0731786de10d0e9ae1d159504c83c6b052647] drm/i915: Add crtc states 
>> before calling compute_config()
>> git bisect good 4be0731786de10d0e9ae1d159504c83c6b052647
>> # good: [d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1] drm/i915: Stage new 
>> modeset state straight into atomic state
>> git bisect good d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1
>> # bad: [a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10] drm/i915: Swap atomic 
>> state in legacy modeset
>> git bisect bad a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10
>> # bad: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic 
>> helpers for computing changed flags
>> git bisect bad 8c7b5ccb729870e606321b3703e2c2e698c49a95
>> # good: [0f63cca2afdc38877e86acfa9821020f6e2213fd] drm/i915: Update crtc 
>> state active flag based on DPMS
>> git bisect good 0f63cca2afdc38877e86acfa9821020f6e2213fd
>> # good: [840bfe953384a134c8639f2964d9b74bfa671e16] drm/atomic: Make 
>> mode_fixup() optional for check_modeset()
>> git bisect good 840bfe953384a134c8639f2964d9b74bfa671e16
>> # first bad commit: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use 
>> atomic helpers for computing changed flags
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[REGRESSION] Re: i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

On Wed, Jul 29, 2015 at 08:49:37PM -0400, Theodore Ts'o wrote:
> 
> Unfortunately the failure causes a series of recursive faults and I
> haven't been able to capture the stack trace, but on 4.2-rcX kernels,
> I can reliably cause the system to crash if my T540p is booted with
> the docking station attached.
> 
> It will also crash if I boot the system first, and then insert the
> laptop into the dockstation.
> 
> Unfortunately, I can't get a stack trace because there are a huge
> number of recursive/double faults, and the system dies so quickly that
> nothing ends up in the log files.  If you really need a stack dump I
> can try to rig something, but modern Laptops don't have serial
> consoles any more, alas, so it's bit of a pain.

The bad news is that I tried to use kdump to capture a crashdump and
hopefully get more information, and kdump utterly wedged on the panic.
The good news is because it wedged the system, I was able to get the
console stackdump before it scrolled off due to a whole series of
recursive oops messages.

It's here:  https://goo.gl/photos/xHjn2Z97JQEw6k2C9

Hopefully tihs is useful.  It's not obvious how to revert this change,
since there were a large number of changes to i915 after this.  If
someone could help me with a revert, I'd be happy to test it.

Thanks,

- Ted



> 
> I was able to bisect it down to this commit, however: 8c7b5ccb72987:
> "drm/i915: Use atomic helpers for computing changed flags:"
> 
> Is there any chance Intel could add a Lenovo Dockstation with a
> Multistream DP output to part of your test hardware?  Unfortunately it
> seems pretty common that I see regressions with my particular
> hardware.  Maybe there aren't enough people using Thinkpads any more?  :-(
> 
> - Ted
> 
> 
> P.S.  The git bisect log
> 
> git bisect start
> # bad: [421d125c06c4be4c5005cb69840206bd09b71dd6] builddeb: sign the modules 
> after splitting out the debuginfo files
> git bisect bad 421d125c06c4be4c5005cb69840206bd09b71dd6
> # good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
> git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345
> # good: [aeaa2122af4e53f3bfd28e8f294557bb95af43fc] drm/i915/skl: Add the INIT 
> power domain to the MISC I/O power well
> git bisect good aeaa2122af4e53f3bfd28e8f294557bb95af43fc
> # bad: [4d70f38a760ad2879d2ebd84001c92980180f630] drm/i915/bios: remove a 
> redundant NULL pointer check
> git bisect bad 4d70f38a760ad2879d2ebd84001c92980180f630
> # bad: [27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25] drm/i915/bxt: Enable 
> WaEnableYV12BugFixInHalfSliceChicken7 for Broxton
> git bisect bad 27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25
> # good: [4be0731786de10d0e9ae1d159504c83c6b052647] drm/i915: Add crtc states 
> before calling compute_config()
> git bisect good 4be0731786de10d0e9ae1d159504c83c6b052647
> # good: [d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1] drm/i915: Stage new 
> modeset state straight into atomic state
> git bisect good d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1
> # bad: [a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10] drm/i915: Swap atomic state 
> in legacy modeset
> git bisect bad a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10
> # bad: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic 
> helpers for computing changed flags
> git bisect bad 8c7b5ccb729870e606321b3703e2c2e698c49a95
> # good: [0f63cca2afdc38877e86acfa9821020f6e2213fd] drm/i915: Update crtc 
> state active flag based on DPMS
> git bisect good 0f63cca2afdc38877e86acfa9821020f6e2213fd
> # good: [840bfe953384a134c8639f2964d9b74bfa671e16] drm/atomic: Make 
> mode_fixup() optional for check_modeset()
> git bisect good 840bfe953384a134c8639f2964d9b74bfa671e16
> # first bad commit: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use 
> atomic helpers for computing changed flags
> 

[PATCH v2 18/22 EXPERIMENTAL] vga_switcheroo: Allow using active client as proxy when reading DDC/AUX

[Lukas Wunner]

The retina MacBook Pro uses an eDP panel and a gmux controller to switch
the panel between its two GPUs. Unfortunately it seems that it cannot
switch the AUX channel separately from the main link.

But we can emulate switching of DDC/AUX in software by using the active
client as a proxy to talk to the panel.

Allow storing pointers to each client's struct i2c_adapter (for DDC) and
struct drm_dp_aux. Allow retrieving the active client's structures but
constrain access to vga_switcheroo clients to prevent non-clients from
using proxying.

Drivers store AUX first, then DDC because they access the DPCD before
the EDID. Retrieving AUX is only allowed if DDC is also stored, thereby
avoiding race condition where AUX is already stored but not DDC and the
inactive client uses AUX then fails on retrieving the EDID via DDC.

Upon storing DDC, generate hotplug event so that already registered
inactive clients reprobe once the active client has registered its
DDC/AUX structures.

Based (loosely) on patches by Matthew Garrett 
who let the active client stash the EDID and the first 8 bytes of the
DPCD (receiver capabilities) in vga_switcheroo where the inactive client
would subsequently pick it up. It turns out that the drivers are unhappy
with just 8 bytes of DPCD, they need access to the full DPCD to set up
their outputs. Switching in software gives us more options (even write
access to the DPCD if need be):
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0016-vga_switcheroo-Allow-stashing-of-panel-data.patch

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko 
[MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
Tested-by: William Brown 
[MBP  8,2 2011  intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner 
[MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
Tested-by: Bruno Bierbaumer 
[MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 62 
 include/linux/vga_switcheroo.h   | 11 +++
 2 files changed, 73 insertions(+)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 94b0b6f..0c52eb4 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -19,6 +19,7 @@
  */

 #include 
+#include 

 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 
@@ -37,6 +39,8 @@
 struct vga_switcheroo_client {
struct pci_dev *pdev;
struct fb_info *fb_info;
+   struct i2c_adapter *ddc;
+   struct drm_dp_aux *aux;
struct work_struct reprobe_work;
int pwr_state;
const struct vga_switcheroo_client_ops *ops;
@@ -355,6 +359,64 @@ out:
 }
 EXPORT_SYMBOL(vga_switcheroo_unlock_ddc);

+void vga_switcheroo_set_ddc(struct pci_dev *pdev, struct i2c_adapter *ddc)
+{
+   struct vga_switcheroo_client *client;
+
+   mutex_lock(_mutex);
+   client = find_client_from_pci(_priv.clients, pdev);
+   if (client)
+   client->ddc = ddc;
+   mutex_unlock(_mutex);
+
+   /* DDC is stored after AUX on eDP, so we have both now */
+   if (client->active)
+   vga_switcheroo_reprobe_inactive_clients();
+}
+EXPORT_SYMBOL(vga_switcheroo_set_ddc);
+
+struct i2c_adapter *vga_switcheroo_get_ddc(struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *active = NULL;
+
+   mutex_lock(_mutex);
+   if (find_client_from_pci(_priv.clients, pdev))
+   active = find_active_client(_priv.clients);
+   mutex_unlock(_mutex);
+   if (!active)
+   return NULL;
+
+   return active->ddc;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_ddc);
+
+void vga_switcheroo_set_aux(struct pci_dev *pdev, struct drm_dp_aux *aux)
+{
+   struct vga_switcheroo_client *client;
+
+   mutex_lock(_mutex);
+   client = find_client_from_pci(_priv.clients, pdev);
+   if (client)
+   client->aux = aux;
+   mutex_unlock(_mutex);
+}
+EXPORT_SYMBOL(vga_switcheroo_set_aux);
+
+struct drm_dp_aux *vga_switcheroo_get_aux(struct pci_dev *pdev)
+{
+   struct vga_switcheroo_client *active = NULL;
+
+   mutex_lock(_mutex);
+   if (find_client_from_pci(_priv.clients, pdev))
+   active = find_active_client(_priv.clients);
+   mutex_unlock(_mutex);
+   if (!active || !active->ddc)
+   return NULL;
+
+   return active->aux;
+}
+EXPORT_SYMBOL(vga_switcheroo_get_aux);
+
 static int vga_switcheroo_show(struct seq_file *m, void *v)
 {
struct vga_switcheroo_client *client;
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index b935d83..1d4c07e 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -10,7 +10,10 @@
 #ifndef _LINUX_VGA_SWITCHEROO_H_
 #define _LINUX_VGA_SWITCHEROO_H_

[PATCH 1/2] drm/doc: Add hflip/vflip property descriptions in msm

[jil...@codeaurora.org]

Thanks for this information, Daniel.
I will change it to use rotation prop in next patch.
> On Mon, Jul 27, 2015 at 06:57:33PM -0400, Jilai Wang wrote:
>> Add plane properties hflip/vflip which are used in MDP driver to flip
>> the input horizontally/vertically.
>>
>> Signed-off-by: Jilai Wang 
>
> Is the existing rotation prop with flip masks not enough?
> -Daniel
>
>> ---
>>  Documentation/DocBook/drm.tmpl | 18 --
>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl
>> b/Documentation/DocBook/drm.tmpl
>> index d9f5613..bef6d34 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -3501,8 +3501,8 @@ void intel_crt_init(struct drm_device *dev)
>>  TBD
>>  
>>  
>> -msm
>> -Generic
>> +msm
>> +Generic
>>  "premultiplied"
>>  ENUM
>>  { "false", "true" }
>> @@ -3523,6 +3523,20 @@ void intel_crt_init(struct drm_device *dev)
>>  Plane
>>  property to set plane's z position during
>> blending
>>  
>> +
>> +"hflip"
>> +ENUM
>> +{ "off", "on" }
>> +Plane
>> +property to flip the input horizontally
>> +
>> +
>> +"vflip"
>> +ENUM
>> +{ "off", "on" }
>> +Plane
>> +property to flip the input vertically
>> +
>>  
>>  
>>  
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> a Linux Foundation Collaborative Project
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>

i915 driver crashes on T540p if docking station attached

[Theodore Ts'o]

Unfortunately the failure causes a series of recursive faults and I
haven't been able to capture the stack trace, but on 4.2-rcX kernels,
I can reliably cause the system to crash if my T540p is booted with
the docking station attached.

It will also crash if I boot the system first, and then insert the
laptop into the dockstation.

Unfortunately, I can't get a stack trace because there are a huge
number of recursive/double faults, and the system dies so quickly that
nothing ends up in the log files.  If you really need a stack dump I
can try to rig something, but modern Laptops don't have serial
consoles any more, alas, so it's bit of a pain.

I was able to bisect it down to this commit, however: 8c7b5ccb72987:
"drm/i915: Use atomic helpers for computing changed flags:"

Is there any chance Intel could add a Lenovo Dockstation with a
Multistream DP output to part of your test hardware?  Unfortunately it
seems pretty common that I see regressions with my particular
hardware.  Maybe there aren't enough people using Thinkpads any more?  :-(

  - Ted


P.S.  The git bisect log

git bisect start
# bad: [421d125c06c4be4c5005cb69840206bd09b71dd6] builddeb: sign the modules 
after splitting out the debuginfo files
git bisect bad 421d125c06c4be4c5005cb69840206bd09b71dd6
# good: [b953c0d234bc72e8489d3bf51a276c5c4ec85345] Linux 4.1
git bisect good b953c0d234bc72e8489d3bf51a276c5c4ec85345
# good: [aeaa2122af4e53f3bfd28e8f294557bb95af43fc] drm/i915/skl: Add the INIT 
power domain to the MISC I/O power well
git bisect good aeaa2122af4e53f3bfd28e8f294557bb95af43fc
# bad: [4d70f38a760ad2879d2ebd84001c92980180f630] drm/i915/bios: remove a 
redundant NULL pointer check
git bisect bad 4d70f38a760ad2879d2ebd84001c92980180f630
# bad: [27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25] drm/i915/bxt: Enable 
WaEnableYV12BugFixInHalfSliceChicken7 for Broxton
git bisect bad 27a1b688d9f1fa2abd14bfe6a8729a19fb3b1b25
# good: [4be0731786de10d0e9ae1d159504c83c6b052647] drm/i915: Add crtc states 
before calling compute_config()
git bisect good 4be0731786de10d0e9ae1d159504c83c6b052647
# good: [d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1] drm/i915: Stage new modeset 
state straight into atomic state
git bisect good d5432a9d19b61ba6a2b3d88f3026e0ca60eb57a1
# bad: [a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10] drm/i915: Swap atomic state 
in legacy modeset
git bisect bad a821fc46bc7bb6d4cf9a5f8d2787fd70231c2c10
# bad: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use atomic helpers 
for computing changed flags
git bisect bad 8c7b5ccb729870e606321b3703e2c2e698c49a95
# good: [0f63cca2afdc38877e86acfa9821020f6e2213fd] drm/i915: Update crtc state 
active flag based on DPMS
git bisect good 0f63cca2afdc38877e86acfa9821020f6e2213fd
# good: [840bfe953384a134c8639f2964d9b74bfa671e16] drm/atomic: Make 
mode_fixup() optional for check_modeset()
git bisect good 840bfe953384a134c8639f2964d9b74bfa671e16
# first bad commit: [8c7b5ccb729870e606321b3703e2c2e698c49a95] drm/i915: Use 
atomic helpers for computing changed flags

[Bug 91480] Dead Island: Crash loading Act 3 possible shader issue

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

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

Sven Arvidsson  changed:

   What|Removed |Added

Version|10.6|git

--- Comment #4 from Sven Arvidsson  ---
I reproduced the bug with git master e933d545997de9e50a8ed5247722c1c786bf4858.

I tried making a trace, but Dead Island segfaults right away if started with
apitrace.

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

[PATCH] [linux-next] drm:bridge: Fix warning while make xmldocs caused by drm_crtc.h

[Masanari Iida]

This patch fix following warning while make xmldocs.

.//include/drm/drm_crtc.h:933: warning: Excess struct/union/enum/typedef
member 'base' description in 'drm_bridge'

Signed-off-by: Masanari Iida 
---
 include/drm/drm_crtc.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5746569..382c10a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -915,7 +915,6 @@ struct drm_bridge_funcs {
  * @next: the next bridge in the encoder chain
  * @of_node: device node pointer to the bridge
  * @list: to keep track of all added bridges
- * @base: base mode object
  * @funcs: control functions
  * @driver_private: pointer to the bridge driver's internal context
  */
-- 
2.5.0

[PATCH libdrm] man: remove .man_fixup workaround

[Emil Velikov]

On 16 July 2015 at 19:05, Jonathan Gray  wrote:
> On Thu, Jul 16, 2015 at 04:55:40PM +0100, Emil Velikov wrote:
>> The whole thing is quite messy - the file is used to indicate that the
>> man pages were correctly generated prior to applying the "fixup" (alias)
>>
>> At the same time we use a rule with the same name, to create the same
>> file if the generation has failed.
>>
>> In other words - it attempts to create the file either way. So there is
>> little point in it and we can remove it.
>>
>> Spotted while attempting to build with bmake which kindly blocked on the
>> following (non compliant construct)
>>
>> .man_fixup: | $(miscman_DATA)
>>
>> Cc: Jonathan Gray 
>> Signed-off-by: Emil Velikov 
>> ---
>>
>> Jonathan,
>>
>> With the following patch libdrm build fine on my Arch + bmake.
>> The `dist' target is still broken, yet `all' and `check' work great.
>>
>> Will you guys consider moving back to the upstream build ? As mentioned
>> before if there are problems do mention/file bugs so that we can get
>> them sorted.
>
> Hi Emil,
>
> I've taken a quick look at extracting patches from the OpenBSD version
> and put the result up here:
>
> https://github.com/jonathangray/drm/commits/openbsd
>
> I'm in Canada at the moment so won't be able to test on Radeon for a
> week or so but this seems to work on i915 at least.
>
> Currently we don't duplicate the public drm headers between userland
> and the kernel but we could move back to doing things that
> way.
>
> I can clean those patches up and submit them if you like.
> The xenocara wrapper makefile is just to fit into the
> system makefiles so you can ignore that one.
This and your three patches are in master now.

Hopefully we'll get the remaining diff between libdrm and
{Open,Net,*}BSD sorted in the not too distant future :)

Thanks
Emil

[Nouveau] [PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

[Hans de Goede]

Hi,

On 28-07-15 09:26, Ben Skeggs wrote:
> On 28 July 2015 at 01:52, Hans de Goede  wrote:
>> Hi,
>>
>> On 24-07-15 04:32, Ben Skeggs wrote:
>>>
>>> On 24 July 2015 at 01:20, Hans de Goede  wrote:

 MSI interrupts appear to not work for nv46 based cards. Change the mc
 subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
 identical to the nv44 mc code except that it does not use msi
 (it does not define a msi_rearm callback).
>>>
>>> I'm fine with this, but it'd be nice to check that the binary driver
>>> doesn't/can't use MSI on these too (there might be an alternate method
>>> we need to use).
>>>
>>> Would you be able to grab the latest proprietary driver that works on
>>> nv4x, and do a mmiotrace of it?
>>
>>
>> I've grabbed 304.125
>>
>>> You *might* need to use "modprobe
>>> nvidia NVreg_EnableMSI=1", because at some point NVIDIA didn't use it
>>> by default anywhere.
>>
>>
>> You're right I needed to specify NVreg_EnableMSI=1, with that set
>> /proc/interrupts shows that MSI is used.
>>
>> Here is an of running glxgears with the binary driver using msi interrupts
>> mmiotrace:
>>
>> https://fedorapeople.org/~jwrdegoede/nvidia-bin-nv46-msi-on-glxgears.mmiotrace.gz
>>
>> AFAIK there are some nouveau tools to parse this a bit, right ? I'm going
>> to call it a day for today, if you can give me some pointers what to do with
>> the
>> mmiotrace to find a potential fix for the msi issues, that would be
>> appreciated.

I've run demmio on this as suggested by Ilia, I've checked all the writes
to the pmc pbus and pci ranges, and I've been unable to find anything which
helps I'm afraid. I've also checked the interrupt regs of the crt block, and
those are correct, and the interrupt flag for vblank is set.

So I'm all out of clues I'm afraid. One thing which does stand out is that
lspci -vvv shows the following differences between nouveau vs nvidea output:

@@ -361,23 +361,23 @@
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Ste
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
-   Kernel driver in use: nouveau
+   Kernel driver in use: nvidia
 Kernel modules: nouveau, nvidia

The DevSta shows that we are sending some commands the device does not like.

At first I thought this would be the culprit, but as discussed before on some
boots things just work and on others they do not (when using nouveau). I've
checked a boot with nouveau where things just happen to work, and there
UncorrErr+ and UnsuppReq+ are still set when things just work.

So I'm officially giving up on this, and I'm going to continue to work on
the nv46 with msi disabled.

Note that when things do not work, we do get some interrupts, they just stop
coming at one point shortly after boot.

>> BTW I had to build my own kernel with mmiotrace enabled in Kconfig, as this
>> is disabled in the Fedora kernels by default. Do you know if there is a good
>> reason to have this disabled by default, or should I ask the Fedora
>> kernel maintainers to enable it by default ?
> The -debug kernel has it enabled already.  However, it's also
> problematic in that it enables various lockdep debugging stuff that
> causes the binary driver kernel module to end up depending on GPL-only
> symbols, which you have to hack around by changing the
> MODULE_LICENSE() for the binary driver to "GPL"... Which is clearly a
> pain :)  So, I guess if you want a slightly more straight-forward
> approach, it'd be good to enable in the non-debug kernels too.

Ok, before I submit a patch to the Fedora kernel devs for this, mmiotrace
uses live patching like the other ftrace stuff, so no performance impact
unless actually used, right ?

>
>>
>>
>> Slightly offtopic:
>>
>> I decided to be bold and try gnome-shell on the nv46 with msi disabled,
>> which sofar was a guaranteed way to freeze the system, and it now works
>> somewhat (latest kernel, ddx and mesa). I see something which shows
>> horizontal lines which are small parts from my desktop background, and
>> things change significantly when I switch to the overview mode.
>>
>> But other then that the display is completely wrong, it looks a bit
>> like a framebuffer pitch problem, but then different. I think it
>> is likely some tiling problem or some such.
>>
>> Note that metacity + glxgears works, this only shows with
>> gnome-shell, any hints where to start looking wrt debugging this?

> These are the main issues that I'd like to see resolved :)

Agreed getting gnome-shell running is really the minimum level we should
support cards at.

>> Or should I first try to run piglet and see if some tests there
>> point out the culprit?
> I think this is a good place to start.

Ok, will do.

Regards,

Hans

[PATCH v3 1/9] drm/exynos: pass the correct pipe number

[Gustavo Padovan]

Hi Inki,

Any comments about this series?

Thanks,

Gustavo

2015-07-16 Gustavo Padovan :

> From: Gustavo Padovan 
> 
> Instead of giving -1 to as arg to  drm_send_vblank_event() pass the
> correct pipe number to it.
> 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 644b4b7..22b9ca0 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device 
> *dev, int pipe)
>   spin_lock_irqsave(>event_lock, flags);
>   if (exynos_crtc->event) {
>  
> - drm_send_vblank_event(dev, -1, exynos_crtc->event);
> + drm_send_vblank_event(dev, pipe, exynos_crtc->event);
>   drm_vblank_put(dev, pipe);
>   wake_up(_crtc->pending_flip_queue);
>  
> -- 
> 2.1.0
> 

[PATCH] libdrm/amdgpu: Fixed drm.h include.

[Alex Deucher]

On Tue, Jul 28, 2015 at 10:35 PM, Alexandr Akulich
 wrote:
> On Wed, Jul 22, 2015 at 1:20 PM, Michel Dänzer  wrote:
>> On 22.07.2015 16:33, Alexandr Akulich wrote:
>>> On Wed, Jul 22, 2015 at 1:19 PM, Michel Dänzer  
>>> wrote:
 On 17.07.2015 22:33, Alexandr Akulich wrote:
> As I see, this is not a kernel header, but a local (belongs to libdrm) 
> one.
> (Otherwise, I would like you to point me on such file at, say,
> https://github.com/torvalds/linux/tree/master/include/drm)

 https://github.com/torvalds/linux/blob/master/include/uapi/drm/amdgpu_drm.h


> At files drm_sarea.h, mga_drm.h, qxl_drm.h, radeon_drm.h and via_drm.h we 
> have
>
> #include "drm.h"
>
> At the same time, at i915_drm.h and tegra_drm.h. we have
>
> #include 
>
> I'm pretty sure that the first case is correct, because drm.h is
> always would be local file (in the same directory), related to
> amdgpu_drm.h, and that is why local include "drm.h" would be always
> valid.

 Makes sense to me, the patch is

 Reviewed-by: Michel Dänzer 
>>> Thanks! I have no write access to this fd.o repository. Can you apply it 
>>> please?
>>
>> I assume your patch is against the amdgpu branch of
>> http://cgit.freedesktop.org/~agd5f/drm/, right? Only Alex Deucher has
>> write access to that.
>
> Well, what I can do?
> Alex, can you apply the patch, please?

Applied.  thanks!

Alex

[pull] amdgpu and radeon drm-fixes-4.2

[Alex Deucher]

Hi Dave,

Radeon and amdgpu fixes for 4.2.  The audio fix ended up being more
invasive than I would have liked, but this should finally fix up the
last of the regressions since DP audio support was added.

The following changes since commit 520e8bfc35066d4344adf13081e59bfde30aa36d:

  Merge branch 'linux-4.2' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2015-07-29 
17:21:38 +1000)

are available in the git repository at:


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

for you to fetch changes up to 194a33643b1161fe7a054fa9bf43875ae0f6e1e8:

  drm/amdgpu: add new parameter to seperate map and unmap (2015-07-29 16:06:45 
-0400)


Alex Deucher (4):
  drm/radeon: rework audio detect (v4)
  drm/radeon: rework audio modeset to handle non-audio hdmi features
  drm/radeon/combios: add some validation of lvds values
  drm/amdgpu: clean up init sequence for failures

Dan Carpenter (1):
  drm/amdgpu: information leak in amdgpu_info_ioctl()

Michel Dänzer (2):
  drm/radeon: Drop drm/ prefix for including drm.h in radeon_drm.h
  drm/amdgpu: Drop drm/ prefix for including drm.h in amdgpu_drm.h

monk.liu (3):
  drm/amdgpu: different emit_ib for gfx and compute
  drm/amdgpu: hdp_flush is not needed for inside IB
  drm/amdgpu: add new parameter to seperate map and unmap

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  38 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |  16 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  46 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  47 +--
 drivers/gpu/drm/radeon/atombios_encoders.c |   3 +-
 drivers/gpu/drm/radeon/dce6_afmt.c |  62 -
 drivers/gpu/drm/radeon/radeon_audio.c  | 204 ++---
 drivers/gpu/drm/radeon/radeon_audio.h  |   3 +-
 drivers/gpu/drm/radeon/radeon_combios.c|   7 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |  18 ++-
 drivers/gpu/drm/radeon/radeon_mode.h   |   2 +-
 include/uapi/drm/amdgpu_drm.h  |   2 +-
 include/uapi/drm/radeon_drm.h  |   2 +-
 16 files changed, 267 insertions(+), 205 deletions(-)

[pull] drm/msm: fixes for 4.2

[Rob Clark]

Fix for nasty crash on mdp4 in disable path, fix for dma-buf export,
smb leak on mdp5 which could result in intermittent modeset fails, and
don't let interrupted system call disturb atomic commit once we are
past the point of no return.

BR,
-R

The following changes since commit 520e8bfc35066d4344adf13081e59bfde30aa36d:

  Merge branch 'linux-4.2' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes
(2015-07-29 17:21:38 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.2

for you to fetch changes up to b4cba04f05ed6b9b2278547295ecc5c40180e612:

  drm/msm/mdp5: release SMB (shared memory blocks) in various cases
(2015-07-29 16:38:24 -0400)


Archit Taneja (1):
  drm/msm: mdp4: Fix drm_framebuffer dereference crash

Rob Clark (1):
  drm/msm: fix msm_gem_prime_get_sg_table()

Wentao Xu (2):
  drm/msm: change to uninterruptible wait in atomic commit
  drm/msm/mdp5: release SMB (shared memory blocks) in various cases

 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 13 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   | 87 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h   |  1 +
 drivers/gpu/drm/msm/msm_atomic.c  |  8 +--
 drivers/gpu/drm/msm/msm_drv.c | 13 +++--
 drivers/gpu/drm/msm/msm_drv.h |  4 +-
 drivers/gpu/drm/msm/msm_gem.c |  2 +-
 drivers/gpu/drm/msm/msm_gem_prime.c   |  8 ++-
 11 files changed, 127 insertions(+), 48 deletions(-)

[PATCH v14 6/6] arm:dts:ls1021a: Add a TFT LCD panel dts node

[Jianwei Wang]

Add a TFT LCD panel. the TFT LCD panel is WQVGA "480x272",
and the bpp is 24.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..2443329 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -56,6 +56,17 @@
enet0_sgmii_phy = _phy2;
enet1_sgmii_phy = _phy0;
};
+
+   panel: panel {
+   compatible = "nec,nl4827hc19_05b";
+   };
+
+};
+
+ {
+   fsl,panel = <>;
+   status = "okay";
+
 };

  {
-- 
2.1.0.27.g96db324

[PATCH v14 5/6] arm:dts:ls1021a: Add DCU dts node

[Jianwei Wang]

Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
 <_clk 1>;
};

+   dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324

[PATCH v14 4/6] MAINTAINERS: add Freescale DCU DRM driver maintainer

[Jianwei Wang]

Add Alison and myself as maintainers of the Freescale DCU DRM driver.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c9dd5f..66746e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3555,6 +3555,15 @@ F:   drivers/gpu/drm/exynos/
 F: include/drm/exynos*
 F: include/uapi/drm/exynos*

+DRM DRIVERS FOR FREESCALE DCU
+M: Jianwei Wang 
+M: Alison Wang 
+L: dri-devel at lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/video/fsl,dcu.txt
+F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
+
 DRM DRIVERS FOR FREESCALE IMX
 M: Philipp Zabel 
 L: dri-devel at lists.freedesktop.org
-- 
2.1.0.27.g96db324

[PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Jianwei Wang]

This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
simple panel driver.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
Acked-by: Daniel Vetter 
---
 .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt

diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt 
b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
new file mode 100644
index 000..20e9473
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
@@ -0,0 +1,7 @@
+NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "nec,nl4827hc19_05b"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..db61dd1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -943,6 +943,29 @@ static const struct panel_desc lg_lp129qe = {
},
 };

+static const struct drm_display_mode nec_nl4827hc19_05b_mode = {
+   .clock = 10870,
+   .hdisplay = 480,
+   .hsync_start = 480 + 2,
+   .hsync_end = 480 + 2 + 41,
+   .htotal = 480 + 2 + 41 + 2,
+   .vdisplay = 272,
+   .vsync_start = 272 + 2,
+   .vsync_end = 272 + 2 + 4,
+   .vtotal = 272 + 2 + 4 + 2,
+   .vrefresh = 74,
+};
+
+static const struct panel_desc nec_nl4827hc19_05b = {
+   .modes = _nl4827hc19_05b_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24
+};
+
 static const struct drm_display_mode ortustech_com43h4m85ulc_mode  = {
.clock = 25000,
.hdisplay = 480,
@@ -1113,6 +1136,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lp129qe",
.data = _lp129qe,
}, {
+   .compatible = "nec,nl4827hc19_05b",
+   .data = _nl4827hc19_05b,
+   }, {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
-- 
2.1.0.27.g96db324

[PATCH v14 2/6] devicetree: Add NEC to the vendor-prefix list

[Jianwei Wang]

NEC represent NEC LCD Technologies, Ltd.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..42ca6bc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -140,6 +140,7 @@ mundoreader Mundo Reader S.L.
 murata Murata Manufacturing Co., Ltd.
 mxicy  Macronix International Co., Ltd.
 national   National Semiconductor
+necNEC LCD Technologies, Ltd.
 neonodeNeonode Inc.
 netgearNETGEAR
 netlogic   Broadcom Corporation (formerly NetLogic Microsystems)
-- 
2.1.0.27.g96db324

[PATCH v14 1/6] drm/layerscape: Add Freescale DCU DRM driver

[Jianwei Wang]

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA BGRA ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.

This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
Acked-by: Daniel Vetter 
---
 .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/fsl-dcu/Kconfig|  18 +
 drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  19 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 404 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 197 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  23 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  43 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  33 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 261 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  17 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  | 182 ++
 15 files changed, 1437 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,dcu.txt
 create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig
 create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c

diff --git a/Documentation/devicetree/bindings/video/fsl,dcu.txt 
b/Documentation/devicetree/bindings/video/fsl,dcu.txt
new file mode 100644
index 000..ebf1be9
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,dcu.txt
@@ -0,0 +1,22 @@
+Device Tree bindings for Freescale DCU DRM Driver
+
+Required properties:
+- compatible:  Should be one of
+   * "fsl,ls1021a-dcu".
+   * "fsl,vf610-dcu".
+
+- reg: Address and length of the register set for dcu.
+- clocks:  From common clock binding: handle to dcu clock.
+- clock-names: From common clock binding: Shall be "dcu".
+- big-endian   Boolean property, LS1021A DCU registers are big-endian.
+- fsl,panel:   The phandle to panel node.
+
+Examples:
+dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   fsl,panel = <>;
+};
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..9cfd14e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -231,6 +231,8 @@ source "drivers/gpu/drm/virtio/Kconfig"

 source "drivers/gpu/drm/msm/Kconfig"

+source "drivers/gpu/drm/fsl-dcu/Kconfig"
+
 source "drivers/gpu/drm/tegra/Kconfig"

 source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..11cb81e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_DRM_IMX) += imx/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
+obj-$(CONFIG_DRM_FSL_DCU) 

[PATCH v14 0/6] drm/layerscape: Add Freescale DCU DRM driver

[Jianwei Wang]

Changed in v14

-Remove drm_modeset_lock_all before drm_mode_config_reset

Changed in v13
-set regmap_config.cache_type to REGCACHE_RBTREE
-add call drm_modeset_lock_all before drm_mode_config_reset
-adjust patch order for creating pull request

Changed in v12

-Add one patch for MAINTAINER entry for drm/layerscape
Adviced by Daniel Vetter
-Add #include 

Changed in V11
-set regmap_config.cache_type to REGCACHE_FLAT
Advanced by Alexander Stein

Changed in V10
-adjust commit log, remove meaningless statement
-cleanup code for it's format and style.
-remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
-remove useless sentences: encoder->crtc = crtc; and connector->encoder = 
encoder; and so on
-add vendor prefix for panel pandle
-make a DCU_CTRLDESCLN(x, y)  to avoid high repetition
-introduce per-SoC capability structure to avoid check on the OF node's 
compatible string
-Implement some functions: crtc enable and disable, enable and disable VBLANK, 
plane atomic_disable and atomic_enable -atomic_check and so on
-move DCU config sentence to the right place
-move get resources functions to  ->probe()
-move fsl,dcu.txt to video/ folder
-add big-endian describe
All advaced by Thierry Reding

Changed in V9

put node after calling of_drm_find_panel
split clk_prepare_enable() to clk_prepare() and clk_enable(), just call 
clk_prepare once, and check return value
check regmap_write/regmap_read return return value
remove useless ".owner= THIS_MODULE,"
All advanced by Mark Yao

Changed in V8

- Remove useless code
#define DRIVER_NAME "fsl-dcu-drm"
MODULE_ALIAS("platform:fsl-dcu-drm");
Adviced by Paul Bolle

Changed in V7

- Remove redundant functions and replace deprecated hook
Adviced by Daniel Vetter
- Replace drm_platform_init with drm_dev_alloc/register
Adviced by Daniel Vetter

Changed in V6

- Add NEC nl4827hc19_05b panel to panel-simple.c
Adviced by Mark Yao
- Add DRIVER_ATOMIC for driver_features
Adviced by Mark Yao
- check fsl_dev if it's NULL at PM suspend/resume
Adviced by Mark Yao

Changed in V5

- Update commit message
- Add layer registers initialization
- Remove unused functions
- Rename driver folder
Adviced by Stefan Agner
- Move pixel clock control functions to fsl_dcu_drm_drv.c
- remove redundant enable the clock implicitly using regmap
- Add maintainer message

Changed in V4:

-This version doesn't have functionality changed
Just a minor adjustment.

Changed in V3:

- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
Adviced by Daniel Vetter
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt

Changed in v2:
- Add atomic support
Adviced by Daniel Vetter
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility
Adviced by Stefan Agner


This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA BGRA ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.

This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.

---
 .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/fsl-dcu/Kconfig|  18 +
 drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  19 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 404 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 197 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  23 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  

[PATCH v13 0/6] drm/layerscape: Add Freescale DCU DRM driver

[Jianwei Wang]

On Wed, Jul 29, 2015 at 3:21 PM, Daniel Vetter  wrote:
> On Wed, Jul 29, 2015 at 02:54:46PM +0800, Jianwei Wang wrote:
>> Changed in v13
>> -set regmap_config.cache_type to REGCACHE_RBTREE
>> -add call drm_modeset_lock_all before drm_mode_config_reset
>
> This was a bug in one of my recently merged patches, please don't call
> drm_modeset_lock_all before config_reset. Instead please test "drm: Fixup
> locking WARNINGs in drm_mode_config_reset" which should address this
> problem too.
>

I have test that patch, It's okay. I'll remove drm_modeset_lock_all.

Thanks
Jianwei

> Thanks, Daniel
>
>> -adjust patch order for creating pull request
>>
>> Changed in v12
>>
>> -Add one patch for MAINTAINER entry for drm/layerscape
>> Adviced by Daniel Vetter
>> -Add #include 
>>
>> Changed in V11
>> -set regmap_config.cache_type to REGCACHE_FLAT
>> Advanced by Alexander Stein
>>
>> Changed in V10
>> -adjust commit log, remove meaningless statement
>> -cleanup code for it's format and style.
>> -remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
>> -remove useless sentences: encoder->crtc = crtc; and connector->encoder = 
>> encoder; and so on
>> -add vendor prefix for panel pandle
>> -make a DCU_CTRLDESCLN(x, y)  to avoid high repetition
>> -introduce per-SoC capability structure to avoid check on the OF node's 
>> compatible string
>> -Implement some functions: crtc enable and disable, enable and disable 
>> VBLANK, plane atomic_disable and atomic_enable -atomic_check and so on
>> -move DCU config sentence to the right place
>> -move get resources functions to  ->probe()
>> -move fsl,dcu.txt to video/ folder
>> -add big-endian describe
>> All advaced by Thierry Reding
>>
>> Changed in V9
>>
>> put node after calling of_drm_find_panel
>> split clk_prepare_enable() to clk_prepare() and clk_enable(), just call 
>> clk_prepare once, and check return value
>> check regmap_write/regmap_read return return value
>> remove useless ".owner= THIS_MODULE,"
>> All advanced by Mark Yao
>>
>> Changed in V8
>>
>> - Remove useless code
>> #define DRIVER_NAME "fsl-dcu-drm"
>> MODULE_ALIAS("platform:fsl-dcu-drm");
>> Adviced by Paul Bolle
>>
>> Changed in V7
>>
>> - Remove redundant functions and replace deprecated hook
>> Adviced by Daniel Vetter
>> - Replace drm_platform_init with drm_dev_alloc/register
>> Adviced by Daniel Vetter
>>
>> Changed in V6
>>
>> - Add NEC nl4827hc19_05b panel to panel-simple.c
>> Adviced by Mark Yao
>> - Add DRIVER_ATOMIC for driver_features
>> Adviced by Mark Yao
>> - check fsl_dev if it's NULL at PM suspend/resume
>> Adviced by Mark Yao
>>
>> Changed in V5
>>
>> - Update commit message
>> - Add layer registers initialization
>> - Remove unused functions
>> - Rename driver folder
>> Adviced by Stefan Agner
>> - Move pixel clock control functions to fsl_dcu_drm_drv.c
>> - remove redundant enable the clock implicitly using regmap
>> - Add maintainer message
>>
>> Changed in V4:
>>
>> -This version doesn't have functionality changed
>> Just a minor adjustment.
>>
>> Changed in V3:
>>
>> - Test driver on Vybrid board and add compatible string
>> - Remove unused functions
>> - set default crtc for encoder
>> - replace legacy functions with atomic help functions
>> Adviced by Daniel Vetter
>> - Set the unique name of the DRM device
>> - Implement irq handle function for vblank interrupt
>>
>> Changed in v2:
>> - Add atomic support
>> Adviced by Daniel Vetter
>> - Modify bindings file
>> - Rename node for compatibility
>> - Move platform related code out for compatibility
>> Adviced by Stefan Agner
>>
>> This patch add support for Two Dimensional Animation and Compositing
>> Engine (2D-ACE) on the Freescale SoCs.
>>
>> 2D-ACE is a Freescale display controller. 2D-ACE describes
>> the functionality of the module extremely well its name is a value
>> that cannot be used as a token in programming languages.
>> Instead the valid token "DCU" is used to tag the register names and
>> function names.
>>
>> The Display Controller Unit (DCU) module is a system master that
>> fetches graphics stored in internal or external memory and displays
>> them on a TFT LCD panel. A wide range of panel sizes is supported
>> and the timing of the interface signals is highly configurable.
>> Graphics are read directly from memory and then blended in real-time,
>> which allows for dynamic content creation with minimal CPU
>> intervention.
>>
>> The features:
>> (1) Full RGB888 output to TFT LCD panel.
>> (2) Blending of each pixel using up to 4 source layers
>> dependent
>> on size of panel.
>> (3) Each graphic layer can be placed with one pixel resolution
>> in either axis.
>> (4) Each graphic layer support RGB565 and RGB888 direct colors
>> without alpha channel and BGRA BGRA ARGB1555 direct
>> colors
>> with an alpha channel and YUV422 format.
>> (5) Each graphic layer support alpha blending with 8-bit
>> resolution.
>>
>> .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
>> 

[Bug 70227] OpenCL reaper-prime app crashes due to atomic_or unimplemented

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

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

Serge Martin <edb+freedesktop at sigluy.net> changed:

   What|Removed |Added

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

--- Comment #3 from Serge Martin <edb+freedesktop at sigluy.net> ---
atomic should be ok with libclc from r217914 (the 17/09/2014)

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

[PATCH v13 6/6] arm:dts:ls1021a: Add a TFT LCD panel dts node

[Jianwei Wang]

Add a TFT LCD panel. the TFT LCD panel is WQVGA "480x272",
and the bpp is 24.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..2443329 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -56,6 +56,17 @@
enet0_sgmii_phy = _phy2;
enet1_sgmii_phy = _phy0;
};
+
+   panel: panel {
+   compatible = "nec,nl4827hc19_05b";
+   };
+
+};
+
+ {
+   fsl,panel = <>;
+   status = "okay";
+
 };

  {
-- 
2.1.0.27.g96db324

[PATCH v13 5/6] arm:dts:ls1021a: Add DCU dts node

[Jianwei Wang]

Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
 <_clk 1>;
};

+   dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324

[PATCH v13 4/6] MAINTAINERS: add Freescale DCU DRM driver maintainer

[Jianwei Wang]

Add Alison and myself as maintainers of the Freescale DCU DRM driver.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c9dd5f..66746e4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3555,6 +3555,15 @@ F:   drivers/gpu/drm/exynos/
 F: include/drm/exynos*
 F: include/uapi/drm/exynos*

+DRM DRIVERS FOR FREESCALE DCU
+M: Jianwei Wang 
+M: Alison Wang 
+L: dri-devel at lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/video/fsl,dcu.txt
+F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
+
 DRM DRIVERS FOR FREESCALE IMX
 M: Philipp Zabel 
 L: dri-devel at lists.freedesktop.org
-- 
2.1.0.27.g96db324

[PATCH v13 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Jianwei Wang]

This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
simple panel driver.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
Acked-by: Daniel Vetter 
---
 .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt

diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt 
b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
new file mode 100644
index 000..20e9473
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
@@ -0,0 +1,7 @@
+NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "nec,nl4827hc19_05b"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..db61dd1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -943,6 +943,29 @@ static const struct panel_desc lg_lp129qe = {
},
 };

+static const struct drm_display_mode nec_nl4827hc19_05b_mode = {
+   .clock = 10870,
+   .hdisplay = 480,
+   .hsync_start = 480 + 2,
+   .hsync_end = 480 + 2 + 41,
+   .htotal = 480 + 2 + 41 + 2,
+   .vdisplay = 272,
+   .vsync_start = 272 + 2,
+   .vsync_end = 272 + 2 + 4,
+   .vtotal = 272 + 2 + 4 + 2,
+   .vrefresh = 74,
+};
+
+static const struct panel_desc nec_nl4827hc19_05b = {
+   .modes = _nl4827hc19_05b_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24
+};
+
 static const struct drm_display_mode ortustech_com43h4m85ulc_mode  = {
.clock = 25000,
.hdisplay = 480,
@@ -1113,6 +1136,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lp129qe",
.data = _lp129qe,
}, {
+   .compatible = "nec,nl4827hc19_05b",
+   .data = _nl4827hc19_05b,
+   }, {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
-- 
2.1.0.27.g96db324

[PATCH v13 2/6] devicetree: Add NEC to the vendor-prefix list

[Jianwei Wang]

NEC represent NEC LCD Technologies, Ltd.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index d444757..42ca6bc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -140,6 +140,7 @@ mundoreader Mundo Reader S.L.
 murata Murata Manufacturing Co., Ltd.
 mxicy  Macronix International Co., Ltd.
 national   National Semiconductor
+necNEC LCD Technologies, Ltd.
 neonodeNeonode Inc.
 netgearNETGEAR
 netlogic   Broadcom Corporation (formerly NetLogic Microsystems)
-- 
2.1.0.27.g96db324

[PATCH v13 1/6] drm/layerscape: Add Freescale DCU DRM driver

[Jianwei Wang]

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA BGRA ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.

This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
Acked-by: Daniel Vetter 
---
 .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/fsl-dcu/Kconfig|  18 +
 drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  19 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 404 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 197 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  23 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  45 +++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  33 ++
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 261 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  17 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  | 182 ++
 15 files changed, 1439 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/fsl,dcu.txt
 create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig
 create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h
 create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c

diff --git a/Documentation/devicetree/bindings/video/fsl,dcu.txt 
b/Documentation/devicetree/bindings/video/fsl,dcu.txt
new file mode 100644
index 000..ebf1be9
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,dcu.txt
@@ -0,0 +1,22 @@
+Device Tree bindings for Freescale DCU DRM Driver
+
+Required properties:
+- compatible:  Should be one of
+   * "fsl,ls1021a-dcu".
+   * "fsl,vf610-dcu".
+
+- reg: Address and length of the register set for dcu.
+- clocks:  From common clock binding: handle to dcu clock.
+- clock-names: From common clock binding: Shall be "dcu".
+- big-endian   Boolean property, LS1021A DCU registers are big-endian.
+- fsl,panel:   The phandle to panel node.
+
+Examples:
+dcu: dcu at 2ce {
+   compatible = "fsl,ls1021a-dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   fsl,panel = <>;
+};
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..9cfd14e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -231,6 +231,8 @@ source "drivers/gpu/drm/virtio/Kconfig"

 source "drivers/gpu/drm/msm/Kconfig"

+source "drivers/gpu/drm/fsl-dcu/Kconfig"
+
 source "drivers/gpu/drm/tegra/Kconfig"

 source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..11cb81e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -70,3 +70,4 @@ obj-$(CONFIG_DRM_IMX) += imx/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
+obj-$(CONFIG_DRM_FSL_DCU) 

[PATCH v13 0/6] drm/layerscape: Add Freescale DCU DRM driver

[Jianwei Wang]

Changed in v13
-set regmap_config.cache_type to REGCACHE_RBTREE
-add call drm_modeset_lock_all before drm_mode_config_reset
-adjust patch order for creating pull request

Changed in v12

-Add one patch for MAINTAINER entry for drm/layerscape
Adviced by Daniel Vetter
-Add #include 

Changed in V11
-set regmap_config.cache_type to REGCACHE_FLAT
Advanced by Alexander Stein

Changed in V10
-adjust commit log, remove meaningless statement
-cleanup code for it's format and style.
-remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
-remove useless sentences: encoder->crtc = crtc; and connector->encoder = 
encoder; and so on
-add vendor prefix for panel pandle
-make a DCU_CTRLDESCLN(x, y)  to avoid high repetition
-introduce per-SoC capability structure to avoid check on the OF node's 
compatible string
-Implement some functions: crtc enable and disable, enable and disable VBLANK, 
plane atomic_disable and atomic_enable -atomic_check and so on
-move DCU config sentence to the right place
-move get resources functions to  ->probe()
-move fsl,dcu.txt to video/ folder
-add big-endian describe
All advaced by Thierry Reding

Changed in V9

put node after calling of_drm_find_panel
split clk_prepare_enable() to clk_prepare() and clk_enable(), just call 
clk_prepare once, and check return value
check regmap_write/regmap_read return return value
remove useless ".owner= THIS_MODULE,"
All advanced by Mark Yao

Changed in V8

- Remove useless code
#define DRIVER_NAME "fsl-dcu-drm"
MODULE_ALIAS("platform:fsl-dcu-drm");
Adviced by Paul Bolle

Changed in V7

- Remove redundant functions and replace deprecated hook
Adviced by Daniel Vetter
- Replace drm_platform_init with drm_dev_alloc/register
Adviced by Daniel Vetter

Changed in V6

- Add NEC nl4827hc19_05b panel to panel-simple.c
Adviced by Mark Yao
- Add DRIVER_ATOMIC for driver_features
Adviced by Mark Yao
- check fsl_dev if it's NULL at PM suspend/resume
Adviced by Mark Yao

Changed in V5

- Update commit message
- Add layer registers initialization
- Remove unused functions
- Rename driver folder
Adviced by Stefan Agner
- Move pixel clock control functions to fsl_dcu_drm_drv.c
- remove redundant enable the clock implicitly using regmap
- Add maintainer message

Changed in V4:

-This version doesn't have functionality changed
Just a minor adjustment.

Changed in V3:

- Test driver on Vybrid board and add compatible string
- Remove unused functions
- set default crtc for encoder
- replace legacy functions with atomic help functions
Adviced by Daniel Vetter
- Set the unique name of the DRM device
- Implement irq handle function for vblank interrupt

Changed in v2:
- Add atomic support
Adviced by Daniel Vetter
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility
Adviced by Stefan Agner

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.

2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.

The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.

The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA BGRA ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.

.../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
drivers/gpu/drm/Kconfig|   2 +
drivers/gpu/drm/Makefile   |   1 +
drivers/gpu/drm/fsl-dcu/Kconfig|  18 +
drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 208 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h |  19 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  | 404 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 197 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c|  23 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c  |  45 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h   |  33 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 261 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h|  17 +

[PATCH 0/4] enable migration of driver pages

[Daniel Vetter]

On Wed, Jul 29, 2015 at 01:16:14PM +0100, Mel Gorman wrote:
> On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
> > > On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> > > > My ARM-based platform occured severe fragmentation problem after 
> > > > long-term
> > > > (several days) test. Sometimes even order-3 page allocation failed. It 
> > > > has
> > > > memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
> > > > processing
> > > > and 20~30 memory is reserved for zram.
> > > > 
> > > 
> > > The primary motivation of this series is to reduce fragmentation by 
> > > allowing
> > > more kernel pages to be moved. Conceptually that is a worthwhile goal but
> > > there should be at least one major in-kernel user and while balloon
> > > pages were a good starting point, I think we really need to see what the
> > > zram changes look like at the same time.
> > 
> > I think gpu drivers really would be the perfect candidate for compacting
> > kernel page allocations. And this also seems the primary motivation for
> > this patch series, so I think that's really what we should use to judge
> > these patches.
> > 
> > Of course then there's the seemingly eternal chicken/egg problem of
> > upstream gpu drivers for SoCs :(
> 
> I recognised that the driver he had modified was not an in-tree user so
> it did not really help the review or the design. I did not think it was
> very fair to ask that an in-tree GPU driver be converted when it would not
> help the embedded platform of interest. Converting zram is both a useful
> illustration of the aops requirements and is expected to be beneficial on
> the embedded platform. Now, if a GPU driver author was willing to convert
> theirs as an example then that would be useful!

Well my concern is more with merging infrastructure to upstream for
drivers which aren't upstream and with no plan to make that happen anytime
soon. Seems like just offload a bit to me ... but in the end core mm isn't
my thing so not my decision.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

drm properties, ABI and compositors

[Daniel Vetter]

Hi all,

I've discussed drm props and ABI requirements a bit with Dave on irc.
In the past we've been pretty lax with properties since connector
properties are mostly meant for end-users to set manually, so not
really much point in standardizing and treating them like ABI. But now
we have props for plane/CRTC and atomic and those are really meant to
be used by compositors, so all the problems with ABI start to kick in.
And we had them already, e.g. early i915 patches for rotation where cw
while existing omap supports was ccw. I also just spotted msm patches
which reinvent the mirror flags of the rotation prop with their own
flip prop. And there's a lot of things in-progress already like
zpos/alpha/blending props, color manager/per-plane gamma, ...

To avoid future ABI disaster I think we should treat these props like
any other drm ABI and require full-blown userspace, so here that would
be a real implementation in something like weston, -modesetting, the
new cros thing or maybe even hwc if that ever happens as an
open-source project. And test tools like modetest don't cut it since
upside down desktop is obvious, upside down test pattern meh. And
modetest doesn't bother with all the TEST_ONLY and failure recory
stuff like e.g. weston atomic needs to.

Internally I think we should also try to standarize prop handling by
pushing them into drm_*_state structs and adding decoding in core and
good helpers. And hopefully soon we have markdown for kerneldoc so can
transform that horrible docbook table into something sane. But that's
just internals which we can always fix. ABI's forever.

Anyway this is all kinda just clarification at least for i915. props
for compositors are ABI like anything else, same rules still apply.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] drm/atomic: refuse changing CRTC for planes while active

[Daniel Vetter]

Very strictly speaking this is possible if you have special hw and
genlocked CRTCs. In general switching a plane between two active CRTC
just won't work so well and is probably not tested at all. Just forbid
it.

The exception is when both CRTC do a full modeset, then it should be
no problem at all to move the planes around (presuming a correct
implementation) so allow that case.

I've put this into the core since I really couldn't come up with a
case where we don't want to enforce that. But if that ever happens it
would be easy to move this check into helpers.

Cc: Thierry Reding 
Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c| 38 +
 drivers/gpu/drm/drm_atomic_helper.c |  1 +
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 434915448ea0..422183e7ee7d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -663,6 +663,38 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
 }

+/* checks whether a plane has its CRTC switched while being in active use. */
+static bool
+active_plane_switching(struct drm_atomic_state *state,
+  struct drm_plane *plane,
+  struct drm_plane_state *plane_state)
+{
+   struct drm_crtc_state *crtc_state, *curr_crtc_state;
+
+   if (!plane->state->crtc || !plane_state->crtc)
+   return false;
+
+   if (plane->state->crtc == plane_state->crtc)
+   return false;
+
+   curr_crtc_state = plane->state->crtc->state;
+   if (!curr_crtc_state->active)
+   return false;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   plane_state->crtc);
+   if (!crtc_state->active)
+   return false;
+
+   /* plane switching CRTC and both CRTC are active. This is only ok if
+* both CRTC do a full modeset. */
+   if (drm_atomic_crtc_needs_modeset(curr_crtc_state) &&
+   drm_atomic_crtc_needs_modeset(crtc_state))
+   return false;
+
+   return true;
+}
+
 /**
  * drm_atomic_plane_check - check plane state
  * @plane: plane to check
@@ -734,6 +766,12 @@ static int drm_atomic_plane_check(struct drm_plane *plane,
return -ENOSPC;
}

+   if (active_plane_switching(state->state, plane, state)) {
+   DRM_DEBUG_ATOMIC("[PLANE:%d] switching active CRTC without 
modeset\n",
+plane->base.id);
+   return -EINVAL;
+   }
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 6be0adb5a0e9..54c59ddc59a5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -497,6 +497,7 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
 plane->base.id);
return ret;
}
+
}

for_each_crtc_in_state(state, crtc, crtc_state, i) {
-- 
2.5.0

[PATCH 2/3] drm/rcar: Only update planes on active crtc

[Daniel Vetter]

R-car does runtime pm (that's why it's committing plane state only at
the end). Therefore better to only update planes on active crtc. Note
that since the helpers always add all enabled planes when doing a
modeset change on a crtc we are guaranteed to update plane hw state to
the latest requested state each time the crtc is enabled.

Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ca12e8ca5552..20813582fbf1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -456,7 +456,7 @@ static void rcar_du_atomic_complete(struct rcar_du_commit 
*commit)
/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
drm_atomic_helper_commit_modeset_enables(dev, old_state);
-   drm_atomic_helper_commit_planes(dev, old_state, false);
+   drm_atomic_helper_commit_planes(dev, old_state, true);

drm_atomic_helper_wait_for_vblanks(dev, old_state);

-- 
2.5.0

[PATCH 1/3] drm/atomic-helper: Add option to update planes only on active crtc

[Daniel Vetter]

With drivers supporting runtime pm it's generally not a good idea to
touch the hardware when it's off. Add an option to the commit_planes
helper to support this case.

Note that the helpers already add all planes on a crtc when a modeset
happens, hence plane updates will not be lost if drivers set this to
true.

v2: Check for NULL state->crtc before chasing the pointer. Also check
both old and new crtc if there's a switch. Finally just outright
disallow switching crtcs for a plane if the plane is in active use, on
most hardware that doesn't make sense.

v3: Since commit_planes(active_only = true) is for enabling things
only after all the crtc are on we should only look at the new crtc to
decide whether to call the plane hooks - if the current CRTC isn't on
then skip. If the old crtc (when moving a plane) went down then the
plane should have been disabled as part of the pipe shutdown work
already. For which there's currently no helper really unfortunately.
Also move the check for wether a plane gets a new CRTC assigned while
still in active use out of this patch.

Cc: Maarten Lankhorst 
Cc: Thierry Reding 
Cc: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c| 20 ++--
 drivers/gpu/drm/exynos/exynos_drm_fb.c |  2 +-
 drivers/gpu/drm/msm/msm_atomic.c   |  2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |  2 +-
 drivers/gpu/drm/sti/sti_drm_drv.c  |  2 +-
 drivers/gpu/drm/tegra/drm.c|  2 +-
 include/drm/drm_atomic_helper.h|  3 ++-
 8 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0b475fae067d..6be0adb5a0e9 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1029,7 +1029,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,

drm_atomic_helper_commit_modeset_disables(dev, state);

-   drm_atomic_helper_commit_planes(dev, state);
+   drm_atomic_helper_commit_planes(dev, state, false);

drm_atomic_helper_commit_modeset_enables(dev, state);

@@ -1144,10 +1144,16 @@ fail:
 }
 EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);

+bool plane_crtc_active(struct drm_plane_state *state)
+{
+   return state->crtc && state->crtc->state->active;
+}
+
 /**
  * drm_atomic_helper_commit_planes - commit plane state
  * @dev: DRM device
  * @old_state: atomic state object with old state structures
+ * @active_only: Only commit on active CRTC if set
  *
  * This function commits the new plane state using the plane and atomic helper
  * functions for planes and crtcs. It assumes that the atomic state has already
@@ -1162,7 +1168,8 @@ EXPORT_SYMBOL(drm_atomic_helper_prepare_planes);
  * drm_atomic_helper_commit_planes_on_crtc() instead.
  */
 void drm_atomic_helper_commit_planes(struct drm_device *dev,
-struct drm_atomic_state *old_state)
+struct drm_atomic_state *old_state,
+bool active_only)
 {
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
@@ -1178,6 +1185,9 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs || !funcs->atomic_begin)
continue;

+   if (active_only && !crtc->state->active)
+   continue;
+
funcs->atomic_begin(crtc, old_crtc_state);
}

@@ -1189,6 +1199,9 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs)
continue;

+   if (active_only && !plane_crtc_active(plane->state))
+   continue;
+
/*
 * Special-case disabling the plane if drivers support it.
 */
@@ -1208,6 +1221,9 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs || !funcs->atomic_flush)
continue;

+   if (active_only && !crtc->state->active)
+   continue;
+
funcs->atomic_flush(crtc, old_crtc_state);
}
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 2b6320e6eae2..7b383acbb5af 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -293,7 +293,7 @@ static int exynos_atomic_commit(struct drm_device *dev,
 * have the relevant clocks enabled to perform the update.
 */

-   drm_atomic_helper_commit_planes(dev, state);
+   drm_atomic_helper_commit_planes(dev, state, false);

drm_atomic_helper_cleanup_planes(dev, state);

diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 1b22d8bfe142..0709b97251bf 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c

[PATCH 0/4] enable migration of driver pages

[Mel Gorman]

On Wed, Jul 29, 2015 at 12:55:54PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
> > On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> > > My ARM-based platform occured severe fragmentation problem after long-term
> > > (several days) test. Sometimes even order-3 page allocation failed. It has
> > > memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
> > > processing
> > > and 20~30 memory is reserved for zram.
> > > 
> > 
> > The primary motivation of this series is to reduce fragmentation by allowing
> > more kernel pages to be moved. Conceptually that is a worthwhile goal but
> > there should be at least one major in-kernel user and while balloon
> > pages were a good starting point, I think we really need to see what the
> > zram changes look like at the same time.
> 
> I think gpu drivers really would be the perfect candidate for compacting
> kernel page allocations. And this also seems the primary motivation for
> this patch series, so I think that's really what we should use to judge
> these patches.
> 
> Of course then there's the seemingly eternal chicken/egg problem of
> upstream gpu drivers for SoCs :(

I recognised that the driver he had modified was not an in-tree user so
it did not really help the review or the design. I did not think it was
very fair to ask that an in-tree GPU driver be converted when it would not
help the embedded platform of interest. Converting zram is both a useful
illustration of the aops requirements and is expected to be beneficial on
the embedded platform. Now, if a GPU driver author was willing to convert
theirs as an example then that would be useful!

-- 
Mel Gorman
SUSE Labs

[PATCH 0/4] enable migration of driver pages

[Daniel Vetter]

On Wed, Jul 29, 2015 at 11:49:45AM +0100, Mel Gorman wrote:
> On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> > My ARM-based platform occured severe fragmentation problem after long-term
> > (several days) test. Sometimes even order-3 page allocation failed. It has
> > memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
> > processing
> > and 20~30 memory is reserved for zram.
> > 
> 
> The primary motivation of this series is to reduce fragmentation by allowing
> more kernel pages to be moved. Conceptually that is a worthwhile goal but
> there should be at least one major in-kernel user and while balloon
> pages were a good starting point, I think we really need to see what the
> zram changes look like at the same time.

I think gpu drivers really would be the perfect candidate for compacting
kernel page allocations. And this also seems the primary motivation for
this patch series, so I think that's really what we should use to judge
these patches.

Of course then there's the seemingly eternal chicken/egg problem of
upstream gpu drivers for SoCs :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/atomic: Paper over locking WARN in default_state_clear

[Daniel Vetter]

In

commit 6f75cea66c8dd043ced282016b21a639af176642
Author: Daniel Vetter 
Date:   Wed Nov 19 18:38:07 2014 +0100

drm/atomic: Only destroy connector states with connection mutex held

I tried to fix races of atomic commits against connector
hot-unplugging. The idea is to ensure lifetimes by holding the
connection_mutex long enough. That works for synchronous commits, but
not for async ones.

For async atomic commit we really need to fix up connector lifetimes
for real. But that's a much bigger task, so just add more duct-tape:
For cleaning up connector states we currently don't need the connector
itself. So NULL it out and remove the locking check. Of course that
check was to protect the entire sequence, but the modeset itself
should be save since currently DP MST hot-removal does a dpms-off. And
that should synchronize with any outstanding async atomic commit.

Or at least that's my hope, this is all a giant mess.

Reported-by: Maarten Lankhorst 
Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3efd91c0c6cb..434915448ea0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -153,9 +153,15 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
if (!connector)
continue;

-   WARN_ON(!drm_modeset_is_locked(>connection_mutex));
-
-   connector->funcs->atomic_destroy_state(connector,
+   /*
+* FIXME: Async commits can race with connector unplugging and
+* there's currently nothing that prevents cleanup up state for
+* deleted connectors. As long as the callback doesn't look at
+* the connector we'll be fine though, so make sure that's the
+* case by setting all connector pointers to NULL.
+*/
+   state->connector_states[i]->connector = NULL;
+   connector->funcs->atomic_destroy_state(NULL,
   
state->connector_states[i]);
state->connectors[i] = NULL;
state->connector_states[i] = NULL;
-- 
2.5.0

[PATCH v2 1/2] drm/amdgpu: fix bug when amdkfd destroys hqd

[Alex Deucher]

On Wed, Jul 29, 2015 at 4:57 AM, Oded Gabbay  wrote:
> The wrong define was used to check if the hqd is still active
>
> v2: Don't use SHIFT as the MASK is already shifted
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> index 2daad33..dd2037b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> @@ -450,7 +450,7 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t 
> reset_type,
>
> while (true) {
> temp = RREG32(mmCP_HQD_ACTIVE);
> -   if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
> +   if (temp & CP_HQD_ACTIVE__ACTIVE_MASK)
> break;
> if (timeout == 0) {
> pr_err("kfd: cp queue preemption time out (%dms)\n",
> --
> 2.4.3
>

[PATCH] drm/tilcdc: panel: Add tilcdc- prefix to driver name

[Thierry Reding]

From: Thierry Reding 

The current driver name, "panel", is very generic. This causes problems
when the driver is enabled on non-TI device tree platforms if the panel
node is called "panel". This causes the driver name match fall-back in
platform_match() to succeed, even if some other driver would precisely
match using the OF device ID table, for example.

Currently there don't seem to be any in-tree users that rely on the
driver name match, so adding the prefix should be safe.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tilcdc/tilcdc_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c 
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 7a0315855e90..375505caf9c7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -460,7 +460,7 @@ struct platform_driver panel_driver = {
.remove = panel_remove,
.driver = {
.owner = THIS_MODULE,
-   .name = "panel",
+   .name = "tilcdc-panel",
.of_match_table = panel_of_match,
},
 };
-- 
2.4.5

[PATCH v2 1/2] drm/amdgpu: fix bug when amdkfd destroys hqd

[Oded Gabbay]

The wrong define was used to check if the hqd is still active

v2: Don't use SHIFT as the MASK is already shifted

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
index 2daad33..dd2037b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
@@ -450,7 +450,7 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t 
reset_type,

while (true) {
temp = RREG32(mmCP_HQD_ACTIVE);
-   if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
+   if (temp & CP_HQD_ACTIVE__ACTIVE_MASK)
break;
if (timeout == 0) {
pr_err("kfd: cp queue preemption time out (%dms)\n",
-- 
2.4.3

[PATCH 1/2] drm/amdgpu: fix bug when amdkfd destroys hqd

[Oded Gabbay]

On Wed, Jul 29, 2015 at 11:49 AM, Ilia Mirkin  wrote:
> On Wed, Jul 29, 2015 at 3:44 AM, Oded Gabbay  wrote:
>> The wrong define was used to check if the hqd is still active
>>
>> Signed-off-by: Oded Gabbay 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
>> index 2daad33..6a45330 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
>> @@ -450,7 +450,8 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t 
>> reset_type,
>>
>> while (true) {
>> temp = RREG32(mmCP_HQD_ACTIVE);
>> -   if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
>> +   if (temp & (CP_HQD_ACTIVE__ACTIVE_MASK <<
>> +   CP_HQD_ACTIVE__ACTIVE__SHIFT))
>
> It's a bit moot here since the shift is 0, but I thought the mask
> normally included the shift already...
>
> #define CP_MQD_BASE_ADDR__BASE_ADDR_MASK 0xfffc
> #define CP_MQD_BASE_ADDR__BASE_ADDR__SHIFT 0x2
>
> #define CP_HPD_EOP_CONTROL__PEND_SIG_SEM_MASK 0x8000
> #define CP_HPD_EOP_CONTROL__PEND_SIG_SEM__SHIFT 0x1f
>
> etc.
>
Absolutely correct and although it is muted here, still best practice
is to fix that.
Thanks!

   Oded
>> break;
>> if (timeout == 0) {
>> pr_err("kfd: cp queue preemption time out (%dms)\n",
>> --
>> 2.4.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amdkfd: fix bug when initializing sdma vm

[Alex Deucher]

On Wed, Jul 29, 2015 at 3:44 AM, Oded Gabbay  wrote:
> A logical AND operation was used during mask and shift, instead of a
> bitwise AND operation. This patch fixes this bug by changing the
> operation to bitwise AND.
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c | 2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> index 23ce774..c6f435a 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
> @@ -143,7 +143,7 @@ static void init_sdma_vm(struct device_queue_manager 
> *dqm, struct queue *q,
> get_sh_mem_bases_32(qpd_to_pdd(qpd));
> else
> value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
> -   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) 
> &&
> +   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
>
> q->properties.sdma_vm_addr = value;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
> index 44c38e8..7e9cae9 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
> @@ -155,7 +155,7 @@ static void init_sdma_vm(struct device_queue_manager 
> *dqm, struct queue *q,
> get_sh_mem_bases_32(qpd_to_pdd(qpd));
> else
> value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
> -   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) 
> &&
> +   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
>
> q->properties.sdma_vm_addr = value;
> --
> 2.4.3
>

[PATCH 2/4] mm/compaction: enable mobile-page migration

[Mel Gorman]

On Mon, Jul 13, 2015 at 05:35:17PM +0900, Gioh Kim wrote:
> From: Gioh Kim 
> 
> Add framework to register callback functions and check page mobility.
> There are some modes for page isolation so that isolate interface
> has arguments of page address and isolation mode while putback
> interface has only page address as argument.
> 
> Signed-off-by: Gioh Kim 
> Acked-by: Rafael Aquini 
> ---
>  fs/proc/page.c |  3 ++
>  include/linux/compaction.h | 80 
> ++
>  include/linux/fs.h |  2 +
>  include/linux/page-flags.h | 19 
>  include/uapi/linux/kernel-page-flags.h |  1 +
>  5 files changed, 105 insertions(+)
> 

An update to the address_space operations in
Documentation/filesystems/Locking and Documentation/filesystems/vfs.txt
is required. I was going to say "recommended" but it really is required.
The responsibilities and locking rules of these interfaces must be extremely
clear as you may be asking multiple driver authors to use this interface.

For example, it must be clear to users of these interfaces that the isolate
must prevent any parallel updates to the data, prevent parallel frees and
halt attempted accesses until migration is complete. It will not always
be obvious how to do this and may not be obvious that it is required if
someone has not experienced the joy that is mm/migrate.c. For example,
mapped LRU pages get unmapped with migration entries so faults that access
the data wait until the migration completes. Balloons, zram, graphics will
need to provide similar guarantees.

As data accesses may now sleep due to migration, drivers will need to
be careful that it is safe to sleep and suggest that they do not attempt
to spin.

Depending on how it is implemented, the putback may be responsible for
waking up any tasks waiting to access the page.

There are going to be more hazards here which is why documentation to spell
it out is ideal and that zram gets converted to find all the locking and
access pitfalls.

> diff --git a/fs/proc/page.c b/fs/proc/page.c
> index 7eee2d8..a4f5a00 100644
> --- a/fs/proc/page.c
> +++ b/fs/proc/page.c
> @@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
>   if (PageBalloon(page))
>   u |= 1 << KPF_BALLOON;
>  
> + if (PageMobile(page))
> + u |= 1 << KPF_MOBILE;
> +
>   u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
>  
>   u |= kpf_copy_bit(k, KPF_SLAB,  PG_slab);
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index aa8f61c..f693072 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -1,6 +1,9 @@
>  #ifndef _LINUX_COMPACTION_H
>  #define _LINUX_COMPACTION_H
>  
> +#include 
> +#include 
> +
>  /* Return values for compact_zone() and try_to_compact_pages() */
>  /* compaction didn't start as it was deferred due to past failures */
>  #define COMPACT_DEFERRED 0
> @@ -51,6 +54,70 @@ extern void compaction_defer_reset(struct zone *zone, int 
> order,
>   bool alloc_success);
>  extern bool compaction_restarting(struct zone *zone, int order);
>  
> +static inline bool mobile_page(struct page *page)
> +{
> + return page->mapping && (PageMobile(page) || PageBalloon(page));
> +}
> +

This creates an oddity because now there is a disconnect between movable
and mobile pages. They are similar but different.

o A Mobile page is a driver-owned page that has the address space
  operations that enable migration.

o A Movable page is generally a page mapped by page tables that can be
  migrated using the existing mechanisms.

The concepts should be unified.

A Mobile page is a driver-owner page that has the address space
operations that enable migration. Pages that are mapped by userspace are
considered to be mobile with the following properties

a_ops->isolatepage isolates the page from the LRU to prevent
parallel reclaim. It is unmapped from page tables using rmap
with PTEs replaced by migration entries. Any attempt to access
the page will wait in page fault until the migration completes.

a_ops->putbackpage removes the migration entries and wakes up
all waiters in page fault.

A further property is that allocation of this type specified
__GFP_MOVABLE to group them all together. They are the most mobile
page category that are cheapest to move. In theory, all mobile
pages could be allocated __GFP_MOVABLE if it's known in advance
the page->mapping will have the necessary operations in the
future.

?

A complicating factor is that a Movable page as it's currently defined
may not have a page->mapping. You'd have to continue replying on PageLRU to
identify them as a special page that has access to the necessary isolateppage
and putbackpage helpers. However, at least we would have a single view
on what a movable page is.

Additional 

[PATCH 1/4] fs/anon_inodes: new interface to create new inode

[Mel Gorman]

On Mon, Jul 13, 2015 at 05:35:16PM +0900, Gioh Kim wrote:
> From: Gioh Kim 
> 
> The anon_inodes has already complete interfaces to create manage
> many anonymous inodes but don't have interface to get
> new inode. Other sub-modules can create anonymous inode
> without creating and mounting it's own pseudo filesystem.
> 
> Signed-off-by: Gioh Kim 
> Acked-by: Rafael Aquini 

This is my first run through the series so I'm going to miss details but
this patch confuses me a little. You create an inode to associate with
the balloon dev_info so that page->mapping can be assigned. It's only the
mapping you care about for the aops so why are multiple inodes required? A
driver should be able to share and reference count a single inode. The
motivation to do it that way would be to reduce memory consumption and
this series is motivated by embedded platforms.

anon_inode_getfd has the following

 * Creates a new file by hooking it on a single inode. This is useful for files
 * that do not need to have a full-fledged inode in order to operate correctly.
 * All the files created with anon_inode_getfd() will share a single inode,
 * hence saving memory and avoiding code duplication for the file/inode/dentry
 * setup.  Returns new descriptor or an error code.

If all we care about the inode is the aops then it would follow that
anon_inode_getfd() is ideal. The tradeoff is reference counting overhead.
The changelog needs to explain why anon_inode_getfd() cannot be used.

-- 
Mel Gorman
SUSE Labs

[PATCH 0/4] enable migration of driver pages

[Mel Gorman]

On Mon, Jul 13, 2015 at 05:35:15PM +0900, Gioh Kim wrote:
> My ARM-based platform occured severe fragmentation problem after long-term
> (several days) test. Sometimes even order-3 page allocation failed. It has
> memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic 
> processing
> and 20~30 memory is reserved for zram.
> 

The primary motivation of this series is to reduce fragmentation by allowing
more kernel pages to be moved. Conceptually that is a worthwhile goal but
there should be at least one major in-kernel user and while balloon
pages were a good starting point, I think we really need to see what the
zram changes look like at the same time.

> I found that many pages of GPU driver and zram are non-movable pages. So I
> reported Minchan Kim, the maintainer of zram, and he made the internal 
> compaction logic of zram. And I made the internal compaction of GPU driver.
> 

I am not familiar with the internals of zram but I took a look at what
it merged.  At a glance the compaction it implements and what you need are
are different in important respects. The core ability to move a zsmalloc
object is useful but the motivation of zram compaction appears to be
reducing the memory footprint. You need to reduce fragmentation which is
not the same. You could be faced with a situation where a full page in an
awkward place. Then there are three choices I can think of quickly and
probably more

1. You can move the whole page to another whole page and update all the
   references. This would play nicely with how compactions migrate and
   free scanner operates. However, you need free memory to move it

2. You could try moving the full page into other zsmalloc pages so that
   memory usage is also potentially reduced. This would work better with
   what Minchan intended but then there is the problem of discovery.
   Potentially it means though that another address space callback is
   required to nominate a target migration page

3. Hybrid approach. First trigger the zsmalloc compaction as it
   currently exists, then kick of compaction and move whole pages
   regardless of their content. The downside here is that it's expensive
   and potentially copies data multiple times but it's going to be
   easier to implement than 2.

1 would be the logical starting point, 3 is probably most effective even
if it's expensive and 2 is probably the best overall if the search costs
can be controlled.

This is a lot more complex than what balloon requires which is why I
would like to see it pinned down before new address_space operations are
created. Once they are created and drivers start using them then we lose
a lot of flexibilty and fixing the design becomes a lot harder.

With that in mind, I'll still read the rest of the series.

-- 
Mel Gorman
SUSE Labs

[PATCH V6 3/6] mm: Introduce VM_LOCKONFAULT

[Eric B Munson]

The cost of faulting in all memory to be locked can be very high when
working with large mappings.  If only portions of the mapping will be
used this can incur a high penalty for locking.

For the example of a large file, this is the usage pattern for a large
statical language model (probably applies to other statical or graphical
models as well).  For the security example, any application transacting
in data that cannot be swapped out (credit card data, medical records,
etc).

This patch introduces the ability to request that pages are not
pre-faulted, but are placed on the unevictable LRU when they are finally
faulted in.  The VM_LOCKONFAULT flag will be used together with
VM_LOCKED and has no effect when set without VM_LOCKED.  Setting the
VM_LOCKONFAULT flag for a VMA will cause pages faulted into that VMA to
be added to the unevictable LRU when they are faulted or if they are
already present, but will not cause any missing pages to be faulted in.

Exposing this new lock state means that we cannot overload the meaning
of the FOLL_POPULATE flag any longer.  Prior to this patch it was used
to mean that the VMA for a fault was locked.  This means we need the
new FOLL_MLOCK flag to communicate the locked state of a VMA.
FOLL_POPULATE will now only control if the VMA should be populated and
in the case of VM_LOCKONFAULT, it will not be set.

Signed-off-by: Eric B Munson 
Acked-by: Kirill A. Shutemov 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: Jonathan Corbet 
Cc: "Kirill A. Shutemov" 
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-mm at kvack.org
Cc: linux-api at vger.kernel.org
---
 drivers/gpu/drm/drm_vm.c |  8 +++-
 fs/proc/task_mmu.c   |  1 +
 include/linux/mm.h   |  2 ++
 kernel/fork.c|  2 +-
 mm/debug.c   |  1 +
 mm/gup.c | 10 --
 mm/huge_memory.c |  2 +-
 mm/hugetlb.c |  4 ++--
 mm/mlock.c   |  2 +-
 mm/mmap.c|  2 +-
 mm/rmap.c|  4 ++--
 11 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index aab49ee..103a5f6 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -699,9 +699,15 @@ int drm_vma_info(struct seq_file *m, void *data)
   (void *)(unsigned long)virt_to_phys(high_memory));

list_for_each_entry(pt, >vmalist, head) {
+   char lock_flag = '-';
+
vma = pt->vma;
if (!vma)
continue;
+   if (vma->vm_flags & VM_LOCKONFAULT)
+   lock_flag = 'f';
+   else if (vma->vm_flags & VM_LOCKED)
+   lock_flag = 'l';
seq_printf(m,
   "\n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000",
   pt->pid,
@@ -710,7 +716,7 @@ int drm_vma_info(struct seq_file *m, void *data)
   vma->vm_flags & VM_WRITE ? 'w' : '-',
   vma->vm_flags & VM_EXEC ? 'x' : '-',
   vma->vm_flags & VM_MAYSHARE ? 's' : 'p',
-  vma->vm_flags & VM_LOCKED ? 'l' : '-',
+  lock_flag,
   vma->vm_flags & VM_IO ? 'i' : '-',
   vma->vm_pgoff);

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ca1e091..38d69fc 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -579,6 +579,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct 
vm_area_struct *vma)
 #ifdef CONFIG_X86_INTEL_MPX
[ilog2(VM_MPX)] = "mp",
 #endif
+   [ilog2(VM_LOCKONFAULT)] = "lf",
[ilog2(VM_LOCKED)]  = "lo",
[ilog2(VM_IO)]  = "io",
[ilog2(VM_SEQ_READ)]= "sr",
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2e872f9..c2f3551 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -127,6 +127,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_PFNMAP  0x0400  /* Page-ranges managed without "struct 
page", just pure PFN */
 #define VM_DENYWRITE   0x0800  /* ETXTBSY on write attempts.. */

+#define VM_LOCKONFAULT 0x1000  /* Lock the pages covered when they are 
faulted in */
 #define VM_LOCKED  0x2000
 #define VM_IO   0x4000 /* Memory mapped I/O or similar */

@@ -2043,6 +2044,7 @@ static inline struct page *follow_page(struct 
vm_area_struct *vma,
 #define FOLL_NUMA  0x200   /* force NUMA hinting page fault */
 #define FOLL_MIGRATION 0x400   /* wait for page to replace migration entry */
 #define FOLL_TRIED 0x800   /* a retry, previous pass started an IO */
+#define FOLL_MLOCK 0x1000  /* lock present pages */

 typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
void *data);
diff --git a/kernel/fork.c b/kernel/fork.c
index 

[PATCH 2/2] drm/amdkfd: fix bug when initializing sdma vm

[Oded Gabbay]

A logical AND operation was used during mask and shift, instead of a
bitwise AND operation. This patch fixes this bug by changing the
operation to bitwise AND.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
index 23ce774..c6f435a 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
@@ -143,7 +143,7 @@ static void init_sdma_vm(struct device_queue_manager *dqm, 
struct queue *q,
get_sh_mem_bases_32(qpd_to_pdd(qpd));
else
value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
-   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&
+   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;

q->properties.sdma_vm_addr = value;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
index 44c38e8..7e9cae9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
@@ -155,7 +155,7 @@ static void init_sdma_vm(struct device_queue_manager *dqm, 
struct queue *q,
get_sh_mem_bases_32(qpd_to_pdd(qpd));
else
value |= ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
-   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&
+   SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &
SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;

q->properties.sdma_vm_addr = value;
-- 
2.4.3

[PATCH 1/2] drm/amdgpu: fix bug when amdkfd destroys hqd

[Oded Gabbay]

The wrong define was used to check if the hqd is still active

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
index 2daad33..6a45330 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
@@ -450,7 +450,8 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t 
reset_type,

while (true) {
temp = RREG32(mmCP_HQD_ACTIVE);
-   if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
+   if (temp & (CP_HQD_ACTIVE__ACTIVE_MASK <<
+   CP_HQD_ACTIVE__ACTIVE__SHIFT))
break;
if (timeout == 0) {
pr_err("kfd: cp queue preemption time out (%dms)\n",
-- 
2.4.3

drm/amdkfd: Add support for VI in DQM

[Oded Gabbay]

On Tue, Jul 28, 2015 at 7:00 PM, Dan Carpenter  
wrote:
> Hello Ben Goz,
>
> The patch 914bea6329b2: "drm/amdkfd: Add support for VI in DQM" from
> Jan 12, 2015, leads to the following static checker warning:
>
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c:158 
> init_sdma_vm()
> warn: should this be a bitwise op?
>
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c
>148  static void init_sdma_vm(struct device_queue_manager *dqm, struct 
> queue *q,
>149  struct qcm_process_device *qpd)
>150  {
>151  uint32_t value = (1 << SDMA0_RLC0_VIRTUAL_ADDR__ATC__SHIFT);
>152
>153  if (q->process->is_32bit_user_mode)
>154  value |= (1 << SDMA0_RLC0_VIRTUAL_ADDR__PTR32__SHIFT) 
> |
>155  get_sh_mem_bases_32(qpd_to_pdd(qpd));
>156  else
>157  value |= 
> ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
>158  
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&
>   
>^^
> Probably logical AND was intended.
>
>159  
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
>160
>161  q->properties.sdma_vm_addr = value;
>162  }
>
> Also:
>
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c:146
> init_sdma_vm() warn: should this be a bitwise op?
>
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_cik.c
>136  static void init_sdma_vm(struct device_queue_manager *dqm, struct 
> queue *q,
>137  struct qcm_process_device *qpd)
>138  {
>139  uint32_t value = (1 << SDMA0_RLC0_VIRTUAL_ADDR__ATC__SHIFT);
>140
>141  if (q->process->is_32bit_user_mode)
>142  value |= (1 << SDMA0_RLC0_VIRTUAL_ADDR__PTR32__SHIFT) 
> |
>143  get_sh_mem_bases_32(qpd_to_pdd(qpd));
>144  else
>145  value |= 
> ((get_sh_mem_bases_nybble_64(qpd_to_pdd(qpd))) <<
>146  
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE__SHIFT) &&
>   
>^
>147  
> SDMA0_RLC0_VIRTUAL_ADDR__SHARED_BASE_MASK;
>148
>149  q->properties.sdma_vm_addr = value;
>150  }
>
> regards,
> dan carpenter
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Thanks again for catching that.
Indeed, the AND operation should be bitwise AND, not logical AND.
I will send a patch shortly.

   Oded

drm/amdgpu: add amdgpu <--> amdkfd gfx7 interface

[Oded Gabbay]

On Tue, Jul 28, 2015 at 6:56 PM, Dan Carpenter 
wrote:

> Hello Oded Gabbay,
>
> The patch 32c22e994f44: "drm/amdgpu: add amdgpu <--> amdkfd gfx7
> interface" from Jun 12, 2015, leads to the following static checker
> warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c:453
> kgd_hqd_destroy()
> warn: bitwise AND condition is false here
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
>439  static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t
> reset_type,
>440  unsigned int timeout, uint32_t
> pipe_id,
>441  uint32_t queue_id)
>442  {
>443  struct amdgpu_device *adev = get_amdgpu_device(kgd);
>444  uint32_t temp;
>445
>446  acquire_queue(kgd, pipe_id, queue_id);
>447  WREG32(mmCP_HQD_PQ_DOORBELL_CONTROL, 0);
>448
>449  WREG32(mmCP_HQD_DEQUEUE_REQUEST, reset_type);
>450
>451  while (true) {
>452  temp = RREG32(mmCP_HQD_ACTIVE);
>453  if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
> ^^^
> Never true.  ANDing against a shift is weird.  A zero shift is sort of
> pointless, also.
>
>454  break;
>455  if (timeout == 0) {
>456  pr_err("kfd: cp queue preemption time out
> (%dms)\n",
>457  temp);
>458  release_queue(kgd);
>459  return -ETIME;
>460  }
>461  msleep(20);
>462  timeout -= 20;
>463  }
>464
>465  release_queue(kgd);
>466  return 0;
>467  }
>
> regards,
> dan carpenter
>

​Dan, thanks for catching that!
Will send a fix shortly.

​  Oded
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150729/a75626ab/attachment-0001.html>

[PATCH] drm: Fixup locking WARNINGs in drm_mode_config_reset

[Daniel Vetter]

On Wed, Jul 29, 2015 at 08:32:43AM +0200, Daniel Vetter wrote:
> With
> 
> commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> Author: Daniel Vetter 
> Date:   Thu Jul 9 23:44:28 2015 +0200
> 
> drm: Check locking in drm_for_each_connector
> 
> we started checking the locking in drm_for_each_connector but somehow
> I totally missed drm_mode_config_reset. There's no problem there since
> this function should only be called in single-threaded contexts
> (driver load or resume), so just wrap the loop with the right lock.
> 
> v2: Drink coffee and all that ...
> 
> Cc: Laurent Pinchart 
> Reported-by: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

Tested-by: Jianwei Wang 

> ---
>  drivers/gpu/drm/drm_crtc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index c91c18b2b1d4..10c1a0f6680c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5273,9 +5273,11 @@ void drm_mode_config_reset(struct drm_device *dev)
>   if (encoder->funcs->reset)
>   encoder->funcs->reset(encoder);
>  
> + mutex_lock(>mode_config.mutex);
>   drm_for_each_connector(connector, dev)
>   if (connector->funcs->reset)
>   connector->funcs->reset(connector);
> + mutex_unlock(>mode_config.mutex);
>  }
>  EXPORT_SYMBOL(drm_mode_config_reset);
>  
> -- 
> 2.1.4
> 

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

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Archit Taneja]

On 07/29/2015 12:19 AM, Daniel Vetter wrote:
> On Tue, Jul 28, 2015 at 08:46:24PM +0200, Daniel Vetter wrote:
>> On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
>>> Some drm drivers call remove_conflicting_framebuffers. Create a
>>> drm_fb_helper function that wraps around these calls.
>>>
>>> This is part of an effort to prevent drm drivers from calling fbdev
>>> functions directly, in order to make fbdev emulation a top level drm
>>> option.
>>>
>>> v2:
>>> - Added kerneldocs
>>> - Follow the drm way of aligning of arguments in func definitions
>>>
>>> Signed-off-by: Archit Taneja 
>>> ---
>>>   drivers/gpu/drm/drm_fb_helper.c | 15 +++
>>>   include/drm/drm_fb_helper.h |  4 
>>>   2 files changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 9620aa5..86e4e2c 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
>>> *fb_helper, int state)
>>>   }
>>>   EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>>>
>>> +/**
>>> + * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
>>> + * remove_conflicting_framebuffers
>>> + * @fb_helper: driver-allocated fbdev helper
>>> + *
>>> + * A wrapper around remove_conflicting_framebuffers implemented by fbdev 
>>> core
>>> + */
>>> +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
>>> *a,
>>> + const char *name,
>>> + bool primary)
>>> +{
>>> +   return remove_conflicting_framebuffers(a, name, primary);
>>> +}
>>> +EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);
>>
>> Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
>> there's a missing symbol problem here because i915 wants to kick out other
>> framebuffers (well we have to for correctness) even when fbdev emulation
>> is disabled. If you look at i915_dma.c you'll see that the call to
>> remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
>> CONFIG_I915_FBDEV.
>>
>> I think the proper solution here would be to provide a static inline
>> helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
>> all drivers who call this still want to call this even when fbdev
>> emulation is disabled.
>>
>> Plan B would be to move this into core drm and make the static inline one
>> selected for CONFIG_FB=n. If you do that then maybe also rename it to
>> drm_remove_conflicting_framebuffer since this really is only tangetial to
>> fbdev emulation.
>>
>> Anyway current patch unfortunately won't work since we really must remove
>> other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
>> from drm-misc for now. Unfortunately that means all the driver conversions
>> won't apply anymore either :(
>
> Ok I didn't have to drop all of the driver specific patches since all the
> arm ones don't have calls to remove_conflicting_framebuffers.

I can re-spin the x86 ones and make them stick to the original 
remove_conflicting_framebuffers call. This way we can at least use the
other helpers.

Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Archit Taneja]

On 07/29/2015 12:16 AM, Daniel Vetter wrote:
> On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
>> Some drm drivers call remove_conflicting_framebuffers. Create a
>> drm_fb_helper function that wraps around these calls.
>>
>> This is part of an effort to prevent drm drivers from calling fbdev
>> functions directly, in order to make fbdev emulation a top level drm
>> option.
>>
>> v2:
>> - Added kerneldocs
>> - Follow the drm way of aligning of arguments in func definitions
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/drm_fb_helper.c | 15 +++
>>   include/drm/drm_fb_helper.h |  4 
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 9620aa5..86e4e2c 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
>> *fb_helper, int state)
>>   }
>>   EXPORT_SYMBOL(drm_fb_helper_set_suspend);
>>
>> +/**
>> + * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
>> + *  remove_conflicting_framebuffers
>> + * @fb_helper: driver-allocated fbdev helper
>> + *
>> + * A wrapper around remove_conflicting_framebuffers implemented by fbdev 
>> core
>> + */
>> +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
>> *a,
>> +  const char *name,
>> +  bool primary)
>> +{
>> +return remove_conflicting_framebuffers(a, name, primary);
>> +}
>> +EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);
>
> Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
> there's a missing symbol problem here because i915 wants to kick out other
> framebuffers (well we have to for correctness) even when fbdev emulation
> is disabled. If you look at i915_dma.c you'll see that the call to
> remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
> CONFIG_I915_FBDEV.
>
> I think the proper solution here would be to provide a static inline
> helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
> all drivers who call this still want to call this even when fbdev
> emulation is disabled.
>
> Plan B would be to move this into core drm and make the static inline one
> selected for CONFIG_FB=n. If you do that then maybe also rename it to
> drm_remove_conflicting_framebuffer since this really is only tangetial to
> fbdev emulation.

The remove_conflicting_framebuffers calls do_unregister_framebuffer(),
which seems to be quite central to fb core, and can't just work without
other fb core funcs.

What I don't get is, if legacy fb was never enabled, how did we end up
registering fbs in the first place?

Could you briefly explain what these other 'framebuffers' are that
remove_conflicting_framebuffers removes? The comments say that they are
firmware allocated fbs. I'm not well versed with what happens in
desktop graphics.

Archit

>
> Anyway current patch unfortunately won't work since we really must remove
> other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
> from drm-misc for now. Unfortunately that means all the driver conversions
> won't apply anymore either :(
>
> Thanks, Daniel
>> +
>>   static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
>>   u16 blue, u16 regno, struct fb_info *info)
>>   {
>> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
>> index ef32500..cbdc69d 100644
>> --- a/include/drm/drm_fb_helper.h
>> +++ b/include/drm/drm_fb_helper.h
>> @@ -168,6 +168,10 @@ void drm_fb_helper_cfb_imageblit(struct fb_info *info,
>>
>>   void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int state);
>>
>> +int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
>> *a,
>> +  const char *name,
>> +  bool primary);
>> +
>>   int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
>>
>>   int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v13 0/6] drm/layerscape: Add Freescale DCU DRM driver

[Daniel Vetter]

On Wed, Jul 29, 2015 at 02:54:46PM +0800, Jianwei Wang wrote:
> Changed in v13
> -set regmap_config.cache_type to REGCACHE_RBTREE
> -add call drm_modeset_lock_all before drm_mode_config_reset

This was a bug in one of my recently merged patches, please don't call
drm_modeset_lock_all before config_reset. Instead please test "drm: Fixup
locking WARNINGs in drm_mode_config_reset" which should address this
problem too.

Thanks, Daniel

> -adjust patch order for creating pull request
> 
> Changed in v12
> 
> -Add one patch for MAINTAINER entry for drm/layerscape
> Adviced by Daniel Vetter
> -Add #include 
> 
> Changed in V11
> -set regmap_config.cache_type to REGCACHE_FLAT
> Advanced by Alexander Stein
> 
> Changed in V10
> -adjust commit log, remove meaningless statement
> -cleanup code for it's format and style.
> -remove platform related code out, including of tcon(vf610) and scfg(ls1021a)
> -remove useless sentences: encoder->crtc = crtc; and connector->encoder = 
> encoder; and so on
> -add vendor prefix for panel pandle
> -make a DCU_CTRLDESCLN(x, y)  to avoid high repetition
> -introduce per-SoC capability structure to avoid check on the OF node's 
> compatible string
> -Implement some functions: crtc enable and disable, enable and disable 
> VBLANK, plane atomic_disable and atomic_enable -atomic_check and so on
> -move DCU config sentence to the right place
> -move get resources functions to  ->probe()
> -move fsl,dcu.txt to video/ folder
> -add big-endian describe
> All advaced by Thierry Reding
> 
> Changed in V9
> 
> put node after calling of_drm_find_panel
> split clk_prepare_enable() to clk_prepare() and clk_enable(), just call 
> clk_prepare once, and check return value
> check regmap_write/regmap_read return return value
> remove useless ".owner= THIS_MODULE,"
> All advanced by Mark Yao
> 
> Changed in V8
> 
> - Remove useless code
> #define DRIVER_NAME "fsl-dcu-drm"
> MODULE_ALIAS("platform:fsl-dcu-drm");
> Adviced by Paul Bolle
> 
> Changed in V7
> 
> - Remove redundant functions and replace deprecated hook
> Adviced by Daniel Vetter
> - Replace drm_platform_init with drm_dev_alloc/register
> Adviced by Daniel Vetter
> 
> Changed in V6
> 
> - Add NEC nl4827hc19_05b panel to panel-simple.c
> Adviced by Mark Yao
> - Add DRIVER_ATOMIC for driver_features
> Adviced by Mark Yao
> - check fsl_dev if it's NULL at PM suspend/resume
> Adviced by Mark Yao
> 
> Changed in V5
> 
> - Update commit message
> - Add layer registers initialization
> - Remove unused functions
> - Rename driver folder
> Adviced by Stefan Agner
> - Move pixel clock control functions to fsl_dcu_drm_drv.c
> - remove redundant enable the clock implicitly using regmap
> - Add maintainer message
> 
> Changed in V4:
> 
> -This version doesn't have functionality changed
> Just a minor adjustment.
> 
> Changed in V3:
> 
> - Test driver on Vybrid board and add compatible string
> - Remove unused functions
> - set default crtc for encoder
> - replace legacy functions with atomic help functions
> Adviced by Daniel Vetter
> - Set the unique name of the DRM device
> - Implement irq handle function for vblank interrupt
> 
> Changed in v2:
> - Add atomic support
> Adviced by Daniel Vetter
> - Modify bindings file
> - Rename node for compatibility
> - Move platform related code out for compatibility
> Adviced by Stefan Agner
> 
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale SoCs.
> 
> 2D-ACE is a Freescale display controller. 2D-ACE describes
> the functionality of the module extremely well its name is a value
> that cannot be used as a token in programming languages.
> Instead the valid token "DCU" is used to tag the register names and
> function names.
> 
> The Display Controller Unit (DCU) module is a system master that
> fetches graphics stored in internal or external memory and displays
> them on a TFT LCD panel. A wide range of panel sizes is supported
> and the timing of the interface signals is highly configurable.
> Graphics are read directly from memory and then blended in real-time,
> which allows for dynamic content creation with minimal CPU
> intervention.
> 
> The features:
> (1) Full RGB888 output to TFT LCD panel.
> (2) Blending of each pixel using up to 4 source layers
> dependent
> on size of panel.
> (3) Each graphic layer can be placed with one pixel resolution
> in either axis.
> (4) Each graphic layer support RGB565 and RGB888 direct colors
> without alpha channel and BGRA BGRA ARGB1555 direct
> colors
> with an alpha channel and YUV422 format.
> (5) Each graphic layer support alpha blending with 8-bit
> resolution.
> 
> .../devicetree/bindings/video/fsl,dcu.txt  |  22 ++
> drivers/gpu/drm/Kconfig|   2 +
> drivers/gpu/drm/Makefile   |   1 +
> drivers/gpu/drm/fsl-dcu/Kconfig|  18 +
> drivers/gpu/drm/fsl-dcu/Makefile   |   7 +
> 

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Daniel Vetter]

On Wed, Jul 29, 2015 at 09:50:56AM +0530, Archit Taneja wrote:
> 
> 
> On 07/29/2015 12:19 AM, Daniel Vetter wrote:
> >On Tue, Jul 28, 2015 at 08:46:24PM +0200, Daniel Vetter wrote:
> >>On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> >>>Some drm drivers call remove_conflicting_framebuffers. Create a
> >>>drm_fb_helper function that wraps around these calls.
> >>>
> >>>This is part of an effort to prevent drm drivers from calling fbdev
> >>>functions directly, in order to make fbdev emulation a top level drm
> >>>option.
> >>>
> >>>v2:
> >>>- Added kerneldocs
> >>>- Follow the drm way of aligning of arguments in func definitions
> >>>
> >>>Signed-off-by: Archit Taneja 
> >>>---
> >>>  drivers/gpu/drm/drm_fb_helper.c | 15 +++
> >>>  include/drm/drm_fb_helper.h |  4 
> >>>  2 files changed, 19 insertions(+)
> >>>
> >>>diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >>>b/drivers/gpu/drm/drm_fb_helper.c
> >>>index 9620aa5..86e4e2c 100644
> >>>--- a/drivers/gpu/drm/drm_fb_helper.c
> >>>+++ b/drivers/gpu/drm/drm_fb_helper.c
> >>>@@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> >>>*fb_helper, int state)
> >>>  }
> >>>  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >>>
> >>>+/**
> >>>+ * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
> >>>+ *
> >>>remove_conflicting_framebuffers
> >>>+ * @fb_helper: driver-allocated fbdev helper
> >>>+ *
> >>>+ * A wrapper around remove_conflicting_framebuffers implemented by fbdev 
> >>>core
> >>>+ */
> >>>+int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
> >>>*a,
> >>>+const char *name,
> >>>+bool primary)
> >>>+{
> >>>+  return remove_conflicting_framebuffers(a, name, primary);
> >>>+}
> >>>+EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);
> >>
> >>Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
> >>there's a missing symbol problem here because i915 wants to kick out other
> >>framebuffers (well we have to for correctness) even when fbdev emulation
> >>is disabled. If you look at i915_dma.c you'll see that the call to
> >>remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
> >>CONFIG_I915_FBDEV.
> >>
> >>I think the proper solution here would be to provide a static inline
> >>helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
> >>all drivers who call this still want to call this even when fbdev
> >>emulation is disabled.
> >>
> >>Plan B would be to move this into core drm and make the static inline one
> >>selected for CONFIG_FB=n. If you do that then maybe also rename it to
> >>drm_remove_conflicting_framebuffer since this really is only tangetial to
> >>fbdev emulation.
> >>
> >>Anyway current patch unfortunately won't work since we really must remove
> >>other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
> >>from drm-misc for now. Unfortunately that means all the driver conversions
> >>won't apply anymore either :(
> >
> >Ok I didn't have to drop all of the driver specific patches since all the
> >arm ones don't have calls to remove_conflicting_framebuffers.
> 
> I can re-spin the x86 ones and make them stick to the original
> remove_conflicting_framebuffers call. This way we can at least use the
> other helpers.

Yeah that would work. btw for the kerneldoc I guess it would be easier if
you just provide a fixup patch, changed my mind there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH RESEND v2 06/25] drm/fb_helper: Create a wrapper for remove_conflicting_framebuffers

[Daniel Vetter]

On Wed, Jul 29, 2015 at 09:49:04AM +0530, Archit Taneja wrote:
> 
> 
> On 07/29/2015 12:16 AM, Daniel Vetter wrote:
> >On Wed, Jul 22, 2015 at 02:58:01PM +0530, Archit Taneja wrote:
> >>Some drm drivers call remove_conflicting_framebuffers. Create a
> >>drm_fb_helper function that wraps around these calls.
> >>
> >>This is part of an effort to prevent drm drivers from calling fbdev
> >>functions directly, in order to make fbdev emulation a top level drm
> >>option.
> >>
> >>v2:
> >>- Added kerneldocs
> >>- Follow the drm way of aligning of arguments in func definitions
> >>
> >>Signed-off-by: Archit Taneja 
> >>---
> >>  drivers/gpu/drm/drm_fb_helper.c | 15 +++
> >>  include/drm/drm_fb_helper.h |  4 
> >>  2 files changed, 19 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >>b/drivers/gpu/drm/drm_fb_helper.c
> >>index 9620aa5..86e4e2c 100644
> >>--- a/drivers/gpu/drm/drm_fb_helper.c
> >>+++ b/drivers/gpu/drm/drm_fb_helper.c
> >>@@ -894,6 +894,21 @@ void drm_fb_helper_set_suspend(struct drm_fb_helper 
> >>*fb_helper, int state)
> >>  }
> >>  EXPORT_SYMBOL(drm_fb_helper_set_suspend);
> >>
> >>+/**
> >>+ * drm_fb_helper_remove_conflicting_framebuffers - wrapper around
> >>+ * remove_conflicting_framebuffers
> >>+ * @fb_helper: driver-allocated fbdev helper
> >>+ *
> >>+ * A wrapper around remove_conflicting_framebuffers implemented by fbdev 
> >>core
> >>+ */
> >>+int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
> >>*a,
> >>+ const char *name,
> >>+ bool primary)
> >>+{
> >>+   return remove_conflicting_framebuffers(a, name, primary);
> >>+}
> >>+EXPORT_SYMBOL(drm_fb_helper_remove_conflicting_framebuffers);
> >
> >Chris Wilson reported on irc that if he builds with I915_FBDEV=n then
> >there's a missing symbol problem here because i915 wants to kick out other
> >framebuffers (well we have to for correctness) even when fbdev emulation
> >is disabled. If you look at i915_dma.c you'll see that the call to
> >remove_conflicting_framebuffers is conditional upon CONFIG_FB and not
> >CONFIG_I915_FBDEV.
> >
> >I think the proper solution here would be to provide a static inline
> >helper for remove_conflicting_framebuffer itself when CONFIG_FB=n, since a
> >all drivers who call this still want to call this even when fbdev
> >emulation is disabled.
> >
> >Plan B would be to move this into core drm and make the static inline one
> >selected for CONFIG_FB=n. If you do that then maybe also rename it to
> >drm_remove_conflicting_framebuffer since this really is only tangetial to
> >fbdev emulation.
> 
> The remove_conflicting_framebuffers calls do_unregister_framebuffer(),
> which seems to be quite central to fb core, and can't just work without
> other fb core funcs.
> 
> What I don't get is, if legacy fb was never enabled, how did we end up
> registering fbs in the first place?
> 
> Could you briefly explain what these other 'framebuffers' are that
> remove_conflicting_framebuffers removes? The comments say that they are
> firmware allocated fbs. I'm not well versed with what happens in
> desktop graphics.

Following config is the relevant one:

CONFIG_FB=y
CONFIG_DRM_I915_FBDEV=n

I.e. core fbdev is enabled and so we might load vesafb or efifb and
similar firmware fbdev drivers. But drm/i915 fbdev emulation isn't
enabled. Still we absolutely must kick off these firmware fbs in that
case.
-Daniel

> 
> Archit
> 
> >
> >Anyway current patch unfortunately won't work since we really must remove
> >other framebuffers even in the FB=y, I915_FBDEV=n case. So I dropped it
> >from drm-misc for now. Unfortunately that means all the driver conversions
> >won't apply anymore either :(
> >
> >Thanks, Daniel
> >>+
> >>  static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> >> u16 blue, u16 regno, struct fb_info *info)
> >>  {
> >>diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> >>index ef32500..cbdc69d 100644
> >>--- a/include/drm/drm_fb_helper.h
> >>+++ b/include/drm/drm_fb_helper.h
> >>@@ -168,6 +168,10 @@ void drm_fb_helper_cfb_imageblit(struct fb_info *info,
> >>
> >>  void drm_fb_helper_set_suspend(struct drm_fb_helper *fb_helper, int 
> >> state);
> >>
> >>+int drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct 
> >>*a,
> >>+ const char *name,
> >>+ bool primary);
> >>+
> >>  int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
> >>
> >>  int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
> >>--
> >>The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> >>hosted by The Linux Foundation
> >>
> >
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 

[PATCH] drm: Fixup locking WARNINGs in drm_mode_config_reset

[Daniel Vetter]

With

commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
Author: Daniel Vetter 
Date:   Thu Jul 9 23:44:28 2015 +0200

drm: Check locking in drm_for_each_connector

we started checking the locking in drm_for_each_connector but somehow
I totally missed drm_mode_config_reset. There's no problem there since
this function should only be called in single-threaded contexts
(driver load or resume), so just wrap the loop with the right lock.

Cc: Laurent Pinchart 
Reported-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c91c18b2b1d4..a8e5ca79aad1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5273,9 +5273,11 @@ void drm_mode_config_reset(struct drm_device *dev)
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);

+   mutex_lock(dev->mode_config.mutex);
drm_for_each_connector(connector, dev)
if (connector->funcs->reset)
connector->funcs->reset(connector);
+   mutex_unlock(dev->mode_config.mutex);
 }
 EXPORT_SYMBOL(drm_mode_config_reset);

-- 
2.1.4

[PATCH] libdrm/amdgpu: Fixed drm.h include.

[Alexandr Akulich]

On Wed, Jul 22, 2015 at 1:20 PM, Michel Dänzer  wrote:
> On 22.07.2015 16:33, Alexandr Akulich wrote:
>> On Wed, Jul 22, 2015 at 1:19 PM, Michel Dänzer  
>> wrote:
>>> On 17.07.2015 22:33, Alexandr Akulich wrote:
 As I see, this is not a kernel header, but a local (belongs to libdrm) one.
 (Otherwise, I would like you to point me on such file at, say,
 https://github.com/torvalds/linux/tree/master/include/drm)
>>>
>>> https://github.com/torvalds/linux/blob/master/include/uapi/drm/amdgpu_drm.h
>>>
>>>
 At files drm_sarea.h, mga_drm.h, qxl_drm.h, radeon_drm.h and via_drm.h we 
 have

 #include "drm.h"

 At the same time, at i915_drm.h and tegra_drm.h. we have

 #include 

 I'm pretty sure that the first case is correct, because drm.h is
 always would be local file (in the same directory), related to
 amdgpu_drm.h, and that is why local include "drm.h" would be always
 valid.
>>>
>>> Makes sense to me, the patch is
>>>
>>> Reviewed-by: Michel Dänzer 
>> Thanks! I have no write access to this fd.o repository. Can you apply it 
>> please?
>
> I assume your patch is against the amdgpu branch of
> http://cgit.freedesktop.org/~agd5f/drm/, right? Only Alex Deucher has
> write access to that.

Well, what I can do?
Alex, can you apply the patch, please?

[Bug 90378] [LLVM][bisected] GPU lockups in Left 4 Dead 2

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

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

--- Comment #9 from Daniel Scharrer  ---
Hi Marek,

Looks like http://lists.freedesktop.org/archives/mesa-dev/2015-July/089950.html
does help. With latest LLVM + Mesa + that patch series, glitches and lockups
seem to be gone. I got one lockup when replaying L4D2-radeonsi.trace after
rebuilding mesa, but could not reproduce it after reboot or in game (tested in
L4D2, CS:GO and The Talos Principle).

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

[PATCH 1/2] drm/amdgpu: fix bug when amdkfd destroys hqd

[Ilia Mirkin]

On Wed, Jul 29, 2015 at 3:44 AM, Oded Gabbay  wrote:
> The wrong define was used to check if the hqd is still active
>
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> index 2daad33..6a45330 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
> @@ -450,7 +450,8 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, uint32_t 
> reset_type,
>
> while (true) {
> temp = RREG32(mmCP_HQD_ACTIVE);
> -   if (temp & CP_HQD_ACTIVE__ACTIVE__SHIFT)
> +   if (temp & (CP_HQD_ACTIVE__ACTIVE_MASK <<
> +   CP_HQD_ACTIVE__ACTIVE__SHIFT))

It's a bit moot here since the shift is 0, but I thought the mask
normally included the shift already...

#define CP_MQD_BASE_ADDR__BASE_ADDR_MASK 0xfffc
#define CP_MQD_BASE_ADDR__BASE_ADDR__SHIFT 0x2

#define CP_HPD_EOP_CONTROL__PEND_SIG_SEM_MASK 0x8000
#define CP_HPD_EOP_CONTROL__PEND_SIG_SEM__SHIFT 0x1f

etc.

> break;
> if (timeout == 0) {
> pr_err("kfd: cp queue preemption time out (%dms)\n",
> --
> 2.4.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/22] On-demand device probing

[Rafael J. Wysocki]

On Tuesday, July 28, 2015 03:19:31 PM Tomeu Vizoso wrote:
> Hello,
> 
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a better way of solving this than moving nodes around in the
> DT or playing with initcall levels and linking order.
> 
> While reading the thread [1] that Alexander Holler started with his
> series to make probing order deterministic, it occurred to me that it
> should be possible to achieve the same by probing devices as they are
> referenced by other devices.
> 
> This basically reuses the information that is already implicit in the
> probe() implementations, saving us from refactoring existing drivers or
> adding information to DTBs.
> 
> During review of v1 of this series Linus Walleij suggested that it
> should be the device driver core to make sure that dependencies are
> ready before probing a device. I gave this idea a try [2] but Mark Brown
> pointed out to the logic duplication between the resource acquisition
> and dependency discovery code paths (though I think it's fairly minor).
> 
> To address that code duplication I experimented with Arnd's devm_probe
> [3] concept of having drivers declare their dependencies instead of
> acquiring them during probe, and while it worked [4], I don't think we
> end up winning anything when compared to just probing devices on-demand
> from resource getters.
> 
> One remaining objection is to the "sprinkling" of calls to
> fwnode_ensure_device() in the resource getters of each subsystem, but I
> think it's the right thing to do given that the storage of resources is
> currently subsystem-specific.
> 
> We could avoid the above by moving resource storage into the core, but I
> don't think there's a compelling case for that.
> 
> I have tested this on boards with Tegra, iMX.6, Exynos and OMAP SoCs,
> and these patches were enough to eliminate all the deferred probes
> (except one in PandaBoard because omap_dma_system doesn't have a
> firmware node as of yet).
> 
> With this series I get the kernel to output to the panel in 0.5s,
> instead of 2.8s.

Can you trim your CC list somewhat, please?

I'm definitely going to look at this, but not before then next week.
Sorry about that.

Thanks,
Rafael

[PATCH 05/14] drm: Check locking in drm_for_each_connector

[Laurent Pinchart]

Hi Daniel,

On Thursday 09 July 2015 23:44:28 Daniel Vetter wrote:
> Because of DP MST connectors can now be hotplugged and we must hold
> the right lock when walking the connector lists.  Enforce this by
> checking the locking in our shiny new list walking macros.
> 
> v2: Extract the locking check into a small static inline helper to
> help readability. This will be more important when we make the
> read list access rules more complicated in later patches. Inspired by
> comments from Chris. Unfortunately, due to header loops around the
> definition of struct drm_device the function interface is a bit funny.
> 
> v3: Encoders aren't hotadded/removed. For each dp mst encoder we
> statically create one fake encoder per pipe so that we can support as
> many mst sinks as the hw can (Dave).
> 
> Cc: Chris Wilson 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_crtc.h | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 7c95a7df6065..499562274353 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1589,8 +1589,18 @@ static inline struct drm_property
> *drm_property_find(struct drm_device *dev, #define drm_for_each_crtc(crtc,
> dev) \
>   list_for_each_entry(crtc, &(dev)->mode_config.crtc_list, head)
> 
> +static inline void
> +assert_drm_connector_list_read_locked(struct drm_mode_config *mode_config)
> +{
> + WARN_ON(!mutex_is_locked(_config->mutex));

I believe this introduced a regression for all drivers that call 
drm_mode_config_reset() at .load() time (and there's lots of them), as the 
mode config mutex isn't locked then.

> +}
> +
>  #define drm_for_each_connector(connector, dev) \
> - list_for_each_entry(connector, &(dev)->mode_config.connector_list, head)
> + for (assert_drm_connector_list_read_locked(&(dev)->mode_config),
> \
> +  connector = list_first_entry(&(dev)->mode_config.connector_list,   
\
> +   struct drm_connector, head);  
> \
> +  >head != (&(dev)->mode_config.connector_list);  
> \
> +  connector = list_next_entry(connector, head))
> 
>  #define drm_for_each_encoder(encoder, dev) \
>   list_for_each_entry(encoder, &(dev)->mode_config.encoder_list, head)

-- 
Regards,

Laurent Pinchart

[Bug 91136] [tahiti xt] portal2/dota2 glitchy without R600_DEBUG=switch_on_eop

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

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

--- Comment #4 from Sylvain BERTRAND  ---
In dota2 source 1, if, additionally, I do enable vsync, it seems that 100% of
the glitches are gone.

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