[RFC 1/3] dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701

2016-05-12 Thread Yingjoe Chen
On Thu, 2016-05-12 at 19:49 +0800, yt.shen at mediatek.com wrote:
> From: YT Shen 
> 
> Add device tree binding documentation for the display subsystem in
> Mediatek SoC MT2701
> 
> Signed-off-by: YT Shen 
> ---
>  .../bindings/display/mediatek/mediatek,disp.txt|1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index db6e77e..53b3cc3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -40,6 +40,7 @@ Required properties (all function blocks):
>   "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
>   "mediatek,-disp-mutex" - display mutex
>   "mediatek,-disp-od"- overdrive
> + "mediatek,-disp-bls"   - backlight
>  - reg: Physical base address and length of the function block register space
>  - interrupts: The interrupt signal from the function block (required, except 
> for
>merge and split function blocks).


Hi,

This one is in conflict with "Support Mediatek Soc MT2701 disp pwm"
series Weiqing sent last week, which add disp-bls support to display pwm
driver.

Joe.C




[patch] drm/exynos/hdmi: add a missing tab

2016-05-12 Thread Dan Carpenter
Smatch warns that the if statement isn't indented.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 0f87acb..748e62f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1612,7 +1612,7 @@ static int hdmi_clk_init(struct hdmi_context *hdata)

clks = devm_kzalloc(dev, sizeof(*clks) * count, GFP_KERNEL);
if (!clks)
-   return -ENOMEM;
+   return -ENOMEM;

hdata->clk_gates = clks;
hdata->clk_muxes = clks + drv_data->clk_gates.count;


[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Ville Syrjälä
On Thu, May 12, 2016 at 10:20:12PM +0300, Laurent Pinchart wrote:
> Hi Ville,
> 
> On Thursday 12 May 2016 14:51:55 Ville Syrjälä wrote:
> > On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> > > From: Marek Szyprowski 
> > > 
> > > This patch adds support for generic plane's zpos property property with
> > > well-defined semantics:
> > > - added zpos properties to plane and plane state structures
> > > - added helpers for normalizing zpos properties of given set of planes
> > > - well defined semantics: planes are sorted by zpos values and then plane
> > >   id value if zpos equals
> > > 
> > > Normalized zpos values are calculated automatically when generic
> > > muttable zpos property has been initialized. Drivers can simply use
> > > plane_state->normalized_zpos in their atomic_check and/or plane_update
> > > callbacks without any additional calls to DRM core.
> > > 
> > > Signed-off-by: Marek Szyprowski 
> > > 
> > > Compare to Marek's original patch zpos property is now specific to each
> > > plane and no more to the core.
> > > Normalize function take care of the range of per plane defined range
> > > before set normalized_zpos.
> > > 
> > > Signed-off-by: Benjamin Gaignard 
> > > 
> > > Cc: Inki Dae 
> > > Cc: Daniel Vetter 
> > > Cc: Ville Syrjala 
> > > Cc: Joonyoung Shim 
> > > Cc: Seung-Woo Kim 
> > > Cc: Andrzej Hajda 
> > > Cc: Krzysztof Kozlowski 
> > > Cc: Bartlomiej Zolnierkiewicz 
> > > Cc: Tobias Jakobi 
> > > Cc: Gustavo Padovan 
> > > Cc: vincent.abriou at st.com
> > > Cc: fabien.dessenne at st.com
> > > Cc: Laurent Pinchart 
> > > ---
> > > 
> > >  Documentation/DocBook/gpu.tmpl  |  10 ++
> > >  drivers/gpu/drm/Makefile|   2 +-
> > >  drivers/gpu/drm/drm_atomic.c|   4 +
> > >  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> > >  drivers/gpu/drm/drm_blend.c | 229 +++
> > >  drivers/gpu/drm/drm_crtc_internal.h |   3 +
> > >  include/drm/drm_crtc.h  |  28 +
> > >  7 files changed, 281 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> [snip]
> 
> > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > > new file mode 100644
> > > index 000..eef59bb
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_blend.c
> > > @@ -0,0 +1,229 @@
> 
> [snip]
> 
> > > +static int drm_atomic_state_zpos_cmp(const void *a, const void *b)
> > > +{
> > > + const struct drm_plane_state *sa = *(struct drm_plane_state **)a;
> > > + const struct drm_plane_state *sb = *(struct drm_plane_state **)b;
> > > +
> > > + if (sa->zpos != sb->zpos)
> > > + return sa->zpos - sb->zpos;
> > > + else
> > > + return sa->plane->base.id - sb->plane->base.id;
> > > +}
> > 
> > Still not really convinced this normalization is a good idea when we
> > have atomic. It made sense before atomic since otherwise you might not be
> > able to swap the zpos of two planes without shutting one of them down,
> > but it makes interpreting the zpos prop values more confusing. And with
> > atomic we don't actually need it AFAICS. Or do we have an actual use case
> > for this behaviour?
> 
> Speaking selfishly about my use case (rcar-du-drm), I need to sort planes in 
> display order from 0 to N-1 as that's how the hardware is programmed. 
> Normalization gives me an array of sorted planes, which is exactly what I 
> need. I expect other drivers to have similar requirements, so normalization 
> in 
> the core will allow code sharing.

It just eliminates duplicate zpos values. It won't re-sort your plane
states magically or anything like that. Nor does it guarantee that
the zpos values for the actually visible planes are even contiguous.

> 
> Now, is your concern that allowing two planes to have the same zpos isn't 
> needed with the atomic API ? I agree with that, but it would also make it 
> impossible to swap two planes using the legacy API implemented on top of 
> atomic drivers. I'll let others decide whether this is considered as a 
> concern.
> 
> While at it, Benjamin told me that you've requested configurable min/max 
> values per plane, what are your use cases for that ? On the same topic, 
> please 
> see below.
> 
> > > +
> > > +/**
> > > + * drm_atomic_helper_crtc_normalize_zpos - calculate normalized zpos
> > > values
> > > + * @crtc: crtc with planes, which have to be considered for normalization
> > > + * @crtc_state: new atomic state to apply
> > > + *
> > > + * This function checks new states of all planes assigned to given crtc
> > > and
> > > + * calculates normalized zpos value for them. Planes are compared first
> > > by their
> > > + * zpos values, then by plane id (if zpos equals). Plane with lowest zpos
> > > value
> > > + * is at the bottom. The plane_state->normalized_zpos is then filled with
> > > unique
> > > + * values from 0 to number of active planes in crtc minus one.
> > > + *
> > > + * RETURNS
> > > + * Zero for success or -errno
> > > + */
> 

[PATCH 3/5] drm/dp/mst: change MST detection scheme

2016-05-12 Thread Grodzovsky, Andrey
Hi Dave,

Have you had a chance to see if Mykola's latest patch addresses the issue you 
observed with tiled MST display ?

Thanks.
-Original Message-
From: Lysenko, Mykola 
Sent: Monday, February 22, 2016 10:09 PM
To: Dave Airlie; Wentland, Harry
Cc: dri-devel
Subject: RE: [PATCH 3/5] drm/dp/mst: change MST detection scheme

Hi Dave,

Attached patch should fix the issue.

I have one question though: should we add drm_mode_connector_set_tile_property 
to the drm_get_displayid function, so it will be updated in case of regular DP 
displays as well?

As an example of such usage could be 5k displays with two tiles 2560x2880 that 
could not be driven on one MST connector because of bandwidth limitations, and 
are driven in SST mode.

Thanks,
Mykola

-Original Message-
From: Lysenko, Mykola
Sent: Thursday, February 18, 2016 12:53 PM
To: 'Dave Airlie' ; Wentland, Harry 
Cc: dri-devel 
Subject: RE: [PATCH 3/5] drm/dp/mst: change MST detection scheme

Hi Dave,

it seems to be missed call to 

drm_mode_connector_set_tile_property(port->connector);

here:

> +   } else if (port->pdt == DP_PEER_DEVICE_SST_SINK ||
> +   port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV) {
> +   if (!port->cached_edid) {
> +   port->cached_edid =
> +   drm_get_edid(port->connector, 
> + >aux.ddc);
 
drm_mode_connector_set_tile_property(port->connector);
> +   }

I will test with tile display to see if it solves the issue.

Thanks,
Mykola


-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, February 17, 2016 1:46 PM
To: Wentland, Harry 
Cc: dri-devel ; Lysenko, Mykola 

Subject: Re: [PATCH 3/5] drm/dp/mst: change MST detection scheme

On 23 January 2016 at 08:07, Harry Wentland  wrote:
> From: Mykola Lysenko 
>
> 1. Get edid for all connected MST displays, not only on logical ports,
>in the same thread as MST topology detection is done:
>  There are displays that have branches inside w/o logical ports.
>  So in case another SST display connected downstream system can
>  end-up in situation when 3 DOWN requests sent: two for
> ‘remote i2c read’ and one for ‘enum path resources’, making slots 
> full.
>
> 2. Call notification callback in one place in the end of topology 
> discovery/update:
>  This is done to reduce number of events sent to userspace in case complex
>  topology discovery is going, adding multiple number of 
> connectors;
>
> 3. Remove notification callback call from short pulse interrupt processing 
> function:
>  This is done in order not to block interrupt processing function, in 
> case any
>  MST request will be made from it. Notification will be send from topology
>  discovery/update work item.

I've had to pull this out, as I did some more indepth testing with
i915 and a Dell 30"
and this broke things.

The main thing it broke is setting the tiling property that userspace needs to 
see those dual-panel monitors as one.

you should be able to see xrandr --props if the tile property is correct if you 
test.

I'm also not sure about some other bits in this patch, so I probably need to 
dig a bit deeper into it.

Dave.

>
> Signed-off-by: Mykola Lysenko 
> Reviewed-by: Harry Wentland 
> Acked-by: Alex Deucher 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 37
> ++-
>  1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 041597b7a7c6..052c20ca35ee 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1130,13 +1130,11 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
> *mstb,
> drm_dp_put_port(port);
> goto out;
> }
> -   if (port->port_num >= DP_MST_LOGICAL_PORT_0) {
> -   port->cached_edid = drm_get_edid(port->connector, 
> >aux.ddc);
> -   drm_mode_connector_set_tile_property(port->connector);
> -   }
> +
> +   drm_mode_connector_set_tile_property(port->connector);
> +
> (*mstb->mgr->cbs->register_connector)(port->connector);
> }
> -
>  out:
> /* put reference to this port */
> drm_dp_put_port(port);
> @@ -1161,9 +1159,9 @@ static void drm_dp_update_port(struct drm_dp_mst_branch 
> *mstb,
> port->ddps = conn_stat->displayport_device_plug_status;
>
> if (old_ddps != port->ddps) {
> +   dowork = true;
> if (port->ddps) {
> drm_dp_check_port_guid(mstb, port);
> -   dowork = true;
> } else {
> port->guid_valid = false;
> port->available_pbn = 0; @@ 

[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Laurent Pinchart
Hi Ville,

On Thursday 12 May 2016 14:51:55 Ville Syrjälä wrote:
> On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> > From: Marek Szyprowski 
> > 
> > This patch adds support for generic plane's zpos property property with
> > well-defined semantics:
> > - added zpos properties to plane and plane state structures
> > - added helpers for normalizing zpos properties of given set of planes
> > - well defined semantics: planes are sorted by zpos values and then plane
> >   id value if zpos equals
> > 
> > Normalized zpos values are calculated automatically when generic
> > muttable zpos property has been initialized. Drivers can simply use
> > plane_state->normalized_zpos in their atomic_check and/or plane_update
> > callbacks without any additional calls to DRM core.
> > 
> > Signed-off-by: Marek Szyprowski 
> > 
> > Compare to Marek's original patch zpos property is now specific to each
> > plane and no more to the core.
> > Normalize function take care of the range of per plane defined range
> > before set normalized_zpos.
> > 
> > Signed-off-by: Benjamin Gaignard 
> > 
> > Cc: Inki Dae 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: Andrzej Hajda 
> > Cc: Krzysztof Kozlowski 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: Tobias Jakobi 
> > Cc: Gustavo Padovan 
> > Cc: vincent.abriou at st.com
> > Cc: fabien.dessenne at st.com
> > Cc: Laurent Pinchart 
> > ---
> > 
> >  Documentation/DocBook/gpu.tmpl  |  10 ++
> >  drivers/gpu/drm/Makefile|   2 +-
> >  drivers/gpu/drm/drm_atomic.c|   4 +
> >  drivers/gpu/drm/drm_atomic_helper.c |   6 +
> >  drivers/gpu/drm/drm_blend.c | 229 +++
> >  drivers/gpu/drm/drm_crtc_internal.h |   3 +
> >  include/drm/drm_crtc.h  |  28 +
> >  7 files changed, 281 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_blend.c

[snip]

> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > new file mode 100644
> > index 000..eef59bb
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -0,0 +1,229 @@

[snip]

> > +static int drm_atomic_state_zpos_cmp(const void *a, const void *b)
> > +{
> > +   const struct drm_plane_state *sa = *(struct drm_plane_state **)a;
> > +   const struct drm_plane_state *sb = *(struct drm_plane_state **)b;
> > +
> > +   if (sa->zpos != sb->zpos)
> > +   return sa->zpos - sb->zpos;
> > +   else
> > +   return sa->plane->base.id - sb->plane->base.id;
> > +}
> 
> Still not really convinced this normalization is a good idea when we
> have atomic. It made sense before atomic since otherwise you might not be
> able to swap the zpos of two planes without shutting one of them down,
> but it makes interpreting the zpos prop values more confusing. And with
> atomic we don't actually need it AFAICS. Or do we have an actual use case
> for this behaviour?

Speaking selfishly about my use case (rcar-du-drm), I need to sort planes in 
display order from 0 to N-1 as that's how the hardware is programmed. 
Normalization gives me an array of sorted planes, which is exactly what I 
need. I expect other drivers to have similar requirements, so normalization in 
the core will allow code sharing.

Now, is your concern that allowing two planes to have the same zpos isn't 
needed with the atomic API ? I agree with that, but it would also make it 
impossible to swap two planes using the legacy API implemented on top of 
atomic drivers. I'll let others decide whether this is considered as a 
concern.

While at it, Benjamin told me that you've requested configurable min/max 
values per plane, what are your use cases for that ? On the same topic, please 
see below.

> > +
> > +/**
> > + * drm_atomic_helper_crtc_normalize_zpos - calculate normalized zpos
> > values
> > + * @crtc: crtc with planes, which have to be considered for normalization
> > + * @crtc_state: new atomic state to apply
> > + *
> > + * This function checks new states of all planes assigned to given crtc
> > and
> > + * calculates normalized zpos value for them. Planes are compared first
> > by their
> > + * zpos values, then by plane id (if zpos equals). Plane with lowest zpos
> > value
> > + * is at the bottom. The plane_state->normalized_zpos is then filled with
> > unique
> > + * values from 0 to number of active planes in crtc minus one.
> > + *
> > + * RETURNS
> > + * Zero for success or -errno
> > + */
> > +int drm_atomic_helper_crtc_normalize_zpos(struct drm_crtc *crtc,
> > + struct drm_crtc_state *crtc_state)
> > +{
> > +   struct drm_atomic_state *state = crtc_state->state;
> > +   struct drm_device *dev = crtc->dev;
> > +   int total_planes = dev->mode_config.num_total_plane;
> > +   struct drm_plane_state **states;
> > +   struct drm_plane *plane;
> > +   int i, zpos, n = 0;
> > +   int ret = 0;
> > +
> > +   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] calculating 

[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=92258

--- Comment #45 from Mez  ---
Indeed, this works, but at the cost of a 33% decrease in performance, meaning
that my discrete GPU actually renders games as well as my integrated GPU.
Hence, I deactivated this option to start Steam. I'd rather have freezes (I can
avoid without going into context menus) than play games in a choppy way.

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


[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Laurent Pinchart
On Thursday 12 May 2016 15:36:07 Daniel Vetter wrote:
> On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> > From: Marek Szyprowski 
> > 
> > This patch adds support for generic plane's zpos property property with
> > well-defined semantics:
> > - added zpos properties to plane and plane state structures
> > - added helpers for normalizing zpos properties of given set of planes
> > - well defined semantics: planes are sorted by zpos values and then plane
> > 
> >   id value if zpos equals
> > 
> > Normalized zpos values are calculated automatically when generic
> > muttable zpos property has been initialized. Drivers can simply use
> > plane_state->normalized_zpos in their atomic_check and/or plane_update
> > callbacks without any additional calls to DRM core.
> > 
> > Signed-off-by: Marek Szyprowski 
> > 
> > Compare to Marek's original patch zpos property is now specific to each
> > plane and no more to the core.
> > Normalize function take care of the range of per plane defined range
> > before set normalized_zpos.
> > 
> > Signed-off-by: Benjamin Gaignard 
> > 
> > Cc: Inki Dae 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Cc: Joonyoung Shim 
> > Cc: Seung-Woo Kim 
> > Cc: Andrzej Hajda 
> > Cc: Krzysztof Kozlowski 
> > Cc: Bartlomiej Zolnierkiewicz 
> > Cc: Tobias Jakobi 
> > Cc: Gustavo Padovan 
> > Cc: vincent.abriou at st.com
> > Cc: fabien.dessenne at st.com
> > Cc: Laurent Pinchart 
> 
> When resending you must have a changelog somewhere. At elast in the cover
> letter, better is per-patch. Otherwise reviewers need to dig out the old
> threads and compare themselves.

And please update the subject as well to include the version number. You can 
use

$ git format-patch --cover --subject-prefix 'PATCH vX'

-- 
Regards,

Laurent Pinchart



[PATCH v4 0/3] drm: Add various helpers for simple drivers

2016-05-12 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patches.

For 1/3 and 2/3,

Reviewed-by: Laurent Pinchart 

On Thursday 12 May 2016 20:25:20 Noralf Trønnes wrote:
> This patchset adds various helpers that was originally part of the
> tinydrm patchset.
> 
> Essentially it adds 2 functions:
> - drm_fb_cma_create_with_funcs()
>   CMA backed framebuffer supporting a dirty() callback.
> - drm_simple_display_pipe_init()
>   Plane, crtc and encoder are collapsed into one entity.
> 
> 
> Changes since v3:
> - Add patch 'drm/fb-cma-helper: Use const for drm_framebuffer_funcs
> argument' - drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
>   - funcs argument should be const
> - drm: Add helper for simple display pipeline
>   - (struct drm_simple_display_pipe *)->funcs should be const
> 
> Changes since v2:
> - drm: Add helper for simple display pipeline
>   - Drop Kconfig knob DRM_KMS_HELPER
>   - Expand documentation
> 
> Changes since v1:
> - Drop patch: drm/panel: Add helper for simple panel connector
> - Add fb-helper and fb-cma-helper doc patches
> - Add drm/atomic: Don't skip drm_bridge_*() calls if
> !drm_encoder_helper_funcs - Add drm_atomic_helper_best_encoder()
> - drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
>   - Expand docs
> - drm: Add helper for simple display pipeline
>   - Add DOC header and add to gpu.tmpl
>   - Fix docs: @funcs is optional, "negative error code",
> "This hook is optional."
>   - Add checks to drm_simple_kms_plane_atomic_check()
> 
> 
> Noralf Trønnes (3):
>   drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument
>   drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
>   drm: Add helper for simple display pipeline
> 
>  Documentation/DocBook/gpu.tmpl  |   6 +
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_fb_cma_helper.c |  35 --
>  drivers/gpu/drm/drm_simple_kms_helper.c | 208
>  include/drm/drm_fb_cma_helper.h | 
>  5 +-
>  include/drm/drm_simple_kms_helper.h |  94 +++
>  6 files changed, 340 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>  create mode 100644 include/drm/drm_simple_kms_helper.h
> 
> --
> 2.8.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Regards,

Laurent Pinchart



[PATCH v4 3/3] drm: Add helper for simple display pipeline

2016-05-12 Thread Ville Syrjälä
On Thu, May 12, 2016 at 08:25:23PM +0200, Noralf Trønnes wrote:
> Provides helper functions for drivers that have a simple display
> pipeline. Plane, crtc and encoder are collapsed into one entity.
> 
> Cc: jsarha at ti.com
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes since v3:
> - (struct drm_simple_display_pipe *)->funcs should be const
> 
> Changes since v2:
> - Drop Kconfig knob DRM_KMS_HELPER
> - Expand documentation
> 
> Changes since v1:
> - Add DOC header and add to gpu.tmpl
> - Fix docs: @funcs is optional, "negative error code",
>   "This hook is optional."
> - Add checks to drm_simple_kms_plane_atomic_check()
> 
>  Documentation/DocBook/gpu.tmpl  |   6 +
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_simple_kms_helper.c | 208 
> 
>  include/drm/drm_simple_kms_helper.h |  94 +++
>  4 files changed, 309 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
>  create mode 100644 include/drm/drm_simple_kms_helper.h
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 4a0c599..cf3f5a8 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
>  !Edrivers/gpu/drm/drm_panel.c
>  !Pdrivers/gpu/drm/drm_panel.c drm panel
>  
> +
> +  Simple KMS Helper Reference
> +!Iinclude/drm/drm_simple_kms_helper.h
> +!Edrivers/gpu/drm/drm_simple_kms_helper.c
> +!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
> +
>
> 
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..31b85df5 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.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_kms_helper_common.o drm_simple_kms_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_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> new file mode 100644
> index 000..d45417a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -0,0 +1,208 @@
> +/*
> + * Copyright (C) 2016 Noralf Trønnes
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DOC: overview
> + *
> + * This helper library provides helpers for drivers for simple display
> + * hardware.
> + *
> + * drm_simple_display_pipe_init() initializes a simple display pipeline
> + * which has only one full-screen scanout buffer feeding one output. The
> + * pipeline is represented by struct _simple_display_pipe and binds
> + * together _plane, _crtc and _encoder structures into one fixed
> + * entity. Some flexibility for code reuse is provided through a separately
> + * allocated _connector object and supporting optional _bridge
> + * encoder drivers.
> + */
> +
> +static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> + if (!pipe->funcs || !pipe->funcs->enable)
> + return;
> +
> + pipe->funcs->enable(pipe, crtc->state);
> +}
> +
> +static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
> +{
> + struct drm_simple_display_pipe *pipe;
> +
> + pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
> + if (!pipe->funcs || !pipe->funcs->disable)
> + return;
> +
> + pipe->funcs->disable(pipe);
> +}
> +
> +static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = 
> {
> + .disable = drm_simple_kms_crtc_disable,
> + .enable = drm_simple_kms_crtc_enable,
> +};
> +
> +static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
> + .reset = drm_atomic_helper_crtc_reset,
> + .destroy = drm_crtc_cleanup,
> + .set_config = drm_atomic_helper_set_config,
> + .page_flip = drm_atomic_helper_page_flip,
> + .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> +};
> +
> +static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
> + struct 

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=87682

--- Comment #18 from Thom  ---
(In reply to Chris Bainbridge from comment #17)
> if you don't get a reply here you could try emailing Christian
> König and asking.

I did, and Christian responded almost instantly, so I will be busy for quite a
while with testing. Don't close this bug yetwork in progress :-)

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


[PATCH v4 3/3] drm: Add helper for simple display pipeline

2016-05-12 Thread Noralf Trønnes
Provides helper functions for drivers that have a simple display
pipeline. Plane, crtc and encoder are collapsed into one entity.

Cc: jsarha at ti.com
Signed-off-by: Noralf Trønnes 
---

Changes since v3:
- (struct drm_simple_display_pipe *)->funcs should be const

Changes since v2:
- Drop Kconfig knob DRM_KMS_HELPER
- Expand documentation

Changes since v1:
- Add DOC header and add to gpu.tmpl
- Fix docs: @funcs is optional, "negative error code",
  "This hook is optional."
- Add checks to drm_simple_kms_plane_atomic_check()

 Documentation/DocBook/gpu.tmpl  |   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c | 208 
 include/drm/drm_simple_kms_helper.h |  94 +++
 4 files changed, 309 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 4a0c599..cf3f5a8 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_panel.c
 !Pdrivers/gpu/drm/drm_panel.c drm panel
 
+
+  Simple KMS Helper Reference
+!Iinclude/drm/drm_simple_kms_helper.h
+!Edrivers/gpu/drm/drm_simple_kms_helper.c
+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
+
   

   
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..31b85df5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.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_kms_helper_common.o drm_simple_kms_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_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
new file mode 100644
index 000..d45417a
--- /dev/null
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -0,0 +1,208 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This helper library provides helpers for drivers for simple display
+ * hardware.
+ *
+ * drm_simple_display_pipe_init() initializes a simple display pipeline
+ * which has only one full-screen scanout buffer feeding one output. The
+ * pipeline is represented by struct _simple_display_pipe and binds
+ * together _plane, _crtc and _encoder structures into one fixed
+ * entity. Some flexibility for code reuse is provided through a separately
+ * allocated _connector object and supporting optional _bridge
+ * encoder drivers.
+ */
+
+static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->enable)
+   return;
+
+   pipe->funcs->enable(pipe, crtc->state);
+}
+
+static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->disable)
+   return;
+
+   pipe->funcs->disable(pipe);
+}
+
+static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+   .disable = drm_simple_kms_crtc_disable,
+   .enable = drm_simple_kms_crtc_enable,
+};
+
+static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
+   .reset = drm_atomic_helper_crtc_reset,
+   .destroy = drm_crtc_cleanup,
+   .set_config = drm_atomic_helper_set_config,
+   .page_flip = drm_atomic_helper_page_flip,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *plane_state)
+{
+   struct drm_rect src = {
+   .x1 = plane_state->src_x,
+   .y1 = plane_state->src_y,
+   .x2 = plane_state->src_x + plane_state->src_w,
+   .y2 = plane_state->src_y + plane_state->src_h,
+   };
+   struct drm_rect dest 

[PATCH v4 2/3] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

2016-05-12 Thread Noralf Trønnes
Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.

Signed-off-by: Noralf Trønnes 
Acked-by: Laurent Pinchart 
---

Changes since v3:
- funcs argument should be const

Changes since v1:
- Expand docs

 drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
 include/drm/drm_fb_cma_helper.h |  3 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 815c72f..2248c32 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct 
drm_device *dev,
 }

 /**
- * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create callback 
function
+ * drm_fb_cma_create_with_funcs() - helper function for the
+ *  _mode_config_funcs ->fb_create
+ *  callback function
  *
- * If your hardware has special alignment or pitch requirements these should be
- * checked before calling this function.
+ * This can be used to set _framebuffer_funcs for drivers that need the
+ * dirty() callback. Use drm_fb_cma_create() if you don't need to change
+ * _framebuffer_funcs.
  */
-struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
-   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   const struct drm_framebuffer_funcs *funcs)
 {
struct drm_fb_cma *fb_cma;
struct drm_gem_cma_object *objs[4];
@@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct drm_device 
*dev,
objs[i] = to_drm_gem_cma_obj(obj);
}

-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
+   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;
@@ -215,6 +219,21 @@ err_gem_object_unreference:
drm_gem_object_unreference_unlocked([i]->base);
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
+
+/**
+ * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback function
+ *
+ * If your hardware has special alignment or pitch requirements these should be
+ * checked before calling this function. Use drm_fb_cma_create_with_funcs() if
+ * you need to set _framebuffer_funcs ->dirty.
+ */
+struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
+   _fb_cma_funcs);
+}
 EXPORT_SYMBOL_GPL(drm_fb_cma_create);

 /**
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index ac38a05..fd0dde9 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
 int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle);

+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   const struct drm_framebuffer_funcs *funcs);
 struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

--
2.8.2



[PATCH v4 1/3] drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument

2016-05-12 Thread Noralf Trønnes
drm_framebuffer_init() uses const for the drm_framebuffer_funcs
argument so use that on drm_fb_cma_alloc() and
drm_fbdev_cma_create_with_funcs() as well.

Cc: laurent.pinchart at ideasonboard.com
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 4 ++--
 include/drm/drm_fb_cma_helper.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 3165ac0..815c72f 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -133,7 +133,7 @@ static struct drm_framebuffer_funcs drm_fb_cma_funcs = {
 static struct drm_fb_cma *drm_fb_cma_alloc(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_cma_object **obj,
-   unsigned int num_planes, struct drm_framebuffer_funcs *funcs)
+   unsigned int num_planes, const struct drm_framebuffer_funcs *funcs)
 {
struct drm_fb_cma *fb_cma;
int ret;
@@ -350,7 +350,7 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi)
  */
 int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes,
-   struct drm_framebuffer_funcs *funcs)
+   const struct drm_framebuffer_funcs *funcs)
 {
struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
struct drm_mode_fb_cmd2 mode_cmd = { 0 };
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index c6d9c9c..ac38a05 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -25,7 +25,7 @@ void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma 
*fbdev_cma);
 void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
 int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes,
-   struct drm_framebuffer_funcs *funcs);
+   const struct drm_framebuffer_funcs *funcs);

 void drm_fb_cma_destroy(struct drm_framebuffer *fb);
 int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
-- 
2.8.2



[PATCH v4 0/3] drm: Add various helpers for simple drivers

2016-05-12 Thread Noralf Trønnes
This patchset adds various helpers that was originally part of the
tinydrm patchset.

Essentially it adds 2 functions:
- drm_fb_cma_create_with_funcs()
  CMA backed framebuffer supporting a dirty() callback.
- drm_simple_display_pipe_init()
  Plane, crtc and encoder are collapsed into one entity.


Changes since v3:
- Add patch 'drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument'
- drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  - funcs argument should be const
- drm: Add helper for simple display pipeline
  - (struct drm_simple_display_pipe *)->funcs should be const

Changes since v2:
- drm: Add helper for simple display pipeline
  - Drop Kconfig knob DRM_KMS_HELPER
  - Expand documentation

Changes since v1:
- Drop patch: drm/panel: Add helper for simple panel connector
- Add fb-helper and fb-cma-helper doc patches
- Add drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
- Add drm_atomic_helper_best_encoder()
- drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  - Expand docs
- drm: Add helper for simple display pipeline
  - Add DOC header and add to gpu.tmpl
  - Fix docs: @funcs is optional, "negative error code",
"This hook is optional."
  - Add checks to drm_simple_kms_plane_atomic_check()


Noralf Trønnes (3):
  drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument
  drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  drm: Add helper for simple display pipeline

 Documentation/DocBook/gpu.tmpl  |   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c |  35 --
 drivers/gpu/drm/drm_simple_kms_helper.c | 208 
 include/drm/drm_fb_cma_helper.h |   5 +-
 include/drm/drm_simple_kms_helper.h |  94 +++
 6 files changed, 340 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

--
2.8.2



[RFC 3/3] arm: dts: mt2701: Add display subsystem related nodes for MT2701

2016-05-12 Thread yt.s...@mediatek.com
From: YT Shen 

This patch adds the device nodes for the DISP function blocks for MT2701

Signed-off-by: YT Shen 
---
 arch/arm/boot/dts/mt2701.dtsi |  117 +
 1 file changed, 117 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 363de0d..0beef2a 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -24,6 +24,13 @@
compatible = "mediatek,mt2701";
interrupt-parent = <>;

+   aliases {
+   rdma0 = 
+   rdma1 = 
+   dpi0 = 
+   dpi1 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -171,6 +178,14 @@
power-domains = < MT2701_POWER_DOMAIN_DISP>;
};

+   mipi_tx0: mipi-dphy at 1001 {
+   compatible = "mediatek,mt2701-mipi-tx";
+   reg = <0 0x1001 0 0x90>;
+   clocks = <>;
+   clock-output-names = "mipi_tx0_pll";
+   status = "disabled";
+   };
+
sysirq: interrupt-controller at 10200100 {
compatible = "mediatek,mt2701-sysirq",
 "mediatek,mt6577-sysirq";
@@ -255,6 +270,79 @@
status = "disabled";
};

+   ovl at 14007000 {
+   compatible = "mediatek,mt2701-disp-ovl";
+   reg = <0 0x14007000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_OVL>;
+   iommus = < MT2701_M4U_PORT_DISP_OVL_0>;
+   mediatek,larb = <>;
+   };
+
+   rdma0: rdma at 14008000 {
+   compatible = "mediatek,mt2701-disp-rdma";
+   reg = <0 0x14008000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_RDMA>;
+   iommus = < MT2701_M4U_PORT_DISP_RDMA>;
+   mediatek,larb = <>;
+   };
+
+   wdma at 14009000 {
+   compatible = "mediatek,mt2701-disp-wdma";
+   reg = <0 0x14009000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_WDMA>;
+   iommus = < MT2701_M4U_PORT_DISP_WDMA>;
+   mediatek,larb = <>;
+   };
+
+   bls at 1400a000 {
+   compatible = "mediatek,mt2701-disp-bls";
+   reg = <0 0x1400a000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_BLS>;
+   };
+
+   color at 1400b000 {
+   compatible = "mediatek,mt2701-disp-color";
+   reg = <0 0x1400b000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_COLOR>;
+   };
+
+   dsi0: dsi at 1400c000 {
+   compatible = "mediatek,mt2701-dsi";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DSI_ENGINE>, < CLK_MM_DSI_DIG>,
+<_tx0>;
+   clock-names = "engine", "digital", "hs";
+   phys = <_tx0>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   dpi0: dpi at 1400d000 {
+   compatible = "mediatek,mt2701-dpi";
+   reg = <0 0x1400d000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DPI_DIGL>,
+< CLK_MM_DPI_ENGINE>;
+   clock-names = "clk_dpi_digl",
+ "clk_dpi_engine";
+   status = "disabled";
+   };
+
+   mutex: mutex at 1400e000 {
+   compatible = "mediatek,mt2701-disp-mutex";
+   reg = <0 0x1400e000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_MUTEX_32K>;
+   };
+
larb0: larb at 1401 {
compatible = "mediatek,mt2701-smi-larb";
reg = <0 0x1401 0 0x1000>;
@@ -265,6 +353,35 @@
power-domains = < MT2701_POWER_DOMAIN_DISP>;
};

+   rdma1: rdma at 14012000 {
+   compatible = "mediatek,mt2701-disp-rdma";
+   reg = <0 0x14012000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_RDMA1>;
+   iommus = < MT2701_M4U_PORT_DISP_RDMA1>;
+   mediatek,larb = <>;
+   };
+
+   ufoe at 14013000 {
+   compatible = "mediatek,mt2701-disp-ufoe";
+   reg = <0 0x14013000 0 0x1000>;
+   clocks = < CLK_MM_DISP_UFOE>;
+   };
+
+   dpi1: dpi at 14014000 {
+   compatible = "mediatek,mt2701-dpi";
+   reg = <0 0x14014000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DPI1_DIGL>,
+< CLK_MM_DPI1_ENGINE>,
+< CLK_TOP_DPI1_SEL>,
+< CLK_TOP_TVDPLL>,
+< 

[RFC 2/3] drm/mediatek: add support for Mediatek SoC MT2701

2016-05-12 Thread yt.s...@mediatek.com
From: YT Shen 

This patch add support for the Mediatek MT2701 DISP subsystem.
There is only one OVL engine in MT2701, and we have shadow
register support here.

Signed-off-by: YT Shen 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c |   49 ++---
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c|   36 +--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   78 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  |  151 ---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   63 +--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |   15 +++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  |   72 +++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |9 ++
 drivers/gpu/drm/mediatek/mtk_drm_gem.c  |4 +
 10 files changed, 373 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8f62671f..e4a10bd6 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -40,8 +40,6 @@
 #defineOVL_RDMA_MEM_GMC0x40402020

 #define OVL_CON_BYTE_SWAP  BIT(24)
-#define OVL_CON_CLRFMT_RGB565  (0 << 12)
-#define OVL_CON_CLRFMT_RGB888  (1 << 12)
 #define OVL_CON_CLRFMT_RGBA(2 << 12)
 #define OVL_CON_CLRFMT_ARGB(3 << 12)
 #defineOVL_CON_AEN BIT(8)
@@ -136,18 +134,18 @@ static void mtk_ovl_layer_off(struct mtk_ddp_comp *comp, 
unsigned int idx)
writel(0x0, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
 }

-static unsigned int ovl_fmt_convert(unsigned int fmt)
+static unsigned int ovl_fmt_convert(struct mtk_ddp_comp *comp, unsigned int 
fmt)
 {
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
-   return OVL_CON_CLRFMT_RGB565;
+   return comp->data->ovl.fmt_rgb565;
case DRM_FORMAT_BGR565:
-   return OVL_CON_CLRFMT_RGB565 | OVL_CON_BYTE_SWAP;
+   return comp->data->ovl.fmt_rgb565 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGB888:
-   return OVL_CON_CLRFMT_RGB888;
+   return comp->data->ovl.fmt_rgb888;
case DRM_FORMAT_BGR888:
-   return OVL_CON_CLRFMT_RGB888 | OVL_CON_BYTE_SWAP;
+   return comp->data->ovl.fmt_rgb888 | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_RGBX:
case DRM_FORMAT_RGBA:
return OVL_CON_CLRFMT_ARGB;
@@ -177,7 +175,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
if (!pending->enable)
mtk_ovl_layer_off(comp, idx);

-   con = ovl_fmt_convert(fmt);
+   con = ovl_fmt_convert(comp, fmt);
if (idx != 0)
con |= OVL_CON_AEN | OVL_CON_ALPHA;

@@ -185,7 +183,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
writel_relaxed(offset, comp->regs + DISP_REG_OVL_OFFSET(idx));
-   writel_relaxed(addr, comp->regs + DISP_REG_OVL_ADDR(idx));
+   writel_relaxed(addr, comp->regs + (comp->data->ovl.addr_offset + idx * 
0x20));

if (pending->enable)
mtk_ovl_layer_on(comp, idx);
@@ -233,6 +231,32 @@ static const struct component_ops 
mtk_disp_ovl_component_ops = {
.unbind = mtk_disp_ovl_unbind,
 };

+static struct mtk_ddp_comp_driver_data mt2701_ovl_driver_data = {
+   .ovl = {0x0040, 1 << 12, 0}
+};
+
+static struct mtk_ddp_comp_driver_data mt8173_ovl_driver_data = {
+   .ovl = {0x0f40, 0, 1 << 12}
+};
+
+static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
+   { .compatible = "mediatek,mt2701-disp-ovl",
+ .data = _ovl_driver_data},
+   { .compatible = "mediatek,mt8173-disp-ovl",
+ .data = _ovl_driver_data},
+   {},
+};
+MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
+
+static inline struct mtk_ddp_comp_driver_data *mtk_ovl_get_driver_data(
+   struct platform_device *pdev)
+{
+   const struct of_device_id *of_id =
+   of_match_device(mtk_disp_ovl_driver_dt_match, >dev);
+
+   return (struct mtk_ddp_comp_driver_data *)of_id->data;
+}
+
 static int mtk_disp_ovl_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -269,6 +293,8 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}

+   priv->ddp_comp.data = mtk_ovl_get_driver_data(pdev);
+
platform_set_drvdata(pdev, priv);

ret = component_add(dev, _disp_ovl_component_ops);
@@ -285,11 +311,6 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
return 0;
 }

-static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
-   { .compatible = "mediatek,mt8173-disp-ovl", },
-   {},
-};
-MODULE_DEVICE_TABLE(of, 

[RFC 1/3] dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701

2016-05-12 Thread yt.s...@mediatek.com
From: YT Shen 

Add device tree binding documentation for the display subsystem in
Mediatek SoC MT2701

Signed-off-by: YT Shen 
---
 .../bindings/display/mediatek/mediatek,disp.txt|1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index db6e77e..53b3cc3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -40,6 +40,7 @@ Required properties (all function blocks):
"mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
"mediatek,-disp-mutex" - display mutex
"mediatek,-disp-od"- overdrive
+   "mediatek,-disp-bls"   - backlight
 - reg: Physical base address and length of the function block register space
 - interrupts: The interrupt signal from the function block (required, except 
for
   merge and split function blocks).
-- 
1.7.9.5



[RFC 0/3] MT2701 DRM support

2016-05-12 Thread yt.s...@mediatek.com
From: YT Shen 

This is MT2701 DRM support RFC, based on MT8173 DRM patch v16.
Most codes are the same, except some register changed.

For example:
 - DISP_OVL address offset changed, color format definition changed.
 - DISP_RDMA fifo size changed.
 - DISP_COLOR offset changed.

We add a new component DISP_BLS, and the connection settings are updated.
And we have shadow register support in MT2701.

The RFC depends on MT2701 iommu/smi driver.
https://patchwork.kernel.org/patch/9043411/ ("dt-bindings: mediatek: add 
descriptions for mediatek mt2701 iommu and smi"),
https://patchwork.kernel.org/patch/9043391/ ("iommu/mediatek: move the common 
struct into header file"),
https://patchwork.kernel.org/patch/9043421/ ("memory/mediatek: add support for 
mt2701"),
https://patchwork.kernel.org/patch/9043451/ ("iommu/mediatek: add support for 
mtk iommu generation one HW"),
https://patchwork.kernel.org/patch/9043471/ ("ARM: dts: mt2701: add iommu/smi 
dtsi node for mt2701"),

Thanks,
yt.shen

YT Shen (3):
  dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701
  drm/mediatek: add support for Mediatek SoC MT2701
  arm: dts: mt2701: Add display subsystem related nodes for MT2701

 .../bindings/display/mediatek/mediatek,disp.txt|1 +
 arch/arm/boot/dts/mt2701.dtsi  |  117 +++
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c|   49 +--
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c   |   36 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|   78 ++
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c |  151 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |2 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|   63 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h|   15 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |   72 --
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |9 ++
 drivers/gpu/drm/mediatek/mtk_drm_gem.c |4 +
 12 files changed, 491 insertions(+), 106 deletions(-)

-- 
1.7.9.5



[PATCH] qxl: catch qxlfb_create_pinned_object failures

2016-05-12 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_fb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 7136e52..17c1ef0 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -360,6 +360,9 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth);

ret = qxlfb_create_pinned_object(qfbdev, _cmd, );
+   if (ret < 0)
+   return ret;
+
qbo = gem_to_qxl_bo(gobj);
QXL_INFO(qdev, "%s: %dx%d %d\n", __func__, mode_cmd.width,
 mode_cmd.height, mode_cmd.pitches[0]);
-- 
1.8.3.1



EDID/DP color precision fixes on Intel hw for stable

2016-05-12 Thread Mario Kleiner
On 05/07/2016 08:15 PM, Ville Syrjälä wrote:
> On Fri, May 06, 2016 at 10:03:06PM +0200, Mario Kleiner wrote:
>> On 05/06/2016 08:27 PM, Ville Syrjälä wrote:
>>> On Mon, Mar 28, 2016 at 01:52:44AM +0200, Mario Kleiner wrote:
 Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331

 received a potential fix that was backported to stable. While that
 patch itself is correct for treating DP video sinks with "unknown
 color depth", it uncovered some lack in our general EDID 1.3
 handling, and in how we treat DP->DVI/VGA, causing the fall back
 of Intel DP to 6 bpc / 18 bpp in cases where it shouldn't fall
 back. That leads to unhappy neuroscience/medical users of Intel gpus
 which need their DP->DVI or DP->VGA display devices to operate at at
 least 8 bpc without dithering.

 The following three patches try to improve our EDID handling and
 Intel DP to try harder to detect the proper bpc to avoid these
 regressions for DP-DVI and DP-VGA. The third patch tries to fix
 FDO bug 105331 without causing general unhappiness of other users.
>>>
>>
>> Thanks for the feedback.
>>
>>> It would seem simpler to me to move the 18bpp fallback into intel_dp.c
>>> and only do it for native DP sinks/downstream ports. That way we should
>>> avoid the need for any EDID quirks IIUC.
>>>
>>
>> I think that specific EDID quirk in patch 3/3 for that FDO bug we'd
>> always need, because that specific panels EDID reports 8 bpc capability
>> by setting the "DFP 1.x compliant TMDS" bit in its EDID 1.3, but
>> according to the FDO bug it needs to be driven with 6 bpc + dithering
>> for good results.
>
> If we just do the fallback for DP, then I don;t think we need any
> changes to the EDID parser, and hence no quirk either.
>
>>

You are probably right. Rereading the bug report it seems to be a native 
DP panel without EDID color info, so the 6 bpc fallback only for native 
DP sinks should handle that.

I just sent out a new patch, also for stable, which folds the 6 bpc 
fallback into my DP bpc detection code.

I wonder if it would still make sense to apply the DFP 1.x bit handling 
in the shared EDID parser, just so we take full advantage of what info a 
EDID 1.3 provides? Although then we'd need a quirk for that panel again, 
as it does have a somewhat broken EDID.

thanks,
-mario

>> Do you agree with patch 1/3? That would avoid kms drivers needing to
>> work out DFP compliant displays.I think we could probably make the
>> assumption that anything that has EDID 1.3 is 8 bpc capable? DVI spec
>> seems to require that for anything DVI, and  i'd assume any VGA DAC
>> manufactured in the last 20 years would have at least 8 bpc?
>>
>> Wrt. 18 bpp fallback you mean putting it into intel_dp_legacy_bpc() from
>> patch 2/3 or similar and checking that the sink is really not an active
>> DVI or VGA converter?
>
> Yeah, I'd just check the downstream port type, and do the 18bpp fallback
> only for native DP if the sink didn't give us a bpc. For everything else
> 8bpc seems like a reasonable default (unless the port caps say otherwise,
> of course).
>
>>
>> I tried to keep these patches relatively simple/conservative to allow
>> safe backporting to stable kernels that are affected by the regression.
>>
>>> The downstream port caps we should still check I suppose. Later
>>> versions of the spec extend the information for pretty much all port
>>> types. I started to write something similar [1] a while back, and by the
>>> looks of things I was probably basing that on the DP 1.2 spec since 1.3
>>> has even more stuff there. Anyways we should put that logic into the
>>> DP helper so that other drivers migth use it as well.
>>>
>>> [1] git://github.com/vsyrjala/linux.git dp_downstream_ports
>>>
>>
>> Have to look at that. I don't have official access to the latest specs,
>> just to whatever i could find floating in the internet.
>>
>> thanks,
>> -mario
>


[PATCH] drm/i915/dp: Try to find proper bpc for DP->legacy converters. (v2)

2016-05-12 Thread Mario Kleiner
This fixes a regression in output precision for DVI and VGA
video sinks connected to Intel hw via active DisplayPort->DVI/VGA
converters.

The regression was indirectly introduced by commit 013dd9e03872
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown").

Our current drm edid 1.3 handling can't reliably assign a proper
minimum supported display depth of 8 bpc to all DVI sinks, as
mandated by DVI 1.0 spec, section 2.2.11.2 "Monitor data format
support", but returns 0 bpc = "Don't know" instead. For analog VGA
sinks it also returns 0 bpc, although those sinks themselves have
infinite color depth, only restricted by the DAC resolution of
the encoder.

If a VGA or dual-link DVI display is connected via DisplayPort
connector then due to above commit the driver would fall back to
only 6 bpc, which would cause degradation for DVI and VGA displays,
annoying in general, but especially harmful for application of display
devices used in neuroscience research and for medical diagnosic
which absolutely need native non-dithered 8 bpc at a minimum to
operate correctly.

For DP connectors with bpc == 0 according to EDID, fix this problem
by checking the dpcd data to find out if a DP->legacy converter
is connected. If the converter is DP->DVI/HDMI assume 8 bpc
depth. If the converter is DP->VGA assume at least 8 bpc, but
try to get a more accurate value (8, 10, 12 or 16 bpc) if the
converter exposes this info.

Only for a DP sink without downstream ports we assume it is a native DP
sink and apply the 6 bpc / 18 bpp fallback as required by the DP spec.

As the "fall back to 18 bpp" patch was backported to stable we should
include this one also into stable to fix the regression in color
precision.

Tested with MiniDP->DP adapter, MiniDP->HDMI adapter,
MiniDP->single-link DVI adapter, MiniDP->dual-link DVI active adapter,
and Apple MiniDP->VGA active adapter.

v2: Take Ville's feedback into account: Fold the 18 bpp fallback into
the detection function, so it only applies to native DP sinks.
Rename intel_dp_legacy_bpc() to intel_dp_sink_bpc().

Signed-off-by: Mario Kleiner 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/i915/intel_display.c | 12 ++--
 drivers/gpu/drm/i915/intel_dp.c  | 59 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a297e1f..7ef52db 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12072,10 +12072,16 @@ connected_sink_compute_bpp(struct intel_connector 
*connector,
int type = connector->base.connector_type;
int clamp_bpp = 24;

-   /* Fall back to 18 bpp when DP sink capability is unknown. */
+   /* On DisplayPort try harder to find sink bpc */
if (type == DRM_MODE_CONNECTOR_DisplayPort ||
-   type == DRM_MODE_CONNECTOR_eDP)
-   clamp_bpp = 18;
+   type == DRM_MODE_CONNECTOR_eDP) {
+   int sink_bpc = intel_dp_sink_bpc(>base);
+
+   if (sink_bpc) {
+   DRM_DEBUG_KMS("DP sink with bpc %d\n", 
sink_bpc);
+   clamp_bpp = 3 * sink_bpc;
+   }
+   }

if (bpp > clamp_bpp) {
DRM_DEBUG_KMS("clamping display bpp (was %d) to default 
limit of %d\n",
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f192f58..4dbb55b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6046,3 +6046,62 @@ void intel_dp_mst_resume(struct drm_device *dev)
}
}
 }
+
+/* XXX Needs work for more than 1 downstream port */
+int intel_dp_sink_bpc(struct drm_connector *connector)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(connector);
+   uint8_t *dpcd = intel_dp->dpcd;
+   uint8_t type;
+   int bpc = 0;
+
+   /*
+* If there isn't any downstream port then this is a native DP sink.
+* The standard requires to fall back to 6 bpc / 18 bpp for native DP
+* sinks which don't provide bit depth via EDID.
+*/
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   return 6;
+
+   /* Basic type of downstream ports */
+   type = dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_TYPE_MASK;
+
+   /*
+* Lacking other info, 8 bpc is a reasonable start for analog out.
+* E.g., Apple MiniDP->VGA adaptors don't provide more info than
+* that. Despite having DP_DPCD_REV == 0x11 their downstream_ports
+* descriptor is empty - all zeros.
+*/
+   if (type == DP_DWN_STRM_PORT_TYPE_ANALOG)
+   bpc = 8;
+
+   if 

[PATCH v2 1/3] drm: Tune up error message for incorrect plane/format combinations

2016-05-12 Thread Imre Deak
Returning 0 from these functions isn't ever valid. In many cases it can
also lead to a div-by-zero possibly at some later point in time, so make
sure we catch such errors as soon as possible via louder error
reporting.

v2:
- Print the same WARN whenever we check for the same condition (Ville)
- Don't change drm_fb_get_bpp_depth(), for non-RGB formats we return
  bpp=0, depth=0 normally. (Ville, Daniel)

CC: Dave Airlie 
CC: Ville Syrjälä 
CC: Daniel Vetter 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_crtc.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 70f9c68..990a9de 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5544,6 +5544,13 @@ int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
return dev->driver->dumb_destroy(file_priv, dev, args->handle);
 }

+static bool check_format_plane_valid(uint32_t format, int plane)
+{
+   return !WARN(plane >= drm_format_num_planes(format),
+"invalid plane %d for format %s\n",
+plane, drm_get_format_name(format));
+}
+
 /**
  * drm_fb_get_bpp_depth - get the bpp/depth values for format
  * @format: pixel format (DRM_FORMAT_*)
@@ -5666,7 +5673,7 @@ int drm_format_plane_cpp(uint32_t format, int plane)
unsigned int depth;
int bpp;

-   if (plane >= drm_format_num_planes(format))
+   if (!check_format_plane_valid(format, plane))
return 0;

switch (format) {
@@ -5771,7 +5778,7 @@ EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
  */
 int drm_format_plane_width(int width, uint32_t format, int plane)
 {
-   if (plane >= drm_format_num_planes(format))
+   if (!check_format_plane_valid(format, plane))
return 0;

if (plane == 0)
@@ -5792,7 +5799,7 @@ EXPORT_SYMBOL(drm_format_plane_width);
  */
 int drm_format_plane_height(int height, uint32_t format, int plane)
 {
-   if (plane >= drm_format_num_planes(format))
+   if (!check_format_plane_valid(format, plane))
return 0;

if (plane == 0)
-- 
2.5.0



[Bug 93826] 144Hz graphic glitches and bad refresh rate

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #21 from Pavel Bordukov  ---
Same bug here, everything looks like Damien described. R290X + MG279Q at 144HZ.

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


[nexus7-flo] backlight brightness

2016-05-12 Thread John Stultz
On Mon, May 2, 2016 at 9:56 PM, Vinay Simha  wrote:
> Here does the parent also should be jdi->dsi->dev ? because the
> backlight is not mapped to fb of android ( android->
> settings->brightness) , even though i can change the brightness value
> from sysfs and it works only when the display is off. When it
> awakes(power button press) panel_enable calls, backlight_update_status
> will have the latest brightness value.
>
> if echo the brightness value when the display is awake, dsi fails for
> brightness control.
> echo 100 > /sys/class/backlight/470.qcom,mdss_dsi.0/brightness
> [  152.865949] dsi_cmds2buf_tx: cmd dma tx failed, type=0x15, data0=0x51, 
> len=4
>
> static int dsi_bl_update_status(struct backlight_device *bl)
> {
> struct jdi_panel *jdi = bl_get_data(bl);
> struct mipi_dsi_device *dsi = jdi->dsi;
> int ret;
> u8 brightness = bl->props.brightness;
>
> ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_SET_DISPLAY_BRIGHTNESS,
> , sizeof(brightness));
> if (ret < 0)
> return ret;
>
> return 0;
> }
>
> static const struct backlight_ops dsi_bl_ops = {
> .update_status = dsi_bl_update_status,
>  };
>
> john,
> for android fb do we need to map the backlight in userspace? As i have
> seen in 3.4 kernel when we register the backlight using
> platform_device_register, backlight used to map with the
> userspace(ubuntu/fedora) settings->brightness.

Just to follow up here. I did add a lights HAL in my userspace build
to support the brightness sysfs interface. It looks like its working
ok, but as you note above, the brightness settings from the slider
don't seem to apply until the screen is turned off and back on.

thanks
-john


[2/3] drm/mst: Fix error handling during MST sideband message reception

2016-05-12 Thread Lyude Paul
On Thu, 2016-05-12 at 16:00 +0300, Imre Deak wrote:
> Handle any error due to partial reads, timeouts etc. to avoid parsing
> uninitialized data subsequently. Also bail out if the parsing itself
> fails.
> 
> CC: Dave Airlie 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index a13edf5..12c0ab3 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2204,11 +2204,19 @@ static void drm_dp_get_one_sb_msg(struct
> drm_dp_mst_topology_mgr *mgr, bool up)
>  ret = drm_dp_dpcd_read(mgr->aux, basereg + curreply,
>      replyblock, len);
>  if (ret != len) {
> - DRM_DEBUG_KMS("failed to read a chunk\n");
> + DRM_DEBUG_KMS("failed to read a chunk (len %d, ret
> %d)\n",
> +       len, ret);
> +
I'd get rid of the whitespace here…
> + return;
>  }
> +
>  ret = drm_dp_sideband_msg_build(msg, replyblock, len, false);
> - if (ret == false)
> + if (!ret) {
>  DRM_DEBUG_KMS("failed to build sideband msg\n");
> +
And here, to match the rest of the file. Otherwise looks good to me;

Reviewed-by: Lyude 
> + return;
> + }
> +
>  curreply += len;
>  replylen -= len;
>  }


[PATCH V5 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

2016-05-12 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO
interface like setting voltage signal levels and power state of
the interface. The group is generally referred as IO pads. The
power state and voltage control of IO pins can be done at IO pads
level.

Tegra generation SoC supports the power down of IO pads when it
is not used even in the active state of system. This saves power
from that IO interface. Also it supports multiple voltage level
in IO pins for interfacing on some of pads. The IO pad voltage is
automatically detected till T124, hence SW need not to configure
this. But from T210, the automatically detection logic has been
removed, hence SW need to explicitly set the IO pad voltage into
IO pad configuration registers.

Add support to set the power states and voltage level of the IO pads
from client driver. The implementation for the APIs are in generic
which is applicable for all generation os Tegra SoC.

IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
driver is modified to use the new APIs.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage control APIs in single call.

Changes from V2:
- Remove the tegra_io_rail_power_off/on() apis and change client (sor) driver
to use the new APIs for IO pad power.
- Remove the TEGRA_IO_RAIL_ macros.

Changes from V3:
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.

Changes from V4:
- IO_PAD->IO_PADS
- TEGRA_IO_PADS_POWER_SOURCE_ -> TEGRA_IO_PADS_VCONF_
---
 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 221 ++--
 include/soc/tegra/pmc.h | 132 ++
 3 files changed, 294 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 757c6e8..3ce547a 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1134,7 +1134,7 @@ static void tegra_sor_edp_disable(struct drm_encoder 
*encoder)
dev_err(sor->dev, "failed to disable DP: %d\n", err);
}

-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power off I/O rail: %d\n", err);

@@ -1296,7 +1296,7 @@ static void tegra_sor_edp_enable(struct drm_encoder 
*encoder)
tegra_sor_writel(sor, value, SOR_DP_PADCTL0);

/* step 2 */
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power on I/O rail: %d\n", err);

@@ -1748,7 +1748,7 @@ static void tegra_sor_hdmi_disable(struct drm_encoder 
*encoder)
if (err < 0)
dev_err(sor->dev, "failed to power down SOR: %d\n", err);

-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power off HDMI rail: %d\n", err);

@@ -1787,7 +1787,7 @@ static void tegra_sor_hdmi_enable(struct drm_encoder 
*encoder)

div = clk_get_rate(sor->clk) / 100 * 4;

-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PADS_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power on HDMI rail: %d\n", err);

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 09c2b97..7023a59 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -76,6 +76,10 @@

 #define PMC_SCRATCH41  0x140

+/* Power detect for pad voltage */
+#define PMC_PWR_DET0x48
+#define PMC_PWR_DET_VAL0xe4
+
 #define PMC_SENSOR_CTRL0x1b0
 #define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
 #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
@@ -105,6 +109,14 @@

 #define GPU_RG_CNTRL   0x2d4

+/* Define the IO_PADS SOC for SOC mask to find out that IO pads supported
+ * or not in given SoC.
+ */
+#define TEGRA_IO_PADS_T124 0x1
+#define TEGRA_IO_PADS_T210 0x2
+#define TEGRA_IO_PADS_T124_T210(TEGRA_IO_PADS_T124 |   \
+   TEGRA_IO_PADS_T210)
+
 struct tegra_powergate {
struct generic_pm_domain genpd;
struct tegra_pmc *pmc;
@@ -115,12 +127,23 @@ struct tegra_powergate {
unsigned int num_resets;
 };

+/* tegra_io_pads_config_info: Tegra IO pads bit config info.
+ * @dpd_config_bit: DPD configuration bit 

[PATCH V5 2/3] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()

2016-05-12 Thread Laxman Dewangan
The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.

Signed-off-by: Laxman Dewangan 
Reviewed-by: Jon Hunter 

---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.

Changes from V2:
- Make unsigned long to u32 for some missed variable from V1.

Changes from V3:
- Revert back the value to ulong where time calcualtion is done.

Changes from V4:
- Collected RB from Jon.
---
 drivers/soc/tegra/pmc.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 2c3f1f9..09c2b97 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -875,10 +875,10 @@ static int tegra_io_rail_prepare(unsigned int id, 
unsigned long *request,
return 0;
 }

-static int tegra_io_rail_poll(unsigned long offset, unsigned long mask,
- unsigned long val, unsigned long timeout)
+static int tegra_io_rail_poll(unsigned long offset, u32 mask,
+ u32 val, unsigned long timeout)
 {
-   unsigned long value;
+   u32 value;

timeout = jiffies + msecs_to_jiffies(timeout);

@@ -900,8 +900,9 @@ static void tegra_io_rail_unprepare(void)

 int tegra_io_rail_power_on(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;

mutex_lock(>powergates_lock);
@@ -935,8 +936,9 @@ EXPORT_SYMBOL(tegra_io_rail_power_on);

 int tegra_io_rail_power_off(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;

mutex_lock(>powergates_lock);
-- 
2.1.4



[PATCH V5 1/3] soc/tegra: pmc: Use BIT macro for register field definition

2016-05-12 Thread Laxman Dewangan
Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)

Signed-off-by: Laxman Dewangan 
Acked-by: Jon Hunter 

---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None

Changes from V3:
- None

Changes from V4:
- Collected ack from Jon.
---
 drivers/soc/tegra/pmc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb17345..2c3f1f9 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -45,28 +45,28 @@
 #include 

 #define PMC_CNTRL  0x0
-#define  PMC_CNTRL_SYSCLK_POLARITY (1 << 10)  /* sys clk polarity */
-#define  PMC_CNTRL_SYSCLK_OE   (1 << 11)  /* system clock enable */
-#define  PMC_CNTRL_SIDE_EFFECT_LP0 (1 << 14)  /* LP0 when CPU pwr gated */
-#define  PMC_CNTRL_CPU_PWRREQ_POLARITY (1 << 15)  /* CPU pwr req polarity */
-#define  PMC_CNTRL_CPU_PWRREQ_OE   (1 << 16)  /* CPU pwr req enable */
-#define  PMC_CNTRL_INTR_POLARITY   (1 << 17)  /* inverts INTR polarity */
+#define PMC_CNTRL_SYSCLK_POLARITY  BIT(10) /* sys clk polarity */
+#define PMC_CNTRL_SYSCLK_OEBIT(11) /* system clock enable */
+#define PMC_CNTRL_SIDE_EFFECT_LP0  BIT(14) /* LP0 when CPU pwr gated */
+#define PMC_CNTRL_CPU_PWRREQ_POLARITY  BIT(15) /* CPU pwr req polarity */
+#define PMC_CNTRL_CPU_PWRREQ_OEBIT(16) /* CPU pwr req enable */
+#define PMC_CNTRL_INTR_POLARITYBIT(17)/* inverts INTR polarity 
*/

 #define DPD_SAMPLE 0x020
-#define  DPD_SAMPLE_ENABLE (1 << 0)
-#define  DPD_SAMPLE_DISABLE(0 << 0)
+#define DPD_SAMPLE_ENABLE  BIT(0)
+#define DPD_SAMPLE_DISABLE (0 << 0)

 #define PWRGATE_TOGGLE 0x30
-#define  PWRGATE_TOGGLE_START  (1 << 8)
+#define PWRGATE_TOGGLE_START   BIT(8)

 #define REMOVE_CLAMPING0x34

 #define PWRGATE_STATUS 0x38

 #define PMC_SCRATCH0   0x50
-#define  PMC_SCRATCH0_MODE_RECOVERY(1 << 31)
-#define  PMC_SCRATCH0_MODE_BOOTLOADER  (1 << 30)
-#define  PMC_SCRATCH0_MODE_RCM (1 << 1)
+#define PMC_SCRATCH0_MODE_RECOVERY BIT(31)
+#define PMC_SCRATCH0_MODE_BOOTLOADER   BIT(30)
+#define PMC_SCRATCH0_MODE_RCM  BIT(1)
 #define  PMC_SCRATCH0_MODE_MASK(PMC_SCRATCH0_MODE_RECOVERY | \
 PMC_SCRATCH0_MODE_BOOTLOADER | \
 PMC_SCRATCH0_MODE_RCM)
@@ -77,14 +77,14 @@
 #define PMC_SCRATCH41  0x140

 #define PMC_SENSOR_CTRL0x1b0
-#define PMC_SENSOR_CTRL_SCRATCH_WRITE  (1 << 2)
-#define PMC_SENSOR_CTRL_ENABLE_RST (1 << 1)
+#define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
+#define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)

 #define IO_DPD_REQ 0x1b8
-#define  IO_DPD_REQ_CODE_IDLE  (0 << 30)
-#define  IO_DPD_REQ_CODE_OFF   (1 << 30)
-#define  IO_DPD_REQ_CODE_ON(2 << 30)
-#define  IO_DPD_REQ_CODE_MASK  (3 << 30)
+#define IO_DPD_REQ_CODE_IDLE   (0 << 30)
+#define IO_DPD_REQ_CODE_OFF(1U << 30)
+#define IO_DPD_REQ_CODE_ON (2U << 30)
+#define IO_DPD_REQ_CODE_MASK   (3U << 30)

 #define IO_DPD_STATUS  0x1bc
 #define IO_DPD2_REQ0x1c0
@@ -96,10 +96,10 @@
 #define PMC_SCRATCH54_ADDR_SHIFT   0

 #define PMC_SCRATCH55  0x25c
-#define PMC_SCRATCH55_RESET_TEGRA  (1 << 31)
+#define PMC_SCRATCH55_RESET_TEGRA  BIT(31)
 #define PMC_SCRATCH55_CNTRL_ID_SHIFT   27
 #define PMC_SCRATCH55_PINMUX_SHIFT 24
-#define PMC_SCRATCH55_16BITOP  (1 << 15)
+#define PMC_SCRATCH55_16BITOP  BIT(15)
 #define PMC_SCRATCH55_CHECKSUM_SHIFT   16
 #define PMC_SCRATCH55_I2CSLV1_SHIFT0

-- 
2.1.4



[PATCH V5 0/3] soc/tegra: Add support for IO pads power and voltage control

2016-05-12 Thread Laxman Dewangan
The IO pins of Tegra SoCs are grouped for common control of IO interface
like setting voltage signal levels and power state of the interface. The 
group is generally referred as IO pads. The power state and voltage control
of IO pins can be done at IO pads level.

Tegra124 onwards IO pads support the power down state when system is
active. The voltage levels on IO pads are auto detected on Tegra124/
Tegra132 but it is not in Tegra210. For Tegra210, the SW need to
explicitly configure the voltage levels of IO pads

This series add the interface for the IO pad power state and voltage
configurations. Modifies the client to use new APIs.
Register the child devices to provide the client interface to configure
IO pads power state and voltage from Device tree.

---
Changes from V2: 
- Drop the pinctrl driver from series till pmc interfce is finalise.
- Move client to use the new APIs.
- Remove older APIs to configure IO rail and related macros.

Changes from V3: 
- keep value  to be unsigned long in the dpd_prepare.
- Make all pad_id/io_pad_id to id.
- tegra_io_pad_ -> tegra_io_pads
- dpd_bit -> bit, pwr_mask/bit to mask/bit.
- Rename function to tegra_io_pads_{set,get}_voltage_config
- Make the io pad tables common for all SoC.
- Make io_pads enums.
- Add enums for voltage.
- Drop patch of adding sub devs

Changes from V4:
- Change IO_PAD to IO_PADS.
- Change enum for voltage config 

Laxman Dewangan (3):
  soc/tegra: pmc: Use BIT macro for register field definition
  soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
  soc/tegra: pmc: Add support for IO pads power state and voltage

 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 273 +++-
 include/soc/tegra/pmc.h | 132 +++--
 3 files changed, 321 insertions(+), 92 deletions(-)

-- 
2.1.4



[PATCH v3 2/2] drm: Add helper for simple display pipeline

2016-05-12 Thread Daniel Vetter
On Thu, May 12, 2016 at 02:53:26PM +0200, Noralf Trønnes wrote:
> +/**
> + * struct drm_simple_display_pipe - simple display pipeline
> + * @crtc: CRTC control structure
> + * @plane: Plane control structure
> + * @encoder: Encoder control structure
> + * @connector: Connector control structure
> + * @funcs: Pipeline control functions (optional)
> + *
> + * Simple display pipeline with plane, crtc and encoder collapsed into one
> + * entity. It should be initialized by calling 
> drm_simple_display_pipe_init().
> + */
> +struct drm_simple_display_pipe {
> + struct drm_crtc crtc;
> + struct drm_plane plane;
> + struct drm_encoder encoder;
> + struct drm_connector *connector;
> +
> + struct drm_simple_display_pipe_funcs *funcs;
> +};

Same thing as in the previous patch: Function table pointers should be
const. I totally forgot about this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Imre Deak
On Thu, 2016-05-12 at 16:52 +0300, Ville Syrjälä wrote:
> On Thu, May 12, 2016 at 04:43:05PM +0300, Imre Deak wrote:
> > On Thu, 2016-05-12 at 16:10 +0300, Ville Syrjälä wrote:
> > > On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
> > > > Returning a 0 bpp/cpp value from these functions isn't ever
> > > > valid.
> > > > In
> > > > many cases it can also lead to a div-by-zero possibly at some
> > > > later
> > > > point in time, so make sure we catch such errors as soon as
> > > > possible via
> > > > louder error reporting.
> > > > 
> > > > CC: Dave Airlie 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/drm_crtc.c | 10 +++---
> > > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > b/drivers/gpu/drm/drm_crtc.c
> > > > index 70f9c68..3a32606 100644
> > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t
> > > > format,
> > > > unsigned int *depth,
> > > >    *bpp = 32;
> > > >    break;
> > > >    default:
> > > > -   DRM_DEBUG_KMS("unsupported pixel format %s\n",
> > > > -         drm_get_format_name(format));
> > > > +   WARN(1, "unsupported pixel format %s\n",
> > > > +        drm_get_format_name(format));
> > > 
> > > NAK. This will happen every time drm_helper_mode_fill_fb_struct()
> > > is called with a non-RGB format.
> > 
> > Yep, missed that. So how about handling here those formats
> > explicitly,
> > and emitting a warning only for truly unsupported formats?
> 
> More work to keep this list updated, and it wouldn't prevent any
> div-by-zero with those formats. So I don't really see a point in
> that.

It would avoid the incorrect 'unsupported pixel format' message for
those.

> > 
> > > >    *depth = 0;
> > > >    *bpp = 0;
> > > >    break;
> > > > @@ -5666,8 +5666,12 @@ int drm_format_plane_cpp(uint32_t
> > > > format,
> > > > int plane)
> > > >    unsigned int depth;
> > > >    int bpp;
> > > >  
> > > > -   if (plane >= drm_format_num_planes(format))
> > > > +   if (plane >= drm_format_num_planes(format)) {
> > > > +   WARN(1, "invalid plane %d for format %s\n",
> > > > +        plane, drm_get_format_name(format));
> > > > +
> > > 
> > > We have this check in many places. Should either convert all or
> > > none.
> > 
> > Ok, I can also change drm_format_plane_width()
> > and drm_format_plane_height(). Couldn't spot any other places.
> 
> I thought we might have more. I guess not.
> 
> > 
> > > >    return 0;
> > > > +   }
> > > >  
> > > >    switch (format) {
> > > >    case DRM_FORMAT_YUYV:
> > > > -- 
> > > > 2.5.0
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel at lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 
> 


[PATCH] MAINTAINERS: add entry for the Sync File Framework

2016-05-12 Thread Emil Velikov
Hi Gustavo,

On 11 May 2016 at 14:45, Gustavo Padovan  wrote:
> From: Gustavo Padovan 
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal 
> Signed-off-by: Gustavo Padovan 
> ---
>  MAINTAINERS | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8c10b4c..0abc9c3 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3677,6 +3677,16 @@ F:   include/linux/*fence.h
>  F: Documentation/dma-buf-sharing.txt
>  T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>
> +SYNC FILE FRAMEWORK
> +M: Gustavo Padovan 
> +S: Maintained
> +L: linux-media at vger.kernel.org
> +L: dri-devel at lists.freedesktop.org
> +F: drivers/dma-buf/sync_file.c
> +F: include/linux/sync_file.h
> +F: Documentation/sync_file.txt
> +T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
> +
Do you have commit access to that tree/repo ? If not I'd suggest
dropping/updating the line.

Or you are thinking about being a 'designated' reviewer while Sumit
still handling maintainership/pull requests ? In which case add Sumit
as M: and yourself as R:

Regards,
Emil


[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Ville Syrjälä
On Thu, May 12, 2016 at 04:43:05PM +0300, Imre Deak wrote:
> On Thu, 2016-05-12 at 16:10 +0300, Ville Syrjälä wrote:
> > On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
> > > Returning a 0 bpp/cpp value from these functions isn't ever valid.
> > > In
> > > many cases it can also lead to a div-by-zero possibly at some later
> > > point in time, so make sure we catch such errors as soon as
> > > possible via
> > > louder error reporting.
> > > 
> > > CC: Dave Airlie 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c | 10 +++---
> > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > b/drivers/gpu/drm/drm_crtc.c
> > > index 70f9c68..3a32606 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t format,
> > > unsigned int *depth,
> > >  *bpp = 32;
> > >  break;
> > >  default:
> > > - DRM_DEBUG_KMS("unsupported pixel format %s\n",
> > > -       drm_get_format_name(format));
> > > + WARN(1, "unsupported pixel format %s\n",
> > > +      drm_get_format_name(format));
> > 
> > NAK. This will happen every time drm_helper_mode_fill_fb_struct()
> > is called with a non-RGB format.
> 
> Yep, missed that. So how about handling here those formats explicitly,
> and emitting a warning only for truly unsupported formats?

More work to keep this list updated, and it wouldn't prevent any
div-by-zero with those formats. So I don't really see a point in that.

> 
> > >  *depth = 0;
> > >  *bpp = 0;
> > >  break;
> > > @@ -5666,8 +5666,12 @@ int drm_format_plane_cpp(uint32_t format,
> > > int plane)
> > >  unsigned int depth;
> > >  int bpp;
> > >  
> > > - if (plane >= drm_format_num_planes(format))
> > > + if (plane >= drm_format_num_planes(format)) {
> > > + WARN(1, "invalid plane %d for format %s\n",
> > > +      plane, drm_get_format_name(format));
> > > +
> > 
> > We have this check in many places. Should either convert all or none.
> 
> Ok, I can also change drm_format_plane_width()
> and drm_format_plane_height(). Couldn't spot any other places.

I thought we might have more. I guess not.

> 
> > >  return 0;
> > > + }
> > >  
> > >  switch (format) {
> > >  case DRM_FORMAT_YUYV:
> > > -- 
> > > 2.5.0
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 

-- 
Ville Syrjälä
Intel OTC


[PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

2016-05-12 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patch.

On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:
> Add drm_fb_cma_create_with_funcs() for drivers that need to set the
> dirty() callback.
> 
> Cc: laurent.pinchart at ideasonboard.com
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes since v1:
> - Expand docs
> 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
>  include/drm/drm_fb_cma_helper.h |  3 +++
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
> drm_device *dev, }
> 
>  /**
> - * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
> callback function
> + * drm_fb_cma_create_with_funcs() - helper function for the
> + *  _mode_config_funcs ->fb_create
> + *  callback function
>   *
> - * If your hardware has special alignment or pitch requirements these
> should be
> - * checked before calling this function.
> + * This can be used to set _framebuffer_funcs for drivers that need the
> + * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
> * _framebuffer_funcs.
>   */
> -struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs)

Shouldn't the funcs argument be const ?

Apart from that,

Acked-by: Laurent Pinchart 

>  {
>   struct drm_fb_cma *fb_cma;
>   struct drm_gem_cma_object *objs[4];
> @@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
> drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
>   }
> 
> - fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
> + 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;
> @@ -215,6 +219,21 @@ err_gem_object_unreference:
>   drm_gem_object_unreference_unlocked([i]->base);
>   return ERR_PTR(ret);
>  }
> +EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
> +
> +/**
> + * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
> function
> + *
> + * If your hardware has special alignment or pitch requirements these
> should be
> + * checked before calling this function. Use drm_fb_cma_create_with_funcs()
> if
> + * you need to set _framebuffer_funcs ->dirty.
> + */
> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
> + _fb_cma_funcs);
> +}
>  EXPORT_SYMBOL_GPL(drm_fb_cma_create);
> 
>  /**
> diff --git a/include/drm/drm_fb_cma_helper.h
> b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
>  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
>   struct drm_file *file_priv, unsigned int *handle);
> 
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs);
>  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

-- 
Regards,

Laurent Pinchart



[PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

2016-05-12 Thread Noralf Trønnes

Den 12.05.2016 15:47, skrev Laurent Pinchart:
> Hi Noralf,
>
> Thank you for the patch.
>
> On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:
>> Add drm_fb_cma_create_with_funcs() for drivers that need to set the
>> dirty() callback.
>>
>> Cc: laurent.pinchart at ideasonboard.com
>> Signed-off-by: Noralf Trønnes 
>> ---
>>
>> Changes since v1:
>> - Expand docs
>>
>>   drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
>>   include/drm/drm_fb_cma_helper.h |  3 +++
>>   2 files changed, 28 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
>> b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
>> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
>> @@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
>> drm_device *dev, }
>>
>>   /**
>> - * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
>> callback function
>> + * drm_fb_cma_create_with_funcs() - helper function for the
>> + *  _mode_config_funcs ->fb_create
>> + *  callback function
>>*
>> - * If your hardware has special alignment or pitch requirements these
>> should be
>> - * checked before calling this function.
>> + * This can be used to set _framebuffer_funcs for drivers that need the
>> + * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
>> * _framebuffer_funcs.
>>*/
>> -struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>> -struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
>> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
>> *dev,
>> +struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
>> +struct drm_framebuffer_funcs *funcs)
> Shouldn't the funcs argument be const ?

Yes you're right, drm_framebuffer_init() uses const.
I missed this in my previous patch as well, so I need to fix up
drm_fb_cma_alloc() and drm_fbdev_cma_create_with_funcs() as well.

Thanks.

Noralf.

> Apart from that,
>
> Acked-by: Laurent Pinchart 
>
>>   {
>>  struct drm_fb_cma *fb_cma;
>>  struct drm_gem_cma_object *objs[4];
>> @@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
>> drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
>>  }
>>
>> -fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
>> +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;
>> @@ -215,6 +219,21 @@ err_gem_object_unreference:
>>  drm_gem_object_unreference_unlocked([i]->base);
>>  return ERR_PTR(ret);
>>   }
>> +EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
>> +
>> +/**
>> + * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
>> function
>> + *
>> + * If your hardware has special alignment or pitch requirements these
>> should be
>> + * checked before calling this function. Use drm_fb_cma_create_with_funcs()
>> if
>> + * you need to set _framebuffer_funcs ->dirty.
>> + */
>> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>> +struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
>> +{
>> +return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
>> +_fb_cma_funcs);
>> +}
>>   EXPORT_SYMBOL_GPL(drm_fb_cma_create);
>>
>>   /**
>> diff --git a/include/drm/drm_fb_cma_helper.h
>> b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
>> --- a/include/drm/drm_fb_cma_helper.h
>> +++ b/include/drm/drm_fb_cma_helper.h
>> @@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
>>   int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
>>  struct drm_file *file_priv, unsigned int *handle);
>>
>> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
>> *dev,
>> +struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
>> +struct drm_framebuffer_funcs *funcs);
>>   struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>>  struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);



[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Imre Deak
On Thu, 2016-05-12 at 16:10 +0300, Ville Syrjälä wrote:
> On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
> > Returning a 0 bpp/cpp value from these functions isn't ever valid.
> > In
> > many cases it can also lead to a div-by-zero possibly at some later
> > point in time, so make sure we catch such errors as soon as
> > possible via
> > louder error reporting.
> > 
> > CC: Dave Airlie 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c
> > b/drivers/gpu/drm/drm_crtc.c
> > index 70f9c68..3a32606 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t format,
> > unsigned int *depth,
> >    *bpp = 32;
> >    break;
> >    default:
> > -   DRM_DEBUG_KMS("unsupported pixel format %s\n",
> > -         drm_get_format_name(format));
> > +   WARN(1, "unsupported pixel format %s\n",
> > +        drm_get_format_name(format));
> 
> NAK. This will happen every time drm_helper_mode_fill_fb_struct()
> is called with a non-RGB format.

Yep, missed that. So how about handling here those formats explicitly,
and emitting a warning only for truly unsupported formats?

> >    *depth = 0;
> >    *bpp = 0;
> >    break;
> > @@ -5666,8 +5666,12 @@ int drm_format_plane_cpp(uint32_t format,
> > int plane)
> >    unsigned int depth;
> >    int bpp;
> >  
> > -   if (plane >= drm_format_num_planes(format))
> > +   if (plane >= drm_format_num_planes(format)) {
> > +   WARN(1, "invalid plane %d for format %s\n",
> > +        plane, drm_get_format_name(format));
> > +
> 
> We have this check in many places. Should either convert all or none.

Ok, I can also change drm_format_plane_width()
and drm_format_plane_height(). Couldn't spot any other places.

> >    return 0;
> > +   }
> >  
> >    switch (format) {
> >    case DRM_FORMAT_YUYV:
> > -- 
> > 2.5.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 


[PATCH v3 2/2] PM / Domains: Remove redundant wrapper functions for system PM

2016-05-12 Thread Ulf Hansson
Due to the previous changes to genpd, which removed the suspend_power_off
flag, several of the system PM callbacks is no longer doing any additional
checks but only invoking a corresponding pm_generic_* helper function.

To clean up the code let's remove these wrapper functions as they have
become redundant. Instead assign the system PM callbacks directly to
the pm_generic_*() helper function.

While changing this, it became clear that some of the current system PM
callbacks in genpd, invokes the wrong callback at the driver level. For
example, genpd's ->restore() callback invokes pm_generic_resume(), while
it should be pm_generic_restore(). Let's fix this as well.

Signed-off-by: Ulf Hansson 
---

Changes in v3:
- None.

Changes in v2:
- Updated changelog.

---
 drivers/base/power/domain.c | 203 +++-
 1 file changed, 12 insertions(+), 191 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index a608f52..658eb1b 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -768,48 +768,6 @@ static int pm_genpd_prepare(struct device *dev)
 }

 /**
- * pm_genpd_suspend - Suspend a device belonging to an I/O PM domain.
- * @dev: Device to suspend.
- *
- * Suspend a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a PM domain consisting of I/O devices.
- */
-static int pm_genpd_suspend(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_suspend(dev);
-}
-
-/**
- * pm_genpd_suspend_late - Late suspend of a device from an I/O PM domain.
- * @dev: Device to suspend.
- *
- * Carry out a late suspend of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a PM domain consisting of I/O devices.
- */
-static int pm_genpd_suspend_late(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_suspend_late(dev);
-}
-
-/**
  * pm_genpd_suspend_noirq - Completion of suspend of device in an I/O PM 
domain.
  * @dev: Device to suspend.
  *
@@ -873,92 +831,6 @@ static int pm_genpd_resume_noirq(struct device *dev)
 }

 /**
- * pm_genpd_resume_early - Early resume of a device in an I/O PM domain.
- * @dev: Device to resume.
- *
- * Carry out an early resume of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a power domain consisting of I/O
- * devices.
- */
-static int pm_genpd_resume_early(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_resume_early(dev);
-}
-
-/**
- * pm_genpd_resume - Resume of device in an I/O PM domain.
- * @dev: Device to resume.
- *
- * Resume a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a power domain consisting of I/O devices.
- */
-static int pm_genpd_resume(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_resume(dev);
-}
-
-/**
- * pm_genpd_freeze - Freezing a device in an I/O PM domain.
- * @dev: Device to freeze.
- *
- * Freeze a device under the assumption that its pm_domain field points to the
- * domain member of an object of type struct generic_pm_domain representing
- * a power domain consisting of I/O devices.
- */
-static int pm_genpd_freeze(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return pm_generic_freeze(dev);
-}
-
-/**
- * pm_genpd_freeze_late - Late freeze of a device in an I/O PM domain.
- * @dev: Device to freeze.
- *
- * Carry out a late freeze of a device under the assumption that its
- * pm_domain field points to the domain member of an object of type
- * struct generic_pm_domain representing a power domain consisting of I/O
- * devices.
- */
-static int pm_genpd_freeze_late(struct device *dev)
-{
-   struct generic_pm_domain *genpd;
-
-   dev_dbg(dev, "%s()\n", __func__);
-
-   genpd = dev_to_genpd(dev);
-   if (IS_ERR(genpd))
-   return -EINVAL;
-
-   return 

[PATCH v3 1/2] PM / Domains: Allow genpd to power on during the system PM phases

2016-05-12 Thread Ulf Hansson
If the PM domain is powered off when the first device starts its system PM
prepare phase, genpd prevents any further attempts to power on the PM
domain during the following system PM phases. Not until the system PM
complete phase is finalized for all devices in the PM domain, genpd again
allows it to be powered on.

This behaviour needs to be changed, as a subsystem/driver for a device in
the same PM domain may still need to be able to serve requests in some of
the system PM phases. Accordingly, it may need to runtime resume its
device and thus also request the corresponding PM domain to be powered on.

To deal with these scenarios, let's make the device operational in the
system PM prepare phase by runtime resuming it, no matter if the PM domain
is powered on or off. Changing this also enables us to remove genpd's
suspend_power_off flag, as it's being used to track this condition.
Additionally, we must allow the PM domain to be powered on via runtime PM
during the system PM phases.

This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
driver. It registers a genpd to model the ACP as a PM domain, but
unfortunately it's also abuses genpd's "internal" suspend_power_off flag
to deal with a corner case at system PM resume.

More precisely, the so called SMU block powers on the ACP at system PM
resume, unconditionally if it's being used or not. This may lead to that
genpd's internal status of the power state, may not correctly reflect the
power state of the HW after a system PM resume.

Because of changing the behaviour of genpd, by runtime resuming devices in
the prepare phase, the AMD ACP drm driver no longer have to deal with this
corner case. So let's just drop the related code in this driver.

Cc: David Airlie 
Cc: Alex Deucher 
Cc: Christian König 
Cc: Maruthi Srinivas Bayyavarapu 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ulf Hansson 
---

Changes in v3:
- Updated changelog.

Changes in v2:
- Updated changelog.
- Added a fix in the AMD ACP (Audio CoProcessor) drm driver, which
registers a genpd. The fix removes the usage of genpd's internal
suspend_power_off flag as it's not needed after this change. Because of
this change I am also requesting an ack from the drm driver maintainer.


---
 drivers/base/power/domain.c | 84 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 23 -
 include/linux/pm_domain.h   |  1 -
 3 files changed, 31 insertions(+), 77 deletions(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index de23b64..a608f52 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -187,8 +187,7 @@ static int genpd_poweron(struct generic_pm_domain *genpd, 
unsigned int depth)
struct gpd_link *link;
int ret = 0;

-   if (genpd->status == GPD_STATE_ACTIVE
-   || (genpd->prepared_count > 0 && genpd->suspend_power_off))
+   if (genpd->status == GPD_STATE_ACTIVE)
return 0;

/*
@@ -735,21 +734,22 @@ static int pm_genpd_prepare(struct device *dev)

mutex_lock(>lock);

-   if (genpd->prepared_count++ == 0) {
+   if (genpd->prepared_count++ == 0)
genpd->suspended_count = 0;
-   genpd->suspend_power_off = genpd->status == GPD_STATE_POWER_OFF;
-   }

mutex_unlock(>lock);

-   if (genpd->suspend_power_off)
-   return 0;
-
/*
-* The PM domain must be in the GPD_STATE_ACTIVE state at this point,
-* so genpd_poweron() will return immediately, but if the device
-* is suspended (e.g. it's been stopped by genpd_stop_dev()), we need
-* to make it operational.
+* Even if the PM domain is powered off at this point, we can't expect
+* it to remain in that state during the entire system PM suspend
+* phase. Any subsystem/driver for a device in the PM domain, may still
+* need to serve a request which may require the device to be runtime
+* resumed and its PM domain to be powered.
+*
+* As we are disabling runtime PM at this point, we are preventing the
+* subsystem/driver to decide themselves. For that reason, we need to
+* make sure the device is operational as it may be required in some
+* cases.
 */
pm_runtime_resume(dev);
__pm_runtime_disable(dev, false);
@@ -758,8 +758,7 @@ static int pm_genpd_prepare(struct device *dev)
if (ret) {
mutex_lock(>lock);

-   if (--genpd->prepared_count == 0)
-   genpd->suspend_power_off = false;
+   genpd->prepared_count--;

mutex_unlock(>lock);
pm_runtime_enable(dev);
@@ -786,7 +785,7 @@ static int pm_genpd_suspend(struct device *dev)
if (IS_ERR(genpd))
return -EINVAL;

-   return genpd->suspend_power_off ? 0 : 

[PATCH v3 0/2] PM / Domains: Second step in improving system PM code in genpd

2016-05-12 Thread Ulf Hansson
Changes in v3:
- Changelog of patch 1/2.

Changes in v2:
- Updated changelogs for both patches according to comments from Kevin.
- Updated patch 1/2, as I realized one genpd client driver, (ab)uses
genpd's suspend_power_off flag.

This is the second step in improving the system PM code in genpd. The first
patch is actually fixing a bug while it also enables for further clean-ups,
which is done in the second patch.

The next step of improving system PM code in genpd will move it to the part of
trying to optimize the behaviour, such as avoid waking up devices unless it's
really needed.

Ulf Hansson (2):
  PM / Domains: Allow genpd to power on during the system PM phases
  PM / Domains: Remove redundant wrapper functions for system PM

 drivers/base/power/domain.c | 271 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c |  23 ---
 include/linux/pm_domain.h   |   1 -
 3 files changed, 35 insertions(+), 260 deletions(-)

-- 
1.9.1



[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Ville Syrjälä
On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
> Returning a 0 bpp/cpp value from these functions isn't ever valid. In
> many cases it can also lead to a div-by-zero possibly at some later
> point in time, so make sure we catch such errors as soon as possible via
> louder error reporting.
> 
> CC: Dave Airlie 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_crtc.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 70f9c68..3a32606 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int 
> *depth,
>   *bpp = 32;
>   break;
>   default:
> - DRM_DEBUG_KMS("unsupported pixel format %s\n",
> -   drm_get_format_name(format));
> + WARN(1, "unsupported pixel format %s\n",
> +  drm_get_format_name(format));

NAK. This will happen every time drm_helper_mode_fill_fb_struct()
is called with a non-RGB format.

>   *depth = 0;
>   *bpp = 0;
>   break;
> @@ -5666,8 +5666,12 @@ int drm_format_plane_cpp(uint32_t format, int plane)
>   unsigned int depth;
>   int bpp;
>  
> - if (plane >= drm_format_num_planes(format))
> + if (plane >= drm_format_num_planes(format)) {
> + WARN(1, "invalid plane %d for format %s\n",
> +  plane, drm_get_format_name(format));
> +

We have this check in many places. Should either convert all or none.

>   return 0;
> + }
>  
>   switch (format) {
>   case DRM_FORMAT_YUYV:
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC


[PATCH] drm/imx: Match imx-ipuv3-crtc components using device node in platform data

2016-05-12 Thread Philipp Zabel
The component master driver imx-drm-core matches component devices using
their of_node. Since commit 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc
module autoloading"), the imx-ipuv3-crtc dev->of_node is not set during
probing. Before that, of_node was set and caused an of: modalias to be
used instead of the platform: modalias, which broke module autoloading.

On the other hand, if dev->of_node is not set yet when the imx-ipuv3-crtc
probe function calls component_add, component matching in imx-drm-core
fails. While dev->of_node will be set once the next component tries to
bring up the component master, imx-drm-core component binding will never
succeed if one of the crtc devices is probed last.

This patch adds an of_node pointer to the component platform data and
matches against the pdata->of_node instead of dev->of_node in imx-drm-core
to work around this problem.

Fixes: 950b410dd1ab ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
Signed-off-by: Philipp Zabel 
---
I don't like this workaround on top of a workaround, and I think
commit 950b410dd1ab should eventually be reverted in favor of another
patch that allows the core code to fall back to a platform: modalias
if the pdev->dev.of_node doesn't have a compatible property set.

As an alternative to applying this patch I would see reverting
commit 407c9eba7897 ("drm/imx: Remove of_node assignment from ipuv3-crtc
driver probe") for now, even though I think it is correct.
---
 drivers/gpu/drm/imx/imx-drm-core.c | 8 
 drivers/gpu/ipu-v3/ipu-common.c| 5 +++--
 include/video/imx-ipu-v3.h | 2 ++
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index e26dcde..05229b9 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "imx-drm.h"

@@ -444,6 +445,13 @@ static int compare_of(struct device *dev, void *data)
 {
struct device_node *np = data;

+   /* Special case for DI, dev->of_node may not be set yet */
+   if (strcmp(dev->driver->name, "imx-ipuv3-crtc") == 0) {
+   struct ipu_client_platformdata *pdata = dev->platform_data;
+
+   return pdata->of_node == np;
+   }
+
/* Special case for LDB, one device for two channels */
if (of_node_cmp(np->name, "lvds-channel") == 0) {
np = of_get_parent(np);
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index abb98c7..99dcacf 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -997,7 +997,7 @@ struct ipu_platform_reg {
 };

 /* These must be in the order of the corresponding device tree port nodes */
-static const struct ipu_platform_reg client_reg[] = {
+static struct ipu_platform_reg client_reg[] = {
{
.pdata = {
.csi = 0,
@@ -1048,7 +1048,7 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
mutex_unlock(_client_id_mutex);

for (i = 0; i < ARRAY_SIZE(client_reg); i++) {
-   const struct ipu_platform_reg *reg = _reg[i];
+   struct ipu_platform_reg *reg = _reg[i];
struct platform_device *pdev;
struct device_node *of_node;

@@ -1070,6 +1070,7 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)

pdev->dev.parent = dev;

+   reg->pdata.of_node = of_node;
ret = platform_device_add_data(pdev, >pdata,
   sizeof(reg->pdata));
if (!ret)
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index ad66589..3a2a794 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -345,6 +346,7 @@ struct ipu_client_platformdata {
int dc;
int dp;
int dma[2];
+   struct device_node *of_node;
 };

 #endif /* __DRM_IPU_H__ */
-- 
2.8.0.rc3



[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Daniel Vetter
On Thu, May 12, 2016 at 05:00:06PM +0300, Imre Deak wrote:
> On Thu, 2016-05-12 at 16:52 +0300, Ville Syrjälä wrote:
> > On Thu, May 12, 2016 at 04:43:05PM +0300, Imre Deak wrote:
> > > On Thu, 2016-05-12 at 16:10 +0300, Ville Syrjälä wrote:
> > > > On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
> > > > > Returning a 0 bpp/cpp value from these functions isn't ever
> > > > > valid.
> > > > > In
> > > > > many cases it can also lead to a div-by-zero possibly at some
> > > > > later
> > > > > point in time, so make sure we catch such errors as soon as
> > > > > possible via
> > > > > louder error reporting.
> > > > > 
> > > > > CC: Dave Airlie 
> > > > > Signed-off-by: Imre Deak 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_crtc.c | 10 +++---
> > > > >  1 file changed, 7 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_crtc.c
> > > > > b/drivers/gpu/drm/drm_crtc.c
> > > > > index 70f9c68..3a32606 100644
> > > > > --- a/drivers/gpu/drm/drm_crtc.c
> > > > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > > > @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t
> > > > > format,
> > > > > unsigned int *depth,
> > > > >  *bpp = 32;
> > > > >  break;
> > > > >  default:
> > > > > - DRM_DEBUG_KMS("unsupported pixel format %s\n",
> > > > > -       drm_get_format_name(format));
> > > > > + WARN(1, "unsupported pixel format %s\n",
> > > > > +      drm_get_format_name(format));
> > > > 
> > > > NAK. This will happen every time drm_helper_mode_fill_fb_struct()
> > > > is called with a non-RGB format.
> > > 
> > > Yep, missed that. So how about handling here those formats
> > > explicitly,
> > > and emitting a warning only for truly unsupported formats?
> > 
> > More work to keep this list updated, and it wouldn't prevent any
> > div-by-zero with those formats. So I don't really see a point in
> > that.
> 
> It would avoid the incorrect 'unsupported pixel format' message for
> those.

If that's the entire concern, delete it. New drivers shouldn't use these
functions any more anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 3/3] drm: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()

2016-05-12 Thread Imre Deak
In case of an unknown broadcast message is sent mstb will remain unset,
so check for this.

CC: Dave Airlie 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 12c0ab3..412b9ca 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2334,7 +2334,9 @@ static int drm_dp_mst_handle_up_req(struct 
drm_dp_mst_topology_mgr *mgr)
DRM_DEBUG_KMS("Got RSN: pn: %d avail_pbn %d\n", 
msg.u.resource_stat.port_number, msg.u.resource_stat.available_pbn);
}

-   drm_dp_put_mst_branch_device(mstb);
+   if (mstb)
+   drm_dp_put_mst_branch_device(mstb);
+
memset(>up_req_recv, 0, sizeof(struct 
drm_dp_sideband_msg_rx));
}
return ret;
-- 
2.5.0



[PATCH 2/3] drm/mst: Fix error handling during MST sideband message reception

2016-05-12 Thread Imre Deak
Handle any error due to partial reads, timeouts etc. to avoid parsing
uninitialized data subsequently. Also bail out if the parsing itself
fails.

CC: Dave Airlie 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index a13edf5..12c0ab3 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2204,11 +2204,19 @@ static void drm_dp_get_one_sb_msg(struct 
drm_dp_mst_topology_mgr *mgr, bool up)
ret = drm_dp_dpcd_read(mgr->aux, basereg + curreply,
replyblock, len);
if (ret != len) {
-   DRM_DEBUG_KMS("failed to read a chunk\n");
+   DRM_DEBUG_KMS("failed to read a chunk (len %d, ret 
%d)\n",
+ len, ret);
+
+   return;
}
+
ret = drm_dp_sideband_msg_build(msg, replyblock, len, false);
-   if (ret == false)
+   if (!ret) {
DRM_DEBUG_KMS("failed to build sideband msg\n");
+
+   return;
+   }
+
curreply += len;
replylen -= len;
}
-- 
2.5.0



[PATCH 1/3] drm: Tune up error message during format->bpp/cpp conversion

2016-05-12 Thread Imre Deak
Returning a 0 bpp/cpp value from these functions isn't ever valid. In
many cases it can also lead to a div-by-zero possibly at some later
point in time, so make sure we catch such errors as soon as possible via
louder error reporting.

CC: Dave Airlie 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_crtc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 70f9c68..3a32606 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int 
*depth,
*bpp = 32;
break;
default:
-   DRM_DEBUG_KMS("unsupported pixel format %s\n",
- drm_get_format_name(format));
+   WARN(1, "unsupported pixel format %s\n",
+drm_get_format_name(format));
*depth = 0;
*bpp = 0;
break;
@@ -5666,8 +5666,12 @@ int drm_format_plane_cpp(uint32_t format, int plane)
unsigned int depth;
int bpp;

-   if (plane >= drm_format_num_planes(format))
+   if (plane >= drm_format_num_planes(format)) {
+   WARN(1, "invalid plane %d for format %s\n",
+plane, drm_get_format_name(format));
+
return 0;
+   }

switch (format) {
case DRM_FORMAT_YUYV:
-- 
2.5.0



[PATCH 0/3] drm: Fix/annotate better a few error paths

2016-05-12 Thread Imre Deak
Fix a few minor issues durring error handling, all of these were pointed
at by Coverity reports.

Imre Deak (3):
  drm: Tune up error message during format->bpp/cpp conversion
  drm/mst: Fix error handling during MST sideband message reception
  drm: Avoid dereferencing a NULL mstb in drm_dp_mst_handle_up_req()

 drivers/gpu/drm/drm_crtc.c| 10 +++---
 drivers/gpu/drm/drm_dp_mst_topology.c | 16 +---
 2 files changed, 20 insertions(+), 6 deletions(-)

-- 
2.5.0



[PATCH] radeon and amdgpu drm-fixes-4.6

2016-05-12 Thread Alex Deucher
Hi Dave,

One more small fix for a DP regression in 4.6

The following changes since commit 58a6e2e5794d2aeacf6a84afeaed46e3a5e0fbb0:

  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-05-12 10:05:36 +1000)

are available in the git repository at:

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

for you to fetch changes up to c47b9e0944e483309d66c807d650ac8b8ceafb57:

  drm/amdgpu: fix DP mode validation (2016-05-12 15:03:49 -0400)


Alex Deucher (2):
  drm/radeon: fix DP mode validation
  drm/amdgpu: fix DP mode validation

 drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 4 ++--
 drivers/gpu/drm/radeon/atombios_dp.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)


[PATCH] drm: expand cea861 mode timing table

2016-05-12 Thread Eric Yang
This patch expand the cea861 mode timing table to include vic 65
to 107. This allows more modes to be reported on newer displays,
including 4k at 60Hz on HDMI, which was previously only reported if
the display edid has a detailed timing descriptor block specifying
the exact timing

Signed-off-by: Eric Yang 
---
 drivers/gpu/drm/drm_edid.c | 215 +
 drivers/video/hdmi.c   |   4 +
 include/linux/hdmi.h   |   2 +
 3 files changed, 221 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 04cb487..34ed001 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -988,6 +988,221 @@ static const struct drm_display_mode edid_cea_modes[] = {
   2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720 at 24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59341, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720 at 25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720 at 30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720 at 50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720 at 60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74176, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720 at 100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720 at 120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148352, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080 at 24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080 at 25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080 at 30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74176, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080 at 50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080 at 60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148352, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 77 - 1920x1080 at 100Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 78 - 1920x1080 at 120Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 296704, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | 

[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Daniel Vetter
On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 

When resending you must have a changelog somewhere. At elast in the cover
letter, better is per-patch. Otherwise reviewers need to dig out the old
threads and compare themselves.
-Daniel

> ---
>  Documentation/DocBook/gpu.tmpl  |  10 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic.c|   4 +
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 229 
> 
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  28 +
>  7 files changed, 281 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 9dd48f7..0df6abb 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
>   the underlying hardware).
>   
>   
> +  "zpos" 
> + RANGE
> + Min= driver dependent, Max= driver dependent
> + Plane
> + Plane's 'z' position during blending operation (0 for 
> background, highest for frontmost).
> + If two planes assigned to same CRTC have equal zpos values, the 
> plane with higher plane
> + id is treated as closer to front. Can be IMMUTABLE if driver 
> doesn't support changing
> + planes' order. Exact value range is driver dependent.
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..df88253 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 86e89db..bd457ca 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -700,6 +700,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property) {
>   state->rotation = val;
> + } else if (property == plane->zpos_property) {
> + state->zpos = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -756,6 +758,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_h;
>   } else if (property == config->rotation_property) {
>   *val = state->rotation;
> + } else if (property == plane->zpos_property) {
> + *val = state->zpos;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 997fd21..f10652f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
> +
>  /**
>   * DOC: overview
>   *
> @@ -587,6 +589,10 @@ 

[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Javier Martinez Canillas
>
> And please update the subject as well to include the version number. You can
> use
>
> $ git format-patch --cover --subject-prefix 'PATCH vX'
>

And git even has a -v option now, so this could just be:

$ git format-patch --cover -vX

Best regards,
Javier


[Bug 118131] New: it is an error in drm for radeon

2016-05-12 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=118131

Bug ID: 118131
   Summary: it is an error in drm for radeon
   Product: Drivers
   Version: 2.5
Kernel Version: 4.5.4
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: ahiliation at yahoo.co.in
Regression: No

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

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Trinity [Radeon HD 7480D]

Linux debian 4.5.4 #1 SMP Thu May 12 19:55:29 IST 2016 x86_64 GNU/Linux

i get an error during bootup...

[drm] radeon: irq initialized.
[   11.556777] [drm] ring test on 0 succeeded in 2 usecs
[   11.556788] [drm] ring test on 3 succeeded in 3 usecs
[   11.556795] [drm] ring test on 4 succeeded in 3 usecs
[   11.602519] [drm] ring test on 5 succeeded in 1 usecs
[   11.622959] [drm] UVD initialized successfully.
[   12.714405] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   13.726471] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   14.738556] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   15.750620] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   16.762679] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   17.774740] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   18.786801] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   19.798864] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   20.810927] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   21.822998] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, trying
to reset the ECPU!!!
[   21.842908] [drm:vce_v1_0_start [radeon]] *ERROR* VCE not responding, giving
up!!!
[   21.842975] [drm:cayman_startup [radeon]] *ERROR* radeon: failed
initializing VCE (-1).
[   21.843923] [drm] ib test on ring 0 succeeded in 0 usecs
[   21.86] [drm] ib test on ring 3 succeeded in 0 usecs
[   21.844963] [drm] ib test on ring 4 succeeded in 0 usecs
[   21.865376] [drm] ib test on ring 5 succeeded

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


[PATCH v2 1/2] PM / Domains: Allow genpd to power on during the system PM phase

2016-05-12 Thread Ulf Hansson
On 11 May 2016 at 23:25, Rafael J. Wysocki  wrote:
> On Wed, May 11, 2016 at 10:00 AM, Ulf Hansson  
> wrote:
>> If the PM domain is powered off when the first device in the domain starts
>> its system PM prepare phase, genpd prevents any further attempts to power
>> on the PM domain during the system PM phase. This constraint affects not
>> only the current device which is being prepared, but all devices within
>> the same PM domain.
>
> What exactly do you mean by "the system PM phase"?

In between system PM device prepare and system PM device complete.

Do you want me to clarify this in a better way in the change log?

Kind regards
Uffe


[PATCH v3 2/2] drm: Add helper for simple display pipeline

2016-05-12 Thread Noralf Trønnes
Provides helper functions for drivers that have a simple display
pipeline. Plane, crtc and encoder are collapsed into one entity.

Cc: jsarha at ti.com
Signed-off-by: Noralf Trønnes 
---

Changes since v2:
- Drop Kconfig knob DRM_KMS_HELPER
- Expand documentation

Changes since v1:
- Add DOC header and add to gpu.tmpl
- Fix docs: @funcs is optional, "negative error code",
  "This hook is optional."
- Add checks to drm_simple_kms_plane_atomic_check()

 Documentation/DocBook/gpu.tmpl  |   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c | 209 
 include/drm/drm_simple_kms_helper.h |  95 +++
 4 files changed, 311 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 4a0c599..cf3f5a8 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1693,6 +1693,12 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_panel.c
 !Pdrivers/gpu/drm/drm_panel.c drm panel
 
+
+  Simple KMS Helper Reference
+!Iinclude/drm/drm_simple_kms_helper.h
+!Edrivers/gpu/drm/drm_simple_kms_helper.c
+!Pdrivers/gpu/drm/drm_simple_kms_helper.c overview
+
   

   
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..31b85df5 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.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_kms_helper_common.o drm_simple_kms_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_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
new file mode 100644
index 000..74dbada
--- /dev/null
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: overview
+ *
+ * This helper library provides helpers for drivers for simple display
+ * hardware.
+ *
+ * drm_simple_display_pipe_init() initializes a simple display pipeline
+ * which has only one full-screen scanout buffer feeding one output. The
+ * pipeline is represented by struct _simple_display_pipe and binds
+ * together _plane, _crtc and _encoder structures into one fixed
+ * entity. Some flexibility for code reuse is provided through a separately
+ * allocated _connector object and supporting optional _bridge
+ * encoder drivers.
+ */
+
+static const struct drm_encoder_funcs drm_simple_kms_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->enable)
+   return;
+
+   pipe->funcs->enable(pipe, crtc->state);
+}
+
+static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc)
+{
+   struct drm_simple_display_pipe *pipe;
+
+   pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
+   if (!pipe->funcs || !pipe->funcs->disable)
+   return;
+
+   pipe->funcs->disable(pipe);
+}
+
+static const struct drm_crtc_helper_funcs drm_simple_kms_crtc_helper_funcs = {
+   .disable = drm_simple_kms_crtc_disable,
+   .enable = drm_simple_kms_crtc_enable,
+};
+
+static const struct drm_crtc_funcs drm_simple_kms_crtc_funcs = {
+   .reset = drm_atomic_helper_crtc_reset,
+   .destroy = drm_crtc_cleanup,
+   .set_config = drm_atomic_helper_set_config,
+   .page_flip = drm_atomic_helper_page_flip,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
+   struct drm_plane_state *plane_state)
+{
+   struct drm_rect src = {
+   .x1 = plane_state->src_x,
+   .y1 = plane_state->src_y,
+   .x2 = plane_state->src_x + plane_state->src_w,
+   .y2 = plane_state->src_y + plane_state->src_h,
+   };
+   struct drm_rect dest = {
+   .x1 = plane_state->crtc_x,
+   .y1 = 

[PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

2016-05-12 Thread Noralf Trønnes
Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.

Cc: laurent.pinchart at ideasonboard.com
Signed-off-by: Noralf Trønnes 
---

Changes since v1:
- Expand docs

 drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
 include/drm/drm_fb_cma_helper.h |  3 +++
 2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 3165ac0..ede77c9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct 
drm_device *dev,
 }

 /**
- * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create callback 
function
+ * drm_fb_cma_create_with_funcs() - helper function for the
+ *  _mode_config_funcs ->fb_create
+ *  callback function
  *
- * If your hardware has special alignment or pitch requirements these should be
- * checked before calling this function.
+ * This can be used to set _framebuffer_funcs for drivers that need the
+ * dirty() callback. Use drm_fb_cma_create() if you don't need to change
+ * _framebuffer_funcs.
  */
-struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
-   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs)
 {
struct drm_fb_cma *fb_cma;
struct drm_gem_cma_object *objs[4];
@@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct drm_device 
*dev,
objs[i] = to_drm_gem_cma_obj(obj);
}

-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
+   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;
@@ -215,6 +219,21 @@ err_gem_object_unreference:
drm_gem_object_unreference_unlocked([i]->base);
return ERR_PTR(ret);
 }
+EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
+
+/**
+ * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback function
+ *
+ * If your hardware has special alignment or pitch requirements these should be
+ * checked before calling this function. Use drm_fb_cma_create_with_funcs() if
+ * you need to set _framebuffer_funcs ->dirty.
+ */
+struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
+   _fb_cma_funcs);
+}
 EXPORT_SYMBOL_GPL(drm_fb_cma_create);

 /**
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index c6d9c9c..1f9a8bc 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
 int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle);

+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs);
 struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

--
2.8.2



[PATCH v3 0/2] drm: Add various helpers for simple drivers

2016-05-12 Thread Noralf Trønnes
This patchset adds various helpers that was originally part of the
tinydrm patchset.

4 patches from the previous version have been applied and 2 are now left.

Essentially it adds 2 functions:
- drm_fb_cma_create_with_funcs()
  CMA backed framebuffer supporting a dirty() callback.
- drm_simple_display_pipe_init()
  Plane, crtc and encoder are collapsed into one entity.


Changes since v2:
- drm: Add helper for simple display pipeline
  - Drop Kconfig knob DRM_KMS_HELPER
  - Expand documentation

Changes since v1:
- Drop patch: drm/panel: Add helper for simple panel connector
- Add fb-helper and fb-cma-helper doc patches
- Add drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
- Add drm_atomic_helper_best_encoder()
- drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  - Expand docs
- drm: Add helper for simple display pipeline
  - Add DOC header and add to gpu.tmpl
  - Fix docs: @funcs is optional, "negative error code",
"This hook is optional."
  - Add checks to drm_simple_kms_plane_atomic_check()

Noralf Trønnes (2):
  drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()
  drm: Add helper for simple display pipeline

 Documentation/DocBook/gpu.tmpl  |   6 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_fb_cma_helper.c |  31 -
 drivers/gpu/drm/drm_simple_kms_helper.c | 209 
 include/drm/drm_fb_cma_helper.h |   3 +
 include/drm/drm_simple_kms_helper.h |  95 +++
 6 files changed, 339 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_simple_kms_helper.c
 create mode 100644 include/drm/drm_simple_kms_helper.h

--
2.8.2



[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Ville Syrjälä
On Thu, May 12, 2016 at 12:28:19PM +0200, Benjamin Gaignard wrote:
> From: Marek Szyprowski 
> 
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to plane and plane state structures
> - added helpers for normalizing zpos properties of given set of planes
> - well defined semantics: planes are sorted by zpos values and then plane
>   id value if zpos equals
> 
> Normalized zpos values are calculated automatically when generic
> muttable zpos property has been initialized. Drivers can simply use
> plane_state->normalized_zpos in their atomic_check and/or plane_update
> callbacks without any additional calls to DRM core.
> 
> Signed-off-by: Marek Szyprowski 
> 
> Compare to Marek's original patch zpos property is now specific to each
> plane and no more to the core.
> Normalize function take care of the range of per plane defined range
> before set normalized_zpos.
> 
> Signed-off-by: Benjamin Gaignard 
> 
> Cc: Inki Dae 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Andrzej Hajda 
> Cc: Krzysztof Kozlowski 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Tobias Jakobi 
> Cc: Gustavo Padovan 
> Cc: vincent.abriou at st.com
> Cc: fabien.dessenne at st.com
> Cc: Laurent Pinchart 
> ---
>  Documentation/DocBook/gpu.tmpl  |  10 ++
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_atomic.c|   4 +
>  drivers/gpu/drm/drm_atomic_helper.c |   6 +
>  drivers/gpu/drm/drm_blend.c | 229 
> 
>  drivers/gpu/drm/drm_crtc_internal.h |   3 +
>  include/drm/drm_crtc.h  |  28 +
>  7 files changed, 281 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_blend.c
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 9dd48f7..0df6abb 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
>   the underlying hardware).
>   
>   
> +  "zpos" 
> + RANGE
> + Min= driver dependent, Max= driver dependent
> + Plane
> + Plane's 'z' position during blending operation (0 for 
> background, highest for frontmost).
> + If two planes assigned to same CRTC have equal zpos values, the 
> plane with higher plane
> + id is treated as closer to front. Can be IMMUTABLE if driver 
> doesn't support changing
> + planes' order. Exact value range is driver dependent.
> + 
> + 
>   i915
>   Generic
>   "Broadcast RGB"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 2bd3e5a..df88253 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the drm device driver.  This driver provides support for the
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
> -drm-y   :=   drm_auth.o drm_bufs.o drm_cache.o \
> +drm-y   :=   drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
>   drm_context.o drm_dma.o \
>   drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 86e89db..bd457ca 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -700,6 +700,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property) {
>   state->rotation = val;
> + } else if (property == plane->zpos_property) {
> + state->zpos = val;
>   } else if (plane->funcs->atomic_set_property) {
>   return plane->funcs->atomic_set_property(plane, state,
>   property, val);
> @@ -756,6 +758,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_h;
>   } else if (property == config->rotation_property) {
>   *val = state->rotation;
> + } else if (property == plane->zpos_property) {
> + *val = state->zpos;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
> property, val);
>   } else {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 997fd21..f10652f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
> +
>  /**
>   * DOC: overview
>   *
> @@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
>   struct drm_plane_state *plane_state;
>   int i, ret = 0;
>  
> + ret = drm_atomic_helper_normalize_zpos(dev, state);
> + if (ret)
> +  

[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-12 Thread Stephen Boyd
On 05/12, Maxime Ripard wrote:
> 
> diff --git a/drivers/clk/sunxi/clk-sun4i-display.c 
> b/drivers/clk/sunxi/clk-sun4i-display.c
> index 70803aa7028c..9780fac6d029 100644
> --- a/drivers/clk/sunxi/clk-sun4i-display.c
> +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> @@ -128,8 +128,8 @@ static void __init sun4i_a10_display_init(struct 
> device_node *node,
>   return;
>   }
>  
> - ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
> - if (ret != ARRAY_SIZE(parents)) {
> + ret = of_clk_parent_fill(node, parents, data->parents);
> + if (ret != data->parents) {
>   pr_err("%s: Could not retrieve the parents\n", clk_name);
>   goto unmap;
>   }

Ah ok. Thanks for catching that thinko and sending a patch.

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


[PATCH] MAINTAINERS: add entry for the Sync File Framework

2016-05-12 Thread Maarten Lankhorst
Op 11-05-16 om 15:45 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal 
> Signed-off-by: Gustavo Padovan 
Acked-by: Maarten Lankhorst 


drm: sun4i: Add composite output

2016-05-12 Thread Dan Carpenter
Hello Maxime Ripard,

The patch 03c4c71d25b4: "drm: sun4i: Add composite output" from Oct
29, 2015, leads to the following static checker warning:

drivers/gpu/drm/sun4i/sun4i_tv.c:513 sun4i_tv_comp_get_modes()
error: potential null dereference 'mode'.  (drm_mode_create returns 
null)

drivers/gpu/drm/sun4i/sun4i_tv.c
   505  static int sun4i_tv_comp_get_modes(struct drm_connector *connector)
   506  {
   507  int i;
   508  
   509  for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
   510  struct drm_display_mode *mode = 
drm_mode_create(connector->dev);
 
^^
   511  struct tv_mode *tv_mode = _modes[i];
   512  
   513  strcpy(mode->name, tv_mode->name);
   ^^
   514  
   515  sun4i_tv_mode_to_drm_mode(tv_mode, mode);
   516  drm_mode_probed_add(connector, mode);
   517  }
   518  
   519  return i;
   520  }

regards,
dan carpenter


[PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array

2016-05-12 Thread Jani Nikula
On Wed, 11 May 2016, Muhammad Falak R Wani  wrote:
> Use ARRAY_SIZE() for the size calculation of the array. Also move the
> condition evaulation function out of the for loop.
> Although, any respectable c-compiler would optimize this and evaluate
> the function only once outside the loop, but the optimzation engine
> of gcc is bit brain-dead, and at times needs some hand holding.

This just caught my eye. ARRAY_SIZE is a macro that expands to a compile
time constant. Arguably adding the the local variable here gives GCC
more chances to go wrong than keeping the ARRAY_SIZE in the loop
condition.

BR,
Jani.

>
> Signed-off-by: Muhammad Falak R Wani 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> index da18f44..718a551 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> @@ -636,10 +636,11 @@ static int cz_smu_populate_firmware_entries(struct 
> pp_smumgr *smumgr)
>   int ret;
>   enum cgs_ucode_id ucode_id;
>   struct cgs_firmware_info info = {0};
> + int n = ARRAY_SIZE(firmware_list);
>  
>   cz_smu->driver_buffer_length = 0;
>  
> - for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
> + for (i = 0; i < n; i++) {
>  
>   firmware_type = cz_translate_firmware_enum_to_arg(smumgr,
>   firmware_list[i]);

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH] drm: mediatek: remove IOMMU_DMA select

2016-05-12 Thread Philipp Zabel
Am Mittwoch, den 11.05.2016, 22:11 +0200 schrieb Arnd Bergmann:
> We get a harmless build warning when trying to use the mediatek
> DRM driver with IOMMU support disabled:
> 
> warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies 
> (IOMMU_SUPPORT)
> 
> However, the IOMMU_DMA symbol is not meant to be used by drivers
> at all, and this driver doesn't seem to have a strict dependency
> on it other than using the mediatek IOMMU driver that does.
> 
> Since we also want to be able to do compile tests with the
> driver on other platforms, the IOMMU_DMA symbol should not
> be selected here.
> 
> Signed-off-by: Arnd Bergmann 
> ---
> If someone has a better explanation about why the 'select' is here,
> let me know, it certainly seems out of place.

No, it just has been there since the initial RFC and nobody noticed.

>  drivers/gpu/drm/mediatek/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> index 0c06a69d7f04..545973f6b743 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -7,7 +7,6 @@ config DRM_MEDIATEK
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL
> - select IOMMU_DMA
>   select MEMORY
>   select MTK_SMI
>   help

Acked-by: Philipp Zabel 

I tried
  make ARCH=arm64 allnoconfig
and then set
  CONFIG_MODULES=y
  CONFIG_ARCH_MEDIATEK=y
  CONFIG_DRM=m
  CONFIG_DRM_MEDIATEK=m

And it builds fine with IOMMU_DMA/MTK_IOMMU disabled.

thanks
Philipp



[PATCH v2 6/6] drm: Add helper for simple display pipeline

2016-05-12 Thread Daniel Vetter
On Thu, May 12, 2016 at 12:18 PM, Noralf Trønnes  wrote:
> Den 12.05.2016 10:11, skrev Daniel Vetter:
>>
>> On Wed, May 11, 2016 at 07:09:10PM +0200, Daniel Vetter wrote:
>>>
>>> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:

 +/**
 + * drm_simple_display_pipe_init - Initialize a simple display pipeline
 + * @dev: DRM device
 + * @pipe: simple display pipe object to initialize
 + * @funcs: callbacks for the display pipe (optional)
 + * @formats: array of supported formats (%DRM_FORMAT_*)
 + * @format_count: number of elements in @formats
 + * @connector: connector to attach and register
 + *
 + * Sets up a display pipeline which consist of a really simple
 + * plane-crtc-encoder pipe coupled with the provided connector.
>>>
>>> How are drivers supposed to release this stuff again? Maybe add:
>>>
>>> "Teardown of a simple display pipe is all handled automatically by the
>>> drm
>>> core through calling drm_mode_config_cleanup()."
>>
>> Thought a bit more about this, maybe we should also add "Drivers
>> afterwards need to release the memory for the structure themselves."
>>
>> Btw one other thing I realized is that there's no atomic_commit for this.
>> How do you plane to implement async commit? No need to address this right
>> away, we can discuss it when you've rebased tinydrm and submit that for
>> review.
>> -Daniel
>
>
> I don't follow you here. Isn't this atomic_commit:
>
> drm_atomic_helper_commit => drm_atomic_helper_commit_planes =>
> drm_simple_kms_plane_atomic_update => pipe->funcs->update

drm_atomic_helper_commit does not implement nonblocking commits,
because that's a bit tricky when there's more than 1 crtc. But if you
only have 1 crtc it's easy. And without nonblocking commit the legacy
pageflip stuff will also not work.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


[PATCH 4/4] drm: rcar: use generic code for managing zpos plane property

2016-05-12 Thread Benjamin Gaignard
This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.

Signed-off-by: Benjamin Gaignard 

Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Laurent Pinchart 
Cc: Marek Szyprowski 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 5 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
 drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
 5 files changed, 3 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..28d2cb6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,

 static unsigned int plane_zpos(struct rcar_du_plane *plane)
 {
-   return to_rcar_plane_state(plane->plane.state)->zpos;
+   return plane->plane.state->normalized_zpos;
 }

 static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
-   struct drm_property *zpos;
} props;

unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index e70a4f3..4ace0aa 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;

-   rcdu->props.zpos =
-   drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
-   if (rcdu->props.zpos == NULL)
-   return -ENOMEM;
-
return 0;
 }

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 8460ae1..4764afc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -656,7 +656,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
-   state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;

plane->state = >state;
plane->state->plane = plane;
@@ -674,8 +674,6 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
-   else if (property == rcdu->props.zpos)
-   rstate->zpos = val;
else
return -EINVAL;

@@ -694,8 +692,6 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
-   else if (property == rcdu->props.zpos)
-   *val = rstate->zpos;
else
return -EINVAL;

@@ -767,8 +763,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(>plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
-   drm_object_attach_property(>plane.base,
-  rcdu->props.zpos, 1);
+   drm_plane_create_zpos_property(>plane, 1, 7);
}

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @hwindex: 0-based hardware plane index, -1 means unused
  * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
  */
 struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {

unsigned int alpha;
unsigned int colorkey;
-   unsigned int zpos;
 };

 static inline struct rcar_du_plane_state *
-- 
1.9.1



[PATCH 3/4] drm/exynos: use generic code for managing zpos plane property

2016-05-12 Thread Benjamin Gaignard
From: Marek Szyprowski 

This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  2 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
 drivers/gpu/drm/exynos/exynos_mixer.c |  6 ++-
 3 files changed, 13 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cc33ec9..b34a7b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
-   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

struct device *dma_dev;
unsigned long da_start;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 50185ac..bbaf6d3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
-   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = _state->base;
plane->state->plane = plane;
+   plane->state->zpos = exynos_plane->config->zpos;
}
 }

@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, >base);
-   copy->zpos = exynos_state->zpos;
return >base;
 }

@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
-   struct drm_plane_state *state,
-   struct drm_property *property,
-   uint64_t val)
-{
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-   struct exynos_drm_plane_state *exynos_state =
-   to_exynos_plane_state(state);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-   const struct exynos_drm_plane_config *config = exynos_plane->config;
-
-   if (property == dev_priv->plane_zpos_property &&
-   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
-   exynos_state->zpos = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
-   const struct exynos_drm_plane_state *exynos_state =
-   container_of(state, const struct exynos_drm_plane_state, base);
-   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
-   if (property == dev_priv->plane_zpos_property)
-   *val = exynos_state->zpos;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
-   .atomic_set_property = exynos_drm_plane_atomic_set_property,
-   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

 static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
 {
-   struct drm_device *dev = plane->dev;
-   struct exynos_drm_private 

[PATCH 2/4] drm: sti: use generic zpos for plane

2016-05-12 Thread Benjamin Gaignard
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 drivers/gpu/drm/sti/sti_mixer.c |  9 ++---
 drivers/gpu/drm/sti/sti_plane.c | 80 +++--
 drivers/gpu/drm/sti/sti_plane.h |  2 --
 3 files changed, 31 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index e7425c3..d93f537 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -245,13 +245,10 @@ static void sti_mixer_set_background_area(struct 
sti_mixer *mixer,

 int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
 {
-   int plane_id, depth = plane->zorder;
+   int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;

-   if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
-   return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -284,8 +281,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer, 
struct sti_plane *plane)
break;
}

-   mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
-   plane_id = plane_id << (3 * (depth - 1));
+   mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+   plane_id = plane_id << (3 * depth);

DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
 sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index f10c98d..0e447d9 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
 #include "sti_drv.h"
 #include "sti_plane.h"

-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
-   STI_GDP_0,
-   STI_GDP_1,
-   STI_HQVDP_0,
-   STI_GDP_2,
-   STI_GDP_3,
-};
-
 const char *sti_plane_to_str(struct sti_plane *plane)
 {
switch (plane->desc) {
@@ -114,69 +105,54 @@ static void sti_plane_destroy(struct drm_plane *drm_plane)
drm_plane_cleanup(drm_plane);
 }

-static int sti_plane_set_property(struct drm_plane *drm_plane,
- struct drm_property *property,
- uint64_t val)
+static int sti_plane_get_default_zpos(enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-
-   DRM_DEBUG_DRIVER("\n");
-
-   if (property == private->plane_zorder_property) {
-   plane->zorder = val;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
return 0;
+   case DRM_PLANE_TYPE_OVERLAY:
+   return 1;
+   case DRM_PLANE_TYPE_CURSOR:
+   return 7;
}
+   return 0;
+}

-   return -EINVAL;
+static void sti_plane_reset(struct drm_plane *plane)
+{
+   drm_atomic_helper_plane_reset(plane);
+   plane->state->zpos = sti_plane_get_default_zpos(plane->type);
 }

-static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane)
+static void sti_plane_attach_zorder_property(struct drm_plane *drm_plane,
+enum drm_plane_type type)
 {
-   struct drm_device *dev = drm_plane->dev;
-   struct sti_private *private = dev->dev_private;
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-   struct drm_property *prop;
-
-   prop = private->plane_zorder_property;
-   if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos", 1,
-GAM_MIXER_NB_DEPTH_LEVEL);
-   if (!prop)
-   return;
-
-   private->plane_zorder_property = prop;
+   switch (type) {
+   case DRM_PLANE_TYPE_PRIMARY:
+   case DRM_PLANE_TYPE_OVERLAY:
+   drm_plane_create_zpos_property(drm_plane, 0, 6);
+   break;
+   case DRM_PLANE_TYPE_CURSOR:
+   drm_plane_create_zpos_immutable_property(drm_plane, 7, 7);
+   break;
}
-
-   drm_object_attach_property(_plane->base, prop, plane->zorder);
 }

 void sti_plane_init_property(struct sti_plane *plane,
 enum drm_plane_type type)
 {
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(sti_plane_default_zorder); i++)
-   if (sti_plane_default_zorder[i] == plane->desc)
-   

[PATCH 1/4] drm: add generic zpos property

2016-05-12 Thread Benjamin Gaignard
From: Marek Szyprowski 

This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals

Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.

Signed-off-by: Marek Szyprowski 

Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.

Signed-off-by: Benjamin Gaignard 

Cc: Inki Dae 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Andrzej Hajda 
Cc: Krzysztof Kozlowski 
Cc: Bartlomiej Zolnierkiewicz 
Cc: Tobias Jakobi 
Cc: Gustavo Padovan 
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart 
---
 Documentation/DocBook/gpu.tmpl  |  10 ++
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_atomic.c|   4 +
 drivers/gpu/drm/drm_atomic_helper.c |   6 +
 drivers/gpu/drm/drm_blend.c | 229 
 drivers/gpu/drm/drm_crtc_internal.h |   3 +
 include/drm/drm_crtc.h  |  28 +
 7 files changed, 281 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_blend.c

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9dd48f7..0df6abb 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2151,6 +2151,16 @@ void intel_crt_init(struct drm_device *dev)
the underlying hardware).


+"zpos" 
+   RANGE
+   Min= driver dependent, Max= driver dependent
+   Plane
+   Plane's 'z' position during blending operation (0 for 
background, highest for frontmost).
+   If two planes assigned to same CRTC have equal zpos values, the 
plane with higher plane
+   id is treated as closer to front. Can be IMMUTABLE if driver 
doesn't support changing
+   planes' order. Exact value range is driver dependent.
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2bd3e5a..df88253 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o drm_blend.o drm_cache.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 86e89db..bd457ca 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -700,6 +700,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == plane->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -756,6 +758,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == plane->zpos_property) {
+   *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 997fd21..f10652f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -32,6 +32,8 @@
 #include 
 #include 

+#include "drm_crtc_internal.h"
+
 /**
  * DOC: overview
  *
@@ -587,6 +589,10 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;

+   ret = drm_atomic_helper_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
new file mode 100644

[PATCH v2 6/6] drm: Add helper for simple display pipeline

2016-05-12 Thread Noralf Trønnes
Den 12.05.2016 10:11, skrev Daniel Vetter:
> On Wed, May 11, 2016 at 07:09:10PM +0200, Daniel Vetter wrote:
>> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
>>> +/**
>>> + * drm_simple_display_pipe_init - Initialize a simple display pipeline
>>> + * @dev: DRM device
>>> + * @pipe: simple display pipe object to initialize
>>> + * @funcs: callbacks for the display pipe (optional)
>>> + * @formats: array of supported formats (%DRM_FORMAT_*)
>>> + * @format_count: number of elements in @formats
>>> + * @connector: connector to attach and register
>>> + *
>>> + * Sets up a display pipeline which consist of a really simple
>>> + * plane-crtc-encoder pipe coupled with the provided connector.
>> How are drivers supposed to release this stuff again? Maybe add:
>>
>> "Teardown of a simple display pipe is all handled automatically by the drm
>> core through calling drm_mode_config_cleanup()."
> Thought a bit more about this, maybe we should also add "Drivers
> afterwards need to release the memory for the structure themselves."
>
> Btw one other thing I realized is that there's no atomic_commit for this.
> How do you plane to implement async commit? No need to address this right
> away, we can discuss it when you've rebased tinydrm and submit that for
> review.
> -Daniel

I don't follow you here. Isn't this atomic_commit:

drm_atomic_helper_commit => drm_atomic_helper_commit_planes =>
drm_simple_kms_plane_atomic_update => pipe->funcs->update

Noralf.



[GIT PULL v2] drm/panel: Changes for v4.7-rc1

2016-05-12 Thread Thierry Reding
Hi Dave,

The following changes since commit 95306975e9dd38ba2775dd96cb29987ecc7d9360:

  Merge tag 'drm/tegra/for-4.7-rc1' of 
git://anongit.freedesktop.org/tegra/linux into drm-next (2016-05-12 11:15:18 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.7-rc1

for you to fetch changes up to 227e4f4079e198695b9b5df344aa0e29676a5a29:

  drm/panel: simple: Add support for TPK U.S.A. LLC Fusion 7" and 10.1" panels 
(2016-05-12 11:32:14 +0200)

This is the same pull request as I sent yesterday but rebased on your
drm-next branch, and hence the two bus_flags patches are no longer
included.

Thanks,
Thierry


drm/panel: Changes for v4.7-rc1

This contains support for a bunch of new panels in the simple panel
driver along with some cleanup and support for a new Analogix HDMI to DP
bridge.


Bhuvanchandra DV (1):
  drm/panel: simple: Add support for TPK U.S.A. LLC Fusion 7" and 10.1" 
panels

Boris Brezillon (2):
  drm/panel: simple: Set appropriate mode type
  drm/panel: simple: Remove useless drm_mode_set_name()

Enric Balletbo i Serra (4):
  drm/dp: Add define to set 0.5% down-spread in MAX_DOWNSPREAD register
  of: Add vendor prefix for Analogix Semiconductor
  devicetree: Add ANX7814 SlimPort transmitter binding
  drm/bridge: Add Analogix anx78xx support

Eric Anholt (2):
  of: Add vendor prefix for On Tat Industrial Company.
  drm/panel: simple: Add the 7" DPI panel from Adafruit

Maxime Ripard (1):
  drm/panel: simple: Add timings for the Olimex LCD-OLinuXino-4.3TS

Riccardo Bortolato (1):
  drm/panel: simple: Add support for Innolux AT070TN92

 .../bindings/display/panel/innolux,at070tn92.txt   |7 +
 .../display/panel/olimex,lcd-olinuxino-43-ts.txt   |7 +
 .../bindings/display/panel/ontat,yx700wv03.txt |7 +
 .../bindings/display/panel/tpk,f07a-0102.txt   |8 +
 .../bindings/display/panel/tpk,f10a-0102.txt   |8 +
 .../devicetree/bindings/vendor-prefixes.txt|3 +
 .../devicetree/bindings/video/bridge/anx7814.txt   |   40 +
 drivers/gpu/drm/bridge/Kconfig |   10 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix-anx78xx.c  | 1514 
 drivers/gpu/drm/bridge/analogix-anx78xx.h  |  719 ++
 drivers/gpu/drm/panel/panel-simple.c   |  151 +-
 include/drm/drm_dp_helper.h|1 +
 13 files changed, 2475 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino-43-ts.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tpk,f07a-0102.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/tpk,f10a-0102.txt
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.c
 create mode 100644 drivers/gpu/drm/bridge/analogix-anx78xx.h


[GIT PULL] drm/panel: Changes for v4.7-rc1

2016-05-12 Thread Dave Airlie
On 11 May 2016 at 00:58, Thierry Reding  wrote:
> Hi Dave,
>
> The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
>
>   Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.7-rc1
>
> for you to fetch changes up to 69b3478efeed79059dcf1ee0cf1d08abb12d:
>
>   drm/panel: simple: Add support for TPK U.S.A. LLC Fusion 7" and 10.1" 
> panels (2016-05-10 14:32:22 +0200)
>
> As I mentioned in another email earlier today, I've had to pull in
> Stefan's two patches (for the bus_flags) because another patch in this
> tree depends on it. I just checked your drm-next branch and you hadn't
> yet pulled Stefan's request, so hopefully this will work out okay. If
> you want to pull separately, let me know and I'll remove the patches
> and the patch that depends on it again.

Can you rebase it onto drm-next? I've definitely pulled those patches
in at this point.

Dave.


[Bug 95206] Display port bandwidth regression

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95206

--- Comment #12 from Christian L.  ---
Your fix works like a charm. Thanks alot!

Applied the fix to 4.5.0 mainline and the problem is gone.

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


[PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array

2016-05-12 Thread Eric Engestrom
On Wed, May 11, 2016 at 11:18:43PM +0530, Muhammad Falak R Wani wrote:
> Use ARRAY_SIZE() for the size calculation of the array. Also move the
> condition evaulation function out of the for loop.
> Although, any respectable c-compiler would optimize this and evaluate
> the function only once outside the loop, but the optimzation engine
> of gcc is bit brain-dead, and at times needs some hand holding.

`sizeof` is actually a compile-time thing, so at worst, if no
optimisation is made, the runtime result is a division of two
literals, eg. `for (i = 0; i < 64/8; i++)` (which I doubt any
compiler would leave as is anyway)

So, +1 on using ARRAY_SIZE, -1 on creating a new variable (which
is not even `const` btw)

> 
> Signed-off-by: Muhammad Falak R Wani 
> ---
>  drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> index da18f44..718a551 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> @@ -636,10 +636,11 @@ static int cz_smu_populate_firmware_entries(struct 
> pp_smumgr *smumgr)
>   int ret;
>   enum cgs_ucode_id ucode_id;
>   struct cgs_firmware_info info = {0};
> + int n = ARRAY_SIZE(firmware_list);
>  
>   cz_smu->driver_buffer_length = 0;
>  
> - for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
> + for (i = 0; i < n; i++) {
>  
>   firmware_type = cz_translate_firmware_enum_to_arg(smumgr,
>   firmware_list[i]);
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-12 Thread Maxime Ripard
On Thu, May 12, 2016 at 08:59:43AM +0200, Maxime Ripard wrote:
> On Thu, May 12, 2016 at 06:39:20AM +0300, Priit Laes wrote:
> > On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote:
> > > On 05/10, Priit Laes wrote:
> > > > 
> > > > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> > > > > 
> > > > > On 05/09, Stephen Boyd wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Ok I applied this one to clk-next.
> > > > > > 
> > > > > And I squashed this in to silence the following checker warning.
> > > > > 
> > > > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > > > > length array is used.
> > > > > 
> > > > > ---8<---
> > > > > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> > > > > b/drivers/clk/sunxi/clk-sun4i-display.c
> > > > > index f02e250e64ed..f8ff6c4a5633 100644
> > > > > --- a/drivers/clk/sunxi/clk-sun4i-display.c
> > > > > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > > > > @@ -107,7 +107,7 @@ static int
> > > > > sun4i_a10_display_reset_xlate(struct
> > > > > reset_controller_dev *rcdev,
> > > > >  static void __init sun4i_a10_display_init(struct device_node
> > > > > *node,
> > > > >    const struct
> > > > > sun4i_a10_display_clk_data *data)
> > > > >  {
> > > > > - const char *parents[data->parents];
> > > > > + const char *parents[4];
> > > > This change breaks at least de_[bf]e clocks which have 3 clock
> > > > parents.
> > 
> > > I just used the largest data->parents number, which was 4. How
> > > does that break anything?
> > 
> > If you look at the sun4i_a10_display_init, it contains this block:
> > 
> >     ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
> >     if (ret != ARRAY_SIZE(parents)) {
> >         pr_err("%s: Could not retrieve the parents\n", clk_name);
> >         goto unmap;
> >     }
> > 
> > of_clk_parent_fill returns 3 for de_be/de_fe nodes, and
> > ARRAY_SIZE(parents) is 4.
> 
> Replacing both ARRAY_SIZE(parents) by data->parents would work though.

I just tested on top of current next, and indeed the following patch
is needed.

Stephen, could you squash it in the former patch?

diff --git a/drivers/clk/sunxi/clk-sun4i-display.c 
b/drivers/clk/sunxi/clk-sun4i-display.c
index 70803aa7028c..9780fac6d029 100644
--- a/drivers/clk/sunxi/clk-sun4i-display.c
+++ b/drivers/clk/sunxi/clk-sun4i-display.c
@@ -128,8 +128,8 @@ static void __init sun4i_a10_display_init(struct 
device_node *node,
return;
}

-   ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
-   if (ret != ARRAY_SIZE(parents)) {
+   ret = of_clk_parent_fill(node, parents, data->parents);
+   if (ret != data->parents) {
pr_err("%s: Could not retrieve the parents\n", clk_name);
goto unmap;
}

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160512/bea383f2/attachment.sig>


[PATCH] drm: mediatek: remove IOMMU_DMA select

2016-05-12 Thread Robin Murphy
On 11/05/16 21:11, Arnd Bergmann wrote:
> We get a harmless build warning when trying to use the mediatek
> DRM driver with IOMMU support disabled:
>
> warning: (DRM_MEDIATEK) selects IOMMU_DMA which has unmet direct dependencies 
> (IOMMU_SUPPORT)
>
> However, the IOMMU_DMA symbol is not meant to be used by drivers
> at all, and this driver doesn't seem to have a strict dependency
> on it other than using the mediatek IOMMU driver that does.
>
> Since we also want to be able to do compile tests with the
> driver on other platforms, the IOMMU_DMA symbol should not
> be selected here.
>
> Signed-off-by: Arnd Bergmann 
> ---
> If someone has a better explanation about why the 'select' is here,
> let me know, it certainly seems out of place.

Ack - it's neither an IOMMU driver nor a DMA API implementation, so it 
has no business with IOMMU_DMA. If there's an IOMMU dependency in 
general it should be on MTK_IOMMU, not underlying implementation details.

Robin.

>   drivers/gpu/drm/mediatek/Kconfig | 1 -
>   1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> index 0c06a69d7f04..545973f6b743 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -7,7 +7,6 @@ config DRM_MEDIATEK
>   select DRM_KMS_HELPER
>   select DRM_MIPI_DSI
>   select DRM_PANEL
> - select IOMMU_DMA
>   select MEMORY
>   select MTK_SMI
>   help
>



[PATCH v2 6/6] drm: Add helper for simple display pipeline

2016-05-12 Thread Daniel Vetter
On Wed, May 11, 2016 at 07:09:10PM +0200, Daniel Vetter wrote:
> On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote:
> > +/**
> > + * drm_simple_display_pipe_init - Initialize a simple display pipeline
> > + * @dev: DRM device
> > + * @pipe: simple display pipe object to initialize
> > + * @funcs: callbacks for the display pipe (optional)
> > + * @formats: array of supported formats (%DRM_FORMAT_*)
> > + * @format_count: number of elements in @formats
> > + * @connector: connector to attach and register
> > + *
> > + * Sets up a display pipeline which consist of a really simple
> > + * plane-crtc-encoder pipe coupled with the provided connector.
> 
> How are drivers supposed to release this stuff again? Maybe add:
> 
> "Teardown of a simple display pipe is all handled automatically by the drm
> core through calling drm_mode_config_cleanup()."

Thought a bit more about this, maybe we should also add "Drivers
afterwards need to release the memory for the structure themselves."

Btw one other thing I realized is that there's no atomic_commit for this.
How do you plane to implement async commit? No need to address this right
away, we can discuss it when you've rebased tinydrm and submit that for
review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


[PATCH 2/2] drm/amdgpu: fix DP mode validation

2016-05-12 Thread Alex Deucher
Switch the order of the loops to walk the rates on the top
so we exhaust all DP 1.1 rate/lane combinations before trying
DP 1.2 rate/lane combos.

This avoids selecting rates that are supported by the monitor,
but not the connector leading to valid modes getting rejected.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
index bf731e9..7f85c2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
@@ -276,8 +276,8 @@ static int amdgpu_atombios_dp_get_dp_link_config(struct 
drm_connector *connector
}
}
} else {
-   for (lane_num = 1; lane_num <= max_lane_num; lane_num <<= 1) {
-   for (i = 0; i < ARRAY_SIZE(link_rates) && link_rates[i] 
<= max_link_rate; i++) {
+   for (i = 0; i < ARRAY_SIZE(link_rates) && link_rates[i] <= 
max_link_rate; i++) {
+   for (lane_num = 1; lane_num <= max_lane_num; lane_num 
<<= 1) {
max_pix_clock = (lane_num * link_rates[i] * 8) 
/ bpp;
if (max_pix_clock >= pix_clock) {
*dp_lanes = lane_num;
-- 
2.5.5



[PATCH 1/2] drm/radeon: fix DP mode validation

2016-05-12 Thread Alex Deucher
Switch the order of the loops to walk the rates on the top
so we exhaust all DP 1.1 rate/lane combinations before trying
DP 1.2 rate/lane combos.

This avoids selecting rates that are supported by the monitor,
but not the connector leading to valid modes getting rejected.

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

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/atombios_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index afa9db1..cead089a 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -326,8 +326,8 @@ int radeon_dp_get_dp_link_config(struct drm_connector 
*connector,
}
}
} else {
-   for (lane_num = 1; lane_num <= max_lane_num; lane_num <<= 1) {
-   for (i = 0; i < ARRAY_SIZE(link_rates) && link_rates[i] 
<= max_link_rate; i++) {
+   for (i = 0; i < ARRAY_SIZE(link_rates) && link_rates[i] <= 
max_link_rate; i++) {
+   for (lane_num = 1; lane_num <= max_lane_num; lane_num 
<<= 1) {
max_pix_clock = (lane_num * link_rates[i] * 8) 
/ bpp;
if (max_pix_clock >= pix_clock) {
*dp_lanes = lane_num;
-- 
2.5.5



[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-12 Thread Maxime Ripard
On Thu, May 12, 2016 at 06:39:20AM +0300, Priit Laes wrote:
> On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote:
> > On 05/10, Priit Laes wrote:
> > > 
> > > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> > > > 
> > > > On 05/09, Stephen Boyd wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > Ok I applied this one to clk-next.
> > > > > 
> > > > And I squashed this in to silence the following checker warning.
> > > > 
> > > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > > > length array is used.
> > > > 
> > > > ---8<---
> > > > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> > > > b/drivers/clk/sunxi/clk-sun4i-display.c
> > > > index f02e250e64ed..f8ff6c4a5633 100644
> > > > --- a/drivers/clk/sunxi/clk-sun4i-display.c
> > > > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > > > @@ -107,7 +107,7 @@ static int
> > > > sun4i_a10_display_reset_xlate(struct
> > > > reset_controller_dev *rcdev,
> > > >  static void __init sun4i_a10_display_init(struct device_node
> > > > *node,
> > > >      const struct
> > > > sun4i_a10_display_clk_data *data)
> > > >  {
> > > > -   const char *parents[data->parents];
> > > > +   const char *parents[4];
> > > This change breaks at least de_[bf]e clocks which have 3 clock
> > > parents.
> 
> > I just used the largest data->parents number, which was 4. How
> > does that break anything?
> 
> If you look at the sun4i_a10_display_init, it contains this block:
> 
>     ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
>     if (ret != ARRAY_SIZE(parents)) {
>         pr_err("%s: Could not retrieve the parents\n", clk_name);
>         goto unmap;
>     }
> 
> of_clk_parent_fill returns 3 for de_be/de_fe nodes, and
> ARRAY_SIZE(parents) is 4.

Replacing both ARRAY_SIZE(parents) by data->parents would work though.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160512/443d58bd/attachment.sig>


[linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

2016-05-12 Thread Priit Laes
On Wed, 2016-05-11 at 15:15 -0700, Stephen Boyd wrote:
> On 05/10, Priit Laes wrote:
> > 
> > On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote:
> > > 
> > > On 05/09, Stephen Boyd wrote:
> > > > 
> > > > 
> > > > 
> > > > Ok I applied this one to clk-next.
> > > > 
> > > And I squashed this in to silence the following checker warning.
> > > 
> > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable
> > > length array is used.
> > > 
> > > ---8<---
> > > diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
> > > b/drivers/clk/sunxi/clk-sun4i-display.c
> > > index f02e250e64ed..f8ff6c4a5633 100644
> > > --- a/drivers/clk/sunxi/clk-sun4i-display.c
> > > +++ b/drivers/clk/sunxi/clk-sun4i-display.c
> > > @@ -107,7 +107,7 @@ static int
> > > sun4i_a10_display_reset_xlate(struct
> > > reset_controller_dev *rcdev,
> > >  static void __init sun4i_a10_display_init(struct device_node
> > > *node,
> > >    const struct
> > > sun4i_a10_display_clk_data *data)
> > >  {
> > > - const char *parents[data->parents];
> > > + const char *parents[4];
> > This change breaks at least de_[bf]e clocks which have 3 clock
> > parents.

> I just used the largest data->parents number, which was 4. How
> does that break anything?

If you look at the sun4i_a10_display_init, it contains this block:

    ret = of_clk_parent_fill(node, parents, ARRAY_SIZE(parents));
    if (ret != ARRAY_SIZE(parents)) {
        pr_err("%s: Could not retrieve the parents\n", clk_name);
        goto unmap;
    }

of_clk_parent_fill returns 3 for de_be/de_fe nodes, and
ARRAY_SIZE(parents) is 4.

Päikest,
Priit :)


[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95247

--- Comment #4 from Sandeep  ---
Created attachment 123638
  --> https://bugs.freedesktop.org/attachment.cgi?id=123638=edit
Full dmesg log 4.6-rc6

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


[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93341

Jean-François Fortin Tam  changed:

   What|Removed |Added

URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1335360

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


[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=93341

--- Comment #6 from Jean-François Fortin Tam  ---
For what it's like, compared to my previous comment #5, tonight (same machine,
same distro/stack) I was able to trigger the bug pretty frequently by using the
Epiphany browser with a particular website—twice within the span of fifteen
minutes or so.

So while there is a simple time component (ex: crashes while the computer isn't
doing anything in particular), it can also sometimes be triggered by stressing
the graphic card a little with some operations (such as can be seen on some
browsers).

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


[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=92258

--- Comment #44 from russianneuromancer at ya.ru ---
Maz, I launch Steam like this "LIBGL_DRI3_DISABLE=1 DRI_PRIME=1 steam" as
workaround for now.

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


[PATCH] drm/nouveau/bios: remove unused variable.

2016-05-12 Thread Muhammad Falak R Wani
Remove unused vairable, return 0 explicitly.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/nouveau/nouveau_bios.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 4dca65a..5449838 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -2039,7 +2039,6 @@ nouveau_run_vbios_init(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvbios *bios = >vbios;
-   int ret = 0;

/* Reset the BIOS head to 0. */
bios->state.crtchead = 0;
@@ -2052,7 +2051,7 @@ nouveau_run_vbios_init(struct drm_device *dev)
bios->fp.lvds_init_run = false;
}

-   return ret;
+   return 0;
 }

 static bool
-- 
1.9.1



[Bug 95358] Tonga no hdmi audio on DAL 4.7 works on DAL 4.6

2016-05-12 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95358

Bug ID: 95358
   Summary: Tonga no hdmi audio on DAL 4.7 works on DAL 4.6
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

I have lost HDMI audio with adg5f drm-next-4.7-wip-dal

It worked with 4.6 dal branch.

I can't bisect 4.7 as I can't find a working - if I go too far back I die on
boot and need hard reset or get no display.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 



[PATCH v2 1/2] PM / Domains: Allow genpd to power on during the system PM phase

2016-05-12 Thread Rafael J. Wysocki
On Wed, May 11, 2016 at 10:00 AM, Ulf Hansson  wrote:
> If the PM domain is powered off when the first device in the domain starts
> its system PM prepare phase, genpd prevents any further attempts to power
> on the PM domain during the system PM phase. This constraint affects not
> only the current device which is being prepared, but all devices within
> the same PM domain.

What exactly do you mean by "the system PM phase"?


[PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array

2016-05-12 Thread Muhammad Falak R Wani
Use ARRAY_SIZE() for the size calculation of the array. Also move the
condition evaulation function out of the for loop.
Although, any respectable c-compiler would optimize this and evaluate
the function only once outside the loop, but the optimzation engine
of gcc is bit brain-dead, and at times needs some hand holding.

Signed-off-by: Muhammad Falak R Wani 
---
 drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index da18f44..718a551 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -636,10 +636,11 @@ static int cz_smu_populate_firmware_entries(struct 
pp_smumgr *smumgr)
int ret;
enum cgs_ucode_id ucode_id;
struct cgs_firmware_info info = {0};
+   int n = ARRAY_SIZE(firmware_list);

cz_smu->driver_buffer_length = 0;

-   for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
+   for (i = 0; i < n; i++) {

firmware_type = cz_translate_firmware_enum_to_arg(smumgr,
firmware_list[i]);
-- 
1.9.1



[PATCH] drm: Deal with rotation in drm_plane_helper_check_update()

2016-05-12 Thread Ville Syrjälä
On Fri, Jan 15, 2016 at 08:51:06PM +0200, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> drm_plane_helper_check_update() needs to account for the plane rotation
> for correct clipping/scaling calculations. Do so.
> 
> There was an earlier attempt [1] to add this into
> intel_check_primary_plane() but I requested that it'd be put into the
> helper instead. An updated patch never materialized AFAICS, so I went
> ahead and cooked one up myself.

Ping. Anyone interested in rotation actually working with
drm_plane_helper_check_update() ?

> 
> [1] https://patchwork.freedesktop.org/patch/65177/
> Cc: Nabendu Maiti 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/armada/armada_overlay.c |  1 +
>  drivers/gpu/drm/drm_plane_helper.c  | 28 ++--
>  drivers/gpu/drm/i915/intel_display.c|  2 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
>  include/drm/drm_plane_helper.h  |  1 +
>  5 files changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
> b/drivers/gpu/drm/armada/armada_overlay.c
> index 148e8a42b2c6..1ee707ef6b8d 100644
> --- a/drivers/gpu/drm/armada/armada_overlay.c
> +++ b/drivers/gpu/drm/armada/armada_overlay.c
> @@ -121,6 +121,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
> drm_crtc *crtc,
>   int ret;
>  
>   ret = drm_plane_helper_check_update(plane, crtc, fb, , , ,
> + BIT(DRM_ROTATE_0),
>   0, INT_MAX, true, false, );
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 369d2898ff9e..0c12fa1a696f 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -115,6 +115,7 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
>   * @src: source coordinates in 16.16 fixed point
>   * @dest: integer destination coordinates
>   * @clip: integer clipping coordinates
> + * @rotation: plane rotation
>   * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
>   * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
>   * @can_position: is it legal to position the plane such that it
> @@ -134,16 +135,17 @@ static int get_connectors_for_crtc(struct drm_crtc 
> *crtc,
>   * Zero if update appears valid, error code on failure
>   */
>  int drm_plane_helper_check_update(struct drm_plane *plane,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_rect *src,
> - struct drm_rect *dest,
> - const struct drm_rect *clip,
> - int min_scale,
> - int max_scale,
> - bool can_position,
> - bool can_update_disabled,
> - bool *visible)
> +   struct drm_crtc *crtc,
> +   struct drm_framebuffer *fb,
> +   struct drm_rect *src,
> +   struct drm_rect *dest,
> +   const struct drm_rect *clip,
> +   unsigned int rotation,
> +   int min_scale,
> +   int max_scale,
> +   bool can_position,
> +   bool can_update_disabled,
> +   bool *visible)
>  {
>   int hscale, vscale;
>  
> @@ -163,6 +165,8 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
>   return -EINVAL;
>   }
>  
> + drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
> +
>   /* Check scaling */
>   hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
>   vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> @@ -174,6 +178,9 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
>   }
>  
>   *visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
> +
> + drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
> +
>   if (!*visible)
>   /*
>* Plane isn't visible; some drivers can handle this
> @@ -265,6 +272,7 @@ int drm_primary_helper_update(struct drm_plane *plane, 
> struct drm_crtc *crtc,
>  
>   ret = drm_plane_helper_check_update(plane, crtc, fb,
>   , , ,
> + BIT(DRM_ROTATE_0),
>   DRM_PLANE_HELPER_NO_SCALING,
>   DRM_PLANE_HELPER_NO_SCALING,
>   false, false, );
> diff