[PATCH v6 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[hl]

Hi Chanwoo Choi,

On 2016年08月17日 12:50, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016년 08월 17일 07:36, Lin Huang wrote:
>> This patch adds the documentation for rockchip rk3399 dmc driver.
>>
>> Signed-off-by: Lin Huang 
>> ---
>> Changes in v6:
>> -Add more detail in Documentation
>>
>> Changes in v5:
>> -None
>>
>> Changes in v4:
>> -None
>>
>> Changes in v3:
>> -None
>>
>> Changes in v2:
>> -None
>>
>> Changes in v1:
>> -None
>>   .../devicetree/bindings/devfreq/rk3399_dmc.txt | 84 
>> ++
>>   1 file changed, 84 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
>> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>> new file mode 100644
>> index 000..e73067c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
>> @@ -0,0 +1,84 @@
>> +* Rockchip rk3399 DMC(Dynamic Memory Controller) device
>> +
>> +Required properties:
>> +- compatible: Must be "rockchip,rk3399-dmc".
>> +- devfreq-events: Node to get ddr loading, Refer to
>> +  Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
>> +- interrupts: The interrupt number to the cpu. The interrupt specifier 
>> format
>> +  depends on the interrupt controller. it should be dcf interrupts,
>> +  when ddr dvfs finish, it will happen.
> If possible, you better to keep the indentation with other properties.
> s/it->It, dcf->DCF, ddr->DDR
>
>
>> +- clocks: Phandles for clock specified in "clock-names" property
>> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
>> +- operating-points-v2: Refer to 
>> Documentation/devicetree/bindings/power/opp.txt
>> +   for details.
> ditto.
>
>> +- center-supply: Dmc supply node.
> s/Dmc/DMC becaue DMC an abbreviation.
>
>> +- status: Marks the node enabled/disabled.
>> +
>> +Optional properties:
>> +- ddr_timing: ddr timing need to pass to arm trust firmware
>> +- upthreshold: the upthreshold to simpleondeamnd policy
>> +- downdifferential: The downdifferential to simpleondeamnd policy
>> +
>> +Example:
>> +ddr_timing: ddr_timing {
>> +compatible = "rockchip,ddr-timing";
> I can't find the 'rockchip,ddr-timing' driver on linux-next git repo 
> (20160816).
> If ddr_timing includes the only properties for ddr_timing,
> I recommend you make the separate a .dtsi file including
> the ddr timing configuration. I add the reference and an example on below.
>
>> +ddr3_speed_bin = <21>;
>> +pd_idle = <0>;
>> +sr_idle = <0>;
>> +sr_mc_gate_idle = <0>;
>> +srpd_lite_idle  = <0>;
>> +standby_idle = <0>;
>> +dram_dll_dis_freq = <300>;
>> +phy_dll_dis_freq = <125>;
>> +
>> +ddr3_odt_dis_freq = <333>;
>> +ddr3_drv = ;
>> +ddr3_odt = ;
>> +phy_ddr3_ca_drv = ;
>> +phy_ddr3_dq_drv = ;
>> +phy_ddr3_odt = ;
>> +
>> +lpddr3_odt_dis_freq = <333>;
>> +lpddr3_drv = ;
>> +lpddr3_odt = ;
>> +phy_lpddr3_ca_drv = ;
>> +phy_lpddr3_dq_drv = ;
>> +phy_lpddr3_odt = ;
>> +
>> +lpddr4_odt_dis_freq = <333>;
>> +lpddr4_drv = ;
>> +lpddr4_dq_odt = ;
>> +lpddr4_ca_odt = ;
>> +phy_lpddr4_ca_drv = ;
>> +phy_lpddr4_ck_cs_drv = ;
>> +phy_lpddr4_dq_drv = ;
>> +phy_lpddr4_odt = ;
>> +};
>> +
>> +dmc_opp_table: dmc_opp_table {
>> +compatible = "operating-points-v2";
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <3>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <66600>;
>> +opp-microvolt = <90>;
>> +};
>> +};
>> +
>> +dmc: dmc {
>> +compatible = "rockchip,rk3399-dmc";
>> +devfreq-events = <&dfi>;
>> +interrupts = ;
>> +clocks = <&cru SCLK_DDRCLK>;
>> +clock-names = "dmc_clk";
>> +ddr_timing = <&ddr_timing>;
> You can use the following '#include' instead of 'ddr_timing'
> because the ddr_timing is not a device driver. Instead,
> the rk3399-dmc must need the ddr timing configuration.
>
>   #include "rk3399-dmc-timing-conf.dtsi"
>
> You can refer the similar usage case[1].
> The *.conf.dtsi is used on exynos3250 tmu dt node[2].
>
> [1] arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi
> [2] arch/arm/boot/dts/exynos3250.dtsi, 224 line.
>
>> +operating-points-v2 = <&dmc_opp_table>;
>> +center-supply = <&ppvar_centerlogic>;
>> +upthreshold = <15>;
>> +downdifferential = <10>;
>> +status = "disabled";
>> +};
>> +
>>
> For example,
>

[Bug 97428] Specific OpenGL applications deadlock on AMD GPU drivers

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

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

--- Comment #2 from Michel Dänzer  ---
This could be a duplicate of bug 97174, try the LD_PRELOAD / LIBGL_DRI3_DISABLE
workarounds described there.

-- 
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/20160822/1929afa5/attachment.html>

[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1

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

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

--- Comment #12 from Michael J Evans  ---
I seem to be experiencing this issue as well.

ArchLinux

Linux 4.7
Mesa 12.0.1
xorg-server 1.18.4

GPU is an AMD R9 285 with 2GB of video RAM.

I seem to encounter this issue once every day or two.  The desktop is a frozen
framebuffer.

SSH is still responsive, though I can't reboot or shutdown cleanly (I have to
hard power off; maybe I could kill Xorg or something, I haven't tried that
yet).

I noticed that the crash logs are similar to what I am observing, but that
doesn't appear to collect data for this issue.

1) When it does crash is there anything that can be done at that point to
collect data that would be useful?

2) Shouldn't the amdgpu driver respond appropriately to inappropriate use and
cause a clean crash of the offending application?  Preferably just whichever
program has the bug and not the entire xorg session?

-- 
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/20160822/660f10dd/attachment-0001.html>

[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Daniel Vetter]

On Sat, Aug 20, 2016 at 2:20 PM, Emil Velikov  
wrote:
>> While I understand some people want to discuss this further, these
>> patches must land first in order bring back the compatibility with
>> libdrm.
> This is where the misunderstanding lies - there _must_ _not_ be
> compatible with the libdrm ones, but the other way around. Check the
> output of $ git log -p -- include/drm in libdrm. Pretty please ?

Yes, uapi needs to flow from the kernel. libdrm cannot be treated as
the master copy for shared headers. I think the problem here was
simply that a patch landed without the Ack from maintainers, or they
didn't check things carefully enough.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "

[Daniel Vetter]

On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov  
wrote:
> On 20 August 2016 at 16:08, Marek Olšák  wrote:
>> On Sat, Aug 20, 2016 at 2:20 PM, Emil Velikov  
>> wrote:
>>> On 20 August 2016 at 12:47, Marek Olšák  wrote:
 On Sat, Aug 20, 2016 at 1:08 PM, Emil Velikov >>> gmail.com> wrote:
> On 20 August 2016 at 11:05, Marek Olšák  wrote:
>> On Sat, Aug 20, 2016 at 12:54 AM, Emil Velikov > gmail.com> wrote:
>>> On 19 August 2016 at 15:26, Christian König >> vodafone.de> wrote:
 Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>
> From: Marek Olšák 
>
> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>
> See the comment in the code. Basically, don't do cleanups in this 
> header.
>
> Signed-off-by: Marek Olšák 


 I completely agree with you that this was a bad move, but I fear that 
 we
 will run into opposition with that.

>>> Please check the facts before introducing RATHER ANNOYING AND HARD TO
>>> READ COMMENT IN ALL CAPS.
>>>
>>> Story time:
>>> I was dreaming of a day were we can stop installing these headers,
>>> thus making deprecation a bit easier process.
>>> Yet after failing to convince Dave and Daniel on a number of occasions
>>> I've accepted that those headers _are_ here to stay. And yes they
>>> _are_ the UAPI, even though no applications are meant to use them but
>>> the libdrm 'version'.
>>> Thus any changes to the libdrm ones should be a mirror of the ones
>>> here and libdrm should _not_ differ.
>>>
>>> But let's ignore all that and imagine that those headers are _not_
>>> UAPI. That gives us even greater reason to _not_ use the uintx_t types
>>> but the kernel __uX ones. The series that did these changes had a fair
>>> few references why we want that.
>>>
>>> Yes, I can imagine that the situation isn't ideal, and/or not that
>>> clear. Then again a check with git log should have straightened things
>>> out.
>>> If not _please_ help us improve this (documentation and/or others).
>>>
>>>
>>> And last but not least, please share with up what inspired this -
>>> (build/runtime) regression, attempted sync with libdrm, other ?
>>
>> Syncing with libdrm became difficult.
> Actually it should be easier now. Perhaps the radeon one was always a
> good citizen, but sadly that was not the case for the rest.
>
>> I'd like the diff between kernel
>> and libdrm to be as small as possible.
>>
> I believe we all agree on this one :-)
>
>> We must take into account that the uapi headers can potentially be
>> implemented by a different OS.
> Agreed. Have you looked at the 'compatibility layer' in drm.h ?
>
>> That's why they are in libdrm and
>> that's why nobody should make random changes to them in the kernel
>> tree. Do not think like a kernel developer isolated in Linux and just
>> consider the broader use case. If you do, you'll realize that it
>> simply doesn't make sense to use the __uX types here.
>>
> Ftr, like Rob (and maybe others) I believe that using __uX (in the
> kernel) is a bit odd, and opting for the stdint.h types should happen.
> But until/if that happens we have to live with the __uX ones.
>
> That said, I have poked various BSD people on a number of occasions,
> (hopefully) inspiring them to upstream their changes in a compatible
> way. Thus the whole "don't think like a kernel developer" doesn't
> really apply here :-\
>
> I'm simply one of the few fools^wpeople trying to make things OK for
> most (since one can never please everyone, all the time).
>
> IIRC the FreeBSD/DragonFly people had some issues with their
> compatibility layer since the kernel and userspace drm.h were
> divergent "by design" [1]. To make it even 'better' there's even two
> difference versions of drm.h in their kernel itself [2].
>
> What I am for is a discussion how to resolve things. Although expect
> resistance if you're thinking about applying tape, in order to fix
> somethings that's 'broken' elsewhere.
>
> If you or any !Linux folks are around on XDC we should really sit down
> and untangle some/all of these issues.

 It's not 100% certain but it looks like we won't be there.

 We need the uapi headers to be the same as libdrm ones to make syncing
 easier. There is not much else to discuss here really. We (AMD) are
 also the ones who have to work with these headers the most, not you, not 
 Mikko.

>>> Agreed and agreed.
>>>
 While I understand some people want to discuss this further, these
 patches must land first in order bring back the compatibility with
 libdrm.
>>> This is where the misunderstanding lies - there _must

linux-next: manual merge of the jc_docs tree with the drm-misc tree

[Daniel Vetter]

On Fri, Aug 19, 2016 at 11:50:09AM -0600, Jonathan Corbet wrote:
> On Fri, 19 Aug 2016 11:52:15 +1000
> Stephen Rothwell  wrote:
> 
> > Today's linux-next merge of the jc_docs tree got a conflict in:
> > 
> >   Documentation/gpu/index.rst
> > 
> > between commit:
> > 
> >   b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc")
> > 
> > from the drm-misc tree and commit:
> > 
> >   505f711174b0 ("doc-rst: add index to sub-folders")
> > 
> > from the jc_docs tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> Thanks, the fix is good.
> 
> Daniel: my apologies, I should have asked for that patch to be split up
> and the relevant pieces sent through the gpu and media trees.

No worries, as far as conflicts go this one is trivial ;-) And I think a
few conflicts while we shake out best practices for the new doc
infrastructure in various trees is perfectly fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3 1/3] drm/atomic-helper: Add atomic_disable CRTC helper callback

[Daniel Vetter]

On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote:
> Some display controllers need plane(s) to be disabled together with
> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
> This patch adds atomic_disable CRTC helper callback so that
> old_crtc_state(as a parameter of the callback) could be used
> to get all appropriate active plane(s) of the old CRTC state for
> disable operation.
> 
> Suggested-by: Daniel Vetter 
> Cc: Philipp Zabel 
> Cc: David Airlie 
> Cc: Russell King 
> Cc: Daniel Vetter 
> Cc: Peter Senna Tschudin 
> Cc: Lucas Stach 
> Signed-off-by: Liu Ying 
> ---
> v3:
> * Newly introduced in v3.
> 
>  drivers/gpu/drm/drm_atomic_helper.c  |  2 ++
>  include/drm/drm_modeset_helper_vtables.h | 14 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9abe0a2..254bdde 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -749,6 +749,8 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   /* Right function depends upon target state. */
>   if (crtc->state->enable && funcs->prepare)
>   funcs->prepare(crtc);
> + else if (funcs->atomic_disable)
> +  funcs->atomic_disable(crtc, old_crtc_state);
>   else if (funcs->disable)
>   funcs->disable(crtc);
>   else
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 686feec..16fd918 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -391,6 +391,20 @@ struct drm_crtc_helper_funcs {
>*/
>   void (*atomic_flush)(struct drm_crtc *crtc,
>struct drm_crtc_state *old_crtc_state);
> +
> + /**
> +  * @atomic_disable:
> +  *
> +  * This callback should be used to disable the CRTC. It is called
> +  * after all encoders connected to this CRTC have been shut off
> +  * already using their own ->disable hook.
> +  *
> +  * This hook is used only by atomic helpers. Atomic drivers don't
> +  * need to implement it if there's no need to disable anything at the
> +  * CRTC level.

kernel-doc is a bit lacking compared to the one for @disable. And I think
on top of that it should explain better the difference with @disable (and
@disable should reference @atomic_disable too).
-Daniel

> +  */
> + void (*atomic_disable)(struct drm_crtc *crtc,
> +struct drm_crtc_state *old_crtc_state);
>  };
>  
>  /**
> -- 
> 2.7.4
> 

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

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

[Daniel Vetter]

On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote:
> We don't support configuring active plane on-the-fly for imx-drm.
> The relevant CRTC should be disabled before the plane configuration.
> Of course, the plane itself should be disabled as well.
> 
> This patch adds active plane reconfiguration support by forcing CRTC
> mode change in plane's ->atomic_check callback and adding disable
> operation for all appropriate active planes(when necessary) in CRTC's
> ->atomic_disable callback.  The atomic core would reenabled the
> affected CRTC and planes at atomic commit stage.
> 
> Suggested-by: Daniel Vetter 
> Cc: Philipp Zabel 
> Cc: David Airlie 
> Cc: Russell King 
> Cc: Daniel Vetter 
> Cc: Peter Senna Tschudin 
> Cc: Lucas Stach 
> Signed-off-by: Liu Ying 
> ---
> v2->v3:
> * Disable all appropriate affected planes(when necessary) in CRTC's
>   ->atomic_disable callback, but not in each plane's ->atomic_update callback,
>   as suggested by Daniel Vetter.
> * +Cc Lucas Stach, as he tested the patch v2.
> 
> v1->v2:
> * Do not reject reconfiguring an active overlay plane.
> 
>  drivers/gpu/drm/imx/imx-drm-core.c | 26 +-
>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 26 ++
>  drivers/gpu/drm/imx/ipuv3-plane.c  | 21 ++---
>  3 files changed, 65 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index 438bac8..d61b048 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -146,10 +146,34 @@ static void imx_drm_output_poll_changed(struct 
> drm_device *drm)
>   drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
>  }
>  
> +static int imx_drm_atomic_check(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_helper_check_planes(dev, state);
> + if (ret)
> + return ret;
> +
> + /*
> +  * Check modeset again in case crtc_state->mode_changed is
> +  * updated in plane's ->atomic_check callback.
> +  */
> + ret = drm_atomic_helper_check_modeset(dev, state);
> + if (ret)
> + return ret;
> +
> + return ret;
> +}
> +
>  static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
>   .fb_create = drm_fb_cma_create,
>   .output_poll_changed = imx_drm_output_poll_changed,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = imx_drm_atomic_check,
>   .atomic_commit = drm_atomic_helper_commit,
>  };
>  
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index 83c46bd..0779eed 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -76,6 +76,32 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>   crtc->state->event = NULL;
>   }
>   spin_unlock_irq(&crtc->dev->event_lock);
> +
> + /*
> +  * The relevant plane's ->atomic_check callback may set
> +  * crtc_state->mode_changed to be true when the active
> +  * plane needs to be reconfigured.  In this case and only
> +  * this case, active_changed is false - we disable all the
> +  * appropriate active planes here.
> +  */
> + if (!crtc->state->active_changed) {
> + struct drm_plane *plane;
> +
> + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
> + const struct drm_plane_helper_funcs *plane_funcs =
> + plane->helper_private;
> +
> + /*
> +  * Filter out the plane which is explicitly required
> +  * to be disabled by the user via atomic commit
> +  * so that it won't be accidentally disabled twice.
> +  */
> + if (!plane->state->crtc)
> + continue;

I think the better place would be to do the filtering in commit_planes(),
not here. And would be great to include your patch to fix up
disable_planes_on_crtc(), too.
-Daniel

> +
> + plane_funcs->atomic_disable(plane, NULL);
> + }
> + }
>  }
>  
>  static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index 4ad67d0..6063ebe 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -319,13 +319,16 @@ static int ipu_plane_atomic_check(struct drm_plane 
> *plane,
>   return -EINVAL;
>  
>   /*
> -  * since we cannot touch active IDMAC channels, we do not support
> -  * resizing the enabled plane or changing its format
> +  * We support resizing active plane or changing its format by
> +  * forcing CRTC mode chan

[PATCH] reservation: fix small comment typo

[Daniel Vetter]

On Fri, Aug 19, 2016 at 04:55:34PM -0400, Rob Clark wrote:
> Signed-off-by: Rob Clark 
> ---
>  drivers/dma-buf/reservation.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index b528edb..1461b51 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -205,7 +205,7 @@ done:
>   * @fence: the shared fence to add
>   *
>   * Add a fence to a shared slot, obj->lock must be held, and
> - * reservation_object_reserve_shared_fence has been called.
> + * reservation_object_reserve_shared has been called.

If you add a () at the end it even becomes a hyperlink in the generated
output. I applied that bikeshed and merged to -misc, thanks.
-Daniel

>   */
>  void reservation_object_add_shared_fence(struct reservation_object *obj,
>struct fence *fence)
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 1/1] drm: avoid exposing kernel stack in compat_drm_getstats

[Daniel Vetter]

On Sun, Aug 21, 2016 at 07:56:19PM +0200, Heinrich Schuchardt wrote:
> The C standard does not specify the size of the integer used
> to store an enum. Hence in structure drm_stats32_t alignment
> bytes may exist.
> 
> To avoid exposing bytes from the kernel stack it is
> necessary to initialize variable s32 completely.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_ioc32.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 57676f8..32a489b 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -346,6 +346,7 @@ static int compat_drm_getstats(struct file *file, 
> unsigned int cmd,
>   struct drm_stats __user *stats;
>   int i, err;
>  
> + memset(&s32, 0, sizeof(drm_stats32_t));
>   stats = compat_alloc_user_space(sizeof(*stats));
>   if (!stats)
>   return -EFAULT;
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drm/gma500: dont expose bytes from kernel stack

[Daniel Vetter]

On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
> 
> Signed-off-by: Heinrich Schuchardt 

Might be a silly question, but where exactly would we expose these bytes?
This isn't directly called by an ioctl, I have no idea how those bytes
might get to userspace ...
-Daniel
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index da9fd34..28bd8f3 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -138,6 +138,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
>   u32 target_vco, actual_freq;
>   s32 freq_error, min_error = 10;
>  
> + memset(clock, 0, sizeof(struct gma_clock_t));
>   memset(best_clock, 0, sizeof(*best_clock));
>  
>   for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH v3 1/3] drm/atomic-helper: Add atomic_disable CRTC helper callback

[Ying Liu]

On Mon, Aug 22, 2016 at 3:01 PM, Daniel Vetter  wrote:
> On Fri, Aug 19, 2016 at 05:36:57PM +0800, Liu Ying wrote:
>> Some display controllers need plane(s) to be disabled together with
>> the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
>> This patch adds atomic_disable CRTC helper callback so that
>> old_crtc_state(as a parameter of the callback) could be used
>> to get all appropriate active plane(s) of the old CRTC state for
>> disable operation.
>>
>> Suggested-by: Daniel Vetter 
>> Cc: Philipp Zabel 
>> Cc: David Airlie 
>> Cc: Russell King 
>> Cc: Daniel Vetter 
>> Cc: Peter Senna Tschudin 
>> Cc: Lucas Stach 
>> Signed-off-by: Liu Ying 
>> ---
>> v3:
>> * Newly introduced in v3.
>>
>>  drivers/gpu/drm/drm_atomic_helper.c  |  2 ++
>>  include/drm/drm_modeset_helper_vtables.h | 14 ++
>>  2 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 9abe0a2..254bdde 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -749,6 +749,8 @@ disable_outputs(struct drm_device *dev, struct 
>> drm_atomic_state *old_state)
>>   /* Right function depends upon target state. */
>>   if (crtc->state->enable && funcs->prepare)
>>   funcs->prepare(crtc);
>> + else if (funcs->atomic_disable)
>> +  funcs->atomic_disable(crtc, old_crtc_state);
>>   else if (funcs->disable)
>>   funcs->disable(crtc);
>>   else
>> diff --git a/include/drm/drm_modeset_helper_vtables.h 
>> b/include/drm/drm_modeset_helper_vtables.h
>> index 686feec..16fd918 100644
>> --- a/include/drm/drm_modeset_helper_vtables.h
>> +++ b/include/drm/drm_modeset_helper_vtables.h
>> @@ -391,6 +391,20 @@ struct drm_crtc_helper_funcs {
>>*/
>>   void (*atomic_flush)(struct drm_crtc *crtc,
>>struct drm_crtc_state *old_crtc_state);
>> +
>> + /**
>> +  * @atomic_disable:
>> +  *
>> +  * This callback should be used to disable the CRTC. It is called
>> +  * after all encoders connected to this CRTC have been shut off
>> +  * already using their own ->disable hook.
>> +  *
>> +  * This hook is used only by atomic helpers. Atomic drivers don't
>> +  * need to implement it if there's no need to disable anything at the
>> +  * CRTC level.
>
> kernel-doc is a bit lacking compared to the one for @disable. And I think
> on top of that it should explain better the difference with @disable (and
> @disable should reference @atomic_disable too).

Will improve the kernel-doc in the next version.  Thanks.

Regards,
Liu Ying

> -Daniel
>
>> +  */
>> + void (*atomic_disable)(struct drm_crtc *crtc,
>> +struct drm_crtc_state *old_crtc_state);
>>  };
>>
>>  /**
>> --
>> 2.7.4
>>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

[Ying Liu]

Hi Daniel,

On Mon, Aug 22, 2016 at 3:20 PM, Daniel Vetter  wrote:
> On Fri, Aug 19, 2016 at 05:36:59PM +0800, Liu Ying wrote:
>> We don't support configuring active plane on-the-fly for imx-drm.
>> The relevant CRTC should be disabled before the plane configuration.
>> Of course, the plane itself should be disabled as well.
>>
>> This patch adds active plane reconfiguration support by forcing CRTC
>> mode change in plane's ->atomic_check callback and adding disable
>> operation for all appropriate active planes(when necessary) in CRTC's
>> ->atomic_disable callback.  The atomic core would reenabled the
>> affected CRTC and planes at atomic commit stage.
>>
>> Suggested-by: Daniel Vetter 
>> Cc: Philipp Zabel 
>> Cc: David Airlie 
>> Cc: Russell King 
>> Cc: Daniel Vetter 
>> Cc: Peter Senna Tschudin 
>> Cc: Lucas Stach 
>> Signed-off-by: Liu Ying 
>> ---
>> v2->v3:
>> * Disable all appropriate affected planes(when necessary) in CRTC's
>>   ->atomic_disable callback, but not in each plane's ->atomic_update 
>> callback,
>>   as suggested by Daniel Vetter.
>> * +Cc Lucas Stach, as he tested the patch v2.
>>
>> v1->v2:
>> * Do not reject reconfiguring an active overlay plane.
>>
>>  drivers/gpu/drm/imx/imx-drm-core.c | 26 +-
>>  drivers/gpu/drm/imx/ipuv3-crtc.c   | 26 ++
>>  drivers/gpu/drm/imx/ipuv3-plane.c  | 21 ++---
>>  3 files changed, 65 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
>> b/drivers/gpu/drm/imx/imx-drm-core.c
>> index 438bac8..d61b048 100644
>> --- a/drivers/gpu/drm/imx/imx-drm-core.c
>> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
>> @@ -146,10 +146,34 @@ static void imx_drm_output_poll_changed(struct 
>> drm_device *drm)
>>   drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
>>  }
>>
>> +static int imx_drm_atomic_check(struct drm_device *dev,
>> + struct drm_atomic_state *state)
>> +{
>> + int ret;
>> +
>> + ret = drm_atomic_helper_check_modeset(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + ret = drm_atomic_helper_check_planes(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + /*
>> +  * Check modeset again in case crtc_state->mode_changed is
>> +  * updated in plane's ->atomic_check callback.
>> +  */
>> + ret = drm_atomic_helper_check_modeset(dev, state);
>> + if (ret)
>> + return ret;
>> +
>> + return ret;
>> +}
>> +
>>  static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
>>   .fb_create = drm_fb_cma_create,
>>   .output_poll_changed = imx_drm_output_poll_changed,
>> - .atomic_check = drm_atomic_helper_check,
>> + .atomic_check = imx_drm_atomic_check,
>>   .atomic_commit = drm_atomic_helper_commit,
>>  };
>>
>> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
>> b/drivers/gpu/drm/imx/ipuv3-crtc.c
>> index 83c46bd..0779eed 100644
>> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
>> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
>> @@ -76,6 +76,32 @@ static void ipu_crtc_atomic_disable(struct drm_crtc *crtc,
>>   crtc->state->event = NULL;
>>   }
>>   spin_unlock_irq(&crtc->dev->event_lock);
>> +
>> + /*
>> +  * The relevant plane's ->atomic_check callback may set
>> +  * crtc_state->mode_changed to be true when the active
>> +  * plane needs to be reconfigured.  In this case and only
>> +  * this case, active_changed is false - we disable all the
>> +  * appropriate active planes here.
>> +  */
>> + if (!crtc->state->active_changed) {
>> + struct drm_plane *plane;
>> +
>> + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
>> + const struct drm_plane_helper_funcs *plane_funcs =
>> + plane->helper_private;
>> +
>> + /*
>> +  * Filter out the plane which is explicitly required
>> +  * to be disabled by the user via atomic commit
>> +  * so that it won't be accidentally disabled twice.
>> +  */
>> + if (!plane->state->crtc)
>> + continue;
>
> I think the better place would be to do the filtering in commit_planes(),
> not here. And would be great to include your patch to fix up
> disable_planes_on_crtc(), too.

Do you mean we can do the filtering by checking (!plane->state->crtc)
right before plane_funcs->atomic_disable in commit_planes()?
Won't it filter out all the apples?
commit_planes() doesn't know whether the driver calls
disable_planes_on_crtc() or not.

imo, doing the filtering in crtc_funcs->atomic_disable is sane.

Regards,
Liu Ying


> -Daniel
>
>> +
>> + plane_funcs->atomic_disable(plane, NULL);
>> + }
>> + }
>>  }
>>
>>  static void imx_drm_crtc_reset(struct drm_crtc *crtc)
>> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

[Daniel Vetter]

On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu  wrote:
>>> +
>>> + /*
>>> +  * The relevant plane's ->atomic_check callback may set
>>> +  * crtc_state->mode_changed to be true when the active
>>> +  * plane needs to be reconfigured.  In this case and only
>>> +  * this case, active_changed is false - we disable all the
>>> +  * appropriate active planes here.
>>> +  */
>>> + if (!crtc->state->active_changed) {
>>> + struct drm_plane *plane;
>>> +
>>> + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
>>> + const struct drm_plane_helper_funcs *plane_funcs =
>>> + plane->helper_private;
>>> +
>>> + /*
>>> +  * Filter out the plane which is explicitly required
>>> +  * to be disabled by the user via atomic commit
>>> +  * so that it won't be accidentally disabled twice.
>>> +  */
>>> + if (!plane->state->crtc)
>>> + continue;
>>
>> I think the better place would be to do the filtering in commit_planes(),
>> not here. And would be great to include your patch to fix up
>> disable_planes_on_crtc(), too.
>
> Do you mean we can do the filtering by checking (!plane->state->crtc)
> right before plane_funcs->atomic_disable in commit_planes()?
> Won't it filter out all the apples?
> commit_planes() doesn't know whether the driver calls
> disable_planes_on_crtc() or not.

You need to filter on needs_modeset(crtc_state), and it needs to be
optional like active_only, using a flag.

> imo, doing the filtering in crtc_funcs->atomic_disable is sane.

It is not sane in general, since usually you need to call
disable_planes_on_crtc to avoid upsetting your hardware. And for that
use-case filtering in disable will lead to hung hardware. Which really
means that you need to filter in commit_planes.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v3 1/3] drm/atomic-helper: Add atomic_disable CRTC helper callback

[Daniel Vetter]

On Mon, Aug 22, 2016 at 9:37 AM, Ying Liu  wrote:
>> kernel-doc is a bit lacking compared to the one for @disable. And I think
>> on top of that it should explain better the difference with @disable (and
>> @disable should reference @atomic_disable too).
>
> Will improve the kernel-doc in the next version.  Thanks.

For consistency pls start out with a copy of the exact text for
@disable (minus the note which is only relevant for legacy crtc
helpers ofc).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v7 2/8] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

[Lin Huang]

Signed-off-by: Lin Huang 
---
Changes in v7:
-None

Changes in v6:
-None

Changes in v5:
-None
Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 include/dt-bindings/clock/rk3399-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3399-cru.h 
b/include/dt-bindings/clock/rk3399-cru.h
index 50a44cf..ce5f3e9 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -131,6 +131,7 @@
 #define SCLK_DPHY_RX0_CFG  165
 #define SCLK_RMII_SRC  166
 #define SCLK_PCIEPHY_REF100M   167
+#define SCLK_DDRC  168

 #define DCLK_VOP0  180
 #define DCLK_VOP1  181
-- 
2.6.6

[PATCH v7 3/8] clk: rockchip: rk3399: add ddrc clock support

[Lin Huang]

add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.

Signed-off-by: Lin Huang 
---
Changes in v7:
- change SCLK_DDRC name from clk_ddrc to sclk_ddrc

Changes in v6:
- None

Changes in v5:
- fit for the ddr type

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list

Changes in v1:
- remove ddrc source CLK_IGNORE_UNUSED flag
- move clk_ddrc and clk_ddrc_dpll_src to critical

 drivers/clk/rockchip/clk-rk3399.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index e445cd6..134bd18 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -120,6 +120,10 @@ PNAME(mux_armclkb_p)   = { 
"clk_core_b_lpll_src",
"clk_core_b_bpll_src",
"clk_core_b_dpll_src",
"clk_core_b_gpll_src" };
+PNAME(mux_ddrclk_p)= { "clk_ddrc_lpll_src",
+   "clk_ddrc_bpll_src",
+   "clk_ddrc_dpll_src",
+   "clk_ddrc_gpll_src" };
 PNAME(mux_aclk_cci_p)  = { "cpll_aclk_cci_src",
"gpll_aclk_cci_src",
"npll_aclk_cci_src",
@@ -1379,6 +1383,18 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
RK3368_CLKGATE_CON(13), 11, GFLAGS),
+
+   /* ddrc */
+   GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
+0, GFLAGS),
+   GATE(0, "clk_ddrc_bpll_src", "bpll", 0, RK3399_CLKGATE_CON(3),
+1, GFLAGS),
+   GATE(0, "clk_ddrc_dpll_src", "dpll", 0, RK3399_CLKGATE_CON(3),
+2, GFLAGS),
+   GATE(0, "clk_ddrc_gpll_src", "gpll", 0, RK3399_CLKGATE_CON(3),
+3, GFLAGS),
+   COMPOSITE_DDRCLK(SCLK_DDRC, "sclk_ddrc", mux_ddrclk_p, 0,
+  RK3399_CLKSEL_CON(6), 4, 2, 0, 0, ROCKCHIP_DDRCLK_SIP),
 };

 static struct rockchip_clk_branch rk3399_clk_pmu_branches[] __initdata = {
@@ -1493,6 +1509,9 @@ static const char *const rk3399_cru_critical_clocks[] 
__initconst = {
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
"aclk_vio_noc",
+
+   /* ddrc */
+   "sclk_ddrc"
 };

 static const char *const rk3399_pmucru_critical_clocks[] __initconst = {
-- 
2.6.6

[PATCH v7 4/8] Documentation: bindings: add dt documentation for dfi controller

[Lin Huang]

This patch adds the documentation for rockchip dfi devfreq-event driver.

Signed-off-by: Lin Huang 
---
Changes in v7:
-None

Changes in v6:
-None

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None
 .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt

diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..bf42255
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,20 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+   dfi: dfi at 0xff63 {
+   reg = <0x00 0xff63 0x00 0x4000>;
+   compatible = "rockchip,rk3399-dfi";
+   rockchip,pmu = <&pmugrf>;
+   clocks = <&cru PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
+
-- 
2.6.6

[PATCH] drm/doc: Document uapi requirements in DRM

[Daniel Vetter]

Everyone knows them, except all the new folks joining from the ARM
side haven't lived through all the pain of the past years and are
entirely surprised when I raise this. Definitely time to document
this.

Last time this was a big discussion was about 6 years ago, when qcom
tried to land a kernel driver without userspace. Dave Airlie made the
rules really clear:

http://airlied.livejournal.com/73115.html

This write-up here is essentially what I've put into a presentation a
while ago, which was also reviewed by Dave:

http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html

v2: Fix typos Eric&Rob spotted.

Cc: Dave Airlie 
Cc: Oded Gabbay 
Cc: Russell King 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
Cc: Thomas Hellstrom 
Cc: Sinclair Yeh 
Cc: Lucas Stach 
Cc: Benjamin Gaignard 
Cc: Mark Yao 
Cc: Laurent Pinchart 
Cc: Ben Skeggs 
Cc: Rob Clark 
Cc: CK Hu 
Cc: Xinliang Liu 
Cc: Philipp Zabel 
Cc: Stefan Agner 
Cc: Inki Dae 
Cc: Maxime Ripard  
Cc: Boris Brezillon 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Thierry Reding 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Gerd Hoffmann 
Cc: Brian Starkey 
Cc: Liviu Dudau 
Cc: Alexey Brodkin 
Acked-by: Dave Airlie 
Reviewed-by: Rob Clark 
Reviewed-by: Christian König 
Reviewed-by: Eric Anholt 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-uapi.rst | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 94876938aef3..747b51f8c422 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication
 Open-Source Userspace Requirements
 ==

+The DRM subsystem has stricter requirements on what the userspace side for new
+uAPI needs to look like. This section here explains what exactly those
+requirements are, and why they exist.
+
+The short summary is that any addition of DRM uAPI requires corresponding
+open-sourced userspace patches, and those patches must be reviewed and ready 
for
+merging into a suitable and canonical upstream project.
+
+GFX devices (both display and render/GPU side) are really complex bits of
+hardware, with userspace and kernel by necessity having to work together really
+closely.  The interfaces, for rendering and modesetting, must be extremely wide
+and flexible, and therefore it is almost always impossible to precisely define
+them for every possible corner case. This in turn makes it really practically
+infeasible to differentiate between behaviour that's required by userspace, and
+which must not be changed to avoid regressions, and behaviour which is only an
+accidental artifact of the current implementation.
+
+Without access to the full source code of all userspace users that means it
+becomes impossible to change the implementation details, since userspace could
+depend upon the accidental behaviour of the current implementation in minute
+details. And debugging such regressions without access to source code is pretty
+much impossible. As a consequence this means:
+
+- The Linux kernel's "no regression" policy holds in practice only for
+  open-source userspace of the DRM subsystem. DRM developers are perfectly fine
+  if closed-source blob drivers in userspace use the same uAPI as the open
+  drivers, but they must do so in the exact same way as the open drivers.
+  Creative (ab)use of the interfaces will, and in the past routinely has, lead
+  to breakage.
+
+- Any new userspace interface must have an open-source implementation as
+  demonstration vehicle.
+
+The other reason for requiring open-source userspace is uAPI review. Since the
+kernel and userspace parts of a GFX stack must work together so closely, code
+review can only assess whether a new interface achieves its goals by looking at
+both sides. Making sure that the interface indeed covers the use-case fully
+leads to a few additional requirements:
+
+- The open-source userspace must not be a toy/test application, but the real
+  thing. Specifically it needs to handle all the usual error and corner cases.
+  These are often the places where new uAPI falls apart and hence essential to
+  assess the fitness of a proposed interface.
+
+- The userspace side must be fully reviewed and tested to the standards of that
+  userspace project. For e.g. mesa this means piglit testcases and review on 
the
+  mailing list. This is again to ensure that the new interface actually gets 
the
+  job done.
+
+- The userspace patches must be against the canonical upstream, not some vendor
+  fork. This is to make sure that no one cheats on the review and testing
+  requirements by doing a quick fork.
+
+- The kernel patch can only be merged after all the above requirements are met,
+  but it **must** be merged **before** the userspace patches land. uAPI always 
flows
+  from the kernel, doing things the other way round risks divergence of the 
uAPI
+  definitions 

[PATCH v7 0/8] rk3399 support ddr frequency scaling

[Lin Huang]

rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:

 kernelbl31

monitor ddr load
|
|
get_target_rate
|
|   pass rate to bl31
clk_set_rate(ddr) ->run dcf flow
|   |
|   |
wait dcf interrupt<---trigger dcf interrupt
|
|
  return

Lin Huang (8):
  clk: rockchip: add new clock-type for the ddrclk
  clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
  clk: rockchip: rk3399: add ddrc clock support
  Documentation: bindings: add dt documentation for dfi controller
  PM / devfreq: event: support rockchip dfi controller
  Documentation: bindings: add dt documentation for rk3399 dmc
  PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
  drm/rockchip: Add dmc notifier in vop driver

 .../bindings/devfreq/event/rockchip-dfi.txt|  20 +
 .../devicetree/bindings/devfreq/rk3399_dmc.txt |  85 
 drivers/clk/rockchip/Makefile  |   1 +
 drivers/clk/rockchip/clk-ddr.c | 157 +++
 drivers/clk/rockchip/clk-rk3399.c  |  19 +
 drivers/clk/rockchip/clk.c |   9 +
 drivers/clk/rockchip/clk.h |  35 ++
 drivers/devfreq/Kconfig|  11 +
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/event/Kconfig  |   7 +
 drivers/devfreq/event/Makefile |   1 +
 drivers/devfreq/event/rockchip-dfi.c   | 256 +++
 drivers/devfreq/rk3399_dmc.c   | 499 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 127 +-
 include/dt-bindings/clock/rk3399-cru.h |   1 +
 include/soc/rockchip/rockchip_sip.h|  27 ++
 16 files changed, 1251 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c
 create mode 100644 drivers/devfreq/rk3399_dmc.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

-- 
2.6.6

[PATCH v7 1/8] clk: rockchip: add new clock-type for the ddrclk

[Lin Huang]

On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.

Signed-off-by: Lin Huang 
---
Changes in v7:
- add rockchip_ddrclk_sip_ops so we can distinguish other ddr clock operate
- add ROCKCHIP_SIP_CONFIG_* in rockchip_sip.h give constants a specific name

Changes in v6:
- none

Changes in v5:
- delete unuse mux_flag
- use div_flag to distinguish sip call and other operate

Changes in v4:
- use arm_smccc_smc() to set/read ddr rate

Changes in v3:
- use sip call to set/read ddr rate

Changes in v2:
- use GENMASK instead val_mask
- use divider_recalc_rate() instead DIV_ROUND_UP_ULL
- cleanup code

Changes in v1:
- none

 drivers/clk/rockchip/Makefile   |   1 +
 drivers/clk/rockchip/clk-ddr.c  | 157 
 drivers/clk/rockchip/clk.c  |   9 +++
 drivers/clk/rockchip/clk.h  |  35 
 include/soc/rockchip/rockchip_sip.h |  27 +++
 5 files changed, 229 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y   += clk-pll.o
 obj-y  += clk-cpu.o
 obj-y  += clk-inverter.o
 obj-y  += clk-mmc-phase.o
+obj-y  += clk-ddr.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o

 obj-y  += clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
new file mode 100644
index 000..224e07e
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,157 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+struct rockchip_ddrclk {
+   struct clk_hw   hw;
+   void __iomem*reg_base;
+   int mux_offset;
+   int mux_shift;
+   int mux_width;
+   int div_shift;
+   int div_width;
+   int ddr_flag;
+   spinlock_t  *lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+
+static int rockchip_ddrclk_sip_set_rate(struct clk_hw *hw, unsigned long drate,
+   unsigned long prate)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   unsigned long flags;
+   struct arm_smccc_res res;
+
+   spin_lock_irqsave(ddrclk->lock, flags);
+   arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, drate, 0,
+ ROCKCHIP_SIP_CONFIG_DRAM_SET_RATE,
+ 0, 0, 0, 0, &res);
+   spin_unlock_irqrestore(ddrclk->lock, flags);
+
+   return res.a0;
+}
+
+static unsigned long
+rockchip_ddrclk_sip_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, 0, 0,
+ ROCKCHIP_SIP_CONFIG_DRAM_GET_RATE,
+ 0, 0, 0, 0, &res);
+
+   return res.a0;
+}
+
+static long rockchip_ddrclk_sip_round_rate(struct clk_hw *hw,
+  unsigned long rate,
+  unsigned long *prate)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(ROCKCHIP_SIP_DRAM_FREQ, rate, 0,
+ ROCKCHIP_SIP_CONFIG_DRAM_ROUND_RATE,
+ 0, 0, 0, 0, &res);
+
+   return res.a0;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   int num_parents = clk_hw_get_num_parents(hw);
+   u32 val;
+
+   val = clk_readl(ddrclk->reg_base +
+   ddrclk->mux_offset) >> ddrclk->mux_shift;
+   val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+   if (val >= num_parents)
+   return -EINVAL;
+
+   return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_sip_ops = {
+   .recalc_rate = rockchip_ddrclk_sip_recalc_rate,
+   .set_rate = rockchip_ddrclk_sip_set_rate,
+   .round_rate = rockchip_ddrclk_sip_round_rate,
+   .get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+ 

[PATCH v7 5/8] PM / devfreq: event: support rockchip dfi controller

[Lin Huang]

on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.

Signed-off-by: Lin Huang 
Acked-by: Chanwoo Choi 
---
Changes in v7:
-access need to *4 to get right DDR loading

Changes in v6:
-None

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 drivers/devfreq/event/Kconfig|   7 +
 drivers/devfreq/event/Makefile   |   1 +
 drivers/devfreq/event/rockchip-dfi.c | 256 +++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c

diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
  (Platform Performance Monitoring Unit) counters to estimate the
  utilization of each module.

+config DEVFREQ_EVENT_ROCKCHIP_DFI
+   tristate "ROCKCHIP DFI DEVFREQ event Driver"
+   depends on ARCH_ROCKCHIP
+   help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
 endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@

 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c 
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..43fcc5a
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,256 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK3399_DMC_NUM_CH  2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN  (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN  (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define SOFTWARE_DIS   (0x1 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM   0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
+#define DDRMON_CH1_COUNT_NUM   0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT  13
+#define DDRTYPE_MASK   7
+
+enum {
+   DDR3 = 3,
+   LPDDR3 = 6,
+   LPDDR4 = 7,
+   UNUSED = 0xFF
+};
+
+struct dmc_usage {
+   u32 access;
+   u32 total;
+};
+
+/*
+ * The dfi controller can monitor DDR load. It has an upper and lower threshold
+ * for the operating points. Whenever the usage leaves these bounds an event is
+ * generated to indicate the DDR frequency should be changed.
+ */
+struct rockchip_dfi {
+   struct devfreq_event_dev *edev;
+   struct devfreq_event_desc *desc;
+   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *regmap_pmu;
+   struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+   u32 ddr_type;
+
+   /* get ddr type */
+   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
+   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+   /* clear DDRMON_CTRL setting */
+   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+   /* set ddr type to dfi */
+   if (ddr_type == LPDDR3)
+   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+   else if (ddr_type == LPDDR4)
+   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+   /* enable count, use software mode */
+   writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+
+   writel_relaxed(SOFTWARE_DIS, dfi_regs + DDRMON_CTRL);
+}
+
+static int

[PATCH v7 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Lin Huang]

This patch adds the documentation for rockchip rk3399 dmc driver.

Signed-off-by: Lin Huang 
---
Changes in v7:
-None

Changes in v6:
-Add more detail in Documentation

Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None
 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 85 ++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt

diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
new file mode 100644
index 000..b787abb
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -0,0 +1,85 @@
+* Rockchip rk3399 DMC(Dynamic Memory Controller) device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dmc".
+- devfreq-events: Node to get DDR loading, Refer to
+ Documentation/devicetree/bindings/devfreq/rockchip-dfi.txt
+- interrupts: The interrupt number to the CPU. The interrupt specifier format
+ depends on the interrupt controller. It should be DCF interrupts,
+ when DDR dvfs finish, it will happen.
+- clocks: Phandles for clock specified in "clock-names" property
+- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
+- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
+  for details.
+- center-supply: DMC supply node.
+- status: Marks the node enabled/disabled.
+
+Optional properties:
+- ddr_timing:  DDR timing need to pass to arm trust firmware
+- upthreshold: The upthreshold to simpleondeamnd policy
+- downdifferential: The downdifferential to simpleondeamnd policy
+
+Example:
+
+   ddr_timing: ddr_timing {
+   compatible = "rockchip,ddr-timing";
+   ddr3_speed_bin = <21>;
+   pd_idle = <0>;
+   sr_idle = <0>;
+   sr_mc_gate_idle = <0>;
+   srpd_lite_idle  = <0>;
+   standby_idle = <0>;
+   dram_dll_dis_freq = <300>;
+   phy_dll_dis_freq = <125>;
+
+   ddr3_odt_dis_freq = <333>;
+   ddr3_drv = ;
+   ddr3_odt = ;
+   phy_ddr3_ca_drv = ;
+   phy_ddr3_dq_drv = ;
+   phy_ddr3_odt = ;
+
+   lpddr3_odt_dis_freq = <333>;
+   lpddr3_drv = ;
+   lpddr3_odt = ;
+   phy_lpddr3_ca_drv = ;
+   phy_lpddr3_dq_drv = ;
+   phy_lpddr3_odt = ;
+
+   lpddr4_odt_dis_freq = <333>;
+   lpddr4_drv = ;
+   lpddr4_dq_odt = ;
+   lpddr4_ca_odt = ;
+   phy_lpddr4_ca_drv = ;
+   phy_lpddr4_ck_cs_drv = ;
+   phy_lpddr4_dq_drv = ;
+   phy_lpddr4_odt = ;
+   };
+
+   dmc_opp_table: dmc_opp_table {
+   compatible = "operating-points-v2";
+
+   opp00 {
+   opp-hz = /bits/ 64 <3>;
+   opp-microvolt = <90>;
+   };
+   opp01 {
+   opp-hz = /bits/ 64 <66600>;
+   opp-microvolt = <90>;
+   };
+   };
+
+   dmc: dmc {
+   compatible = "rockchip,rk3399-dmc";
+   devfreq-events = <&dfi>;
+   interrupts = ;
+   clocks = <&cru SCLK_DDRCLK>;
+   clock-names = "dmc_clk";
+   ddr_timing = <&ddr_timing>;
+   operating-points-v2 = <&dmc_opp_table>;
+   center-supply = <&ppvar_centerlogic>;
+   upthreshold = <15>;
+   downdifferential = <10>;
+   status = "disabled";
+   };
+
-- 
2.6.6

[PATCH v7 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Lin Huang]

base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v7:
- remove a blank line

Changes in v6:
- fix some nit suggest by Chanwoo Choi

Changes in v5:
- improve dmc driver suggest by Chanwoo Choi

Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order

Changes in v3:
- operate dram setting through sip call
- imporve set rate flow

Changes in v2:
- None

Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()

 drivers/devfreq/Kconfig  |  11 +
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/rk3399_dmc.c | 499 +++
 3 files changed, 511 insertions(+)
 create mode 100644 drivers/devfreq/rk3399_dmc.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..e848121 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,17 @@ config ARM_TEGRA_DEVFREQ
  It reads ACTMON counters of memory controllers and adjusts the
  operating frequencies and voltages with OPP support.

+config ARM_RK3399_DMC_DEVFREQ
+   tristate "ARM RK3399 DMC DEVFREQ Driver"
+   depends on ARCH_ROCKCHIP
+   select DEVFREQ_EVENT_ROCKCHIP_DFI
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select PM_OPP
+   help
+  This adds the DEVFREQ driver for the RK3399 DMC(Dynamic Memory 
Controller).
+  It sets the frequency for the memory controller and reads the usage 
counts
+  from hardware.
+
 source "drivers/devfreq/event/Kconfig"

 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..fbff40a 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o

 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)   += rk3399_dmc.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o

 # DEVFREQ Event Drivers
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..b73a73c
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,499 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dram_timing {
+   unsigned int ddr3_speed_bin;
+   unsigned int pd_idle;
+   unsigned int sr_idle;
+   unsigned int sr_mc_gate_idle;
+   unsigned int srpd_lite_idle;
+   unsigned int standby_idle;
+   unsigned int dram_dll_dis_freq;
+   unsigned int phy_dll_dis_freq;
+   unsigned int ddr3_odt_dis_freq;
+   unsigned int ddr3_drv;
+   unsigned int ddr3_odt;
+   unsigned int phy_ddr3_ca_drv;
+   unsigned int phy_ddr3_dq_drv;
+   unsigned int phy_ddr3_odt;
+   unsigned int lpddr3_odt_dis_freq;
+   unsigned int lpddr3_drv;
+   unsigned int lpddr3_odt;
+   unsigned int phy_lpddr3_ca_drv;
+   unsigned int phy_lpddr3_dq_drv;
+   unsigned int phy_lpddr3_odt;
+   unsigned int lpddr4_odt_dis_freq;
+   unsigned int lpddr4_drv;
+   unsigned int lpddr4_dq_odt;
+   unsigned int lpddr4_ca_odt;
+   unsigned int phy_lpddr4_ca_drv;
+   unsigned int phy_lpddr4_ck_cs_drv;
+   unsigned int phy_lpddr4_dq_drv;
+   unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+   struct device *dev;
+   struct devfreq *devfreq;
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct clk *dmc_clk;
+   struct devfreq_event_dev *edev;
+   struct mutex lock;
+   struct dram_timing *timing;
+
+   /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* control it in arm trust firmware.
+*/
+   wait_queue_head_t   wait_dcf_queue;
+   int irq;
+   int wait_dcf_flag;
+   struct regulator *vdd_center;
+   unsigned long rate, target_rate;
+   unsigned long volt, target_volt;
+   struct dev_pm_opp *curr_opp;
+};
+

[PATCH v7 8/8] drm/rockchip: Add dmc notifier in vop driver

[Lin Huang]

when in ddr frequency scaling process, vop can not do enable or
disable operation, since in dcf we check vop clock to see whether
vop work. If vop work, dcf do ddr frequency scaling when vop
in vblank status, and we need to read vop register to check whether
vop go into vblank status. If vop not work, dcf can do ddr frequency
any time. So when do ddr frequency scaling, you disabled or enable
vop, there may two bad thing happen: 1, the panel flicker(when vop from
disable status change to enable). 2, kernel hang (when vop from enable
status change to disable, dcf need to read vblank status, but if you disable
vop clock, it can not get the status, it will lead soc dead) So we need
register to devfreq notifier, and we can get the dmc status. Also, when
there have two vop enabled, we need to disable dmc, since dcf only base
on one vop vblank time, so the other panel will flicker when do ddr
frequency scaling.

Signed-off-by: Lin Huang 
Reviewed-by: Chanwoo Choi 
---
Changes in v7:
- None

Changes in v6:
- fix a build error

Changes in v5:
- improve some nits

Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc

Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish

Changes in v2:
- None

Changes in v1:
- use wait_event instead usleep

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 127 ++--
 1 file changed, 122 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ec8ad00..a76e70c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -12,6 +12,8 @@
  * GNU General Public License for more details.
  */

+#include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +120,13 @@ struct vop {

const struct vop_data *data;

+   struct devfreq *devfreq;
+   struct devfreq_event_dev *devfreq_event_dev;
+   struct notifier_block dmc_nb;
+   int dmc_in_process;
+   int vop_switch_status;
+   wait_queue_head_t wait_dmc_queue;
+   wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;

@@ -428,21 +437,59 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
*vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
 }

+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+   struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+   if (event == DEVFREQ_PRECHANGE) {
+   /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+   if (!wait_event_timeout(vop->wait_vop_switch_queue,
+   !vop->vop_switch_status, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+   vop->dmc_in_process = 1;
+   } else if (event == DEVFREQ_POSTCHANGE) {
+   vop->dmc_in_process = 0;
+   wake_up(&vop->wait_dmc_queue);
+   }
+
+   return NOTIFY_OK;
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
+   int num_enabled_crtc = 0;
int ret;

+   if (vop->is_enabled)
+   return;
+
+   /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 100ms as timeout time.
+*/
+   if (!wait_event_timeout(vop->wait_dmc_queue,
+   !vop->dmc_in_process, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+   vop->vop_switch_status = 1;
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   return;
+   goto err;
}

ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
-   return;
+   goto err;
}

ret = clk_enable(vop->dclk);
@@ -456,7 +503,6 @@ static void vop_enable(struct drm_crtc *crtc)
dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
goto err_disable_dclk;
}
-
/*
 * Slave iommu shares power, irq and clock with vop.  It was associated
 * automatically with this master device via common driver code.
@@ -485,6 +531,21 @@ static void vop_enable(struct drm_crtc *crtc)

drm_crtc_vblank_on(crtc);

+   vop->vop_switch_status = 0;
+   wake_up(&vop->wait_vop_switch_queue);
+
+   /* check how many vop we use now */
+   drm_for_each_crtc(crtc, vop

[PATCH 1/1] drm/amdgpu/gmc7: remove dead code

[Christian König]

Am 21.08.2016 um 20:06 schrieb Heinrich Schuchardt:
> In an if block for (running == 0) running cannot be non-zero.
>
> Signed-off-by: Heinrich Schuchardt 

The following patches are all Reviewed-by: Christian König 
:

[PATCH 1/1] drm/amdgpu/gmc7: remove dead code
[PATCH 1/1] drm/amdgpu/gmc8: remove dead code
[PATCH 1/1] drm/amd/powerplay: avoid NULL pointer dereference
[PATCH 1/1] drm/amd/powerplay: avoid NULL dereference, cz_hwmgr.c
[PATCH 1/1] drm/radeon/cik: remove dead code
[PATCH 1/1] drm/radeon: remove dead code, si_mc_load_microcode

Thanks for the help,
Christian.

PS: Please send such minor cleanups as one set of patches next time, 
cause that makes reviewing them much easier.

> ---
>   drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 
>   1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index 0b0f086..1239463 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -203,11 +203,6 @@ static int gmc_v7_0_mc_load_microcode(struct 
> amdgpu_device *adev)
>   running = REG_GET_FIELD(RREG32(mmMC_SEQ_SUP_CNTL), MC_SEQ_SUP_CNTL, 
> RUN);
>   
>   if (running == 0) {
> - if (running) {
> - blackout = RREG32(mmMC_SHARED_BLACKOUT_CNTL);
> - WREG32(mmMC_SHARED_BLACKOUT_CNTL, blackout | 1);
> - }
> -
>   /* reset the engine and set to writable */
>   WREG32(mmMC_SEQ_SUP_CNTL, 0x0008);
>   WREG32(mmMC_SEQ_SUP_CNTL, 0x0010);
> @@ -239,9 +234,6 @@ static int gmc_v7_0_mc_load_microcode(struct 
> amdgpu_device *adev)
>   break;
>   udelay(1);
>   }
> -
> - if (running)
> - WREG32(mmMC_SHARED_BLACKOUT_CNTL, blackout);
>   }
>   
>   return 0;

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

[Ying Liu]

On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter  wrote:
> On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu  wrote:
 +
 + /*
 +  * The relevant plane's ->atomic_check callback may set
 +  * crtc_state->mode_changed to be true when the active
 +  * plane needs to be reconfigured.  In this case and only
 +  * this case, active_changed is false - we disable all the
 +  * appropriate active planes here.
 +  */
 + if (!crtc->state->active_changed) {
 + struct drm_plane *plane;
 +
 + drm_atomic_crtc_state_for_each_plane(plane, old_crtc_state) {
 + const struct drm_plane_helper_funcs *plane_funcs =
 + plane->helper_private;
 +
 + /*
 +  * Filter out the plane which is explicitly required
 +  * to be disabled by the user via atomic commit
 +  * so that it won't be accidentally disabled twice.
 +  */
 + if (!plane->state->crtc)
 + continue;
>>>
>>> I think the better place would be to do the filtering in commit_planes(),
>>> not here. And would be great to include your patch to fix up
>>> disable_planes_on_crtc(), too.
>>
>> Do you mean we can do the filtering by checking (!plane->state->crtc)
>> right before plane_funcs->atomic_disable in commit_planes()?
>> Won't it filter out all the apples?
>> commit_planes() doesn't know whether the driver calls
>> disable_planes_on_crtc() or not.
>
> You need to filter on needs_modeset(crtc_state), and it needs to be
> optional like active_only, using a flag.

Then, IIUC, the flag will be CRTC specific and be dynamically
changeable. I'm not clear about the way to implement this.

>
>> imo, doing the filtering in crtc_funcs->atomic_disable is sane.
>
> It is not sane in general, since usually you need to call
> disable_planes_on_crtc to avoid upsetting your hardware. And for that

Calling disable_planes_on_crtc() in crtc_funcs->atomic_disable is
a bit over-kill and will cause the issue of disabling plane twice, unless
the filtering is done in disable_planes_on_crtc() (which was rejected
by you on irc) or in commit_planes()?(which I'm not clear about
the way to implement, as I mentioned before).  So I chose to do the
filtering in the imx-drm specific crtc_funcs->atomic_disable function.

> use-case filtering in disable will lead to hung hardware. Which really

Hung hardware due to filtering? How?

> means that you need to filter in commit_planes.

Really don't understand the rational for filtering in commit_planes...
Did I miss anything?

Regards,
Liu Ying

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

[PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Maarten Lankhorst]

Op 18-08-16 om 16:05 schreef Lyude Paul:
> On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 17-08-16 om 21:55 schreef Lyude:
>>> Since the watermark calculations for Skylake are still broken, we're apt
>>> to hitting underruns very easily under multi-monitor configurations.
>>> While it would be lovely if this was fixed, it's not. Another problem
>>> that's been coming from this however, is the mysterious issue of
>>> underruns causing full system hangs. An easy way to reproduce this with
>>> a skylake system:
>>>
>>> - Get a laptop with a skylake GPU, and hook up two external monitors to
>>>   it
>>> - Move the cursor from the built-in LCD to one of the external displays
>>>   as quickly as you can
>>> - You'll get a few pipe underruns, and eventually the entire system will
>>>   just freeze.
>>>
>>> After doing a lot of investigation and reading through the bspec, I
>>> found the existence of the SAGV, which is responsible for adjusting the
>>> system agent voltage and clock frequencies depending on how much power
>>> we need. According to the bspec:
>>>
>>> "The display engine access to system memory is blocked during the
>>>  adjustment time. SAGV defaults to enabled. Software must use the
>>>  GT-driver pcode mailbox to disable SAGV when the display engine is not
>>>  able to tolerate the blocking time."
>>>
>>> The rest of the bspec goes on to explain that software can simply leave
>>> the SAGV enabled, and disable it when we use interlaced pipes/have more
>>> then one pipe active.
>>>
>>> Sure enough, with this patchset the system hangs resulting from pipe
>>> underruns on Skylake have completely vanished on my T460s. Additionally,
>>> the bspec mentions turning off the SAGV with more then one pipe
>>> enabled
>>> as a workaround for display underruns. While this patch doesn't entirely
>>> fix that, it looks like it does improve the situation a little bit so
>>> it's likely this is going to be required to make watermarks on Skylake
>>> fully functional.
>>>
>>> This will still need additional work in the future: we shouldn't be
>>> enabling the SAGV if any of the currently enabled planes can't enable WM
>>> levels that introduce latencies >= 30 µs.
>>>
>>> Changes since v11:
>>>  - Add skl_can_enable_sagv()
>>>  - Make sure we don't enable SAGV when not all planes can enable
>>>watermarks >= the SAGV engine block time. I was originally going to
>>>save this for later, but I recently managed to run into a machine
>>>that was having problems with a single pipe configuration + SAGV.
>>>  - Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit
>>>  - Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE
>>>  - Move printks outside of mutexes
>>>  - Don't print error messages twice
>>> Changes since v10:
>>>  - Apparently sandybridge_pcode_read actually writes values and reads
>>>them back, despite it's misleading function name. This means we've
>>>been doing this mostly wrong and have been writing garbage to the
>>>SAGV control. Because of this, we no longer attempt to read the SAGV
>>>status during initialization (since there are no helpers for this).
>>>  - mlankhorst noticed that this patch was breaking on some very early
>>>pre-release Skylake machines, which apparently don't allow you to
>>>disable the SAGV. To prevent machines from failing tests due to SAGV
>>>errors, if the first time we try to control the SAGV results in the
>>>mailbox indicating an invalid command, we just disable future attempts
>>>to control the SAGV state by setting dev_priv->skl_sagv_status to
>>>I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
>>>  - Move mutex_unlock() a little higher in skl_enable_sagv(). This
>>>doesn't actually fix anything, but lets us release the lock a little
>>>sooner since we're finished with it.
>>> Changes since v9:
>>>  - Only enable/disable sagv on Skylake
>>> Changes since v8:
>>>  - Add intel_state->modeset guard to the conditional for
>>>skl_enable_sagv()
>>> Changes since v7:
>>>  - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
>>>all we use it for anyway)
>>>  - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
>>>  - Fix a styling error that snuck past me
>>> Changes since v6:
>>>  - Protect skl_enable_sagv() with intel_state->modeset conditional in
>>>intel_atomic_commit_tail()
>>> Changes since v5:
>>>  - Don't use is_power_of_2. Makes things confusing
>>>  - Don't use the old state to figure out whether or not to
>>>enable/disable the sagv, use the new one
>>>  - Split the loop in skl_disable_sagv into it's own function
>>>  - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
>>> Changes since v4:
>>>  - Use is_power_of_2 against active_crtcs to check whether we have > 1
>>>pipe enabled
>>>  - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
>>>enabled
>>>  - Call skl_sagv_enable/disable() fr

[PATCH 1/1] drm: avoid exposing kernel stack in compat_drm_getstats

[Jani Nikula]

On Mon, 22 Aug 2016, Daniel Vetter  wrote:
> On Sun, Aug 21, 2016 at 07:56:19PM +0200, Heinrich Schuchardt wrote:
>> The C standard does not specify the size of the integer used
>> to store an enum. Hence in structure drm_stats32_t alignment
>> bytes may exist.
>> 
>> To avoid exposing bytes from the kernel stack it is
>> necessary to initialize variable s32 completely.
>> 
>> Signed-off-by: Heinrich Schuchardt 
>
> Applied to drm-misc, thanks.
> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_ioc32.c | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
>> index 57676f8..32a489b 100644
>> --- a/drivers/gpu/drm/drm_ioc32.c
>> +++ b/drivers/gpu/drm/drm_ioc32.c
>> @@ -346,6 +346,7 @@ static int compat_drm_getstats(struct file *file, 
>> unsigned int cmd,
>>  struct drm_stats __user *stats;
>>  int i, err;
>>  
>> +memset(&s32, 0, sizeof(drm_stats32_t));

For future reference,

memset(&s32, 0, sizeof(s32));

is the better approach, avoiding problems if the type of s32 ever
changes.

BR,
Jani.


>>  stats = compat_alloc_user_space(sizeof(*stats));
>>  if (!stats)
>>  return -EFAULT;
>> -- 
>> 2.1.4
>> 
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/gma500: dont expose bytes from kernel stack

[Jani Nikula]

On Sun, 21 Aug 2016, Heinrich Schuchardt  wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index da9fd34..28bd8f3 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -138,6 +138,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
>   u32 target_vco, actual_freq;
>   s32 freq_error, min_error = 10;
>  
> + memset(clock, 0, sizeof(struct gma_clock_t));

Did you build this? Did you run this?

BR,
Jani.


>   memset(best_clock, 0, sizeof(*best_clock));
>  
>   for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/1] drm/gma500: dont expose stack, mrst_lvds_find_best_pll

[Jani Nikula]

On Sun, 21 Aug 2016, Heinrich Schuchardt  wrote:
> All components of variable clock should be initialized
> to avoid bytes from the kernel stack to be exposed.
>
> Reported-by: Joe Perches 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index 28bd8f3..0277d85 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -195,6 +195,7 @@ static bool mrst_lvds_find_best_pll(const struct 
> gma_limit_t *limit,
>   struct gma_clock_t clock;
>   int err = target;
>  
> + memset(clock, 0, sizeof(struct gma_clock_t));

Again, did you actually build this? This is hurting not helping us. It
makes me think you didn't try your other patches either.

BR,
Jani.


>   memset(best_clock, 0, sizeof(*best_clock));
>  
>   for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {

-- 
Jani Nikula, Intel Open Source Technology Center

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Emil Velikov]

On 20 August 2016 at 23:31, Rob Clark  wrote:
> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli  wrote:
>> Cc'ing lkml too.
>>
>> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>>> Story time:
>>> I was dreaming of a day were we can stop installing these headers,
>>> thus making deprecation a bit easier process.
>>> Yet after failing to convince Dave and Daniel on a number of occasions
>>> I've accepted that those headers _are_ here to stay. And yes they
>>> _are_ the UAPI, even though no applications are meant to use them but
>>> the libdrm 'version'.
>>> Thus any changes to the libdrm ones should be a mirror of the ones
>>> here and libdrm should _not_ differ.
>>
>> Another day dream:
>>
>> Wouldn't it be nice if the uapi headers from Linux kernel would pass
>> a simple quality check of compiling in userspace where they are meant to be
>> used? Stand alone. Without magic tricks and additional libraries and their
>> headers. Without glibc or any other libc implementation specific additions.
>> The uapi headers define many parts of the Linux kernel API and ABI, and thus
>> compiling them also without the 'official' GNU/Linux userspace libraries
>> like glibc or libdrm does have some uses. For example API and ABI
>> compatibility checks and API/ABI/system call fuzzers.
>>
>> Many headers required stdint.h types but Linux kernel headers do not
>> define them in userspace, and then Linus has said that uapi headers
>> should use the linux/types.h with double underscores. Thus my patches
>> for fixing trivial compile errors turned into changing several stdint.h
>> definitions to linux/types.h.
>
> The problem is, for the most part, the driver specific gpu related
> ioctl interfaces are not intended for general public consumption.
> They have one consumer, ie. libdrm_$drivername (or perhaps mesa
> directly).  They are complex interfaces, because GPUs are complex.
> They are not intended to be used directly (or for the most part, even
> indirectly) by random userspace applications.  And in fact the uapi
> headers exported from kernel are not actually ever used.  (ie.
> libdrm_$drivername uses it's own copy internally within libdrm.)
>
> So Linus's argument against stdint types, as weak as it is, doesn't
> even apply for gpu driver specific ioctls.
>
Although last time around people leaned towards the __uX types, if we
have a consensus amongst drm (kernel) developers about using stdint
ones everything should be fine.
We just need a handful of acks from the different maintainers.

That said, _note_ that some applications are built with -C89 -pedantic
[1] which means that using stdint.h may or may not work as expected.
So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
If the affected programs are proprietary ones we should be safe,
otherwise we want to update them ~alongside the transition.

Thanks
Emil

[1]
https://cgit.freedesktop.org/mesa/drm/commit/?id=0f4452bb51306024fbf4cbf77d8baab20cefba67
https://cgit.freedesktop.org/mesa/drm/commit/?id=d20314d083e533e3b8753192b1846752341afbbe

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Christian König]

Am 22.08.2016 um 10:48 schrieb Emil Velikov:
>
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.

For the record I always clearly voted for the C99 stdint types instead 
of the kernel ones.

> That said, _note_ that some applications are built with -C89 -pedantic
> [1] which means that using stdint.h may or may not work as expected.
> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
> If the affected programs are proprietary ones we should be safe,
> otherwise we want to update them ~alongside the transition.

While it is theoretical possible I don't think we have any applications 
which actually do this, cause they would have been broken before as well.

Regards,
Christian.

>
> Thanks
> Emil
>
> [1]
> https://cgit.freedesktop.org/mesa/drm/commit/?id=0f4452bb51306024fbf4cbf77d8baab20cefba67
> https://cgit.freedesktop.org/mesa/drm/commit/?id=d20314d083e533e3b8753192b1846752341afbbe
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/gma500: dont expose bytes from kernel stack

[One Thousand Gnomes]

On Mon, 22 Aug 2016 09:29:17 +0200
Daniel Vetter  wrote:

> On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> > Components m1, m2, p2, dot, vco of variable clock should be
> > initialized to avoid bytes from the kernel stack to be
> > exposed.
> > 
> > Signed-off-by: Heinrich Schuchardt   
> 
> Might be a silly question, but where exactly would we expose these bytes?
> This isn't directly called by an ioctl, I have no idea how those bytes
> might get to userspace ...

mrst_print_pll displays clock.p2 - which is indeed never cleared 8)

Alan

[PATCH 3/3] drm/etnaviv: remove unneeded variable initialization

[Lucas Stach]

Am Sonntag, den 21.08.2016, 19:32 -0300 schrieb Fabio Estevam:
> There is no need to initialize variable 'err' with 0 because it will
> be properly assigned later on. 
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index d93eb8c..27f34f5 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1652,7 +1652,7 @@ static int etnaviv_gpu_platform_probe(struct 
> platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   struct etnaviv_gpu *gpu;
> - int err = 0;
> + int err;

This looks like churn to me, and I wouldn't take this patch if it would
stand on its own. But as it's part of the series and the other 2 patches
look good to me, I'll take the whole series.

Thanks,
Lucas

[RFC 1/2] drm: add support for framebuffer processors

[Marek Szyprowski]

This patch extends DRM API with generic support for hardware modules, which
can be used for processing image data from the one memory buffer to
another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them. I named such hardware modules a
framebuffer processors.

The new API is heavily inspired by atomic KMS approach - it is also
based on DRM objects and their properties. A new DRM object is introduced:
framebuffer processor (called fbproc for convenience). Such fbproc objects
have a set of standard DRM properties, which describes the operation to be
performed by respective hardware module. In typical case those properties
are a source fb id and rectangle (x, y, width, height) and destination fb
id and rectangle. Optionally a rotation property can be also specified if
supported by the given hardware. To perform an operation on image data,
userspace provides a set of properties and their values for given fbproc
object in a similar way as object and properties are provided for
performing atomic page flip / mode setting.

The API consists of the 3 new ioctls:
- DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
  objects,
- DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
- DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
  set.

The proposed API is extensible. Drivers can attach their own, custom
properties to add support for more advanced picture processing (for example
blending).

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_atomic.c|   5 +
 drivers/gpu/drm/drm_crtc.c  |   6 +
 drivers/gpu/drm/drm_crtc_internal.h |  12 +
 drivers/gpu/drm/drm_fbproc.c| 754 
 drivers/gpu/drm/drm_ioctl.c |   3 +
 include/drm/drmP.h  |  10 +
 include/drm/drm_crtc.h  | 211 ++
 include/drm/drm_irq.h   |  14 +
 include/uapi/drm/drm.h  |  13 +
 include/uapi/drm/drm_mode.h |  39 ++
 11 files changed, 1069 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_fbproc.c

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0238bf8bc8c3..9ff4e04d8071 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,8 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_modeset_lock.o drm_atomic.o drm_bridge.o
+   drm_modeset_lock.o drm_atomic.o drm_bridge.o \
+   drm_fbproc.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index fa3930757972..5338c2898db2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1059,6 +1059,11 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
plane->state, property, val);
break;
}
+   case DRM_MODE_OBJECT_FBPROC: {
+   struct drm_fbproc *fbproc = obj_to_fbproc(obj);
+   ret = drm_fbproc_get_property(fbproc, property, val);
+   break;
+   }
default:
ret = -EINVAL;
break;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e92bb9d3f90f..091d33516335 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1540,6 +1540,7 @@ void drm_modeset_unregister_all(struct drm_device *dev)
 static int drm_mode_create_standard_properties(struct drm_device *dev)
 {
struct drm_property *prop;
+   int ret;

/*
 * Standard properties (apply to all connectors)
@@ -1689,6 +1690,10 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   ret = drm_fbproc_create_properties(dev);
+   if (ret)
+   return ret;
+
return 0;
 }

@@ -5692,6 +5697,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
INIT_LIST_HEAD(&dev->mode_config.plane_list);
+   INIT_LIST_HEAD(&dev->mode_config.fbproc_list);
idr_init(&dev->mode_config.crtc_idr);
idr_init(&dev->mode_config.tile_idr);
ida_init(&dev->mode_config.connector_ida);
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 0c34e6d906d1..bbdea67cefdf 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -132,3 +132,15 @@ void drm_modeset_unregister_all(struct drm_device *dev);
 /* 

[RFC 2/2] drm/exynos: register rotator as fbproc instead of custom ipp framework

[Marek Szyprowski]

This is a quick conversion of Exynos DRM rotator driver from
Exynos IPP framework to generic DRM FBProc API to demonstrate how to use it
from the driver side.

Not-for-merge-yet: the code of the driver must be cleaned up first, because
its internals still depends on Exynos IPP structures.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/Kconfig  |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 353 +++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |  19 --
 4 files changed, 194 insertions(+), 182 deletions(-)
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 83f61c513b7e..6eebba9be797 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -109,7 +109,6 @@ config DRM_EXYNOS_FIMC

 config DRM_EXYNOS_ROTATOR
bool "Rotator"
-   depends on DRM_EXYNOS_IPP
help
  Choose this option if you want to use Exynos Rotator for DRM.

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 877d2efa28e2..f536a63531bb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -395,7 +395,7 @@ static const struct file_operations exynos_drm_driver_fops 
= {

 static struct drm_driver exynos_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME
- | DRIVER_ATOMIC | DRIVER_RENDER,
+ | DRIVER_ATOMIC | DRIVER_RENDER | 
DRIVER_FBPROC,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
.open   = exynos_drm_open,
@@ -532,6 +532,7 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = 
{
DRV_PTR(fimc_driver, CONFIG_DRM_EXYNOS_FIMC),
}, {
DRV_PTR(rotator_driver, CONFIG_DRM_EXYNOS_ROTATOR),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(gsc_driver, CONFIG_DRM_EXYNOS_GSC),
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 404367a430b5..8ecd8db0649a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -10,6 +10,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,8 +22,10 @@
 #include 
 #include 
 #include "regs-rotator.h"
+#include "exynos_drm_fb.h"
 #include "exynos_drm_drv.h"
 #include "exynos_drm_ipp.h"
+#include "exynos_drm_iommu.h"

 /*
  * Rotator supports image crop/rotator and input/output DMA operations.
@@ -92,7 +95,9 @@ struct rot_limit_table {
  * @suspended: suspended state.
  */
 struct rot_context {
-   struct exynos_drm_ippdrvippdrv;
+   struct drm_fbproc fbproc;
+   struct drm_device *drm_dev;
+   struct device *dev;
struct resource *regs_res;
void __iomem*regs;
struct clk  *clock;
@@ -100,6 +105,10 @@ struct rot_context {
int irq;
int cur_buf_id[EXYNOS_DRM_OPS_MAX];
boolsuspended;
+   spinlock_t  lock;
+   struct drm_fbproc_task  *task;
+   wait_queue_head_t   done_wq;
+   booldone;
 };

 static void rotator_reg_set_irq(struct rot_context *rot, bool enable)
@@ -138,9 +147,6 @@ static enum rot_irq_status 
rotator_reg_get_irq_status(struct rot_context *rot)
 static irqreturn_t rotator_irq_handler(int irq, void *arg)
 {
struct rot_context *rot = arg;
-   struct exynos_drm_ippdrv *ippdrv = &rot->ippdrv;
-   struct drm_exynos_ipp_cmd_node *c_node = ippdrv->c_node;
-   struct drm_exynos_ipp_event_work *event_work = c_node->event_work;
enum rot_irq_status irq_status;
u32 val;

@@ -152,12 +158,14 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
val |= ROT_STATUS_IRQ_PENDING((u32)irq_status);
rot_write(val, ROT_STATUS);

-   if (irq_status == ROT_IRQ_STATUS_COMPLETE) {
-   event_work->ippdrv = ippdrv;
-   event_work->buf_id[EXYNOS_DRM_OPS_DST] =
-   rot->cur_buf_id[EXYNOS_DRM_OPS_DST];
-   queue_work(ippdrv->event_workq, &event_work->work);
-   } else {
+   spin_lock(&rot->lock);
+   rot->task = NULL;
+   rot->done = true;
+   spin_unlock(&rot->lock);
+
+   wake_up(&rot->done_wq);
+
+   if (irq_status != ROT_IRQ_STATUS_COMPLETE) {
DRM_ERROR("the SFR is set illegally\n");
}

@@ -455,36 +463,6 @@ static int rotator_dst_set_addr(struct device *dev,
return 0;
 }

-static struct exynos_drm_ipp_ops rot_src_ops = {
-   .set_fmt=   rotator_src_set_fmt,
-   .set_size   =   rotator_src_set_size,
-   .set_addr   =   rotator_src_set_addr,

[RFC libdrm] add support for framebuffer processor (fbproc) objects

[Marek Szyprowski]

This patch extends DRM API with generic support for hardware modules, which
can be used for processing image data from the one memory buffer to
another. Typical memory-to-memory operations are: rotation, scaling, colour
space conversion or mix of them. I named such hardware modules a
framebuffer processors.

The new API is heavily inspired by atomic KMS approach - it is also
based on DRM objects and their properties. A new DRM object is introduced:
framebuffer processor (called fbproc for convenience). Such fbproc objects
have a set of standard DRM properties, which describes the operation to be
performed by respective hardware module. In typical case those properties
are a source fb id and rectangle (x, y, width, height) and destination fb
id and rectangle. Optionally a rotation property can be also specified if
supported by the given hardware. To perform an operation on image data,
userspace provides a set of properties and their values for given fbproc
object in a similar way as object and properties are provided for
performing atomic page flip / mode setting.

The API consists of the 3 new ioctls:
- DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
  objects,
- DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
- DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
  set.

The proposed API is extensible. Drivers can attach their own, custom
properties to add support for more advanced picture processing (for example
blending).

Signed-off-by: Marek Szyprowski 
---
 include/drm/drm.h  |  13 ++
 include/drm/drm_mode.h |  39 ++
 xf86drmMode.c  | 345 +
 xf86drmMode.h  |  37 ++
 4 files changed, 434 insertions(+)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index b4ebaa9..15691fd 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -794,6 +794,9 @@ struct drm_prime_handle {
 #define DRM_IOCTL_MODE_ATOMIC  DRM_IOWR(0xBC, struct drm_mode_atomic)
 #define DRM_IOCTL_MODE_CREATEPROPBLOB  DRM_IOWR(0xBD, struct 
drm_mode_create_blob)
 #define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct 
drm_mode_destroy_blob)
+#define DRM_IOCTL_MODE_GETFBPROCRESOURCES DRM_IOWR(0xBF, struct 
drm_mode_get_fbproc_res)
+#define DRM_IOCTL_MODE_GETFBPROC   DRM_IOWR(0xC0, struct 
drm_mode_get_fbproc)
+#define DRM_IOCTL_MODE_FBPROC  DRM_IOWR(0xC1, struct drm_mode_fbproc)

 /**
  * Device specific ioctls should only be in their respective headers
@@ -825,6 +828,7 @@ struct drm_event {

 #define DRM_EVENT_VBLANK 0x01
 #define DRM_EVENT_FLIP_COMPLETE 0x02
+#define DRM_EVENT_FBPROC_COMPLETE 0x03

 struct drm_event_vblank {
struct drm_event base;
@@ -835,6 +839,15 @@ struct drm_event_vblank {
__u32 reserved;
 };

+struct drm_event_fbproc {
+   struct drm_event base;
+   __u64 user_data;
+   __u32 tv_sec;
+   __u32 tv_usec;
+   __u32 sequence;
+   __u32 reserved;
+};
+
 /* typedef area */
 typedef struct drm_clip_rect drm_clip_rect_t;
 typedef struct drm_drawable_info drm_drawable_info_t;
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 7a7856e..03dbd04 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -320,6 +320,21 @@ struct drm_mode_connector_set_property {
__u32 connector_id;
 };

+struct drm_mode_get_fbproc_res {
+   __u64 fbproc_id_ptr;
+   __u32 count_fbprocs;
+};
+
+struct drm_mode_get_fbproc {
+   __u32 fbproc_id;
+   __u32 capabilities;
+
+   __u32 src_format_count;
+   __u32 dst_format_count;
+   __u64 src_format_type_ptr;
+   __u64 dst_format_type_ptr;
+};
+
 #define DRM_MODE_OBJECT_CRTC 0x
 #define DRM_MODE_OBJECT_CONNECTOR 0xc0c0c0c0
 #define DRM_MODE_OBJECT_ENCODER 0xe0e0e0e0
@@ -328,6 +343,7 @@ struct drm_mode_connector_set_property {
 #define DRM_MODE_OBJECT_FB 0xfbfbfbfb
 #define DRM_MODE_OBJECT_BLOB 0x
 #define DRM_MODE_OBJECT_PLANE 0x
+#define DRM_MODE_OBJECT_FBPROC 0x
 #define DRM_MODE_OBJECT_ANY 0

 struct drm_mode_obj_get_properties {
@@ -621,4 +637,27 @@ struct drm_mode_destroy_blob {
__u32 blob_id;
 };

+#define DRM_FBPROC_CAP_CROP  0x01
+#define DRM_FBPROC_CAP_ROTATE0x02
+#define DRM_FBPROC_CAP_SCALE 0x04
+#define DRM_FBPROC_CAP_CONVERT   0x08
+#define DRM_FBPROC_CAP_FB_MODIFIERS0x1000
+
+#define DRM_MODE_FBPROC_EVENT  0x01
+#define DRM_MODE_FBPROC_TEST_ONLY  0x02
+#define DRM_MODE_FBPROC_NONBLOCK   0x04
+
+#define DRM_MODE_FBPROC_FLAGS (DRM_MODE_FBPROC_EVENT |\
+   DRM_MODE_FBPROC_TEST_ONLY | DRM_MODE_FBPROC_NONBLOCK)
+
+struct drm_mode_fbproc {
+   __u32 fbproc_id;
+   __u32 flags;
+   __u32 count_props;
+   __u64 props_ptr;
+   __u64 prop_values_ptr;
+   __u64 reserved;
+   __u64 user_data;
+};
+
 #endif
diff --git a/xf86drmMode.c b/xf86drmMode.c
index f7b5948..65db2b6 100644
--- a/xf86drm

[RFC 0/2] New feature: Framebuffer processors

[Marek Szyprowski]

Dear all,

This is the initial proposal for extending DRM API with generic support for
hardware modules, which can be used for processing image data from the one
memory buffer to another. Typical memory-to-memory operations are:
rotation, scaling, colour space conversion or mix of them. In this proposal
I named such hardware modules a framebuffer processors.

Embedded SoCs are known to have a number of hardware blocks, which perform
such operations. They can be used in paralel to the main GPU module to
offload CPU from processing grapics or video data. One of example use of
such modules is implementing video overlay, which usually requires color
space conversion from NV12 (or similar) to RGB32 color space and scaling to
target window size.

Till now there was no generic, hardware independent API for performing such
operations. Exynos DRM driver has its own custom extension called IPP
(Image Post Processing), but frankly speaking, it is over-engineered and not
really used in open-source. I didn't indentify similar API in other DRM
drivers, besides those which expose complete support for the whole GPU.

However, the need for commmon API has been already mentioned on the mailing
list. Here are some example threads:
1. "RFC: hardware accelerated bitblt using dma engine"
http://www.spinics.net/lists/dri-devel/msg114250.html
2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem"
https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html

The proposed API is heavily inspired by atomic KMS approach - it is also
based on DRM objects and their properties. A new DRM object is introduced:
framebuffer processor (called fbproc for convenience). Such fbproc objects
have a set of standard DRM properties, which describes the operation to be
performed by respective hardware module. In typical case those properties
are a source fb id and rectangle (x, y, width, height) and destination fb
id and rectangle. Optionally a rotation property can be also specified if
supported by the given hardware. To perform an operation on image data,
userspace provides a set of properties and their values for given fbproc
object in a similar way as object and properties are provided for
performing atomic page flip / mode setting.

The proposed API consists of the 3 new ioctls:
- DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
  objects,
- DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
- DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
  set.

The proposed API is extensible. Drivers can attach their own, custom
properties to add support for more advanced picture processing (for example
blending).

Please note that this API is intended to be used for simple memory-to-memory
image processing hardware not the full-blown GPU blitters, which usually
have more features. Typically blitters provides much more operations beside
simple pixel copying and operate best if its command queue is controlled from
respective dedicated code in userspace.

The patchset consist of 4 parts:
1. generic code for DRM core for handling fbproc objects and ioctls
2. example, quick conversion of Exynos Rotator driver to fbproc API
3. libdrm extensions for handling fbproc objects
4. simple example of userspace code for performing 180 degree rotation of the
   framebuffer

Patches were tested on Exynos 4412-based Odroid U3 board, on top
of Linux v4.8-rc1 kernel.

TODO:
1. agree on the API shape
2. add more documentation, especially to the kernel docs
3. add more userspace examples

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Marek Szyprowski (2):
  drm: add support for framebuffer processor objects
  drm/exynos: register rotator as fbproc instead of custom ipp framework

 drivers/gpu/drm/Makefile|   3 +-
 drivers/gpu/drm/drm_atomic.c|   5 +
 drivers/gpu/drm/drm_crtc.c  |   6 +
 drivers/gpu/drm/drm_crtc_internal.h |  12 +
 drivers/gpu/drm/drm_fbproc.c| 754 
 drivers/gpu/drm/drm_ioctl.c |   3 +
 drivers/gpu/drm/exynos/Kconfig  |   1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 353 +++--
 drivers/gpu/drm/exynos/exynos_drm_rotator.h |  19 -
 include/drm/drmP.h  |  10 +
 include/drm/drm_crtc.h  | 211 
 include/drm/drm_irq.h   |  14 +
 include/uapi/drm/drm.h  |  13 +
 include/uapi/drm/drm_mode.h |  39 ++
 15 files changed, 1263 insertions(+), 183 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_fbproc.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_rotator.h

-- 
1.9.1

[RFC code example] example code for testing fbproc drivers

[Marek Szyprowski]

This is simple example how DRM FBProc API can be used from
userspace. The code allocates 2 dumb framebuffers, fill first with
test pattern and then performs 180 degree rotation of the image data.

TODO: add code to release all allocated resources

Signed-off-by: Marek Szyprowski 
---
 rotate.c | 336 +++
 1 file changed, 336 insertions(+)
 create mode 100644 rotate.c

diff --git a/rotate.c b/rotate.c
new file mode 100644
index 000..ff4aae0
--- /dev/null
+++ b/rotate.c
@@ -0,0 +1,336 @@
+/*
+ * Copyright (C) 2016 Samsung Electronics Co.Ltd
+ * Authors: Marek Szyprowski 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* missing rotation property bits */
+#define DRM_ROTATE_0   0x01
+#define DRM_ROTATE_90  0x02
+#define DRM_ROTATE_180 0x04
+#define DRM_ROTATE_270 0x08
+#define DRM_REFLECT_X  0x10
+#define DRM_REFLECT_Y  0x20
+
+struct bo
+{
+   int fd;
+   void *ptr;
+   size_t size;
+   size_t offset;
+   size_t pitch;
+   int width;
+   int height;
+   unsigned handle;
+   unsigned fb_id;
+};
+
+struct bo *bo_create_dumb(int fd, unsigned int width, unsigned int height,
+ unsigned int bpp)
+{
+   struct drm_mode_create_dumb arg;
+   struct bo *bo;
+   int ret;
+
+   bo = calloc(1, sizeof(*bo));
+   if (bo == NULL) {
+   fprintf(stderr, "failed to allocate buffer object\n");
+   return NULL;
+   }
+
+   memset(&arg, 0, sizeof(arg));
+   arg.bpp = bpp;
+   arg.width = width;
+   arg.height = height;
+
+   ret = drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &arg);
+   if (ret) {
+   fprintf(stderr, "failed to create dumb buffer: %s\n",
+   strerror(errno));
+   free(bo);
+   return NULL;
+   }
+
+   bo->fd = fd;
+   bo->handle = arg.handle;
+   bo->size = arg.size;
+   bo->pitch = arg.pitch;
+   bo->width = width;
+   bo->height = height;
+
+   return bo;
+}
+
+int bo_map(struct bo *bo)
+{
+   struct drm_mode_map_dumb arg;
+   void *map;
+   int ret;
+
+   memset(&arg, 0, sizeof(arg));
+   arg.handle = bo->handle;
+
+   ret = drmIoctl(bo->fd, DRM_IOCTL_MODE_MAP_DUMB, &arg);
+   if (ret)
+   return ret;
+
+   map = mmap(0, bo->size, PROT_READ | PROT_WRITE, MAP_SHARED,
+  bo->fd, arg.offset);
+   if (map == MAP_FAILED)
+   return -EINVAL;
+
+   bo->ptr = map;
+
+   return 0;
+}
+
+void bo_unmap(struct bo *bo)
+{
+   if (!bo->ptr)
+   return;
+
+   munmap(bo->ptr, bo->size);
+   bo->ptr = NULL;
+}
+
+void bo_destroy(struct bo *bo)
+{
+   struct drm_mode_destroy_dumb arg;
+   int ret;
+
+   memset(&arg, 0, sizeof(arg));
+   arg.handle = bo->handle;
+
+   ret = drmIoctl(bo->fd, DRM_IOCTL_MODE_DESTROY_DUMB, &arg);
+   if (ret)
+   fprintf(stderr, "failed to destroy dumb buffer: %s\n",
+   strerror(errno));
+
+   free(bo);
+}
+
+int bo_add_fb(struct bo *bo, uint32_t format, uint32_t flags)
+{
+   int ret;
+   uint32_t handles[4] = {bo->handle};
+   uint32_t pitches[4] = {bo->pitch};
+   uint32_t offsets[4] = {};
+
+
+   ret = drmModeAddFB2(bo->fd, bo->width, bo->height,
+   format, handles, pitches, offsets,
+   &bo->fb_id, flags);
+   if (ret) {
+   printf("failed to create fb ret=%d\n", ret);
+   return ret;
+   }
+   return 0;
+}
+
+struct bo *bo_create_dumb_fb_xrgb(int fd, unsigned int width, unsigned int 
height)
+{
+   struct bo *bo;
+
+   bo = bo_create_dumb(fd, wi

[RFC 0/2] New feature: Framebuffer processors

[Tobias Jakobi]

Hey Marek,

I had a quick look at the series and I really like the new approach.

I was wondering about the following though. If I understand this
correctly I can only perform m2m operations on buffers which are
registered as framebuffers. Is this possible to weaken that requirements
such that arbitrary GEM objects can be used as input and output?

Anyway, great work!

With best wishes,
Tobias


Marek Szyprowski wrote:
> Dear all,
> 
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
> rotation, scaling, colour space conversion or mix of them. In this proposal
> I named such hardware modules a framebuffer processors.
> 
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling to
> target window size.
> 
> Till now there was no generic, hardware independent API for performing such
> operations. Exynos DRM driver has its own custom extension called IPP
> (Image Post Processing), but frankly speaking, it is over-engineered and not
> really used in open-source. I didn't indentify similar API in other DRM
> drivers, besides those which expose complete support for the whole GPU.
> 
> However, the need for commmon API has been already mentioned on the mailing
> list. Here are some example threads:
> 1. "RFC: hardware accelerated bitblt using dma engine"
> http://www.spinics.net/lists/dri-devel/msg114250.html
> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) 
> subsystem"
> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
> 
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> framebuffer processor (called fbproc for convenience). Such fbproc objects
> have a set of standard DRM properties, which describes the operation to be
> performed by respective hardware module. In typical case those properties
> are a source fb id and rectangle (x, y, width, height) and destination fb
> id and rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
> 
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
>   objects,
> - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
> - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
>   set.
> 
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for example
> blending).
> 
> Please note that this API is intended to be used for simple memory-to-memory
> image processing hardware not the full-blown GPU blitters, which usually
> have more features. Typically blitters provides much more operations beside
> simple pixel copying and operate best if its command queue is controlled from
> respective dedicated code in userspace.
> 
> The patchset consist of 4 parts:
> 1. generic code for DRM core for handling fbproc objects and ioctls
> 2. example, quick conversion of Exynos Rotator driver to fbproc API
> 3. libdrm extensions for handling fbproc objects
> 4. simple example of userspace code for performing 180 degree rotation of the
>framebuffer
> 
> Patches were tested on Exynos 4412-based Odroid U3 board, on top
> of Linux v4.8-rc1 kernel.
> 
> TODO:
> 1. agree on the API shape
> 2. add more documentation, especially to the kernel docs
> 3. add more userspace examples
> 
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
> 
> 
> Marek Szyprowski (2):
>   drm: add support for framebuffer processor objects
>   drm/exynos: register rotator as fbproc instead of custom ipp framework
> 
>  drivers/gpu/drm/Makefile|   3 +-
>  drivers/gpu/drm/drm_atomic.c|   5 +
>  drivers/gpu/drm/drm_crtc.c  |   6 +
>  drivers/gpu/drm/drm_crtc_internal.h |  12 +
>  drivers/gpu/drm/drm_fbproc.c| 754 
> 
>  drivers/gpu/drm/drm_ioctl.c |   3 +
>  drivers/gpu/drm/exynos/Kconfig  |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c | 353 +++--

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Mikko Rapeli]

On Mon, Aug 22, 2016 at 09:48:10AM +0100, Emil Velikov wrote:
> On 20 August 2016 at 23:31, Rob Clark  wrote:
> > On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli  
> > wrote:
> >> Cc'ing lkml too.
> >>
> >> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
> >>> Story time:
> >>> I was dreaming of a day were we can stop installing these headers,
> >>> thus making deprecation a bit easier process.
> >>> Yet after failing to convince Dave and Daniel on a number of occasions
> >>> I've accepted that those headers _are_ here to stay. And yes they
> >>> _are_ the UAPI, even though no applications are meant to use them but
> >>> the libdrm 'version'.
> >>> Thus any changes to the libdrm ones should be a mirror of the ones
> >>> here and libdrm should _not_ differ.
> >>
> >> Another day dream:
> >>
> >> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> >> a simple quality check of compiling in userspace where they are meant to be
> >> used? Stand alone. Without magic tricks and additional libraries and their
> >> headers. Without glibc or any other libc implementation specific additions.
> >> The uapi headers define many parts of the Linux kernel API and ABI, and 
> >> thus
> >> compiling them also without the 'official' GNU/Linux userspace libraries
> >> like glibc or libdrm does have some uses. For example API and ABI
> >> compatibility checks and API/ABI/system call fuzzers.
> >>
> >> Many headers required stdint.h types but Linux kernel headers do not
> >> define them in userspace, and then Linus has said that uapi headers
> >> should use the linux/types.h with double underscores. Thus my patches
> >> for fixing trivial compile errors turned into changing several stdint.h
> >> definitions to linux/types.h.
> >
> > The problem is, for the most part, the driver specific gpu related
> > ioctl interfaces are not intended for general public consumption.
> > They have one consumer, ie. libdrm_$drivername (or perhaps mesa
> > directly).  They are complex interfaces, because GPUs are complex.
> > They are not intended to be used directly (or for the most part, even
> > indirectly) by random userspace applications.  And in fact the uapi
> > headers exported from kernel are not actually ever used.  (ie.
> > libdrm_$drivername uses it's own copy internally within libdrm.)
> >
> > So Linus's argument against stdint types, as weak as it is, doesn't
> > even apply for gpu driver specific ioctls.
> >
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.

Note that drm in not the only kernel subsystem with this wish/requirement.

fuse maintainer has said the same problem and there are others, where
Linux kernel uapi headers come from standards or other external sources.
coda and xen come to my mind due to changes I had to make lately.

> That said, _note_ that some applications are built with -C89 -pedantic
> [1] which means that using stdint.h may or may not work as expected.
> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
> If the affected programs are proprietary ones we should be safe,
> otherwise we want to update them ~alongside the transition.

In the uapi headers side maybe a common kernel subsystem specific compatibility
header could define the policy, e.g.  would include
. In similar way,  and 
would handle fuse and xen policies.  could define the
default policy of  as it is now.

-Mikko

[RFC 0/2] New feature: Framebuffer processors

[Christian König]

Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> Dear all,
>
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
> rotation, scaling, colour space conversion or mix of them. In this proposal
> I named such hardware modules a framebuffer processors.
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling to
> target window size.
>
> Till now there was no generic, hardware independent API for performing such
> operations. Exynos DRM driver has its own custom extension called IPP
> (Image Post Processing), but frankly speaking, it is over-engineered and not
> really used in open-source. I didn't indentify similar API in other DRM
> drivers, besides those which expose complete support for the whole GPU.

Well there are good reasons why we don't have hardware independent 
command submission.

We already tried approaches like this and they didn't worked very well 
and are generally a pain to get right.

So my feeling goes into the direction of a NAK, especially since you 
didn't explained in this mail why there is need for a common API.

Regards,
Christian.

>
> However, the need for commmon API has been already mentioned on the mailing
> list. Here are some example threads:
> 1. "RFC: hardware accelerated bitblt using dma engine"
> http://www.spinics.net/lists/dri-devel/msg114250.html
> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) 
> subsystem"
> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
>
> The proposed API is heavily inspired by atomic KMS approach - it is also
> based on DRM objects and their properties. A new DRM object is introduced:
> framebuffer processor (called fbproc for convenience). Such fbproc objects
> have a set of standard DRM properties, which describes the operation to be
> performed by respective hardware module. In typical case those properties
> are a source fb id and rectangle (x, y, width, height) and destination fb
> id and rectangle. Optionally a rotation property can be also specified if
> supported by the given hardware. To perform an operation on image data,
> userspace provides a set of properties and their values for given fbproc
> object in a similar way as object and properties are provided for
> performing atomic page flip / mode setting.
>
> The proposed API consists of the 3 new ioctls:
> - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
>objects,
> - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
> - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
>set.
>
> The proposed API is extensible. Drivers can attach their own, custom
> properties to add support for more advanced picture processing (for example
> blending).
>
> Please note that this API is intended to be used for simple memory-to-memory
> image processing hardware not the full-blown GPU blitters, which usually
> have more features. Typically blitters provides much more operations beside
> simple pixel copying and operate best if its command queue is controlled from
> respective dedicated code in userspace.
>
> The patchset consist of 4 parts:
> 1. generic code for DRM core for handling fbproc objects and ioctls
> 2. example, quick conversion of Exynos Rotator driver to fbproc API
> 3. libdrm extensions for handling fbproc objects
> 4. simple example of userspace code for performing 180 degree rotation of the
> framebuffer
>
> Patches were tested on Exynos 4412-based Odroid U3 board, on top
> of Linux v4.8-rc1 kernel.
>
> TODO:
> 1. agree on the API shape
> 2. add more documentation, especially to the kernel docs
> 3. add more userspace examples
>
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
>
>
> Marek Szyprowski (2):
>drm: add support for framebuffer processor objects
>drm/exynos: register rotator as fbproc instead of custom ipp framework
>
>   drivers/gpu/drm/Makefile|   3 +-
>   drivers/gpu/drm/drm_atomic.c|   5 +
>   drivers/gpu/drm/drm_crtc.c  |   6 +
>   drivers/gpu/drm/drm_crtc_internal.h |  12 +
>   drivers/gpu/drm/drm_fbproc.c| 754 
> 
>   drivers/gpu/drm/drm_ioctl.c |   3 +
>   drivers/gpu/drm/exynos/Kconfig  |   1 -
>   drivers/gpu/drm/exynos/exynos_drm_drv.c |   3 +-
>   drivers/gpu/drm/exynos/exynos_drm_rotator.c | 353 +++--
>   drivers/gp

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Rob Clark]

On Mon, Aug 22, 2016 at 4:48 AM, Emil Velikov  
wrote:
> On 20 August 2016 at 23:31, Rob Clark  wrote:
>> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli  wrote:
>>> Cc'ing lkml too.
>>>
>>> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
 Story time:
 I was dreaming of a day were we can stop installing these headers,
 thus making deprecation a bit easier process.
 Yet after failing to convince Dave and Daniel on a number of occasions
 I've accepted that those headers _are_ here to stay. And yes they
 _are_ the UAPI, even though no applications are meant to use them but
 the libdrm 'version'.
 Thus any changes to the libdrm ones should be a mirror of the ones
 here and libdrm should _not_ differ.
>>>
>>> Another day dream:
>>>
>>> Wouldn't it be nice if the uapi headers from Linux kernel would pass
>>> a simple quality check of compiling in userspace where they are meant to be
>>> used? Stand alone. Without magic tricks and additional libraries and their
>>> headers. Without glibc or any other libc implementation specific additions.
>>> The uapi headers define many parts of the Linux kernel API and ABI, and thus
>>> compiling them also without the 'official' GNU/Linux userspace libraries
>>> like glibc or libdrm does have some uses. For example API and ABI
>>> compatibility checks and API/ABI/system call fuzzers.
>>>
>>> Many headers required stdint.h types but Linux kernel headers do not
>>> define them in userspace, and then Linus has said that uapi headers
>>> should use the linux/types.h with double underscores. Thus my patches
>>> for fixing trivial compile errors turned into changing several stdint.h
>>> definitions to linux/types.h.
>>
>> The problem is, for the most part, the driver specific gpu related
>> ioctl interfaces are not intended for general public consumption.
>> They have one consumer, ie. libdrm_$drivername (or perhaps mesa
>> directly).  They are complex interfaces, because GPUs are complex.
>> They are not intended to be used directly (or for the most part, even
>> indirectly) by random userspace applications.  And in fact the uapi
>> headers exported from kernel are not actually ever used.  (ie.
>> libdrm_$drivername uses it's own copy internally within libdrm.)
>>
>> So Linus's argument against stdint types, as weak as it is, doesn't
>> even apply for gpu driver specific ioctls.
>>
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.

maybe I didn't grumble loudly enough at the time (against __uX types)

> That said, _note_ that some applications are built with -C89 -pedantic
> [1] which means that using stdint.h may or may not work as expected.
> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
> If the affected programs are proprietary ones we should be safe,
> otherwise we want to update them ~alongside the transition.

naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
-C89.. problem solved!

BR,
-R

> Thanks
> Emil
>
> [1]
> https://cgit.freedesktop.org/mesa/drm/commit/?id=0f4452bb51306024fbf4cbf77d8baab20cefba67
> https://cgit.freedesktop.org/mesa/drm/commit/?id=d20314d083e533e3b8753192b1846752341afbbe

[RFC 0/2] New feature: Framebuffer processors

[Marek Szyprowski]

Dear Tobias


On 2016-08-22 12:07, Tobias Jakobi wrote:
> Hey Marek,
>
> I had a quick look at the series and I really like the new approach.
>
> I was wondering about the following though. If I understand this
> correctly I can only perform m2m operations on buffers which are
> registered as framebuffers. Is this possible to weaken that requirements
> such that arbitrary GEM objects can be used as input and output?

Thanks for you comment.

I'm open for discussion if the API should be based on framebuffers or
GEM objects.

Initially I thought that GEM objects would be enough, but later I
noticed that in such case user would need to provide at least width,
height, stride, start offset and pixel format - all parameters that
are already used to create framebuffer object. Operating on GEM
buffers will also make support for images composed from multiple
buffers (like separate GEM objects for luma/chroma parts in case of
planar formats) a bit harder. Same about already introduced API for
fb-modifiers. I just don't want to duplicate all of it in fbproc API.

Operating on framebuffer objects also helps to reduce errors in
userspace. One can already queue the result of processing to the
display hardware and this way avoid common issues related to debugging
why the processed image is not displayed correctly due to incorrectly
defined pitch/fourcc/start offset/etc. This is however not really a
strong advantage of framebuffers.


>
> Anyway, great work!
>
> With best wishes,
> Tobias
>
>
> Marek Szyprowski wrote:
>> Dear all,
>>
>> This is the initial proposal for extending DRM API with generic support for
>> hardware modules, which can be used for processing image data from the one
>> memory buffer to another. Typical memory-to-memory operations are:
>> rotation, scaling, colour space conversion or mix of them. In this proposal
>> I named such hardware modules a framebuffer processors.
>>
>> Embedded SoCs are known to have a number of hardware blocks, which perform
>> such operations. They can be used in paralel to the main GPU module to
>> offload CPU from processing grapics or video data. One of example use of
>> such modules is implementing video overlay, which usually requires color
>> space conversion from NV12 (or similar) to RGB32 color space and scaling to
>> target window size.
>>
>> Till now there was no generic, hardware independent API for performing such
>> operations. Exynos DRM driver has its own custom extension called IPP
>> (Image Post Processing), but frankly speaking, it is over-engineered and not
>> really used in open-source. I didn't indentify similar API in other DRM
>> drivers, besides those which expose complete support for the whole GPU.
>>
>> However, the need for commmon API has been already mentioned on the mailing
>> list. Here are some example threads:
>> 1. "RFC: hardware accelerated bitblt using dma engine"
>> http://www.spinics.net/lists/dri-devel/msg114250.html
>> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) 
>> subsystem"
>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
>>
>> The proposed API is heavily inspired by atomic KMS approach - it is also
>> based on DRM objects and their properties. A new DRM object is introduced:
>> framebuffer processor (called fbproc for convenience). Such fbproc objects
>> have a set of standard DRM properties, which describes the operation to be
>> performed by respective hardware module. In typical case those properties
>> are a source fb id and rectangle (x, y, width, height) and destination fb
>> id and rectangle. Optionally a rotation property can be also specified if
>> supported by the given hardware. To perform an operation on image data,
>> userspace provides a set of properties and their values for given fbproc
>> object in a similar way as object and properties are provided for
>> performing atomic page flip / mode setting.
>>
>> The proposed API consists of the 3 new ioctls:
>> - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
>>objects,
>> - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
>> - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
>>set.
>>
>> The proposed API is extensible. Drivers can attach their own, custom
>> properties to add support for more advanced picture processing (for example
>> blending).
>>
>> Please note that this API is intended to be used for simple memory-to-memory
>> image processing hardware not the full-blown GPU blitters, which usually
>> have more features. Typically blitters provides much more operations beside
>> simple pixel copying and operate best if its command queue is controlled from
>> respective dedicated code in userspace.
>>
>> The patchset consist of 4 parts:
>> 1. generic code for DRM core for handling fbproc objects and ioctls
>> 2. example, quick conversion of Exynos Rotator driver 

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Lucas Stach]

The GPU may still keep its state when in suspend, which breaks the
assumption that the hardware is in a clean state before the init
routine runs. Make sure to reset the GPU when coming back from
suspend, so this assumption is validated.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index b382cf505262..433d2df0907b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1531,17 +1531,13 @@ static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu 
*gpu)
 #ifdef CONFIG_PM
 static int etnaviv_gpu_hw_resume(struct etnaviv_gpu *gpu)
 {
-   u32 clock;
int ret;

ret = mutex_lock_killable(&gpu->lock);
if (ret)
return ret;

-   clock = VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS |
-   VIVS_HI_CLOCK_CONTROL_FSCALE_VAL(0x40);
-
-   etnaviv_gpu_load_clock(gpu, clock);
+   etnaviv_hw_reset(gpu);
etnaviv_gpu_hw_init(gpu);

gpu->switch_context = true;
-- 
2.8.1

[PATCH 04/18] drm/etnaviv: rename etnaviv_iommu_domain_restore to etnaviv_iommuv1_restore

[Lucas Stach]

This function has external visibility and only handles the Vivant IOMMU
version 1. Rename to make this more clear and allow a clear separation
of the different IOMMU versions.

Also drop the domain parameter, as we can infer it from the GPU we are
dealing with.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 6 +++---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h | 3 +--
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 2306962330a0..f18857e07b8f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -576,7 +576,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_PE, gpu->memory_base);

/* setup the MMU page table pointers */
-   etnaviv_iommu_domain_restore(gpu, gpu->mmu->domain);
+   etnaviv_iommuv1_restore(gpu);

/* Start command processor */
prefetch = etnaviv_buffer_init(gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
index 16353ee81651..35f365f50e18 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -196,10 +196,10 @@ static struct etnaviv_iommu_ops etnaviv_iommu_ops = {
.dump = etnaviv_iommuv1_dump,
 };

-void etnaviv_iommu_domain_restore(struct etnaviv_gpu *gpu,
-   struct iommu_domain *domain)
+void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu)
 {
-   struct etnaviv_iommu_domain *etnaviv_domain = to_etnaviv_domain(domain);
+   struct etnaviv_iommu_domain *etnaviv_domain =
+   to_etnaviv_domain(gpu->mmu->domain);
u32 pgtable;

/* set page table address in MC */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
index cf45503f6b6f..dfb4ba23ce08 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
@@ -21,8 +21,7 @@
 struct etnaviv_gpu;

 struct iommu_domain *etnaviv_iommu_domain_alloc(struct etnaviv_gpu *gpu);
-void etnaviv_iommu_domain_restore(struct etnaviv_gpu *gpu,
-   struct iommu_domain *domain);
+void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu);
 struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu);

 #endif /* __ETNAVIV_IOMMU_H__ */
-- 
2.8.1

[PATCH 00/18] drm/etnaviv: MMUv2 and new hardware support

[Lucas Stach]

Hi all,

this series adds support for the new MMU version 2, found on newer
Vivante cores. The new MMU provides full isolation, with no way for
the GPU to bypass it. This may enable optimizations like skipping
commandstream validation later on. For now we stick with a single
address space for all clients, making the initial implementation
a lot simpler.

With the support for the new MMU in place it is trivial to add
support for the new Vivante cores, found on the i.MX6 QuadPlus.

I've only really tested this series with the 2D core yet, as the
3D userspace needs some changes to work properly on top of the
GC3000 cores. Those are still in the works and will be published
in coming days.

Regards,
Lucas 

Lucas Stach (18):
  drm/etnaviv: reset GPU when coming back from suspend
  drm/etnaviv: only try to use the linear window on MMUv1
  drm/etnaviv: only check if the cmdbuf is inside the linear window on
MMUv1
  drm/etnaviv: rename etnaviv_iommu_domain_restore to
etnaviv_iommuv1_restore
  drm/etnaviv: move linear window setup into etnaviv_iommuv1_restore
  drm/etnaviv: indirect IOMMU restore through etnaviv MMU
  drm/etnaviv: move IOMMU domain allocation into etnaviv MMU
  drm/etnaviv: remove unused iommu_v2 header
  drm/etnaviv: move gpu_va() to etnaviv mmu
  drm/etnaviv: split out wait for gpu idle
  drm/etnaviv: split out FE start
  drm/etnaviv: split out iova search and MMU reaping logic
  drm/etnaviv: map cmdbuf through MMU on version 2
  drm/etnaviv: add function to construct MMUv2 init buffer
  drm/etnaviv: add flushing logic for MMUv2
  drm/etnaviv: handle MMU exception in IRQ handler
  drm/etnaviv: implement IOMMUv2 translation
  drm/etnaviv: fix up model and revision for GC2000+

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c   |  81 +++--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h  |   1 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 137 +++
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h  |   4 +
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c|  15 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h|  10 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 257 -
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h |  25 ---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c  | 144 
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h  |   9 +-
 drivers/gpu/drm/etnaviv/state_hi.xml.h |   9 +-
 11 files changed, 532 insertions(+), 160 deletions(-)
 delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h

-- 
2.8.1

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

[Lucas Stach]

There is no linear window on MMUv2 and the FE can access the full 4GB
address space either directly (as long as the MMU isn't configured) or
through the MMU, once it is up.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 433d2df0907b..2306962330a0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -678,7 +678,9 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
dev_err(gpu->dev, "could not create command buffer\n");
goto destroy_iommu;
}
-   if (gpu->buffer->paddr - gpu->memory_base > 0x8000) {
+
+   if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) &&
+   gpu->buffer->paddr - gpu->memory_base > 0x8000) {
ret = -EINVAL;
dev_err(gpu->dev,
"command buffer outside valid memory window\n");
-- 
2.8.1

[PATCH 02/18] drm/etnaviv: only try to use the linear window on MMUv1

[Lucas Stach]

As the comment above the code states, the linear window is only
available on MMUv1. Don't try to use it on MMUv2.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index 29a723fabc17..e2013b5b3f6a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -115,7 +115,8 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
mutex_lock(&mmu->lock);

/* v1 MMU can optimize single entry (contiguous) scatterlists */
-   if (sgt->nents == 1 && !(etnaviv_obj->flags & ETNA_BO_FORCE_MMU)) {
+   if (mmu->version == ETNAVIV_IOMMU_V1 &&
+   sgt->nents == 1 && !(etnaviv_obj->flags & ETNA_BO_FORCE_MMU)) {
u32 iova;

iova = sg_dma_address(sgt->sgl) - memory_base;
-- 
2.8.1

[PATCH 07/18] drm/etnaviv: move IOMMU domain allocation into etnaviv MMU

[Lucas Stach]

The GPU code doesn't need to deal with the IOMMU directly, instead
it can all be hidden behind the etnaviv mmu interface. Move the
last remaining part into etnaviv mmu.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 33 +++---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c|  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h|  4 ++--
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c  | 28 ++---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h  |  3 +--
 6 files changed, 29 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 759be57fe7eb..8bca6ad4501f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -22,8 +22,6 @@
 #include "etnaviv_gpu.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_mmu.h"
-#include "etnaviv_iommu.h"
-#include "etnaviv_iommu_v2.h"
 #include "common.xml.h"
 #include "state.xml.h"
 #include "state_hi.xml.h"
@@ -585,9 +583,6 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
 int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
 {
int ret, i;
-   struct iommu_domain *iommu;
-   enum etnaviv_iommu_version version;
-   bool mmuv2;

ret = pm_runtime_get_sync(gpu->dev);
if (ret < 0) {
@@ -635,32 +630,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}

-   /* Setup IOMMU.. eventually we will (I think) do this once per context
-* and have separate page tables per context.  For now, to keep things
-* simple and to get something working, just use a single address space:
-*/
-   mmuv2 = gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION;
-   dev_dbg(gpu->dev, "mmuv2: %d\n", mmuv2);
-
-   if (!mmuv2) {
-   iommu = etnaviv_iommu_domain_alloc(gpu);
-   version = ETNAVIV_IOMMU_V1;
-   } else {
-   iommu = etnaviv_iommu_v2_domain_alloc(gpu);
-   version = ETNAVIV_IOMMU_V2;
-   }
-
-   if (!iommu) {
-   dev_err(gpu->dev, "Failed to allocate GPU IOMMU domain\n");
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   gpu->mmu = etnaviv_iommu_new(gpu, iommu, version);
-   if (!gpu->mmu) {
+   gpu->mmu = etnaviv_iommu_new(gpu);
+   if (IS_ERR(gpu->mmu)) {
dev_err(gpu->dev, "Failed to instantiate GPU IOMMU\n");
-   iommu_domain_free(iommu);
-   ret = -ENOMEM;
+   ret = PTR_ERR(gpu->mmu);
goto fail;
}

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
index 912a290a4e9c..81f1583a7946 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -219,7 +219,7 @@ void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_MC_MMU_RA_PAGE_TABLE, pgtable);
 }

-struct iommu_domain *etnaviv_iommu_domain_alloc(struct etnaviv_gpu *gpu)
+struct iommu_domain *etnaviv_iommuv1_domain_alloc(struct etnaviv_gpu *gpu)
 {
struct etnaviv_iommu_domain *etnaviv_domain;
int ret;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
index dfb4ba23ce08..4b6212999c1e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
@@ -20,8 +20,8 @@
 #include 
 struct etnaviv_gpu;

-struct iommu_domain *etnaviv_iommu_domain_alloc(struct etnaviv_gpu *gpu);
+struct iommu_domain *etnaviv_iommuv1_domain_alloc(struct etnaviv_gpu *gpu);
 void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu);
-struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu);
+struct iommu_domain *etnaviv_iommuv2_domain_alloc(struct etnaviv_gpu *gpu);

 #endif /* __ETNAVIV_IOMMU_H__ */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index fbb4aed3dc80..8c913c83ac5e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -26,7 +26,7 @@
 #include "state_hi.xml.h"


-struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu)
+struct iommu_domain *etnaviv_iommuv2_domain_alloc(struct etnaviv_gpu *gpu)
 {
/* TODO */
return NULL;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index 55d4229f6932..e744c6d81a2d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -14,6 +14,7 @@
  * this program.  If not, see .
  */

+#include "common.xml.h"
 #include "etnaviv_drv.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_gpu.h"
@@ -258,26 +259,39 @@ void etnaviv_iommu_destroy(struct etnaviv_iommu *mmu)
kfree(mmu);
 }

-struct etnaviv_iommu *etnaviv_iommu_new(struct etnaviv_g

[PATCH 06/18] drm/etnaviv: indirect IOMMU restore through etnaviv MMU

[Lucas Stach]

So we can call the v2 restore code once it is there.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 9 +
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 988b59f66569..759be57fe7eb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -569,7 +569,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
}

/* setup the MMU */
-   etnaviv_iommuv1_restore(gpu);
+   etnaviv_iommu_restore(gpu);

/* Start command processor */
prefetch = etnaviv_buffer_init(gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index e2013b5b3f6a..55d4229f6932 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -17,6 +17,7 @@
 #include "etnaviv_drv.h"
 #include "etnaviv_gem.h"
 #include "etnaviv_gpu.h"
+#include "etnaviv_iommu.h"
 #include "etnaviv_mmu.h"

 static int etnaviv_fault_handler(struct iommu_domain *iommu, struct device 
*dev,
@@ -281,6 +282,14 @@ struct etnaviv_iommu *etnaviv_iommu_new(struct etnaviv_gpu 
*gpu,
return mmu;
 }

+void etnaviv_iommu_restore(struct etnaviv_gpu *gpu)
+{
+   if (gpu->mmu->version == ETNAVIV_IOMMU_V1)
+   etnaviv_iommuv1_restore(gpu);
+   else
+   dev_err(gpu->dev, "IOMMUv2 restore not implemented\n");
+}
+
 size_t etnaviv_iommu_dump_size(struct etnaviv_iommu *iommu)
 {
struct etnaviv_iommu_ops *ops;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
index fff215a47630..dea1314fc44e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -67,5 +67,6 @@ void etnaviv_iommu_dump(struct etnaviv_iommu *iommu, void 
*buf);

 struct etnaviv_iommu *etnaviv_iommu_new(struct etnaviv_gpu *gpu,
struct iommu_domain *domain, enum etnaviv_iommu_version version);
+void etnaviv_iommu_restore(struct etnaviv_gpu *gpu);

 #endif /* __ETNAVIV_MMU_H__ */
-- 
2.8.1

[PATCH 10/18] drm/etnaviv: split out wait for gpu idle

[Lucas Stach]

Split out into a new externally visible function, as the IOMMUv2
code needs this functionality, too.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 40 +++
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  1 +
 2 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 3b8c56d4c943..46b1775969c9 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1462,11 +1462,30 @@ static int etnaviv_gpu_clk_disable(struct etnaviv_gpu 
*gpu)
return 0;
 }

+int etnaviv_gpu_wait_idle(struct etnaviv_gpu *gpu, unsigned int timeout_ms)
+{
+   unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
+
+   do {
+   u32 idle = gpu_read(gpu, VIVS_HI_IDLE_STATE);
+
+   if ((idle & gpu->idle_mask) == gpu->idle_mask)
+   return 0;
+
+   if (time_is_before_jiffies(timeout)) {
+   dev_warn(gpu->dev,
+"timed out waiting for idle: idle=0x%x\n",
+idle);
+   return -ETIMEDOUT;
+   }
+
+   udelay(5);
+   } while (1);
+}
+
 static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu *gpu)
 {
if (gpu->buffer) {
-   unsigned long timeout;
-
/* Replace the last WAIT with END */
etnaviv_buffer_end(gpu);

@@ -1475,22 +1494,7 @@ static int etnaviv_gpu_hw_suspend(struct etnaviv_gpu 
*gpu)
 * happen quickly (as the WAIT is only 200 cycles).  If
 * we fail, just warn and continue.
 */
-   timeout = jiffies + msecs_to_jiffies(100);
-   do {
-   u32 idle = gpu_read(gpu, VIVS_HI_IDLE_STATE);
-
-   if ((idle & gpu->idle_mask) == gpu->idle_mask)
-   break;
-
-   if (time_is_before_jiffies(timeout)) {
-   dev_warn(gpu->dev,
-"timed out waiting for idle: 
idle=0x%x\n",
-idle);
-   break;
-   }
-
-   udelay(5);
-   } while (1);
+   etnaviv_gpu_wait_idle(gpu, 100);
}

return etnaviv_gpu_clk_disable(gpu);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index a69cdd526bf8..303450b1f981 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -214,6 +214,7 @@ struct etnaviv_cmdbuf *etnaviv_gpu_cmdbuf_new(struct 
etnaviv_gpu *gpu,
 void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf);
 int etnaviv_gpu_pm_get_sync(struct etnaviv_gpu *gpu);
 void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu);
+int etnaviv_gpu_wait_idle(struct etnaviv_gpu *gpu, unsigned int timeout_ms);

 extern struct platform_driver etnaviv_gpu_driver;

-- 
2.8.1

[PATCH 12/18] drm/etnaviv: split out iova search and MMU reaping logic

[Lucas Stach]

With MMUv2 the command buffers need to be mapped through the MMU.
Split out the iova search and MMU reaping logic so it can be reused
for the cmdbuf mapping, where no GEM object is involved.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 62 +--
 1 file changed, 37 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index d62125eb30d8..69ea0a0a70c2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -103,41 +103,21 @@ static void etnaviv_iommu_remove_mapping(struct 
etnaviv_iommu *mmu,
drm_mm_remove_node(&mapping->vram_node);
 }

-int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
-   struct etnaviv_gem_object *etnaviv_obj, u32 memory_base,
-   struct etnaviv_vram_mapping *mapping)
+static int etnaviv_iommu_find_iova(struct etnaviv_iommu *mmu,
+  struct drm_mm_node *node, size_t size)
 {
struct etnaviv_vram_mapping *free = NULL;
-   struct sg_table *sgt = etnaviv_obj->sgt;
-   struct drm_mm_node *node;
int ret;

-   lockdep_assert_held(&etnaviv_obj->lock);
-
-   mutex_lock(&mmu->lock);
+   lockdep_assert_held(&mmu->lock);

-   /* v1 MMU can optimize single entry (contiguous) scatterlists */
-   if (mmu->version == ETNAVIV_IOMMU_V1 &&
-   sgt->nents == 1 && !(etnaviv_obj->flags & ETNA_BO_FORCE_MMU)) {
-   u32 iova;
-
-   iova = sg_dma_address(sgt->sgl) - memory_base;
-   if (iova < 0x8000 - sg_dma_len(sgt->sgl)) {
-   mapping->iova = iova;
-   list_add_tail(&mapping->mmu_node, &mmu->mappings);
-   mutex_unlock(&mmu->lock);
-   return 0;
-   }
-   }
-
-   node = &mapping->vram_node;
while (1) {
struct etnaviv_vram_mapping *m, *n;
struct list_head list;
bool found;

ret = drm_mm_insert_node_in_range(&mmu->mm, node,
-   etnaviv_obj->base.size, 0, mmu->last_iova, ~0UL,
+   size, 0, mmu->last_iova, ~0UL,
DRM_MM_SEARCH_DEFAULT);

if (ret != -ENOSPC)
@@ -154,7 +134,7 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
}

/* Try to retire some entries */
-   drm_mm_init_scan(&mmu->mm, etnaviv_obj->base.size, 0, 0);
+   drm_mm_init_scan(&mmu->mm, size, 0, 0);

found = 0;
INIT_LIST_HEAD(&list);
@@ -215,6 +195,38 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
mmu->need_flush = true;
}

+   return ret;
+}
+
+int etnaviv_iommu_map_gem(struct etnaviv_iommu *mmu,
+   struct etnaviv_gem_object *etnaviv_obj, u32 memory_base,
+   struct etnaviv_vram_mapping *mapping)
+{
+   struct sg_table *sgt = etnaviv_obj->sgt;
+   struct drm_mm_node *node;
+   int ret;
+
+   lockdep_assert_held(&etnaviv_obj->lock);
+
+   mutex_lock(&mmu->lock);
+
+   /* v1 MMU can optimize single entry (contiguous) scatterlists */
+   if (mmu->version == ETNAVIV_IOMMU_V1 &&
+   sgt->nents == 1 && !(etnaviv_obj->flags & ETNA_BO_FORCE_MMU)) {
+   u32 iova;
+
+   iova = sg_dma_address(sgt->sgl) - memory_base;
+   if (iova < 0x8000 - sg_dma_len(sgt->sgl)) {
+   mapping->iova = iova;
+   list_add_tail(&mapping->mmu_node, &mmu->mappings);
+   mutex_unlock(&mmu->lock);
+   return 0;
+   }
+   }
+
+   node = &mapping->vram_node;
+
+   ret = etnaviv_iommu_find_iova(mmu, node, etnaviv_obj->base.size);
if (ret < 0) {
mutex_unlock(&mmu->lock);
return ret;
-- 
2.8.1

[PATCH 11/18] drm/etnaviv: split out FE start

[Lucas Stach]

Split out into a new externally visible function, as the IOMMUv2
code needs this functionality, too.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  1 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 46b1775969c9..fe541a3cdc10 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -526,6 +526,14 @@ static void etnaviv_gpu_enable_mlcg(struct etnaviv_gpu 
*gpu)
gpu_write(gpu, VIVS_PM_MODULE_CONTROLS, pmc);
 }

+void etnaviv_gpu_start_fe(struct etnaviv_gpu *gpu, u32 address, u16 prefetch)
+{
+   gpu_write(gpu, VIVS_FE_COMMAND_ADDRESS, address);
+   gpu_write(gpu, VIVS_FE_COMMAND_CONTROL,
+ VIVS_FE_COMMAND_CONTROL_ENABLE |
+ VIVS_FE_COMMAND_CONTROL_PREFETCH(prefetch));
+}
+
 static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
 {
u16 prefetch;
@@ -573,11 +581,8 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
prefetch = etnaviv_buffer_init(gpu);

gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
-   gpu_write(gpu, VIVS_FE_COMMAND_ADDRESS,
- etnaviv_iommu_get_cmdbuf_va(gpu, gpu->buffer));
-   gpu_write(gpu, VIVS_FE_COMMAND_CONTROL,
- VIVS_FE_COMMAND_CONTROL_ENABLE |
- VIVS_FE_COMMAND_CONTROL_PREFETCH(prefetch));
+   etnaviv_gpu_start_fe(gpu, etnaviv_iommu_get_cmdbuf_va(gpu, gpu->buffer),
+prefetch);
 }

 int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 303450b1f981..7a10a9c32a70 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -215,6 +215,7 @@ void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf);
 int etnaviv_gpu_pm_get_sync(struct etnaviv_gpu *gpu);
 void etnaviv_gpu_pm_put(struct etnaviv_gpu *gpu);
 int etnaviv_gpu_wait_idle(struct etnaviv_gpu *gpu, unsigned int timeout_ms);
+void etnaviv_gpu_start_fe(struct etnaviv_gpu *gpu, u32 address, u16 prefetch);

 extern struct platform_driver etnaviv_gpu_driver;

-- 
2.8.1

[PATCH 13/18] drm/etnaviv: map cmdbuf through MMU on version 2

[Lucas Stach]

With MMUv2 all buffers need to be mapped through the MMU once it
is enabled. Align the buffer size to 4K, as the MMU is only able to
map page aligned buffers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c |  4 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  2 ++
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 42 ++-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h |  2 ++
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index fe541a3cdc10..4c706438c7c8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1151,6 +1151,9 @@ struct etnaviv_cmdbuf *etnaviv_gpu_cmdbuf_new(struct 
etnaviv_gpu *gpu, u32 size,
if (!cmdbuf)
return NULL;

+   if (gpu->mmu->version == ETNAVIV_IOMMU_V2)
+   size = ALIGN(size, SZ_4K);
+
cmdbuf->vaddr = dma_alloc_wc(gpu->dev, size, &cmdbuf->paddr,
 GFP_KERNEL);
if (!cmdbuf->vaddr) {
@@ -1166,6 +1169,7 @@ struct etnaviv_cmdbuf *etnaviv_gpu_cmdbuf_new(struct 
etnaviv_gpu *gpu, u32 size,

 void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf)
 {
+   etnaviv_iommu_put_cmdbuf_va(cmdbuf->gpu, cmdbuf);
dma_free_wc(cmdbuf->gpu->dev, cmdbuf->size, cmdbuf->vaddr,
cmdbuf->paddr);
kfree(cmdbuf);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 7a10a9c32a70..73c278dc3706 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -160,6 +160,8 @@ struct etnaviv_cmdbuf {
dma_addr_t paddr;
u32 size;
u32 user_size;
+   /* vram node used if the cmdbuf is mapped through the MMUv2 */
+   struct drm_mm_node vram_node;
/* fence after which this buffer is to be disposed */
struct fence *fence;
/* target exec state */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index 69ea0a0a70c2..98c84ef862c7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -319,9 +319,49 @@ void etnaviv_iommu_restore(struct etnaviv_gpu *gpu)
 u32 etnaviv_iommu_get_cmdbuf_va(struct etnaviv_gpu *gpu,
struct etnaviv_cmdbuf *buf)
 {
-   return buf->paddr - gpu->memory_base;
+   struct etnaviv_iommu *mmu = gpu->mmu;
+
+   if (mmu->version == ETNAVIV_IOMMU_V1) {
+   return buf->paddr - gpu->memory_base;
+   } else {
+   int ret;
+
+   if (buf->vram_node.allocated)
+   return (u32)buf->vram_node.start;
+
+   mutex_lock(&mmu->lock);
+   ret = etnaviv_iommu_find_iova(mmu, &buf->vram_node, buf->size);
+   if (ret < 0) {
+   mutex_unlock(&mmu->lock);
+   return 0;
+   }
+   ret = iommu_map(mmu->domain, buf->vram_node.start, buf->paddr,
+   buf->size, IOMMU_READ);
+   if (ret < 0) {
+   drm_mm_remove_node(&buf->vram_node);
+   mutex_unlock(&mmu->lock);
+   return 0;
+   }
+   mmu->last_iova = buf->vram_node.start + buf->size;
+   gpu->mmu->need_flush = true;
+   mutex_unlock(&mmu->lock);
+
+   return (u32)buf->vram_node.start;
+   }
 }

+void etnaviv_iommu_put_cmdbuf_va(struct etnaviv_gpu *gpu,
+struct etnaviv_cmdbuf *buf)
+{
+   struct etnaviv_iommu *mmu = gpu->mmu;
+
+   if (mmu->version == ETNAVIV_IOMMU_V2 && buf->vram_node.allocated) {
+   mutex_lock(&mmu->lock);
+   iommu_unmap(mmu->domain, buf->vram_node.start, buf->size);
+   drm_mm_remove_node(&buf->vram_node);
+   mutex_unlock(&mmu->lock);
+   }
+}
 size_t etnaviv_iommu_dump_size(struct etnaviv_iommu *iommu)
 {
struct etnaviv_iommu_ops *ops;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
index 0d34325a318a..e787e49c9693 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -64,6 +64,8 @@ void etnaviv_iommu_destroy(struct etnaviv_iommu *iommu);

 u32 etnaviv_iommu_get_cmdbuf_va(struct etnaviv_gpu *gpu,
struct etnaviv_cmdbuf *buf);
+void etnaviv_iommu_put_cmdbuf_va(struct etnaviv_gpu *gpu,
+struct etnaviv_cmdbuf *buf);

 size_t etnaviv_iommu_dump_size(struct etnaviv_iommu *iommu);
 void etnaviv_iommu_dump(struct etnaviv_iommu *iommu, void *buf);
-- 
2.8.1

[PATCH 15/18] drm/etnaviv: add flushing logic for MMUv2

[Lucas Stach]

Flushing works differently on MMUv2, in that it's only necessary
to set a single bit in the control register to flush all translation
units. A semaphore stall then makes sure that the flush has propagated
properly.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 47b93427fecb..cb86c7e5495c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -276,8 +276,12 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
unsigned int event,
extra_dwords = 1;

/* flush command */
-   if (gpu->mmu->need_flush)
-   extra_dwords += 1;
+   if (gpu->mmu->need_flush) {
+   if (gpu->mmu->version == ETNAVIV_IOMMU_V1)
+   extra_dwords += 1;
+   else
+   extra_dwords += 3;
+   }

/* pipe switch commands */
if (gpu->switch_context)
@@ -287,12 +291,23 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, 
unsigned int event,

if (gpu->mmu->need_flush) {
/* Add the MMU flush */
-   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_MMU,
-  VIVS_GL_FLUSH_MMU_FLUSH_FEMMU |
-  VIVS_GL_FLUSH_MMU_FLUSH_UNK1 |
-  VIVS_GL_FLUSH_MMU_FLUSH_UNK2 |
-  VIVS_GL_FLUSH_MMU_FLUSH_PEMMU |
-  VIVS_GL_FLUSH_MMU_FLUSH_UNK4);
+   if (gpu->mmu->version == ETNAVIV_IOMMU_V1) {
+   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_MMU,
+  VIVS_GL_FLUSH_MMU_FLUSH_FEMMU |
+  VIVS_GL_FLUSH_MMU_FLUSH_UNK1 |
+  VIVS_GL_FLUSH_MMU_FLUSH_UNK2 |
+  VIVS_GL_FLUSH_MMU_FLUSH_PEMMU |
+  VIVS_GL_FLUSH_MMU_FLUSH_UNK4);
+   } else {
+   CMD_LOAD_STATE(buffer, VIVS_MMUv2_CONFIGURATION,
+   VIVS_MMUv2_CONFIGURATION_MODE_MASK |
+   VIVS_MMUv2_CONFIGURATION_ADDRESS_MASK |
+   VIVS_MMUv2_CONFIGURATION_FLUSH_FLUSH);
+   CMD_SEM(buffer, SYNC_RECIPIENT_FE,
+   SYNC_RECIPIENT_PE);
+   CMD_STALL(buffer, SYNC_RECIPIENT_FE,
+   SYNC_RECIPIENT_PE);
+   }

gpu->mmu->need_flush = false;
}
-- 
2.8.1

[PATCH 18/18] drm/etnaviv: fix up model and revision for GC2000+

[Lucas Stach]

GC2000+ on the i.MX6QP is just a re-branded GC3000, lets call it by
its real name to avoid confusion in other parts of the driver.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 923f6c78e1af..267c65b2f2d7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -327,6 +327,18 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
gpu->identity.revision = 0x1051;
}
}
+
+   /*
+* NXP likes to call the GPU on the i.MX6QP GC2000+, but in
+* reality it's just a re-branded GC3000. We can identify this
+* core by the upper half of the revision register being all 1.
+* Fix model/rev here, so all other places can refer to this
+* core by its real identity.
+*/
+   if (etnaviv_is_model_rev(gpu, GC2000, 0x5450)) {
+   gpu->identity.model = chipModel_GC3000;
+   gpu->identity.revision &= 0x;
+   }
}

dev_info(gpu->dev, "model: GC%x, revision: %x\n",
-- 
2.8.1

[PATCH 05/18] drm/etnaviv: move linear window setup into etnaviv_iommuv1_restore

[Lucas Stach]

It is only relevant for the V1 MMU, so we should not do this in the
common code.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c   | 9 +
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 7 +++
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index f18857e07b8f..988b59f66569 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -568,14 +568,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)
gpu_write(gpu, VIVS_MC_BUS_CONFIG, bus_config);
}

-   /* set base addresses */
-   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_RA, gpu->memory_base);
-   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_FE, gpu->memory_base);
-   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_TX, gpu->memory_base);
-   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_PEZ, gpu->memory_base);
-   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_PE, gpu->memory_base);
-
-   /* setup the MMU page table pointers */
+   /* setup the MMU */
etnaviv_iommuv1_restore(gpu);

/* Start command processor */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
index 35f365f50e18..912a290a4e9c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -202,6 +202,13 @@ void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu)
to_etnaviv_domain(gpu->mmu->domain);
u32 pgtable;

+   /* set base addresses */
+   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_RA, gpu->memory_base);
+   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_FE, gpu->memory_base);
+   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_TX, gpu->memory_base);
+   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_PEZ, gpu->memory_base);
+   gpu_write(gpu, VIVS_MC_MEMORY_BASE_ADDR_PE, gpu->memory_base);
+
/* set page table address in MC */
pgtable = (u32)etnaviv_domain->pgtable.paddr;

-- 
2.8.1

[PATCH 14/18] drm/etnaviv: add function to construct MMUv2 init buffer

[Lucas Stach]

Both the safe/scratch address and the master TLB address are per pipe
with the CPU mapped registers not properly propagating to the
different translation units.

The only way to correctly configure all translation units is to have
a command stream snipped executed by the FE, before any other execution
can start.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 34 
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 +
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 46d13f49883e..47b93427fecb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -21,6 +21,7 @@

 #include "common.xml.h"
 #include "state.xml.h"
+#include "state_hi.xml.h"
 #include "state_3d.xml.h"
 #include "cmdstream.xml.h"

@@ -174,6 +175,39 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
return buffer->user_size / 8;
 }

+u16 etnaviv_buffer_config_mmuv2(struct etnaviv_gpu *gpu, u32 mtlb_addr, u32 
safe_addr)
+{
+   struct etnaviv_cmdbuf *buffer = gpu->buffer;
+
+   buffer->user_size = 0;
+
+   if (gpu->identity.features & chipFeatures_PIPE_3D) {
+   CMD_LOAD_STATE(buffer, VIVS_GL_PIPE_SELECT,
+  VIVS_GL_PIPE_SELECT_PIPE(ETNA_PIPE_3D));
+   CMD_LOAD_STATE(buffer, VIVS_MMUv2_CONFIGURATION,
+   mtlb_addr | VIVS_MMUv2_CONFIGURATION_MODE_MODE4_K);
+   CMD_LOAD_STATE(buffer, VIVS_MMUv2_SAFE_ADDRESS, safe_addr);
+   CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+   CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+   }
+
+   if (gpu->identity.features & chipFeatures_PIPE_2D) {
+   CMD_LOAD_STATE(buffer, VIVS_GL_PIPE_SELECT,
+  VIVS_GL_PIPE_SELECT_PIPE(ETNA_PIPE_2D));
+   CMD_LOAD_STATE(buffer, VIVS_MMUv2_CONFIGURATION,
+   mtlb_addr | VIVS_MMUv2_CONFIGURATION_MODE_MODE4_K);
+   CMD_LOAD_STATE(buffer, VIVS_MMUv2_SAFE_ADDRESS, safe_addr);
+   CMD_SEM(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+   CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+   }
+
+   CMD_END(buffer);
+
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   return buffer->user_size / 8;
+}
+
 void etnaviv_buffer_end(struct etnaviv_gpu *gpu)
 {
struct etnaviv_cmdbuf *buffer = gpu->buffer;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 115c5bc6d7c8..65e057639653 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -96,6 +96,7 @@ struct drm_gem_object *etnaviv_gem_new(struct drm_device *dev,
 int etnaviv_gem_new_userptr(struct drm_device *dev, struct drm_file *file,
uintptr_t ptr, u32 size, u32 flags, u32 *handle);
 u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu);
+u16 etnaviv_buffer_config_mmuv2(struct etnaviv_gpu *gpu, u32 mtlb_addr, u32 
safe_addr);
 void etnaviv_buffer_end(struct etnaviv_gpu *gpu);
 void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int event,
struct etnaviv_cmdbuf *cmdbuf);
-- 
2.8.1

[PATCH 08/18] drm/etnaviv: remove unused iommu_v2 header

[Lucas Stach]

This has been there from the original merge, but has never been used.
Get rid of it.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h | 25 -
 1 file changed, 25 deletions(-)
 delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h
deleted file mode 100644
index 603ea41c5389..
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * Copyright (C) 2014 Christian Gmeiner 
-  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#ifndef __ETNAVIV_IOMMU_V2_H__
-#define __ETNAVIV_IOMMU_V2_H__
-
-#include 
-struct etnaviv_gpu;
-
-struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu);
-
-#endif /* __ETNAVIV_IOMMU_V2_H__ */
-- 
2.8.1

[PATCH 09/18] drm/etnaviv: move gpu_va() to etnaviv mmu

[Lucas Stach]

The GPU virtual address for the command buffers differs depending on
the IOMMU version. Move the calculation of the iova into etnaviv
mmu, to enable proper dispatch.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 16 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c|  6 ++
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h|  3 +++
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index d8d556457427..46d13f49883e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -117,11 +117,6 @@ static void etnaviv_cmd_select_pipe(struct etnaviv_gpu 
*gpu,
   VIVS_GL_PIPE_SELECT_PIPE(pipe));
 }

-static u32 gpu_va(struct etnaviv_gpu *gpu, struct etnaviv_cmdbuf *buf)
-{
-   return buf->paddr - gpu->memory_base;
-}
-
 static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
struct etnaviv_cmdbuf *buf, u32 off, u32 len)
 {
@@ -129,7 +124,7 @@ static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
u32 *ptr = buf->vaddr + off;

dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
-   ptr, gpu_va(gpu, buf) + off, size - len * 4 - off);
+   ptr, etnaviv_iommu_get_cmdbuf_va(gpu, buf) + off, size 
- len * 4 - off);

print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
ptr, len * 4, 0);
@@ -162,7 +157,7 @@ static u32 etnaviv_buffer_reserve(struct etnaviv_gpu *gpu,
if (buffer->user_size + cmd_dwords * sizeof(u64) > buffer->size)
buffer->user_size = 0;

-   return gpu_va(gpu, buffer) + buffer->user_size;
+   return etnaviv_iommu_get_cmdbuf_va(gpu, buffer) + buffer->user_size;
 }

 u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
@@ -173,7 +168,8 @@ u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu)
buffer->user_size = 0;

CMD_WAIT(buffer);
-   CMD_LINK(buffer, 2, gpu_va(gpu, buffer) + buffer->user_size - 4);
+   CMD_LINK(buffer, 2, etnaviv_iommu_get_cmdbuf_va(gpu, buffer) +
+buffer->user_size - 4);

return buffer->user_size / 8;
 }
@@ -231,7 +227,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned 
int event,
if (drm_debug & DRM_UT_DRIVER)
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);

-   link_target = gpu_va(gpu, cmdbuf);
+   link_target = etnaviv_iommu_get_cmdbuf_va(gpu, cmdbuf);
link_dwords = cmdbuf->size / 8;

/*
@@ -301,7 +297,7 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned 
int event,

if (drm_debug & DRM_UT_DRIVER)
pr_info("stream link to 0x%08x @ 0x%08x %p\n",
-   return_target, gpu_va(gpu, cmdbuf), cmdbuf->vaddr);
+   return_target, etnaviv_iommu_get_cmdbuf_va(gpu, 
cmdbuf), cmdbuf->vaddr);

if (drm_debug & DRM_UT_DRIVER) {
print_hex_dump(KERN_INFO, "cmd ", DUMP_PREFIX_OFFSET, 16, 4,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 8bca6ad4501f..3b8c56d4c943 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -574,7 +574,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu)

gpu_write(gpu, VIVS_HI_INTR_ENBL, ~0U);
gpu_write(gpu, VIVS_FE_COMMAND_ADDRESS,
- gpu->buffer->paddr - gpu->memory_base);
+ etnaviv_iommu_get_cmdbuf_va(gpu, gpu->buffer));
gpu_write(gpu, VIVS_FE_COMMAND_CONTROL,
  VIVS_FE_COMMAND_CONTROL_ENABLE |
  VIVS_FE_COMMAND_CONTROL_PREFETCH(prefetch));
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index e744c6d81a2d..d62125eb30d8 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -304,6 +304,12 @@ void etnaviv_iommu_restore(struct etnaviv_gpu *gpu)
dev_err(gpu->dev, "IOMMUv2 restore not implemented\n");
 }

+u32 etnaviv_iommu_get_cmdbuf_va(struct etnaviv_gpu *gpu,
+   struct etnaviv_cmdbuf *buf)
+{
+   return buf->paddr - gpu->memory_base;
+}
+
 size_t etnaviv_iommu_dump_size(struct etnaviv_iommu *iommu)
 {
struct etnaviv_iommu_ops *ops;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
index 70ff1e46717d..0d34325a318a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.h
@@ -62,6 +62,9 @@ void etnaviv_iommu_unmap_gem(struct etnaviv_iommu *mmu,
struct etnaviv_vram_mapping *mapping);
 void etnaviv_iommu_destroy(struct etnaviv_iommu *iommu);

+u32 etnaviv_iommu_get_cmdbuf_va(struct etnaviv_gpu *gpu,
+   struct etnaviv_cmdbuf *buf);
+
 size_t etnaviv_iommu_dump_siz

[PATCH 16/18] drm/etnaviv: handle MMU exception in IRQ handler

[Lucas Stach]

Bit 30 of the interrupt status signals an MMU exception. Handle this
condition properly and dump some useful registers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 12 
 drivers/gpu/drm/etnaviv/state_hi.xml.h |  9 +
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 4c706438c7c8..923f6c78e1af 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1402,6 +1402,18 @@ static irqreturn_t irq_handler(int irq, void *data)
intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR;
}

+   if (intr & VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION) {
+   int i;
+
+   dev_err(gpu->dev, "MMU fault status 0x%08x\n",
+   gpu_read(gpu, VIVS_MMUv2_STATUS));
+   for (i = 0; i < 4; i++)
+   dev_err(gpu->dev, "MMU %d fault addr 0x%08x\n",
+   i, gpu_read(gpu,
+   VIVS_MMUv2_EXCEPTION_ADDR(i)));
+   intr &= ~VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION;
+   }
+
while ((event = ffs(intr)) != 0) {
struct fence *fence;

diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h 
b/drivers/gpu/drm/etnaviv/state_hi.xml.h
index 807a3d9e0dd5..43c73e2ed34f 100644
--- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
+++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
@@ -8,10 +8,10 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
 git clone git://0x04.net/rules-ng-ng

 The rules-ng-ng source files this header was generated from are:
-- state_hi.xml (  24309 bytes, from 2015-12-12 09:02:53)
-- common.xml   (  18437 bytes, from 2015-12-12 09:02:53)
+- state_hi.xml (  25620 bytes, from 2016-08-19 22:07:37)
+- common.xml   (  20583 bytes, from 2016-06-07 05:22:38)

-Copyright (C) 2015
+Copyright (C) 2016
 */


@@ -78,9 +78,10 @@ Copyright (C) 2015
 #define VIVS_HI_AXI_STATUS_DET_RD_ERR  0x0200

 #define VIVS_HI_INTR_ACKNOWLEDGE   0x0010
-#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
0x7fff
+#define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK
0x3fff
 #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT   0
 #define VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC(x)   (((x) << 
VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__SHIFT) & 
VIVS_HI_INTR_ACKNOWLEDGE_INTR_VEC__MASK)
+#define VIVS_HI_INTR_ACKNOWLEDGE_MMU_EXCEPTION 0x4000
 #define VIVS_HI_INTR_ACKNOWLEDGE_AXI_BUS_ERROR 0x8000

 #define VIVS_HI_INTR_ENBL  0x0014
-- 
2.8.1

[PATCH 17/18] drm/etnaviv: implement IOMMUv2 translation

[Lucas Stach]

All other parts are now in place, so implement the actual translation
step and hook it up, so the driver claims support for cores with
the new MMU.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h|   3 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 255 -
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c  |   2 +-
 3 files changed, 256 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
index 4b6212999c1e..8b51e7c16feb 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.h
@@ -17,11 +17,12 @@
 #ifndef __ETNAVIV_IOMMU_H__
 #define __ETNAVIV_IOMMU_H__

-#include 
 struct etnaviv_gpu;

 struct iommu_domain *etnaviv_iommuv1_domain_alloc(struct etnaviv_gpu *gpu);
 void etnaviv_iommuv1_restore(struct etnaviv_gpu *gpu);
+
 struct iommu_domain *etnaviv_iommuv2_domain_alloc(struct etnaviv_gpu *gpu);
+void etnaviv_iommuv2_restore(struct etnaviv_gpu *gpu);

 #endif /* __ETNAVIV_IOMMU_H__ */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 8c913c83ac5e..dea2e8c8b8a0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2014 Christian Gmeiner 
+ * Copyright (C) 2016 Etnaviv Project
   *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2 as published by
@@ -22,12 +22,263 @@
 #include 

 #include "etnaviv_gpu.h"
+#include "etnaviv_mmu.h"
 #include "etnaviv_iommu.h"
+#include "state.xml.h"
 #include "state_hi.xml.h"

+#define MMUv2_PTE_PRESENT  BIT(0)
+#define MMUv2_PTE_EXCEPTIONBIT(1)
+#define MMUv2_PTE_WRITEABLEBIT(2)

+#define MMUv2_MTLB_MASK0xffc0
+#define MMUv2_MTLB_SHIFT   22
+#define MMUv2_STLB_MASK0x003ff000
+#define MMUv2_STLB_SHIFT   12
+
+#define MMUv2_MAX_STLB_ENTRIES 1024
+
+struct etnaviv_iommuv2_domain {
+   struct iommu_domain domain;
+   struct device *dev;
+   void *bad_page_cpu;
+   dma_addr_t bad_page_dma;
+   /* M(aster) TLB aka first level pagetable */
+   u32 *mtlb_cpu;
+   dma_addr_t mtlb_dma;
+   /* S(lave) TLB aka second level pagetable */
+   u32 *stlb_cpu[1024];
+   dma_addr_t stlb_dma[1024];
+};
+
+static struct etnaviv_iommuv2_domain *to_etnaviv_domain(struct iommu_domain 
*domain)
+{
+   return container_of(domain, struct etnaviv_iommuv2_domain, domain);
+}
+
+static int etnaviv_iommuv2_map(struct iommu_domain *domain, unsigned long iova,
+  phys_addr_t paddr, size_t size, int prot)
+{
+   struct etnaviv_iommuv2_domain *etnaviv_domain =
+   to_etnaviv_domain(domain);
+   int mtlb_entry, stlb_entry;
+   u32 entry = (u32)paddr | MMUv2_PTE_PRESENT;
+
+   if (size != SZ_4K)
+   return -EINVAL;
+
+   if (prot & IOMMU_WRITE)
+   entry |= MMUv2_PTE_WRITEABLE;
+
+   mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
+   stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
+
+   etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] = entry;
+
+   return 0;
+}
+
+static size_t etnaviv_iommuv2_unmap(struct iommu_domain *domain,
+   unsigned long iova, size_t size)
+{
+   struct etnaviv_iommuv2_domain *etnaviv_domain =
+   to_etnaviv_domain(domain);
+   int mtlb_entry, stlb_entry;
+
+   if (size != SZ_4K)
+   return -EINVAL;
+
+   mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
+   stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
+
+   etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] = MMUv2_PTE_EXCEPTION;
+
+   return SZ_4K;
+}
+
+static phys_addr_t etnaviv_iommuv2_iova_to_phys(struct iommu_domain *domain,
+   dma_addr_t iova)
+{
+   struct etnaviv_iommuv2_domain *etnaviv_domain =
+   to_etnaviv_domain(domain);
+   int mtlb_entry, stlb_entry;
+
+   mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
+   stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
+
+   return etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] & ~(SZ_4K - 1);
+}
+
+static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain)
+{
+   u32 *p;
+   int ret, i, j;
+
+   /* allocate scratch page */
+   etnaviv_domain->bad_page_cpu = dma_alloc_coherent(etnaviv_domain->dev,
+ SZ_4K,
+ &etnaviv_domain->bad_page_dma,
+ GFP_KERNEL);
+   if (!etnaviv_domain->bad_page_cpu) {
+   ret = -ENOMEM;
+   goto fail_mem;
+   }
+   p = etnaviv_domai

[PATCH v12 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

[Maarten Lankhorst]

Op 17-08-16 om 21:55 schreef Lyude:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> values written to them won't take effect until said registers are
> "armed", which is done by writing to the PLANE_SURF (or in the case of
> cursor planes, the CURBASE register) register.
>
> With this in mind, up until now we've been updating watermarks on skl
> like this:
This patch breaks on plane disabling. I think that all the disable_plane hooks
should zero all the watermark values. This might also make modeset more reliable

It's shown in this testcase that I wrote to expose this issue: 
kms_atomic_transition.plane-all-modeset-transition

I've applied patch 1, 2, 3 and 5 with some minor fixes.

[RFC 0/2] New feature: Framebuffer processors

[Tobias Jakobi]

Hello Marek,

Marek Szyprowski wrote:
> Dear Tobias
> 
> 
> On 2016-08-22 12:07, Tobias Jakobi wrote:
>> Hey Marek,
>>
>> I had a quick look at the series and I really like the new approach.
>>
>> I was wondering about the following though. If I understand this
>> correctly I can only perform m2m operations on buffers which are
>> registered as framebuffers. Is this possible to weaken that requirements
>> such that arbitrary GEM objects can be used as input and output?
> 
> Thanks for you comment.
> 
> I'm open for discussion if the API should be based on framebuffers or
> GEM objects.
> 
> Initially I thought that GEM objects would be enough, but later I
> noticed that in such case user would need to provide at least width,
> height, stride, start offset and pixel format - all parameters that
> are already used to create framebuffer object. Operating on GEM
> buffers will also make support for images composed from multiple
> buffers (like separate GEM objects for luma/chroma parts in case of
> planar formats) a bit harder. Same about already introduced API for
> fb-modifiers. I just don't want to duplicate all of it in fbproc API.
yes, that makes perfectly sense. Passing the buffer parameters
(geometry, pixel format, etc.) each time is probably not a good (and
efficient) idea.


I'm still wondering if there can't arise a situation where I simply
can't register a buffer as framebuffer.

I'm specifically looking at internal_framebuffer_create() and the driver
specific fb_create(). Now internal_framebuffer_create() itself only does
some minimal checking, but e.g. it does check against certain
minimum/maximum geometry parameters. How do we know that these
parameters match the ones for the block that performs the m2m operations?

I could image that a block could perform scaling operations on buffers
with a much larger geometry than the core allows to bind as
framebuffers. So if I have such a buffer with large geometry I might
want to scale it down, so that I can display it. But that's not possible
since I can't even bind the src as fb.

Does that make sense?


With best wishes,
Tobias


> Operating on framebuffer objects also helps to reduce errors in
> userspace. One can already queue the result of processing to the
> display hardware and this way avoid common issues related to debugging
> why the processed image is not displayed correctly due to incorrectly
> defined pitch/fourcc/start offset/etc. This is however not really a
> strong advantage of framebuffers.
> 
> 
>>
>> Anyway, great work!
>>
>> With best wishes,
>> Tobias
>>
>>
>> Marek Szyprowski wrote:
>>> Dear all,
>>>
>>> This is the initial proposal for extending DRM API with generic
>>> support for
>>> hardware modules, which can be used for processing image data from
>>> the one
>>> memory buffer to another. Typical memory-to-memory operations are:
>>> rotation, scaling, colour space conversion or mix of them. In this
>>> proposal
>>> I named such hardware modules a framebuffer processors.
>>>
>>> Embedded SoCs are known to have a number of hardware blocks, which
>>> perform
>>> such operations. They can be used in paralel to the main GPU module to
>>> offload CPU from processing grapics or video data. One of example use of
>>> such modules is implementing video overlay, which usually requires color
>>> space conversion from NV12 (or similar) to RGB32 color space and
>>> scaling to
>>> target window size.
>>>
>>> Till now there was no generic, hardware independent API for
>>> performing such
>>> operations. Exynos DRM driver has its own custom extension called IPP
>>> (Image Post Processing), but frankly speaking, it is over-engineered
>>> and not
>>> really used in open-source. I didn't indentify similar API in other DRM
>>> drivers, besides those which expose complete support for the whole GPU.
>>>
>>> However, the need for commmon API has been already mentioned on the
>>> mailing
>>> list. Here are some example threads:
>>> 1. "RFC: hardware accelerated bitblt using dma engine"
>>> http://www.spinics.net/lists/dri-devel/msg114250.html
>>> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing)
>>> subsystem"
>>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
>>>
>>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
>>>
>>>
>>> The proposed API is heavily inspired by atomic KMS approach - it is also
>>> based on DRM objects and their properties. A new DRM object is
>>> introduced:
>>> framebuffer processor (called fbproc for convenience). Such fbproc
>>> objects
>>> have a set of standard DRM properties, which describes the operation
>>> to be
>>> performed by respective hardware module. In typical case those
>>> properties
>>> are a source fb id and rectangle (x, y, width, height) and
>>> destination fb
>>> id and rectangle. Optionally a rotation property can be also
>>> specified if
>>> supported by the given hardware. To perform an operation on image data,
>>> userspace provid

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

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

https://bugzilla.kernel.org/show_bug.cgi?id=153121

--- Comment #32 from Kontantin Ivanov  ---
Created attachment 229671
  --> https://bugzilla.kernel.org/attachment.cgi?id=229671&action=edit
4.8.0-040800rc3 dmesg

yet another dmesg for 4.8.0-rc3

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

[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650

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

https://bugzilla.kernel.org/show_bug.cgi?id=153121

--- Comment #33 from Kontantin Ivanov  ---
Created attachment 229681
  --> https://bugzilla.kernel.org/attachment.cgi?id=229681&action=edit
4.8.0-040800rc3 Xorg.0.log

yet another Xorg.0.log (4.8.0-rc3)

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

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Lucas Stach]

Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > The GPU may still keep its state when in suspend, which breaks the
> > assumption that the hardware is in a clean state before the init
> > routine runs. Make sure to reset the GPU when coming back from
> > suspend, so this assumption is validated.
> 
> This doesn't mean very much to me - could you explain exactly what the
> problem you're trying to solve here is?
> 
On the i.MX6 both the 2D and 3D GPU are in the same power domain. As
long as the 2D core is in use the 3D core will not loose power during
suspend and the other way around.

So the GPU is keeping it's state during suspend. What I've seen is that
we definitely fall over when trying to configure an already enabled MMU,
as this is causing faults. But I can well imagine that we the GPU might
behave slightly different in a number of places.

Also currently the i.MX6 platform resets the GPU after powering up the
power domain, but there is no guarantee that the platform does this and
the driver should work correctly regardless. In fact im.MX6QP has an
erratum, which disallows to power down the GPU power domain, as long as
the PRE unit is active, so there will be no power-up reset when coming
back from suspend.

> This looks like it makes resuming the GPU quite expensive.
> 
Possibly, yes. But the timeouts for runtime PM are really long right
now, so we should not power down the GPU when it's in active use. So
taking a little longer to resume the GPU shouldn't matter. Even more so
when taking into account that the resume path is already quite
expensive, involving a regulator the be enabled and waited on to become
stable.

Regards,
Lucas

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

[Lucas Stach]

Am Montag, den 22.08.2016, 12:22 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote:
> > There is no linear window on MMUv2 and the FE can access the full 4GB
> > address space either directly (as long as the MMU isn't configured) or
> > through the MMU, once it is up.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > index 433d2df0907b..2306962330a0 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> > @@ -678,7 +678,9 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
> > dev_err(gpu->dev, "could not create command buffer\n");
> > goto destroy_iommu;
> > }
> > -   if (gpu->buffer->paddr - gpu->memory_base > 0x8000) {
> > +
> > +   if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) &&
> 
> Why are you using a different test to the one in patch 2?  By this
> time, we've already setup the MMU, so the test can be the same.
> 
That's right. I'll change this to be consistent.

[Bug 97371] AMDGPU/Iceland amdgpu: failed testing IB on ring 9/10

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

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

--- Comment #10 from Dea1993  ---
same problem on my laptaop.
i've tested:
linux 4.8 rc1, rc2 and now also rc3.

@Christian König
"Good, the patch should show up in the next rc."
do you mean on rc4??

-- 
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/20160822/2aee8c0a/attachment.html>

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Lucas Stach]

Am Montag, den 22.08.2016, 13:27 +0100 schrieb Russell King - ARM Linux:
> On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> > Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > > The GPU may still keep its state when in suspend, which breaks the
> > > > assumption that the hardware is in a clean state before the init
> > > > routine runs. Make sure to reset the GPU when coming back from
> > > > suspend, so this assumption is validated.
> > > 
> > > This doesn't mean very much to me - could you explain exactly what the
> > > problem you're trying to solve here is?
> > > 
> > On the i.MX6 both the 2D and 3D GPU are in the same power domain. As
> > long as the 2D core is in use the 3D core will not loose power during
> > suspend and the other way around.
> 
> ... which is already fine.
> 
> > So the GPU is keeping it's state during suspend. What I've seen is that
> > we definitely fall over when trying to configure an already enabled MMU,
> > as this is causing faults. But I can well imagine that we the GPU might
> > behave slightly different in a number of places.
> 
> I've not seen this on iMX6, and since my setup exercises the 2D and 3D
> GPUs quite independently, I'm surprised that you've found a problem here.
> Again... more details please.  Bearing in mind that the iMX6 GPUs (with
> v1 MMUs) are incapable of generating any kind of fault, I'm not really
> sure what you're talking about here.
> 
I'm looking at i.MX6QP with MMUv2.

> > Also currently the i.MX6 platform resets the GPU after powering up the
> > power domain, but there is no guarantee that the platform does this and
> > the driver should work correctly regardless. In fact im.MX6QP has an
> > erratum, which disallows to power down the GPU power domain, as long as
> > the PRE unit is active, so there will be no power-up reset when coming
> > back from suspend.
> 
> There is no requirement to actually power down the GPU when placing it
> into low power state, and we don't make the assumption that it will be
> powered down - but we do expect that it may power down, so we do enough
> to bring it back up.
> 
> In any case, if hardware has been powered down, it has _got_ to be reset
> by hardware when re-applying power otherwise it is in a completely
> indeterminant state.  That is very dangerous as it would mean that the
> MMUs can contain random data, as well as the command processor, and the
> rest of the GPU.  The GPU could well think that it's supposed to be
> drawing stuff to random places in memory.  You can't say "ah yes, but
> this is why we need to software reset it" because that's _way_ too late,
> there's a time window between applying power and the GPU starting to
> scribble, and the CPU getting around to applying the software reset.
> 
> So, software resetting the GPU doesn't achieve very much in this
> situation IMHO.
> 
> > > This looks like it makes resuming the GPU quite expensive.
> > > 
> > Possibly, yes. But the timeouts for runtime PM are really long right
> > now, so we should not power down the GPU when it's in active use. So
> > taking a little longer to resume the GPU shouldn't matter. Even more so
> > when taking into account that the resume path is already quite
> > expensive, involving a regulator the be enabled and waited on to become
> > stable.
> 
> Not all platforms are that expensive.  For Dove, it's writing three
> registers and you're done, with no wait required.  So I don't buy
> the argument that "it's already expensive, so we can make it more
> expensive."
> 
Okay, I see your argument. I'll drop this patch and add a check to the
MMUv2 code to not restore anything if the state is retained during
suspend.

Regards,
Lucas

[PATCH 1/1] drm/gma500: dont expose stack, mrst_lvds_find_best_pll

[kbuild test robot]

Hi Heinrich,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Heinrich-Schuchardt/drm-gma500-dont-expose-stack-mrst_lvds_find_best_pll/20160822-040114
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-n0-08221935 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from arch/x86/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/uapi/linux/uuid.h:21,
from include/linux/uuid.h:19,
from include/linux/mod_devicetable.h:12,
from include/linux/i2c.h:29,
from drivers/gpu/drm/gma500/oaktrail_crtc.c:18:
   drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
'mrst_lvds_find_best_pll':
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:197:33: error: incompatible type for 
>> argument 1 of '__memset'
 memset(clock, 0, sizeof(struct gma_clock_t));
^
   arch/x86/include/asm/string_64.h:78:40: note: in definition of macro 'memset'
#define memset(s, c, n) __memset(s, c, n)
   ^
   arch/x86/include/asm/string_64.h:56:7: note: expected 'void *' but argument 
is of type 'struct gma_clock_t'
void *__memset(void *s, int c, size_t n);
  ^

vim +/__memset +197 drivers/gpu/drm/gma500/oaktrail_crtc.c

12   *
13   * You should have received a copy of the GNU General Public License 
along with
14   * this program; if not, write to the Free Software Foundation, Inc.,
15   * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
16   */
17  
  > 18  #include 
19  #include 
20  
21  #include 
22  #include "framebuffer.h"
23  #include "psb_drv.h"
24  #include "psb_intel_drv.h"
25  #include "psb_intel_reg.h"
26  #include "gma_display.h"
27  #include "power.h"
28  
29  #define MRST_LIMIT_LVDS_100L0
30  #define MRST_LIMIT_LVDS_83  1
31  #define MRST_LIMIT_LVDS_100 2
32  #define MRST_LIMIT_SDVO 3
33  
34  #define MRST_DOT_MIN  19750
35  #define MRST_DOT_MAX  12
36  #define MRST_M_MIN_100L 20
37  #define MRST_M_MIN_100  10
38  #define MRST_M_MIN_83   12
39  #define MRST_M_MAX_100L 34
40  #define MRST_M_MAX_100  17
41  #define MRST_M_MAX_83   20
42  #define MRST_P1_MIN 2
43  #define MRST_P1_MAX_0   7
44  #define MRST_P1_MAX_1   8
45  
46  static bool mrst_lvds_find_best_pll(const struct gma_limit_t *limit,
47  struct drm_crtc *crtc, int target,
48  int refclk, struct gma_clock_t 
*best_clock);
49  
50  static bool mrst_sdvo_find_best_pll(const struct gma_limit_t *limit,
51  struct drm_crtc *crtc, int target,
52  int refclk, struct gma_clock_t 
*best_clock);
53  
54  static const struct gma_limit_t mrst_limits[] = {
55  {   /* MRST_LIMIT_LVDS_100L */
56   .dot = {.min = MRST_DOT_MIN, .max = MRST_DOT_MAX},
57   .m = {.min = MRST_M_MIN_100L, .max = MRST_M_MAX_100L},
58   .p1 = {.min = MRST_P1_MIN, .max = MRST_P1_MAX_1},
59   .find_pll = mrst_lvds_find_best_pll,
60   },
61  {   /* MRST_LIMIT_LVDS_83L */
62   .dot = {.min = MRST_DOT_MIN, .max = MRST_DOT_MAX},
63   .m = {.min = MRST_M_MIN_83, .max = MRST_M_MAX_83},
64   .p1 = {.min = MRST_P1_MIN, .max = MRST_P1_MAX_0},
65   .find_pll = mrst_lvds_find_best_pll,
66   },
67  {   /* MRST_LIMIT_LVDS_100 */
68   .dot = {.min = MRST_DOT_MIN, .max = MRST_DOT_MAX},
69   .m = {.min = MRST_M_MIN_100, .max = MRST_M_MAX_100},
70   .p1 = {.min = MRST_P1_MIN, .max = MRST_P1_MAX_1},
71   .find_pll = mrst_lvds_find_best_pll,
72   },
73  {   /* MRST_LIMIT_SDVO */
74  

[PATCH -next] drm/i915: Fix non static symbol warning

[Jani Nikula]

On Sun, 21 Aug 2016, Wei Yongjun  wrote:
> From: Wei Yongjun 
>
> Fixes the following sparse warning:
>
> drivers/gpu/drm/i915/intel_hotplug.c:480:6: warning:
>  symbol 'i915_hpd_poll_init_work' was not declared. Should it be static?
>
> Also move the '{' to new line.

Thanks for the patch, but we've already fixed this in

commit 24808e96792a860f3e83e2eb69c5190261716924
Author: Chris Wilson 
Date:   Wed Aug 17 12:09:06 2016 +0100

drm/i915: Mark i915_hpd_poll_init_work as static

BR,
Jani.

>
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/gpu/drm/i915/intel_hotplug.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 5dc2c20..334d47b 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -477,7 +477,8 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
>   spin_unlock_irq(&dev_priv->irq_lock);
>  }
>  
> -void i915_hpd_poll_init_work(struct work_struct *work) {
> +static void i915_hpd_poll_init_work(struct work_struct *work)
> +{
>   struct drm_i915_private *dev_priv =
>   container_of(work, struct drm_i915_private,
>hotplug.poll_init_work);
>

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v2 4/7] drm/bridge: Add RGB to VGA bridge support

[Maxime Ripard]

Hi Archit,

On Thu, Jul 21, 2016 at 03:23:18PM +0530, Archit Taneja wrote:
> Hi,
> 
> On 07/20/2016 03:28 PM, Maxime Ripard wrote:
> >Some boards have an entirely passive RGB to VGA bridge, based on either
> >DACs or resistor ladders.
> >
> >Those might or might not have an i2c bus routed to the VGA connector in
> >order to access the screen EDIDs.
> >
> >Add a bridge that doesn't do anything but expose the modes available on the
> >screen, either based on the EDIDs if available, or based on the XGA
> >standards.
> 
> Our eventual aim is to separate out the connectors from the bridge
> drivers wherever possible. In the future, a KMS driver using the
> bridge would be responsible for establishing the links between
> the bridge and encoder, and the encoder and connector.
> 
> If in the future we remove the connector pieces from this driver
> to create a separate generic VGA connector driver, we'll end up
> with a bridge driver whose main functionality is to convert RGB
> signals to VGA. The EDID parts would move to the VGA connector
> driver. In your platform's case, there is no software needed
> to translate RGB to VGA, but maybe in the future, we might need
> to add an optional regulator in the driver to support another
> platform. Therefore, the bridge driver would still be handy to
> have.
> 
> Keeping this in consideration, I think this driver (and the DT
> binding) should be called "dumb-rgb-to-vga-bridge", or
> "rgb-to-vga-bridge" since that's what the bridge HW primarily
> does.

That works for me. I'll change it and repost.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel 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/20160822/846b3b46/attachment.sig>

[PATCH] drm/gma500: dont expose bytes from kernel stack

[kbuild test robot]

Hi Heinrich,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.8-rc3 next-20160822]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Heinrich-Schuchardt/drm-gma500-dont-expose-bytes-from-kernel-stack/20160822-024132
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x015-201634 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/gma500/oaktrail_crtc.c: In function 
'mrst_sdvo_find_best_pll':
>> drivers/gpu/drm/gma500/oaktrail_crtc.c:141:9: error: incompatible type for 
>> argument 1 of 'memset'
 memset(clock, 0, sizeof(struct gma_clock_t));
^
   In file included from arch/x86/include/asm/string.h:4:0,
from include/linux/string.h:18,
from include/uapi/linux/uuid.h:21,
from include/linux/uuid.h:19,
from include/linux/mod_devicetable.h:12,
from include/linux/i2c.h:29,
from drivers/gpu/drm/gma500/oaktrail_crtc.c:18:
   arch/x86/include/asm/string_64.h:55:7: note: expected 'void *' but argument 
is of type 'struct gma_clock_t'
void *memset(void *s, int c, size_t n);
  ^~

vim +/memset +141 drivers/gpu/drm/gma500/oaktrail_crtc.c

   135  int refclk, struct gma_clock_t 
*best_clock)
   136  {
   137  struct gma_clock_t clock;
   138  u32 target_vco, actual_freq;
   139  s32 freq_error, min_error = 10;
   140  
 > 141  memset(clock, 0, sizeof(struct gma_clock_t));
   142  memset(best_clock, 0, sizeof(*best_clock));
   143  
   144  for (clock.m = limit->m.min; clock.m <= limit->m.max; 
clock.m++) {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 31106 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/04de8f79/attachment-0001.obj>

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Russell King - ARM Linux]

On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> The GPU may still keep its state when in suspend, which breaks the
> assumption that the hardware is in a clean state before the init
> routine runs. Make sure to reset the GPU when coming back from
> suspend, so this assumption is validated.

This doesn't mean very much to me - could you explain exactly what the
problem you're trying to solve here is?

This looks like it makes resuming the GPU quite expensive.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 01/18] drm/etnaviv: reset GPU when coming back from suspend

[Russell King - ARM Linux]

On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > The GPU may still keep its state when in suspend, which breaks the
> > > assumption that the hardware is in a clean state before the init
> > > routine runs. Make sure to reset the GPU when coming back from
> > > suspend, so this assumption is validated.
> > 
> > This doesn't mean very much to me - could you explain exactly what the
> > problem you're trying to solve here is?
> > 
> On the i.MX6 both the 2D and 3D GPU are in the same power domain. As
> long as the 2D core is in use the 3D core will not loose power during
> suspend and the other way around.

... which is already fine.

> So the GPU is keeping it's state during suspend. What I've seen is that
> we definitely fall over when trying to configure an already enabled MMU,
> as this is causing faults. But I can well imagine that we the GPU might
> behave slightly different in a number of places.

I've not seen this on iMX6, and since my setup exercises the 2D and 3D
GPUs quite independently, I'm surprised that you've found a problem here.
Again... more details please.  Bearing in mind that the iMX6 GPUs (with
v1 MMUs) are incapable of generating any kind of fault, I'm not really
sure what you're talking about here.

> Also currently the i.MX6 platform resets the GPU after powering up the
> power domain, but there is no guarantee that the platform does this and
> the driver should work correctly regardless. In fact im.MX6QP has an
> erratum, which disallows to power down the GPU power domain, as long as
> the PRE unit is active, so there will be no power-up reset when coming
> back from suspend.

There is no requirement to actually power down the GPU when placing it
into low power state, and we don't make the assumption that it will be
powered down - but we do expect that it may power down, so we do enough
to bring it back up.

In any case, if hardware has been powered down, it has _got_ to be reset
by hardware when re-applying power otherwise it is in a completely
indeterminant state.  That is very dangerous as it would mean that the
MMUs can contain random data, as well as the command processor, and the
rest of the GPU.  The GPU could well think that it's supposed to be
drawing stuff to random places in memory.  You can't say "ah yes, but
this is why we need to software reset it" because that's _way_ too late,
there's a time window between applying power and the GPU starting to
scribble, and the CPU getting around to applying the software reset.

So, software resetting the GPU doesn't achieve very much in this
situation IMHO.

> > This looks like it makes resuming the GPU quite expensive.
> > 
> Possibly, yes. But the timeouts for runtime PM are really long right
> now, so we should not power down the GPU when it's in active use. So
> taking a little longer to resume the GPU shouldn't matter. Even more so
> when taking into account that the resume path is already quite
> expensive, involving a regulator the be enabled and waited on to become
> stable.

Not all platforms are that expensive.  For Dove, it's writing three
registers and you're done, with no wait required.  So I don't buy
the argument that "it's already expensive, so we can make it more
expensive."

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2] drm/fsl-dcu: Implement gamma_lut atomic crtc properties

[Meng Yi]

Hi Stefan,
What do you think about this patch for gamma correction. 
I see many people approach gamma correction this way. Do you have any 
comments?

Best Regards,
Meng

> +static void fsl_crtc_gamma_set(struct drm_crtc *crtc, struct drm_color_lut
> *lut,
> +   uint32_t size)
> +{
> + struct fsl_dcu_drm_device *fsl_dev = crtc->dev->dev_private;
> + unsigned int i;
> +
> + for (i = 0; i < size; i++) {
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_R + 4 * i,
> +  lut[i].red << 24);
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_G + 4 * i,
> +  lut[i].green << 24);
> + regmap_write(fsl_dev->regmap, FSL_GAMMA_B + 4 * i,
> +  lut[i].blue << 24);
> + }
> +}
> +
>  static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state)
> { @@ -37,6 +53,11 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct
> drm_crtc *crtc,
>   drm_crtc_send_vblank_event(crtc, event);
>   spin_unlock_irq(&crtc->dev->event_lock);
>   }
> +
> + if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
> + fsl_crtc_gamma_set(crtc, (struct drm_color_lut *)
> +crtc->state->gamma_lut->data,
> +256);
>  }
> 
>  static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc) @@ -46,6 +67,11
> @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
> 
>   drm_crtc_vblank_off(crtc);
> 
> + if (fsl_dev->enable_color_mgmt)
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +DCU_MODE_EN_GAMMA_MASK,
> +DCU_MODE_GAMMA_DISABLE);
> +
>   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
>  DCU_MODE_DCU_MODE_MASK,
>  DCU_MODE_DCU_MODE(DCU_MODE_OFF)); @@ -
> 58,6 +84,11 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
>   struct drm_device *dev = crtc->dev;
>   struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> 
> + if (fsl_dev->enable_color_mgmt)
> + regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
> +DCU_MODE_EN_GAMMA_MASK,
> +DCU_MODE_GAMMA_ENABLE);
> +
>   regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
>  DCU_MODE_DCU_MODE_MASK,
>  DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
> @@ -135,6 +166,7 @@ static const struct drm_crtc_funcs
> fsl_dcu_drm_crtc_funcs = {
>   .page_flip = drm_atomic_helper_page_flip,
>   .reset = drm_atomic_helper_crtc_reset,
>   .set_config = drm_atomic_helper_set_config,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
>  };
> 

[PATCH] drm/doc: Document uapi requirements in DRM

[Jani Nikula]

On Mon, 22 Aug 2016, Daniel Vetter  wrote:
> Everyone knows them, except all the new folks joining from the ARM
> side haven't lived through all the pain of the past years and are
> entirely surprised when I raise this. Definitely time to document
> this.
>
> Last time this was a big discussion was about 6 years ago, when qcom
> tried to land a kernel driver without userspace. Dave Airlie made the
> rules really clear:
>
> http://airlied.livejournal.com/73115.html
>
> This write-up here is essentially what I've put into a presentation a
> while ago, which was also reviewed by Dave:
>
> http://blog.ffwll.ch/2015/05/gfx-kernel-upstreaming-requirements.html
>
> v2: Fix typos Eric&Rob spotted.
>
> Cc: Dave Airlie 
> Cc: Oded Gabbay 
> Cc: Russell King 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> Cc: Thomas Hellstrom 
> Cc: Sinclair Yeh 
> Cc: Lucas Stach 
> Cc: Benjamin Gaignard 
> Cc: Mark Yao 
> Cc: Laurent Pinchart 
> Cc: Ben Skeggs 
> Cc: Rob Clark 
> Cc: CK Hu 
> Cc: Xinliang Liu 
> Cc: Philipp Zabel 
> Cc: Stefan Agner 
> Cc: Inki Dae 
> Cc: Maxime Ripard  
> Cc: Boris Brezillon 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Thierry Reding 
> Cc: Christian König 
> Cc: Alex Deucher 
> Cc: Gerd Hoffmann 
> Cc: Brian Starkey 
> Cc: Liviu Dudau 
> Cc: Alexey Brodkin 
> Acked-by: Dave Airlie 
> Reviewed-by: Rob Clark 
> Reviewed-by: Christian König 
> Reviewed-by: Eric Anholt 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-uapi.rst | 67 
> ++
>  1 file changed, 67 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 94876938aef3..747b51f8c422 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -36,6 +36,73 @@ Primary Nodes, DRM Master and Authentication
>  Open-Source Userspace Requirements
>  ==
>  
> +The DRM subsystem has stricter requirements on what the userspace side for 
> new
> +uAPI needs to look like. This section here explains what exactly those
> +requirements are, and why they exist.

Nitpick, stricter requirements than what? I know what you mean, but the
comparative begs for the thing to compare against.

Otherwise,

Reviewed-by: Jani Nikula 

> +
> +The short summary is that any addition of DRM uAPI requires corresponding
> +open-sourced userspace patches, and those patches must be reviewed and ready 
> for
> +merging into a suitable and canonical upstream project.
> +
> +GFX devices (both display and render/GPU side) are really complex bits of
> +hardware, with userspace and kernel by necessity having to work together 
> really
> +closely.  The interfaces, for rendering and modesetting, must be extremely 
> wide
> +and flexible, and therefore it is almost always impossible to precisely 
> define
> +them for every possible corner case. This in turn makes it really practically
> +infeasible to differentiate between behaviour that's required by userspace, 
> and
> +which must not be changed to avoid regressions, and behaviour which is only 
> an
> +accidental artifact of the current implementation.
> +
> +Without access to the full source code of all userspace users that means it
> +becomes impossible to change the implementation details, since userspace 
> could
> +depend upon the accidental behaviour of the current implementation in minute
> +details. And debugging such regressions without access to source code is 
> pretty
> +much impossible. As a consequence this means:
> +
> +- The Linux kernel's "no regression" policy holds in practice only for
> +  open-source userspace of the DRM subsystem. DRM developers are perfectly 
> fine
> +  if closed-source blob drivers in userspace use the same uAPI as the open
> +  drivers, but they must do so in the exact same way as the open drivers.
> +  Creative (ab)use of the interfaces will, and in the past routinely has, 
> lead
> +  to breakage.
> +
> +- Any new userspace interface must have an open-source implementation as
> +  demonstration vehicle.
> +
> +The other reason for requiring open-source userspace is uAPI review. Since 
> the
> +kernel and userspace parts of a GFX stack must work together so closely, code
> +review can only assess whether a new interface achieves its goals by looking 
> at
> +both sides. Making sure that the interface indeed covers the use-case fully
> +leads to a few additional requirements:
> +
> +- The open-source userspace must not be a toy/test application, but the real
> +  thing. Specifically it needs to handle all the usual error and corner 
> cases.
> +  These are often the places where new uAPI falls apart and hence essential 
> to
> +  assess the fitness of a proposed interface.
> +
> +- The userspace side must be fully reviewed and tested to the standards of 
> that
> +  userspace project. For e.g. mesa this means piglit testcases and review on 
> the
> +  mailing list. This is again to ensure that the new interface actually gets 
> the
>

[8086:0416] i915 Inability to drive internal (eDP) panel since 4.7 final

[Tony Vroon]

: application/pgp-signature
Size: 248 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160822/a0b6e532/attachment-0001.sig>

[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

[Russell King - ARM Linux]

On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote:
> There is no linear window on MMUv2 and the FE can access the full 4GB
> address space either directly (as long as the MMU isn't configured) or
> through the MMU, once it is up.
> 
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 433d2df0907b..2306962330a0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -678,7 +678,9 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   dev_err(gpu->dev, "could not create command buffer\n");
>   goto destroy_iommu;
>   }
> - if (gpu->buffer->paddr - gpu->memory_base > 0x8000) {
> +
> + if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) &&

Why are you using a different test to the one in patch 2?  By this
time, we've already setup the MMU, so the test can be the same.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Daniel Vetter]

On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark  wrote:
>> That said, _note_ that some applications are built with -C89 -pedantic
>> [1] which means that using stdint.h may or may not work as expected.
>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
>> If the affected programs are proprietary ones we should be safe,
>> otherwise we want to update them ~alongside the transition.
>
> naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
> -C89.. problem solved!

Yeah, I think sprinkling an

#ifdef __kernel___
#include 
#else
#include 
#endif

at the opt of all drm uapi headers should be good enough. Or at least
those which opt to choose stdints. Since our userspace is very
limited, and our headers will never leak to general applications we
can just require c99, at least for driver headers. For kms/general drm
uapi that might not be the best idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v3 3/3] drm/imx: Add active plane reconfiguration support

[Daniel Vetter]

On Mon, Aug 22, 2016 at 04:23:36PM +0800, Ying Liu wrote:
> On Mon, Aug 22, 2016 at 3:53 PM, Daniel Vetter  wrote:
> > On Mon, Aug 22, 2016 at 9:43 AM, Ying Liu  wrote:
>  +
>  + /*
>  +  * The relevant plane's ->atomic_check callback may set
>  +  * crtc_state->mode_changed to be true when the active
>  +  * plane needs to be reconfigured.  In this case and only
>  +  * this case, active_changed is false - we disable all the
>  +  * appropriate active planes here.
>  +  */
>  + if (!crtc->state->active_changed) {
>  + struct drm_plane *plane;
>  +
>  + drm_atomic_crtc_state_for_each_plane(plane, 
>  old_crtc_state) {
>  + const struct drm_plane_helper_funcs *plane_funcs =
>  + plane->helper_private;
>  +
>  + /*
>  +  * Filter out the plane which is explicitly 
>  required
>  +  * to be disabled by the user via atomic commit
>  +  * so that it won't be accidentally disabled twice.
>  +  */
>  + if (!plane->state->crtc)
>  + continue;
> >>>
> >>> I think the better place would be to do the filtering in commit_planes(),
> >>> not here. And would be great to include your patch to fix up
> >>> disable_planes_on_crtc(), too.
> >>
> >> Do you mean we can do the filtering by checking (!plane->state->crtc)
> >> right before plane_funcs->atomic_disable in commit_planes()?
> >> Won't it filter out all the apples?
> >> commit_planes() doesn't know whether the driver calls
> >> disable_planes_on_crtc() or not.
> >
> > You need to filter on needs_modeset(crtc_state), and it needs to be
> > optional like active_only, using a flag.
> 
> Then, IIUC, the flag will be CRTC specific and be dynamically
> changeable. I'm not clear about the way to implement this.
> 
> >
> >> imo, doing the filtering in crtc_funcs->atomic_disable is sane.
> >
> > It is not sane in general, since usually you need to call
> > disable_planes_on_crtc to avoid upsetting your hardware. And for that
> 
> Calling disable_planes_on_crtc() in crtc_funcs->atomic_disable is
> a bit over-kill and will cause the issue of disabling plane twice, unless
> the filtering is done in disable_planes_on_crtc() (which was rejected
> by you on irc) or in commit_planes()?(which I'm not clear about
> the way to implement, as I mentioned before).  So I chose to do the
> filtering in the imx-drm specific crtc_funcs->atomic_disable function.

For filtering in commit_planes I think the best plane is to
- add a new flag NO_DISABLE_AFTER_MODESET
- which does exactly what it says on the tin: If the commmit_planes helper
  would call plane_funcs->atomic_disable, but
  drm_atomic_crtc_needs_modeset() for that crtc is true then you skip the
  ->atomic_disable call.

This assumes that all disables have already been committed when disabling
the crtc. For a lot of hardware it only makes sense to set both this flag
and ACTIVE_ONLY, but there's probably some fun hardware out there where
this is not the case (yours seems to be one example).

Now it's not pretty to have 2 boolean arguments for the same function, so
we also need to convert that into a bitflag field. End result:

#define COMMIT_ACTIVE_ONLY  BIT(0)
#define COMMIT_NO_DISABLE_AFTER_MODESET BIT(1)

Ofc kernel-doc should explain what the flags are for and when to use them.

void drm_atomic_helper_commit_planes(struct drm_device *dev,
 struct drm_atomic_state *state,
 unsigned flags);

A bit more work, but I think overall worth it.

> > use-case filtering in disable will lead to hung hardware. Which really
> 
> Hung hardware due to filtering? How?

If you shut down the crtc and keep the planes running the hw dies. Yup,
this happens.

> > means that you need to filter in commit_planes.
> 
> Really don't understand the rational for filtering in commit_planes...
> Did I miss anything?

See above, it might work for your driver, but it definitely restricts the
usefulness of the helpers in general. And helpers which are only useful
for 1 driver aren't useful.

I hope this explains my idea a bit better, otherwise probably best if you
ping me on irc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC 0/2] New feature: Framebuffer processors

[Daniel Vetter]

On Mon, Aug 22, 2016 at 11:59:24AM +0200, Christian König wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
> > Dear all,
> > 
> > This is the initial proposal for extending DRM API with generic support for
> > hardware modules, which can be used for processing image data from the one
> > memory buffer to another. Typical memory-to-memory operations are:
> > rotation, scaling, colour space conversion or mix of them. In this proposal
> > I named such hardware modules a framebuffer processors.
> > 
> > Embedded SoCs are known to have a number of hardware blocks, which perform
> > such operations. They can be used in paralel to the main GPU module to
> > offload CPU from processing grapics or video data. One of example use of
> > such modules is implementing video overlay, which usually requires color
> > space conversion from NV12 (or similar) to RGB32 color space and scaling to
> > target window size.
> > 
> > Till now there was no generic, hardware independent API for performing such
> > operations. Exynos DRM driver has its own custom extension called IPP
> > (Image Post Processing), but frankly speaking, it is over-engineered and not
> > really used in open-source. I didn't indentify similar API in other DRM
> > drivers, besides those which expose complete support for the whole GPU.
> 
> Well there are good reasons why we don't have hardware independent command
> submission.
> 
> We already tried approaches like this and they didn't worked very well and
> are generally a pain to get right.
> 
> So my feeling goes into the direction of a NAK, especially since you didn't
> explained in this mail why there is need for a common API.

We've had an earlier RFC thread, and I made it clear there already that
this will face a steep uphill battle. I don't really see any explanation
here why this is not an exact copy of the ideas we've shown to not work
10+ years ago, hence I concur on this NACK.

Make this a driver private thing, operating on gem objects (and yes that
means you get to reinvent the metdata, which is imo a good thing since it
avoids encumbering kms with this blitter use-case). And then that
interface proves indeed useful for multiple blitter IP blocks we can use
it for that in generic fashion. And if it shows up in different
display/render/gpu blocks we can reuse the driver using dma-buf/prime
sharing. So there's really downside, except that your ioctl won't be
blessed as official in any way, which imo is a Good Thing.

Or this all turns out as a mistake (which I expect it to be) and we can
quitely burry it again since it's just a little driver.

Trying to push this will lead to 1+ years of frustration and most likely
still not succeed.
-Daniel

> 
> Regards,
> Christian.
> 
> > 
> > However, the need for commmon API has been already mentioned on the mailing
> > list. Here are some example threads:
> > 1. "RFC: hardware accelerated bitblt using dma engine"
> > http://www.spinics.net/lists/dri-devel/msg114250.html
> > 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) 
> > subsystem"
> > https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
> > https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
> > 
> > The proposed API is heavily inspired by atomic KMS approach - it is also
> > based on DRM objects and their properties. A new DRM object is introduced:
> > framebuffer processor (called fbproc for convenience). Such fbproc objects
> > have a set of standard DRM properties, which describes the operation to be
> > performed by respective hardware module. In typical case those properties
> > are a source fb id and rectangle (x, y, width, height) and destination fb
> > id and rectangle. Optionally a rotation property can be also specified if
> > supported by the given hardware. To perform an operation on image data,
> > userspace provides a set of properties and their values for given fbproc
> > object in a similar way as object and properties are provided for
> > performing atomic page flip / mode setting.
> > 
> > The proposed API consists of the 3 new ioctls:
> > - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
> >objects,
> > - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
> > - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
> >set.
> > 
> > The proposed API is extensible. Drivers can attach their own, custom
> > properties to add support for more advanced picture processing (for example
> > blending).
> > 
> > Please note that this API is intended to be used for simple memory-to-memory
> > image processing hardware not the full-blown GPU blitters, which usually
> > have more features. Typically blitters provides much more operations beside
> > simple pixel copying and operate best if its command queue is controlled 
> > from
> > respective dedicated code in userspace.
> > 
> > The patchset consist of 4 parts:
> > 1. generic code for DRM core for han

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Emil Velikov]

On 22 August 2016 at 15:38, Daniel Vetter  wrote:
> On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark  wrote:
>>> That said, _note_ that some applications are built with -C89 -pedantic
>>> [1] which means that using stdint.h may or may not work as expected.
>>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
>>> If the affected programs are proprietary ones we should be safe,
>>> otherwise we want to update them ~alongside the transition.
>>
>> naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
>> -C89.. problem solved!
>
> Yeah, I think sprinkling an
>
> #ifdef __kernel___
> #include 
> #else
> #include 
> #endif
>
Guess i was too vague :-]

I was thinking about the following cases:
 - using old/incomplete stdint.h - thus the __STDC_VESION__ check.
 - building non-libdrm software - for libdrm we've (implicitly and
explicitly) required C99 for a long time.

> at the opt of all drm uapi headers should be good enough. Or at least
> those which opt to choose stdints. Since our userspace is very
> limited, and our headers will never leak to general applications we
> can just require c99, at least for driver headers. For kms/general drm
> uapi that might not be the best idea.
Won't doing so bring more confusion to an already convoluted topic ?
If we opt for it, let's have a juicy comment that clarifies things.

-Emil

[PATCH v2 0/2] doc: dma-buf: sphinx conversion

[Sumit Semwal]

Convert dma-buf documentation over to sphinx.

While at that, convert dma-buf-sharing.txt as well, and make it the
dma-buf API guide.

There is no content change yet; only format conversion and creation of
some hyperlinks.

v2: Address review comments from Jonathan Corbet and Markus Heiser.

Sumit Semwal (2):
  Documentation: move dma-buf documentation to rst
  Documentation/sphinx: link dma-buf rsts

 Documentation/DocBook/device-drivers.tmpl |  41 ---
 Documentation/dma-buf-sharing.txt | 482 
 Documentation/dma-buf/guide.rst   | 507 ++
 Documentation/dma-buf/intro.rst   |  82 +
 Documentation/index.rst   |   2 +
 MAINTAINERS   |   2 +-
 6 files changed, 592 insertions(+), 524 deletions(-)
 delete mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

-- 
2.7.4

[PATCH v2 1/2] Documentation: move dma-buf documentation to rst

[Sumit Semwal]

Branch out dma-buf related documentation into its own rst file to allow
adding it to the sphinx documentation generated.

While at it, move dma-buf-sharing.txt into rst as the dma-buf guide too;
adjust MAINTAINERS accordingly.

v2:
- Removed authorship as suggested by Jani,
- Address review comments from Jonathan Corbet and Markus Heiser.

Signed-off-by: Sumit Semwal 
---
 Documentation/DocBook/device-drivers.tmpl |  41 ---
 Documentation/dma-buf-sharing.txt | 482 
 Documentation/dma-buf/guide.rst   | 507 ++
 Documentation/dma-buf/intro.rst   |  82 +
 MAINTAINERS   |   2 +-
 5 files changed, 590 insertions(+), 524 deletions(-)
 delete mode 100644 Documentation/dma-buf-sharing.txt
 create mode 100644 Documentation/dma-buf/guide.rst
 create mode 100644 Documentation/dma-buf/intro.rst

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 9c10030eb2be..a93fbffa9742 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,47 +128,6 @@ X!Edrivers/base/interface.c
 !Edrivers/base/platform.c
 !Edrivers/base/bus.c
  
- 
-   Buffer Sharing and Synchronization
-   
- The dma-buf subsystem provides the framework for sharing buffers
- for hardware (DMA) access across multiple device drivers and
- subsystems, and for synchronizing asynchronous hardware access.
-   
-   
- This is used, for example, by drm "prime" multi-GPU support, but
- is of course not limited to GPU use cases.
-   
-   
- The three main components of this are: (1) dma-buf, representing
- a sg_table and exposed to userspace as a file descriptor to allow
- passing between devices, (2) fence, which provides a mechanism
- to signal when one device as finished access, and (3) reservation,
- which manages the shared or exclusive fence(s) associated with
- the buffer.
-   
-   dma-buf
-!Edrivers/dma-buf/dma-buf.c
-!Iinclude/linux/dma-buf.h
-   
-   reservation
-!Pdrivers/dma-buf/reservation.c Reservation Object Overview
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
-   
-   fence
-!Edrivers/dma-buf/fence.c
-!Iinclude/linux/fence.h
-!Edrivers/dma-buf/seqno-fence.c
-!Iinclude/linux/seqno-fence.h
-!Edrivers/dma-buf/fence-array.c
-!Iinclude/linux/fence-array.h
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
-!Edrivers/dma-buf/sync_file.c
-!Iinclude/linux/sync_file.h
-   
- 
  Device Drivers DMA Management
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
deleted file mode 100644
index ca44c5820585..
--- a/Documentation/dma-buf-sharing.txt
+++ /dev/null
@@ -1,482 +0,0 @@
-DMA Buffer Sharing API Guide
-
-
-Sumit Semwal
-
- 
-
-This document serves as a guide to device-driver writers on what is the dma-buf
-buffer sharing API, how to use it for exporting and using shared buffers.
-
-Any device driver which wishes to be a part of DMA buffer sharing, can do so as
-either the 'exporter' of buffers, or the 'user' of buffers.
-
-Say a driver A wants to use buffers created by driver B, then we call B as the
-exporter, and A as buffer-user.
-
-The exporter
-- implements and manages operations[1] for the buffer
-- allows other users to share the buffer by using dma_buf sharing APIs,
-- manages the details of buffer allocation,
-- decides about the actual backing storage where this allocation happens,
-- takes care of any migration of scatterlist - for all (shared) users of this
-   buffer,
-
-The buffer-user
-- is one of (many) sharing users of the buffer.
-- doesn't need to worry about how the buffer is allocated, or where.
-- needs a mechanism to get access to the scatterlist that makes up this buffer
-   in memory, mapped into its own address space, so it can access the same area
-   of memory.
-
-dma-buf operations for device dma only
---
-
-The dma_buf buffer sharing API usage contains the following steps:
-
-1. Exporter announces that it wishes to export a buffer
-2. Userspace gets the file descriptor associated with the exported buffer, and
-   passes it around to potential buffer-users based on use case
-3. Each buffer-user 'connects' itself to the buffer
-4. When needed, buffer-user requests access to the buffer from exporter
-5. When finished with its use, the buffer-user notifies end-of-DMA to exporter
-6. when buffer-user is done using this buffer completely, it 'disconnects'
-   itself from the buffer.
-
-
-1. Exporter's announcement of buffer export
-
-   The buffer exporter announces its wi

[PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

[Sumit Semwal]

Include dma-buf sphinx documentation into top level index.

Signed-off-by: Sumit Semwal 
---
 Documentation/index.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index e0fc72963e87..8d05070122c2 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -14,6 +14,8 @@ Contents:
:maxdepth: 2

kernel-documentation
+   dma-buf/intro
+   dma-buf/guide
media/media_uapi
media/media_kapi
media/dvb-drivers/index
-- 
2.7.4

[RFC 0/2] New feature: Framebuffer processors

[Rob Clark]

On Mon, Aug 22, 2016 at 5:59 AM, Christian König
 wrote:
> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
>>
>> Dear all,
>>
>> This is the initial proposal for extending DRM API with generic support
>> for
>> hardware modules, which can be used for processing image data from the one
>> memory buffer to another. Typical memory-to-memory operations are:
>> rotation, scaling, colour space conversion or mix of them. In this
>> proposal
>> I named such hardware modules a framebuffer processors.
>>
>> Embedded SoCs are known to have a number of hardware blocks, which perform
>> such operations. They can be used in paralel to the main GPU module to
>> offload CPU from processing grapics or video data. One of example use of
>> such modules is implementing video overlay, which usually requires color
>> space conversion from NV12 (or similar) to RGB32 color space and scaling
>> to
>> target window size.
>>
>> Till now there was no generic, hardware independent API for performing
>> such
>> operations. Exynos DRM driver has its own custom extension called IPP
>> (Image Post Processing), but frankly speaking, it is over-engineered and
>> not
>> really used in open-source. I didn't indentify similar API in other DRM
>> drivers, besides those which expose complete support for the whole GPU.
>
>
> Well there are good reasons why we don't have hardware independent command
> submission.
>
> We already tried approaches like this and they didn't worked very well and
> are generally a pain to get right.
>
> So my feeling goes into the direction of a NAK, especially since you didn't
> explained in this mail why there is need for a common API.

I guess a lot comes down to 'how long before hw designers bolt a CP to
the thing'..  at that point, I think you especially don't want a
per-blit kernel interface.

But either way, if userspace needs/wants a generic 2d blitter API, it
is probably best to start out with defining a common userspace level
API.  That gets you a lot more flexibility to throw it away and start
again once you realize you've painted yourself into a corner.  And it
is something that could be implemented on top of real gpu's in
addition to things that look more like a mem2mem crtc.

Given the length of time kernel uapi must be supported, vs how fast hw
evolves, I'm leaning towards NAK as well.

BR,
-R


> Regards,
> Christian.
>
>
>>
>> However, the need for commmon API has been already mentioned on the
>> mailing
>> list. Here are some example threads:
>> 1. "RFC: hardware accelerated bitblt using dma engine"
>> http://www.spinics.net/lists/dri-devel/msg114250.html
>> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing)
>> subsystem"
>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
>>
>> The proposed API is heavily inspired by atomic KMS approach - it is also
>> based on DRM objects and their properties. A new DRM object is introduced:
>> framebuffer processor (called fbproc for convenience). Such fbproc objects
>> have a set of standard DRM properties, which describes the operation to be
>> performed by respective hardware module. In typical case those properties
>> are a source fb id and rectangle (x, y, width, height) and destination fb
>> id and rectangle. Optionally a rotation property can be also specified if
>> supported by the given hardware. To perform an operation on image data,
>> userspace provides a set of properties and their values for given fbproc
>> object in a similar way as object and properties are provided for
>> performing atomic page flip / mode setting.
>>
>> The proposed API consists of the 3 new ioctls:
>> - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
>>objects,
>> - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
>> - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
>>set.
>>
>> The proposed API is extensible. Drivers can attach their own, custom
>> properties to add support for more advanced picture processing (for
>> example
>> blending).
>>
>> Please note that this API is intended to be used for simple
>> memory-to-memory
>> image processing hardware not the full-blown GPU blitters, which usually
>> have more features. Typically blitters provides much more operations
>> beside
>> simple pixel copying and operate best if its command queue is controlled
>> from
>> respective dedicated code in userspace.
>>
>> The patchset consist of 4 parts:
>> 1. generic code for DRM core for handling fbproc objects and ioctls
>> 2. example, quick conversion of Exynos Rotator driver to fbproc API
>> 3. libdrm extensions for handling fbproc objects
>> 4. simple example of userspace code for performing 180 degree rotation of
>> the
>> framebuffer
>>
>> Patches were tested on Exynos 4412-based Odroid U3 board, on top
>> of Linux v4.8-rc1 kernel.
>>
>> TODO:
>> 1. agree on the API shape
>> 2. add m

[RFC 0/2] New feature: Framebuffer processors

[Benjamin Gaignard]

In STM SoC we have hardware block doing scaling/colorspace conversion,
we have decide to use v4l2 mem2mem API for it:
https://linuxtv.org/downloads/v4l-dvb-apis/selection-api.html

the code is here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/sti/bdisp?id=refs/tags/v4.8-rc3

Regards,
Benjamin


2016-08-22 17:23 GMT+02:00 Rob Clark :
> On Mon, Aug 22, 2016 at 5:59 AM, Christian König
>  wrote:
>> Am 22.08.2016 um 11:44 schrieb Marek Szyprowski:
>>>
>>> Dear all,
>>>
>>> This is the initial proposal for extending DRM API with generic support
>>> for
>>> hardware modules, which can be used for processing image data from the one
>>> memory buffer to another. Typical memory-to-memory operations are:
>>> rotation, scaling, colour space conversion or mix of them. In this
>>> proposal
>>> I named such hardware modules a framebuffer processors.
>>>
>>> Embedded SoCs are known to have a number of hardware blocks, which perform
>>> such operations. They can be used in paralel to the main GPU module to
>>> offload CPU from processing grapics or video data. One of example use of
>>> such modules is implementing video overlay, which usually requires color
>>> space conversion from NV12 (or similar) to RGB32 color space and scaling
>>> to
>>> target window size.
>>>
>>> Till now there was no generic, hardware independent API for performing
>>> such
>>> operations. Exynos DRM driver has its own custom extension called IPP
>>> (Image Post Processing), but frankly speaking, it is over-engineered and
>>> not
>>> really used in open-source. I didn't indentify similar API in other DRM
>>> drivers, besides those which expose complete support for the whole GPU.
>>
>>
>> Well there are good reasons why we don't have hardware independent command
>> submission.
>>
>> We already tried approaches like this and they didn't worked very well and
>> are generally a pain to get right.
>>
>> So my feeling goes into the direction of a NAK, especially since you didn't
>> explained in this mail why there is need for a common API.
>
> I guess a lot comes down to 'how long before hw designers bolt a CP to
> the thing'..  at that point, I think you especially don't want a
> per-blit kernel interface.
>
> But either way, if userspace needs/wants a generic 2d blitter API, it
> is probably best to start out with defining a common userspace level
> API.  That gets you a lot more flexibility to throw it away and start
> again once you realize you've painted yourself into a corner.  And it
> is something that could be implemented on top of real gpu's in
> addition to things that look more like a mem2mem crtc.
>
> Given the length of time kernel uapi must be supported, vs how fast hw
> evolves, I'm leaning towards NAK as well.
>
> BR,
> -R
>
>
>> Regards,
>> Christian.
>>
>>
>>>
>>> However, the need for commmon API has been already mentioned on the
>>> mailing
>>> list. Here are some example threads:
>>> 1. "RFC: hardware accelerated bitblt using dma engine"
>>> http://www.spinics.net/lists/dri-devel/msg114250.html
>>> 2. "[PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing)
>>> subsystem"
>>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094115.html
>>> https://lists.freedesktop.org/archives/dri-devel/2015-November/094533.html
>>>
>>> The proposed API is heavily inspired by atomic KMS approach - it is also
>>> based on DRM objects and their properties. A new DRM object is introduced:
>>> framebuffer processor (called fbproc for convenience). Such fbproc objects
>>> have a set of standard DRM properties, which describes the operation to be
>>> performed by respective hardware module. In typical case those properties
>>> are a source fb id and rectangle (x, y, width, height) and destination fb
>>> id and rectangle. Optionally a rotation property can be also specified if
>>> supported by the given hardware. To perform an operation on image data,
>>> userspace provides a set of properties and their values for given fbproc
>>> object in a similar way as object and properties are provided for
>>> performing atomic page flip / mode setting.
>>>
>>> The proposed API consists of the 3 new ioctls:
>>> - DRM_IOCTL_MODE_GETFBPROCRESOURCES: to enumerate all available fbproc
>>>objects,
>>> - DRM_IOCTL_MODE_GETFBPROC: to query capabilities of given fbproc object,
>>> - DRM_IOCTL_MODE_FBPROC: to perform operation described by given property
>>>set.
>>>
>>> The proposed API is extensible. Drivers can attach their own, custom
>>> properties to add support for more advanced picture processing (for
>>> example
>>> blending).
>>>
>>> Please note that this API is intended to be used for simple
>>> memory-to-memory
>>> image processing hardware not the full-blown GPU blitters, which usually
>>> have more features. Typically blitters provides much more operations
>>> beside
>>> simple pixel copying and operate best if its command queue is controlled
>>> from
>>> respective dedicated code

[PATCH 0/4] Backported vlv fixes for 4.7.y

[Lyude]

Hope this didn't take too long! Here's the backported versions of the patches
you had trouble applying to stable. The patch for FBC won't be necessary as
that is already present in 4.7.y.

Cheers,
Lyude

Lyude (4):
  drm/i915/vlv: Make intel_crt_reset() per-encoder
  drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
  drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
  drm/i915: Enable polling when we don't have hpd

 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_crt.c|  28 ++--
 drivers/gpu/drm/i915/intel_drv.h|   4 +-
 drivers/gpu/drm/i915/intel_hotplug.c| 117 
 drivers/gpu/drm/i915/intel_runtime_pm.c |   9 +++
 6 files changed, 148 insertions(+), 18 deletions(-)

-- 
2.7.4

[PATCH 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

[Lyude]

This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.

Cc: stable at vger.kernel.org
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_crt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 3fbb6fc..e4dc33e 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,11 +713,11 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }

-static void intel_crt_reset(struct drm_connector *connector)
+static void intel_crt_reset(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = connector->dev;
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crt *crt = intel_attached_crt(connector);
+   struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));

if (INTEL_INFO(dev)->gen >= 5) {
u32 adpa;
@@ -739,7 +739,6 @@ static void intel_crt_reset(struct drm_connector *connector)
  */

 static const struct drm_connector_funcs intel_crt_connector_funcs = {
-   .reset = intel_crt_reset,
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_crt_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -757,6 +756,7 @@ static const struct drm_connector_helper_funcs 
intel_crt_connector_helper_funcs
 };

 static const struct drm_encoder_funcs intel_crt_enc_funcs = {
+   .reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
 };

@@ -902,5 +902,5 @@ void intel_crt_init(struct drm_device *dev)
dev_priv->fdi_rx_config = I915_READ(FDI_RX_CTL(PIPE_A)) & 
fdi_config;
}

-   intel_crt_reset(connector);
+   intel_crt_reset(&crt->base.base);
 }
-- 
2.7.4

[PATCH 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

[Lyude]

While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:

- Disconnect all monitors
- Connect VGA
- Disconnect VGA
- Connect HDMI

Would result in VGA hotplugging becoming disabled, due to the powerwells
getting toggled in the process of connecting HDMI.

Changes since v3:
- Expose intel_crt_reset() through intel_drv.h and call that in
  vlv_display_power_well_init() instead of
  encoder->base.funcs->reset(&encoder->base);
Changes since v2:
- Use intel_encoder structs instead of drm_encoder structs
Changes since v1:
- Instead of handling the register writes ourself, we just reuse
intel_crt_detect()
- Instead of resetting the ADPA during display IRQ installation, we now
  reset them in vlv_display_power_well_init()

Cc: stable at vger.kernel.org
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c| 2 +-
 drivers/gpu/drm/i915/intel_drv.h| 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 7 +++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e4dc33e..d0fb961 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,7 +713,7 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }

-static void intel_crt_reset(struct drm_encoder *encoder)
+void intel_crt_reset(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f7f0f01..14d1dc6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1052,7 +1052,7 @@ void gen8_irq_power_well_pre_disable(struct 
drm_i915_private *dev_priv,

 /* intel_crt.c */
 void intel_crt_init(struct drm_device *dev);
-
+void intel_crt_reset(struct drm_encoder *encoder);

 /* intel_ddi.c */
 void intel_ddi_clk_select(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 7fb1da4..4a3fd3a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -952,6 +952,7 @@ static void vlv_init_display_clock_gating(struct 
drm_i915_private *dev_priv)

 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
 {
+   struct intel_encoder *encoder;
enum pipe pipe;

/*
@@ -987,6 +988,12 @@ static void vlv_display_power_well_init(struct 
drm_i915_private *dev_priv)

intel_hpd_init(dev_priv);

+   /* Re-enable the ADPA, if we have one */
+   for_each_intel_encoder(dev_priv->dev, encoder) {
+   if (encoder->type == INTEL_OUTPUT_ANALOG)
+   intel_crt_reset(&encoder->base);
+   }
+
i915_redisable_vga_power_on(dev_priv->dev);
 }

-- 
2.7.4

[PATCH 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

[Lyude]

One of the things preventing us from using polling is the fact that
calling valleyview_crt_detect_hotplug() when there's a VGA cable
connected results in sending another hotplug. With polling enabled when
HPD is disabled, this results in a scenario like this:

- We enable power wells and reset the ADPA
- output_poll_exec does force probe on VGA, triggering a hpd
- HPD handler waits for poll to unlock dev->mode_config.mutex
- output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex
- HPD handler runs, resets ADPA and brings us back to the start

This results in an endless irq storm getting sent from the ADPA
whenever a VGA connector gets detected in the middle of polling.

Somewhat based off of the "drm/i915: Disable CRT HPD around force
trigger" patch Ville Syrjälä sent a while back

Cc: stable at vger.kernel.org
Cc: Ville Syrjälä 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_crt.c | 18 ++
 drivers/gpu/drm/i915/intel_hotplug.c | 27 +++
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 227a63e..7f8ea58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2791,6 +2791,8 @@ void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
 void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
 bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);

 /* i915_irq.c */
 void i915_queue_hangcheck(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index d0fb961..a3f87d6 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -327,10 +327,25 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = dev->dev_private;
+   bool reenable_hpd;
u32 adpa;
bool ret;
u32 save_adpa;

+   /*
+* Doing a force trigger causes a hpd interrupt to get sent, which can
+* get us stuck in a loop if we're polling:
+*  - We enable power wells and reset the ADPA
+*  - output_poll_exec does force probe on VGA, triggering a hpd
+*  - HPD handler waits for poll to unlock dev->mode_config.mutex
+*  - output_poll_exec shuts off the ADPA, unlocks
+*dev->mode_config.mutex
+*  - HPD handler runs, resets ADPA and brings us back to the start
+*
+* Just disable HPD interrupts here to prevent this
+*/
+   reenable_hpd = intel_hpd_disable(dev_priv, crt->base.hpd_pin);
+
save_adpa = adpa = I915_READ(crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);

@@ -353,6 +368,9 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)

DRM_DEBUG_KMS("valleyview hotplug adpa=0x%x, result %d\n", adpa, ret);

+   if (reenable_hpd)
+   intel_hpd_enable(dev_priv, crt->base.hpd_pin);
+
return ret;
 }

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index bee6730..0c9ee3f 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -511,3 +511,30 @@ void intel_hpd_cancel_work(struct drm_i915_private 
*dev_priv)
cancel_work_sync(&dev_priv->hotplug.hotplug_work);
cancel_delayed_work_sync(&dev_priv->hotplug.reenable_work);
 }
+
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   bool ret = false;
+
+   if (pin == HPD_NONE)
+   return false;
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   if (dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
+   dev_priv->hotplug.stats[pin].state = HPD_DISABLED;
+   ret = true;
+   }
+   spin_unlock_irq(&dev_priv->irq_lock);
+
+   return ret;
+}
+
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   if (pin == HPD_NONE)
+   return;
+
+   spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.stats[pin].state = HPD_ENABLED;
+   spin_unlock_irq(&dev_priv->irq_lock);
+}
-- 
2.7.4

[PATCH 4/4] drm/i915: Enable polling when we don't have hpd

[Lyude]

Unfortunately, there's two situations where we lose hpd right now:
 - Runtime suspend
 - When we've shut off all of the power wells on Valleyview/Cherryview

While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get their display to turn on. For instance; if we boot a Valleyview
system without any monitors connected, it won't need any of it's power
wells and thus shut them off. Since this causes us to lose HPD, this
means that unless the user knows how to ssh into their machine and do a
manual reprobe for monitors, none of the monitors they connect after
booting will actually work.

Eventually we should come up with a better fix then having to enable
polling for this, since this makes rpm a lot less useful, but for now
the infrastructure in i915 just isn't there yet to get hpd in these
situations.

Changes since v1:
 - Add comment explaining the addition of the if
   (!mode_config->poll_running) in intel_hpd_init()
 - Remove unneeded if (!dev->mode_config.poll_enabled) in
   i915_hpd_poll_init_work()
 - Call to drm_helper_hpd_irq_event() after we disable polling
 - Add cancel_work_sync() call to intel_hpd_cancel_work()

Changes since v2:
 - Apparently dev->mode_config.poll_running doesn't actually reflect
   whether or not a poll is currently in progress, and is actually used
   for dynamic module paramter enabling/disabling. So now we instead
   keep track of our own poll_running variable in dev_priv->hotplug
 - Clean i915_hpd_poll_init_work() a little bit

Changes since v3:
 - Remove the now-redundant connector loop in intel_hpd_init(), just
   rely on intel_hpd_poll_enable() for setting connector->polled
   correctly on each connector
 - Get rid of poll_running
 - Don't assign enabled in i915_hpd_poll_init_work before we actually
   lock dev->mode_config.mutex
 - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE()
   for doc purposes
 - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in
   intel_hpd_poll_enable()
 - Add some comments about racing not mattering in intel_hpd_poll_enable

Changes since v4:
 - Rename intel_hpd_poll_enable() to intel_hpd_poll_init()
 - Drop the bool argument from intel_hpd_poll_init()
 - Remove redundant calls to intel_hpd_poll_init()
 - Rename poll_enable_work to poll_init_work
 - Add some kerneldoc for intel_hpd_poll_init()
 - Cross-reference intel_hpd_poll_init() in intel_hpd_init()
 - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init()

Changes since v5:
 - Minor kerneldoc nitpicks

Cc: stable at vger.kernel.org
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.c |  3 ++
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_hotplug.c| 90 -
 drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +
 5 files changed, 88 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 85c4deb..fd3553b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1578,6 +1578,9 @@ static int intel_runtime_suspend(struct device *device)

assert_forcewakes_inactive(dev_priv);

+   if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
+   intel_hpd_poll_init(dev_priv);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7f8ea58..0ed5fd3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -281,6 +281,9 @@ struct i915_hotplug {
u32 short_port_mask;
struct work_struct dig_port_work;

+   struct work_struct poll_init_work;
+   bool poll_enabled;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 14d1dc6..94144a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1346,6 +1346,8 @@ void intel_dsi_init(struct drm_device *dev);

 /* intel_dvo.c */
 void intel_dvo_init(struct drm_device *dev);
+/* intel_hotplug.c */
+void intel_hpd_poll_init(struct drm_i915_private *dev_priv);


 /* legacy fbdev emulation in intel_fbdev.c */
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 0c9ee3f..2c49458 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -453,20 +453,47 @@ void intel_hpd_irq_handler(struct drm_device *dev,
  *
  * This is a separate step from interrupt enabling to simplify the locking 
rules
  * in the driver load and resume code.
+ *
+ * Also see: intel_hpd_poll_init(), which enables connector polling
  */
 void intel_hpd_init(struct dr

[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

[Daniel Vetter]

On Mon, Aug 22, 2016 at 04:05:21PM +0100, Emil Velikov wrote:
> On 22 August 2016 at 15:38, Daniel Vetter  wrote:
> > On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark  wrote:
> >>> That said, _note_ that some applications are built with -C89 -pedantic
> >>> [1] which means that using stdint.h may or may not work as expected.
> >>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
> >>> If the affected programs are proprietary ones we should be safe,
> >>> otherwise we want to update them ~alongside the transition.
> >>
> >> naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
> >> -C89.. problem solved!
> >
> > Yeah, I think sprinkling an
> >
> > #ifdef __kernel___
> > #include 
> > #else
> > #include 
> > #endif
> >
> Guess i was too vague :-]
> 
> I was thinking about the following cases:
>  - using old/incomplete stdint.h - thus the __STDC_VESION__ check.
>  - building non-libdrm software - for libdrm we've (implicitly and
> explicitly) required C99 for a long time.
> 
> > at the opt of all drm uapi headers should be good enough. Or at least
> > those which opt to choose stdints. Since our userspace is very
> > limited, and our headers will never leak to general applications we
> > can just require c99, at least for driver headers. For kms/general drm
> > uapi that might not be the best idea.
> Won't doing so bring more confusion to an already convoluted topic ?
> If we opt for it, let's have a juicy comment that clarifies things.

If we require C99 in libdrm since ages then I think there's no problem
with outright requiring working stdint support in drm uapi headers
everywhere. We still need a bit of #ifdef though I think to impendence
match between kernel and userspace.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #4 from Tom  ---
Created attachment 125945
  --> https://bugs.freedesktop.org/attachment.cgi?id=125945&action=edit
4.7.2 kernel with 2.49 glib2. The display did not go on again after resuming
from suspend.

-- 
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/20160822/08a6b961/attachment-0001.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #5 from Tom  ---
Created attachment 125946
  --> https://bugs.freedesktop.org/attachment.cgi?id=125946&action=edit
4.7.1 kernel with 2.49 glib2. The display blanked temporarily, function
restored for 10 minutes after switching to TTY and back.

-- 
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/20160822/d6c63e21/attachment.html>

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

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

--- Comment #6 from Tom  ---
Created attachment 125947
  --> https://bugs.freedesktop.org/attachment.cgi?id=125947&action=edit
4.7.1 kernel with 2.49 glib2. The display blanked for good after blanking
temporarily.

-- 
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/20160822/2f5f165c/attachment.html>