Re: [PATCH 1/4] drm: add RGB formats with separate alpha plane
On Mon, 2017-02-27 at 17:23 +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 12:52:46PM +0100, Philipp Zabel wrote:
> > Some hardware can read the alpha components separately and then
> > conditionally fetch color components only for non-zero alpha values.
> > This patch adds fourcc definitions for two-plane RGB formats with an
> > 8-bit alpha channel on a second plane.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 4
> > include/uapi/drm/drm_fourcc.h | 14 ++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 90d2cc8da8eb6..e630a4dbf0b14 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -144,6 +144,10 @@ const struct drm_format_info *__drm_format_info(u32
> > format)
> > { .format = DRM_FORMAT_ABGR,.depth = 32,
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_RGBA,.depth = 32,
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_BGRA,.depth = 32,
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_XBGR_A8, .depth = 32,
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_RGBX_A8, .depth = 32,
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_BGRX_A8, .depth = 32,
> > .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
> > { .format = DRM_FORMAT_YUV410, .depth = 0,
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
> > { .format = DRM_FORMAT_YVU410, .depth = 0,
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
> > { .format = DRM_FORMAT_YUV411, .depth = 0,
> > .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index ef20abb8119bf..37cf9c871cebc 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -114,6 +114,20 @@ extern "C" {
> > #define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
> > [31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
> >
> > /*
> > + * 2 plane RGB + A
> > + * index 0 = RGB plane
>
> Maybe clarify the comment here with "RGB plane, same layout as the non _A8
> RGB format has". Better to over-spec this stuff :-)
> -Daniel
Thanks, I'll add this to the comment and resend.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/atmel-hlcdc: Simplify the HLCDC layer logic
Hi Eric,
On Mon, 27 Feb 2017 14:30:13 -0800
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > An HLCDC layers in Atmel's nomenclature is either a DRM plane or a 'Post
> > Processing Layer' which can be used to output the results of the HLCDC
> > composition in a memory buffer.
> >
> > atmel_hlcdc_layer.c was designed to be generic enough to be re-usable in
> > both cases, but we're not exposing the post-processing layer yet, and
> > even if we were, I'm not sure the code would provide the necessary tools
> > to manipulate this kind of layer.
> >
> > Moreover, the code in atmel_hlcdc_{plane,layer}.c was designed before the
> > atomic modesetting API, and was trying solve the
> > check-setting/commit-if-ok/rollback-otherwise problem, which is now
> > entirely solved by the existing core infrastructure.
> >
> > And finally, the code in atmel_hlcdc_layer.c in over-complicated compared
> > to what we really need. This rework is a good excuse to simplify it. Note
> > that this rework solves an existing resource leak (leading to a -EBUSY
> > error) which I failed to clearly identify.
> >
> > Signed-off-by: Boris Brezillon
>
> Deleting 20% of your driver? Awesome.
>
> This was tricky to review, though. I wonder if the configuration layout
> description restructuring (and some of the config update helpers) could
> have been done separately from the rollback removal parts. The merge of
> atmel_hlcdc_layer.h into atmel_hlcdc_dc.h was also something that I only
> reviewed pieces of by occasionally looking into a specific definition to
> see if it had happened to change in the move.
Yes, I'm not happy with the diff either (it's really hard to review),
I'll try do these changes in several steps (as you suggest) and see if
it helps.
>
> I've gone through all the code, particularly with an eye to things like
> copy/paste bugs, so I think with a couple of little comments below
> addressed,
>
> Reviewed-by: Eric Anholt
Thanks a lot for your review.
>
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 246ed1e33d8a..cb6b2d5ae50b 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>
> > static void
> > atmel_hlcdc_plane_update_general_settings(struct atmel_hlcdc_plane *plane,
> > struct atmel_hlcdc_plane_state *state)
> > {
> > - const struct atmel_hlcdc_layer_cfg_layout *layout =
> > - &plane->layer.desc->layout;
> > - unsigned int cfg = ATMEL_HLCDC_LAYER_DMA;
> > + unsigned int cfg = ATMEL_HLCDC_LAYER_DMA_BLEN_INCR16 | state->ahb_id;
> > + const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
> > +
> > + /*
> > +* Rotation optimization is not working on RGB888 (rotation is still
> > +* working but without any optimization).
> > +*/
> > + if (state->base.fb->pixel_format == DRM_FORMAT_RGB888)
> > + cfg |= ATMEL_HLCDC_LAYER_DMA_ROTDIS;
> > +
> > + atmel_hlcdc_layer_write_cfg(&plane->layer, ATMEL_HLCDC_LAYER_DMA_CFG,
> > + cfg);
> > +
> > + cfg = ATMEL_HLCDC_LAYER_DMA;
> >
> > if (plane->base.type != DRM_PLANE_TYPE_PRIMARY) {
> > + u32 format = state->base.fb->pixel_format;
> > +
> > cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
> >ATMEL_HLCDC_LAYER_ITER;
> >
> > - if
> > (atmel_hlcdc_format_embeds_alpha(state->base.fb->pixel_format))
> > + if (atmel_hlcdc_format_embeds_alpha(format))
> > cfg |= ATMEL_HLCDC_LAYER_LAEN;
> > else
> > cfg |= ATMEL_HLCDC_LAYER_GAEN |
> >ATMEL_HLCDC_LAYER_GA(state->alpha);
> > }
>
> The format temp here seems gratuitous (unless you wanted to move it up
> to the declarations at the top of the function and use it for ROTDIS).
Actually, I did that to avoid the "over 80 char" checkpatch warning,
but you're right, I should declare this variable at the top of the
function and use it for ROTDIS.
>
> >
> > - atmel_hlcdc_layer_update_cfg(&plane->layer,
> > -ATMEL_HLCDC_LAYER_DMA_CFG_ID,
> > -ATMEL_HLCDC_LAYER_DMA_BLEN_MASK |
> > -ATMEL_HLCDC_LAYER_DMA_SIF,
> > -ATMEL_HLCDC_LAYER_DMA_BLEN_INCR16 |
> > -state->ahb_id);
> > -
> > - atmel_hlcdc_layer_update_cfg(&plane->layer, layout->general_config,
> > -ATMEL_HLCDC_LAYER_ITER2BL |
> > -ATMEL_HLCDC_LAYER_ITER |
> > -ATMEL_HLCDC_LAYER_GAEN |
> > -ATMEL_HLCDC_LAYER_GA_MASK |
> > -ATMEL_HLCDC_LAYER_LAEN |
> > -ATMEL_
Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper_funcs
On 2017年02月15日 04:32, Daniel Stone
wrote:
Hi John,
On 14 February 2017 at 19:25, John Stultz wrote:
+static enum drm_mode_status
+drm_connector_check_crtc_modes(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ struct drm_device *dev = connector->dev;
+ const struct drm_crtc_helper_funcs *crtc_funcs;
+ struct drm_crtc *c;
+
+ if (mode->status != MODE_OK)
+ return mode->status;
+
+ /* Check all the crtcs on a connector to make sure the mode is valid */
+ drm_for_each_crtc(c, dev) {
+ crtc_funcs = c->helper_private;
+ if (crtc_funcs && crtc_funcs->mode_valid)
+ mode->status = crtc_funcs->mode_valid(c, mode);
+ if (mode->status != MODE_OK)
+ break;
+ }
+ return mode->status;
+}
Hm, that's unfortunate: it limits the mode list for every connector,
to those which are supported by every single CRTC. So if you have one
CRTC serving low-res LVDS, and another serving higher-res HDMI,
suddenly you can't get bigger modes on HDMI. The idea seems sound
enough, but a little more nuance might be good ...
John, I have same requirement, also want to valid mode with crtc,
here is my patch[0], use encoder->possible_crtcs to limit the
crtc valid, may be can solved the low-res and high-res problem.
[0]: https://patchwork.kernel.org/patch/9555945
/*
* ensure all drm display mode can work, if someone want support
more
* resolutions, please limit the possible_crtc, only connect to
* needed crtc.
*/
drm_for_each_crtc(crtc, connector->dev) {
[...]
if (!(encoder->possible_crtcs & drm_crtc_mask(crtc)))
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ｍark Yao
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph
Hi All, [Resend this v2 patches, because i have missing TO and CC.] The dsi + panel is a parental relationship, so OF grpah is not needed. Therefore, the current dsi_parse_dt function will throw an error, because there is no linked OF graph for case such as fimd + dsi + panel. So the 1/5 patch parse the Pll, burst and esc clock frequency properties in dsi_parse_dt and modified to create a bridge_node only if there is an OF graph associated with dsi. Also fixed the dts, which depend on the 1/5 patch. So removed the ports node and move burst and esc clock frequency properties to the parent (DSI node). Changes for V2: - Added the clear explanation for commit. (1/5 patch) - Fixed it to the same subject as the actual work. (2/5 ~ 5/5 patches) Best Regards, Hoegeun Hoegeun Kwon (5): drm/exynos: dsi: Fix the parse_dt function arm64: dts: exynos: Remove the OF graph from DSI node for exynos5433 dts arm: dts: Remove the OF graph from DSI node for exynos3250 dts arm: dts: Remove the OF graph from DSI node for exynos4412 dts arm: dts: Remove the OF graph from DSI node for exynos4210 dts arch/arm/boot/dts/exynos3250-rinato.dts| 23 ++-- arch/arm/boot/dts/exynos4210-trats.dts | 23 ++-- arch/arm/boot/dts/exynos4412-trats2.dts| 23 ++-- .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++- drivers/gpu/drm/exynos/exynos_drm_dsi.c| 32 ++ 5 files changed, 16 insertions(+), 101 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 3/5] arm: dts: Remove the OF graph from DSI node for exynos3250 dts
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos3250-rinato.dts | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 548413e..82e676a 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -215,24 +215,11 @@
&dsi_0 {
vddcore-supply = <&ldo6_reg>;
vddio-supply = <&ldo6_reg>;
+ samsung,burst-clock-frequency = <25000>;
+ samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dsi_out: endpoint {
- remote-endpoint = <&dsi_in>;
- samsung,burst-clock-frequency = <25000>;
- samsung,esc-clock-frequency = <2000>;
- };
- };
- };
-
panel@0 {
compatible = "samsung,s6e63j0x03";
reg = <0>;
@@ -262,12 +249,6 @@
vsync-len = <2>;
};
};
-
- port {
- dsi_in: endpoint {
- remote-endpoint = <&dsi_out>;
- };
- };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 4/5] arm: dts: Remove the OF graph from DSI node for exynos4412 dts
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4412-trats2.dts | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 41ecd6d..86ce5e5 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -385,24 +385,11 @@
&dsi_0 {
vddcore-supply = <&ldo8_reg>;
vddio-supply = <&ldo10_reg>;
+ samsung,burst-clock-frequency = <5>;
+ samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dsi_out: endpoint {
- remote-endpoint = <&dsi_in>;
- samsung,burst-clock-frequency = <5>;
- samsung,esc-clock-frequency = <2000>;
- };
- };
- };
-
panel@0 {
compatible = "samsung,s6e8aa0";
reg = <0>;
@@ -430,12 +417,6 @@
vsync-len = <2>;
};
};
-
- port {
- dsi_in: endpoint {
- remote-endpoint = <&dsi_out>;
- };
- };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 5/5] arm: dts: Remove the OF graph from DSI node for exynos4210 dts
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm/boot/dts/exynos4210-trats.dts | 23 ++-
1 file changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index 0ca1b4d..9452bed 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -197,24 +197,11 @@
&dsi_0 {
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
+ samsung,burst-clock-frequency = <5>;
+ samsung,esc-clock-frequency = <2000>;
samsung,pll-clock-frequency = <2400>;
status = "okay";
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dsi_out: endpoint {
- remote-endpoint = <&dsi_in>;
- samsung,burst-clock-frequency = <5>;
- samsung,esc-clock-frequency = <2000>;
- };
- };
- };
-
panel@0 {
reg = <0>;
compatible = "samsung,s6e8aa0";
@@ -242,12 +229,6 @@
vsync-len = <2>;
};
};
-
- port {
- dsi_in: endpoint {
- remote-endpoint = <&dsi_out>;
- };
- };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 1/5] drm/exynos: dsi: Fix the parse_dt function
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel. So this patch parse the Pll, burst and esc clock frequency
properties in dsi_parse_dt and modified to create a bridge_node only
if there is an OF graph associated with dsi.
So I think the ABI breakage is needed.
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 32
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index f5c04d0..2d4e118 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1652,39 +1652,23 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
if (ret < 0)
return ret;
- ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
- if (!ep) {
- dev_err(dev, "no output port with endpoint specified\n");
- return -EINVAL;
- }
-
- ret = exynos_dsi_of_read_u32(ep, "samsung,burst-clock-frequency",
+ ret = exynos_dsi_of_read_u32(node, "samsung,burst-clock-frequency",
&dsi->burst_clk_rate);
if (ret < 0)
- goto end;
+ return ret;
- ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
+ ret = exynos_dsi_of_read_u32(node, "samsung,esc-clock-frequency",
&dsi->esc_clk_rate);
if (ret < 0)
- goto end;
-
- of_node_put(ep);
+ return ret;
ep = of_graph_get_next_endpoint(node, NULL);
- if (!ep) {
- ret = -EINVAL;
- goto end;
- }
-
- dsi->bridge_node = of_graph_get_remote_port_parent(ep);
- if (!dsi->bridge_node) {
- ret = -EINVAL;
- goto end;
+ if (ep) {
+ dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
}
-end:
- of_node_put(ep);
- return ret;
+ return 0;
}
static int exynos_dsi_bind(struct device *dev, struct device *master,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] New: drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731
Bug ID: 194731
Summary: drm general protection fault in drm_atomic_init
Product: Drivers
Version: 2.5
Kernel Version: 4.10.0
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: Video(DRI - non Intel)
Assignee: drivers_video-...@kernel-bugs.osdl.org
Reporter: janpieter.sol...@dommel.be
Regression: No
I modified the drm_atomic.c a bit to be more verbose. the drm_init calls a
general protection fault when allocating my second GPU(does it work this way?)
of the amdgpu module.
afterwards, the system is unable to allocate more kernel memory. init does not
even manage to reboot, I can not do sudo without segfault
dmesg:
[ 77.946291] [drm] Cannot find any crtc or sizes - going 1024x768
[ 77.946575] [drm] fb mappable at 0xC0CCB000
[ 77.946576] [drm] vram apper at 0xC000
[ 77.946577] [drm] size 786432
[ 77.946578] [drm] fb depth is 24
[ 77.946578] [drm]pitch is 1024
[ 77.950389] kcalloc called
[ 77.950390] kcalloc2 called
[ 77.950433] kcalloc called
[ 77.950444] general protection fault: [#1] SMP
[ 77.950445] Modules linked in: amdkfd amdgpu(O+) amdttm(O) amdkcl(O)
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 nf_nat
l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox
ppp_generic slhc deflate cmac af_key w83627ehf hwmon_vid k10temp fam15h_power
i2c_piix4 pcspkr
[ 77.950462] CPU: 16 PID: 5094 Comm: kworker/16:2 Tainted: G O
4.10.0-rc8 #12
[ 77.950463] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 2.0a
01/09/2012
[ 77.950470] Workqueue: events work_for_cpu_fn
[ 77.950471] task: 88183c027000 task.stack: c90020cfc000
[ 77.950476] RIP: 0010:__kmalloc+0x6f/0x100
[ 77.950477] RSP: 0018:c90020cff6b0 EFLAGS: 00010286
[ 77.950478] RAX: RBX: 8818362628ff RCX:
0897
[ 77.950479] RDX: 0896 RSI: RDI:
00019b70
[ 77.950479] RBP: c90020cff6d0 R08: 88183fc19b70 R09:
81417df1
[ 77.950480] R10: 0300 R11: R12:
ff88183626296000
[ 77.950481] R13: 88083f803a00 R14: 014080c0 R15:
88183602b238
[ 77.950483] FS: () GS:88183fc0()
knlGS:
[ 77.950484] CS: 0010 DS: ES: CR0: 80050033
[ 77.950485] CR2: 5590d5ce93d8 CR3: 01c11000 CR4:
000406e0
[ 77.950485] Call Trace:
[ 77.950492] drm_atomic_state_init+0x81/0xf0
[ 77.950494] drm_atomic_state_alloc+0x53/0x80
[ 77.950497] drm_fb_helper_pan_display+0xf4/0x2a0
[ 77.950501] fb_pan_display+0xd6/0x170
[ 77.950502] bit_update_start+0x24/0x60
[ 77.950504] fbcon_switch+0x3e2/0x670
[ 77.950507] redraw_screen+0x15d/0x220
[ 77.950510] ? tty_do_resize+0x4d/0xa0
[ 77.950512] vc_do_resize+0x4c3/0x4f0
[ 77.950513] vc_resize+0x1a/0x20
[ 77.950515] fbcon_init+0x40b/0x660
[ 77.950516] visual_init+0xce/0x130
[ 77.950517] do_bind_con_driver+0x1c1/0x3a0
[ 77.950519] do_take_over_console+0x113/0x180
[ 77.950520] do_fbcon_takeover+0x51/0xb0
[ 77.950522] fbcon_event_notify+0x75a/0x880
[ 77.950525] notifier_call_chain+0x44/0x70
[ 77.950526] __blocking_notifier_call_chain+0x4e/0x80
[ 77.950528] blocking_notifier_call_chain+0x11/0x20
[ 77.950529] fb_notifier_call_chain+0x16/0x20
[ 77.950531] register_framebuffer+0x200/0x340
[ 77.950533] drm_fb_helper_initial_config+0x201/0x390
piece of code that prints the "kcalloc(2) called":
drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
{
kref_init(&(state->ref));
/* TODO legacy paths should maybe do a better job about
* setting this appropriately?
*/
state->allow_modeset = true;
state->crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(struct
__drm_crtcs_state), GFP_KERNEL);
printk("kcalloc called \n");
if (!(state->crtcs))
goto fail;
state->planes = kcalloc(dev->mode_config.num_total_plane,
sizeof(struct __drm_planes_state), GFP_KERNEL);
printk("kcalloc2 called \n");
if (!(state->planes))
goto fail;
state->dev = dev;
DRM_DEBUG_ATOMIC("Allocated atomic state %p\n", state);
return 0;
fail:
printk("fail called \n");
drm_atomic_state_default_release(state);
return -ENOMEM;
}
EXPORT_SYMBOL(drm_atomic_state_init);
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/6] drm: Add SCDC helpers
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Addressed review comments from Ville
- Handle the I2c return values in a better way (dp_dual_mode)
- Make the macros for SCDC Major/Minor more readable, by adding
a 'GET' in the macro names
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
---
Documentation/gpu/drm-kms-helpers.rst | 12
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_scdc_helper.c | 123 +++
include/drm/drm_scdc_helper.h | 132 ++
4 files changed, 269 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
create mode 100644 include/drm/drm_scdc_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 03040aa..7592756 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -217,6 +217,18 @@ EDID Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_edid.c
:export:
+SCDC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+ :doc: scdc helpers
+
+.. kernel-doc:: include/drm/drm_scdc_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
+ :export:
+
Rectangle Utilities Reference
=
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 3ee9579..da5b08c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
- drm_simple_kms_helper.o drm_modeset_helper.o
+ drm_simple_kms_helper.o drm_modeset_helper.o \
+ drm_scdc_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
new file mode 100644
index 000..c2dd33f
--- /dev/null
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+
+#include
+
+/**
+ * DOC: scdc helpers
+ *
+ * Status and Control Data Channel (SCDC) is a mechanism introduced by the
+ * HDMI 2.0 specification. It is a point-to-point protocol that allows the
+ * HDMI source and HDMI sink to exchange data. The same I2C interface that
+ * is used to access EDID serves as the transport mechanism for SCDC.
+ */
+
+#define SCDC_I2C_SLAVE_ADDRESS 0x54
+
+/**
+ * drm_scdc_read - read a block of data from SCDC
+ * @adapter: I2C controller
+ * @offset: start offset of block to read
+ * @buffer: return location for the block to read
+ * @size: size of the block to read
+ *
+ * Reads a block of data from SCDC, starting at a given offset.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
+ size_t size)
+{
+ int ret;
+ struct i2c_msg msgs[2] = {
+ {
+ .addr = SCDC_I2C_SLAVE_ADDRESS,
+ .flags = 0,
+ .len = 1,
+ .buf = &offset,
+ }, {
+ .a
[PATCH v5 0/6] HDMI 2.0: Scrambling in DRM layer
HDMI 2.0 spec defines a method to reduce the RF footprint while operating at higher pixel clocks, which is called Scrambling. Scrambling can be controlled over a new set of I2C registers which are accessible over existing DDC I2C lines, called SCDC register set. This patch series contains 6 patches: - First two patches add generic drm helper functions to read and write into SCDC registers. These patches are written by Thierry, in a patch series published here: https://patchwork.kernel.org/patch/9459051/ Minor changes were done to map the patches into this series. - Next two patches add functions for scrambling detection and scrambling control. - Next two patches use this infrastructure in DRM layer from I915 driver, to enable scrambling on a GLK deivce which sports a native HDMI 2.0 controller. V2: - addressed review comments from Thierry, Ville and Dhinakaran - added signed-off-by:self in first two patches(Jani N) V3: - addressed review comments from Jose and Jani V4: - addressed review comments from Maarten on patch 5, rebase all other patches V5: - addressed review comments from Ville/Ander on patch 1, 4, 5 rebase all other patches Shashank Sharma (4): drm/edid: detect SCDC support in HF-VSDB drm/edid: detect SCDC support in HF-VSDB drm/i915: enable scrambling drm/i915: allow HDMI 2.0 clock rates Thierry Reding (2): drm: Add SCDC helpers drm/edid: check for HF-VSDB block Documentation/gpu/drm-kms-helpers.rst | 12 ++ drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_edid.c| 60 + drivers/gpu/drm/drm_scdc_helper.c | 234 ++ drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_ddi.c | 29 + drivers/gpu/drm/i915/intel_drv.h | 14 ++ drivers/gpu/drm/i915/intel_hdmi.c | 100 +++ include/drm/drm_connector.h | 52 include/drm/drm_edid.h| 6 +- include/drm/drm_scdc_helper.h | 159 +++ include/linux/hdmi.h | 1 + 12 files changed, 672 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_scdc_helper.c create mode 100644 include/drm/drm_scdc_helper.h -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/6] drm/edid: check for HF-VSDB block
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
Signed-off-by: Thierry Reding
Signed-off-by: Shashank Sharma
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/drm_edid.c | 15 +++
include/linux/hdmi.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e1743ab..055b511 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3248,6 +3248,21 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
return hdmi_id == HDMI_IEEE_OUI;
}
+static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
+{
+ unsigned int oui;
+
+ if (cea_db_tag(db) != VENDOR_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 7)
+ return false;
+
+ oui = db[3] << 16 | db[2] << 8 | db[1];
+
+ return oui == HDMI_FORUM_IEEE_OUI;
+}
+
#define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) +
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)])
+ 1)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index edbb4fc..d271ff2 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -35,6 +35,7 @@ enum hdmi_infoframe_type {
};
#define HDMI_IEEE_OUI 0x000c03
+#define HDMI_FORUM_IEEE_OUI 0xc45dd8
#define HDMI_INFOFRAME_HEADER_SIZE 4
#define HDMI_AVI_INFOFRAME_SIZE13
#define HDMI_SPD_INFOFRAME_SIZE25
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/6] drm/edid: detect SCDC support in HF-VSDB
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.
V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.
Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.
V3: Rebase.
V4: Rebase.
V5: Rebase.
Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/drm_edid.c| 33 +++-
drivers/gpu/drm/drm_scdc_helper.c | 111 ++
include/drm/drm_connector.h | 19 +++
include/drm/drm_edid.h| 6 ++-
include/drm/drm_scdc_helper.h | 27 ++
5 files changed, 194 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0881108..e84c5ab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -3817,13 +3818,43 @@ enum hdmi_quantization_range
static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
const u8 *hf_vsdb)
{
- struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+ struct drm_display_info *display = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &display->hdmi;
if (hf_vsdb[6] & 0x80) {
hdmi->scdc.supported = true;
if (hf_vsdb[6] & 0x40)
hdmi->scdc.read_request = true;
}
+
+ /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340 MHz.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB (let's check)
+* * SCDC support available (let's check)
+* Lets check it out.
+*/
+
+ if (hf_vsdb[5]) {
+ /* max clock is 5000 KHz times block value */
+ u32 max_tmds_clock = hf_vsdb[5] * 5000;
+ struct drm_scdc *scdc = &hdmi->scdc;
+
+ if (max_tmds_clock > 34) {
+ display->max_tmds_clock = max_tmds_clock;
+ DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+ display->max_tmds_clock);
+ }
+
+ if (scdc->supported) {
+ scdc->scrambling.supported = true;
+
+ /* Few sinks support scrambling for cloks < 340M */
+ if ((hf_vsdb[6] & 0x8))
+ scdc->scrambling.low_rates = true;
+ }
+ }
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/drm_scdc_helper.c
b/drivers/gpu/drm/drm_scdc_helper.c
index c2dd33f..180a7cd 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -22,8 +22,10 @@
*/
#include
+#include
#include
+#include
/**
* DOC: scdc helpers
@@ -121,3 +123,112 @@ ssize_t drm_scdc_write(struct i2c_adapter *adapter, u8
offset,
return 0;
}
EXPORT_SYMBOL(drm_scdc_write);
+
+/**
+ * drm_scdc_check_scrambling_status - what is status of scrambling?
+ * @adapter: I2C adapter for DDC channel
+ *
+ * Reads the scrambler status over SCDC, and checks the
+ * scrambling status.
+ *
+ * Returns:
+ * True if the scrambling is enabled, false otherwise.
+ */
+
+bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter)
+{
+ u8 status;
+ int ret;
+
+ ret = drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status);
+ if (ret < 0) {
+ DRM_ERROR("Failed to read scrambling status, error %d\n", ret);
+ return false;
+ }
+
+ return status & SCDC_SCRAMBLING_STATUS;
+}
+EXPORT_SYMBOL(drm_scdc_get_scrambling_status);
+
+/**
+ * drm_scdc_set_scrambling - enable scrambling
+ * @adapter: I2C adapter for DDC channel
+ * @enable: bool to indicate if scrambling is to be enabled/disabled
+ *
+ * Writes the TMDS config register over SCDC c
[PATCH v5 3/6] drm/edid: detect SCDC support in HF-VSDB
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDMI 2.0 sink.
- Checks the HF-VSDB block for presence of SCDC, and marks it
in scdc structure
- If SCDC is present, checks if sink is capable of generating
SCDC read request, and marks it in scdc structure.
V2: Addressed review comments
Thierry:
- Fix typos in commit message and make abbreviation consistent
across the commit message.
- Change structure object name from hdmi_info -> hdmi
- Fix typos and abbreviations in description of structure drm_hdmi_info
end the description with a full stop.
- Create a structure drm_scdc, and keep all information related to SCDC
register set (supported, read request supported) etc in it.
Ville:
- Change rr -> read_request
- Call drm_detect_scrambling function drm_parse_hf_vsdb so that all
of HF-VSDB parsing can be kept in same function, in incremental
patches.
V3: Rebase.
V4: Rebase.
V5: Rebase.
Signed-off-by: Shashank Sharma
Reviewed-by: Thierry Reding
---
drivers/gpu/drm/drm_edid.c | 14 ++
include/drm/drm_connector.h | 33 +
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 055b511..0881108 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3814,6 +3814,18 @@ enum hdmi_quantization_range
}
EXPORT_SYMBOL(drm_default_rgb_quant_range);
+static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ if (hf_vsdb[6] & 0x80) {
+ hdmi->scdc.supported = true;
+ if (hf_vsdb[6] & 0x40)
+ hdmi->scdc.read_request = true;
+ }
+}
+
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
const u8 *hdmi)
{
@@ -3928,6 +3940,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (cea_db_is_hdmi_vsdb(db))
drm_parse_hdmi_vsdb_video(connector, db);
+ if (cea_db_is_hdmi_forum_vsdb(db))
+ drm_parse_hdmi_forum_vsdb(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e5e1edd..6d5304e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -87,6 +87,34 @@ enum subpixel_order {
SubPixelVerticalRGB,
SubPixelVerticalBGR,
SubPixelNone,
+
+};
+
+/*
+ * struct drm_scdc - Information about scdc capabilities of a HDMI 2.0 sink
+ *
+ * Provides SCDC register support and capabilities related information on a
+ * HDMI 2.0 sink. In case of a HDMI 1.4 sink, all parameter must be 0.
+ */
+struct drm_scdc {
+ /**
+* @supported: status control & data channel present.
+*/
+ bool supported;
+ /**
+* @read_request: sink is capable of generating scdc read request.
+*/
+ bool read_request;
+};
+
+/**
+ * struct drm_hdmi_info - runtime information about the connected HDMI sink
+ *
+ * Describes if a given display supports advanced HDMI 2.0 features.
+ * This information is available in CEA-861-F extension blocks (like HF-VSDB).
+ */
+struct drm_hdmi_info {
+ struct drm_scdc scdc;
};
/**
@@ -188,6 +216,11 @@ struct drm_display_info {
* @cea_rev: CEA revision of the HDMI sink.
*/
u8 cea_rev;
+
+ /**
+* @hdmi: advance features of a HDMI sink.
+*/
+ struct drm_hdmi_info hdmi;
};
int drm_display_info_set_bus_formats(struct drm_display_info *info,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/6] drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++
drivers/gpu/drm/i915/intel_ddi.c | 29
drivers/gpu/drm/i915/intel_drv.h | 14 ++
drivers/gpu/drm/i915/intel_hdmi.c | 98 +++
4 files changed, 145 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ce6f096..1759b64 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7824,7 +7824,11 @@ enum {
#define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
#define TRANS_DDI_BFI_ENABLE (1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a7c08d7..24bc3a8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1311,6 +1311,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (IS_GEMINILAKE(dev_priv))
+ temp = intel_hdmi_handle_source_scrambling(
+ intel_encoder,
+ intel_crtc->config, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1885,6 +1890,21 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
+ if (IS_GEMINILAKE(dev_priv)) {
+ struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+ /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+ intel_hdmi_handle_sink_scrambling(intel_encoder,
+ conn_state->connector,
+ crtc->config, true);
+ }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
* are ignored so nothing special needs to be done besides
* enabling the port.
@@ -1912,11 +1932,20 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder,
struct drm_connector_state *old_conn_state)
{
struct drm_encoder *encoder = &intel_encoder->base;
+ struct drm_i915_private *dev_priv = encoder->dev->dev_private;
int type = intel_encoder->type;
if (old_crtc_state->has_audio)
intel_audio_codec_disable(intel_encoder);
+ if ((type == INTEL_OUTPUT_HDMI) && IS_GEMINILAKE(dev_priv)) {
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+
+ intel_hdmi_handle_sink_scrambling(intel_encoder,
+ old_conn_state->connector,
+
[PATCH v5 6/6] drm/i915: allow HDMI 2.0 clock rates
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
Reviewed-by: Ander Conselvan De Oliveira
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index fdbeefd..d44b9fb 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1209,6 +1209,8 @@ static int intel_hdmi_source_max_tmds_clock(struct
drm_i915_private *dev_priv)
{
if (IS_G4X(dev_priv))
return 165000;
+ else if (IS_GEMINILAKE(dev_priv))
+ return 594000;
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return 30;
else
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 2/5] arm64: dts: exynos: Remove the OF graph from DSI node for exynos5433 dts
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 6ce93a3..77ba238 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -298,23 +298,11 @@
status = "okay";
vddcore-supply = <&ldo6_reg>;
vddio-supply = <&ldo7_reg>;
+ samsung,burst-clock-frequency = <51200>;
+ samsung,esc-clock-frequency = <1600>;
samsung,pll-clock-frequency = <2400>;
pinctrl-names = "default";
pinctrl-0 = <&te_irq>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@1 {
- reg = <1>;
-
- dsi_out: endpoint {
- samsung,burst-clock-frequency = <51200>;
- samsung,esc-clock-frequency = <1600>;
- };
- };
- };
};
&hdmi {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: fix dmabuf mmap for dma_alloc'ed buffers
omap_gem_dmabuf_mmap() returns an error (with a WARN) when called for a buffer which is allocated with dma_alloc_*(). This prevents dmabuf mmap from working on SoCs without DMM, e.g. AM4 and OMAP3. I could not find any reason for omap_gem_dmabuf_mmap() rejecting such buffers, and just removing the if() fixes the limitation. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c index af267c35d813..ee5883f59be5 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c +++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c @@ -147,9 +147,6 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer, struct drm_gem_object *obj = buffer->priv; int ret = 0; - if (WARN_ON(!obj->filp)) - return -EINVAL; - ret = drm_gem_mmap_obj(obj, omap_gem_mmap_size(obj), vma); if (ret < 0) return ret; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Tue, Feb 28, 2017 at 04:07:02AM +, Navare, Manasi D wrote: > > On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote: > > Hi Daniel, > > > > We have ACKs on the userspace design from both Adams and Eric. > > Is this enough to merge the kernel patches? > > > > I spoke to Eric briefly about this and he gave me a verbal r-b as well. > > He said the userspace patches cant get merged unless DRM patches are merged. > > > > So what should be some of our next steps here? > > Still needs review on the kernel patches themselves, iirc Jani still had some > opens on that. But I was out of the loop for 2 weeks :-) -Daniel > > Thanks for merging the 1st patch in the kernel series. Are there any opens on > the 2nd patch (the i915 patch)? > I wanted to actually respin the 2nd patch to add reset for > intel_dp->lane_count on the link training failure so that it doesn't > accidently retrain the link with the stale/failed values. Didn't look like that, and we can do this as a follow-up. I only asked where we should merge it for best results. Let's continue that discussion in the other thread. -Daniel > > Regards > Manasi > > > > > Regards > > Manasi > > > > > > On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote: > > > Martin Peres writes: > > > > > > > On 06/02/17 17:50, Martin Peres wrote: > > > >> On 03/02/17 10:04, Daniel Vetter wrote: > > > >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote: > > > On 01/02/17 22:05, Manasi Navare wrote: > > > > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > > > >> Jani Nikula writes: > > > >> > > > >>> On Tue, 31 Jan 2017, Eric Anholt wrote: > > > Martin Peres writes: > > > > > > > Despite all the careful planing of the kernel, a link may > > > > become insufficient to handle the currently-set mode. At > > > > this point, the kernel should mark this particular > > > > configuration as being broken and potentially prune the > > > > mode before setting the offending connector's link-status > > > > to BAD and send the userspace a hotplug event. This may > > > > happen right after a modeset or later on. > > > > > > > > When available, we should use the link-status information > > > > to reset the wanted mode. > > > > > > > > Signed-off-by: Martin Peres > > > If I understand this right, there are two failure modes > > > being > > > handled: > > > > > > 1) A mode that won't actually work because the link isn't > > > good enough. > > > > > > 2) A mode that should work, but link parameters were too > > > optimistic and if we just ask the kernel to set the mode > > > again it'll use more conservative parameters that work. > > > > > > This patch seems good for 2). For 1), the > > > drmmode_set_mode_major is going to set our old mode back. > > > Won't the modeset then fail to link train again, and bring > > > us back into this loop? The only escape that I see would > > > be some other userspace responding to the advertised mode > > > list changing, and then asking X to modeset to something > > > new. > > > > > > To avoid that failure busy loop, should we re-fetching > > > modes at this point, and only re-setting if our mode still > > > exists? > > > >>> Disclaimer: I don't know anything about the internals of the > > > >>> modesetting driver. > > > >>> > > > >>> Perhaps we can identify the two cases now, but I'd put this > > > >>> more > > > >>> generally: if the link status has gone bad, it's an > > > >>> indicator to userspace that the circumstances may have > > > >>> changed, and userspace should query the kernel for the list > > > >>> of available modes again. It should no longer trust > > > >>> information obtained prior to getting the bad link status, > > > >>> including the current mode. > > > >>> > > > >>> But specifically, I think you're right, and AFAICT asking > > > >>> for the list of modes again is the only way for the > > > >>> userspace to distinguish between the two cases. I don't > > > >>> think there's a shortcut for deciding the current mode is > > > >>> still valid. > > > >> To avoid the busy-loop problem, I think I'd like this patch > > > >> to > > > >> re-query > > > >> the kernel to ask about the current mode list, and only try to > > > >> re-set > > > >> the mode if our mode is still there. > > > >> > > > >> If the mode isn't there, then it's up to the DE to take action in > > > >> response to the notification of new modes. If you don't have a DE > > > >> to > > > >> take appropriate action, you're kind of out of luck. > >
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Thu, Feb 02, 2017 at 09:57:20AM -0800, Eric Anholt wrote: > Daniel Vetter writes: > > > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > >> Jani Nikula writes: > >> > >> > On Tue, 31 Jan 2017, Eric Anholt wrote: > >> >> Martin Peres writes: > >> >> > >> >>> Despite all the careful planing of the kernel, a link may become > >> >>> insufficient to handle the currently-set mode. At this point, the > >> >>> kernel should mark this particular configuration as being broken > >> >>> and potentially prune the mode before setting the offending connector's > >> >>> link-status to BAD and send the userspace a hotplug event. This may > >> >>> happen right after a modeset or later on. > >> >>> > >> >>> When available, we should use the link-status information to reset > >> >>> the wanted mode. > >> >>> > >> >>> Signed-off-by: Martin Peres > >> >> > >> >> If I understand this right, there are two failure modes being handled: > >> >> > >> >> 1) A mode that won't actually work because the link isn't good enough. > >> >> > >> >> 2) A mode that should work, but link parameters were too optimistic and > >> >> if we just ask the kernel to set the mode again it'll use more > >> >> conservative parameters that work. > >> >> > >> >> This patch seems good for 2). For 1), the drmmode_set_mode_major is > >> >> going to set our old mode back. Won't the modeset then fail to link > >> >> train again, and bring us back into this loop? The only escape that I > >> >> see would be some other userspace responding to the advertised mode list > >> >> changing, and then asking X to modeset to something new. > >> >> > >> >> To avoid that failure busy loop, should we re-fetching modes at this > >> >> point, and only re-setting if our mode still exists? > >> > > >> > Disclaimer: I don't know anything about the internals of the modesetting > >> > driver. > >> > > >> > Perhaps we can identify the two cases now, but I'd put this more > >> > generally: if the link status has gone bad, it's an indicator to > >> > userspace that the circumstances may have changed, and userspace should > >> > query the kernel for the list of available modes again. It should no > >> > longer trust information obtained prior to getting the bad link status, > >> > including the current mode. > >> > > >> > But specifically, I think you're right, and AFAICT asking for the list > >> > of modes again is the only way for the userspace to distinguish between > >> > the two cases. I don't think there's a shortcut for deciding the current > >> > mode is still valid. > >> > >> To avoid the busy-loop problem, I think I'd like this patch to re-query > >> the kernel to ask about the current mode list, and only try to re-set > >> the mode if our mode is still there. > > > > Yeah, I guess that sounds like a reasonable heuristics. More integrated > > compositors (aka the wayland ones) might be able to make more useful > > decisions, but for -modesetting that's probably the best we can do. > > > >> If the mode isn't there, then it's up to the DE to take action in > >> response to the notification of new modes. If you don't have a DE to > >> take appropriate action, you're kind of out of luck. > >> > >> As far as the ABI goes, this seems fine to me. The only concern I had > >> about ABI was having to walk all the connectors on every uevent to see > >> if any had gone bad -- couldn't we have a flag of some sort about what > >> the uevent indicates? But uevents should be super rare, so I'd say the > >> kernel could go ahead with the current plan. > > > > We've discussed finer-grained uevent singalling a few times, and I'd like > > that to be an orthogonal abi extension. Right now we just don't have the > > required tracking even within the kernel to know which connector changed > > (and the tracking we do have missed a few things, too). My idea is to push > > the tracking into the leaves of the callchains with a function that > > increases some per-connector epoch counter. Then we'd just have to expose > > that somehow cheaply to userspace (could probably just send it along in > > the uevent). Plus expose it as a read-only property so that userspace can > > re-synchronize. > > > > But again, that should be an orthogonal thing imo. > > Yeah, that was roughly my thought process, too. I merged the kernel side of this new uapi: commit 40ee6fbef75fe6452dc9e69e6f9f1a2c7808ed67 Author: Manasi Navare Date: Fri Dec 16 12:29:06 2016 +0200 drm: Add a new connector atomic property for link status Feel free to go ahead with the userspace side merging. (Yes the i915 side isn't merged yet, but purely for "in which branch should I put it?" technicality). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 1/9] video: add hotplug detect notifier support
On Mon, Feb 27, 2017 at 05:46:51PM +, Russell King - ARM Linux wrote: > On Mon, Feb 27, 2017 at 06:21:05PM +0100, Hans Verkuil wrote: > > On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote: > > > I'm afraid that I walked away from this after it became clear that there > > > was little hope for any forward progress being made in a timely manner > > > for multiple reasons (mainly the core CEC code being out of mainline.) > > > > In case you missed it: the core CEC code was moved out of staging and into > > mainline in 4.10. > > I was aware (even though I've not been publishing anything, I do keep > dw-hdmi-cec and tda9950/tda998x up to date with every final kernel > release.) > > > > If you can think of a better approach, then I'm sure there's lots of > > > people who'd be willing to do the coding for it... if not, I'm not > > > sure where we go from here (apart from keeping code in private/vendor > > > trees.) > > > > For CEC there are just two things that it needs: the physical address > > (contained in the EDID) and it needs to be informed when the EDID disappears > > (typically due to a disconnect), in which case the physical address > > becomes invalid (f.f.f.f). > > Yep. CEC really only needs to know "have new phys address" and > "disconnect" provided that CEC drivers understand that they may receive > a new phys address with no intervening disconnect. (Consider the case > where EDID changes, but the HDMI driver failed to spot the HPD signal > pulse - unfortunately, there's hardware out there where HPD is next to > useless.) Ok, simplifying the CEC stuff like that would be a lot better I think, to avoid overlap with other in-kernel interfaces. I still have some questions, but this might be my misunderstanding of how CEC works: I thought that CEC is driven through a special separate wire in the HDMI bus, with the receiver in the TV. Which means that we'd have a 1:1 relationship between HDMI connector and CEC port. That's at least the use-case I've heard of for Intel boards. Are there other use-cases where we do not have a 1:1 relationship between HDMI connector and CEC port? Imo notifier really only makes sense as a quick&dirty hack, or if you really have n:m for at least one of n,m != 1. Otherwise some very specific callback service which just provides the information the CEC side needs seems like a much better idea to me. > > Russell, do you have pending code that needs the ELD support in the > > notifier? CEC doesn't need it, so from my perspective it can be > > dropped in the first version. > > I was looking for that while writing the previous mail, and I think > it's time to drop it - I had thought dw-hdmi-*audio would use it, or > the ASoC people, but it's still got no users, so I think it's time > to drop it. For ELD I'd definitely say let's please use the hdmi-codec.h. It's what's in tree, so better to converge on one solution instead of proliferating even more. The entire sad story of multiple people inventing similar wheels without talking with each another is water down the river, can't fix that anymore :( > I have seen some patch sets go by which are making use of the notifier, > but I haven't paid close attention to how they're using it or what > they're using it for... as I sort of implied in my previous mail, I > had lost interest in mainline wrt CEC stuff due to the glacial rate > of progress. (That's not a criticism.) Maybe some docs that would describe the flow we want to achieve here would help? Doesn't need to be more than a few lines, but reconstructing that from the various driver patches later on is indeed hard. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] vc4 RST documentation
On Mon, Feb 27, 2017 at 12:11:40PM -0800, Eric Anholt wrote: > danvet asked me a while ago to try generating documentation with the > new RST-based infrastructure. I had a couple of hours to do some > editing, so here it is. > > So far I'm not including any kerneldoc for functions. I don't think I > have enough documentation coverage yet to make it useful to start > including the current ones in the output. > > Eric Anholt (4): > drm/vc4: Convert existing documentation to actual kerneldoc. > drm/vc4: Add RST to bring together vc4 kerneldoc. > drm/vc4: Extend and edit documentation for output from the RST > drm/vc4: Add a paragraph at the top of vc4 docs introducing what it > is. Woooho, this is sweet! I know it's just a rough just, but I think i915 is even rougher, and we just need to get going somewhere. Really awesome. On the series: Acked-by: Daniel Vetter > > Documentation/gpu/index.rst| 1 + > Documentation/gpu/vc4.rst | 89 > ++ > drivers/gpu/drm/vc4/vc4_bo.c | 5 +- > drivers/gpu/drm/vc4/vc4_crtc.c | 7 ++- > drivers/gpu/drm/vc4/vc4_dpi.c | 3 +- > drivers/gpu/drm/vc4/vc4_drv.c | 16 ++ > drivers/gpu/drm/vc4/vc4_dsi.c | 5 +- > drivers/gpu/drm/vc4/vc4_gem.c | 26 +++-- > drivers/gpu/drm/vc4/vc4_hdmi.c | 23 +++- > drivers/gpu/drm/vc4/vc4_hvs.c | 12 ++-- > drivers/gpu/drm/vc4/vc4_irq.c | 3 +- > drivers/gpu/drm/vc4/vc4_render_cl.c| 4 ++ > drivers/gpu/drm/vc4/vc4_validate.c | 34 +++- > drivers/gpu/drm/vc4/vc4_validate_shaders.c | 21 --- > drivers/gpu/drm/vc4/vc4_vec.c | 6 ++ > 15 files changed, 212 insertions(+), 43 deletions(-) > create mode 100644 Documentation/gpu/vc4.rst > > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: qxl: Don't alloc fbdev if emulation is not supported
On Mon, Feb 27, 2017 at 05:33:30PM -0300, Gabriel Krisman Bertazi wrote:
> If fbdev emulation is disabled, the QXL shutdown path will try to clean
> a framebuffer that wasn't initialized, hitting the Oops below. The
> problem is that even when FBDEV_EMULATION is disabled we allocate the
> qfbdev strutucture, but we don't initialize it. The fix is to stop
> allocating the memory, since it won't be used. This allows the existing
> verification in the cleanup hook to do it's job preventing the oops.
>
> Now that we don't allocate the unused fbdev structure, we need to be
> careful when dereferencing it in the PM suspend hook.
>
> [ 24.284684] BUG: unable to handle kernel NULL pointer dereference at
> 02e0
> [ 24.285627] IP: mutex_lock+0x18/0x30
> [ 24.286049] PGD 78cdf067
> [ 24.286050] PUD 7940f067
> [ 24.286344] PMD 0
> [ 24.286649]
> [ 24.287072] Oops: 0002 [#1] SMP
> [ 24.287422] Modules linked in: qxl
> [ 24.287806] CPU: 0 PID: 2328 Comm: bash Not tainted 4.10.0-rc5+ #97
> [ 24.288515] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [ 24.289681] task: 88007c4c task.stack: c90001b58000
> [ 24.290354] RIP: 0010:mutex_lock+0x18/0x30
> [ 24.290812] RSP: 0018:c90001b5bcb0 EFLAGS: 00010246
> [ 24.291401] RAX: RBX: 02e0 RCX:
>
> [ 24.292209] RDX: 88007c4c RSI: 0001 RDI:
> 02e0
> [ 24.292987] RBP: c90001b5bcb8 R08: fffe R09:
> 0001
> [ 24.293797] R10: 880078d80b80 R11: 00011400 R12:
>
> [ 24.294601] R13: 02e0 R14: a0009c28 R15:
> 0060
> [ 24.295439] FS: 7f30e3acbb40() GS:88007fc0()
> knlGS:
> [ 24.296364] CS: 0010 DS: ES: CR0: 80050033
> [ 24.296997] CR2: 02e0 CR3: 78c7b000 CR4:
> 06f0
> [ 24.297813] Call Trace:
> [ 24.298097] drm_framebuffer_cleanup+0x1f/0x70
> [ 24.298612] qxl_fbdev_fini+0x68/0x90 [qxl]
> [ 24.299074] qxl_modeset_fini+0xd/0x30 [qxl]
> [ 24.299562] qxl_pci_remove+0x22/0x50 [qxl]
> [ 24.300025] pci_device_remove+0x34/0xb0
> [ 24.300507] device_release_driver_internal+0x150/0x200
> [ 24.301082] device_release_driver+0xd/0x10
> [ 24.301587] unbind_store+0x108/0x150
> [ 24.301993] drv_attr_store+0x20/0x30
> [ 24.302402] sysfs_kf_write+0x32/0x40
> [ 24.302827] kernfs_fop_write+0x108/0x190
> [ 24.303269] __vfs_write+0x23/0x120
> [ 24.303678] ? security_file_permission+0x36/0xb0
> [ 24.304193] ? rw_verify_area+0x49/0xb0
> [ 24.304636] vfs_write+0xb0/0x190
> [ 24.305004] SyS_write+0x41/0xa0
> [ 24.305362] entry_SYSCALL_64_fastpath+0x1a/0xa9
> [ 24.305887] RIP: 0033:0x7f30e31d9620
> [ 24.306285] RSP: 002b:7ffc54b47e68 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 24.307128] RAX: ffda RBX: 7f30e3497600 RCX:
> 7f30e31d9620
> [ 24.307928] RDX: 000d RSI: 00da2008 RDI:
> 0001
> [ 24.308727] RBP: 0070bc60 R08: 7f30e3498760 R09:
> 7f30e3acbb40
> [ 24.309504] R10: 0073 R11: 0246 R12:
> 0001
> [ 24.310295] R13: R14: R15:
> 7ffc54b47f34
> [ 24.311095] Code: 0e 01 e9 7b fe ff ff 66 90 66 2e 0f 1f 84 00 00 00 00 00
> 55 48 89 e5 53 48 89 fb e8 83 e8 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <3e>
> 48 0f b1 13 48 85 c0 74 08 48 89 df e8 66 fd ff ff 5b 5d c3
> [ 24.313182] RIP: mutex_lock+0x18/0x30 RSP: c90001b5bcb0
> [ 24.313811] CR2: 02e0
> [ 24.314208] ---[ end trace 29669c1593cae14b ]---
>
> Signed-off-by: Gabriel Krisman Bertazi
Hm, I bit silly that we need #ifdef here, all this stuff is meant to Just
Work. Can't we just fix the oops with suitable checks in the fini paths
instead?
Also 0day has hit some oops in bochs, it might suffer from similar bugs.
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_fb.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
> index 35124737666e..14e2a49a4dcf 100644
> --- a/drivers/gpu/drm/qxl/qxl_fb.c
> +++ b/drivers/gpu/drm/qxl/qxl_fb.c
> @@ -368,9 +368,11 @@ static const struct drm_fb_helper_funcs
> qxl_fb_helper_funcs = {
>
> int qxl_fbdev_init(struct qxl_device *qdev)
> {
> + int ret = 0;
> +
> +#ifdef CONFIG_DRM_FBDEV_EMULATION
> struct qxl_fbdev *qfbdev;
> int bpp_sel = 32; /* TODO: parameter from somewhere? */
> - int ret;
>
> qfbdev = kzalloc(sizeof(struct qxl_fbdev), GFP_KERNEL);
> if (!qfbdev)
> @@ -403,6 +405,8 @@ int qxl_fbdev_init(struct qxl_device *qdev)
> drm_fb_helper_fini(&qfbdev->helper);
> free:
> kfree(qfbdev);
> +#endif
> +
> return ret;
> }
>
> @@ -418,6 +422,9 @@ void qxl_fbdev_fini(s
Re: [PATCH RESEND] drm/via: use get_user_pages_unlocked()
On Mon, Feb 27, 2017 at 09:50:08PM +, Lorenzo Stoakes wrote:
> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>
> Signed-off-by: Lorenzo Stoakes
Queued for 4.12, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/via/via_dmablit.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/via/via_dmablit.c
> b/drivers/gpu/drm/via/via_dmablit.c
> index 1a3ad769f8c8..98aae9809249 100644
> --- a/drivers/gpu/drm/via/via_dmablit.c
> +++ b/drivers/gpu/drm/via/via_dmablit.c
> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,
> drm_via_dmablit_t *xfer)
> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
> if (NULL == vsg->pages)
> return -ENOMEM;
> - down_read(¤t->mm->mmap_sem);
> - ret = get_user_pages((unsigned long)xfer->mem_addr,
> - vsg->num_pages,
> - (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE :
> 0,
> - vsg->pages, NULL);
> -
> - up_read(¤t->mm->mmap_sem);
> + ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> + vsg->num_pages, vsg->pages,
> + (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
> if (ret != vsg->num_pages) {
> if (ret < 0)
> return ret;
> --
> 2.11.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] gpu: drm: Convert printk(KERN_ to pr_
On Mon, Feb 27, 2017 at 05:31:04PM -0800, Joe Perches wrote: > Use a more common logging style. > > Miscellanea: > > o Coalesce formats and realign arguments > o Neaten a few macros now using pr_ > > Signed-off-by: Joe Perches I know this is pain, but can you pls split this into: - amd/radeon drivers - drm core (anything that's not a subdirectory) - all other drivers for merge technical reasons? DRM is huge, we need to split big patches like this one to avoid conflict chaos. Patch 1 only touches amd stuff, so can go in directly with Alex' tree. -Daniel > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +- > drivers/gpu/drm/amd/amdgpu/atom.c | 44 - > drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 4 +- > drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ++-- > drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ++-- > drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 +- > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 +- > drivers/gpu/drm/amd/include/amd_pcie_helpers.h | 4 +- > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- > drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 2 +- > drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c| 4 +- > drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++--- > .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 +- > drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 +- > drivers/gpu/drm/drm_cache.c| 12 ++--- > drivers/gpu/drm/drm_edid.c | 4 +- > drivers/gpu/drm/drm_ioc32.c| 3 +- > drivers/gpu/drm/gma500/cdv_intel_lvds.c| 9 ++-- > drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++ > drivers/gpu/drm/gma500/psb_drv.h | 5 +- > drivers/gpu/drm/gma500/psb_intel_lvds.c| 7 ++- > drivers/gpu/drm/i915/i915_sw_fence.c | 8 ++-- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_acpi.c | 7 +-- > drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +- > drivers/gpu/drm/nouveau/nv50_display.c | 22 - > drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++-- > drivers/gpu/drm/omapdrm/dss/dsi.c | 17 --- > drivers/gpu/drm/omapdrm/dss/dss.c | 3 +- > drivers/gpu/drm/omapdrm/dss/dss.h | 15 +++--- > drivers/gpu/drm/omapdrm/omap_gem.c | 5 +- > drivers/gpu/drm/r128/r128_cce.c| 7 ++- > drivers/gpu/drm/radeon/atom.c | 46 -- > drivers/gpu/drm/radeon/cik.c | 56 > -- > drivers/gpu/drm/radeon/evergreen.c | 2 +- > drivers/gpu/drm/radeon/evergreen_cs.c | 7 ++- > drivers/gpu/drm/radeon/ni.c| 22 +++-- > drivers/gpu/drm/radeon/r100.c | 18 +++ > drivers/gpu/drm/radeon/r200.c | 3 +- > drivers/gpu/drm/radeon/r300.c | 13 ++--- > drivers/gpu/drm/radeon/r420.c | 9 ++-- > drivers/gpu/drm/radeon/r520.c | 3 +- > drivers/gpu/drm/radeon/r600.c | 21 +++- > drivers/gpu/drm/radeon/r600_cs.c | 7 ++- > drivers/gpu/drm/radeon/radeon.h| 3 +- > drivers/gpu/drm/radeon/radeon_atpx_handler.c | 4 +- > drivers/gpu/drm/radeon/radeon_audio.c | 4 +- > drivers/gpu/drm/radeon/radeon_clocks.c | 2 +- > drivers/gpu/drm/radeon/radeon_device.c | 8 ++-- > drivers/gpu/drm/radeon/radeon_fb.c | 3 +- > drivers/gpu/drm/radeon/radeon_gem.c| 4 +- > drivers/gpu/drm/radeon/radeon_test.c | 6 +-- > drivers/gpu/drm/radeon/rs400.c | 4 +- > drivers/gpu/drm/radeon/rs690.c | 3 +- > drivers/gpu/drm/radeon/rv515.c | 9 ++-- > drivers/gpu/drm/radeon/si.c| 45 ++--- > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +- > 69 f
Re: [PATCH v2 2/3] drm/vc4: Add HDMI audio support
On Mon, 27 Feb 2017 12:28:02 -0800 Eric Anholt wrote: > The HDMI encoder IP embeds all needed blocks to output audio, with a > custom DAI called MAI moving audio between the two parts of the HDMI > core. This driver now exposes a sound card to let users stream audio > to their display. > > Using the hdmi-codec driver has been considered here, but MAI meant > having to significantly rework hdmi-codec, and it would have left > little shared code with the I2S mode anyway. > > The encoder requires that the audio be SPDIF-formatted frames only, > which alsalib will format-convert for us. > > This patch is the combined work of Eric Anholt (initial register setup > with a separate dmaengine driver and using simple-audio-card) and > Boris Brezillon (moving it all into HDMI, massive debug to get it > actually working), and which Eric has the permission to release. > > v2: Drop "-audio" from sound card name, since that's already implied > (suggestion by Boris) > > Signed-off-by: Eric Anholt Acked-by: Boris Brezillon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 1/9] video: add hotplug detect notifier support
On 02/28/17 09:51, Daniel Vetter wrote: On Mon, Feb 27, 2017 at 05:46:51PM +, Russell King - ARM Linux wrote: On Mon, Feb 27, 2017 at 06:21:05PM +0100, Hans Verkuil wrote: On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote: I'm afraid that I walked away from this after it became clear that there was little hope for any forward progress being made in a timely manner for multiple reasons (mainly the core CEC code being out of mainline.) In case you missed it: the core CEC code was moved out of staging and into mainline in 4.10. I was aware (even though I've not been publishing anything, I do keep dw-hdmi-cec and tda9950/tda998x up to date with every final kernel release.) If you can think of a better approach, then I'm sure there's lots of people who'd be willing to do the coding for it... if not, I'm not sure where we go from here (apart from keeping code in private/vendor trees.) For CEC there are just two things that it needs: the physical address (contained in the EDID) and it needs to be informed when the EDID disappears (typically due to a disconnect), in which case the physical address becomes invalid (f.f.f.f). Yep. CEC really only needs to know "have new phys address" and "disconnect" provided that CEC drivers understand that they may receive a new phys address with no intervening disconnect. (Consider the case where EDID changes, but the HDMI driver failed to spot the HPD signal pulse - unfortunately, there's hardware out there where HPD is next to useless.) Ok, simplifying the CEC stuff like that would be a lot better I think, to avoid overlap with other in-kernel interfaces. I still have some questions, but this might be my misunderstanding of how CEC works: I thought that CEC is driven through a special separate wire in the HDMI bus, with the receiver in the TV. Which means that we'd have a 1:1 relationship between HDMI connector and CEC port. That's at least the use-case I've heard of for Intel boards. Are there other use-cases where we do not have a 1:1 relationship between HDMI connector and CEC port? Imo notifier really only makes sense as a quick&dirty hack, or if you really have n:m for at least one of n,m != 1. Otherwise some very specific callback service which just provides the information the CEC side needs seems like a much better idea to me. For the current set of CEC drivers it is 1:1. I am fairly certain you can get n:1 situations where multiple HDMI connectors use a single CEC adapter. I'm thinking primarily about HDMI switches here. Also TVs with multiple inputs (basically a switch as well). I do not support such hardware yet, though. Or to be more specific: I've never tested this, so I am not sure if this would work in the current framework, or if I need to do some more work for that. That said, each CEC adapter would have only 0 or 1 HDMI outputs and 0 or more HDMI inputs. More than one HDMI outputs is AFAICT not possible. Russell, do you have pending code that needs the ELD support in the notifier? CEC doesn't need it, so from my perspective it can be dropped in the first version. I was looking for that while writing the previous mail, and I think it's time to drop it - I had thought dw-hdmi-*audio would use it, or the ASoC people, but it's still got no users, so I think it's time to drop it. For ELD I'd definitely say let's please use the hdmi-codec.h. It's what's in tree, so better to converge on one solution instead of proliferating even more. The entire sad story of multiple people inventing similar wheels without talking with each another is water down the river, can't fix that anymore :( I'll drop that in my next patch series. I have seen some patch sets go by which are making use of the notifier, but I haven't paid close attention to how they're using it or what they're using it for... as I sort of implied in my previous mail, I had lost interest in mainline wrt CEC stuff due to the glacial rate of progress. (That's not a criticism.) Maybe some docs that would describe the flow we want to achieve here would help? Doesn't need to be more than a few lines, but reconstructing that from the various driver patches later on is indeed hard. I'll add some more documentation for the next version. But in a nutshell: each HDMI connector (in or out) has to notify the CEC driver when the physical address changes (when an EDID is read or set, or when the HPD goes down). It also needs to provide the current physical address when the CEC driver is first loaded. This latter requirement is handled by the notifier framework which remembers the EDID and will create a notify event as soon as the CEC driver registers itself. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Janpieter Sollie from comment #0) > I modified the drm_atomic.c a bit to be more verbose. the drm_init calls a > general protection fault when allocating my second GPU(does it work this > way?) of the amdgpu module. [...] > [ 77.950445] Modules linked in: amdkfd amdgpu(O+) amdttm(O) amdkcl(O) amdttm and amdkcl indicate that you're using an out-of-tree version of the amdgpu kernel module, possibly from an amdgpu-pro release? Does the problem also occur with the in-tree amdgpu driver? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #2 from Janpieter Sollie (janpieter.sol...@dommel.be) --- an additional post-protection fault which proves it screws up the memory management of the kernel: <6>[ 376.340003] general protection fault: [#3] SMP <6>[ 376.340005] Modules linked in: amdkfd amdgpu(O+) amdttm(O) amdkcl(O) esp4 xfrm4_mode_tunnel ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat iptable_nat nf_nat_ipv4 nf_nat l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc deflate cmac af_key w83627ehf hwmon_vid k10temp fam15h_power i2c_piix4 pcspkr <6>[ 376.340033] CPU: 16 PID: 10421 Comm: e2label Tainted: G DO 4.10.0-rc8 #12 <6>[ 376.340035] Hardware name: Supermicro H8DG6/H8DGi/H8DG6/H8DGi, BIOS 2.0a 01/09/2012 <6>[ 376.340037] task: 881039be6200 task.stack: c9002663c000 <6>[ 376.340047] RIP: 0010:kmem_cache_alloc+0x57/0xd0 <6>[ 376.340049] RSP: 0018:c9002663f950 EFLAGS: 00010286 <6>[ 376.340052] RAX: RBX: 88083bd7d000 RCX: 0574 <6>[ 376.340053] RDX: 0573 RSI: 01408000 RDI: 00019b70 <6>[ 376.340055] RBP: c9002663f970 R08: 88183fc19b70 R09: 81454f96 <6>[ 376.340056] R10: 0001 R11: 88203a80d550 R12: ff88183888cc <6>[ 376.340057] R13: 88083f803a00 R14: 01408000 R15: 0005 <6>[ 376.340060] FS: 7f62cc6b2780() GS:88183fc0() knlGS: <6>[ 376.340062] CS: 0010 DS: ES: CR0: 80050033 <6>[ 376.340064] CR2: 7f62cc2a8320 CR3: 001837444000 CR4: 000406e0 <6>[ 376.340065] Call Trace: <6>[ 376.340073] scsi_execute_req_flags+0x46/0x100 <6>[ 376.340076] scsi_test_unit_ready+0x85/0x130 <6>[ 376.340080] sd_check_events+0x116/0x160 <6>[ 376.340085] disk_check_events+0x5a/0x130 <6>[ 376.340088] disk_clear_events+0x6a/0x110 <6>[ 376.340092] check_disk_change+0x32/0x70 <6>[ 376.340095] sd_open+0x69/0x130 <6>[ 376.340097] __blkdev_get+0x2ff/0x3f0 <6>[ 376.340100] blkdev_get+0x115/0x330 <6>[ 376.340106] ? _raw_spin_unlock+0x9/0x10 <6>[ 376.340109] blkdev_open+0x56/0x70 <6>[ 376.340113] do_dentry_open+0x215/0x300 <6>[ 376.340115] ? blkdev_get_by_dev+0x60/0x60 <6>[ 376.340118] vfs_open+0x4c/0x70 <6>[ 376.340123] ? may_open+0x96/0x100 <6>[ 376.340127] path_openat+0x29f/0x1350 <6>[ 376.340131] do_filp_open+0x7c/0xd0 <6>[ 376.340135] ? vma_link+0xc5/0xd0 <6>[ 376.340139] ? _raw_spin_unlock+0x9/0x10 <6>[ 376.340142] ? __alloc_fd+0xa9/0x170 <6>[ 376.340145] do_sys_open+0x121/0x200 <6>[ 376.340148] SyS_open+0x19/0x20 <6>[ 376.340152] do_syscall_64+0x63/0x180 <6>[ 376.340156] entry_SYSCALL64_slow_path+0x25/0x25 <6>[ 376.340158] RIP: 0033:0x7f62cb74d760 <6>[ 376.340160] RSP: 002b:7fff591f3d58 EFLAGS: 0246 ORIG_RAX: 0002 <6>[ 376.340162] RAX: ffda RBX: 4000 RCX: 7f62cb74d760 <6>[ 376.340164] RDX: RSI: RDI: 01449420 <6>[ 376.340165] RBP: R08: 0021 R09: 7f62cb79a9b0 <6>[ 376.340167] R10: 0130 R11: 0246 R12: 01449310 <6>[ 376.340168] R13: 01449240 R14: 0009 R15: 01449118 <6>[ 376.340170] Code: 8b 45 00 65 49 8b 50 08 65 4c 03 05 24 5f ea 7e 49 83 78 10 00 4d 8b 20 74 4a 4d 85 e4 74 45 49 63 45 20 48 8d 4a 01 49 8b 7d 00 <49> 8b 1c 04 4c 89 e0 65 48 0f c7 0f 0f 94 c0 84 c0 74 c1 49 63 <1>[ 376.340210] RIP: kmem_cache_alloc+0x57/0xd0 RSP: c9002663f950 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/2] drm/probe-helper: Add mode_valid check to drm_crtc_helper_funcs
On Mon, Feb 27, 2017 at 10:03:20PM -0800, John Stultz wrote: > On Mon, Feb 20, 2017 at 2:32 PM, Daniel Vetter wrote: > > I thought about this some more, I think what we need to fix this mess > > properly is: > > - mode_valid helper callbacks for crtc, encoder, bridges, with the > > same interface as for connectors. > > - calling all these new mode_valid hooks from the probe helpers, but > > with the restriction that we only reject a mode if all possible > > crtc/encoders combos reject it. We need to filter by > > possible_encoders/crtcs for these checks. Bridges have a fixed routing > > to their encoder, so those are easy. > > So... my ignorance here my have complicated things a bit. > > Xinliang can correct me here, if I get this wrong. :) > > So in the past, when we ran into this issue, we just hacked in a mode > white list into the adv7511 bridge mode_valid check, as it was the > easiest place. But as I understood it, the limitation came from logic > in (what is now an early version of) the kirin ade driver. > > However, since kirin made it upstream, the code was refactored and I > believe the specific code was moved to the dsi_calc_phy_rate() which > is part of the dsi encoder, not the crtc code. > > So in my limited understanding I initially tried to add the mode_check > logic in the ade crtc driver, but to me (and I could have this wrong > again) it seems it really ought to be in the encoder (where we > probably could do better then using a white list by doing the mode > calculations and seeing if we get a value that matches what was > requested). > > I'm not sure if that simplifies your proposal (possibly avoiding the > crtc/encoder combo checks?), or if you think we still need the big > grand solution? We'll need the grand plan for other drivers I think. Or at least that's what I'm trying to volunteer you for :-) If you just want to fix up your specific combo, then you can just hack up that driver. You don't need any core/helper changes for that. > > - add calls to mode_valid in the atomic helpers, right before we call > > mode_fixup or atomic_check in drm_atomic_helper_check_modesets. > > - convert drivers to move code from mode_fixup into mode_valid > > wherever possible, to make sure we can share as much of the check > > logic between probe and atomic comit code. > > - update docs for all the hooks, plus update the overview sections > > accordingly. > > > > I think this should give us a good approximation of nirvana. For I > > long time I thought we could get away without adding mode_valid > > everywhere, but in the probe paths we really can't fake the > > adjusted_mode (and other atomic state), so adding dedicated hooks > > which are called from both places is probably the only option. > > So my mental map of the DRM code is all pretty hazy and limited here, > but the above sounds reasonable. I'll try to trace through and better > understand what specifically you're asking for and get something > started here. Yeah, we're still lacking the nice overview graphs for the drm docs. I have them here, but the kbuild scripts need polish :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #3 from Janpieter Sollie (janpieter.sol...@dommel.be) --- (In reply to Michel Dänzer from comment #1) > (In reply to Janpieter Sollie from comment #0) > > I modified the drm_atomic.c a bit to be more verbose. the drm_init calls a > > general protection fault when allocating my second GPU(does it work this > > way?) of the amdgpu module. > > [...] > > > [ 77.950445] Modules linked in: amdkfd amdgpu(O+) amdttm(O) amdkcl(O) > > amdttm and amdkcl indicate that you're using an out-of-tree version of the > amdgpu kernel module, possibly from an amdgpu-pro release? Does the problem > also occur with the in-tree amdgpu driver? no, then the kernel simply reboots. I'm sorry for using the amd pro module, but native amd doesn't tell me anything: modprobe amdgpu & cat /proc/kmsg gives this as its last output: <6>[ 252.228071] amdgpu :41:00.0: fence driver on ring 0 use gpu addr 0x4010, cpu addr 0x881831cc6010 <6>[ 252.228253] amdgpu :41:00.0: fence driver on ring 1 use gpu addr 0x4020, cpu addr 0x881831cc6020 <6>[ 252.228601] amdgpu :41:00.0: fence driver on ring 2 use gpu addr 0x4030, cpu addr 0x881831cc6030 <6>[ 252.228768] amdgpu :41:00.0: fence driver on ring 3 use gpu addr 0x4040, cpu addr 0x881831cc6040 <6>[ 252.228939] amdgpu :41:00.0: fence driver on ring 4 use gpu addr 0x4050, cpu addr 0x881831cc6050 <6>[ 252.229092] [drm] probing gen 2 caps for device 1002:5a1f = 31cd02/0 <6>[ 252.229096] [drm] PCIE gen 2 link speeds already enabled <6>[ 252.458236] [drm] ring test on 0 succeeded in 7 usecs <6>[ 252.460247] [drm] ring test on 1 succeeded in 1 usecs <6>[ 252.460256] [drm] ring test on 2 succeeded in 1 usecs <6>[ 252.460265] [drm] ring test on 3 succeeded in 3 usecs <6>[ 252.460272] [drm] ring test on 4 succeeded in 3 usecs but this is probably related to another bug: 194559 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194559] amdgpu problems loading 2 firmwares on multi-smp system
https://bugzilla.kernel.org/show_bug.cgi?id=194559 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=194731 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 Janpieter Sollie (janpieter.sol...@dommel.be) changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=194559 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv4 1/9] video: add hotplug detect notifier support
On Tue, Feb 28, 2017 at 10:23:57AM +0100, Hans Verkuil wrote: > On 02/28/17 09:51, Daniel Vetter wrote: > > On Mon, Feb 27, 2017 at 05:46:51PM +, Russell King - ARM Linux wrote: > > > On Mon, Feb 27, 2017 at 06:21:05PM +0100, Hans Verkuil wrote: > > > > On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote: > > > > > I'm afraid that I walked away from this after it became clear that > > > > > there > > > > > was little hope for any forward progress being made in a timely manner > > > > > for multiple reasons (mainly the core CEC code being out of mainline.) > > > > > > > > In case you missed it: the core CEC code was moved out of staging and > > > > into > > > > mainline in 4.10. > > > > > > I was aware (even though I've not been publishing anything, I do keep > > > dw-hdmi-cec and tda9950/tda998x up to date with every final kernel > > > release.) > > > > > > > > If you can think of a better approach, then I'm sure there's lots of > > > > > people who'd be willing to do the coding for it... if not, I'm not > > > > > sure where we go from here (apart from keeping code in private/vendor > > > > > trees.) > > > > > > > > For CEC there are just two things that it needs: the physical address > > > > (contained in the EDID) and it needs to be informed when the EDID > > > > disappears > > > > (typically due to a disconnect), in which case the physical address > > > > becomes invalid (f.f.f.f). > > > > > > Yep. CEC really only needs to know "have new phys address" and > > > "disconnect" provided that CEC drivers understand that they may receive > > > a new phys address with no intervening disconnect. (Consider the case > > > where EDID changes, but the HDMI driver failed to spot the HPD signal > > > pulse - unfortunately, there's hardware out there where HPD is next to > > > useless.) > > > > Ok, simplifying the CEC stuff like that would be a lot better I think, to > > avoid overlap with other in-kernel interfaces. I still have some > > questions, but this might be my misunderstanding of how CEC works: > > > > I thought that CEC is driven through a special separate wire in the HDMI > > bus, with the receiver in the TV. Which means that we'd have a 1:1 > > relationship between HDMI connector and CEC port. That's at least the > > use-case I've heard of for Intel boards. Are there other use-cases where > > we do not have a 1:1 relationship between HDMI connector and CEC port? Imo > > notifier really only makes sense as a quick&dirty hack, or if you really > > have n:m for at least one of n,m != 1. Otherwise some very specific > > callback service which just provides the information the CEC side needs > > seems like a much better idea to me. > > For the current set of CEC drivers it is 1:1. > > I am fairly certain you can get n:1 situations where multiple HDMI connectors > use a single CEC adapter. I'm thinking primarily about HDMI switches here. > Also > TVs with multiple inputs (basically a switch as well). > > I do not support such hardware yet, though. Or to be more specific: I've never > tested this, so I am not sure if this would work in the current framework, or > if I need to do some more work for that. > > That said, each CEC adapter would have only 0 or 1 HDMI outputs and 0 or more > HDMI inputs. More than one HDMI outputs is AFAICT not possible. > > > > > > > Russell, do you have pending code that needs the ELD support in the > > > > notifier? CEC doesn't need it, so from my perspective it can be > > > > dropped in the first version. > > > > > > I was looking for that while writing the previous mail, and I think > > > it's time to drop it - I had thought dw-hdmi-*audio would use it, or > > > the ASoC people, but it's still got no users, so I think it's time > > > to drop it. > > > > For ELD I'd definitely say let's please use the hdmi-codec.h. It's what's > > in tree, so better to converge on one solution instead of proliferating > > even more. The entire sad story of multiple people inventing similar > > wheels without talking with each another is water down the river, can't > > fix that anymore :( > > I'll drop that in my next patch series. > > > > > > I have seen some patch sets go by which are making use of the notifier, > > > but I haven't paid close attention to how they're using it or what > > > they're using it for... as I sort of implied in my previous mail, I > > > had lost interest in mainline wrt CEC stuff due to the glacial rate > > > of progress. (That's not a criticism.) > > > > Maybe some docs that would describe the flow we want to achieve here would > > help? Doesn't need to be more than a few lines, but reconstructing that > > from the various driver patches later on is indeed hard. > > I'll add some more documentation for the next version. > > But in a nutshell: each HDMI connector (in or out) has to notify the CEC > driver when the physical address changes (when an EDID is read or set, or > when the HPD goes down). It also needs to provide the current p
[PATCH] drm-misc: Document review best practices
Let's make sure that review doesn't go through needless cycles. Diff doesn't show this, but this is only for the "small drivers" part of drm. Acked-by: Boris Brezillon Acked-by: Jani Nikula Signed-off-by: Daniel Vetter --- drm-misc.rst | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drm-misc.rst b/drm-misc.rst index 73882dc55be6..d6367686d561 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -72,7 +72,7 @@ Merge Criteria Right now the only hard merge criteria are: -* Patch is properly reviewed or at least ack, i.e. don't just push your own +* Patch is properly reviewed or at least Ack, i.e. don't just push your own stuff directly. * drm-misc is for drm core (non-driver) patches, subsystem-wide refactorings, @@ -132,6 +132,16 @@ Slightly different rules apply: most cases this will just along the lines of "Looks good, Ack". drm-misc maintainers will help out with getting that review market going. +* Best practice for review: When you have some suggestions and comments for + future work, please make sure you don't forget your Ack tag to unblock the + original patch. And if you think something really must be fixed before + merging, please give a conditional Ack along the lines of "Fix + $specific_thing, with that addressed, Ack". The goal is to always have a clear + and reasonable speedy path towards getting the patch merged. For authors on + the other side, just do the minimal rework and push the patch, and do any + more involved rework in follow-up work. This way lenghty review cycles get + avoided, which are a drag for both reviewer and author. + Tooling === -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 00/14] QXL atomic modesetting
On Mo, 2017-02-27 at 17:43 -0300, Gabriel Krisman Bertazi wrote: > Hi, > > This is a resend of the qxl atomic modesetting patchset to include the > reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next. > > This series implements support for Atomic Modesetting in the QXL driver. > The first 4 patches in the series are some cleanups to prepare the > ground, while the rest implement Atomic in 3 phases, as suggested by > Daniel's blog post[1]. > > Testing was done with the X server, igt, libdrm testsuit and some custom > code that I can share if requested. I hope this covers the main use > cases. Patches look good, great job. I'll go run some more tests and if all goes fine I'll push to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks
On Mon, 2017-02-27 at 17:25 +0100, Daniel Vetter wrote: > On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote: > > Disabling planes will consist of two steps as of the following patch. > > First, the DP is asked to stop at the next vblank, and then, after the > > vblank the associated IDMAC channel is idle and can be disabled. > > To avoid further commits being awoken out of their wait for dependencies > > too early, we should report commit_hw_done only after wait_for_vblanks. > > > > Signed-off-by: Philipp Zabel > > Reviewed-by: Lucas Stach > > --- > > drivers/gpu/drm/imx/imx-drm-core.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index f562cb7964b08..1ed120c181724 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct > > drm_atomic_state *state) > > > > drm_atomic_helper_commit_modeset_enables(dev, state); > > > > - drm_atomic_helper_commit_hw_done(state); > > - > > drm_atomic_helper_wait_for_vblanks(dev, state); > > > > + drm_atomic_helper_commit_hw_done(state); > > That gives you a pretty good chance of halfing your refresh rate for async > flips. At least if you're not super careful about things. Did you > double-check this? > -Daniel I'm not used to the terminology, does async flips just mean DRM_MODE_PAGE_FLIP_ASYNC? We can't support that at all, since the hardware can't flip during hblank. We are not allowed to touch or even look at the DMA channel parameter memory during the whole frame, unfortunately. With sync flips during vblank, which is the only thing we can support, the only place waiting for the hw_done completion is drm_atomic_helper_wait_for_dependencies, which goes on to wait for the same commit's flip_done completion right afterwards. That is completed by the same vblank IRQ that wait_for_vblanks is also waiting for. So to be completely correct, we could report hw_done before wait_for_vblanks only if there are no plane disables pending, and afterwards otherwise, but I don't think this should make a difference right now. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
On 02/24/2017 03:06 PM, Rob Herring wrote: > On Fri, Feb 24, 2017 at 2:18 AM, Yannick FERTRE wrote: >> >> >> On 02/21/2017 03:07 PM, Rob Herring wrote: >>> On Mon, Feb 20, 2017 at 5:01 AM, Yannick FERTRE >>> wrote: On 02/16/2017 03:34 AM, Rob Herring wrote: > On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote: >> Signed-off-by: Yannick Fertre >> --- >> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 >> +++ >> 1 file changed, 7 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> >> diff --git >> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> >> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> new file mode 100644 >> index 000..f59e3c4 >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt >> @@ -0,0 +1,7 @@ >> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel >> + >> +Required properties: >> +- compatible: should be "ampire,am-480272h3tmqw-t01h" > > No GPIO controls or power supply for this panel? > > Rob > Hi Rob, thank for your reply. There is no gpio or power supply control for this panel with the eval board stm429x9i. >>> >>> You need to describe what the panel has, not what you have control of >>> or not on a particular board. >> >> Yes, I don't have to describe control on a particular board. This >> binding contains few lines. This compatible is used by panel-simple to >> get only timings. Other staff like gpio or power-suypply is well managed >> by panel-simple itself. >> >> This binding is similar to these bindings & not required more details: > > Finding bad examples is not an argument. And yes, lots went in before > we started being more particular in reviews, but now I want to see > power supplies and control lines accurately described. Next week, > there may be additional requirements. > > This is no different than clock or interrupt bindings. We don't just > say "uses clock/interrupt binding" in binding docs. You have to > explicitly state how many clocks/interrupts and their order. > > >>-ampire,am-480272h3tmqw-t01h.txt,ampire,am800480r3tmqwa1h.txt, >>-auo,b080uan01.txt,auo,b101aw03.txt,auo,b101ean01.txt, >>-auo,b101xtn01.txt,auo,b116xw03.txt,auo,b133htn01.txt, >>-auo,b133xtn01.txt,auo,g133han01.txt,auo,g185han01.txt, >>-auo,t215hvn01.txt,avic,tm070ddh03.txt, >>-boe,tv080wum-nl0.txt,chunghwa,claa070wp03xg.txt, >>-chunghwa,claa101wa01a.txt,chunghwa,claa101wb03.txt, >>-edt,et057090dhu.txt,edt,et070080dh6.txt,edt,etm0700g0dh6.txt, >>-foxlink,fl500wvr00-a0t.txt,giantplus,gpg482739qs5.txt, >>-hannstar,hsd070pww1.txt,hannstar,hsd100pxn1.txt, >>-hit,tx23d38vm0caa.txt,innolux,at043tn24.txt, >>-innolux,at070tn92.txt,innolux,g101ice-l01.txt, >>-innolux,g121i1-l01.txt,innolux,g121x1-l03.txt, >>-innolux,n116bge.txt,innolux,n156bge-l21.txt, >>-innolux,zj070na-01p.txt,kyo,tcg121xglp.txt, >>-lg,lb070wv8.txt,lg,ld070wx3-sl01.txt,lg,lh500wx1-sd03.txt, >>-lg,lp079qx1-sp0v.txt, lg,lp097qx1-spa1.txt,lg,lp120up1.txt, >>-lg,lp129qe.txt, nec,nl4827hc19-05b.txt, >>-nvd,9128.txt,okaya,rs800480t-7x0gp.txt, >>-olimex,lcd-olinuxino-43-ts.txt,ontat,yx700wv03.txt, >>-ortustech,com43h4m85ulc.txt, panasonic,vvx10f004b00.txt, >>-qiaodian,qd43003c0-40.txt, >>-samsung,lsn122dl01-c01.txt,samsung,ltn101nt05.txt, >>-samsung,ltn140at29-301.txt,sharp,lq101k1ly04.txt, >>-sharp,lq123p1jx31.txt, >>-shelly,sca07010-bfn-lnn.txt,starry,kr122ea0sra.txt, >>-tpk,f07a-0102.txt,tpk,f10a-0102.txt,urt,umsh-8596md.txt >> >> Best regards >> >>> This binding is similar to all panel bindings which are link to panel simple. Details on gpio & power supply are describe with simple-panel binding. >>> >>> simple-panel.txt provides what possible standard properties there are, >>> not whether a panel uses them. The power supply needs to be explicit >>> because I don't know if you forgot and there's really 2 supplies or >>> you are using "power-supply" for a single supply. >>> >>> Rob >>> Hi Rob, ok, I'll push a V4 version with all details on properties. I write bellow a draft of binding: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel This binding is compatible with the simple-panel binding, which is specified in simple-panel.txt in this directory. Required properties: - compatible: should be "ampire,am-480272h3tmqw-t01h" Optional properties: - power-supply: regulator to provide the supply voltage - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - enable-gpios: GPIO pin to enable or disable the panel - backlight: phandle of the backlight device attached to the panel Optional nodes: - Video port for
[Bug 194731] drm general protection fault in drm_atomic_init
https://bugzilla.kernel.org/show_bug.cgi?id=194731 --- Comment #4 from Janpieter Sollie (janpieter.sol...@dommel.be) --- a workaround (and a very dirty one) for the amdgpu-pro driver is to comment, in line 410, this line: drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel); after that, the pro-module works fine, as I don't use a fb on headless cards ;) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic-helpers: Make nonblocking more resilient
We've switched to refcounting for the event completion, which means
there's no risk for use-after free anymore after:
commit 24835e442f289813aa568d142a755672a740503c
Author: Daniel Vetter
Date: Wed Dec 21 11:23:30 2016 +0100
drm: reference count event->completion
This should make the commit machinery a bit more resilient against
drivers bugs. It won't fix any driver bugs of course.
References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9203f3e933f7..f68181a92210 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1611,15 +1611,16 @@ void drm_atomic_helper_commit_cleanup_done(struct
drm_atomic_state *old_state)
spin_unlock(&crtc->commit_lock);
- /* We must wait for the vblank event to signal our completion
-* before releasing our reference, since the vblank work does
-* not hold a reference of its own. */
ret = wait_for_completion_timeout(&commit->flip_done,
10*HZ);
- if (ret == 0)
+ if (ret == 0) {
DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
crtc->base.id, crtc->name);
+ /* Unblock at least subsequent commits */
+ complete_all(&commit->flip_done);
+ }
+
spin_lock(&crtc->commit_lock);
del_commit:
list_del(&commit->commit_entry);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks
On Tue, Feb 28, 2017 at 10:59:54AM +0100, Philipp Zabel wrote: > On Mon, 2017-02-27 at 17:25 +0100, Daniel Vetter wrote: > > On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote: > > > Disabling planes will consist of two steps as of the following patch. > > > First, the DP is asked to stop at the next vblank, and then, after the > > > vblank the associated IDMAC channel is idle and can be disabled. > > > To avoid further commits being awoken out of their wait for dependencies > > > too early, we should report commit_hw_done only after wait_for_vblanks. > > > > > > Signed-off-by: Philipp Zabel > > > Reviewed-by: Lucas Stach > > > --- > > > drivers/gpu/drm/imx/imx-drm-core.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > index f562cb7964b08..1ed120c181724 100644 > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > @@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct > > > drm_atomic_state *state) > > > > > > drm_atomic_helper_commit_modeset_enables(dev, state); > > > > > > - drm_atomic_helper_commit_hw_done(state); > > > - > > > drm_atomic_helper_wait_for_vblanks(dev, state); > > > > > > + drm_atomic_helper_commit_hw_done(state); > > > > That gives you a pretty good chance of halfing your refresh rate for async > > flips. At least if you're not super careful about things. Did you > > double-check this? > > -Daniel > > I'm not used to the terminology, does async flips just mean > DRM_MODE_PAGE_FLIP_ASYNC? We can't support that at all, since the > hardware can't flip during hblank. We are not allowed to touch or even > look at the DMA channel parameter memory during the whole frame, > unfortunately. sorry, I mixed up async with nonblocking. I meant nonblocking. > With sync flips during vblank, which is the only thing we can support, > the only place waiting for the hw_done completion is > drm_atomic_helper_wait_for_dependencies, which goes on to wait for the > same commit's flip_done completion right afterwards. That is completed > by the same vblank IRQ that wait_for_vblanks is also waiting for. > > So to be completely correct, we could report hw_done before > wait_for_vblanks only if there are no plane disables pending, and > afterwards otherwise, but I don't think this should make a difference > right now. if it works, then it's all fine. Just wanted to raise here that this went wrong before ... The issue is that the _next_ update only waits for hw_done, not for the entire previous commit work item to complete. So there's a very real chance that the next nonblocking commit gets delayed, since you reduce the amount of interleaving they support. It mostly works, except when you get it wrong, or when you're unlucky about races. I think a better fix here would be to put the vblank wait into the disable function of your DP port, to make sure you only incur the vblank delay for the case that needs it, and not for the usual case of a stream of screen updates. hw_done means "I stopped touching the hw, the next thread can jump in", not "the hw is done touching stuff". Oh and if this is all unclear in the docs, pls submit a patch to clarify things more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helpers: Make nonblocking more resilient
On 28.02.2017 11:11, Daniel Vetter wrote: > We've switched to refcounting for the event completion, which means > there's no risk for use-after free anymore after: > > commit 24835e442f289813aa568d142a755672a740503c > Author: Daniel Vetter > Date: Wed Dec 21 11:23:30 2016 +0100 > > drm: reference count event->completion > > This should make the commit machinery a bit more resilient against > drivers bugs. It won't fix any driver bugs of course. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=96781 > Signed-off-by: Daniel Vetter Regarding problems described on the bug tracker - it could be a blind guess, but you can check if events are not canceled meanwhile, if for some reason event responsible for page-flip is canceled completion is not called. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format
On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format. Rockchip's vop support this video format(little
> endian only) as the input video format.
>
> P016 is a planar 4:2:0 YUV 12 bits per channel
>
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
>
> V3: Added P012 and fixed cpp for P010
> V4: format definition refined per review
> V5: Format comment block for each new pixel format
>
> Cc: Daniel Stone
> Cc: Ville Syrjälä
>
> Signed-off-by: Randy Li
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/drm_fourcc.c |4
> include/uapi/drm/drm_fourcc.h | 21 +
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 90d2cc8..5494764 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_UYVY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY,.depth = 0,
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV,.depth = 0,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> + /* FIXME a pixel in Y for P010 is 10 bits */
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> + { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ef20abb..306f979 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -128,6 +128,27 @@
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> /*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
> + */
Your Cb and Cr look swapped (unless my memory is playing tricks on me).
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cb:Cr plane 10 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
> + */
> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> subsampled Cb:Cr plane 12 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y little endian
> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
> + */
> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> subsampled Cb:Cr plane 16 bits per channel */
> +
> +/*
> * 3 plane YCbCr
> * index 0: Y plane, [7:0] Y
> * index 1: Cb plane, [7:0] Cb
> --
> 1.7.9.5
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/exynos/fimd: signal frame done interrupt at front porch
VBLANK interrupt should be signalled as soon as scanout ends, front porch is the best moment. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 638c775..0b74e57 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -256,7 +256,7 @@ static int fimd_enable_vblank(struct exynos_drm_crtc *crtc) val |= VIDINTCON0_INT_FRAME; val &= ~VIDINTCON0_FRAMESEL0_MASK; - val |= VIDINTCON0_FRAMESEL0_VSYNC; + val |= VIDINTCON0_FRAMESEL0_FRONTPORCH; val &= ~VIDINTCON0_FRAMESEL1_MASK; val |= VIDINTCON0_FRAMESEL1_NONE; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/exynos: kill pipe field from drivers contexts
Since possible_crtcs are set by Exynos core helper pipe fields have no
raison d'etre. The only place it was used, as a hack, is
fimd_clear_channels, to avoid calling drm_crtc_handle_vblank, but DRM core
has already other protection mechanism (vblank->enabled), so it could be
safely removed.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 4 +---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 15 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 2 --
5 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 80d8be0..4b596dc 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -64,7 +64,6 @@ struct decon_context {
void __iomem*addr;
struct regmap *sysreg;
struct clk *clks[ARRAY_SIZE(decon_clks_name)];
- int pipe;
unsigned long flags;
unsigned long out_type;
int first_win;
@@ -537,7 +536,6 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
for (win = ctx->first_win; win < WINDOWS_NR; win++) {
int tmp = (win == ctx->first_win) ? 0 : win;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 4320b3b..1ffb0b1 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -55,7 +55,6 @@ struct decon_context {
unsigned long irq_flags;
booli80_if;
boolsuspended;
- int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
@@ -131,7 +130,6 @@ static int decon_ctx_initialize(struct decon_context *ctx,
struct drm_device *drm_dev)
{
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
decon_clear_channels(ctx->crtc);
@@ -605,7 +603,7 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
writel(clear_bit, ctx->regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
goto out;
if (!ctx->i80_if) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 830a364..638c775 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -191,7 +191,6 @@ struct fimd_context {
u32 i80ifcon;
booli80_if;
boolsuspended;
- int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
atomic_twin_updated;
@@ -368,18 +367,13 @@ static void fimd_clear_channels(struct exynos_drm_crtc
*crtc)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- int pipe = ctx->pipe;
-
- /* ensure that vblank interrupt won't be reported to core */
ctx->suspended = false;
- ctx->pipe = -1;
fimd_enable_vblank(ctx->crtc);
fimd_wait_for_vblank(ctx->crtc);
fimd_disable_vblank(ctx->crtc);
ctx->suspended = true;
- ctx->pipe = pipe;
}
clk_disable_unprepare(ctx->lcd_clk);
@@ -913,7 +907,7 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
u32 trg_type = ctx->driver_data->trg_type;
/* Checks the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
return;
if (trg_type == I80_HW_TRG)
@@ -971,7 +965,7 @@ static irqreturn_t fimd_irq_handler(int irq, void *dev_id)
writel(clear_bit, ctx->regs + VIDINTCON1);
/* check the crtc is detached already from encoder */
- if (ctx->pipe < 0 || !ctx->drm_dev)
+ if (!ctx->drm_dev)
goto out;
if (!ctx->i80_if)
@@ -1001,7 +995,6 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
int ret;
ctx->drm_dev = drm_dev;
- ctx->pipe = drm_dev->mode_config.num_crtc;
for (i = 0; i < WINDOW
Re: [PATCH 2/3] drm: Convert drm_framebuffer_remove to atomic, v4.
On Thu, Feb 23, 2017 at 10:09:27AM -0500, Sean Paul wrote:
> On Tue, Feb 21, 2017 at 02:51:41PM +0100, Maarten Lankhorst wrote:
> > Instead of trying to do everything in 1 go, just do a basic safe
> > conversion first. We've been bitten by too many regressions in the
> > past.
> >
> > This patch only converts drm_framebuffer_remove to atomic. The
> > regression sensitive part is split out to a separate patch.
> >
> > v2:
> > - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
> > - Add WARN_ON when atomic_remove_fb fails.
> > - Always call drm_atomic_state_put.
> > v3:
> > - Use drm_drv_uses_atomic_modeset
> > - Handle the case where the first plane-disable-only commit fails
> > with -EINVAL. Some drivers do not support this, fall back to
> > disabling all crtc's in this case.
> > v4:
> > - Solve vmwgfx compatibility issue in their driver, was fixed in this
> > patch by v3.
> > - Move only disabling primary to a separate patch.
> >
>
> Reviewed-by: Sean Paul
Ok, merged the first 2 from this series to drm-misc-next.
Thanks, Daniel
>
> > Signed-off-by: Daniel Vetter
> > Signed-off-by: Daniel Vetter
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/drm_atomic.c| 88
> > +
> > drivers/gpu/drm/drm_crtc_internal.h | 1 +
> > drivers/gpu/drm/drm_framebuffer.c | 7 +++
> > 3 files changed, 96 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index afec53832145..285e1c23e8c9 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -2061,6 +2061,94 @@ static void complete_crtc_signaling(struct
> > drm_device *dev,
> > kfree(fence_state);
> > }
> >
> > +int drm_atomic_remove_fb(struct drm_framebuffer *fb)
> > +{
> > + struct drm_modeset_acquire_ctx ctx;
> > + struct drm_device *dev = fb->dev;
> > + struct drm_atomic_state *state;
> > + struct drm_plane *plane;
> > + struct drm_connector *conn;
> > + struct drm_connector_state *conn_state;
> > + int i, ret = 0;
> > + unsigned plane_mask;
> > +
> > + state = drm_atomic_state_alloc(dev);
> > + if (!state)
> > + return -ENOMEM;
> > +
> > + drm_modeset_acquire_init(&ctx, 0);
> > + state->acquire_ctx = &ctx;
> > +
> > +retry:
> > + plane_mask = 0;
> > + ret = drm_modeset_lock_all_ctx(dev, &ctx);
> > + if (ret)
> > + goto unlock;
> > +
> > + drm_for_each_plane(plane, dev) {
> > + struct drm_plane_state *plane_state;
> > +
> > + if (plane->state->fb != fb)
> > + continue;
> > +
> > + plane_state = drm_atomic_get_plane_state(state, plane);
> > + if (IS_ERR(plane_state)) {
> > + ret = PTR_ERR(plane_state);
> > + goto unlock;
> > + }
> > +
> > + if (plane_state->crtc->primary == plane) {
> > + struct drm_crtc_state *crtc_state;
> > +
> > + crtc_state = drm_atomic_get_existing_crtc_state(state,
> > plane_state->crtc);
> > +
> > + ret = drm_atomic_add_affected_connectors(state,
> > plane_state->crtc);
> > + if (ret)
> > + goto unlock;
> > +
> > + crtc_state->active = false;
> > + ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
> > + if (ret)
> > + goto unlock;
> > + }
> > +
> > + drm_atomic_set_fb_for_plane(plane_state, NULL);
> > + ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> > + if (ret)
> > + goto unlock;
> > +
> > + plane_mask |= BIT(drm_plane_index(plane));
> > +
> > + plane->old_fb = plane->fb;
> > + }
> > +
> > + for_each_connector_in_state(state, conn, conn_state, i) {
> > + ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
> > +
> > + if (ret)
> > + goto unlock;
> > + }
> > +
> > + if (plane_mask)
> > + ret = drm_atomic_commit(state);
> > +
> > +unlock:
> > + if (plane_mask)
> > + drm_atomic_clean_old_fb(dev, plane_mask, ret);
> > +
> > + if (ret == -EDEADLK) {
> > + drm_modeset_backoff(&ctx);
> > + goto retry;
> > + }
> > +
> > + drm_atomic_state_put(state);
> > +
> > + drm_modeset_drop_locks(&ctx);
> > + drm_modeset_acquire_fini(&ctx);
> > +
> > + return ret;
> > +}
> > +
> > int drm_mode_atomic_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv)
> > {
> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index 955c5690bf64..e0678f8a51cf 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -183,6 +183,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
> > struct drm_
[PATCH 1/3] drm/exynos: set plane possible_crtcs in exynos_plane_init
All Exynos planes are assigned to exactly one CRTC, it allows to simplify
initialization by moving setting of possible_crtcs to exynos_plane_init.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
7 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2cb7736..80d8be0 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -548,7 +548,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[win].type = decon_win_types[tmp];
ret = exynos_plane_init(drm_dev, &ctx->planes[win], win,
- 1 << ctx->pipe, &ctx->configs[win]);
+ &ctx->configs[win]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 206e779..4320b3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -642,7 +642,7 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[i].type = decon_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &ctx->configs[i]);
+ &ctx->configs[i]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index df4dc34..830a364 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1009,7 +1009,7 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
ctx->configs[i].zpos = i;
ctx->configs[i].type = fimd_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &ctx->configs[i]);
+ &ctx->configs[i]);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index c2f17f3..611b6fd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -273,14 +273,13 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
}
int exynos_plane_init(struct drm_device *dev,
- struct exynos_drm_plane *exynos_plane,
- unsigned int index, unsigned long possible_crtcs,
+ struct exynos_drm_plane *exynos_plane, unsigned int index,
const struct exynos_drm_plane_config *config)
{
int err;
err = drm_universal_plane_init(dev, &exynos_plane->base,
- possible_crtcs,
+ 1 << dev->mode_config.num_crtc,
&exynos_plane_funcs,
config->pixel_formats,
config->num_pixel_formats,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.h
b/drivers/gpu/drm/exynos/exynos_drm_plane.h
index 9aafad1..497047b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.h
@@ -11,5 +11,4 @@
int exynos_plane_init(struct drm_device *dev,
struct exynos_drm_plane *exynos_plane, unsigned int index,
- unsigned long possible_crtcs,
const struct exynos_drm_plane_config *config);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index cb5e3c6..8860ff4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -408,7 +408,7 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
plane_config.type = vidi_win_types[i];
ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
- 1 << ctx->pipe, &plane_config);
+ &plane_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 1474982..3722b5f 100644
--- a/drivers/gpu/drm/exy
[maintainers-tools] dim: Clarify how to proceed when adding drm-xxx remotes
Some people are specifying the username directly in the url with the following syntax: ssh://@git.freedesktop.org/git/, but dim expects something like ssh://git.freedesktop.org/git/. Update the documentation to document how to assign a default username when connecting to git.freedesktop.org through SSH. Signed-off-by: Boris Brezillon --- dim.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/dim.rst b/dim.rst index 911b4666b4aa..bbb1d15a6d4b 100644 --- a/dim.rst +++ b/dim.rst @@ -54,6 +54,13 @@ This will also check out the latest maintainer-tools branches, so please replace the dim you just downloaded with a symlink after this step. And by the way, if you have improvements for dim, please submit them to intel-gfx. +If you have a freedesktop.org account and plan to push things on one of the +drm-xxx repos, you should use the ssh://git.freedesktop.org/git/drm-xxx urls +when adding a remote and, if it's not already done, you should add new entry in +~/.ssh/config: + +$ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config + You should now have a main repository for patch application. The directory corresponding to this repository is defined by DIM_DRM_INTEL in your .dimrc. You should also have directories called maintainer-tools, drm-tip (for -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] uapi: fix drm/omap_drm.h userspace compilation errors
Hi,
On 25/02/17 15:29, Dmitry V. Levin wrote:
> Consistently use types from linux/types.h like in other uapi drm/*_drm.h
> header files to fix the following drm/omap_drm.h userspace compilation
> errors:
>
> /usr/include/drm/omap_drm.h:36:2: error: unknown type name 'uint64_t'
> uint64_t param; /* in */
> /usr/include/drm/omap_drm.h:37:2: error: unknown type name 'uint64_t'
> uint64_t value; /* in (set_param), out (get_param) */
> /usr/include/drm/omap_drm.h:56:2: error: unknown type name 'uint32_t'
> uint32_t bytes; /* (for non-tiled formats) */
> /usr/include/drm/omap_drm.h:58:3: error: unknown type name 'uint16_t'
>uint16_t width;
> /usr/include/drm/omap_drm.h:59:3: error: unknown type name 'uint16_t'
>uint16_t height;
> /usr/include/drm/omap_drm.h:65:2: error: unknown type name 'uint32_t'
> uint32_t flags; /* in */
> /usr/include/drm/omap_drm.h:66:2: error: unknown type name 'uint32_t'
> uint32_t handle; /* out */
> /usr/include/drm/omap_drm.h:67:2: error: unknown type name 'uint32_t'
> uint32_t __pad;
> /usr/include/drm/omap_drm.h:77:2: error: unknown type name 'uint32_t'
> uint32_t handle; /* buffer handle (in) */
> /usr/include/drm/omap_drm.h:78:2: error: unknown type name 'uint32_t'
> uint32_t op; /* mask of omap_gem_op (in) */
> /usr/include/drm/omap_drm.h:82:2: error: unknown type name 'uint32_t'
> uint32_t handle; /* buffer handle (in) */
> /usr/include/drm/omap_drm.h:83:2: error: unknown type name 'uint32_t'
> uint32_t op; /* mask of omap_gem_op (in) */
> /usr/include/drm/omap_drm.h:88:2: error: unknown type name 'uint32_t'
> uint32_t nregions;
> /usr/include/drm/omap_drm.h:89:2: error: unknown type name 'uint32_t'
> uint32_t __pad;
> /usr/include/drm/omap_drm.h:93:2: error: unknown type name 'uint32_t'
> uint32_t handle; /* buffer handle (in) */
> /usr/include/drm/omap_drm.h:94:2: error: unknown type name 'uint32_t'
> uint32_t pad;
> /usr/include/drm/omap_drm.h:95:2: error: unknown type name 'uint64_t'
> uint64_t offset; /* mmap offset (out) */
> /usr/include/drm/omap_drm.h:102:2: error: unknown type name 'uint32_t'
> uint32_t size; /* virtual size for mmap'ing (out) */
> /usr/include/drm/omap_drm.h:103:2: error: unknown type name 'uint32_t'
> uint32_t __pad;
>
> Fixes: ef6503e89194 ("drm: Kbuild: add omap_drm.h to the installed headers")
> Signed-off-by: Dmitry V. Levin
> ---
> include/uapi/drm/omap_drm.h | 38 +++---
> 1 file changed, 19 insertions(+), 19 deletions(-)
Thanks! I'll queue to fixes.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [maintainers-tools] dim: Clarify how to proceed when adding drm-xxx remotes
Hi, On 28 February 2017 at 12:36, Boris Brezillon wrote: > @@ -54,6 +54,13 @@ This will also check out the latest maintainer-tools > branches, so please replace > the dim you just downloaded with a symlink after this step. And by the way, > if > you have improvements for dim, please submit them to intel-gfx. > > +If you have a freedesktop.org account and plan to push things on one of the > +drm-xxx repos, you should use the ssh://git.freedesktop.org/git/drm-xxx urls > +when adding a remote and, if it's not already done, you should add new entry > in > +~/.ssh/config: > + > +$ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config > + Bikeshed time: You should always use the ssh://git.freedesktop.org/git/drm-xxx URLs for your git remote entries. If you need to specify a username, rather than specifying it in the remote URL, you can modify ~/.ssh/config: $ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config with that, it's: Reviewed-by: Daniel Stone Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] gpu: drm: Convert printk(KERN_ to pr_
Broken up for Daniel Vetter Joe Perches (3): gpu: drm: amd/radeon: Convert printk(KERN_ to pr_ gpu: drm: core: Convert printk(KERN_ to pr_ gpu: drm: drivers: Convert printk(KERN_ to pr_ drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +- drivers/gpu/drm/amd/amdgpu/atom.c | 44 - drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 4 +- drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 +- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 +- drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 +- drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 +- drivers/gpu/drm/amd/include/amd_pcie_helpers.h | 4 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 2 +- drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c| 4 +- drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++--- .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 +- drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 +- drivers/gpu/drm/drm_cache.c| 12 ++--- drivers/gpu/drm/drm_edid.c | 4 +- drivers/gpu/drm/drm_ioc32.c| 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 9 ++-- drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++ drivers/gpu/drm/gma500/psb_drv.h | 5 +- drivers/gpu/drm/gma500/psb_intel_lvds.c| 7 ++- drivers/gpu/drm/i915/i915_sw_fence.c | 8 ++-- drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 2 +- drivers/gpu/drm/nouveau/nouveau_acpi.c | 7 +-- drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +- drivers/gpu/drm/nouveau/nv50_display.c | 22 - drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++-- drivers/gpu/drm/omapdrm/dss/dsi.c | 17 --- drivers/gpu/drm/omapdrm/dss/dss.c | 3 +- drivers/gpu/drm/omapdrm/dss/dss.h | 15 +++--- drivers/gpu/drm/omapdrm/omap_gem.c | 5 +- drivers/gpu/drm/r128/r128_cce.c| 7 ++- drivers/gpu/drm/radeon/atom.c | 46 -- drivers/gpu/drm/radeon/cik.c | 56 -- drivers/gpu/drm/radeon/evergreen.c | 2 +- drivers/gpu/drm/radeon/evergreen_cs.c | 7 ++- drivers/gpu/drm/radeon/ni.c| 22 +++-- drivers/gpu/drm/radeon/r100.c | 18 +++ drivers/gpu/drm/radeon/r200.c | 3 +- drivers/gpu/drm/radeon/r300.c | 13 ++--- drivers/gpu/drm/radeon/r420.c | 9 ++-- drivers/gpu/drm/radeon/r520.c | 3 +- drivers/gpu/drm/radeon/r600.c | 21 +++- drivers/gpu/drm/radeon/r600_cs.c | 7 ++- drivers/gpu/drm/radeon/radeon.h| 3 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 4 +- drivers/gpu/drm/radeon/radeon_audio.c | 4 +- drivers/gpu/drm/radeon/radeon_clocks.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 8 ++-- drivers/gpu/drm/radeon/radeon_fb.c | 3 +- drivers/gpu/drm/radeon/radeon_gem.c| 4 +- drivers/gpu/drm/radeon/radeon_test.c | 6 +-- drivers/gpu/drm/radeon/rs400.c | 4 +- drivers/gpu/drm/radeon/rs690.c | 3 +- drivers/gpu/drm/radeon/rv515.c | 9 ++-- drivers/gpu/drm/radeon/si.c| 45 ++--- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 +-- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +- 69 files changed, 253 insertions(+), 362 deletions(-) -- 2.10.0.rc2.1.g053435c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] gpu: drm: amd/radeon: Convert printk(KERN_ to pr_
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +-
drivers/gpu/drm/amd/amdgpu/atom.c | 44 -
drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 4 +-
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 +-
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 +-
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 +-
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ++--
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 +-
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 +-
drivers/gpu/drm/amd/include/amd_pcie_helpers.h | 4 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 2 +-
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c| 4 +-
drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
.../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 +-
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 +-
drivers/gpu/drm/radeon/atom.c | 46 --
drivers/gpu/drm/radeon/cik.c | 56 --
drivers/gpu/drm/radeon/evergreen.c | 2 +-
drivers/gpu/drm/radeon/evergreen_cs.c | 7 ++-
drivers/gpu/drm/radeon/ni.c| 22 +++--
drivers/gpu/drm/radeon/r100.c | 18 +++
drivers/gpu/drm/radeon/r200.c | 3 +-
drivers/gpu/drm/radeon/r300.c | 13 ++---
drivers/gpu/drm/radeon/r420.c | 9 ++--
drivers/gpu/drm/radeon/r520.c | 3 +-
drivers/gpu/drm/radeon/r600.c | 21 +++-
drivers/gpu/drm/radeon/r600_cs.c | 7 ++-
drivers/gpu/drm/radeon/radeon.h| 3 +-
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 4 +-
drivers/gpu/drm/radeon/radeon_audio.c | 4 +-
drivers/gpu/drm/radeon/radeon_clocks.c | 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 8 ++--
drivers/gpu/drm/radeon/radeon_fb.c | 3 +-
drivers/gpu/drm/radeon/radeon_gem.c| 4 +-
drivers/gpu/drm/radeon/radeon_test.c | 6 +--
drivers/gpu/drm/radeon/rs400.c | 4 +-
drivers/gpu/drm/radeon/rs690.c | 3 +-
drivers/gpu/drm/radeon/rv515.c | 9 ++--
drivers/gpu/drm/radeon/si.c| 45 ++---
46 files changed, 172 insertions(+), 268 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b913541739..3f636632c289 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1515,7 +1515,8 @@ void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32
index, u32 v);
*/
#define RREG32(reg) amdgpu_mm_rreg(adev, (reg), false)
#define RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), true)
-#define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 0x%08X\n",
amdgpu_mm_rreg(adev, (reg), false))
+#define DREG32(reg) pr_info("REGISTER: " #reg " : 0x%08X\n", \
+ amdgpu_mm_rreg(adev, (reg), false))
#define WREG32(reg, v) amdgpu_mm_wreg(adev, (reg), (v), false)
#define WREG32_IDX(reg, v) amdgpu_mm_wreg(adev, (reg), (v), true)
#define REG_SET(FIELD, v) (((v) << FIELD##_SHIFT) & FIELD##_MASK)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
index 857ba0897159..3889486f71fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c
@@ -74,9 +74,9 @@ static void amdgpu_afmt_calc_cts(uint32_t clock, int *CTS,
int *N, int freq)
/* Check that we are in spec (not always possible) */
if (n < (128*freq/1500))
- printk(KERN_WARNING "Calculated ACR N value is too small. You
may experience audio problems.\n");
+ pr_warn("Calculated ACR N value is too small. You may
experience audio problems.\n");
if (n > (128*freq/300))
- printk(KERN_WARNING "Calculated ACR N value is too large. You
may experience audio problems.\n");
+ pr_warn("Calculated ACR N value is too large. You may
experience audio problems.\n");
*N = n;
*CTS = cts;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index
[PATCH 2/3] gpu: drm: core: Convert printk(KERN_ to pr_
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_cache.c | 12 ++--
drivers/gpu/drm/drm_edid.c | 4 ++--
drivers/gpu/drm/drm_ioc32.c | 3 +--
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index c3b9aaccdf42..3bd76e918b5d 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -88,7 +88,7 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
}
if (wbinvd_on_all_cpus())
- printk(KERN_ERR "Timed out waiting for cache flush.\n");
+ pr_err("Timed out waiting for cache flush\n");
#elif defined(__powerpc__)
unsigned long i;
@@ -105,7 +105,7 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
kunmap_atomic(page_virtual);
}
#else
- printk(KERN_ERR "Architecture has no drm_cache.c support\n");
+ pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
#endif
}
@@ -134,9 +134,9 @@ drm_clflush_sg(struct sg_table *st)
}
if (wbinvd_on_all_cpus())
- printk(KERN_ERR "Timed out waiting for cache flush.\n");
+ pr_err("Timed out waiting for cache flush\n");
#else
- printk(KERN_ERR "Architecture has no drm_cache.c support\n");
+ pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
#endif
}
@@ -167,9 +167,9 @@ drm_clflush_virt_range(void *addr, unsigned long length)
}
if (wbinvd_on_all_cpus())
- printk(KERN_ERR "Timed out waiting for cache flush.\n");
+ pr_err("Timed out waiting for cache flush\n");
#else
- printk(KERN_ERR "Architecture has no drm_cache.c support\n");
+ pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
#endif
}
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c8baab9bee0d..ca4f054f71b2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1164,9 +1164,9 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid,
bad:
if (print_bad_edid) {
if (drm_edid_is_zero(raw_edid, EDID_LENGTH)) {
- printk(KERN_ERR "EDID block is all zeroes\n");
+ pr_err("EDID block is all zeroes\n");
} else {
- printk(KERN_ERR "Raw EDID:\n");
+ pr_err("Raw EDID:\n");
print_hex_dump(KERN_ERR, " \t", DUMP_PREFIX_NONE, 16, 1,
raw_edid, EDID_LENGTH, false);
}
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 867ab8c1582b..b134482f4022 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -257,8 +257,7 @@ static int compat_drm_addmap(struct file *file, unsigned
int cmd,
m32.handle = (unsigned long)handle;
if (m32.handle != (unsigned long)handle)
- printk_ratelimited(KERN_ERR "compat_drm_addmap truncated handle"
- " %p for type %d offset %x\n",
+ pr_err_ratelimited("compat_drm_addmap truncated handle %p for
type %d offset %x\n",
handle, m32.type, m32.offset);
if (copy_to_user(argp, &m32, sizeof(m32)))
--
2.10.0.rc2.1.g053435c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_
Use a more common logging style.
Miscellanea:
o Coalesce formats and realign arguments
o Neaten a few macros now using pr_
Signed-off-by: Joe Perches
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 -
drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
drivers/gpu/drm/gma500/psb_drv.h | 5 ++---
drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +++
drivers/gpu/drm/i915/i915_sw_fence.c | 8
drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +-
drivers/gpu/drm/msm/msm_drv.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_acpi.c| 7 ---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
drivers/gpu/drm/omapdrm/dss/dss.c | 3 +--
drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
drivers/gpu/drm/omapdrm/omap_gem.c| 5 ++---
drivers/gpu/drm/r128/r128_cce.c | 7 +++
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
20 files changed, 72 insertions(+), 84 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 5efdb7fbb7ee..e64960db3224 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder
*encoder,
head) {
if (tmp_encoder != encoder
&& tmp_encoder->crtc == encoder->crtc) {
- printk(KERN_ERR "Can't enable LVDS and another "
- "encoder on the same pipe\n");
+ pr_err("Can't enable LVDS and another encoder on the
same pipe\n");
return false;
}
}
@@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
failed_find:
mutex_unlock(&dev->mode_config.mutex);
- printk(KERN_ERR "Failed find\n");
+ pr_err("Failed find\n");
psb_intel_i2c_destroy(gma_encoder->ddc_bus);
failed_ddc:
- printk(KERN_ERR "Failed DDC\n");
+ pr_err("Failed DDC\n");
psb_intel_i2c_destroy(gma_encoder->i2c_bus);
failed_blc_i2c:
- printk(KERN_ERR "Failed BLC\n");
+ pr_err("Failed BLC\n");
drm_encoder_cleanup(encoder);
drm_connector_cleanup(connector);
kfree(lvds_priv);
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index f7038f12ac76..e6943fef0611 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct
drm_device *dev,
((ti->vblank_hi << 8) | ti->vblank_lo);
mode->clock = ti->pixel_clock * 10;
#if 0
- printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
- printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
- printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
- printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
- printk(KERN_INFO "htotal is %d\n", mode->htotal);
- printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
- printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
- printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
- printk(KERN_INFO "clock is %d\n", mode->clock);
+ pr_info("hdisplay is %d\n", mode->hdisplay);
+ pr_info("vdisplay is %d\n", mode->vdisplay);
+ pr_info("HSS is %d\n", mode->hsync_start);
+ pr_info("HSE is %d\n", mode->hsync_end);
+ pr_info("htotal is %d\n", mode->htotal);
+ pr_info("VSS is %d\n", mode->vsync_start);
+ pr_info("VSE is %d\n", mode->vsync_end);
+ pr_info("vtotal is %d\n", mode->vtotal);
+ pr_info("clock is %d\n", mode->clock);
#endif
mode_dev->panel_fixed_mode = mode;
}
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 83e22fd4cfc0..83667087d6e5 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -905,9 +905,8 @@ static inline void REGISTER_WRITE8(struct drm_device *dev,
#define PSB_RSGX32(_offs) \
({ \
if (inl(dev_priv->apm_base + PSB_APM_STS) & 0x3) { \
- printk(KERN_ERR \
-
[PATCH v2 04/10] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier to follow the init sequence / compare it to the spec
2) It is grouped with the pll disable call in intel_dsi_post_disable,
so for consistency it should be grouped with the pll enable in
intel_dsi_pre_enable
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index aee1f2e..04fd01d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -620,14 +620,6 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
}
- intel_dsi_prepare(encoder, pipe_config);
-
- /* Power on, try both CRC pmic gpio and VBT */
- if (intel_dsi->gpio_panel)
- gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
- msleep(intel_dsi->panel_on_delay);
-
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
u32 val;
@@ -637,6 +629,14 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
I915_WRITE(DSPCLK_GATE_D, val);
}
+ intel_dsi_prepare(encoder, pipe_config);
+
+ /* Power on, try both CRC pmic gpio and VBT */
+ if (intel_dsi->gpio_panel)
+ gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
+ msleep(intel_dsi->panel_on_delay);
+
/* put device in ready state */
intel_dsi_device_ready(encoder);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/10] drm/i915/dsi: Document the panel enable / disable sequences from the spec
Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec. Signed-off-by: Hans de Goede Acked-by: Jani Nikula --- Changes in v2: -Make the comment a table with 3 columns for easier comparison of the 3 sequences --- drivers/gpu/drm/i915/intel_dsi.c | 37 + 1 file changed, 37 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 20ed799..c271475 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -554,6 +554,43 @@ static void intel_dsi_prepare(struct intel_encoder *intel_encoder, struct intel_crtc_state *pipe_config); static void intel_dsi_unprepare(struct intel_encoder *encoder); +/* + * Panel enable/disable sequences from the VBT spec. + * + * Note the spec has AssertReset / DeassertReset swapped from their + * usual naming. We use the normal names to avoid confusion (so below + * they are swapped compared to the spec). + * + * Steps starting with MIPI refer to VBT sequences, note that for v2 + * VBTs several steps which have a VBT in v2 are expected to be handled + * directly by the driver, by directly driving gpios for example. + * + * v2 video mode seq v3 video mode seq command mode seq + * - power on- MIPIPanelPowerOn- power on + * - wait t1+t2- wait t1+t2 + * - MIPIDeassertResetPin- MIPIDeassertResetPin- MIPIDeassertResetPin + * - io lines to lp-11 - io lines to lp-11 - io lines to lp-11 + * - MIPISendInitialDcsCmds - MIPISendInitialDcsCmds - MIPISendInitialDcsCmds + * - MIPITearOn + * - MIPIDisplayOn + * - turn on DPI - turn on DPI - set pipe to dsr mode + * - MIPIDisplayOn - MIPIDisplayOn + * - wait t5 - wait t5 + * - backlight on- MIPIBacklightOn - backlight on + * ... ... ... issue mem cmds ... + * - backlight off - MIPIBacklightOff- backlight off + * - wait t6 - wait t6 + * - MIPIDisplayOff + * - turn off DPI- turn off DPI- disable pipe dsr mode + * - MIPITearOff + * - MIPIDisplayOff - MIPIDisplayOff + * - io lines to lp-00 - io lines to lp-00 - io lines to lp-00 + * - MIPIAssertResetPin - MIPIAssertResetPin - MIPIAssertResetPin + * - wait t3 - wait t3 + * - power off - MIPIPanelPowerOff - power off + * - wait t4 - wait t4 + */ + static void intel_dsi_pre_enable(struct intel_encoder *encoder, struct intel_crtc_state *pipe_config, struct drm_connector_state *conn_state) -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/10] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b460c5c..aee1f2e 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -622,10 +622,10 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
intel_dsi_prepare(encoder, pipe_config);
- /* Panel Enable over CRC PMIC */
+ /* Power on, try both CRC pmic gpio and VBT */
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
-
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
msleep(intel_dsi->panel_on_delay);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
@@ -640,7 +640,6 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
/* put device in ready state */
intel_dsi_device_ready(encoder);
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
@@ -758,11 +757,10 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
}
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
+ /* Power off, try both CRC pmic gpio and VBT */
msleep(intel_dsi->panel_off_delay);
-
- /* Panel Disable over CRC PMIC */
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/10] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Slightly change added comment wording
---
drivers/gpu/drm/i915/intel_dsi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 2dd276a..b9727a0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -701,6 +701,11 @@ static void intel_dsi_pre_disable(struct intel_encoder
*encoder,
I915_WRITE(MIPI_DEVICE_READY(port), 0);
}
+ /*
+* According to the spec we should send SHUTDOWN before
+* MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but field testing
+* has shown that the v3 sequence works for v2 VBTs too
+*/
if (is_vid_mode(intel_dsi)) {
/* Send Shutdown command to the panel in LP mode */
for_each_dsi_port(port, intel_dsi->ports)
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/10] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET, will always be called at some point before intel_dsi_pre_enable() making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant. In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes against the VBT spec. Signed-off-by: Hans de Goede --- Changes in v2: -Reword commit msg --- drivers/gpu/drm/i915/intel_dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index c271475..b460c5c 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -640,7 +640,6 @@ static void intel_dsi_pre_enable(struct intel_encoder *encoder, /* put device in ready state */ intel_dsi_device_ready(encoder); - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/10] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
Changes in v2:
-Drop meaningless code-comments
---
drivers/gpu/drm/i915/intel_dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b7b8c6d..2dd276a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -658,12 +658,12 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
msleep(100);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
intel_dsi_port_enable(encoder);
}
intel_panel_enable_backlight(intel_dsi->attached_connector);
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
}
static void intel_dsi_enable_nop(struct intel_encoder *encoder,
@@ -689,6 +689,7 @@ static void intel_dsi_pre_disable(struct intel_encoder
*encoder,
DRM_DEBUG_KMS("\n");
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_panel_disable_backlight(intel_dsi->attached_connector);
/*
@@ -733,7 +734,6 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
* if disable packets are sent before sending shutdown packet then in
* some next enable sequence send turn on packet error is observed
*/
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
/* Transition to LP-00 */
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/10] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop. Signed-off-by: Hans de Goede --- Changes in v2: -Only call MIPI_SEQ_TEAR_OFF in cmd mode --- drivers/gpu/drm/i915/intel_dsi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index b9727a0..d316c24 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -739,6 +739,8 @@ static void intel_dsi_post_disable(struct intel_encoder *encoder, * if disable packets are sent before sending shutdown packet then in * some next enable sequence send turn on packet error is observed */ + if (is_cmd_mode(intel_dsi)) + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF); intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF); /* Transition to LP-00 */ -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/10] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 04fd01d..b7b8c6d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -637,10 +637,13 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
msleep(intel_dsi->panel_on_delay);
- /* put device in ready state */
+ /* Deassert reset */
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+
+ /* Put device in ready state (LP-11) */
intel_dsi_device_ready(encoder);
- intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
+ /* Send initialization commands in LP mode */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);
/* Enable port in pre-enable phase itself because as per hw team
@@ -733,6 +736,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
+ /* Transition to LP-00 */
intel_dsi_clear_device_ready(encoder);
if (IS_BROXTON(dev_priv)) {
@@ -756,6 +760,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
I915_WRITE(DSPCLK_GATE_D, val);
}
+ /* Assert reset */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
/* Power off, try both CRC pmic gpio and VBT */
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/10] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 95e0ff1..68c8aa0 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -554,6 +554,17 @@ static void intel_dsi_prepare(struct intel_encoder
*intel_encoder,
struct intel_crtc_state *pipe_config);
static void intel_dsi_unprepare(struct intel_encoder *encoder);
+static void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
+{
+ struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
+
+ /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
+ if (is_vid_mode(intel_dsi) && dev_priv->vbt.dsi.seq_version >= 3)
+ return;
+
+ msleep(msec);
+}
+
/*
* Panel enable/disable sequences from the VBT spec.
*
@@ -635,7 +646,7 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
- msleep(intel_dsi->panel_on_delay);
+ intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
/* Deassert reset */
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
@@ -657,7 +668,7 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
msleep(20); /* XXX */
for_each_dsi_port(port, intel_dsi->ports)
dpi_send_cmd(intel_dsi, TURN_ON, false, port);
- msleep(100);
+ intel_dsi_msleep(intel_dsi, 100);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
@@ -773,7 +784,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
/* Power off, try both CRC pmic gpio and VBT */
- msleep(intel_dsi->panel_off_delay);
+ intel_dsi_msleep(intel_dsi, intel_dsi->panel_off_delay);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
if (intel_dsi->gpio_panel)
gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
@@ -782,7 +793,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
* FIXME As we do with eDP, just make a note of the time here
* and perform the wait before the next panel power on.
*/
- msleep(intel_dsi->panel_pwr_cycle_delay);
+ intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
}
static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/10] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede
Reviewed-by: Bob Paauwe
---
drivers/gpu/drm/i915/intel_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index d316c24..95e0ff1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -651,6 +651,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
if (is_cmd_mode(intel_dsi)) {
for_each_dsi_port(port, intel_dsi->ports)
I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(port), 8 * 4);
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_ON);
+ intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
} else {
msleep(20); /* XXX */
for_each_dsi_port(port, intel_dsi->ports)
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ABI navigator for libdrm
27.02.2017, 15:30, "Rob Clark":> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko:>> 26.02.2017, 22:15, "Daniel Vetter":>>> On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko: Hello, I'd like to present the ABI Navigator project to search for binary symbols (functions, global data, etc.) across recent versions of the libdrm and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library some symbol is defined, added, removed or changed. The data is taken from the ABI Tracker report for the library: https://abi-laboratory.pro/tracker/timeline/libdrm/ Example for symbol drmGetDevice from libdrm.so: https://abi-laboratory.pro/index.php?view=navigator&selected=drmGetDevice The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the reports in the ABI Tracker. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to import by your code? Try to find it in the ABI Navigator!>> Looks pretty cool. One small suggestion for the UI: Adding separate>>> columns for object/struct changes would be good. Atm it's harder to>>> find these, and e.g. libdrm has a releases with 100% abi compat>>> rating, but still yellow box. The yellow box is because we extended>>> some structs - direct links to those sections would be nice too. Added the "Total Changes" column to the report table: https://abi-laboratory.pro/tracker/timeline/libdrm/>> Cool>> Any chance you could add to configure line: --enable-freedreno> --enable-vc4 and possibly --etnaviv-experimental-api>> It should be possible to compile test and check abi for the libdrm> modules for arm drivers (but by default they are only enabled for arm> builds)> Done: https://abi-laboratory.pro/tracker/timeline/libdrm/ Thank you.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/imx: call drm_atomic_helper_commit_hw_done after drm_atomic_helper_wait_for_vblanks
On Tue, 2017-02-28 at 12:45 +0100, Daniel Vetter wrote: > On Tue, Feb 28, 2017 at 10:59:54AM +0100, Philipp Zabel wrote: > > On Mon, 2017-02-27 at 17:25 +0100, Daniel Vetter wrote: > > > On Mon, Feb 27, 2017 at 02:14:57PM +0100, Philipp Zabel wrote: > > > > Disabling planes will consist of two steps as of the following patch. > > > > First, the DP is asked to stop at the next vblank, and then, after the > > > > vblank the associated IDMAC channel is idle and can be disabled. > > > > To avoid further commits being awoken out of their wait for dependencies > > > > too early, we should report commit_hw_done only after wait_for_vblanks. > > > > > > > > Signed-off-by: Philipp Zabel > > > > Reviewed-by: Lucas Stach > > > > --- > > > > drivers/gpu/drm/imx/imx-drm-core.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > > index f562cb7964b08..1ed120c181724 100644 > > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > > @@ -169,10 +169,10 @@ static void imx_drm_atomic_commit_tail(struct > > > > drm_atomic_state *state) > > > > > > > > drm_atomic_helper_commit_modeset_enables(dev, state); > > > > > > > > - drm_atomic_helper_commit_hw_done(state); > > > > - > > > > drm_atomic_helper_wait_for_vblanks(dev, state); > > > > > > > > + drm_atomic_helper_commit_hw_done(state); > > > > > > That gives you a pretty good chance of halfing your refresh rate for async > > > flips. At least if you're not super careful about things. Did you > > > double-check this? > > > -Daniel > > > > I'm not used to the terminology, does async flips just mean > > DRM_MODE_PAGE_FLIP_ASYNC? We can't support that at all, since the > > hardware can't flip during hblank. We are not allowed to touch or even > > look at the DMA channel parameter memory during the whole frame, > > unfortunately. > > sorry, I mixed up async with nonblocking. I meant nonblocking. Oh, ok. > > With sync flips during vblank, which is the only thing we can support, > > the only place waiting for the hw_done completion is > > drm_atomic_helper_wait_for_dependencies, which goes on to wait for the > > same commit's flip_done completion right afterwards. That is completed > > by the same vblank IRQ that wait_for_vblanks is also waiting for. > > > > So to be completely correct, we could report hw_done before > > wait_for_vblanks only if there are no plane disables pending, and > > afterwards otherwise, but I don't think this should make a difference > > right now. > > if it works, then it's all fine. Just wanted to raise here that this went > wrong before ... The issue is that the _next_ update only waits for > hw_done, not for the entire previous commit work item to complete. So > there's a very real chance that the next nonblocking commit gets delayed, > since you reduce the amount of interleaving they support. It mostly works, > except when you get it wrong, or when you're unlucky about races. I appreciate the hint. We should remove the wait_for_vblanks and cleanup_planes calls from the commit_tail completely if no plane is currently being disabled, as there is no cleanup_fb for CMA based planes anyway. > I think a better fix here would be to put the vblank wait into the disable > function of your DP port, to make sure you only incur the vblank delay for > the case that needs it, and not for the usual case of a stream of screen > updates. Sorry for being unclear, DP in this context doesn't mean DisplayPort, it's just a part of the display pipeline between DMA controller and display controller that handles colorspace conversion and compositing. It just happens to be called "display processor". > hw_done means "I stopped touching the hw, the next thread can > jump in", not "the hw is done touching stuff". > > Oh and if this is all unclear in the docs, pls submit a patch to clarify > things more. Yes, that much is clear. We really have to tell the overlay plane to please stop at the next vblank, then wait for the vblank, and only then touch the stopped hardware to finalize disabling the plane. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [maintainers-tools] dim: Clarify how to proceed when adding drm-xxx remotes
On Tue, Feb 28, 2017 at 12:50:57PM +, Daniel Stone wrote: > Hi, > > On 28 February 2017 at 12:36, Boris Brezillon > wrote: > > @@ -54,6 +54,13 @@ This will also check out the latest maintainer-tools > > branches, so please replace > > the dim you just downloaded with a symlink after this step. And by the > > way, if > > you have improvements for dim, please submit them to intel-gfx. > > > > +If you have a freedesktop.org account and plan to push things on one of the > > +drm-xxx repos, you should use the ssh://git.freedesktop.org/git/drm-xxx > > urls > > +when adding a remote and, if it's not already done, you should add new > > entry in > > +~/.ssh/config: > > + > > +$ printf '\nHost git.freedesktop.org\n\tUser ' >> > > ~/.ssh/config > > + > > Bikeshed time: > > You should always use the ssh://git.freedesktop.org/git/drm-xxx URLs for your > git remote entries. If you need to specify a username, rather than specifying > it > in the remote URL, you can modify ~/.ssh/config: I also converted to :: for the markup. > > $ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config > > with that, it's: > Reviewed-by: Daniel Stone Applied, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 00/14] QXL atomic modesetting
On Mo, 2017-02-27 at 17:43 -0300, Gabriel Krisman Bertazi wrote: > Hi, > > This is a resend of the qxl atomic modesetting patchset to include the > reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next. > > This series implements support for Atomic Modesetting in the QXL driver. > The first 4 patches in the series are some cleanups to prepare the > ground, while the rest implement Atomic in 3 phases, as suggested by > Daniel's blog post[1]. > > Testing was done with the X server, igt, libdrm testsuit and some custom > code that I can share if requested. I hope this covers the main use > cases. Hmm, throws a "unpin not necessary" now and then, when switching runlevels. Not every time, usually have to switch from 5 to 3 and back a few times to see it. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 0/3] gpu: drm: Convert printk(KERN_ to pr_
On Tue, Feb 28, 2017 at 04:55:51AM -0800, Joe Perches wrote: > Broken up for Daniel Vetter Thanks, I applied the core patch (needed a minor resolution in drm_edid.c). I'll wait with the driver patch for a few more acks maybe, and leave the 2 other patches to Alex for picking up directly. Thanks, Daniel > > Joe Perches (3): > gpu: drm: amd/radeon: Convert printk(KERN_ to pr_ > gpu: drm: core: Convert printk(KERN_ to pr_ > gpu: drm: drivers: Convert printk(KERN_ to pr_ > > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_test.c | 2 +- > drivers/gpu/drm/amd/amdgpu/atom.c | 44 - > drivers/gpu/drm/amd/amdgpu/ci_dpm.c| 4 +- > drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 +- > drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 ++-- > drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 ++-- > drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 +- > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 +- > drivers/gpu/drm/amd/include/amd_pcie_helpers.h | 4 +- > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +- > drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 2 +- > drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c| 4 +- > drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++--- > .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 +- > drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 +- > drivers/gpu/drm/drm_cache.c| 12 ++--- > drivers/gpu/drm/drm_edid.c | 4 +- > drivers/gpu/drm/drm_ioc32.c| 3 +- > drivers/gpu/drm/gma500/cdv_intel_lvds.c| 9 ++-- > drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++ > drivers/gpu/drm/gma500/psb_drv.h | 5 +- > drivers/gpu/drm/gma500/psb_intel_lvds.c| 7 ++- > drivers/gpu/drm/i915/i915_sw_fence.c | 8 ++-- > drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- > drivers/gpu/drm/msm/msm_drv.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_acpi.c | 7 +-- > drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +- > drivers/gpu/drm/nouveau/nv50_display.c | 22 - > drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++-- > drivers/gpu/drm/omapdrm/dss/dsi.c | 17 --- > drivers/gpu/drm/omapdrm/dss/dss.c | 3 +- > drivers/gpu/drm/omapdrm/dss/dss.h | 15 +++--- > drivers/gpu/drm/omapdrm/omap_gem.c | 5 +- > drivers/gpu/drm/r128/r128_cce.c| 7 ++- > drivers/gpu/drm/radeon/atom.c | 46 -- > drivers/gpu/drm/radeon/cik.c | 56 > -- > drivers/gpu/drm/radeon/evergreen.c | 2 +- > drivers/gpu/drm/radeon/evergreen_cs.c | 7 ++- > drivers/gpu/drm/radeon/ni.c| 22 +++-- > drivers/gpu/drm/radeon/r100.c | 18 +++ > drivers/gpu/drm/radeon/r200.c | 3 +- > drivers/gpu/drm/radeon/r300.c | 13 ++--- > drivers/gpu/drm/radeon/r420.c | 9 ++-- > drivers/gpu/drm/radeon/r520.c | 3 +- > drivers/gpu/drm/radeon/r600.c | 21 +++- > drivers/gpu/drm/radeon/r600_cs.c | 7 ++- > drivers/gpu/drm/radeon/radeon.h| 3 +- > drivers/gpu/drm/radeon/radeon_atpx_handler.c | 4 +- > drivers/gpu/drm/radeon/radeon_audio.c | 4 +- > drivers/gpu/drm/radeon/radeon_clocks.c | 2 +- > drivers/gpu/drm/radeon/radeon_device.c | 8 ++-- > drivers/gpu/drm/radeon/radeon_fb.c | 3 +- > drivers/gpu/drm/radeon/radeon_gem.c| 4 +- > drivers/gpu/drm/radeon/radeon_test.c | 6 +-- > drivers/gpu/drm/radeon/rs400.c | 4 +- > drivers/gpu/drm/radeon/rs690.c | 3 +- > drivers/gpu/drm/radeon/rv515.c | 9 ++-- > drivers/gpu/drm/radeon/si.c| 45 ++--- > drivers/gpu/drm/ttm/ttm_bo.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +- > 69 files changed, 253 insertions(+), 362 deletions(-) > > -- > 2.10.0.rc2.1.g053435c > >
[PATCH v2 3/4] drm/imx: extend drm_plane_state_to_eba for separate channel support
Allow to calculate EBA for planes other than plane 0. This is in
preparation for the following patch, which adds support for separate
alpha planes.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index a37735298615e..53eceff09d179 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -66,18 +66,18 @@ int ipu_plane_irq(struct ipu_plane *ipu_plane)
}
static inline unsigned long
-drm_plane_state_to_eba(struct drm_plane_state *state)
+drm_plane_state_to_eba(struct drm_plane_state *state, int plane)
{
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
- cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+ cma_obj = drm_fb_cma_get_gem_obj(fb, plane);
BUG_ON(!cma_obj);
- return cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y +
- fb->format->cpp[0] * x;
+ return cma_obj->paddr + fb->offsets[plane] + fb->pitches[plane] * y +
+ fb->format->cpp[plane] * x;
}
static inline unsigned long
@@ -85,7 +85,7 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
{
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
- unsigned long eba = drm_plane_state_to_eba(state);
+ unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
@@ -104,7 +104,7 @@ drm_plane_state_to_vbo(struct drm_plane_state *state)
{
struct drm_framebuffer *fb = state->fb;
struct drm_gem_cma_object *cma_obj;
- unsigned long eba = drm_plane_state_to_eba(state);
+ unsigned long eba = drm_plane_state_to_eba(state, 0);
int x = state->src.x1 >> 16;
int y = state->src.y1 >> 16;
@@ -286,7 +286,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
fb->format != old_fb->format))
crtc_state->mode_changed = true;
- eba = drm_plane_state_to_eba(state);
+ eba = drm_plane_state_to_eba(state, 0);
if (eba & 0x7)
return -EINVAL;
@@ -385,7 +385,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
if (ipu_plane->dp_flow == IPU_DP_FLOW_SYNC_FG)
ipu_dp_set_window_pos(ipu_plane->dp, dst->x1, dst->y1);
- eba = drm_plane_state_to_eba(state);
+ eba = drm_plane_state_to_eba(state, 0);
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] gpu: ipu-v3: add support for separate alpha channels
The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven
by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels.
This allows to reduce memory bandwidth via a conditional read mechanism or
to support planar YUV formats with alpha transparency.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 6 +
drivers/gpu/ipu-v3/ipu-cpmem.c | 57 +
include/video/imx-ipu-v3.h | 22
3 files changed, 85 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8a32ed25a1c29..448043c051e94 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -83,6 +83,12 @@ enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32
drm_fourcc)
case DRM_FORMAT_ABGR:
case DRM_FORMAT_RGBA:
case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
return IPUV3_COLORSPACE_RGB;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
index b72f725e00b59..114160dfc3ade 100644
--- a/drivers/gpu/ipu-v3/ipu-cpmem.c
+++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
@@ -537,6 +537,43 @@ static const struct ipu_rgb def_bgra_16 = {
#define UV2_OFFSET(pix, x, y) ((pix->width * pix->height) + \
(pix->width * y) + (x))
+#define NUM_ALPHA_CHANNELS 7
+
+/* See Table 37-12. Alpha channels mapping. */
+static int ipu_channel_albm(int ch_num)
+{
+ switch (ch_num) {
+ case IPUV3_CHANNEL_G_MEM_IC_PRP_VF: return 0;
+ case IPUV3_CHANNEL_G_MEM_IC_PP: return 1;
+ case IPUV3_CHANNEL_MEM_FG_SYNC: return 2;
+ case IPUV3_CHANNEL_MEM_FG_ASYNC:return 3;
+ case IPUV3_CHANNEL_MEM_BG_SYNC: return 4;
+ case IPUV3_CHANNEL_MEM_BG_ASYNC:return 5;
+ case IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB: return 6;
+ default:
+ return -EINVAL;
+ }
+}
+
+static void ipu_cpmem_set_separate_alpha(struct ipuv3_channel *ch)
+{
+ struct ipu_soc *ipu = ch->ipu;
+ int albm;
+ u32 val;
+
+ albm = ipu_channel_albm(ch->num);
+ if (albm < 0)
+ return;
+
+ ipu_ch_param_write_field(ch, IPU_FIELD_ALU, 1);
+ ipu_ch_param_write_field(ch, IPU_FIELD_ALBM, albm);
+ ipu_ch_param_write_field(ch, IPU_FIELD_CRE, 1);
+
+ val = ipu_idmac_read(ipu, IDMAC_SEP_ALPHA);
+ val |= BIT(ch->num);
+ ipu_idmac_write(ipu, val, IDMAC_SEP_ALPHA);
+}
+
int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32 drm_fourcc)
{
switch (drm_fourcc) {
@@ -599,22 +636,28 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
break;
case DRM_FORMAT_RGBA:
case DRM_FORMAT_RGBX:
+ case DRM_FORMAT_RGBX_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgbx_32);
break;
case DRM_FORMAT_BGRA:
case DRM_FORMAT_BGRX:
+ case DRM_FORMAT_BGRX_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgrx_32);
break;
case DRM_FORMAT_BGR888:
+ case DRM_FORMAT_BGR888_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_24);
break;
case DRM_FORMAT_RGB888:
+ case DRM_FORMAT_RGB888_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_24);
break;
case DRM_FORMAT_RGB565:
+ case DRM_FORMAT_RGB565_A8:
ipu_cpmem_set_format_rgb(ch, &def_rgb_16);
break;
case DRM_FORMAT_BGR565:
+ case DRM_FORMAT_BGR565_A8:
ipu_cpmem_set_format_rgb(ch, &def_bgr_16);
break;
case DRM_FORMAT_ARGB1555:
@@ -636,6 +679,20 @@ int ipu_cpmem_set_fmt(struct ipuv3_channel *ch, u32
drm_fourcc)
return -EINVAL;
}
+ switch (drm_fourcc) {
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ ipu_ch_param_write_field(ch, IPU_FIELD_WID3, 7);
+ ipu_cpmem_set_separate_alpha(ch);
+ break;
+ default:
+ break;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(ipu_cpmem_set_fmt);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 899d2b00ad6d4..6af74f0cf161f 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -161,6 +161,28 @@ enum ipu_channel_irq {
#define IPUV3_CHANNEL_MEM_BG_ASYNC_ALPHA 52
#define IPUV3_NUM_CHANNELS 64
+static inline int ipu_channel_alpha_channel(
[PATCH v2 1/4] drm: add RGB formats with separate alpha plane
Some hardware can read the alpha components separately and then
conditionally fetch color components only for non-zero alpha values.
This patch adds fourcc definitions for two-plane RGB formats with an
8-bit alpha channel on a second plane.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Added a commend that the RGB plane has the same format as the corresponding
RGB format without _A8.
- Added lost drm_format_info fields for RGB565/BGR565/RGB888/BGR888_A8.
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8da8eb6..92bf3306d4b32 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -132,6 +132,8 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_XBGR,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGRX,.depth = 24,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_RGB565_A8, .depth = 24,
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_BGR565_A8, .depth = 24,
.num_planes = 2, .cpp = { 2, 1, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_XRGB2101010, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_XBGR2101010, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBX1010102, .depth = 30,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
@@ -144,6 +146,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_RGBA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_BGRA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XBGR_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_RGBX_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_BGRX_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_YUV410, .depth = 0,
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YVU410, .depth = 0,
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 4 },
{ .format = DRM_FORMAT_YUV411, .depth = 0,
.num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 4, .vsub = 1 },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb8119bf..f0060664ecb6a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -114,6 +114,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
/*
+ * 2 plane RGB + A
+ * index 0 = RGB plane, same format as the corresponding non _A8 format has
+ * index 1 = A plane
+ */
+#define DRM_FORMAT_XRGB_A8 fourcc_code('X', 'R', 'A', '8')
+#define DRM_FORMAT_XBGR_A8 fourcc_code('X', 'B', 'A', '8')
+#define DRM_FORMAT_RGBX_A8 fourcc_code('R', 'X', 'A', '8')
+#define DRM_FORMAT_BGRX_A8 fourcc_code('B', 'X', 'A', '8')
+#define DRM_FORMAT_RGB888_A8 fourcc_code('R', '8', 'A', '8')
+#define DRM_FORMAT_BGR888_A8 fourcc_code('B', '8', 'A', '8')
+#define DRM_FORMAT_RGB565_A8 fourcc_code('R', '5', 'A', '8')
+#define DRM_FORMAT_BGR565_A8 fourcc_code('B', '5', 'A', '8')
+
+/*
* 2 plane YCbCr
* index 0 = Y plane, [7:0] Y
* index 1 = Cr:Cb plane, [15:0] Cr:Cb little endian
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/imx: ipuv3-plane: add support for separate alpha planes
The IPUv3 can read 8-bit alpha values from a separate plane buffer using
a companion IDMAC channel driven by the Alpha Transparency Controller
(ATC) for the graphics channels. The conditional read mechanism allows
to reduce memory bandwidth by skipping reads of color data for
completely transparent bursts.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 97 ++-
drivers/gpu/drm/imx/ipuv3-plane.h | 1 +
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 53eceff09d179..cecb8eba5c320 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -57,6 +57,12 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_NV12,
DRM_FORMAT_NV16,
DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB565_A8,
+ DRM_FORMAT_BGR565_A8,
+ DRM_FORMAT_RGB888_A8,
+ DRM_FORMAT_BGR888_A8,
+ DRM_FORMAT_RGBX_A8,
+ DRM_FORMAT_BGRX_A8,
};
int ipu_plane_irq(struct ipu_plane *ipu_plane)
@@ -126,11 +132,14 @@ void ipu_plane_put_resources(struct ipu_plane *ipu_plane)
ipu_dmfc_put(ipu_plane->dmfc);
if (!IS_ERR_OR_NULL(ipu_plane->ipu_ch))
ipu_idmac_put(ipu_plane->ipu_ch);
+ if (!IS_ERR_OR_NULL(ipu_plane->alpha_ch))
+ ipu_idmac_put(ipu_plane->alpha_ch);
}
int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
{
int ret;
+ int alpha_ch;
ipu_plane->ipu_ch = ipu_idmac_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->ipu_ch)) {
@@ -139,6 +148,17 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
}
+ alpha_ch = ipu_channel_alpha_channel(ipu_plane->dma);
+ if (alpha_ch >= 0) {
+ ipu_plane->alpha_ch = ipu_idmac_get(ipu_plane->ipu, alpha_ch);
+ if (IS_ERR(ipu_plane->alpha_ch)) {
+ ret = PTR_ERR(ipu_plane->alpha_ch);
+ DRM_ERROR("failed to get alpha idmac channel %d: %d\n",
+ alpha_ch, ret);
+ return ret;
+ }
+ }
+
ipu_plane->dmfc = ipu_dmfc_get(ipu_plane->ipu, ipu_plane->dma);
if (IS_ERR(ipu_plane->dmfc)) {
ret = PTR_ERR(ipu_plane->dmfc);
@@ -162,12 +182,29 @@ int ipu_plane_get_resources(struct ipu_plane *ipu_plane)
return ret;
}
+static bool ipu_plane_separate_alpha(struct ipu_plane *ipu_plane)
+{
+ switch (ipu_plane->base.state->fb->format->format) {
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ return true;
+ default:
+ return false;
+ }
+}
+
static void ipu_plane_enable(struct ipu_plane *ipu_plane)
{
if (ipu_plane->dp)
ipu_dp_enable(ipu_plane->ipu);
ipu_dmfc_enable_channel(ipu_plane->dmfc);
ipu_idmac_enable_channel(ipu_plane->ipu_ch);
+ if (ipu_plane_separate_alpha(ipu_plane))
+ ipu_idmac_enable_channel(ipu_plane->alpha_ch);
if (ipu_plane->dp)
ipu_dp_enable_channel(ipu_plane->dp);
}
@@ -181,6 +218,8 @@ void ipu_plane_disable(struct ipu_plane *ipu_plane, bool
disable_dp_channel)
if (ipu_plane->dp && disable_dp_channel)
ipu_dp_disable_channel(ipu_plane->dp, false);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
+ if (ipu_plane->alpha_ch)
+ ipu_idmac_disable_channel(ipu_plane->alpha_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
ipu_dp_disable(ipu_plane->ipu);
@@ -224,7 +263,7 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
struct device *dev = plane->dev->dev;
struct drm_framebuffer *fb = state->fb;
struct drm_framebuffer *old_fb = old_state->fb;
- unsigned long eba, ubo, vbo, old_ubo, old_vbo;
+ unsigned long eba, ubo, vbo, old_ubo, old_vbo, alpha_eba;
bool can_position = (plane->type == DRM_PLANE_TYPE_OVERLAY);
struct drm_rect clip;
int hsub, vsub;
@@ -355,6 +394,23 @@ static int ipu_plane_atomic_check(struct drm_plane *plane,
if (((state->src.x1 >> 16) & (hsub - 1)) ||
((state->src.y1 >> 16) & (vsub - 1)))
return -EINVAL;
+ break;
+ case DRM_FORMAT_RGB565_A8:
+ case DRM_FORMAT_BGR565_A8:
+ case DRM_FORMAT_RGB888_A8:
+ case DRM_FORMAT_BGR888_A8:
+ case DRM_FORMAT_RGBX_A8:
+ case DRM_FORMAT_BGRX_A8:
+ alpha_eba = drm_plane_state_to_eba(state, 1);
+ if (alpha_eba & 0x7)
+ return -EINVAL;
+
+ if (fb->pitches[1] < 1 || f
[PATCH v3 4/4] drm/imx: add deferred plane disabling
The DP (display processor) channel disable code tried to busy wait for
the DP sync flow end interrupt status bit when disabling the partial
plane without a full modeset. That never worked reliably, and it was
disabled completely by the recent "gpu: ipu-v3: remove IRQ dance on DC
channel disable" patch, causing ipu_wait_interrupt to always time out
after 50 ms, which in turn would trigger a timeout in
drm_atomic_helper_wait_for_vblanks.
This patch changes ipu_plane_atomic_disable to only queue a DP channel
register update at the next frame boundary and set a flag, which can be
done without any waiting whatsoever. The imx_drm_atomic_commit_tail then
calls a new ipu_plane_disable_deferred function that does the actual
IDMAC teardown of the planes that are flagged for deferred disabling,
after waiting for the vblank.
Signed-off-by: Philipp Zabel
---
Changes since v2:
- Add missing export for ipu_plane_disable_deferred
- Check if there are any planes to be disabled and only then wait for
vblanks and call the deferred disable function
---
drivers/gpu/drm/imx/imx-drm-core.c | 18 ++
drivers/gpu/drm/imx/ipuv3-crtc.c | 22 +-
drivers/gpu/drm/imx/ipuv3-plane.c | 25 ++---
drivers/gpu/drm/imx/ipuv3-plane.h | 5 +
drivers/gpu/ipu-v3/ipu-dp.c| 3 ---
5 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 0a5e4fbb906bf..94f9c25e1c67b 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -30,6 +30,7 @@
#include
#include "imx-drm.h"
+#include "ipuv3-plane.h"
#define MAX_CRTC 4
@@ -160,6 +161,10 @@ static const struct drm_mode_config_funcs
imx_drm_mode_config_funcs = {
static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
+ struct drm_plane *plane;
+ struct drm_plane_state *plane_state;
+ bool plane_disabling = false;
+ int i;
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -169,6 +174,19 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_commit_modeset_enables(dev, state);
+ for_each_plane_in_state(state, plane, plane_state, i) {
+ if (drm_atomic_plane_disabling(plane, plane_state))
+ plane_disabling = true;
+ }
+
+ if (plane_disabling) {
+ drm_atomic_helper_wait_for_vblanks(dev, state);
+
+ for_each_plane_in_state(state, plane, plane_state, i)
+ ipu_plane_disable_deferred(plane);
+
+ }
+
drm_atomic_helper_commit_hw_done(state);
}
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 6be515a9fb694..0f15f11f26e0c 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -60,6 +60,26 @@ static void ipu_crtc_enable(struct drm_crtc *crtc)
ipu_di_enable(ipu_crtc->di);
}
+static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc,
+ struct drm_crtc_state *old_crtc_state)
+{
+ bool disable_partial = false;
+ bool disable_full = false;
+ struct drm_plane *plane;
+
+ drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
+ if (plane == &ipu_crtc->plane[0]->base)
+ disable_full = true;
+ if (&ipu_crtc->plane[1] && plane == &ipu_crtc->plane[1]->base)
+ disable_partial = true;
+ }
+
+ if (disable_partial)
+ ipu_plane_disable(ipu_crtc->plane[1], true);
+ if (disable_full)
+ ipu_plane_disable(ipu_crtc->plane[0], false);
+}
+
static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
@@ -73,7 +93,7 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
* attached IDMACs will be left in undefined state, possibly hanging
* the IPU or even system.
*/
- drm_atomic_helper_disable_planes_on_crtc(old_crtc_state, false);
+ ipu_crtc_disable_planes(ipu_crtc, old_crtc_state);
ipu_dc_disable(ipu);
spin_lock_irq(&crtc->dev->event_lock);
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 55991d46ced50..a37735298615e 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -172,23 +172,30 @@ static void ipu_plane_enable(struct ipu_plane *ipu_plane)
ipu_dp_enable_channel(ipu_plane->dp);
}
-static int ipu_disable_plane(struct drm_plane *plane)
+void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
{
- struct ipu_plane *ipu_plane = to_ipu_plane(plane);
-
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
ipu_idmac_wait_bu
[PATCH v3 2/4] gpu: ipu-v3: add unsynchronised DP channel disabling
When disabling the foreground DP channel during a modeset, the DC is
already disabled without waiting for end of frame. There is no reason
to wait for a frame boundary before updating the DP registers in that
case.
Add support to apply updates immediately. No functional changes, yet.
Signed-off-by: Philipp Zabel
Reviewed-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
drivers/gpu/ipu-v3/ipu-common.c | 8 +---
drivers/gpu/ipu-v3/ipu-dp.c | 12 ++--
drivers/gpu/ipu-v3/ipu-prv.h | 7 ++-
include/video/imx-ipu-v3.h| 2 +-
5 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 24819c9c36400..55991d46ced50 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -181,7 +181,7 @@ static int ipu_disable_plane(struct drm_plane *plane)
ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
if (ipu_plane->dp)
- ipu_dp_disable_channel(ipu_plane->dp);
+ ipu_dp_disable_channel(ipu_plane->dp, true);
ipu_idmac_disable_channel(ipu_plane->ipu_ch);
ipu_dmfc_disable_channel(ipu_plane->dmfc);
if (ipu_plane->dp)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 8368e6f766ee5..8a32ed25a1c29 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -51,15 +51,17 @@ int ipu_get_num(struct ipu_soc *ipu)
}
EXPORT_SYMBOL_GPL(ipu_get_num);
-void ipu_srm_dp_sync_update(struct ipu_soc *ipu)
+void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync)
{
u32 val;
val = ipu_cm_read(ipu, IPU_SRM_PRI2);
- val |= 0x8;
+ val &= ~DP_S_SRM_MODE_MASK;
+ val |= sync ? DP_S_SRM_MODE_NEXT_FRAME :
+ DP_S_SRM_MODE_NOW;
ipu_cm_write(ipu, val, IPU_SRM_PRI2);
}
-EXPORT_SYMBOL_GPL(ipu_srm_dp_sync_update);
+EXPORT_SYMBOL_GPL(ipu_srm_dp_update);
enum ipu_color_space ipu_drm_fourcc_to_colorspace(u32 drm_fourcc)
{
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 98686edbcdbb0..0e09c98248a0d 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -112,7 +112,7 @@ int ipu_dp_set_global_alpha(struct ipu_dp *dp, bool enable,
writel(reg & ~DP_COM_CONF_GWAM, flow->base + DP_COM_CONF);
}
- ipu_srm_dp_sync_update(priv->ipu);
+ ipu_srm_dp_update(priv->ipu, true);
mutex_unlock(&priv->mutex);
@@ -127,7 +127,7 @@ int ipu_dp_set_window_pos(struct ipu_dp *dp, u16 x_pos, u16
y_pos)
writel((x_pos << 16) | y_pos, flow->base + DP_FG_POS);
- ipu_srm_dp_sync_update(priv->ipu);
+ ipu_srm_dp_update(priv->ipu, true);
return 0;
}
@@ -207,7 +207,7 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
flow->out_cs, DP_COM_CONF_CSC_DEF_FG);
}
- ipu_srm_dp_sync_update(priv->ipu);
+ ipu_srm_dp_update(priv->ipu, true);
mutex_unlock(&priv->mutex);
@@ -247,7 +247,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
reg |= DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
- ipu_srm_dp_sync_update(priv->ipu);
+ ipu_srm_dp_update(priv->ipu, true);
mutex_unlock(&priv->mutex);
@@ -255,7 +255,7 @@ int ipu_dp_enable_channel(struct ipu_dp *dp)
}
EXPORT_SYMBOL_GPL(ipu_dp_enable_channel);
-void ipu_dp_disable_channel(struct ipu_dp *dp)
+void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
{
struct ipu_flow *flow = to_flow(dp);
struct ipu_dp_priv *priv = flow->priv;
@@ -275,7 +275,7 @@ void ipu_dp_disable_channel(struct ipu_dp *dp)
writel(reg, flow->base + DP_COM_CONF);
writel(0, flow->base + DP_FG_POS);
- ipu_srm_dp_sync_update(priv->ipu);
+ ipu_srm_dp_update(priv->ipu, sync);
if (ipu_idmac_channel_busy(priv->ipu, IPUV3_CHANNEL_MEM_BG_SYNC))
ipu_wait_interrupt(priv->ipu, IPU_IRQ_DP_SF_END, 50);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index 22e47b68b14a2..285595702ee0f 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -75,6 +75,11 @@ struct ipu_soc;
#define IPU_INT_CTRL(n)IPU_CM_REG(0x003C + 4 * (n))
#define IPU_INT_STAT(n)IPU_CM_REG(0x0200 + 4 * (n))
+/* SRM_PRI2 */
+#define DP_S_SRM_MODE_MASK (0x3 << 3)
+#define DP_S_SRM_MODE_NOW (0x3 << 3)
+#define DP_S_SRM_MODE_NEXT_FRAME (0x1 << 3)
+
/* FS_PROC_FLOW1 */
#define FS_PRPENC_ROT_SRC_SEL_MASK (0xf << 0)
#define FS_PRPENC_ROT_SRC_SEL_ENC (0x7 << 0)
@@ -215,7 +220,7 @@ static inline void ipu_idmac_write(struct ipu_soc *ipu, u32
value,
writel(value, ipu->idmac_reg + offset);
}
-void ipu_srm_dp_sync_update(struct ipu_soc *ipu);
+void ipu_srm_dp_update(struct ipu_soc *ipu, bool sync);
int ipu_module_enable
[PATCH v3 0/4] Fix DP busy wait and defer disabling overlay plane
Hi, third try. This time I've removed the drm_atomic_helper_wait_for_vblanks call from imx_drm_commit_tail unless there are planes to be disabled. Also the drm_atomic_helper_cleanup_planes call is removed, as that is a no-op for CMA framebuffer based drivers. This series fixes an issue with the IPU DC/DP/IDMAC disable sequence. The interrupt waiting code didn't work as expected, sometimes causing busy waits longer than the timeout in drm_atomic_helper_wait_for_vblanks, which would cause crashes similar to the reported "imxdrm issue on SABRE Lite" [1]. [1] http://www.spinics.net/lists/dri-devel/msg132485.html I could only reproduce the error when the overlay plane was involved, using weston with the atomic modeset patchset to trigger it, so I'm not sure if this fixes the issue above, too. regards Philipp Lucas Stach (1): gpu: ipu-v3: remove IRQ dance on DC channel disable Philipp Zabel (3): gpu: ipu-v3: add unsynchronised DP channel disabling drm/imx: don't wait for vblank and stop calling cleanup_planes in commit_tail drm/imx: add deferred plane disabling drivers/gpu/drm/imx/imx-drm-core.c | 20 +++-- drivers/gpu/drm/imx/ipuv3-crtc.c | 22 +- drivers/gpu/drm/imx/ipuv3-plane.c | 25 +++- drivers/gpu/drm/imx/ipuv3-plane.h | 5 drivers/gpu/ipu-v3/ipu-common.c| 8 +++-- drivers/gpu/ipu-v3/ipu-dc.c| 61 +++--- drivers/gpu/ipu-v3/ipu-dp.c| 15 -- drivers/gpu/ipu-v3/ipu-prv.h | 7 - include/video/imx-ipu-v3.h | 2 +- 9 files changed, 83 insertions(+), 82 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/imx: don't wait for vblank and stop calling cleanup_planes in commit_tail
drm_atomic_helper_cleanup_planes only calls the cleanup_fb plane
helpers, which we don't implement as a CMA framebuffer based driver.
There is no reason to wait for vblanks in commit_tail only to do nothing
afterwards.
Signed-off-by: Philipp Zabel
---
Changes since v2:
- New patch that removes wait_for_vblanks and cleanup_planes instead
of reordering commit_hw_done and wait_for_vblanks.
---
drivers/gpu/drm/imx/imx-drm-core.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index f562cb7964b08..0a5e4fbb906bf 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -170,10 +170,6 @@ static void imx_drm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_atomic_helper_commit_modeset_enables(dev, state);
drm_atomic_helper_commit_hw_done(state);
-
- drm_atomic_helper_wait_for_vblanks(dev, state);
-
- drm_atomic_helper_cleanup_planes(dev, state);
}
static struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers = {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] gpu: ipu-v3: remove IRQ dance on DC channel disable
From: Lucas Stach
This has never worked properly, as the IRQ got retriggered immediately
on unmask. Remove the IRQ wait dance, as it is apparently safe to disable
the DC channel at any point in time.
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dc.c | 61 +++--
1 file changed, 4 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 659475c1e44ab..7a4b8362dda8f 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -112,8 +112,6 @@ struct ipu_dc_priv {
struct ipu_dc channels[IPU_DC_NUM_CHANNELS];
struct mutexmutex;
struct completion comp;
- int dc_irq;
- int dp_irq;
int use_count;
};
@@ -262,47 +260,13 @@ void ipu_dc_enable_channel(struct ipu_dc *dc)
}
EXPORT_SYMBOL_GPL(ipu_dc_enable_channel);
-static irqreturn_t dc_irq_handler(int irq, void *dev_id)
-{
- struct ipu_dc *dc = dev_id;
- u32 reg;
-
- reg = readl(dc->base + DC_WR_CH_CONF);
- reg &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
- writel(reg, dc->base + DC_WR_CH_CONF);
-
- /* The Freescale BSP kernel clears DIx_COUNTER_RELEASE here */
-
- complete(&dc->priv->comp);
- return IRQ_HANDLED;
-}
-
void ipu_dc_disable_channel(struct ipu_dc *dc)
{
- struct ipu_dc_priv *priv = dc->priv;
- int irq;
- unsigned long ret;
u32 val;
- /* TODO: Handle MEM_FG_SYNC differently from MEM_BG_SYNC */
- if (dc->chno == 1)
- irq = priv->dc_irq;
- else if (dc->chno == 5)
- irq = priv->dp_irq;
- else
- return;
-
- init_completion(&priv->comp);
- enable_irq(irq);
- ret = wait_for_completion_timeout(&priv->comp, msecs_to_jiffies(50));
- disable_irq(irq);
- if (ret == 0) {
- dev_warn(priv->dev, "DC stop timeout after 50 ms\n");
-
- val = readl(dc->base + DC_WR_CH_CONF);
- val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
- writel(val, dc->base + DC_WR_CH_CONF);
- }
+ val = readl(dc->base + DC_WR_CH_CONF);
+ val &= ~DC_WR_CH_CONF_PROG_TYPE_MASK;
+ writel(val, dc->base + DC_WR_CH_CONF);
}
EXPORT_SYMBOL_GPL(ipu_dc_disable_channel);
@@ -389,7 +353,7 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
struct ipu_dc_priv *priv;
static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c,
0x78, 0, 0x94, 0xb4};
- int i, ret;
+ int i;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -410,23 +374,6 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
priv->channels[i].base = priv->dc_reg + channel_offsets[i];
}
- priv->dc_irq = ipu_map_irq(ipu, IPU_IRQ_DC_FC_1);
- if (!priv->dc_irq)
- return -EINVAL;
- ret = devm_request_irq(dev, priv->dc_irq, dc_irq_handler, 0, NULL,
- &priv->channels[1]);
- if (ret < 0)
- return ret;
- disable_irq(priv->dc_irq);
- priv->dp_irq = ipu_map_irq(ipu, IPU_IRQ_DP_SF_END);
- if (!priv->dp_irq)
- return -EINVAL;
- ret = devm_request_irq(dev, priv->dp_irq, dc_irq_handler, 0, NULL,
- &priv->channels[5]);
- if (ret < 0)
- return ret;
- disable_irq(priv->dp_irq);
-
writel(DC_WR_CH_CONF_WORD_SIZE_24 | DC_WR_CH_CONF_DISP_ID_PARALLEL(1) |
DC_WR_CH_CONF_PROG_DI_ID,
priv->channels[1].base + DC_WR_CH_CONF);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel
On Tue, Feb 28, 2017 at 4:07 AM, Yannick FERTRE wrote:
> On 02/24/2017 03:06 PM, Rob Herring wrote:
>> On Fri, Feb 24, 2017 at 2:18 AM, Yannick FERTRE
>> wrote:
>>> On 02/21/2017 03:07 PM, Rob Herring wrote:
On Mon, Feb 20, 2017 at 5:01 AM, Yannick FERTRE
wrote:
> On 02/16/2017 03:34 AM, Rob Herring wrote:
>> On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote:
>>> Signed-off-by: Yannick Fertre
>>> ---
>>> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7
>>> +++
>>> 1 file changed, 7 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
[...]
> This binding is similar to all panel bindings which are link to panel
> simple. Details on gpio & power supply are describe with simple-panel
> binding.
simple-panel.txt provides what possible standard properties there are,
not whether a panel uses them. The power supply needs to be explicit
because I don't know if you forgot and there's really 2 supplies or
you are using "power-supply" for a single supply.
Rob
>
>
> Hi Rob,
> ok, I'll push a V4 version with all details on properties.
> I write bellow a draft of binding:
>
> Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
>
> This binding is compatible with the simple-panel binding, which is specified
> in simple-panel.txt in this directory.
>
> Required properties:
> - compatible: should be "ampire,am-480272h3tmqw-t01h"
>
> Optional properties:
> - power-supply: regulator to provide the supply voltage
> - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
Doesn't look like there's any DDC connection to this panel.
> - enable-gpios: GPIO pin to enable or disable the panel
Need to state this is active high.
> - backlight: phandle of the backlight device attached to the panel
>
> Optional nodes:
> - Video port for RGB input.
>
> Example:
> panel_rgb: panel-rgb {
> compatible = "ampire,am-480272h3tmqw-t01h";
> enable-gpios = <&gpioa 8 1>;
> port {
> panel_in_rgb: endpoint {
> remote-endpoint = <&controler_out_rgb>;
> };
> };
> };
>
> Best regards
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
4.11-rc0, thinkpad x220: GPU hang
Hi! mplayer stopped working after a while. Dmesg says: [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5 [ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium [4597], reason: Hang on render ring, action: reset [ 3190.767311] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 3190.767313] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 3190.767315] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 3190.767317] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 3190.767320] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 3190.767427] drm/i915: Resetting chip after gpu hang [ 3228.329384] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been dropped [ 3228.329604] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been dropped [ 3877.246261] perf: interrupt took too long (3142 > 3133), lowering kernel.perf_event_max_sample_rate to 63500 [ 4802.784478] drm/i915: Resetting chip after gpu hang [ 4810.784851] drm/i915: Resetting chip after gpu hang [ 4829.829795] drm/i915: Resetting chip after gpu hang [ 4837.826154] drm/i915: Resetting chip after gpu hang [ 5125.026814] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308257 end=308258) time 203 us, min 763, max 767, scanline start 761, end 771 [ 5125.192602] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe B (start=307385 end=307386) time 204 us, min 1073, max 1079, scanline start 1071, end 1086 [ 5125.309992] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308274 end=308275) time 203 us, min 763, max 767, scanline start 758, end 768 [ 5125.460013] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308283 end=308284) time 204 us, min 763, max 767, scanline start 761, end 771 [ 5125.493340] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308285 end=308286) time 202 us, min 763, max 767, scanline start 761, end 771 [ 5125.526684] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308287 end=308288) time 204 us, min 763, max 767, scanline start 762, end 772 [ 5125.593245] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308291 end=308292) time 203 us, min 763, max 767, scanline start 758, end 768 [ 5125.676636] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308296 end=308297) time 202 us, min 763, max 767, scanline start 762, end 772 [ 5125.709960] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308298 end=308299) time 203 us, min 763, max 767, scanline start 762, end 772 [ 5126.093109] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on pipe A (start=308321 end=308322) time 204 us, min 763, max 767, scanline start 759, end 770 [ 5647.879171] drm/i915: Resetting chip after gpu hang [ 5655.879507] drm/i915: Resetting chip after gpu hang [ 5850.864464] drm/i915: Resetting chip after gpu hang [ 5858.864853] drm/i915: Resetting chip after gpu hang [ 5904.850879] drm/i915: Resetting chip after gpu hang [ 5912.851252] drm/i915: Resetting chip after gpu hang [ 5949.876973] drm/i915: Resetting chip after gpu hang [ 5957.877460] drm/i915: Resetting chip after gpu hang [ 6018.872153] drm/i915: Resetting chip after gpu hang [ 6030.872646] drm/i915: Resetting chip after gpu hang [ 7108.362610] perf: interrupt took too long (3935 > 3927), lowering kernel.perf_event_max_sample_rate to 50750 [ 9670.047072] drm/i915: Resetting chip after gpu hang [ 9678.047415] drm/i915: Resetting chip after gpu hang [10408.064806] drm/i915: Resetting chip after gpu hang [10416.097168] drm/i915: Resetting chip after gpu hang [10416.097181] [drm:i915_reset] *ERROR* GPU recovery failed pavel@duo:/data/film$ Umm. Dmesg wants me to attach card0/error, but it looks like it contains quite a lot of data. If it contains actual framebuffer content, it may not be wise to post to mailing list Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm: Introduce drm_framebuffer_{get,put}()
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_framebuffer_get() and drm_framebuffer_put() to reference count DRM
framebuffers.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
The existing semantic patch for the DRM subsystem-wide conversion is
extended to account for these new helpers.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c | 6 ++--
drivers/gpu/drm/drm_atomic_helper.c | 4 +--
drivers/gpu/drm/drm_crtc.c | 8 +++---
drivers/gpu/drm/drm_framebuffer.c| 34 +++---
drivers/gpu/drm/drm_plane.c | 12
include/drm/drm_framebuffer.h| 49
scripts/coccinelle/api/drm-get-put.cocci | 10 +++
7 files changed, 79 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 82bad40b2f3e..740650b450c5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -733,7 +733,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
- drm_framebuffer_unreference(fb);
+ drm_framebuffer_put(fb);
} else if (property == config->prop_in_fence_fd) {
if (state->fence)
return -EINVAL;
@@ -1837,12 +1837,12 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
if (ret == 0) {
struct drm_framebuffer *new_fb = plane->state->fb;
if (new_fb)
- drm_framebuffer_reference(new_fb);
+ drm_framebuffer_get(new_fb);
plane->fb = new_fb;
plane->crtc = plane->state->crtc;
if (plane->old_fb)
- drm_framebuffer_unreference(plane->old_fb);
+ drm_framebuffer_put(plane->old_fb);
}
plane->old_fb = NULL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 45c99de350c1..1599a2acf7aa 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3151,7 +3151,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct
drm_plane *plane,
memcpy(state, plane->state, sizeof(*state));
if (state->fb)
- drm_framebuffer_reference(state->fb);
+ drm_framebuffer_get(state->fb);
state->fence = NULL;
}
@@ -3191,7 +3191,7 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_duplicate_state);
void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state)
{
if (state->fb)
- drm_framebuffer_unreference(state->fb);
+ drm_framebuffer_put(state->fb);
if (state->fence)
dma_fence_put(state->fence);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9594c623799b..e2974d3c92e7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -471,9 +471,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
drm_for_each_crtc(tmp, crtc->dev) {
if (tmp->primary->fb)
- drm_framebuffer_reference(tmp->primary->fb);
+ drm_framebuffer_get(tmp->primary->fb);
if (tmp->primary->old_fb)
- drm_framebuffer_unreference(tmp->primary->old_fb);
+ drm_framebuffer_put(tmp->primary->old_fb);
tmp->primary->old_fb = NULL;
}
@@ -567,7 +567,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
fb = crtc->primary->fb;
/* Make refcounting symmetric with the lookup path. */
- drm_framebuffer_reference(fb);
+ drm_framebuffer_get(fb);
} else {
fb = drm_framebuffer_lookup(dev, crtc_req->fb_id);
if (!fb) {
@@ -680,7 +680,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
out:
if (fb)
- drm_framebuffer_unreference(fb);
+ drm_framebuffer_put(fb);
if (connector_set) {
for (i = 0; i < crtc_req->count_connectors; i++) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 11daa24692aa..5e8e1d06866a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -52,13 +52,13 @@
* metadata fields.
*
[PATCH v3 7/7] drm: Rename connector list iterator API
From: Thierry Reding
Currently the functions that initialize and tear down a connector
iterator use the _get() and _put() suffixes. However, these suffixes
are typically used by reference counting functions.
Make these function names a little more consistent by changing the
suffixes to _begin() and _end(), which is a fairly common pattern in
the rest of the Linux kernel.
Suggested-by: Jani Nikula
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c| 10 +-
drivers/gpu/drm/drm_atomic_helper.c | 18 +-
drivers/gpu/drm/drm_connector.c | 24
drivers/gpu/drm/drm_crtc_helper.c | 36 ++--
drivers/gpu/drm/drm_encoder.c | 6 +++---
drivers/gpu/drm/drm_fb_helper.c | 4 ++--
drivers/gpu/drm/drm_mode_config.c | 18 +-
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
drivers/gpu/drm/drm_probe_helper.c | 12 ++--
include/drm/drm_connector.h | 12 ++--
10 files changed, 72 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ff5f1756a7ff..3e7c403af922 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1421,18 +1421,18 @@ drm_atomic_add_affected_connectors(struct
drm_atomic_state *state,
* Changed connectors are already in @state, so only need to look at the
* current configuration.
*/
- drm_connector_list_iter_get(state->dev, &conn_iter);
+ drm_connector_list_iter_begin(state->dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
if (connector->state->crtc != crtc)
continue;
conn_state = drm_atomic_get_connector_state(state, connector);
if (IS_ERR(conn_state)) {
- drm_connector_list_iter_put(&conn_iter);
+ drm_connector_list_iter_end(&conn_iter);
return PTR_ERR(conn_state);
}
}
- drm_connector_list_iter_put(&conn_iter);
+ drm_connector_list_iter_end(&conn_iter);
return 0;
}
@@ -1694,10 +1694,10 @@ void drm_state_dump(struct drm_device *dev, struct
drm_printer *p)
list_for_each_entry(crtc, &config->crtc_list, head)
drm_atomic_crtc_print_state(p, crtc->state);
- drm_connector_list_iter_get(dev, &conn_iter);
+ drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter)
drm_atomic_connector_print_state(p, connector->state);
- drm_connector_list_iter_put(&conn_iter);
+ drm_connector_list_iter_end(&conn_iter);
}
EXPORT_SYMBOL(drm_state_dump);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6f94fca4c601..3c2c07ff7168 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -145,7 +145,7 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
* and the crtc is disabled if no encoder is left. This preserves
* compatibility with the legacy set_config behavior.
*/
- drm_connector_list_iter_get(state->dev, &conn_iter);
+ drm_connector_list_iter_begin(state->dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
struct drm_crtc_state *crtc_state;
@@ -193,7 +193,7 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
}
}
out:
- drm_connector_list_iter_put(&conn_iter);
+ drm_connector_list_iter_end(&conn_iter);
return ret;
}
@@ -2429,7 +2429,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
state->acquire_ctx = ctx;
- drm_connector_list_iter_get(dev, &conn_iter);
+ drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(conn, &conn_iter) {
struct drm_crtc *crtc = conn->state->crtc;
struct drm_crtc_state *crtc_state;
@@ -2448,7 +2448,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
err = drm_atomic_commit(state);
free:
- drm_connector_list_iter_put(&conn_iter);
+ drm_connector_list_iter_end(&conn_iter);
drm_atomic_state_put(state);
return err;
}
@@ -2940,7 +2940,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector
*connector,
WARN_ON(!drm_modeset_is_locked(&config->connection_mutex));
- drm_connector_list_iter_get(connector->dev, &conn_iter);
+ drm_connector_list_iter_begin(connector->dev, &conn_iter);
drm_for_each_connector_iter(tmp_connector, &conn_iter) {
if (tmp_connector->state->crtc != crtc)
continue;
@@ -2950,7 +2950,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector
*connector,
break;
}
[PATCH v3 2/7] drm: Introduce drm_mode_object_{get,put}()
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_mode_object_get() and drm_mode_object_put() to reference count DRM
mode objects.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
A semantic patch is provided that can be used to convert all drivers to
the new helpers.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c | 14 +--
drivers/gpu/drm/drm_mode_object.c| 26 ++--
drivers/gpu/drm/drm_property.c | 6 ++---
include/drm/drm_mode_object.h| 36 ++-
scripts/coccinelle/api/drm-get-put.cocci | 42
5 files changed, 95 insertions(+), 29 deletions(-)
create mode 100644 scripts/coccinelle/api/drm-get-put.cocci
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a5673107db26..2bb0a759e8ec 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2122,13 +2122,13 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
}
if (!obj->properties) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
if (get_user(count_props, count_props_ptr + copied_objs)) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
@@ -2141,14 +2141,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_property *prop;
if (get_user(prop_id, props_ptr + copied_props)) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
prop = drm_mode_obj_find_prop_id(obj, prop_id);
if (!prop) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
ret = -ENOENT;
goto out;
}
@@ -2156,14 +2156,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
if (copy_from_user(&prop_value,
prop_values_ptr + copied_props,
sizeof(prop_value))) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
ret = -EFAULT;
goto out;
}
ret = atomic_set_prop(state, obj, prop, prop_value);
if (ret) {
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
goto out;
}
@@ -2176,7 +2176,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
plane_mask |= (1 << drm_plane_index(plane));
plane->old_fb = plane->fb;
}
- drm_mode_object_unreference(obj);
+ drm_mode_object_put(obj);
}
ret = prepare_crtc_signaling(dev, state, arg, file_priv, &fence_state,
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index 3b405dbf1b8d..da9a9adbcc98 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -133,7 +133,7 @@ struct drm_mode_object *__drm_mode_object_find(struct
drm_device *dev,
*
* This function is used to look up a modeset object. It will acquire a
* reference for reference counted objects. This reference must be dropped
again
- * by callind drm_mode_object_unreference().
+ * by callind drm_mode_object_put().
*/
struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
uint32_t id, uint32_t type)
@@ -146,38 +146,38 @@ struct drm_mode_object *drm_mode_object_find(struct
drm_device *dev,
EXPORT_SYMBOL(drm_mode_object_find);
/**
- * drm_mode_object_unreference - decr the object refcnt
- * @obj: mode_object
+ * drm_mode_object_put - release a mode object reference
+ * @obj: DRM mode object
*
* This function decrements the object's refcount if it is a refcounted modeset
* object. It is a no-op on any other object. This is used to drop references
- * acquired with drm_mode_object_reference().
+ * acquired with drm_mode_object_get().
[PATCH v3 3/7] drm: Introduce drm_connector_{get,put}()
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_connector_get() and drm_connector_put() functions to reference count
connectors.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
The existing semantic patch for mode object reference count conversion
is extended for these new helpers.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c | 8 +++
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 10
drivers/gpu/drm/drm_crtc.c | 2 +-
drivers/gpu/drm/drm_crtc_helper.c| 6 ++---
drivers/gpu/drm/drm_fb_helper.c | 12 +-
drivers/gpu/drm/drm_mode_config.c| 2 +-
include/drm/drm_connector.h | 41 +---
scripts/coccinelle/api/drm-get-put.cocci | 10
9 files changed, 65 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2bb0a759e8ec..82bad40b2f3e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -150,7 +150,7 @@ void drm_atomic_state_default_clear(struct drm_atomic_state
*state)
state->connectors[i].state);
state->connectors[i].ptr = NULL;
state->connectors[i].state = NULL;
- drm_connector_unreference(connector);
+ drm_connector_put(connector);
}
for (i = 0; i < config->num_crtc; i++) {
@@ -1026,7 +1026,7 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
if (!connector_state)
return ERR_PTR(-ENOMEM);
- drm_connector_reference(connector);
+ drm_connector_get(connector);
state->connectors[index].state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
@@ -1357,7 +1357,7 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
- drm_connector_unreference(conn_state->connector);
+ drm_connector_put(conn_state->connector);
conn_state->crtc = NULL;
}
@@ -1369,7 +1369,7 @@ drm_atomic_set_crtc_for_connector(struct
drm_connector_state *conn_state,
crtc_state->connector_mask |=
1 << drm_connector_index(conn_state->connector);
- drm_connector_reference(conn_state->connector);
+ drm_connector_get(conn_state->connector);
conn_state->crtc = crtc;
DRM_DEBUG_ATOMIC("Link connector state %p to [CRTC:%d:%s]\n",
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 01d936b7be43..45c99de350c1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3272,7 +3272,7 @@ __drm_atomic_helper_connector_duplicate_state(struct
drm_connector *connector,
{
memcpy(state, connector->state, sizeof(*state));
if (state->crtc)
- drm_connector_reference(connector);
+ drm_connector_get(connector);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_duplicate_state);
@@ -3398,7 +3398,7 @@ void
__drm_atomic_helper_connector_destroy_state(struct drm_connector_state *state)
{
if (state->crtc)
- drm_connector_unreference(state->connector);
+ drm_connector_put(state->connector);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0616062b055a..0dc0e5b33f8a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -35,8 +35,8 @@
* als fixed panels or anything else that can display pixels in some form. As
* opposed to all other KMS objects representing hardware (like CRTC, encoder
or
* plane abstractions) connectors can be hotplugged and unplugged at runtime.
- * Hence they are reference-counted using drm_connector_reference() and
- * drm_connector_unreference().
+ * Hence they are reference-counted using drm_connector_get() and
+ * drm_connector_put().
*
* KMS driver must create, initialize, register and attach at a &struct
* drm_connector for each such sink. The instance is created as other KMS
@@ -545,7 +545,7 @@ drm_connector_list_iter_next(struct drm_connector_list_iter
*iter)
spin_unlock_irqrestore(&config->connector_list_lock, flags);
if (old_conn)
- drm_connector_unreference(old_conn);
+ drm_connector_put(old_conn);
return iter->conn;
}
@@ -564,7 +564
[PATCH v3 5/7] drm: Introduce drm_gem_object_{get,put}()
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_gem_object_get() and drm_gem_object_put(), as well as an unlocked
variant of the latter, to reference count GEM buffer objects.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
The existing semantic patch for the DRM subsystem-wide conversion is
extended to account for these new helpers.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
Documentation/gpu/drm-mm.rst | 14 +++---
drivers/gpu/drm/drm_fb_cma_helper.c | 16 +++
drivers/gpu/drm/drm_gem.c| 44 +-
drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++--
drivers/gpu/drm/drm_prime.c | 10 ++--
include/drm/drm_gem.h| 80 +---
scripts/coccinelle/api/drm-get-put.cocci | 20
7 files changed, 130 insertions(+), 64 deletions(-)
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index f5760b140f13..fd35998acefc 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -183,14 +183,12 @@ GEM Objects Lifetime
All GEM objects are reference-counted by the GEM core. References can be
-acquired and release by :c:func:`calling
-drm_gem_object_reference()` and
-:c:func:`drm_gem_object_unreference()` respectively. The caller
-must hold the :c:type:`struct drm_device `
-struct_mutex lock when calling
-:c:func:`drm_gem_object_reference()`. As a convenience, GEM
-provides :c:func:`drm_gem_object_unreference_unlocked()`
-functions that can be called without holding the lock.
+acquired and release by :c:func:`calling drm_gem_object_get()` and
+:c:func:`drm_gem_object_put()` respectively. The caller must hold the
+:c:type:`struct drm_device ` struct_mutex lock when calling
+:c:func:`drm_gem_object_get()`. As a convenience, GEM provides
+:c:func:`drm_gem_object_put_unlocked()` functions that can be called without
+holding the lock.
When the last reference to a GEM object is released the GEM core calls
the :c:type:`struct drm_driver ` gem_free_object
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 596fabf18c3e..eccc07d20925 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -102,7 +102,7 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb)
for (i = 0; i < 4; i++) {
if (fb_cma->obj[i])
-
drm_gem_object_unreference_unlocked(&fb_cma->obj[i]->base);
+ drm_gem_object_put_unlocked(&fb_cma->obj[i]->base);
}
drm_framebuffer_cleanup(fb);
@@ -190,7 +190,7 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
if (!obj) {
dev_err(dev->dev, "Failed to lookup GEM object\n");
ret = -ENXIO;
- goto err_gem_object_unreference;
+ goto err_gem_object_put;
}
min_size = (height - 1) * mode_cmd->pitches[i]
@@ -198,9 +198,9 @@ struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct
drm_device *dev,
+ mode_cmd->offsets[i];
if (obj->size < min_size) {
- drm_gem_object_unreference_unlocked(obj);
+ drm_gem_object_put_unlocked(obj);
ret = -EINVAL;
- goto err_gem_object_unreference;
+ goto err_gem_object_put;
}
objs[i] = to_drm_gem_cma_obj(obj);
}
@@ -208,14 +208,14 @@ struct drm_framebuffer
*drm_fb_cma_create_with_funcs(struct drm_device *dev,
fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
if (IS_ERR(fb_cma)) {
ret = PTR_ERR(fb_cma);
- goto err_gem_object_unreference;
+ goto err_gem_object_put;
}
return &fb_cma->fb;
-err_gem_object_unreference:
+err_gem_object_put:
for (i--; i >= 0; i--)
- drm_gem_object_unreference_unlocked(&objs[i]->base);
+ drm_gem_object_put_unlocked(&objs[i]->base);
return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
@@ -477,7 +477,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
err_fb_info_destroy:
drm_fb_helper_release_fbi(helper);
err_gem_free_object:
- drm_gem_object_unreference_unlocked(&obj->base);
+ drm_gem_object_put_unlocked(&obj->base);
return ret;
}
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index bc93de308673..b1e28c944637 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -218,7 +218,7 @@ static void drm_gem_object_exported_dma_
[PATCH v3 0/7] drm: Introduce consistent reference counting APIs
From: Thierry Reding
This series introduces DRM reference counting APIs that are consistent
with other reference counting APIs in the kernel. They are also much
shorter. Compatibility aliases are added to keep existing code working
and will stay in place until all users of the old APIs are gone.
All occurrences of the old APIs in the core are already replaced by
this series, and a semantic patch is provided that allows drivers to
be converted automatically. I plan on generating patches against the
drivers once the new functions have been merged and send them out to
their respective maintainers.
Oh, and this fixes one of the items in our recently added TODO list.
Changes in v3:
- fix build error
Changes in v2:
- add patch to rename drm_connector_list_iter_{get,put}() because they
aren't in fact reference counting
- add Reviewed-by from Sean, Acked-by from Christian
- left in the semantic patch for convenience, it can be removed along
with the compatibility functions
Thanks,
Thierry
Thierry Reding (7):
drm: Rename drm_mode_object_get()
drm: Introduce drm_mode_object_{get,put}()
drm: Introduce drm_connector_{get,put}()
drm: Introduce drm_framebuffer_{get,put}()
drm: Introduce drm_gem_object_{get,put}()
drm: Introduce drm_property_blob_{get,put}()
drm: Rename connector list iterator API
Documentation/gpu/drm-mm.rst | 14 +++--
drivers/gpu/drm/drm_atomic.c | 54 +--
drivers/gpu/drm/drm_atomic_helper.c | 44 +++
drivers/gpu/drm/drm_connector.c | 40 +++---
drivers/gpu/drm/drm_crtc.c | 12 ++---
drivers/gpu/drm/drm_crtc_helper.c| 42 +++
drivers/gpu/drm/drm_crtc_internal.h | 12 ++---
drivers/gpu/drm/drm_encoder.c| 8 +--
drivers/gpu/drm/drm_fb_cma_helper.c | 16 +++---
drivers/gpu/drm/drm_fb_helper.c | 16 +++---
drivers/gpu/drm/drm_framebuffer.c| 38 ++---
drivers/gpu/drm/drm_gem.c| 44 +++
drivers/gpu/drm/drm_gem_cma_helper.c | 10 ++--
drivers/gpu/drm/drm_mode_config.c| 22
drivers/gpu/drm/drm_mode_object.c| 44 +++
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/gpu/drm/drm_plane.c | 14 ++---
drivers/gpu/drm/drm_plane_helper.c | 4 +-
drivers/gpu/drm/drm_prime.c | 10 ++--
drivers/gpu/drm/drm_probe_helper.c | 12 ++---
drivers/gpu/drm/drm_property.c | 52 +-
include/drm/drm_connector.h | 51 +-
include/drm/drm_framebuffer.h| 49 -
include/drm/drm_gem.h| 80 +--
include/drm/drm_mode_object.h| 36 ++---
include/drm/drm_property.h | 35 ++--
scripts/coccinelle/api/drm-get-put.cocci | 92
27 files changed, 542 insertions(+), 311 deletions(-)
create mode 100644 scripts/coccinelle/api/drm-get-put.cocci
--
2.11.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/7] drm: Introduce drm_property_blob_{get,put}()
From: Thierry Reding
For consistency with other reference counting APIs in the kernel, add
drm_property_blob_get() and drm_property_blob_put() to reference count
DRM blob properties.
Compatibility aliases are added to keep existing code working. To help
speed up the transition, all the instances of the old functions in the
DRM core are already replaced in this commit.
A semantic patch is provided that can be used to convert all drivers to
the new helpers.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic.c | 16 ++---
drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
drivers/gpu/drm/drm_mode_config.c| 2 +-
drivers/gpu/drm/drm_property.c | 40
include/drm/drm_property.h | 35
scripts/coccinelle/api/drm-get-put.cocci | 10
6 files changed, 78 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 740650b450c5..ff5f1756a7ff 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -322,7 +322,7 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state
*state,
if (mode && memcmp(&state->mode, mode, sizeof(*mode)) == 0)
return 0;
- drm_property_unreference_blob(state->mode_blob);
+ drm_property_blob_put(state->mode_blob);
state->mode_blob = NULL;
if (mode) {
@@ -368,7 +368,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state
*state,
if (blob == state->mode_blob)
return 0;
- drm_property_unreference_blob(state->mode_blob);
+ drm_property_blob_put(state->mode_blob);
state->mode_blob = NULL;
memset(&state->mode, 0, sizeof(state->mode));
@@ -380,7 +380,7 @@ int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state
*state,
blob->data))
return -EINVAL;
- state->mode_blob = drm_property_reference_blob(blob);
+ state->mode_blob = drm_property_blob_get(blob);
state->enable = true;
DRM_DEBUG_ATOMIC("Set [MODE:%s] for CRTC state %p\n",
state->mode.name, state);
@@ -413,9 +413,9 @@ drm_atomic_replace_property_blob(struct drm_property_blob
**blob,
if (old_blob == new_blob)
return;
- drm_property_unreference_blob(old_blob);
+ drm_property_blob_put(old_blob);
if (new_blob)
- drm_property_reference_blob(new_blob);
+ drm_property_blob_get(new_blob);
*blob = new_blob;
*replaced = true;
@@ -437,13 +437,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_crtc
*crtc,
return -EINVAL;
if (expected_size > 0 && expected_size != new_blob->length) {
- drm_property_unreference_blob(new_blob);
+ drm_property_blob_put(new_blob);
return -EINVAL;
}
}
drm_atomic_replace_property_blob(blob, new_blob, replaced);
- drm_property_unreference_blob(new_blob);
+ drm_property_blob_put(new_blob);
return 0;
}
@@ -478,7 +478,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
- drm_property_unreference_blob(mode);
+ drm_property_blob_put(mode);
return ret;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(crtc,
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 1599a2acf7aa..6f94fca4c601 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3042,13 +3042,13 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
memcpy(state, crtc->state, sizeof(*state));
if (state->mode_blob)
- drm_property_reference_blob(state->mode_blob);
+ drm_property_blob_get(state->mode_blob);
if (state->degamma_lut)
- drm_property_reference_blob(state->degamma_lut);
+ drm_property_blob_get(state->degamma_lut);
if (state->ctm)
- drm_property_reference_blob(state->ctm);
+ drm_property_blob_get(state->ctm);
if (state->gamma_lut)
- drm_property_reference_blob(state->gamma_lut);
+ drm_property_blob_get(state->gamma_lut);
state->mode_changed = false;
state->active_changed = false;
state->planes_changed = false;
@@ -3092,10 +3092,10 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_sta
[PATCH v3 1/7] drm: Rename drm_mode_object_get()
From: Thierry Reding
Subsequent patches will introduce reference counting APIs that are more
consistent with similar APIs throughout the Linux kernel. These APIs use
the _get() and _put() suffixes and will collide with this existing
function.
Rename the function to drm_mode_object_add() which is a slightly more
accurate description of what it does. Also the kerneldoc for this
function gives an indication that it's badly named because it doesn't
actually acquire a reference to anything.
Reviewed-by: Sean Paul
Acked-by: Christian König
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_connector.c | 6 +++---
drivers/gpu/drm/drm_crtc.c | 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 12 +---
drivers/gpu/drm/drm_encoder.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 4 ++--
drivers/gpu/drm/drm_mode_object.c | 18 +++---
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/gpu/drm/drm_plane.c | 2 +-
drivers/gpu/drm/drm_property.c | 6 +++---
9 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 45464c8b797d..0616062b055a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -189,9 +189,9 @@ int drm_connector_init(struct drm_device *dev,
struct ida *connector_ida =
&drm_connector_enum_list[connector_type].ida;
- ret = drm_mode_object_get_reg(dev, &connector->base,
- DRM_MODE_OBJECT_CONNECTOR,
- false, drm_connector_free);
+ ret = __drm_mode_object_add(dev, &connector->base,
+ DRM_MODE_OBJECT_CONNECTOR,
+ false, drm_connector_free);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6915f897bd8e..e2284539f82c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -282,7 +282,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
spin_lock_init(&crtc->commit_lock);
drm_modeset_lock_init(&crtc->mutex);
- ret = drm_mode_object_get(dev, &crtc->base, DRM_MODE_OBJECT_CRTC);
+ ret = drm_mode_object_add(dev, &crtc->base, DRM_MODE_OBJECT_CRTC);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 955c5690bf64..43bbf48ee129 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -98,15 +98,13 @@ int drm_mode_destroyblob_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
/* drm_mode_object.c */
-int drm_mode_object_get_reg(struct drm_device *dev,
- struct drm_mode_object *obj,
- uint32_t obj_type,
- bool register_obj,
- void (*obj_free_cb)(struct kref *kref));
+int __drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj,
+ uint32_t obj_type, bool register_obj,
+ void (*obj_free_cb)(struct kref *kref));
+int drm_mode_object_add(struct drm_device *dev, struct drm_mode_object *obj,
+ uint32_t obj_type);
void drm_mode_object_register(struct drm_device *dev,
struct drm_mode_object *obj);
-int drm_mode_object_get(struct drm_device *dev,
- struct drm_mode_object *obj, uint32_t obj_type);
struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
uint32_t id, uint32_t type);
void drm_mode_object_unregister(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 129450713bb7..634ae0244ea9 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -110,7 +110,7 @@ int drm_encoder_init(struct drm_device *dev,
{
int ret;
- ret = drm_mode_object_get(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
+ ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 28a0108a1ab8..11daa24692aa 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -638,8 +638,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
fb->funcs = funcs;
- ret = drm_mode_object_get_reg(dev, &fb->base, DRM_MODE_OBJECT_FB,
- false, drm_framebuffer_free);
+ ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB,
+ false, drm_framebuffer_free);
if (ret)
goto out;
d
Re: [RESEND PATCH 00/14] QXL atomic modesetting
On Di, 2017-02-28 at 14:29 +0100, Gerd Hoffmann wrote: > On Mo, 2017-02-27 at 17:43 -0300, Gabriel Krisman Bertazi wrote: > > Hi, > > > > This is a resend of the qxl atomic modesetting patchset to include the > > reviewed-by tags from Gustavo and rebase on top of the tip of drm-misc-next. > > > > This series implements support for Atomic Modesetting in the QXL driver. > > The first 4 patches in the series are some cleanups to prepare the > > ground, while the rest implement Atomic in 3 phases, as suggested by > > Daniel's blog post[1]. > > > > Testing was done with the X server, igt, libdrm testsuit and some custom > > code that I can share if requested. I hope this covers the main use > > cases. > > Hmm, throws a "unpin not necessary" now and then, when switching > runlevels. Not every time, usually have to switch from 5 to 3 and back > a few times to see it. Oops, scratch that, error in my setup, tested wrong branch, sorry. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 4.11-rc0, thinkpad x220: GPU hang
On Tue, Feb 28, 2017 at 03:34:53PM +0100, Pavel Machek wrote: > Hi! > > mplayer stopped working after a while. Dmesg says: > > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > usb-:00:1d.0-1.2, CDC Ethernet Device, 22:1b:e4:4e:56:f5 > [ 3190.767227] [drm] GPU HANG: ecode 6:0:0xbb409fff, in chromium > [4597], reason: Hang on render ring, action: reset > [ 3190.767311] [drm] GPU hangs can indicate a bug anywhere in the > entire gfx stack, including userspace. > [ 3190.767313] [drm] Please file a _new_ bug report on > bugs.freedesktop.org against DRI -> DRM/Intel > [ 3190.767315] [drm] drm/i915 developers can then reassign to the > right component if it's not a kernel issue. > [ 3190.767317] [drm] The gpu crash dump is required to analyze gpu > hangs, so please always attach it. > [ 3190.767320] [drm] GPU crash dump saved to > /sys/class/drm/card0/error > [ 3190.767427] drm/i915: Resetting chip after gpu hang > [ 3228.329384] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been > dropped > [ 3228.329604] cdc_ether 2-1.2:1.0 usb0: kevent 12 may have been > dropped > [ 3877.246261] perf: interrupt took too long (3142 > 3133), lowering > kernel.perf_event_max_sample_rate to 63500 > [ 4802.784478] drm/i915: Resetting chip after gpu hang > [ 4810.784851] drm/i915: Resetting chip after gpu hang > [ 4829.829795] drm/i915: Resetting chip after gpu hang > [ 4837.826154] drm/i915: Resetting chip after gpu hang > [ 5125.026814] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308257 end=308258) time 203 us, min 763, max > 767, scanline start 761, end 771 > [ 5125.192602] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe B (start=307385 end=307386) time 204 us, min 1073, max > 1079, scanline start 1071, end 1086 > [ 5125.309992] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308274 end=308275) time 203 us, min 763, max > 767, scanline start 758, end 768 > [ 5125.460013] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308283 end=308284) time 204 us, min 763, max > 767, scanline start 761, end 771 > [ 5125.493340] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308285 end=308286) time 202 us, min 763, max > 767, scanline start 761, end 771 > [ 5125.526684] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308287 end=308288) time 204 us, min 763, max > 767, scanline start 762, end 772 > [ 5125.593245] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308291 end=308292) time 203 us, min 763, max > 767, scanline start 758, end 768 > [ 5125.676636] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308296 end=308297) time 202 us, min 763, max > 767, scanline start 762, end 772 > [ 5125.709960] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308298 end=308299) time 203 us, min 763, max > 767, scanline start 762, end 772 > [ 5126.093109] [drm:intel_pipe_update_end] *ERROR* Atomic update > failure on pipe A (start=308321 end=308322) time 204 us, min 763, max > 767, scanline start 759, end 770 > [ 5647.879171] drm/i915: Resetting chip after gpu hang > [ 5655.879507] drm/i915: Resetting chip after gpu hang > [ 5850.864464] drm/i915: Resetting chip after gpu hang > [ 5858.864853] drm/i915: Resetting chip after gpu hang > [ 5904.850879] drm/i915: Resetting chip after gpu hang > [ 5912.851252] drm/i915: Resetting chip after gpu hang > [ 5949.876973] drm/i915: Resetting chip after gpu hang > [ 5957.877460] drm/i915: Resetting chip after gpu hang > [ 6018.872153] drm/i915: Resetting chip after gpu hang > [ 6030.872646] drm/i915: Resetting chip after gpu hang > [ 7108.362610] perf: interrupt took too long (3935 > 3927), lowering > kernel.perf_event_max_sample_rate to 50750 > [ 9670.047072] drm/i915: Resetting chip after gpu hang > [ 9678.047415] drm/i915: Resetting chip after gpu hang > [10408.064806] drm/i915: Resetting chip after gpu hang > [10416.097168] drm/i915: Resetting chip after gpu hang > [10416.097181] [drm:i915_reset] *ERROR* GPU recovery failed > pavel@duo:/data/film$ > > Umm. Dmesg wants me to attach card0/error, but it looks like it > contains quite a lot of data. If it contains actual framebuffer > content, it may not be wise to post to mailing list It contains command and register states. No pixel data unless userspace got particularly creative with its memory corruption. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97590] Fury X (Fiji) LEDs do not reflect GPU load
https://bugs.freedesktop.org/show_bug.cgi?id=97590 --- Comment #15 from Alex Deucher --- (In reply to Vedran Miletić from comment #14) > (In reply to Adam Bolte from comment #9) > > The only difference between this patch and the Windows behaviour is with the > > second card at idle - Windows will display only a single green LED which I > > believe indicates the card is in its lowest power mode. I was unable to > > reproduce that same status with your patch. However I'm guessing this means > > Windows puts the unused card in to a lower power state than AMDGPU is > > currently able, and the LEDs are actually doing the right thing. No big deal > > either way. > > Alex, can you comment on this? Is it a known issue? Windows powers down dGPUs when they are not in use. This is not supported yet in Linux outside of PX systems. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ABI navigator for libdrm
On Tue, Feb 28, 2017 at 8:11 AM, Andrey Ponomarenko wrote: > 27.02.2017, 15:30, "Rob Clark": >> On Mon, Feb 27, 2017 at 1:41 AM, Andrey Ponomarenko: >>> 26.02.2017, 22:15, "Daniel Vetter": On Sun, Feb 26, 2017 at 10:51 AM, Andrey Ponomarenko: > Hello, > > I'd like to present the ABI Navigator project to search for binary > symbols (functions, global data, etc.) across recent versions of the > libdrm > and other open-source libraries: > https://abi-laboratory.pro/index.php?view=navigator > > The project allows to find out in which versions of the library some > symbol is defined, added, removed or changed. The data is taken from the > ABI > Tracker report for the library: > https://abi-laboratory.pro/tracker/timeline/libdrm/ > > Example for symbol drmGetDevice from libdrm.so: > https://abi-laboratory.pro/index.php?view=navigator&selected=drmGetDevice > > The project aims to help library users and maintainers to resolve > issues with missed symbols and navigate through the reports in the ABI > Tracker. > > Have you ever encountered the "undefined reference" error or want to > know whether the symbol is _stable_ enough to import by your code? Try to > find it in the ABI Navigator! Looks pretty cool. One small suggestion for the UI: Adding separate columns for object/struct changes would be good. Atm it's harder to find these, and e.g. libdrm has a releases with 100% abi compat rating, but still yellow box. The yellow box is because we extended some structs - direct links to those sections would be nice too. >>> >>> Added the "Total Changes" column to the report table: >>> https://abi-laboratory.pro/tracker/timeline/libdrm/ >> >> Cool >> >> Any chance you could add to configure line: --enable-freedreno >> --enable-vc4 and possibly --etnaviv-experimental-api >> >> It should be possible to compile test and check abi for the libdrm >> modules for arm drivers (but by default they are only enabled for arm >> builds) >> > > Done: https://abi-laboratory.pro/tracker/timeline/libdrm/ very cool, thanks BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/1] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.
Signed-off-by: Maxime Ripard
Tested-by: Neil Armstrong
---
drivers/gpu/drm/drm_fb_helper.c | 68 ++-
include/drm/drm_fb_helper.h | 12 +-
2 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index c6de87abaca8..8ac8716c023a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1240,6 +1240,74 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
EXPORT_SYMBOL(drm_fb_helper_setcmap);
/**
+ * drm_fb_helper_ioctl - legacy ioctl implementation
+ * @info: fbdev registered by the helper
+ * @cmd: ioctl command
+ * @arg: ioctl argument
+ *
+ * A helper to implement the standard fbdev ioctl. Only
+ * FBIO_WAITFORVSYNC is implemented for now.
+ */
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+ struct drm_mode_set *mode_set;
+ struct drm_crtc *crtc;
+ int ret = 0;
+
+ mutex_lock(&dev->mode_config.mutex);
+ if (!drm_fb_helper_is_bound(fb_helper)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:
+ /*
+* Only consider the first CRTC.
+*
+* This ioctl is supposed to take the CRTC number as
+* an argument, but in fbdev times, what that number
+* was supposed to be was quite unclear, different
+* drivers were passing that argument differently
+* (some by reference, some by value), and most of the
+* userspace applications were just hardcoding 0 as an
+* argument.
+*
+* The first CRTC should be the integrated panel on
+* most drivers, so this is the best choice we can
+* make. If we're not smart enough here, one should
+* just consider switch the userspace to KMS.
+*/
+ mode_set = &fb_helper->crtc_info[0].mode_set;
+ crtc = mode_set->crtc;
+
+ /*
+* Only wait for a vblank event if the CRTC is
+* enabled, otherwise just don't do anythintg,
+* not even report an error.
+*/
+ ret = drm_crtc_vblank_get(crtc);
+ if (!ret) {
+ drm_crtc_wait_one_vblank(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+
+ ret = 0;
+ goto unlock;
+ default:
+ ret = -ENOTTY;
+ }
+
+unlock:
+ mutex_unlock(&dev->mode_config.mutex);
+ return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_ioctl);
+
+/**
* drm_fb_helper_check_var - implementation for ->fb_check_var
* @var: screeninfo to check
* @info: fbdev registered by the helper
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 975deedd593e..2891888c6e41 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,7 +230,8 @@ struct drm_fb_helper {
.fb_blank = drm_fb_helper_blank, \
.fb_pan_display = drm_fb_helper_pan_display, \
.fb_debug_enter = drm_fb_helper_debug_enter, \
- .fb_debug_leave = drm_fb_helper_debug_leave
+ .fb_debug_leave = drm_fb_helper_debug_leave, \
+ .fb_ioctl = drm_fb_helper_ioctl
#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
@@ -286,6 +287,9 @@ void drm_fb_helper_set_suspend_unlocked(struct
drm_fb_helper *fb_helper,
int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg);
+
int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
@@ -377,6 +381,12 @@ static inline int drm_fb_helper_setcmap(struct fb_cmap
*cmap,
return 0;
}
+static inline int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
+ unsigned long arg)
+{
+ return 0;
+}
+
static inline void drm_fb_helper_unlink_fbi(struct drm_fb_helper *fb_helper)
{
}
--
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
[PATCH v4 0/1] drm: Support framebuffer panning
Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v3: - Dropped the overallocation patch that has been applied - Change authorship of the second patch as suggested by Stefan, the original author - Only consider the first CRTC and ignore the ioctl argument Changes from v2: - Renamed the CONFIG_DRM_CMA_FBDEV_BUFFER_NUM to CONFIG_DRM_FBDEV_OVERALLOC, and changed it for a percentage - Moved the overallocation code into the core fbdev helpers to not rely on CMA anymore - Changed the locks taken by drm_fb_helper_ioctl to the mode_config mutex intead of calling drm_modeset_lock_all - Don't test against drm_crtc's enabled anymore, but rely on the error code of drm_crtc_vblank_get instead - Defined drm_fb_helper_ioctl when DRM_FBDEV_EMULATION is not set in order to fix a compilation error - Don't wait for all CRTC's vblank but only the one given in the ioctl argument Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Maxime Ripard (1): drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC drivers/gpu/drm/drm_fb_helper.c | 68 ++- include/drm/drm_fb_helper.h | 12 +- 2 files changed, 79 insertions(+), 1 deletion(-) base-commit: 075ffb50cc16ab055b5d47b30163401bb356ab51 -- git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99850] Tessellation bug on Carrizo
https://bugs.freedesktop.org/show_bug.cgi?id=99850 Samuel Pitoiset changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #12 from Samuel Pitoiset --- Should be fixed by 35915af6c9ab4bdc0f1f8584ca346602405bd7e4. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format
On 02/28/2017 03:56 AM, Ville Syrjälä wrote:
On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c |4
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+ /* FIXME a pixel in Y for P010 is 10 bits */
+ { .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+ { .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
Your Cb and Cr look swapped (unless my memory is playing tricks on me).
This is the information I have:
Y UV
YUV 4:2:0 8 bpc - NV12 7:0 15:8 7:0
YUV 4:2:0 10 bpc - P010 15:6 31:22 15:6
YUV 4:2:0 12 bpc - P012 15:4 31:20 15:4
YUV 4:2:0 16 bpc - P016 15:0 31:16 15:0
-clint
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format
On Tue, Feb 28, 2017 at 08:08:55AM -0800, Clint Taylor wrote:
> On 02/28/2017 03:56 AM, Ville Syrjälä wrote:
> > On Mon, Feb 27, 2017 at 02:57:58PM -0800, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor
> >>
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> >> channel video format. Rockchip's vop support this video format(little
> >> endian only) as the input video format.
> >>
> >> P016 is a planar 4:2:0 YUV 12 bits per channel
> >>
> >> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> >> channel video format.
> >>
> >> V3: Added P012 and fixed cpp for P010
> >> V4: format definition refined per review
> >> V5: Format comment block for each new pixel format
> >>
> >> Cc: Daniel Stone
> >> Cc: Ville Syrjälä
> >>
> >> Signed-off-by: Randy Li
> >> Signed-off-by: Clint Taylor
> >> ---
> >> drivers/gpu/drm/drm_fourcc.c |4
> >> include/uapi/drm/drm_fourcc.h | 21 +
> >> 2 files changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index 90d2cc8..5494764 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -165,6 +165,10 @@ const struct drm_format_info *__drm_format_info(u32
> >> format)
> >>{ .format = DRM_FORMAT_UYVY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> >>{ .format = DRM_FORMAT_VYUY,.depth = 0,
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> >>{ .format = DRM_FORMAT_AYUV,.depth = 0,
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> >> + /* FIXME a pixel in Y for P010 is 10 bits */
> >> + { .format = DRM_FORMAT_P010,.depth = 0,
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >> + { .format = DRM_FORMAT_P012,.depth = 0,
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >> + { .format = DRM_FORMAT_P016,.depth = 0,
> >> .num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> >>};
> >>
> >>unsigned int i;
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index ef20abb..306f979 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -128,6 +128,27 @@
> >> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> >> non-subsampled Cb:Cr plane */
> >>
> >> /*
> >> + * 2 plane YCbCr MSB aligned
> >> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> >> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
> >> + */
> >
> > Your Cb and Cr look swapped (unless my memory is playing tricks on me).
>
> This is the information I have:
> Y UV
> YUV 4:2:0 8 bpc - NV12 7:0 15:8 7:0
> YUV 4:2:0 10 bpc - P010 15:6 31:22 15:6
> YUV 4:2:0 12 bpc - P012 15:4 31:20 15:4
> YUV 4:2:0 16 bpc - P016 15:0 31:16 15:0
I don't think those match the MS docs
https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578%28v=vs.85%29.aspx
>
> -clint
>
> >
> >> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> >> subsampled Cb:Cr plane 10 bits per channel */
> >> +
> >> +/*
> >> + * 2 plane YCbCr MSB aligned
> >> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> >> + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
> >> + */
> >> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> >> subsampled Cb:Cr plane 12 bits per channel */
> >> +
> >> +/*
> >> + * 2 plane YCbCr MSB aligned
> >> + * index 0 = Y plane, [15:0] Y little endian
> >> + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
> >> + */
> >> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> >> subsampled Cb:Cr plane 16 bits per channel */
> >> +
> >> +/*
> >> * 3 plane YCbCr
> >> * index 0: Y plane, [7:0] Y
> >> * index 1: Cb plane, [7:0] Cb
> >> --
> >> 1.7.9.5
> >
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 00/14] QXL atomic modesetting
Hi, > Patches look good, great job. I'll go run some more tests and if all > goes fine I'll push to drm-misc-next. Ok, cool, text console, xorg and wayland all work fine without glitches. Series pushed. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm_fourcc: Add new P010, P016 video format
On 02/28/2017 02:58 AM, ayaka wrote:
On 02/28/2017 06:57 AM, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format. Rockchip's vop support this video format(little
endian only) as the input video format.
P016 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
Cc: Daniel Stone
Cc: Ville Syrjälä
Signed-off-by: Randy Li
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_fourcc.c |4
include/uapi/drm/drm_fourcc.h | 21 +
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 90d2cc8..5494764 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -165,6 +165,10 @@ const struct drm_format_info
*__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0, .num_planes
= 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0, .num_planes
= 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+/* FIXME a pixel in Y for P010 is 10 bits */
You may remove this line, I misunderstand the P010 that time.
That will look better. Thanks.
What I want is adding a new pixel format never be defined before, may it
should be called P010_PACK
We could probably add the PACK variants as DRM_FORMAT_P010V
or something else.
+{ .format = DRM_FORMAT_P010,.depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P012,.depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+{ .format = DRM_FORMAT_P016,.depth = 0, .num_planes
= 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h
b/include/uapi/drm/drm_fourcc.h
index ef20abb..306f979 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -128,6 +128,27 @@
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2
subsampled Cb:Cr plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2
subsampled Cb:Cr plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cb:Cr plane 16 bits per channel */
+
+/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
* index 1: Cb plane, [7:0] Cb
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics
https://bugzilla.kernel.org/show_bug.cgi?id=193341 --- Comment #7 from stefan.ko...@um.si --- Created attachment 254989 --> https://bugzilla.kernel.org/attachment.cgi?id=254989&action=edit Dmesg of 4.10.1-1-ARCH #1 SMP PREEMPT Sun Feb 26 21:08:53 UTC 2017 x86_64 GNU/Linux I'm not sure if all attached fixes were merged to kernel 4.10.1, but now I get different error (when trying to use the discrete GPU). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
