[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo

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

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

--- Comment #15 from Thomas J. Moore  ---
(In reply to SET from comment #13)
> My HP laptop with AMD A10-7300 (Kaveri iGPU, Topaz dGPU) has a fully working
> X up to kernel 4.9 (not beyond) with these module options applied as such :

Thanks.  I probably went through that particular set of options back when I was
still banging my head against the wall trying to make it work (and tried it
again just now in case it miraculously started working).  It does nothing for
me in 4.9, but may help others.  Right now, turning amdgpu off entirely (via
modprobe.blacklist=amdgpu or nomodeset if compiled in) is the only thing that
reliably works (and thus using efifb instead).  And, in case anyone reading
this thinks otherwise, it's not just X that doesn't work; the console doesn't
work, either (on the rare occasions the console works and stays working, X and
Mesa work as well).  The only thing that consistently works with the amdgpu
driver is the backlight.  The display is still black, and maybe occasionally
will get some stray pixels temporarily lit up during boot, as if the display is
pointing to nonexistent memory.

-- 
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/20170103/7974401b/attachment.html>

Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

[Peter Senna Tschudin]

 Hi Rob,

Thank you for the review.

On 03 January, 2017 23:51 CET, Rob Herring  wrote: 

> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > display bridge.
> > 
> > Cc: Martyn Welch 
> > Cc: Martin Donnelly 
> > Cc: Javier Martinez Canillas 
> > Cc: Enric Balletbo i Serra 
> > Cc: Philipp Zabel 
> > Cc: Rob Herring 
> > Cc: Fabio Estevam 
> > Signed-off-by: Peter Senna Tschudin 
> > ---
> > There was an Acked-by from Rob Herring  for V6, but I 
> > changed
> > the bindings to use i2c_new_secondary_device() so I removed it from the 
> > commit
> > message.
> > 
> >  .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 
> > ++
> 
> Generally, bindings are not organized by vendor. Put in 
> bindings/display/bridge/... instead.

Will change that.

> 
> >  1 file changed, 39 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt 
> > b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > new file mode 100644
> > index 000..1bc6ebf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > @@ -0,0 +1,39 @@
> > +Driver for GE B850v3 LVDS/DP++ display bridge
> > +
> > +Required properties:
> > +  - compatible : should be "ge,b850v3-lvds-dp".
> 
> Isn't '-lvds-dp' redundant? The part# should be enough.

b850v3 is the name of the product, this is why the proposed name. What about, 
b850v3-dp2 dp2 indicating the second DP output?

> 
> > +  - reg : should contain the main address which is used to ack the
> > +interrupts and address for edid.
> > +  - reg-names : comma separeted list of register names. Valid values
> 
> s/separeted/separated/

argh, sorry for this. Will fix it.

> 
> > +are "main", and "edid".
> > +  - interrupt-parent : phandle of the interrupt controller that services
> > +interrupts to the device
> > +  - interrupts : one interrupt should be described here, as in
> > +<0 IRQ_TYPE_LEVEL_HIGH>.
> > +  - port : should describe the video signal connection between the host
> > +and the bridge.
> > +
> > +Example:
> > +
> > +&mux2_i2c2 {
> > +   status = "okay";
> > +   clock-frequency = <10>;
> > +
> > +   b850v3-lvds-dp-bridge at 73  {
> > +   compatible = "ge,b850v3-lvds-dp";
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   reg = <0x73 0x72>;
> > +   reg-names = "main", "edid";
> > +
> > +   interrupt-parent = <&gpio2>;
> > +   interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > +   port {
> > +   b850v3_dp_bridge_in: endpoint {
> > +   remote-endpoint = <&lvds0_out>;
> > +   };
> > +   };
> > +   };
> > +};
> > -- 
> > 2.5.5
> > 

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #10 from smoki  ---
(In reply to Chris Rankin from comment #9)
> (In reply to smoki from comment #8)
> > Does this still work for you with DRI2? Asking becuase DRI2 seems now
> > affected also.
> 
> I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and
> removed the hardware-accelerated v11 plugin from the Yum repository :-|

 Yeah it is not have decode accel anymore, but issue is still there... it
actually does not need to be VDPAU used just that hardware accel enabled.

 Asking as i just tried it now and now happens with DRI2 too, basically flash
whatever default with our driver crashing browser... one just need to wait
enough :D

 Interesting is that it works fine with AMD proprietary driver, so it is our
bug likely... mesa probably.

-- 
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/20170103/178511d8/attachment.html>

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #9 from Chris Rankin  ---
(In reply to smoki from comment #8)
> Does this still work for you with DRI2? Asking becuase DRI2 seems now
> affected also.

I can't say, because Adobe has now "upgraded" its Flash plugin to v24 and
removed the hardware-accelerated v11 plugin from the Yum repository :-|

-- 
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/20170103/4924a152/attachment.html>

Implementing Miracast

[Martin Peres]

On 03/01/17 22:47, Jani Nikula wrote:
> On Fri, 23 Dec 2016, norbert  wrote:
>> Hello,
>> about a year ago there was a discussion about Implementing Miracast on
>> this list:
>>
>> https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html
>>
>> Since then I could not find further information about that topic there.
>> So maybe someone can answer this question:
>> Is that implementation  expected to be available in the near future or
>> did that development stop?
>>
>> Thanks
>> Norbert Wegener
>
> Martin, do you know more?

Hey Norbert,

Good to see interest from you on this aspect. The code is available 
internally and we went through our process to Open Source it. I now have 
it available but need to re-write some parts so as to be able to have it 
under the MIT license, before I can send an RFC.

The project is not cancelled, we just have a lot of things on our plates.

Thanks for your interest!

Martin

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

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

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

--- Comment #23 from Larry <5lokuf+c77xmvwa3y1jk at sharklasers.com> ---

Thank you for going to the trouble of checking internally.

(In reply to Tom St Denis from comment #22)
> Chatting internally one of our developers also has a VERDE with a DID of
> 0x683D.  He claims that with mesa + radeon kmd it works.  
> 
> So at this point the possibilities are 
> 
> 1.  Different mesa/kmd combination from what he uses.

Ok, I'll try the combination you suggested.

> 2.  User error (your install is broken)

Ok, I'll try a fedora livecd.

> 3.  Board damaged (analogue/vbios/etc).
> 
> I doubt it's anything analogue and you probably haven't flashed the vbios.  
> 

I haven't, and remember catalyst works... it must be a software thing.

> <...>
> 
> It would help to get the full lspci info for the board too.  See if the
> revision/subsystem id's match up with our developer.

Here it is again:

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 250X] [1002:683d]

This and Other details/logs/shots posted in original bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=99120

-- 
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/20170103/f18eeb32/attachment.html>

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

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

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

--- Comment #8 from smoki  ---
(In reply to Chris Rankin from comment #5) 
> I don't see your point here. AFAIK the Flash plugin knows nothing about
> either DRI2 or DRI3, and it works fine with DRI2... 

 Does this still work for you with DRI2? Asking becuase DRI2 seems now affected
also.

-- 
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/20170103/6b0dd92d/attachment.html>

Implementing Miracast

[Jani Nikula]

On Fri, 23 Dec 2016, norbert  wrote:
> Hello,
> about a year ago there was a discussion about Implementing Miracast on 
> this list:
>
> https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html
>
> Since then I could not find further information about that topic there.
> So maybe someone can answer this question:
> Is that implementation  expected to be available in the near future or 
> did that development stop?
>
> Thanks
> Norbert Wegener

Martin, do you know more?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] uapi: use wildcards to list files

[Arnd Bergmann]

On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
> 
> In fact, all headers under include/uapi/ should be exported, so let's
> use wildcards.

I think the idea makes a lot of sense: if a header is in uapi, we should
really export it. However, using a wildcard expression seems a bit
backwards here, I think we should make this implicit and not have the
Kbuild file at all.

The "header-y" syntax was originally added back when the uapi headers
were mixed with the internal headers in the same directory. After
David Howells introduced the separate directory for uapi, it has
become a bit redundant.

Can you try to modify scripts/Makefile.headersinst instead so we
can simply remove the Kbuild files entirely?

Arnd

[Bug 99253] Radeon R7 370 / R9 270X/370X PCIe Bus Error: severity=Uncorrected (Fatal)

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

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

Alex Deucher  changed:

   What|Removed |Added

 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
  Component|Other   |Drivers/Gallium/radeonsi

--- Comment #2 from Alex Deucher  ---
This is a GPU hang.  Ideally you'd have some way to reproduceably trigger it.

-- 
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/20170103/35187e5c/attachment.html>

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[vathsala nagaraju]

Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.

Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.

v2: (Ilia Mirkin)
- Remove duplicate bit definition 25:27

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  | 10 +++---
 drivers/gpu/drm/i915/intel_dp.c  |  1 -
 drivers/gpu/drm/i915/intel_psr.c | 29 -
 3 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5ca506a..272a283 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3597,9 +3597,12 @@ enum {
 #define   EDP_PSR_PERF_CNT_MASK0xff

 #define EDP_PSR_DEBUG_CTL  _MMIO(dev_priv->psr_mmio_base + 0x60)
-#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
-#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
-#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
+#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
+#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
+#define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)

 #define EDP_PSR2_CTL   _MMIO(0x6f900)
 #define   EDP_PSR2_ENABLE  (1<<31)
@@ -3614,6 +3617,7 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
+#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)

 #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
 #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9b313a3..0a10858 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3655,7 +3655,6 @@ void intel_dp_set_idle_link_train(struct intel_dp 
*intel_dp)
dev_priv->psr.alpm =
intel_dp_get_alpm_status(intel_dp);
}
-
}

/* Read the eDP Display control capabilities registers */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2e75ef6..19cd4d7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -339,7 +339,9 @@ static void hsw_enable_source_psr2(struct intel_dp 
*intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE |
+   EDP_SU_TRACK_ENABLE |
+   EDP_FRAMES_BEFORE_SU_ENTRY;

if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -512,18 +514,27 @@ void intel_psr_enable(struct intel_dp *intel_dp)
dev_priv->psr.psr2_support = false;
else
skl_psr_setup_su_vsc(intel_dp);
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP |
+  EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+  EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
+   /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing  other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP);
}
-   /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
-* Also mask LPSP to avoid dependency on other drivers that
-* might block runtime_pm besides preventing other hw tracking
-* issues now we can rely on frontbuffer tracking.
-*/
-   I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
-  

[Bug 98238] witcher 2: objects are black when changing lod

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

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

--- Comment #13 from Edmondo Tommasina  ---
This series from Marek fixes the issue for me (RX 470):
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139432.html

-- 
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/20170103/af8f399d/attachment-0001.html>

[Bug 99261] Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot hangs on switch to amdgpudrmfb

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

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

--- Comment #3 from Alex Deucher  ---
(In reply to SET from comment #2)
> I tried to bisect for the first time, here's what I did :
> 
> git bisect start
> git bisect bad
> git bisect good v4.9
> Bisecting: 5782 revisions left to test after this (roughly 13 steps)
> [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag 'staging-4.10-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> 
> ... compile ... The resulting kernel loads amdgpu with a usable X.
> 
> git bisect good 
> Bisecting: 2865 revisions left to test after this (roughly 12 steps)
> [775fadd09e7beac2fc61cc0517629e9fa69bdb56] Merge tag 'armsoc-defconfig' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> 
> Now I don't know what else to do !

if things work:
git bisect good
of things don't work:
git bisect bad
and continue until it's done.

> 
> This patch seems to indicate locating vbios is being reworked, something is
> probably left out.
> https://lists.freedesktop.org/archives/amd-gfx/2016-December/004179.html

That code is not upstream yet.  We haven't really touched the vbios fetching
code in a long time, so if you are seeing a regression, it's probably somewhere
else.

-- 
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/20170103/d833d30b/attachment.html>

[Bug 99261] Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot hangs on switch to amdgpudrmfb

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

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

--- Comment #2 from SET  ---
I tried to bisect for the first time, here's what I did :

git bisect start
git bisect bad
git bisect good v4.9
Bisecting: 5782 revisions left to test after this (roughly 13 steps)
[72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag 'staging-4.10-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

... compile ... The resulting kernel loads amdgpu with a usable X.

git bisect good 
Bisecting: 2865 revisions left to test after this (roughly 12 steps)
[775fadd09e7beac2fc61cc0517629e9fa69bdb56] Merge tag 'armsoc-defconfig' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Now I don't know what else to do !

This patch seems to indicate locating vbios is being reworked, something is
probably left out.
https://lists.freedesktop.org/archives/amd-gfx/2016-December/004179.html

Thx.

-- 
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/20170103/a0fb54b5/attachment.html>

[Bug 99264] Deterministic crash on RX460 "NULL pointer dereference"

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

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

--- Comment #1 from Daniël Mantione  ---
Created attachment 128735
  --> https://bugs.freedesktop.org/attachment.cgi?id=128735&action=edit
Xorg log file (no weird things are visible here)

-- 
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/20170103/f5d98f9f/attachment.html>

[Bug 99264] Deterministic crash on RX460 "NULL pointer dereference"

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

led for non-implemented irq source

-- 
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/20170103/e3c98d96/attachment-0001.html>

[PATCH] drm/via: use get_user_pages_unlocked()

[Lorenzo Stoakes]

Hi All,

Just a gentle ping on this one :)

Cheers, Lorenzo

On 1 November 2016 at 19:43, Lorenzo Stoakes  wrote:
> Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
> and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.
>
> Signed-off-by: Lorenzo Stoakes 
> ---
>  drivers/gpu/drm/via/via_dmablit.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/via/via_dmablit.c 
> b/drivers/gpu/drm/via/via_dmablit.c
> index 1a3ad76..98aae98 100644
> --- a/drivers/gpu/drm/via/via_dmablit.c
> +++ b/drivers/gpu/drm/via/via_dmablit.c
> @@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
> drm_via_dmablit_t *xfer)
> vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
> if (NULL == vsg->pages)
> return -ENOMEM;
> -   down_read(¤t->mm->mmap_sem);
> -   ret = get_user_pages((unsigned long)xfer->mem_addr,
> -vsg->num_pages,
> -(vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE 
> : 0,
> -vsg->pages, NULL);
> -
> -   up_read(¤t->mm->mmap_sem);
> +   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
> +   vsg->num_pages, vsg->pages,
> +   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
> if (ret != vsg->num_pages) {
> if (ret < 0)
> return ret;
> --
> 2.10.2
>



-- 
Lorenzo Stoakes
https://ljs.io

[PATCH v2] drm: add fourcc codes for 16bit R and GR

[Rainer Hochecker]

From: Rainer Hochecker 

Now sent with git send-email:

Signed-off-by: Rainer Hochecker 
---
 include/uapi/drm/drm_fourcc.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index a5890bf..f1ef9cb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -41,10 +41,17 @@ extern "C" {
 /* 8 bpp Red */
 #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */

+/* 16 bpp Red */
+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
+
 /* 16 bpp RG */
 #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
[15:0] R:G 8:8 little endian */
 #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
[15:0] G:R 8:8 little endian */

+/* 32 bpp GR */
+#define DRM_FORMAT_RG32fourcc_code('R', 'G', '3', '2') /* 
[31:0] G:R 16:16 little endian */
+#define DRM_FORMAT_GR32fourcc_code('G', 'R', '3', '2') /* 
[31:0] G:R 16:16 little endian */
+
 /* 8 bpp RGB */
 #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B 
3:3:2 */
 #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R 
2:3:3 */
-- 
2.9.3

[Bug 99120] VERDE 7770 - glxdemo, vlc/glx, weston fail with garbled screen. Elsewhere blurry text rendering when focus lost

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

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

--- Comment #22 from Tom St Denis  ---
Chatting internally one of our developers also has a VERDE with a DID of
0x683D.  He claims that with mesa + radeon kmd it works.  

So at this point the possibilities are 

1.  Different mesa/kmd combination from what he uses.
2.  User error (your install is broken)
3.  Board damaged (analogue/vbios/etc).

I doubt it's anything analogue and you probably haven't flashed the vbios.  

I'm sure our developer is using a combo of mesa git and staging kernel.  So if
you haven't already could you try our staging (which is a couple of weeks out
of date internally but should be fine since there aren't really any significant
radeon/si changes pending) 

https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7

and a recent mesa (or mesa git)?

It would help to get the full lspci info for the board too.  See if the
revision/subsystem id's match up with our developer.

-- 
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/20170103/6734591b/attachment.html>

[PATCH] drm: add fourcc codes for 16bit R and GR

[Eric Engestrom]

On Tuesday, 2017-01-03 17:56:10 +0100, Rainer Hochecker wrote:
> On Mon, Jan 2, 2017 at 3:31 PM, Rainer Hochecker  
> wrote:
> >
> > I chose GR16 because that matches with Mesa texture formats. Unfortunately
> > RG16 is already taken by DRM_FORMAT_RGB565
> > So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
> > all planes.
> >
> > (sorry, gmail included some html links on last attempt)
> >
> > On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä  > linux.intel.com> wrote:
> >>
> >> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
> >> > Hi
> >> >
> >> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker  >> > kodi.tv> wrote:
> >> > > From: Rainer Hochecker 
> >> > >
> >> > > Add fourcc codes for 16bit planes. Required by mesa for
> >> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
> >> > >
> >> > > Signed-off-by: Rainer Hochecker 
> >> > > ---
> >> > >  include/uapi/drm/drm_fourcc.h | 6 ++
> >> > >  1 file changed, 6 insertions(+)
> >> > >
> >> > > diff --git a/include/uapi/drm/drm_fourcc.h 
> >> > > b/include/uapi/drm/drm_fourcc.h
> >> > > index a5890bf..e6ab638 100644
> >> > > --- a/include/uapi/drm/drm_fourcc.h
> >> > > +++ b/include/uapi/drm/drm_fourcc.h
> >> > > @@ -41,10 +41,16 @@ extern "C" {
> >> > >  /* 8 bpp Red */
> >> > >  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* 
> >> > > [7:0] R */
> >> > >
> >> > > +/* 16 bpp Red */
> >> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* 
> >> > > [15:0] R */
> >> > > +
> >> > >  /* 16 bpp RG */
> >> > >  #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', 
> >> > > '8') /* [15:0] R:G 8:8 little endian */
> >> > >  #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', 
> >> > > '8') /* [15:0] G:R 8:8 little endian */
> >> > >
> >> > > +/* 32 bpp GR */
> >> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1', 
> >> > > '6') /* [31:0] G:R 16:16 little endian */
> >> > > +
> >> >
> >> > Shouldn't it be 'G', 'R', '3', '2'?
> >>
> >> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
> >> since we can't fit in the full GR1616 in there. Althogh GR32 could work
> >> too I suppose.
> >>
> >> And what about RG16?
> >>
> >> >
> >> > Also, please put dri-devel on CC.
> >> >
> >> > Thanks
> >> > David
> >> >
> >> > >  /* 8 bpp RGB */
> >> > >  #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* 
> >> > > [7:0] R:G:B 3:3:2 */
> >> > >  #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* 
> >> > > [7:0] B:G:R 2:3:3 */
> >> > > --
> >> > > 2.9.3
> >> > >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>
> >> --
> >> Ville Syrjälä
> >> Intel OTC
> >
> >
> 
> Updated patch as suggested by Ville Syrjälä
> 

You shouldn't send patches using Gmail's web interface: it completely
disregards formatting, breaking any machine-readable text. This patch is
unusable :(

It is usually recommended to send patches using `git send-email`, eg.:
  git send-email \
--in-reply-to CAH0Sn6HhaJmFBz5nsfUD7t0xca8=42+5+ia+qG6oQzevX_NCWg at 
mail.gmail.com \
0001-drm-add-fourcc-codes-for-16bit-R-and-GR.patch

`--in-reply-to` keeps the threads together. You can find the ID of the
message you want to reply to in the "Message-ID:" header

You might also want to use `-v2` when formatting the patches
(`git format-patch -vX`); this lets reviewers follow your revisions by
adjusting the subject of the mail :)

Cheers,
  Eric


> 
> From 29e74ff96e0b7c7a11d1b4131891b83adde621c1 Mon Sep 17 00:00:00 2001
> 
> From: Rainer Hochecker 
> 
> Date: Mon, 2 Jan 2017 11:25:18 +0100
> 
> Subject: [PATCH] drm: add fourcc codes for 16bit R and GR
> 
> 
> Signed-off-by: Rainer Hochecker 
> 
> ---
> 
>  include/uapi/drm/drm_fourcc.h | 7 +++
> 
>  1 file changed, 7 insertions(+)
> 
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> 
> index a5890bf..f1ef9cb 100644
> 
> --- a/include/uapi/drm/drm_fourcc.h
> 
> +++ b/include/uapi/drm/drm_fourcc.h
> 
> @@ -41,10 +41,17 @@ extern "C" {
> 
>  /* 8 bpp Red */
> 
>  #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
> 
> 
> 
> +/* 16 bpp Red */
> 
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */
> 
> +
> 
>  /* 16 bpp RG */
> 
>  #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /* [15:0] R:G
> 8:8 little endian */
> 
>  #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /* [15:0] G:R
> 8:8 little endian */
> 
> 
> 
> +/* 32 bpp GR */
> 
> +#define DRM_FORMAT_RG32 fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> 
> +#define DRM_FORMAT_GR32 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
> 16:16 little endian */
> 
> +
> 
>  /* 8 bpp RGB */
> 
>  #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
> R:G:B 3:3:2 */
> 
> 

[PATCH 5/5] drm/sti: do not check hw scaling if mode is not set

[Fabien Dessenne]

Fix a division by 0 case : in some cases, when the HQVDP plane is being
disabled atomic_check() is called with "mode->clock = 0".
In that case, do not check for scaling capabilities.

Change-Id: I7fb752ab394211c3deafa149f52cfb2bca244e84
Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 3fd6f3a..fe36e0f 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1035,9 +1035,9 @@ static int sti_hqvdp_atomic_check(struct drm_plane 
*drm_plane,
src_w = state->src_w >> 16;
src_h = state->src_h >> 16;

-   if (!sti_hqvdp_check_hw_scaling(hqvdp, mode,
-   src_w, src_h,
-   dst_w, dst_h)) {
+   if (mode->clock && !sti_hqvdp_check_hw_scaling(hqvdp, mode,
+  src_w, src_h,
+  dst_w, dst_h)) {
DRM_ERROR("Scaling beyond HW capabilities\n");
return -EINVAL;
}
-- 
2.7.4

[PATCH 4/5] drm/sti: do not sync SETPROPERTY on vblank if not ATOMIC

[Fabien Dessenne]

If the client does not set the ATOMIC capability, do not wait for vblank
before returning an DRM_IOCTL_MODE_OBJ_SETPROPERTY call.

In this way, a legacy framework (eg non-atomic Weston) can call several
SETPROPERTY within the same Vsync cycle.

This is implemented by setting the legacy_cursor_update flag, to behave
the same way as DRM_IOCTL_MODE_CURSOR (not vblank synced).

Change-Id: I6b6134eca57eca399bdda006ab1cb8280d4002d4
Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_cursor.c |  2 +-
 drivers/gpu/drm/sti/sti_gdp.c|  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c  |  2 +-
 drivers/gpu/drm/sti/sti_plane.c  | 54 
 drivers/gpu/drm/sti/sti_plane.h  |  2 ++
 5 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index ea0dbae..d7e9f8a 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -349,7 +349,7 @@ static const struct drm_plane_funcs 
sti_cursor_plane_helpers_funcs = {
.update_plane = sti_plane_update_plane,
.disable_plane = sti_plane_disable_plane,
.destroy = sti_cursor_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
+   .set_property = sti_plane_set_property,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index a379bbe..6fa5042 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -885,7 +885,7 @@ static const struct drm_plane_funcs 
sti_gdp_plane_helpers_funcs = {
.update_plane = sti_plane_update_plane,
.disable_plane = sti_plane_disable_plane,
.destroy = sti_gdp_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
+   .set_property = sti_plane_set_property,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 65ca43f..3fd6f3a 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1255,7 +1255,7 @@ static const struct drm_plane_funcs 
sti_hqvdp_plane_helpers_funcs = {
.update_plane = sti_plane_update_plane,
.disable_plane = sti_plane_disable_plane,
.destroy = sti_hqvdp_destroy,
-   .set_property = drm_atomic_helper_plane_set_property,
+   .set_property = sti_plane_set_property,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 22cf30d..c58fe1b 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -132,6 +132,60 @@ void sti_plane_init_property(struct sti_plane *plane,
 plane->drm_plane.base.id, sti_plane_to_str(plane));
 }

+int sti_plane_set_property(struct drm_plane *plane,
+  struct drm_property *property, uint64_t val)
+{
+   /*
+* Forked from drm_atomic_helper_plane_set_property().
+* Here we do not wait for vblank if the client is not atomic, so
+* DRM_IOCTL_MODE_OBJ_SETPROPERTY returns before vblank.
+*/
+   struct drm_atomic_state *state;
+   struct drm_plane_state *plane_state;
+   struct sti_private *private = plane->dev->dev_private;
+   int ret = 0;
+
+   state = drm_atomic_state_alloc(plane->dev);
+   if (!state)
+   return -ENOMEM;
+
+   /* ->set_property is always called with all locks held. */
+   state->acquire_ctx = plane->dev->mode_config.acquire_ctx;
+retry:
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto fail;
+   }
+
+   ret = drm_atomic_plane_set_property(plane, plane_state,
+   property, val);
+   if (ret)
+   goto fail;
+
+   if (!private->filp->atomic)
+   state->legacy_cursor_update = true;
+
+   ret = drm_atomic_commit(state);
+   if (ret != 0)
+   goto fail;
+
+   /* Driver takes ownership of state on successful commit. */
+   return 0;
+fail:
+   if (ret == -EDEADLK)
+   goto backoff;
+
+   drm_atomic_state_free(state);
+
+   return ret;
+backoff:
+   drm_atomic_state_clear(state);
+   drm_atomic_legacy_backoff(state);
+
+   goto retry;
+}
+
 int sti_plane_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
   struct drm_framebuffer *fb,
   

[PATCH 3/5] drm/sti: do not sync SETPLANE on vblank if not ATOMIC

[Fabien Dessenne]

If the client does not set the ATOMIC capability, do not wait for vblank
before returning an DRM_IOCTL_MODE_SETPLANE call.

In this way, a legacy framework (eg non-atomic Weston) can call several
SETPLANE within the same Vsync cycle.

This is implemented by setting the legacy_cursor_update flag, to behave
the same way as DRM_IOCTL_MODE_CURSOR (not vblank synced).

Change-Id: Ia241b6c88411c675bf589c17d4a44db6d02f669f
Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_cursor.c |   4 +-
 drivers/gpu/drm/sti/sti_gdp.c|   4 +-
 drivers/gpu/drm/sti/sti_hqvdp.c  |   4 +-
 drivers/gpu/drm/sti/sti_plane.c  | 144 +++
 drivers/gpu/drm/sti/sti_plane.h  |   8 +++
 5 files changed, 158 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index cca75bd..ea0dbae 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -346,8 +346,8 @@ static int sti_cursor_late_register(struct drm_plane 
*drm_plane)
 }

 static const struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
+   .update_plane = sti_plane_update_plane,
+   .disable_plane = sti_plane_disable_plane,
.destroy = sti_cursor_destroy,
.set_property = drm_atomic_helper_plane_set_property,
.reset = sti_plane_reset,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 81df309..a379bbe 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -882,8 +882,8 @@ static int sti_gdp_late_register(struct drm_plane 
*drm_plane)
 }

 static const struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
+   .update_plane = sti_plane_update_plane,
+   .disable_plane = sti_plane_disable_plane,
.destroy = sti_gdp_destroy,
.set_property = drm_atomic_helper_plane_set_property,
.reset = sti_plane_reset,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index f88130f..65ca43f 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1252,8 +1252,8 @@ static int sti_hqvdp_late_register(struct drm_plane 
*drm_plane)
 }

 static const struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
-   .update_plane = drm_atomic_helper_update_plane,
-   .disable_plane = drm_atomic_helper_disable_plane,
+   .update_plane = sti_plane_update_plane,
+   .disable_plane = sti_plane_disable_plane,
.destroy = sti_hqvdp_destroy,
.set_property = drm_atomic_helper_plane_set_property,
.reset = sti_plane_reset,
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index ca4b371..22cf30d 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -7,6 +7,7 @@
  */

 #include 
+#include 
 #include 
 #include 

@@ -130,3 +131,146 @@ void sti_plane_init_property(struct sti_plane *plane,
DRM_DEBUG_DRIVER("drm plane:%d mapped to %s\n",
 plane->drm_plane.base.id, sti_plane_to_str(plane));
 }
+
+int sti_plane_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  int crtc_x, int crtc_y,
+  unsigned int crtc_w, unsigned int crtc_h,
+  uint32_t src_x, uint32_t src_y,
+  uint32_t src_w, uint32_t src_h)
+{
+   /*
+* Forked from drm_atomic_helper_update_plane().
+* Here we do not wait for vblank if the client is not atomic, so
+* DRM_IOCTL_MODE_SETPLANE returns before vblank.
+*/
+
+   struct drm_atomic_state *state;
+   struct drm_plane_state *plane_state;
+   struct sti_private *private = plane->dev->dev_private;
+   int ret = 0;
+
+   state = drm_atomic_state_alloc(plane->dev);
+   if (!state)
+   return -ENOMEM;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+retry:
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto fail;
+   }
+
+   ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
+   if (ret != 0)
+   goto fail;
+   drm_atomic_set_fb_for_plane(plane_state, fb);
+   plane_state->crtc_x = crtc_x;
+   plane_state->crtc_y = crtc_y;
+   plane_state->crtc_w = crtc_w;
+   plane_state->crtc_h = crtc_h;
+   plane_state->src_x = src_x;
+   plane_state->src_y = src_y;
+   plane_state->src_w = src_w;
+   plane_state->src_h = src_h;
+
+   if ((plane == crtc->cursor) || !private->filp->atomic)
+   state->legacy_cursor_update = true;
+
+

[PATCH 2/5] drm/sti: add drm_file to sti_private

[Fabien Dessenne]

Store the drm_file *filp in sti_private, so the driver can access more
configuration information like the client capabilities.

Change-Id: Ib8f305f1a41b4fdfe56f80294cd79e5dc44433ee
Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_drv.c | 10 ++
 drivers/gpu/drm/sti/sti_drv.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 9a9b9a2..63febf8 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -170,6 +170,15 @@ static int sti_atomic_check(struct drm_device *dev,
return ret;
 }

+static int sti_drm_open(struct drm_device *ddev, struct drm_file *filp)
+{
+   struct sti_private *private = ddev->dev_private;
+
+   private->filp = filp;
+
+   return 0;
+}
+
 static void sti_output_poll_changed(struct drm_device *ddev)
 {
struct sti_private *private = ddev->dev_private;
@@ -226,6 +235,7 @@ static const struct file_operations sti_driver_fops = {
 static struct drm_driver sti_driver = {
.driver_features = DRIVER_MODESET |
DRIVER_GEM | DRIVER_PRIME | DRIVER_ATOMIC,
+   .open = sti_drm_open,
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
index f9276cd..de22b0d 100644
--- a/drivers/gpu/drm/sti/sti_drv.h
+++ b/drivers/gpu/drm/sti/sti_drv.h
@@ -19,12 +19,15 @@ struct sti_tvout;
  * @compo: compositor
  * @plane_zorder_property: z-order property for CRTC planes
  * @drm_dev:   drm device
+ * @fbdev: framebuffer dev cma struct
+ * @drm_file:  drm file private data
  */
 struct sti_private {
struct sti_compositor *compo;
struct drm_property *plane_zorder_property;
struct drm_device *drm_dev;
struct drm_fbdev_cma *fbdev;
+   struct drm_file *filp;
 };

 extern struct platform_driver sti_tvout_driver;
-- 
2.7.4

[PATCH 1/5] drm/sti: use atomic_helper for commit

[Fabien Dessenne]

Since nonblocking atomic commits are now supported, the driver can
now use drm_atomic_helper_commit().

Change-Id: I3e49872b0dc9e79ca652bec7e5cd29d912c86382
Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_drv.c | 83 +--
 drivers/gpu/drm/sti/sti_drv.h |  6 
 2 files changed, 1 insertion(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index ff71e25..9a9b9a2 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -150,52 +150,6 @@ static void sti_drm_dbg_cleanup(struct drm_minor *minor)
 1, minor);
 }

-static void sti_atomic_schedule(struct sti_private *private,
-   struct drm_atomic_state *state)
-{
-   private->commit.state = state;
-   schedule_work(&private->commit.work);
-}
-
-static void sti_atomic_complete(struct sti_private *private,
-   struct drm_atomic_state *state)
-{
-   struct drm_device *drm = private->drm_dev;
-
-   /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
-   drm_atomic_helper_commit_modeset_disables(drm, state);
-   drm_atomic_helper_commit_planes(drm, state, 0);
-   drm_atomic_helper_commit_modeset_enables(drm, state);
-
-   drm_atomic_helper_wait_for_vblanks(drm, state);
-
-   drm_atomic_helper_cleanup_planes(drm, state);
-   drm_atomic_state_put(state);
-}
-
-static void sti_atomic_work(struct work_struct *work)
-{
-   struct sti_private *private = container_of(work,
-   struct sti_private, commit.work);
-
-   sti_atomic_complete(private, private->commit.state);
-}
-
 static int sti_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
 {
@@ -216,38 +170,6 @@ static int sti_atomic_check(struct drm_device *dev,
return ret;
 }

-static int sti_atomic_commit(struct drm_device *drm,
-struct drm_atomic_state *state, bool nonblock)
-{
-   struct sti_private *private = drm->dev_private;
-   int err;
-
-   err = drm_atomic_helper_prepare_planes(drm, state);
-   if (err)
-   return err;
-
-   /* serialize outstanding nonblocking commits */
-   mutex_lock(&private->commit.lock);
-   flush_work(&private->commit.work);
-
-   /*
-* This is the point of no return - everything below never fails except
-* when the hw goes bonghits. Which means we can commit the new state on
-* the software side now.
-*/
-
-   drm_atomic_helper_swap_state(state, true);
-
-   drm_atomic_state_get(state);
-   if (nonblock)
-   sti_atomic_schedule(private, state);
-   else
-   sti_atomic_complete(private, state);
-
-   mutex_unlock(&private->commit.lock);
-   return 0;
-}
-
 static void sti_output_poll_changed(struct drm_device *ddev)
 {
struct sti_private *private = ddev->dev_private;
@@ -271,7 +193,7 @@ static const struct drm_mode_config_funcs 
sti_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = sti_output_poll_changed,
.atomic_check = sti_atomic_check,
-   .atomic_commit = sti_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };

 static void sti_mode_config_init(struct drm_device *dev)
@@ -352,9 +274,6 @@ static int sti_init(struct drm_device *ddev)
dev_set_drvdata(ddev->dev, ddev);
private->drm_dev = ddev;

-   mutex_init(&private->commit.lock);
-   INIT_WORK(&private->commit.work, sti_atomic_work);
-
drm_mode_config_init(ddev);

sti_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
index 78ebe5e..f9276cd 100644
--- a/drivers/gpu/drm/sti/sti_drv.h
+++ b/drivers/gpu/drm/sti/sti_drv.h
@@ -25,12 +25,6 @@ struct sti_private {
struct drm_property *plane_zorder_property;
struct drm_device *drm_dev;
struct drm_fbdev_cma *fbdev;
-
-   struct {
-   struct drm_atomic_state *state;
-   struct work_struct work;
-

[PATCH 0/5] drm/sti: do not sync legacy IOCTL on vblank if not ATOMIC

[Fabien Dessenne]

These patches allow a legacy framework (eg non-atomic Weston) to call
several SETPLANE within the same Vsync cycle.
- [PATCH 1/5] drm/sti: use atomic_helper for commit
- [PATCH 2/5] drm/sti: add drm_file to sti_private
- [PATCH 3/5] drm/sti: do not sync SETPLANE on vblank if not ATOMIC
- [PATCH 4/5] drm/sti: do not sync SETPROPERTY on vblank if not ATOMIC
- [PATCH 5/5] drm/sti: do not check hw scaling if mode is not set

Fabien

[PATCH] drm: add fourcc codes for 16bit R and GR

[Rainer Hochecker]

On Mon, Jan 2, 2017 at 3:31 PM, Rainer Hochecker  wrote:
>
> I chose GR16 because that matches with Mesa texture formats. Unfortunately
> RG16 is already taken by DRM_FORMAT_RGB565
> So GR32 / RG32 might be better. All other codes in fourcc.h seem to sum up
> all planes.
>
> (sorry, gmail included some html links on last attempt)
>
> On Mon, Jan 2, 2017 at 3:05 PM, Ville Syrjälä  linux.intel.com> wrote:
>>
>> On Mon, Jan 02, 2017 at 01:23:23PM +0100, David Herrmann wrote:
>> > Hi
>> >
>> > On Mon, Jan 2, 2017 at 11:41 AM, Rainer Hochecker  
>> > wrote:
>> > > From: Rainer Hochecker 
>> > >
>> > > Add fourcc codes for 16bit planes. Required by mesa for
>> > > eglCreateImageKHR to access P010 surfaces created by vaapi.
>> > >
>> > > Signed-off-by: Rainer Hochecker 
>> > > ---
>> > >  include/uapi/drm/drm_fourcc.h | 6 ++
>> > >  1 file changed, 6 insertions(+)
>> > >
>> > > diff --git a/include/uapi/drm/drm_fourcc.h 
>> > > b/include/uapi/drm/drm_fourcc.h
>> > > index a5890bf..e6ab638 100644
>> > > --- a/include/uapi/drm/drm_fourcc.h
>> > > +++ b/include/uapi/drm/drm_fourcc.h
>> > > @@ -41,10 +41,16 @@ extern "C" {
>> > >  /* 8 bpp Red */
>> > >  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] 
>> > > R */
>> > >
>> > > +/* 16 bpp Red */
>> > > +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* 
>> > > [15:0] R */
>> > > +
>> > >  /* 16 bpp RG */
>> > >  #define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') 
>> > > /* [15:0] R:G 8:8 little endian */
>> > >  #define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') 
>> > > /* [15:0] G:R 8:8 little endian */
>> > >
>> > > +/* 32 bpp GR */
>> > > +#define DRM_FORMAT_GR16fourcc_code('G', 'R', '1', '6') 
>> > > /* [31:0] G:R 16:16 little endian */
>> > > +
>> >
>> > Shouldn't it be 'G', 'R', '3', '2'?
>>
>> The name should be _GR1616. Using GR16 for the fourcc seems OK to me
>> since we can't fit in the full GR1616 in there. Althogh GR32 could work
>> too I suppose.
>>
>> And what about RG16?
>>
>> >
>> > Also, please put dri-devel on CC.
>> >
>> > Thanks
>> > David
>> >
>> > >  /* 8 bpp RGB */
>> > >  #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] 
>> > > R:G:B 3:3:2 */
>> > >  #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] 
>> > > B:G:R 2:3:3 */
>> > > --
>> > > 2.9.3
>> > >
>> > ___
>> > dri-devel mailing list
>> > dri-devel at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Ville Syrjälä
>> Intel OTC
>
>

Updated patch as suggested by Ville Syrjälä


>From 29e74ff96e0b7c7a11d1b4131891b83adde621c1 Mon Sep 17 00:00:00 2001

From: Rainer Hochecker 

Date: Mon, 2 Jan 2017 11:25:18 +0100

Subject: [PATCH] drm: add fourcc codes for 16bit R and GR


Signed-off-by: Rainer Hochecker 

---

 include/uapi/drm/drm_fourcc.h | 7 +++

 1 file changed, 7 insertions(+)


diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h

index a5890bf..f1ef9cb 100644

--- a/include/uapi/drm/drm_fourcc.h

+++ b/include/uapi/drm/drm_fourcc.h

@@ -41,10 +41,17 @@ extern "C" {

 /* 8 bpp Red */

 #define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */



+/* 16 bpp Red */

+#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R */

+

 /* 16 bpp RG */

 #define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /* [15:0] R:G
8:8 little endian */

 #define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /* [15:0] G:R
8:8 little endian */



+/* 32 bpp GR */

+#define DRM_FORMAT_RG32 fourcc_code('R', 'G', '3', '2') /* [31:0] G:R
16:16 little endian */

+#define DRM_FORMAT_GR32 fourcc_code('G', 'R', '3', '2') /* [31:0] G:R
16:16 little endian */

+

 /* 8 bpp RGB */

 #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
R:G:B 3:3:2 */

 #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0]
B:G:R 2:3:3 */

-- 

2.9.3

linux-next: build failure after merge of the drm-intel-fixes tree

[Zhenyu Wang]

On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> > Alex, I liked to have kvmgt related mdev interface change be merged through
> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> > below fix in your tree? I think in general for possible interface change in
> > future we still need a pull request for i915 to resolve dependence earlier.
> 
> Hi Zhenyu,
> 
> Hopefully this abstraction will help to isolate vendor drivers from
> mdev API changes in the future.  I can certainly roll this patch into
> the original to maintain bisectability.  I want to get these changes in
> for rc3, will a pull request for the i915 changes be sent this week?

Send to Jani who is managing i915 fixes pull.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170103/07b628ec/attachment.sig>

[PATCH] drm/imx: imx-tve: Make the 'dac' regulator optional

[Fabio Estevam]

From: Fabio Estevam 

Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
regulator_set_voltage()") exposes the following probe issue:

63ff.tve supply dac not found, using dummy regulator
imx-drm display-subsystem: failed to bind 63ff.tve (ops imx_tve_ops): -22

When the 'dac' regulator is not passed in the device tree,
devm_regulator_get() will return NULL and when regulator_set_voltage()
is called it returns an error.

Fix the issue by making the 'dac' regulator optional.

Fixes: deb65870b5d9d ("drm/imx: imx-tve: check the value returned by 
regulator_set_voltage()")
Cc:  # 4.8+
Signed-off-by: Fabio Estevam 
---
 drivers/gpu/drm/imx/imx-tve.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 3b602ee..cec0e12 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -619,7 +619,7 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
return ret;
}

-   tve->dac_reg = devm_regulator_get(dev, "dac");
+   tve->dac_reg = devm_regulator_get_optional(dev, "dac");
if (!IS_ERR(tve->dac_reg)) {
ret = regulator_set_voltage(tve->dac_reg, 275, 275);
if (ret)
-- 
2.7.4

[Bug 98784] Talos Principle rendering flickering garbage on start instead of its logo and loading squares

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

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

--- Comment #8 from network723 at rkmail.ru ---
I confirm, LIBGL_DRI3_DISABLE=1 fixes flickering in Talos, blender and firefox'
opengl-accelerated videos

-- 
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/20170103/d568d5d3/attachment.html>

[v1] gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap

[Arvind Yadav]

Here, pci_iomap can fail, handle this case and return -ENOMEM.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/mgag200/mgag200_main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c 
b/drivers/gpu/drm/mgag200/mgag200_main.c
index e79cbc2..fb03e30 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -145,6 +145,8 @@ static int mga_vram_init(struct mga_device *mdev)
}

mem = pci_iomap(mdev->dev->pdev, 0, 0);
+   if (!mem)
+   return -ENOMEM;

mdev->mc.vram_size = mga_probe_vram(mdev, mem);

-- 
1.9.1

[PATCH v4 3/3] ASoC: hdmi-codec: add channel mapping control

[Arnaud Pouliquen]

Add user interface to provide channel mapping.
In a first step this control is read only.

As TLV type, the control provides all configuration available for
HDMI sink(ELD), and provides current channel mapping selected by codec
based on ELD and number of channels specified by user on open.
When control is called before the number of the channel is specified
(i.e. hw_params is set), it returns all channels set to UNKNOWN.

Signed-off-by: Arnaud Pouliquen 
---
 sound/soc/codecs/hdmi-codec.c | 380 +-
 1 file changed, 379 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 90b5948..dc6715a 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,258 @@ struct hdmi_device {
 LIST_HEAD(hdmi_device_list);

 #define DAI_NAME_SIZE 16
+
+#define HDMI_CODEC_CHMAP_IDX_UNKNOWN  -1
+
+struct hdmi_codec_channel_map_table {
+   unsigned char map;  /* ALSA API channel map position */
+   unsigned long spk_mask; /* speaker position bit mask */
+};
+
+/*
+ * CEA speaker placement for HDMI 1.4:
+ *
+ *  FL  FLC   FC   FRC   FR   FRW
+ *
+ *  LFE
+ *
+ *  RL  RLC   RC   RRC   RR
+ *
+ *  Speaker placement has to be extended to support HDMI 2.0
+ */
+enum hdmi_codec_cea_spk_placement {
+   FL  = BIT(0),   /* Front Left   */
+   FC  = BIT(1),   /* Front Center */
+   FR  = BIT(2),   /* Front Right  */
+   FLC = BIT(3),   /* Front Left Center*/
+   FRC = BIT(4),   /* Front Right Center   */
+   RL  = BIT(5),   /* Rear Left*/
+   RC  = BIT(6),   /* Rear Center  */
+   RR  = BIT(7),   /* Rear Right   */
+   RLC = BIT(8),   /* Rear Left Center */
+   RRC = BIT(9),   /* Rear Right Center*/
+   LFE = BIT(10),  /* Low Frequency Effect */
+};
+
+/*
+ * cea Speaker allocation structure
+ */
+struct hdmi_codec_cea_spk_alloc {
+   const int ca_id;
+   unsigned int n_ch;
+   unsigned long mask;
+};
+
+/* Channel maps  stereo HDMI */
+const struct snd_pcm_chmap_elem hdmi_codec_stereo_chmaps[] = {
+   { .channels = 2,
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+   { }
+};
+
+/* Channel maps for multi-channel playbacks, up to 8 n_ch */
+const struct snd_pcm_chmap_elem hdmi_codec_8ch_chmaps[] = {
+   { .channels = 2, /* CA_ID 0x00 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+   { .channels = 4, /* CA_ID 0x01 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_NA } },
+   { .channels = 4, /* CA_ID 0x02 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_FC } },
+   { .channels = 4, /* CA_ID 0x03 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_FC } },
+   { .channels = 6, /* CA_ID 0x04 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 6, /* CA_ID 0x05 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 6, /* CA_ID 0x06 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_FC, SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 6, /* CA_ID 0x07 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_FC, SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 6, /* CA_ID 0x08 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR } },
+   { .channels = 6, /* CA_ID 0x09 */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR } },
+   { .channels = 6, /* CA_ID 0x0A */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_FC, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR } },
+   { .channels = 6, /* CA_ID 0x0B */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_FC, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR } },
+   { .channels = 8, /* CA_ID 0x0C */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_NA,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR,
+  SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 8, /* CA_ID 0x0D */
+ .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR, SNDRV_CHMAP_LFE,
+  SNDRV_CHMAP_NA, SNDRV_CHMAP_RL, SNDRV_CHMAP_RR,
+  SNDRV_CHMAP_RC, SNDRV_CHMAP_NA } },
+   { .channels = 8, /* CA_ID

[PATCH v4 2/3] ASoC: core: add optional pcm_new callback for DAI driver

[Arnaud Pouliquen]

During probe, DAIs can need to perform some actions that requests
the knowledge of the pcm runtime handle.
The callback is called during DAIs linking, after PCM device creation.
For instance this can be used to add relationship between a DAI pcm
control and the pcm device.

Signed-off-by: Arnaud Pouliquen 
---
 include/sound/soc-dai.h |  3 +++
 sound/soc/soc-core.c| 28 
 2 files changed, 31 insertions(+)

diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 964b7de..1c8b579 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -231,6 +231,9 @@ struct snd_soc_dai_driver {
int (*resume)(struct snd_soc_dai *dai);
/* compress dai */
int (*compress_new)(struct snd_soc_pcm_runtime *rtd, int num);
+   /* Optional Callback used at pcm creation*/
+   int (*pcm_new)(struct snd_soc_pcm_runtime *rtd,
+  struct snd_soc_dai *dai);
/* DAI is also used for the control bus */
bool bus_control;

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c0bbcd9..b8c5813 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1552,6 +1552,27 @@ static int soc_probe_dai(struct snd_soc_dai *dai, int 
order)
return 0;
 }

+static int soc_link_dai_pcm_new(struct snd_soc_dai **dais, int num_dais,
+   struct snd_soc_pcm_runtime *rtd)
+{
+   int i, ret = 0;
+
+   for (i = 0; i < num_dais; ++i) {
+   struct snd_soc_dai_driver *drv = dais[i]->driver;
+
+   if (!rtd->dai_link->no_pcm && drv->pcm_new)
+   ret = drv->pcm_new(rtd, dais[i]);
+   if (ret < 0) {
+   dev_err(dais[i]->dev,
+   "ASoC: Failed to bind %s with pcm device\n",
+   dais[i]->name);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int soc_link_dai_widgets(struct snd_soc_card *card,
struct snd_soc_dai_link *dai_link,
struct snd_soc_pcm_runtime *rtd)
@@ -1663,6 +1684,13 @@ static int soc_probe_link_dais(struct snd_soc_card *card,
   dai_link->stream_name, ret);
return ret;
}
+   ret = soc_link_dai_pcm_new(&cpu_dai, 1, rtd);
+   if (ret < 0)
+   return ret;
+   ret = soc_link_dai_pcm_new(rtd->codec_dais,
+  rtd->num_codecs, rtd);
+   if (ret < 0)
+   return ret;
} else {
INIT_DELAYED_WORK(&rtd->delayed_work,
codec2codec_close_delayed_work);
-- 
1.9.1

[PATCH v4 1/3] DRM: add help to get ELD speaker allocation

[Arnaud Pouliquen]

Add helper to allow users to retrieve the speaker allocations without
knowledge of the ELD structure.

Signed-off-by: Arnaud Pouliquen 
Reviewed-by: Jani Nikula 
---
 include/drm/drm_edid.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c3a7d44..de93543 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -248,6 +248,7 @@ struct detailed_timing {
 # define DRM_ELD_AUD_SYNCH_DELAY_MAX   0xfa/* 500 ms */

 #define DRM_ELD_SPEAKER7
+# define DRM_ELD_SPEAKER_MASK  0x7f
 # define DRM_ELD_SPEAKER_RLRC  (1 << 6)
 # define DRM_ELD_SPEAKER_FLRC  (1 << 5)
 # define DRM_ELD_SPEAKER_RC(1 << 4)
@@ -415,6 +416,18 @@ static inline int drm_eld_size(const uint8_t *eld)
 }

 /**
+ * drm_eld_get_spk_alloc - Get speaker allocation
+ * @eld: pointer to an ELD memory structure
+ *
+ * The returned value is the speakers mask. User has to use %DRM_ELD_SPEAKER
+ * field definitions to identify speakers.
+ */
+static inline u8 drm_eld_get_spk_alloc(const uint8_t *eld)
+{
+   return eld[DRM_ELD_SPEAKER] & DRM_ELD_SPEAKER_MASK;
+}
+
+/**
  * drm_eld_get_conn_type - Get device type hdmi/dp connected
  * @eld: pointer to an ELD memory structure
  *
-- 
1.9.1

[PATCH v4 0/3] Generic HDMI codec: Add channel mapping control

[Arnaud Pouliquen]

Aim of this patch is to add  'Playback Channel Map' control to export 
audio capabilities in term of HDMI sink speakers allocation.

V4:
Abandon "Generic HDMI codec: Add channel mapping control" patch as it generates 
warnings during compilation.

Workaround is to define 2 constant tables in hdmi-codec.c to declare channel 
mapping.
One for stereo and one for multichannel.
Consequence is that the behaviour is changed: 
   The chmap multichannel table export the HDMI CA configuration (tlv) and not 
only the one suuported by HDMI sink.
Furthermore the chmap control .get handler is overwritten to allow to export to 
user the selected configuration. 

 - "ASoC: hdmi-codec: add channel mapping control":
- add hdmi_codec_stereo_chmaps and hdmi_codec_8ch_chmaps tables.
- implement chmap control get handler. 
 - "DRM: add help to get ELD speaker allocation"
 => No delta vs V2.
 - "ALSA pcm: allow non constant snd_pcm_chmap_elem"
 => abandonned
 - "ASoC: core: add optional pcm_new callback for DAI driver"
 => No delta vs V2.

V3:
 - "ASoC: hdmi-codec: add channel mapping control":
 => Minor fixes:
 - select stereo speaker config by default if HDMI cable unplugged
 - fix compilation warning. 
 - "DRM: add help to get ELD speaker allocation"
 => No delta vs V2.
 - "ALSA pcm: allow non constant snd_pcm_chmap_elem"
 => No delta vs V2.
 - "ASoC: core: add optional pcm_new callback for DAI driver"
 => No delta vs V2.

V2:
In this version I use chmap helper functions from pcm_lib.c. 
It is quite tricky to use it from ASoC due to the relation chip of the controls
with the pcm runtime.
After several tries, my conclusion is that it must be handled in ASoC DAI 
driver.
Main reason is that the DAI driver can not provide snd_pcm_chmap struct
through kcontrol structure. But this induces that soc-core provides pcm runtime
structure to DAI driver during probe.

Base on this conclusion. I reworked my patches by adding 2 
new patches in patch-set
1)  ALSA pcm: allow non constant snd_pcm_chmap_elem
   This patch allows to handle non constant channel mapping. As ELD
   information can change during runtime it is mandatory to properly 
   handle the feature.
   In term of compatibility with legacy it should be straightforward,
   as update just consists in suppressing the 'const' constraint.

2)  ASoC: core: add optional pcm_new callback for DAI driver
This is the only way i found to be able to use 
snd_pcm_add_chmap_ctls and associated controls helper functions.
From my point of view, this is the more simple way to add relationship
between DAI and associated pcm devices.
   Notice that this patch, if accepted, makes the following one obsolete,
   as it also answer to the associated topic:
  [PATCH v5 0/2] ALSA controls management using index/device/sub-devices fields
  (http://www.spinics.net/lists/alsa-devel/msg57639.html).

If you estimate that this it not reasonable i will come back to my first 
version.

V1:
This patch follows discussion initiate here: 
[RFC] ASOC: HDMI audio info frame speaker allocation
http://www.spinics.net/lists/alsa-devel/msg57363.html

The code is fully inspired from HDA driver.
On hw_param, HDMI sink speaker capabilities are exported via TLV ops
and  a CEA allocation is choson, based on ELD information and the number of
channels requested by user.

Mains differences with HDA implementation are:
 - Control is read only
 - Channel swap is not supported. Consequence is that unused channel in
   the mid of CEA audio infoframe channel mapping are considered as
   active.
   example for channel allocation 0x02: FL, FR, 0, FC)
This configuration is only available for a 4 channels stream.
  - Channel allocation table has been reordered and HDMI 2.0 is not
supported.

Arnaud Pouliquen (4):
  DRM: add help to get ELD speaker allocation
  ASoC: core: add optional pcm_new callback for DAI driver
  ASoC: hdmi-codec: add channel mapping control

 include/drm/drm_edid.h|  13 ++
 include/sound/soc-dai.h   |   3 +
 sound/soc/codecs/hdmi-codec.c | 380 +-
 sound/soc/soc-core.c  |  28 
 4 files changed, 423 insertions(+), 1 deletion(-)

-- 
1.9.1

[PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp

[Rob Herring]

On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
> 
> Cc: Martyn Welch 
> Cc: Martin Donnelly 
> Cc: Javier Martinez Canillas 
> Cc: Enric Balletbo i Serra 
> Cc: Philipp Zabel 
> Cc: Rob Herring 
> Cc: Fabio Estevam 
> Signed-off-by: Peter Senna Tschudin 
> ---
> There was an Acked-by from Rob Herring  for V6, but I 
> changed
> the bindings to use i2c_new_secondary_device() so I removed it from the commit
> message.
> 
>  .../devicetree/bindings/ge/b850v3-lvds-dp.txt  | 39 
> ++

Generally, bindings are not organized by vendor. Put in 
bindings/display/bridge/... instead.

>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> 
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt 
> b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 000..1bc6ebf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,39 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> +  - compatible : should be "ge,b850v3-lvds-dp".

Isn't '-lvds-dp' redundant? The part# should be enough.

> +  - reg : should contain the main address which is used to ack the
> +interrupts and address for edid.
> +  - reg-names : comma separeted list of register names. Valid values

s/separeted/separated/

> +are "main", and "edid".
> +  - interrupt-parent : phandle of the interrupt controller that services
> +interrupts to the device
> +  - interrupts : one interrupt should be described here, as in
> +<0 IRQ_TYPE_LEVEL_HIGH>.
> +  - port : should describe the video signal connection between the host
> +and the bridge.
> +
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <10>;
> +
> + b850v3-lvds-dp-bridge at 73  {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73 0x72>;
> + reg-names = "main", "edid";
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> -- 
> 2.5.5
> 

[PATCH v2 01/13] devicetree/bindings: display: Document common panel properties

[Rob Herring]

On Mon, Dec 19, 2016 at 10:54 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Monday 19 Dec 2016 09:38:49 Rob Herring wrote:
>> On Sun, Dec 18, 2016 at 2:54 PM, Laurent Pinchart wrote:
>> > On Tuesday 29 Nov 2016 20:23:41 Laurent Pinchart wrote:
>> >> On Tuesday 29 Nov 2016 09:14:09 Rob Herring wrote:
>> >>> On Tue, Nov 29, 2016 at 2:27 AM, Laurent Pinchart wrote:
>>  On Tuesday 22 Nov 2016 11:36:55 Laurent Pinchart wrote:
>> > On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
>> >> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
>> >>> Document properties common to several display panels in a central
>> >>> location that can be referenced by the panel device tree bindings.
>> >>
>> >> Looks good. Just one comment...
>> >>
>> >> [...]
>> >>
>> >>> +Connectivity
>> >>> +
>> >>> +
>> >>> +- ports: Panels receive video data through one or multiple
>> >>> connections. While
>> >>> +  the nature of those connections is specific to the panel type,
>> >>> the
>> >>> +  connectivity is expressed in a standard fashion using ports as
>> >>> specified in
>> >>> +  the device graph bindings defined in
>> >>> +  Documentation/devicetree/bindings/graph.txt.
>> >>
>> >> We allow panels to either use graph binding or be a child of the
>> >> display controller.
>> >
>> > I knew that some display controllers use a phandle to the panel (see
>> > the fsl,panel and nvidia,panel properties), but I didn't know we had
>> > panels as children of display controller nodes. I don't think we
>> > should allow that for anything but DSI panels, as the DT hierarchy is
>> > based on control buses. Are you sure we have other panels instantiated
>> > through that mechanism ?
>> >>>
>> >>> Some panels have no control bus, so were do we place them?
>> >>
>> >> I'd say under the root node, like all similar control-less devices.
>> >>
>> >>> I would say the hierarchy is based on buses with a preference for the
>> >>> control bus when there are multiple buses. I'm not a fan of just
>> >>> sticking things are the top level.
>> >>
>> >> OK, so much for my comment a few lines up :-)
>> >>
>> >> The problem with placing non-DSI panels as children of the display
>> >> controller and not using OF graph is that the panel bindings become
>> >> dependent of the display controller being used. A display controller
>> >> using OF graph would require the panel to do the same, while a display
>> >> controller expecting a panel child node (with a specific name) would
>> >> require DT properties for the panel node.
>>
>> Not sure I follow.
>
> Sorry, I meant "would not requite DT properties".
>
>> They become dependent on the controller driver to probe the panel, but the
>> contents of the panel node would not be controller dependent.
>
> If a display controller uses OF graph then the panel DT node has to declare
> ports. If the display controller doesn't use OF graph but instead expects the
> panel to be a direct subnode, or points to the panel using a property such as
> fsl,panel, then the panel DT node will not have ports.

The controller should just ask for the panel via a common function.
That function should then look for either a child node (called
'panel') or a graph port. Of course, for more complex cases, only OF
graph may work. It really just the simple case of a controller with a
single output and single panel that I'm talking about.


>> >> I'm also not sure the complexity of OF graph is really that prohibitive
>> >> if you compare it to panels as child nodes. To get the panel driver to
>> >> bind to the panel DT node the display controller driver would need to
>> >> create a platform device for the panel and register it. That's not very
>> >> difficult, but parsing a single port and endpoint isn't either (and we
>> >> could even provide a helper function for that, a version of
>> >> of_drm_find_panel() that would take as an argument the display controller
>> >> device node instead of the panel device node).
>> >
>> > Ping ?
>> >
>> > I'd like to standardize on one model for panel DT bindings, but I'm not
>> > sure that can be achieved given that we already have multiple competing
>> > models. In any case, is that blocking to merge this patch ? I only
>> > describe one connectivity model here as that's what my panel driver
>> > needs, but I have no issue adding more models later when needed. I
>> > believe this patch is a good step forward already.
>>
>> It is an improvement which I appreciate, so yes I guess we can address
>> it later when needed.
>
> Thank you. Can I get your ack then ? :-)

Yes.

Acked-by: Rob Herring 

Unix Device Memory Allocation project

[James Jones]

On 01/03/2017 04:06 PM, Marek Olšák wrote:
> On Wed, Jan 4, 2017 at 12:43 AM, James Jones  wrote:
>> On 01/03/2017 03:38 PM, Marek Olšák wrote:
>>>
>>> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter  wrote:

 On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák  wrote:
>>>
>>> We've had per buffer metadata in Radeon since KMS, which I believe
>>> first
>>> appeared in 2009. It's 4 bytes large and is used to communicate tiling
>>> flags between Mesa, DDX, and the kernel display code. It was a widely
>>> accepted solution back then and Red Hat was the main developer. So
>>> yeah,
>>> pretty much all people except Intel were collaborating on "sneaking"
>>> this
>>> in in 2009. I think radeon driver developers deserve an apology for
>>> that
>>> language.
>>>
>>> Amdgpu extended that metadata to 8 bytes and it's used in the same way
>>> as
>>> radeon. Additionally, amdgpu added opaque metadata having 256 bytes
>>> for use
>>> by userspace drivers only. The kernel driver isn't supposed to read it
>>> or
>>> parse it. The format is negotiated between userspace driver developers
>>> for
>>> sharing of more complex allocations than 2D displayable surfaces.
>>
>>
>> Metadata needed for kms (what Christian also pointed out) is what
>> everyone
>> did (intel included) and I think that's perfectly reasonable. And I was
>> aware of that radeon is doing that since the dawn of ages since
>> forever.
>>
>> What I think is not really ok is opaque metadata blobs that the kernel
>> never ever inspect, but just carries around. That essentially means
>> you're
>> reimplementing some bad form of IPC, and I dont think that's something
>> the
>> drm subsystem (or dma-buf) really should be doing. Because you still
>> have
>> that real protocol in userspace (dri2/3, wayland, whatever), but now
>> with
>> a side channel with no documented ordering and synchronization. It gets
>> the job done for single-vendor buffer metadata transport, but as soon
>> as
>> there's more than one vendor, or as soon as you need to reallocate
>> buffers
>> dynamically because the usage changes it gets bad imo (and I've seen
>> what
>
>
> The metadata is immutable after allocation, so it's not a
> communication channel. There is no synchronization or ordering needed
> for immutable metadata. That implies that a shared buffer can't be
> reused for an entirely different purpose. It can only be used as-is or
> freed.
>
> For suballocated memory, the idea is to reallocate it as a separate
> buffer on the first "handle" export, so that shared suballocated
> buffers don't exist.


 Yeah, once it becomes mutable the fun starts imo. I didn't realize
 that you're treating it strictly immutable since at least the kernel
 ioctl has both set and get (and that's the thing I looked at).
 Immutable stuff shouldn't be any problem (except that of course it
 won't work cross-driver in any fashion)

>> that looks like on android in various forms). And that consensus (at
>> least
>> among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
>> meeting we've had over 5 years ago. Not sure we're gaining anything
>> with a
>> "who's older" competition.
>>
>> Anyways it's there and it's uabi so will never disappear. Just wanted
>> to
>> make sure it's clear that for dma-buf we've discussed this years ago,
>> and
>> decided it wasn't a great idea. And I think that's still correct.
>
>
> The arguments against blob metadata sound reasonable to me. I'm pretty
> sceptic that window system protocols will make driver-specific
> metadata blobs redundant anytime soon though. It seems the protocols
> don't get much attention nowadays and there is no incentive to do
> things differently in that area. At least that's how it appears to me,
> but I'm not involved in that.


 Folks are working on protocols again, at least I think the plan is to
 make all that shared buffer allocation dance also work over
 compositor/client situation (would be a bit pointless without that).
 And agreed there'll always be driver-specific stuff which is opaque to
 everyone else, but I hope at least in the future that all gets
 shuffled around through protocol extensions. And not in the way every
 Android gfx stack seems to work, where everyone has their own
 vendor-private ipc-over-dma-buf thing. Wayland definitely got this
 right, both protocol versioning and being able to add any kind of
 new/vendor-private protocol endpoints to any wayland protocol. X is a
 lot more pain, but since it finally looks like the world is switching
 away from it we might get away with  a simpler protocol there. At
 least

[Bug 99261] Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot hangs on switch to amdgpudrmfb

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

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

--- Comment #1 from Alex Deucher  ---
The driver is not able to find the vbios:
Jan  3 16:28:52 hp2 kernel: [   10.626851] [drm:amdgpu_get_bios [amdgpu]]
*ERROR* Unable to locate a BIOS ROM

Possibly the related to this:
https://bugzilla.kernel.org/show_bug.cgi?id=141741

-- 
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/20170103/b03de105/attachment-0001.html>

[Bug 99261] Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot hangs on switch to amdgpudrmfb

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #128729|text/x-log  |text/plain
  mime type||

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

[Bug 99261] Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot hangs on switch to amdgpudrmfb

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

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

Bug ID: 99261
   Summary: Kernel 4.10-rc2 on APU with Kaveri + Topaz : boot
hangs on switch to amdgpudrmfb
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: nmset at netcourrier.com

Created attachment 128729
  --> https://bugs.freedesktop.org/attachment.cgi?id=128729&action=edit
kernel log on boot failure

Since testing kernel 4.10 preRC, RC1 and RC2, my laptop hangs on boot at line 
fb : switch to amdgpudrmfb from EVI VGA.

A few specs :

APU : AMD A10-7300 Radeon R6, 10 Compute Cores 4C+6G (from /proc/cpuinfo).
iGPU : 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri
HDMI/DP Audio Controller
dGPU : 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz
XT [Radeon R7 M260/M265 / M340/M360 / M440/M445]
Xorg : 1.18.4, on Arch Linux
Boot command line : BOOT_IMAGE=/boot/vmlinuz-linux
root=UUID=76ba28b4-683c-4a39-96ef-6a1105905567 rw acpi=off (I have to use
acpi=off on 4.10-rcX to go beyonf initramfs loading)

Whatever amdgpu module's option combination I use is of no avail. These ones
(aspm=0 bapm=0 runpm=0 powerplay=1) allow me to use amdgpu on 4.9.

Attached is a kernel.log file where there is a stack trace of amdgpu module
crashing.

I can use 4.10-rc2 on my desktop with RX480 and an old Phenom II x6 CPU.

I am posting here in the hope of getting developer attention to care about this
module's crashing, on KMS seemingly. If I use nomodeset, the module gets
loaded, but obviously, there's no X session beyond.

Regards.

-- 
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/20170103/b021f9c1/attachment.html>

[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off

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

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

--- Comment #12 from Matthias Nagel  ---
Created attachment 128728
  --> https://bugs.freedesktop.org/attachment.cgi?id=128728&action=edit
4th dump 2017-01-03

Anybody working on this? Anything I can help to push this one forward?

I still see this error and I can nearly reliably trigger it.

-- 
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/20170103/80125025/attachment.html>

[Bug 95206] Display port bandwidth regression

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

-- 
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/20170103/194d7295/attachment.html>

[Bug 95206] Display port bandwidth regression

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

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

--- Comment #18 from Alex Deucher  ---
(In reply to mrj from comment #15)
> Sorry Alex, I wasn't clear.
> 
> It's the fixed version that (I've now verified) is causing the Radeon HD6320
> problem as described here
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1402293

Please open a new bug as this one has been addressed.

-- 
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/20170103/fee1bd8d/attachment.html>

[PATCH v2 3/3] arm: sti: update sti-cec for HPD notifier support

[Benjamin Gaignard]

To use HPD notifier sti CEC driver needs to get phandle
of the hdmi device.

Signed-off-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stih407-family.dtsi | 12 
 arch/arm/boot/dts/stih410.dtsi| 13 +
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index c8b2944..592d235 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -756,18 +756,6 @@
 <&clk_s_c0_flexgen CLK_ETH_PHY>;
};

-   cec: sti-cec at 094a087c {
-   compatible = "st,stih-cec";
-   reg = <0x94a087c 0x64>;
-   clocks = <&clk_sysin>;
-   clock-names = "cec-clk";
-   interrupts = ;
-   interrupt-names = "cec-irq";
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_cec0_default>;
-   resets = <&softreset STIH407_LPM_SOFTRESET>;
-   };
-
rng10: rng at 08a89000 {
compatible  = "st,rng";
reg = <0x08a89000 0x1000>;
diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
index 281a124..e8c01f7 100644
--- a/arch/arm/boot/dts/stih410.dtsi
+++ b/arch/arm/boot/dts/stih410.dtsi
@@ -259,5 +259,18 @@
clocks = <&clk_sysin>;
interrupts = ;
};
+
+   sti-cec at 094a087c {
+   compatible = "st,stih-cec";
+   reg = <0x94a087c 0x64>;
+   clocks = <&clk_sysin>;
+   clock-names = "cec-clk";
+   interrupts = ;
+   interrupt-names = "cec-irq";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_cec0_default>;
+   resets = <&softreset STIH407_LPM_SOFTRESET>;
+   st,hdmi-handle = <&sti_hdmi>;
+   };
};
 };
-- 
1.9.1

[PATCH v2 2/3] stih-cec: add HPD notifier support

[Benjamin Gaignard]

By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.

Update the bindings documentation the new hdmi phandle.

Signed-off-by: Benjamin Gaignard 
---
version 2:
- use HPD notifier
- move stih-cec out of staging
- split driver code and devicetree change in two patches
---
 .../devicetree/bindings/media/stih-cec.txt |   2 +
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sti/cec/Makefile|   1 +
 drivers/media/platform/sti/cec/stih-cec.c  | 404 +
 drivers/staging/media/Kconfig  |   2 -
 drivers/staging/media/Makefile |   1 -
 drivers/staging/media/st-cec/Kconfig   |   8 -
 drivers/staging/media/st-cec/Makefile  |   1 -
 drivers/staging/media/st-cec/TODO  |   7 -
 drivers/staging/media/st-cec/stih-cec.c| 379 ---
 11 files changed, 418 insertions(+), 398 deletions(-)
 create mode 100644 drivers/media/platform/sti/cec/Makefile
 create mode 100644 drivers/media/platform/sti/cec/stih-cec.c
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/Makefile
 delete mode 100644 drivers/staging/media/st-cec/TODO
 delete mode 100644 drivers/staging/media/st-cec/stih-cec.c

diff --git a/Documentation/devicetree/bindings/media/stih-cec.txt 
b/Documentation/devicetree/bindings/media/stih-cec.txt
index 71c4b2f..7d82121 100644
--- a/Documentation/devicetree/bindings/media/stih-cec.txt
+++ b/Documentation/devicetree/bindings/media/stih-cec.txt
@@ -9,6 +9,7 @@ Required properties:
  - pinctrl-names: Contains only one value - "default"
  - pinctrl-0: Specifies the pin control groups used for CEC hardware.
  - resets: Reference to a reset controller
+ - st,hdmi-handle: Phandle to the HMDI controller

 Example for STIH407:

@@ -22,4 +23,5 @@ sti-cec at 094a087c {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cec0_default>;
resets = <&softreset STIH407_LPM_SOFTRESET>;
+   st,hdmi-handle = <&hdmi>;
 };
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0d7acf1..e5f680e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -408,6 +408,16 @@ config VIDEO_SAMSUNG_S5P_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.

+config VIDEO_STI_HDMI_CEC
+   tristate "STMicroelectronics STiH4xx HDMI CEC driver"
+   depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (ARCH_STI || COMPILE_TEST)
+   select HPD_NOTIFIER
+   ---help---
+ This is a driver for STIH4xx HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #V4L_CEC_DRIVERS

 menuconfig V4L_TEST_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index ad3bf22..01b689c 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC)+= exynos-gsc/
 obj-$(CONFIG_VIDEO_STI_BDISP)  += sti/bdisp/
 obj-$(CONFIG_VIDEO_STI_HVA)+= sti/hva/
 obj-$(CONFIG_DVB_C8SECTPFE)+= sti/c8sectpfe/
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC)   += sti/cec/

 obj-$(CONFIG_BLACKFIN)  += blackfin/

diff --git a/drivers/media/platform/sti/cec/Makefile 
b/drivers/media/platform/sti/cec/Makefile
new file mode 100644
index 000..f07905e
--- /dev/null
+++ b/drivers/media/platform/sti/cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_STI_HDMI_CEC) += stih-cec.o
diff --git a/drivers/media/platform/sti/cec/stih-cec.c 
b/drivers/media/platform/sti/cec/stih-cec.c
new file mode 100644
index 000..e50e916
--- /dev/null
+++ b/drivers/media/platform/sti/cec/stih-cec.c
@@ -0,0 +1,404 @@
+/*
+ * STIH4xx CEC driver
+ * Copyright (C) STMicroelectronic SA 2016
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define CEC_NAME   "stih-cec"
+
+/* CEC registers  */
+#define CEC_CLK_DIV   0x0
+#define CEC_CTRL  0x4
+#define CEC_IRQ_CTRL  0x8
+#define CEC_STATUS0xC
+#define CEC_EXT_STATUS0x10
+#define CEC_TX_CTRL   0x14
+#define CEC_FREE_TIME_THRESH  0x18
+#define CEC_BIT_TOUT_THRESH   0x1C
+#define CEC_BIT_PULSE_THRESH  0x20

[PATCH v2 1/3] sti: hdmi: add HPD notifier support

[Benjamin Gaignard]

Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.

Signed-off-by: Benjamin Gaignard 

---
version 2:
- use HPD notifier instead of HDMI notifier
---
 drivers/gpu/drm/sti/Kconfig|  1 +
 drivers/gpu/drm/sti/sti_hdmi.c | 14 ++
 drivers/gpu/drm/sti/sti_hdmi.h |  3 +++
 3 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index acd7286..f5c9572 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -8,5 +8,6 @@ config DRM_STI
select DRM_PANEL
select FW_LOADER
select SND_SOC_HDMI_CODEC if SND_SOC
+   select HPD_NOTIFIER
help
  Choose this option to enable DRM on STM stiH4xx chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b076..d32a383 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -786,6 +786,8 @@ static void sti_hdmi_disable(struct drm_bridge *bridge)
clk_disable_unprepare(hdmi->clk_pix);

hdmi->enabled = false;
+
+   hpd_event_disconnect(hdmi->notifier);
 }

 static void sti_hdmi_pre_enable(struct drm_bridge *bridge)
@@ -892,6 +894,9 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
if (!edid)
goto fail;

+   hpd_event_new_edid(hdmi->notifier, edid,
+  EDID_LENGTH * (edid->extensions + 1));
+
count = drm_add_edid_modes(connector, edid);
drm_mode_connector_update_edid_property(connector, edid);
drm_edid_to_eld(connector, edid);
@@ -949,10 +954,12 @@ struct drm_connector_helper_funcs 
sti_hdmi_connector_helper_funcs = {

if (hdmi->hpd) {
DRM_DEBUG_DRIVER("hdmi cable connected\n");
+   hpd_event_connect(hdmi->notifier);
return connector_status_connected;
}

DRM_DEBUG_DRIVER("hdmi cable disconnected\n");
+   hpd_event_disconnect(hdmi->notifier);
return connector_status_disconnected;
 }

@@ -1464,6 +1471,10 @@ static int sti_hdmi_probe(struct platform_device *pdev)
goto release_adapter;
}

+   hdmi->notifier = hpd_notifier_get(&pdev->dev);
+   if (!hdmi->notifier)
+   goto release_adapter;
+
hdmi->reset = devm_reset_control_get(dev, "hdmi");
/* Take hdmi out of reset */
if (!IS_ERR(hdmi->reset))
@@ -1483,11 +1494,14 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(&pdev->dev);

+   hpd_event_disconnect(hdmi->notifier);
+
i2c_put_adapter(hdmi->ddc_adapt);
if (hdmi->audio_pdev)
platform_device_unregister(hdmi->audio_pdev);
component_del(&pdev->dev, &sti_hdmi_ops);

+   hpd_notifier_put(hdmi->notifier);
return 0;
 }

diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 119bc35..2109c97 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -8,6 +8,7 @@
 #define _STI_HDMI_H_

 #include 
+#include 
 #include 

 #include 
@@ -77,6 +78,7 @@ enum sti_hdmi_modes {
  * @audio_pdev: ASoC hdmi-codec platform device
  * @audio: hdmi audio parameters.
  * @drm_connector: hdmi connector
+ * @notifier: hotplug detect notifier
  */
 struct sti_hdmi {
struct device dev;
@@ -102,6 +104,7 @@ struct sti_hdmi {
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
+   struct hpd_notifier *notifier;
 };

 u32 hdmi_read(struct sti_hdmi *hdmi, int offset);
-- 
1.9.1

[PATCH v2 0/3] video/sti/cec: add HPD notifier support

[Benjamin Gaignard]

This patch series following what Hans is doing on exynos to support
hotplug detect notifier code.

It add support of HPD in sti_hdmi drm driver and stih-cec driver which
move out of staging.

Those patches should be applied on top of Hans branch exynos4-cec.

I have tested hdmi notifier by pluging/unpluging HDMI cable and check
the value of the physical address with "cec-ctl --tuner".
"cec-compliance -A" is also functional.

version 2:
- use HPD notifier instead of HDMI notifier
- move stih-cec out of staging
- rebase code on top of git://linuxtv.org/hverkuil/media_tree.git exynos4-cec
  branch
- split DT modifications in a separate patch

Regards,
Benjamin

Benjamin Gaignard (3):
  sti: hdmi: add HPD notifier support
  stih-cec: add HPD notifier support
  arm: sti: update sti-cec for HPD notifier support

 .../devicetree/bindings/media/stih-cec.txt |   2 +
 arch/arm/boot/dts/stih407-family.dtsi  |  12 -
 arch/arm/boot/dts/stih410.dtsi |  13 +
 drivers/gpu/drm/sti/Kconfig|   1 +
 drivers/gpu/drm/sti/sti_hdmi.c |  14 +
 drivers/gpu/drm/sti/sti_hdmi.h |   3 +
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/sti/cec/Makefile|   1 +
 drivers/media/platform/sti/cec/stih-cec.c  | 404 +
 drivers/staging/media/Kconfig  |   2 -
 drivers/staging/media/Makefile |   1 -
 drivers/staging/media/st-cec/Kconfig   |   8 -
 drivers/staging/media/st-cec/Makefile  |   1 -
 drivers/staging/media/st-cec/TODO  |   7 -
 drivers/staging/media/st-cec/stih-cec.c| 379 ---
 16 files changed, 449 insertions(+), 410 deletions(-)
 create mode 100644 drivers/media/platform/sti/cec/Makefile
 create mode 100644 drivers/media/platform/sti/cec/stih-cec.c
 delete mode 100644 drivers/staging/media/st-cec/Kconfig
 delete mode 100644 drivers/staging/media/st-cec/Makefile
 delete mode 100644 drivers/staging/media/st-cec/TODO
 delete mode 100644 drivers/staging/media/st-cec/stih-cec.c

-- 
1.9.1

Unix Device Memory Allocation project

[James Jones]

On 01/03/2017 03:38 PM, Marek Olšák wrote:
> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter  wrote:
>> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák  wrote:
> We've had per buffer metadata in Radeon since KMS, which I believe first
> appeared in 2009. It's 4 bytes large and is used to communicate tiling
> flags between Mesa, DDX, and the kernel display code. It was a widely
> accepted solution back then and Red Hat was the main developer. So yeah,
> pretty much all people except Intel were collaborating on "sneaking" this
> in in 2009. I think radeon driver developers deserve an apology for that
> language.
>
> Amdgpu extended that metadata to 8 bytes and it's used in the same way as
> radeon. Additionally, amdgpu added opaque metadata having 256 bytes for 
> use
> by userspace drivers only. The kernel driver isn't supposed to read it or
> parse it. The format is negotiated between userspace driver developers for
> sharing of more complex allocations than 2D displayable surfaces.

 Metadata needed for kms (what Christian also pointed out) is what everyone
 did (intel included) and I think that's perfectly reasonable. And I was
 aware of that radeon is doing that since the dawn of ages since forever.

 What I think is not really ok is opaque metadata blobs that the kernel
 never ever inspect, but just carries around. That essentially means you're
 reimplementing some bad form of IPC, and I dont think that's something the
 drm subsystem (or dma-buf) really should be doing. Because you still have
 that real protocol in userspace (dri2/3, wayland, whatever), but now with
 a side channel with no documented ordering and synchronization. It gets
 the job done for single-vendor buffer metadata transport, but as soon as
 there's more than one vendor, or as soon as you need to reallocate buffers
 dynamically because the usage changes it gets bad imo (and I've seen what
>>>
>>> The metadata is immutable after allocation, so it's not a
>>> communication channel. There is no synchronization or ordering needed
>>> for immutable metadata. That implies that a shared buffer can't be
>>> reused for an entirely different purpose. It can only be used as-is or
>>> freed.
>>>
>>> For suballocated memory, the idea is to reallocate it as a separate
>>> buffer on the first "handle" export, so that shared suballocated
>>> buffers don't exist.
>>
>> Yeah, once it becomes mutable the fun starts imo. I didn't realize
>> that you're treating it strictly immutable since at least the kernel
>> ioctl has both set and get (and that's the thing I looked at).
>> Immutable stuff shouldn't be any problem (except that of course it
>> won't work cross-driver in any fashion)
>>
 that looks like on android in various forms). And that consensus (at least
 among folks involved in dma-buf) goes back to the dma-buf kickoff 3-day
 meeting we've had over 5 years ago. Not sure we're gaining anything with a
 "who's older" competition.

 Anyways it's there and it's uabi so will never disappear. Just wanted to
 make sure it's clear that for dma-buf we've discussed this years ago, and
 decided it wasn't a great idea. And I think that's still correct.
>>>
>>> The arguments against blob metadata sound reasonable to me. I'm pretty
>>> sceptic that window system protocols will make driver-specific
>>> metadata blobs redundant anytime soon though. It seems the protocols
>>> don't get much attention nowadays and there is no incentive to do
>>> things differently in that area. At least that's how it appears to me,
>>> but I'm not involved in that.
>>
>> Folks are working on protocols again, at least I think the plan is to
>> make all that shared buffer allocation dance also work over
>> compositor/client situation (would be a bit pointless without that).
>> And agreed there'll always be driver-specific stuff which is opaque to
>> everyone else, but I hope at least in the future that all gets
>> shuffled around through protocol extensions. And not in the way every
>> Android gfx stack seems to work, where everyone has their own
>> vendor-private ipc-over-dma-buf thing. Wayland definitely got this
>> right, both protocol versioning and being able to add any kind of
>> new/vendor-private protocol endpoints to any wayland protocol. X is a
>> lot more pain, but since it finally looks like the world is switching
>> away from it we might get away with  a simpler protocol there. At
>> least all the tricky reallocation dances seem to matter a lot more on
>> mobile/tablets/phones, and there Wayland starts to rule.
>
> I've been thinking about it, and it looks like we're gonna continue
> using immutable per-BO metadata (buffer layout, tiling description,
> compression flags). The reasons are that everything else is less
> economical, and the current "modifier" work done in EGL/GBM is
> insufficient for our hardware - we need approx

[PATCH] uapi: use wildcards to list files

[Nicolas Dichtel]

Regularly, when a new header is created in include/uapi/, the developer
forgets to add it in the corresponding Kbuild file. This error is usually
detected after the release is out.

In fact, all headers under include/uapi/ should be exported, so let's
use wildcards.

After this patch, the following files, which were not exported, are now
exported:
drm/vgem_drm.h
drm/armada_drm.h
drm/omap_drm.h
drm/etnaviv_drm.h
rdma/qedr-abi.h
linux/bcache.h
linux/kfd_ioctl.h
linux/cryptouser.h
linux/kcm.h
linux/kcov.h
linux/seg6_iptunnel.h
linux/stm.h
linux/seg6.h
linux/auto_dev-ioctl.h
linux/userio.h
linux/pr.h
linux/wil6210_uapi.h
linux/nilfs2_ondisk.h
linux/hash_info.h
linux/seg6_genl.h
linux/seg6_hmac.h
linux/batman_adv.h
linux/nsfs.h
linux/qrtr.h
linux/btrfs_tree.h
linux/coresight-stm.h
linux/dma-buf.h
linux/module.h
linux/lightnvm.h
linux/nilfs2_api.h

Signed-off-by: Nicolas Dichtel 
---

This patch is built against linus tree. I don't know if it should be
done against antoher tree.

Comments are welcomed,
Nicolas

 include/uapi/asm-generic/Kbuild|  36 +--
 include/uapi/drm/Kbuild|  22 +-
 include/uapi/linux/Kbuild  | 463 +
 include/uapi/linux/android/Kbuild  |   2 +-
 include/uapi/linux/byteorder/Kbuild|   3 +-
 include/uapi/linux/caif/Kbuild |   3 +-
 include/uapi/linux/can/Kbuild  |   6 +-
 include/uapi/linux/dvb/Kbuild  |   9 +-
 include/uapi/linux/hdlc/Kbuild |   2 +-
 include/uapi/linux/hsi/Kbuild  |   2 +-
 include/uapi/linux/iio/Kbuild  |   3 +-
 include/uapi/linux/isdn/Kbuild |   2 +-
 include/uapi/linux/mmc/Kbuild  |   2 +-
 include/uapi/linux/netfilter/Kbuild|  88 +-
 include/uapi/linux/netfilter/ipset/Kbuild  |   5 +-
 include/uapi/linux/netfilter_arp/Kbuild|   3 +-
 include/uapi/linux/netfilter_bridge/Kbuild |  18 +-
 include/uapi/linux/netfilter_ipv4/Kbuild   |  10 +-
 include/uapi/linux/netfilter_ipv6/Kbuild   |  13 +-
 include/uapi/linux/nfsd/Kbuild |   6 +-
 include/uapi/linux/raid/Kbuild |   3 +-
 include/uapi/linux/spi/Kbuild  |   2 +-
 include/uapi/linux/sunrpc/Kbuild   |   2 +-
 include/uapi/linux/tc_act/Kbuild   |  15 +-
 include/uapi/linux/tc_ematch/Kbuild|   5 +-
 include/uapi/linux/usb/Kbuild  |  12 +-
 include/uapi/linux/wimax/Kbuild|   2 +-
 include/uapi/misc/Kbuild   |   2 +-
 include/uapi/mtd/Kbuild|   6 +-
 include/uapi/rdma/Kbuild   |  17 +-
 include/uapi/rdma/hfi/Kbuild   |   2 +-
 include/uapi/scsi/Kbuild   |   5 +-
 include/uapi/scsi/fc/Kbuild|   5 +-
 include/uapi/sound/Kbuild  |  16 +-
 include/uapi/video/Kbuild  |   4 +-
 include/uapi/xen/Kbuild|   5 +-
 36 files changed, 47 insertions(+), 754 deletions(-)

diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
index b73de7bb7a62..8e52cdc3d941 100644
--- a/include/uapi/asm-generic/Kbuild
+++ b/include/uapi/asm-generic/Kbuild
@@ -1,36 +1,2 @@
 # UAPI Header export list
-header-y += auxvec.h
-header-y += bitsperlong.h
-header-y += errno-base.h
-header-y += errno.h
-header-y += fcntl.h
-header-y += int-l64.h
-header-y += int-ll64.h
-header-y += ioctl.h
-header-y += ioctls.h
-header-y += ipcbuf.h
-header-y += kvm_para.h
-header-y += mman-common.h
-header-y += mman.h
-header-y += msgbuf.h
-header-y += param.h
-header-y += poll.h
-header-y += posix_types.h
-header-y += resource.h
-header-y += sembuf.h
-header-y += setup.h
-header-y += shmbuf.h
-header-y += shmparam.h
-header-y += siginfo.h
-header-y += signal-defs.h
-header-y += signal.h
-header-y += socket.h
-header-y += sockios.h
-header-y += stat.h
-header-y += statfs.h
-header-y += swab.h
-header-y += termbits.h
-header-y += termios.h
-header-y += types.h
-header-y += ucontext.h
-header-y += unistd.h
+header-y += $(notdir $(wildcard $(srctree)/include/uapi/asm-generic/*.h))
diff --git a/include/uapi/drm/Kbuild b/include/uapi/drm/Kbuild
index 9355dd8eff3b..75f4cde6d9ba 100644
--- a/include/uapi/drm/Kbuild
+++ b/include/uapi/drm/Kbuild
@@ -1,22 +1,2 @@
 # UAPI Header export list
-header-y += drm.h
-header-y += drm_fourcc.h
-header-y += drm_mode.h
-header-y += drm_sarea.h
-header-y += amdgpu_drm.h
-header-y += exynos_drm.h
-header-y += i810_drm.h
-header-y += i915_drm.h
-header-y += mga_drm.h
-header-y += nouveau_drm.h
-header-y += qxl_drm.h
-header-y += r128_drm.h
-header-y += radeon_drm.h
-header-y += savage_drm.h
-header-y += sis_drm.h
-header-y += tegra_drm.h
-header-y += via_drm.h
-header-y += vmwgfx_drm.h
-header-y += msm_drm.h
-header-y += vc4_drm.h
-header-y += virtgpu_drm.h
+header-y += $(notdir $(wildcard $(srctree)/include/uapi/drm/*.h))
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index a8b93e685239.

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

[Jani Nikula]

On Tue, 03 Jan 2017, Zhenyu Wang  wrote:
> On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
>> > Alex, I liked to have kvmgt related mdev interface change be merged through
>> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you 
>> > apply
>> > below fix in your tree? I think in general for possible interface change in
>> > future we still need a pull request for i915 to resolve dependence earlier.
>> 
>> Hi Zhenyu,
>> 
>> Hopefully this abstraction will help to isolate vendor drivers from
>> mdev API changes in the future.  I can certainly roll this patch into
>> the original to maintain bisectability.  I want to get these changes in
>> for rc3, will a pull request for the i915 changes be sent this week?
>
> Send to Jani who is managing i915 fixes pull.

Send what to me? I've pushed fixes to drm-intel-fixes today for testing,
and expect to send a pull request to Dave early Thursday. If there's a
conflict, it can usually be solved while merging, like Stephen has done.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 99019] "Star Ruler 2" game will freeze the system

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

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

--- Comment #5 from Samuel Pitoiset  ---
Confirmed, it hangs the GPU at draw call 15626. Tested on RX 480 with latest
mesa/llvm.

Replacing gui_skin_ps.txt by gui_skin_simple_ps.txt with qapitrace fixes the
hang.

Not sure yet if the shader is miscompiled or if something is not currently
bound.

-- 
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/20170103/63fce208/attachment.html>

linux-next: build failure after merge of the drm-intel-fixes tree

[Stephen Rothwell]

Hi Zhenyu,

On Tue, 3 Jan 2017 10:59:29 +0800 Zhenyu Wang  
wrote:
>
> Alex, I liked to have kvmgt related mdev interface change be merged through
> vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> below fix in your tree? I think in general for possible interface change in
> future we still need a pull request for i915 to resolve dependence earlier.

This only happens because I merge both trees (I think) ...

-- 
Cheers,
Stephen Rothwell

[PATCH] ARM: davinci_all_defconfig: enable dumb vga-dac drm bridge

[Sekhar Nori]

On Friday 25 November 2016 02:43 PM, Bartosz Golaszewski wrote:
> This enables the dumb-vga-dac driver by default for davinci boards.
> 
> The driver is needed for tilcdc support on da850-lcdk board.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  arch/arm/configs/davinci_all_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/configs/davinci_all_defconfig 
> b/arch/arm/configs/davinci_all_defconfig
> index b5e978f..ab1bf18 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -127,6 +127,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
>  CONFIG_REGULATOR_TPS6507X=y
>  CONFIG_DRM=m
>  CONFIG_DRM_TILCDC=m
> +CONFIG_DRM_BRIDGE=y

DRM_BRIDGE is a 'def_bool y'. So no need to explicitly enable it. And
actually it will get dropped with the next savedefconfig refresh anyway.

Applying this patch with this line dropped.

Thanks,
Sekhar

[PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Daniel Kurtz]

Hi Kristian,

On Wed, Dec 21, 2016 at 8:12 AM, Kristian H. Kristensen
 wrote:
> From: "Kristian H. Kristensen" 
>
> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning
> information about the modifiers that will work with each format.
>
> Signed-off-by: Kristian H. Kristensen 
> ---
>  drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
>  drivers/gpu/drm/armada/armada_crtc.c|  1 +
>  drivers/gpu/drm/armada/armada_overlay.c |  1 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 ++-
>  drivers/gpu/drm/drm_ioctl.c |  2 +-
>  drivers/gpu/drm/drm_modeset_helper.c|  1 +
>  drivers/gpu/drm/drm_plane.c | 40 
> +++--
>  drivers/gpu/drm/drm_simple_kms_helper.c |  5 
>  drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
>  drivers/gpu/drm/i915/intel_display.c|  5 +++-
>  drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +--

Looks like this missed drivers/gpu/drm/mediatek.

>  drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
>  drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
>  drivers/gpu/drm/omapdrm/omap_plane.c|  3 +-
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
>  drivers/gpu/drm/sti/sti_cursor.c|  1 +
>  drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
>  drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
>  drivers/gpu/drm/tegra/dc.c  | 12 
>  drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
>  drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
>  include/drm/drm_plane.h |  7 -
>  include/drm/drm_simple_kms_helper.h |  2 ++
>  include/uapi/drm/drm.h  |  1 +
>  include/uapi/drm/drm_mode.h | 27 +
>  27 files changed, 116 insertions(+), 28 deletions(-)

To contribute

[Swapnil Pathak]

Hi,

I also want to contribute, But I don't know from where to start. Could 
you please help me where to start.


Thanks

Swapnil

Disclaimer:- The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended recipient, you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately and 
destroy all copies of this message and any attachments. The views expressed in 
this E-mail message (including the enclosure/(s) or attachment/(s) if any) are 
those of the individual sender, except where the sender expressly, and with 
authority, states them to be the views of GlobalEdge. Before opening any mail 
and attachments please check them for viruses .GlobalEdge does not accept any 
liability for virus infected mails.

[PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay

[Daniel Kurtz]

On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh  
wrote:
>
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh 
> Reviewed-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c  | 21 +
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c |  2 ++
>  2 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c703102..de05845 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -40,10 +40,13 @@
>  #defineOVL_RDMA_MEM_GMC0x40402020
>
>  #define OVL_CON_BYTE_SWAP  BIT(24)
> +#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
>  #define OVL_CON_CLRFMT_RGB565  (0 << 12)
>  #define OVL_CON_CLRFMT_RGB888  (1 << 12)
>  #define OVL_CON_CLRFMT_RGBA(2 << 12)
>  #define OVL_CON_CLRFMT_ARGB(3 << 12)
> +#define OVL_CON_CLRFMT_UYVY(4 << 12)
> +#define OVL_CON_CLRFMT_YUYV(5 << 12)

Why not just add " | OVL_CON_MTX_YUV_TO_RGB" here in the definition of
these two constants, instead of adding a helper function?

>  #defineOVL_CON_AEN BIT(8)
>  #defineOVL_CON_ALPHA   0xff
>
> @@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> case DRM_FORMAT_XBGR:
> case DRM_FORMAT_ABGR:
> return OVL_CON_CLRFMT_RGBA | OVL_CON_BYTE_SWAP;
> +   case DRM_FORMAT_UYVY:
> +   return OVL_CON_CLRFMT_UYVY;
> +   case DRM_FORMAT_YUYV:
> +   return OVL_CON_CLRFMT_YUYV;
> +   }
> +}
> +
> +static bool ovl_yuv_space(unsigned int fmt)
> +{
> +   switch (fmt) {
> +   case DRM_FORMAT_UYVY:
> +   case DRM_FORMAT_YUYV:
> +   return true;
> +   default:
> +   return false;
> }
>  }
>
> @@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> *comp, unsigned int idx,
> if (idx != 0)
> con |= OVL_CON_AEN | OVL_CON_ALPHA;
>
> +   if (ovl_yuv_space(fmt))
> +   con |= OVL_CON_MTX_YUV_TO_RGB;
> +
> writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
> writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
> writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..8c02d1d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
> DRM_FORMAT_XRGB,
> DRM_FORMAT_ARGB,
> DRM_FORMAT_RGB565,
> +   DRM_FORMAT_UYVY,
> +   DRM_FORMAT_YUYV,
>  };
>
>  static void mtk_plane_reset(struct drm_plane *plane)
> --
> 1.9.1
>

[PATCH 0/5] omapdrm: fences and zpos

[Tomi Valkeinen]

 [drm]) from 
[] (drm_ioctl+0x210/0x424 [drm])
[   67.452392] [] (drm_ioctl [drm]) from [] 
(do_vfs_ioctl+0x9c/0xa88)
[   67.460352]  r10: r9:0003 r8:0003 r7:c02d15f4 r6:ed14b180 
r5:ed5feac8
[   67.468219]  r4:be95c44c
[   67.470771] [] (do_vfs_ioctl) from [] 
(SyS_ioctl+0x74/0x84)
[   67.478120]  r10: r9:0003 r8:be95c44c r7:c00464b4 r6:ed14b180 
r5:ed14b180
[   67.485987]  r4:
[   67.488541] [] (SyS_ioctl) from [] 
(ret_fast_syscall+0x0/0x1c)
[   67.496151]  r9:ee7ee000 r8:c0108c04 r7:0036 r6:c00464b4 r5:be95c44c 
r4:0005de78
[   67.504143] ---[ end trace 11d19f8e7a3544b1 ]---

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170103/6addf3d0/attachment.sig>

[Intel-gfx] [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()

[Tvrtko Ursulin]

On 03/01/2017 11:05, Chris Wilson wrote:
> As the fence->status is an optional field that may be set before
> dma_fence_signal() is called to convey that the fence completed with an
> error, we have to ensure that it is always set to zero on initialisation
> so that the typical use (i.e. unset) always flags a successful completion.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/dma-buf/dma-fence.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 3444f293ad4a..9130f790ebf3 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct 
> dma_fence_ops *ops,
>   fence->context = context;
>   fence->seqno = seqno;
>   fence->flags = 0UL;
> + fence->status = 0;
>
>   trace_dma_fence_init(fence);
>  }
>

Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

[PATCH] drm: Remove the struct drm_device platformdev field

[Russell King - ARM Linux]

On Sun, Dec 18, 2016 at 12:39:16AM +0200, Laurent Pinchart wrote:
> The field contains a pointer to the parent platform device of the DRM
> device. As struct drm_device also contains a dev pointer to the struct
> device embedded in the platform_device structure, the platformdev field
> is redundant. Remove it and use the dev pointer directly.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/armada/armada_drv.c | 3 +--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 5 ++---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c| 2 +-
>  drivers/gpu/drm/msm/msm_drv.c   | 1 -
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 3 +--
>  drivers/gpu/drm/sti/sti_drv.c   | 2 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 -
>  include/drm/drmP.h  | 1 -
>  11 files changed, 7 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 07086b427c22..f6442ed23bcd 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -154,10 +154,9 @@ static int armada_drm_bind(struct device *dev)
>   return ret;
>   }
>  
> - priv->drm.platformdev = to_platform_device(dev);
>   priv->drm.dev_private = priv;
>  
> - platform_set_drvdata(priv->drm.platformdev, &priv->drm);
> + dev_set_drvdata(dev, &priv->drm);
>  
>   INIT_WORK(&priv->fb_unref_work, armada_drm_unref_work);
>   INIT_KFIFO(priv->fb_unref);

For Armada,

Acked-by: Russell King 

Thanks.

-- 
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] drm: Remove the struct drm_device platformdev field

[Vincent ABRIOU]

Hi Laurent,

Ok for the sti driver.
Acked-by: Vincent Abriou 

On 12/17/2016 11:39 PM, Laurent Pinchart wrote:
> The field contains a pointer to the parent platform device of the DRM
> device. As struct drm_device also contains a dev pointer to the struct
> device embedded in the platform_device structure, the platformdev field
> is redundant. Remove it and use the dev pointer directly.
>
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/armada/armada_drv.c | 3 +--
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 5 ++---
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 --
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c| 2 +-
>  drivers/gpu/drm/msm/msm_drv.c   | 1 -
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 3 +--
>  drivers/gpu/drm/sti/sti_drv.c   | 2 --
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 -
>  include/drm/drmP.h  | 1 -
>  11 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 07086b427c22..f6442ed23bcd 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -154,10 +154,9 @@ static int armada_drm_bind(struct device *dev)
>   return ret;
>   }
>
> - priv->drm.platformdev = to_platform_device(dev);
>   priv->drm.dev_private = priv;
>
> - platform_set_drvdata(priv->drm.platformdev, &priv->drm);
> + dev_set_drvdata(dev, &priv->drm);
>
>   INIT_WORK(&priv->fb_unref_work, armada_drm_unref_work);
>   INIT_KFIFO(priv->fb_unref);
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index afc2b5d2d5f0..ec1c70d1b682 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -975,7 +975,7 @@ static int ade_dts_parse(struct platform_device *pdev, 
> struct ade_hw_ctx *ctx)
>
>  static int ade_drm_init(struct drm_device *dev)
>  {
> - struct platform_device *pdev = dev->platformdev;
> + struct platform_device *pdev = to_platform_device(dev->dev);
>   struct ade_data *ade;
>   struct ade_hw_ctx *ctx;
>   struct ade_crtc *acrtc;
> @@ -1036,8 +1036,7 @@ static int ade_drm_init(struct drm_device *dev)
>
>  static void ade_drm_cleanup(struct drm_device *dev)
>  {
> - struct platform_device *pdev = dev->platformdev;
> - struct ade_data *ade = platform_get_drvdata(pdev);
> + struct ade_data *ade = dev_get_drvdata(dev->dev);
>   struct drm_crtc *crtc = &ade->acrtc.base;
>
>   drm_crtc_cleanup(crtc);
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index ebd5f4fe4c23..842f70251691 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -209,8 +209,6 @@ static int kirin_drm_bind(struct device *dev)
>   if (IS_ERR(drm_dev))
>   return PTR_ERR(drm_dev);
>
> - drm_dev->platformdev = to_platform_device(dev);
> -
>   ret = kirin_drm_kms_init(drm_dev);
>   if (ret)
>   goto err_drm_dev_unref;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index b782efd4b95f..e8e14a502d21 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -438,7 +438,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
>
>  struct msm_kms *mdp4_kms_init(struct drm_device *dev)
>  {
> - struct platform_device *pdev = dev->platformdev;
> + struct platform_device *pdev = to_platform_device(dev->dev);
>   struct mdp4_platform_config *config = mdp4_get_config(pdev);
>   struct mdp4_kms *mdp4_kms;
>   struct msm_kms *kms = NULL;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> index 618b2ffed9b4..70eae85cf1de 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> @@ -495,7 +495,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
> *mdp5_kms,
>   uint32_t major, uint32_t minor)
>  {
>   struct drm_device *dev = mdp5_kms->dev;
> - struct platform_device *pdev = dev->platformdev;
> + struct platform_device *pdev = to_platform_device(dev->dev);
>   struct mdp5_cfg_handler *cfg_handler;
>   struct mdp5_cfg_platform *pconfig;
>   int i, ret = 0;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
> index d444a6901fff..f8f48d014978 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
> @@ -160,7 +160,7 @@ void msm_mdss_destroy(struct drm_device *dev

[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

[Alex Williamson]

On Tue, 03 Jan 2017 15:25:24 +0200
Jani Nikula  wrote:

> On Tue, 03 Jan 2017, Zhenyu Wang  wrote:
> > On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:  
> >> > Alex, I liked to have kvmgt related mdev interface change be merged 
> >> > through
> >> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you 
> >> > apply
> >> > below fix in your tree? I think in general for possible interface change 
> >> > in
> >> > future we still need a pull request for i915 to resolve dependence 
> >> > earlier.  
> >> 
> >> Hi Zhenyu,
> >> 
> >> Hopefully this abstraction will help to isolate vendor drivers from
> >> mdev API changes in the future.  I can certainly roll this patch into
> >> the original to maintain bisectability.  I want to get these changes in
> >> for rc3, will a pull request for the i915 changes be sent this week?  
> >
> > Send to Jani who is managing i915 fixes pull.  
> 
> Send what to me? I've pushed fixes to drm-intel-fixes today for testing,
> and expect to send a pull request to Dave early Thursday. If there's a
> conflict, it can usually be solved while merging, like Stephen has done.

Unless there's some preference otherwise, I was only asking if the i915
changes were queued for rc3 such that I could trail behind them and
fixup the mdev API change without relying on it getting caught in the
merge.  If we're happy to do it at merge time, I won't worry about it.
Thanks,

Alex

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Chris Wilson]

On Tue, Jan 03, 2017 at 01:17:19PM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 12:38, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 12:13, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 11:46, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>The struct dma_fence carries a status field exposed to userspace by
> >>>sync_file. This is inspected after the fence is signaled and can convey
> >>>whether or not the request completed successfully, or in our case if we
> >>>detected a hang during the request (signaled via -EIO in
> >>>SYNC_IOC_FILE_INFO).
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc: Tvrtko Ursulin 
> >>>Cc: Mika Kuoppala 
> >>>---
> >>>drivers/gpu/drm/i915/i915_gem.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index 204c4a673bf3..bc99c0e292d8 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> >>>intel_engine_cs *engine)
> >>>   ring_hung = false;
> >>>   }
> >>>
> >>>-  if (ring_hung)
> >>>+  if (ring_hung) {
> >>>   i915_gem_context_mark_guilty(request->ctx);
> >>>-  else
> >>>+  request->fence.status = -EIO;
> >>>+  } else {
> >>>   i915_gem_context_mark_innocent(request->ctx);
> >>>+  }
> >>>
> >>>   if (!ring_hung)
> >>>   return;
> >>>
> >>
> >>Reading what happens later in this function, should we set the
> >>status of all the other requests we are about to clear?
> >>
> >>However one thing I don't understand is how this scheme interacts
> >>with the current userspace. We will clear/no-nop some of the
> >>submitted requests since the state is corrupt. But how will
> >>userspace notice this before it submits more requets?
> >
> >There is no mechanism currently for user space to be able to detect a
> >hung request. (It can use the uevent for async notification of the
> >hang/reset, but that will not tell you who caused the hang.) Userspace
> >can track the number of hangs it caused, but the delay makes any
> >roundtripping impractical (i.e. you have to synchronise before all
> >rendering if you must detect the event immediately). Note also that we
> >do not want to give out interprocess information (i.e. to allow one
> >client to spy on another), which makes things harder to get right.
> 
> So idea is to clear already submitted requests _if_ the userspace is
> synchronising before all rendering and looking at reset stats, to
> make it theoretically possible to detect the corrupt state?
> >>>
> >>>No, I'm just don't see a way that userspace can detect the hang without
> >>>testing after seeing the request signaled (either by waiting on the
> >>>batch or by waiting on the fence), i.e. by being completely synchronous
> >>>(or at least chosing its synchronous points very carefully, such as
> >>>around IPC). It can either poll reset-count or use sync_file (which
> >>>requires fence exporting).
> >>>
> >>>The current robustness interfaces is a basic query on whether any reset
> >>>occurred within the context, not when.
> >>
> >>Why do we bother with clearing the submitted requests then?
> >
> >The same reason we ban processes from submitting new requests if they
> >cause repeated hangs. If before we ban that client, it has already
> >submitted 1000 hanging requests, it has successfully locked the machine
> >up for a couple of hours.
> 
> So we would need to gate clearing on the transition to banned state
> I think. Because currently it does in unconditionally.

Yes, see the other patch :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Tvrtko Ursulin]

On 03/01/2017 12:38, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 12:13, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:

 On 03/01/2017 11:46, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:05, Chris Wilson wrote:
>>> The struct dma_fence carries a status field exposed to userspace by
>>> sync_file. This is inspected after the fence is signaled and can convey
>>> whether or not the request completed successfully, or in our case if we
>>> detected a hang during the request (signaled via -EIO in
>>> SYNC_IOC_FILE_INFO).
>>>
>>> Signed-off-by: Chris Wilson 
>>> Cc: Tvrtko Ursulin 
>>> Cc: Mika Kuoppala 
>>> ---
>>> drivers/gpu/drm/i915/i915_gem.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>>> b/drivers/gpu/drm/i915/i915_gem.c
>>> index 204c4a673bf3..bc99c0e292d8 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
>>> intel_engine_cs *engine)
>>> ring_hung = false;
>>> }
>>>
>>> -   if (ring_hung)
>>> +   if (ring_hung) {
>>> i915_gem_context_mark_guilty(request->ctx);
>>> -   else
>>> +   request->fence.status = -EIO;
>>> +   } else {
>>> i915_gem_context_mark_innocent(request->ctx);
>>> +   }
>>>
>>> if (!ring_hung)
>>> return;
>>>
>>
>> Reading what happens later in this function, should we set the
>> status of all the other requests we are about to clear?
>>
>> However one thing I don't understand is how this scheme interacts
>> with the current userspace. We will clear/no-nop some of the
>> submitted requests since the state is corrupt. But how will
>> userspace notice this before it submits more requets?
>
> There is no mechanism currently for user space to be able to detect a
> hung request. (It can use the uevent for async notification of the
> hang/reset, but that will not tell you who caused the hang.) Userspace
> can track the number of hangs it caused, but the delay makes any
> roundtripping impractical (i.e. you have to synchronise before all
> rendering if you must detect the event immediately). Note also that we
> do not want to give out interprocess information (i.e. to allow one
> client to spy on another), which makes things harder to get right.

 So idea is to clear already submitted requests _if_ the userspace is
 synchronising before all rendering and looking at reset stats, to
 make it theoretically possible to detect the corrupt state?
>>>
>>> No, I'm just don't see a way that userspace can detect the hang without
>>> testing after seeing the request signaled (either by waiting on the
>>> batch or by waiting on the fence), i.e. by being completely synchronous
>>> (or at least chosing its synchronous points very carefully, such as
>>> around IPC). It can either poll reset-count or use sync_file (which
>>> requires fence exporting).
>>>
>>> The current robustness interfaces is a basic query on whether any reset
>>> occurred within the context, not when.
>>
>> Why do we bother with clearing the submitted requests then?
>
> The same reason we ban processes from submitting new requests if they
> cause repeated hangs. If before we ban that client, it has already
> submitted 1000 hanging requests, it has successfully locked the machine
> up for a couple of hours.

So we would need to gate clearing on the transition to banned state I 
think. Because currently it does in unconditionally.

Regards,

Tvrtko

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/intel_pm.c

between commit:

  e339d67eeb02 ("drm/i915: Pass crtc state to vlv_compute_wm_level()")

from the drm-intel tree and commit:

  353c85989963 ("drm: Replace drm_format_plane_cpp() with fb->format->cpp[]")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_pm.c
index 4b12637e2084,ce03d9d5aca6..
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@@ -991,13 -960,13 +991,13 @@@ static uint16_t vlv_compute_wm_level(co
if (dev_priv->wm.pri_latency[level] == 0)
return USHRT_MAX;

 -  if (!state->base.visible)
 +  if (!plane_state->base.visible)
return 0;

-   cpp = drm_format_plane_cpp(plane_state->base.fb->pixel_format, 0);
 -  cpp = state->base.fb->format->cpp[0];
 -  clock = crtc->config->base.adjusted_mode.crtc_clock;
 -  htotal = crtc->config->base.adjusted_mode.crtc_htotal;
 -  width = crtc->config->pipe_src_w;
++  cpp = plane_state->base.fb->format->cpp[0];
 +  clock = adjusted_mode->crtc_clock;
 +  htotal = adjusted_mode->crtc_htotal;
 +  width = crtc_state->pipe_src_w;
if (WARN_ON(htotal == 0))
htotal = 1;

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/intel_overlay.c

between commit:

  39ccc04e7435 ("drm/i915: Use primary plane->state for overlay ckey setup")

from the drm-intel tree and commits:

  1967b34d5afb ("drm/i915: Add local 'fb' variables")
  438b74a5497c ("drm: Nuke fb->pixel_format")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_overlay.c
index c95362327ffb,568d194435fd..
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@@ -722,10 -666,8 +722,10 @@@ static void update_colorkey(struct inte
if (overlay->color_key_enabled)
flags |= DST_KEY_ENABLE;

 -  switch (fb->format->format) {
 +  if (state->base.visible)
-   format = state->base.fb->pixel_format;
++  format = state->base.fb->format->format;
 +
 +  switch (format) {
case DRM_FORMAT_C8:
key = 0;
flags |= CLK_RGB8I_MASK;

[PATCH 1/5] drm: omapdrm: Handle events when enabling/disabling CRTCs

[Laurent Pinchart]

Hi Tomi,

On Tuesday 03 Jan 2017 12:07:25 Tomi Valkeinen wrote:
> On 03/01/17 01:29, Laurent Pinchart wrote:
> > The driver currently handles vblank events only when updating planes on
> > an already enabled CRTC. The atomic update API however allows requesting
> > an event when enabling or disabling a CRTC. This currently leads to
> > event objects being leaked in the kernel and to events not being sent
> > out. Fix it.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> > @@ -351,6 +363,13 @@ static void omap_crtc_disable(struct drm_crtc *crtc)
> > 
> > DBG("%s", omap_crtc->name);
> > 
> > +   spin_lock_irq(&crtc->dev->event_lock);
> > +   if (crtc->state->event) {
> > +   drm_crtc_send_vblank_event(crtc, crtc->state->event);
> > +   crtc->state->event = NULL;
> > +   }
> > +   spin_unlock_irq(&crtc->dev->event_lock);
> > +
> > drm_crtc_vblank_off(crtc);
> >  }
> 
> Hmm... How does this go... omap_crtc_dss_disable(), which is called via
> the encoder's disable, is synchronous and waits until the output has
> been disabled. Is omap_crtc_disable() called before or after that? If
> before, we're sending the event too soon.

Fortunately CRTCs are disabled after encoders, I've checked that before 
sending the patch.

> We need to fix the enable/disable call chains =).

Yksi asia kerrallaan :-)

-- 
Regards,

Laurent Pinchart

[PATCH 6/6] drm/i915/dp: Track available DP MST vcpi time slots

[Dhinakaran Pandiyan]

Make use of the added MST helpers to find, allocate and release link bw
for atomic modesets.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_display.c | 39 +++-
 drivers/gpu/drm/i915/intel_dp_mst.c  | 36 -
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 3 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ab72858..71e2ac7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14072,6 +14072,40 @@ static int calc_watermark_data(struct drm_atomic_state 
*state)
return 0;
 }

+static int intel_mst_clear_config(struct drm_atomic_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   struct drm_connector *connector;
+   struct drm_connector_state *connector_state;
+   int i, j;
+
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   if (!crtc_state->active_changed || crtc_state->active)
+   continue;
+
+   for_each_connector_in_state(state, connector, connector_state, 
j) {
+   struct intel_encoder *encoder;
+   struct drm_crtc *curr_crtc;
+   int slots;
+
+   encoder = 
to_intel_encoder(connector->state->best_encoder);
+   if (encoder->type != INTEL_OUTPUT_DP_MST)
+   continue;
+
+   curr_crtc = connector->state->crtc;
+   if (curr_crtc && crtc == curr_crtc) {
+   slots = 
to_intel_crtc_state(crtc->state)->dp_m_n.tu;
+   return intel_dp_mst_reset_vcpi(encoder,
+  connector_state,
+  slots);
+   }
+   }
+   }
+
+   return 0;
+}
+
 /**
  * intel_atomic_check - validate state object
  * @dev: drm device
@@ -14142,8 +14176,11 @@ static int intel_atomic_check(struct drm_device *dev,
}

if (any_ms) {
-   ret = intel_modeset_checks(state);
+   ret = intel_mst_clear_config(state);
+   if (ret)
+   return ret;

+   ret = intel_modeset_checks(state);
if (ret)
return ret;
} else {
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 02a1e2c..331909b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -44,6 +44,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
int lane_count, slots;
const struct drm_display_mode *adjusted_mode = 
&pipe_config->base.adjusted_mode;
int mst_pbn;
+   struct drm_dp_mst_topology_state *topology_state;

pipe_config->has_pch_encoder = false;
bpp = 24;
@@ -65,7 +66,18 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);

pipe_config->pbn = mst_pbn;
-   slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn);
+
+   topology_state = drm_atomic_get_mst_topology_state(state,
+  &intel_dp->mst_mgr);
+   if (topology_state == NULL)
+   return false;
+
+   slots = drm_dp_atomic_find_vcpi_slots(topology_state, connector->port,
+ mst_pbn);
+   if (slots < 0) {
+   DRM_DEBUG_KMS("not enough link bw for this mode\n");
+   return false;
+   }

intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
@@ -78,6 +90,28 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,

 }

+int intel_dp_mst_reset_vcpi(struct intel_encoder *encoder,
+struct drm_connector_state *conn_state, int slots)
+{
+   struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
+   struct drm_dp_mst_topology_mgr *mgr  = &intel_mst->primary->dp.mst_mgr;
+   struct drm_dp_mst_topology_state *topology_state;
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
+   int released;
+
+   topology_state = drm_atomic_get_mst_topology_state(conn_state->state, 
mgr);
+   if (IS_ERR(topology_state))
+   return PTR_ERR(topology_state);
+
+   released = drm_dp_atomic_release_vcpi_slots(topology_state, 
connector->port);
+
+   if (WARN_ON(released != slots))
+   return -EINVAL;
+
+   return 0;
+}
+
 static void intel_mst_disable_dp(struct intel_encoder *encoder,
   

[PATCH 5/6] drm/dp: Add DP MST helpers to atomically find and release vcpi slots

[Dhinakaran Pandiyan]

drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi for the port.

drm_dp_atomic_release_vcpi_slots() should be called from
->atomic_check() to release a port's vcpi slot allocation from the
state.

Drivers that do not make use of this atomic helper are expected to call
drm_dp_find_vcpi_slots() instead before calling
drm_dp_mst_allocate_vcpi().

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 43 +++
 include/drm/drm_dp_mst_helper.h   |  5 
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1be19e1..737d61f 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2501,6 +2501,49 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 }

 /**
+ * drm_dp_atomic_release_vcpi_slots() - Release allocated vcpi slots from the 
state
+ * @topology_state: MST topology state
+ * @port: port to release the vcpi slots for
+ */
+int drm_dp_atomic_release_vcpi_slots(struct drm_dp_mst_topology_state 
*topology_state,
+struct drm_dp_mst_port *port)
+{
+   int alloc = drm_dp_mst_get_vcpi_slots(topology_state->mgr, port);
+
+   topology_state->avail_slots += alloc;
+   DRM_DEBUG_KMS("vcpi slots released=%d, avail=%d\n",
+   alloc, topology_state->avail_slots);
+   return alloc;
+}
+EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots);
+
+/**
+ * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
+ * @topology_state: MST topology state
+ * @port: port to find vcpi slots for
+ * @pbn: bandwidth required for the mode in PBN
+ */
+int drm_dp_atomic_find_vcpi_slots(struct drm_dp_mst_topology_state 
*topology_state,
+ struct drm_dp_mst_port *port, int pbn)
+{
+   int num_slots, curr_alloc;
+   struct drm_dp_mst_topology_mgr *mgr = topology_state->mgr;
+
+   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   curr_alloc = drm_dp_mst_get_vcpi_slots(mgr, port);
+   DRM_DEBUG_KMS("vcpi slots new=%d, curr=%d, avail=%d\n",
+   num_slots, curr_alloc, topology_state->avail_slots);
+
+   if (num_slots - curr_alloc > topology_state->avail_slots)
+   return -ENOSPC;
+
+   topology_state->avail_slots -= (num_slots - curr_alloc);
+   DRM_DEBUG_KMS("vcpi slots avail=%d", topology_state->avail_slots);
+   return num_slots;
+}
+EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots);
+
+/**
  * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel
  * @mgr: manager for this port
  * @port: port to allocate a virtual channel for.
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0a9bf20..90395d8 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -609,4 +609,9 @@ void drm_dp_mst_topology_mgr_suspend(struct 
drm_dp_mst_topology_mgr *mgr);
 int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
 struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
+int drm_dp_atomic_find_vcpi_slots(struct drm_dp_mst_topology_state 
*topology_state,
+ struct drm_dp_mst_port *port, int pbn);
+int drm_dp_atomic_release_vcpi_slots(struct drm_dp_mst_topology_state 
*topology_state,
+struct drm_dp_mst_port *port);
+
 #endif
-- 
2.7.4

[PATCH 4/6] drm/dp: Introduce DP MST topology manager state to track DP link bw

[Dhinakaran Pandiyan]

Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the shared
link bandwidth for a primary link directly connected to the GPU. For atomic
modesetting drivers, checking if there is sufficient link bandwidth for a
mode needs to be done during the atomic_check phase to avoid failed
modesets. Let's encsapsulate the available link bw information in a state
structure so that bw can be allocated and released atomically for each of
the ports sharing the primary link.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c  | 66 +++
 drivers/gpu/drm/drm_atomic_helper.c   | 10 ++
 drivers/gpu/drm/drm_dp_mst_topology.c | 10 ++
 include/drm/drm_atomic.h  | 13 +++
 include/drm/drm_dp_mst_helper.h   | 13 +++
 5 files changed, 112 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 681d5f9..b8e2cea 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "drm_crtc_internal.h"
@@ -62,6 +63,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->dp_mst_topologies);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -189,6 +191,18 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_mst_topologies; i++) {
+   struct drm_dp_mst_topology_mgr *mgr = 
state->dp_mst_topologies[i].ptr;
+
+   if (!mgr)
+   continue;
+
+   kfree(state->dp_mst_topologies[i].state);
+   state->dp_mst_topologies[i].ptr = NULL;
+   state->dp_mst_topologies[i].state = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -981,6 +995,58 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
plane->funcs->atomic_print_state(p, state);
 }

+struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct 
drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr *mgr)
+{
+
+   int ret, i;
+   size_t new_size;
+   struct __drm_dp_mst_topology_state *new_arr;
+   struct drm_dp_mst_topology_state *new_mst_state;
+   int num_topologies;
+   struct drm_mode_config *config = &mgr->dev->mode_config;
+
+   WARN_ON(!state->acquire_ctx);
+
+   ret = drm_modeset_lock(&config->connection_mutex, state->acquire_ctx);
+   if (ret)
+   return ERR_PTR(ret);
+
+   for (i = 0; i < state->num_mst_topologies; i++) {
+   if (mgr == state->dp_mst_topologies[i].ptr &&
+   state->dp_mst_topologies[i].state) {
+   return state->dp_mst_topologies[i].state;
+   }
+   }
+
+   num_topologies = state->num_mst_topologies + 1;
+   new_size = sizeof(*state->dp_mst_topologies) * num_topologies;
+   new_arr = krealloc(state->dp_mst_topologies, new_size, GFP_KERNEL);
+   if (!new_arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->dp_mst_topologies = new_arr;
+   memset(&state->dp_mst_topologies[state->num_mst_topologies], 0,
+   sizeof(*state->dp_mst_topologies));
+
+   new_mst_state = kmalloc(sizeof(*mgr->state), GFP_KERNEL);
+   if (!new_mst_state)
+   return ERR_PTR(-ENOMEM);
+
+   new_mst_state->avail_slots = mgr->state->avail_slots;
+   state->dp_mst_topologies[state->num_mst_topologies].state = 
new_mst_state;
+   state->dp_mst_topologies[state->num_mst_topologies].ptr = mgr;
+   state->num_mst_topologies = num_topologies;
+   new_mst_state->mgr = mgr;
+   mgr->state->state = state;
+
+   DRM_DEBUG_ATOMIC("Added [MST Topology w/ base connector:%d] %p state to 
%p\n",
+mgr->conn_base_id, new_mst_state, state);
+
+   return new_mst_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+
 /**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5e52244..1cd38b7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "drm_crtc_internal.h"
@@ -1992,6 +1993,15 @@ void drm_atomic_helper_swap_state(struct 
drm_atomic_state *state,
connector->state->state = NULL;
}

+   for (i = 0; i < state->num_mst_topologies; i++) {
+   struct drm_dp_mst_topology_mgr *mgr;
+
+   mgr = state->dp_mst_topologies[i].ptr;
+ 

[PATCH 3/6] drm/dp: Split drm_dp_mst_allocate_vcpi

[Dhinakaran Pandiyan]

drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if there are enough vcpi slots before allocating them.

This brings the check to one place. Additionally drivers that will use MST
state tracking for atomic modesets can uses the atomic version of
find_vcpi_slots() and reuse drm_dp_mst_allocate_vcpi()

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c  | 20 +---
 drivers/gpu/drm/i915/intel_dp_mst.c|  3 +--
 drivers/gpu/drm/nouveau/nv50_display.c |  3 ++-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  3 ++-
 include/drm/drm_dp_mst_helper.h|  2 +-
 5 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5df00ae..d42a6c0 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2479,20 +2479,17 @@ int drm_dp_find_vcpi_slots(struct 
drm_dp_mst_topology_mgr *mgr,
 EXPORT_SYMBOL(drm_dp_find_vcpi_slots);

 static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
-   struct drm_dp_vcpi *vcpi, int pbn)
+   struct drm_dp_vcpi *vcpi, int pbn, int slots)
 {
-   int num_slots;
int ret;

-   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
-
/* max. time slots - one slot for MTP header */
-   if (num_slots > 63)
+   if (slots > 63)
return -ENOSPC;

vcpi->pbn = pbn;
-   vcpi->aligned_pbn = num_slots * mgr->pbn_div;
-   vcpi->num_slots = num_slots;
+   vcpi->aligned_pbn = slots * mgr->pbn_div;
+   vcpi->num_slots = slots;

ret = drm_dp_mst_assign_payload_id(mgr, vcpi);
if (ret < 0)
@@ -2507,7 +2504,7 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
  * @pbn: payload bandwidth number to request
  * @slots: returned number of slots for this PBN.
  */
-bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port, int pbn, int *slots)
+bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port, int pbn, int slots)
 {
int ret;

@@ -2515,22 +2512,23 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp
if (!port)
return false;

+   if (slots < 0)
+   return false;
+
if (port->vcpi.vcpi > 0) {
DRM_DEBUG_KMS("payload: vcpi %d already allocated for pbn %d - 
requested pbn %d\n", port->vcpi.vcpi, port->vcpi.pbn, pbn);
if (pbn == port->vcpi.pbn) {
-   *slots = port->vcpi.num_slots;
drm_dp_put_port(port);
return true;
}
}

-   ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn);
+   ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn, slots);
if (ret) {
DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n", 
DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
goto out;
}
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n", pbn, 
port->vcpi.num_slots);
-   *slots = port->vcpi.num_slots;

drm_dp_put_port(port);
return true;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 38e3ca2..02a1e2c 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -147,7 +147,6 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
to_intel_connector(conn_state->connector);
int ret;
uint32_t temp;
-   int slots;

/* MST encoders are bound to a crtc, not to a connector,
 * force the mapping here for get_hw_state.
@@ -177,7 +176,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,

ret = drm_dp_mst_allocate_vcpi(&intel_dp->mst_mgr,
   connector->port,
-  pipe_config->pbn, &slots);
+  pipe_config->pbn, 
pipe_config->dp_m_n.tu);
if (ret == false) {
DRM_ERROR("failed to allocate vcpi\n");
return;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 452da48..91a4875 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2959,7 +2959,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
if (WARN_ON(!mstc))
return;

-   r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, &slots);
+   slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn);
+   r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->

[PATCH 2/6] drm/dp: Kill unused MST vcpi slot availability tracking

[Dhinakaran Pandiyan]

The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total_slots. So, let's make that check obvious. Secondly, since the total
vcpi time slots is always 63 and does not depend on the link BW, remove
total_slots from MST topology manager struct. The third change is to
remove total_pbn which is hardcoded to 2560. The total PBN that the
topology manager allocates from depends on the link rate and is not a
constant. So, fix this by removing the total_pbn member itself.

Finally, make debug messages more informative.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
 include/drm/drm_dp_mst_helper.h   | 12 
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 122a1b0..5df00ae 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2042,10 +2042,6 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
}

-   mgr->total_pbn = 2560;
-   mgr->total_slots = DIV_ROUND_UP(mgr->total_pbn, mgr->pbn_div);
-   mgr->avail_slots = mgr->total_slots;
-
/* add initial branch device at LCT 1 */
mstb = drm_dp_add_mst_branch_device(1, NULL);
if (mstb == NULL) {
@@ -2475,7 +2471,8 @@ int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr 
*mgr,

num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);

-   if (num_slots > mgr->avail_slots)
+   /* max. time slots - one slot for MTP header */
+   if (num_slots > 63)
return -ENOSPC;
return num_slots;
 }
@@ -2489,7 +2486,8 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,

num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);

-   if (num_slots > mgr->avail_slots)
+   /* max. time slots - one slot for MTP header */
+   if (num_slots > 63)
return -ENOSPC;

vcpi->pbn = pbn;
@@ -2528,10 +2526,10 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp

ret = drm_dp_init_vcpi(mgr, &port->vcpi, pbn);
if (ret) {
-   DRM_DEBUG_KMS("failed to init vcpi %d %d %d\n", 
DIV_ROUND_UP(pbn, mgr->pbn_div), mgr->avail_slots, ret);
+   DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n", 
DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
goto out;
}
-   DRM_DEBUG_KMS("initing vcpi for %d %d\n", pbn, port->vcpi.num_slots);
+   DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n", pbn, 
port->vcpi.num_slots);
*slots = port->vcpi.num_slots;

drm_dp_put_port(port);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 27f3e99..b0f4a09 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -479,18 +479,6 @@ struct drm_dp_mst_topology_mgr {
 * @pbn_div: PBN to slots divisor.
 */
int pbn_div;
-   /**
-* @total_slots: Total slots that can be allocated.
-*/
-   int total_slots;
-   /**
-* @avail_slots: Still available slots that can be allocated.
-*/
-   int avail_slots;
-   /**
-* @total_pbn: Total PBN count.
-*/
-   int total_pbn;

/**
 * @qlock: protects @tx_msg_downq, the tx_slots in struct
-- 
2.7.4

[PATCH 1/6] drm/dp: Store drm_device in MST topology manager

[Dhinakaran Pandiyan]

struct drm_dp_mst_topology_mgr currently stores a pointer to struct dev.
Changing this to instead hold a pointer to drm_device is more useful as it
can give us access to DRM structures from the topology manager. This
also makes it consistent with other DRM structures like drm_crtc,
drm_connector etc.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c  | 6 +++---
 drivers/gpu/drm/i915/intel_dp_mst.c| 3 ++-
 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
 include/drm/drm_dp_mst_helper.h| 7 +--
 5 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index aa64448..122a1b0 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1086,7 +1086,7 @@ static void build_mst_prop_path(const struct 
drm_dp_mst_branch *mstb,
 }

 static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
-   struct device *dev,
+   struct drm_device *dev,
struct drm_dp_link_addr_reply_port *port_msg)
 {
struct drm_dp_mst_port *port;
@@ -1104,7 +1104,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,
port->port_num = port_msg->port_number;
port->mgr = mstb->mgr;
port->aux.name = "DPMST";
-   port->aux.dev = dev;
+   port->aux.dev = dev->dev;
created = true;
} else {
old_pdt = port->pdt;
@@ -2949,7 +2949,7 @@ static void drm_dp_destroy_connector_work(struct 
work_struct *work)
  * Return 0 for success, or negative error code on failure
  */
 int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
-struct device *dev, struct drm_dp_aux *aux,
+struct drm_device *dev, struct drm_dp_aux *aux,
 int max_dpcd_transaction_bytes,
 int max_payloads, int conn_base_id)
 {
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 205fe47..38e3ca2 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -587,7 +587,8 @@ intel_dp_mst_encoder_init(struct intel_digital_port 
*intel_dig_port, int conn_ba

/* create encoders */
intel_dp_create_fake_mst_encoders(intel_dig_port);
-   ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, dev->dev, 
&intel_dp->aux, 16, 3, conn_base_id);
+   ret = drm_dp_mst_topology_mgr_init(&intel_dp->mst_mgr, dev,
+  &intel_dp->aux, 16, 3, conn_base_id);
if (ret) {
intel_dp->can_mst = false;
return ret;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index cb85cb7..452da48 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -3417,7 +3417,7 @@ nv50_mstm_new(struct nouveau_encoder *outp, struct 
drm_dp_aux *aux, int aux_max,
mstm->outp = outp;
mstm->mgr.cbs = &nv50_mstm;

-   ret = drm_dp_mst_topology_mgr_init(&mstm->mgr, dev->dev, aux, aux_max,
+   ret = drm_dp_mst_topology_mgr_init(&mstm->mgr, dev, aux, aux_max,
   max_payloads, conn_base_id);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 6d1237d..7d5ada3 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -667,7 +667,7 @@ radeon_dp_mst_init(struct radeon_connector 
*radeon_connector)
return 0;

radeon_connector->mst_mgr.cbs = &mst_cbs;
-   return drm_dp_mst_topology_mgr_init(&radeon_connector->mst_mgr, 
dev->dev,
+   return drm_dp_mst_topology_mgr_init(&radeon_connector->mst_mgr, dev,
&radeon_connector->ddc_bus->aux, 
16, 6,
radeon_connector->base.base.id);
 }
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0032076..27f3e99 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -414,7 +414,7 @@ struct drm_dp_mst_topology_mgr {
/**
 * @dev: device pointer for adding i2c devices etc.
 */
-   struct device *dev;
+   struct drm_device *dev;
/**
 * @cbs: callbacks for connector addition and destruction.
 */
@@ -556,7 +556,10 @@ struct drm_dp_mst_topology_mgr {
struct work_struct destroy_connector_work;
 };

-int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr, struct 
device *dev, struct drm_dp_aux *aux, int max_dpcd_transaction_bytes, int 
max_payloads, int conn_base_id);
+int

[PATCH 0/6] Introduce DP MST Topology state

[Dhinakaran Pandiyan]

Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the shared
link bandwidth for a primary link directly connected to the GPU. For atomic
modesetting drivers, checking if there is sufficient link bandwidth for a
mode needs to be done during the atomic_check phase to avoid failed
modesets.

This series adds dp_mst_topology_state to track available link bw for
atomic modesets and MST helpers to find and release link bw in terms of
vcpi time slots. Using the new helpers is optional and the changes should
not affect drivers that don't support atomic modesetting. I have made
changes to i915 to use the new helpers, but this should be applicable to
nouveau as well.

Patches 1-3/6 include cleanups and refactoring.
Patch 4/6 adds the MST topology state, 5/6 adds helpers to alter the state
and 6/6 contains i915 changes to use the helpers .

Dhinakaran Pandiyan (6):
  drm/dp: Store drm_device in MST topology manager
  drm/dp: Kill unused MST vcpi slot availability tracking
  drm/dp: Split drm_dp_mst_allocate_vcpi
  drm/dp: Introduce DP MST topology manager state to track DP link bw
  drm/dp: Add DP MST helpers to atomically find and release vcpi slots
  drm/i915/dp: Track available DP MST vcpi time slots

 drivers/gpu/drm/drm_atomic.c   | 66 +
 drivers/gpu/drm/drm_atomic_helper.c| 10 
 drivers/gpu/drm/drm_dp_mst_topology.c  | 89 ++
 drivers/gpu/drm/i915/intel_display.c   | 39 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c| 42 ++--
 drivers/gpu/drm/i915/intel_drv.h   |  3 ++
 drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  5 +-
 include/drm/drm_atomic.h   | 11 +
 include/drm/drm_dp_mst_helper.h| 35 -
 10 files changed, 263 insertions(+), 42 deletions(-)

-- 
2.7.4

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/i915_vma.c

between commit:

  7d1d9aea3ee0 ("drm/i915: Tidy i915_gem_valid_gtt_space()")

from the drm-intel tree and commit:

  3f85fb3462dc ("drm: Wrap drm_mm_node.hole_follows")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_vma.c
index e008e4e8b481,325b917c5ad7..
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@@ -327,16 -313,18 +327,16 @@@ bool i915_gem_valid_gtt_space(struct i9
if (vma->vm->mm.color_adjust == NULL)
return true;

 -  if (!drm_mm_node_allocated(gtt_space))
 -  return true;
 -
 -  if (list_empty(>t_space->node_list))
 -  return true;
 +  /* Only valid to be called on an already inserted vma */
 +  GEM_BUG_ON(!drm_mm_node_allocated(node));
 +  GEM_BUG_ON(list_empty(&node->node_list));

 -  other = list_entry(gtt_space->node_list.prev, struct drm_mm_node, 
node_list);
 -  if (other->allocated && !drm_mm_hole_follows(other) && other->color != 
cache_level)
 +  other = list_prev_entry(node, node_list);
-   if (color_differs(other, cache_level) && !other->hole_follows)
++  if (color_differs(other, cache_level) && !drm_mm_hole_follows(other))
return false;

 -  other = list_entry(gtt_space->node_list.next, struct drm_mm_node, 
node_list);
 -  if (other->allocated && !drm_mm_hole_follows(gtt_space) && other->color 
!= cache_level)
 +  other = list_next_entry(node, node_list);
-   if (color_differs(other, cache_level) && !node->hole_follows)
++  if (color_differs(other, cache_level) && !drm_mm_hole_follows(node))
return false;

return true;

[Bug 98784] Talos Principle rendering flickering garbage on start instead of its logo and loading squares

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

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

--- Comment #7 from Samuel Pitoiset  ---
Can you try with LIBGL_DRI3_DISABLE=1 ? This will use DRI2 and it should fix
the flickering.

After bisecting, the first bad commit seems to be:

commit d3d33918c79d9e87aedaf6f70ed39f75eed262a0
Author: Michel Dänzer 
Date:   Wed Aug 17 17:02:04 2016 +0900

loader/dri3: Overhaul dri3_update_num_back

Always use 3 buffers when flipping. With only 2 buffers, we have to wait
for a flip to complete (which takes non-0 time even with asynchronous
flips) before we can start working on the next frame. We were previously
only using 2 buffers for flipping if the X server supports asynchronous
flips, even when we're not using asynchronous flips. This could result
in bad performance (the referenced bug report is an extreme case, where
the inter-frame stalls were preventing the GPU from reaching its maximum
clocks).

I couldn't measure any performance boost using 4 buffers with flipping.
Performance actually seemed to go down slightly, but that might have
been just noise.

Without flipping, a single back buffer is enough for swap interval 0,
but we need to use 2 back buffers when the swap interval is non-0,
otherwise we have to wait for the swap interval to pass before we can
start working on the next frame. This condition was previously reversed.

Cc: "12.0 11.2" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97260
Reviewed-by: Frank Binns 
Reviewed-by: Eric Anholt 
(cherry picked from commit 1e3218bc5ba2b739261f0c0bacf4eb662d377236)

Squashed with commit:

loader/dri3: Always use at least two back buffers

This can make a significant difference for performance with some extreme
test cases such as vblank_mode=0 glxgears.

Fixes: 1e3218bc5ba2 ("loader/dri3: Overhaul dri3_update_num_back")
Cc: "12.0 11.2" 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97549
Reviewed-by: Jason Ekstrand 
Tested-by: Dieter Nützel 
(cherry picked from commit dc3bb5db8c81e7f08ae12ea5d3ee999e2afcbfd1)

:04 04 aa5cf86f1e98d023f9539a6a15654fd9754101a2
fb92ad057feeb3fbff38d808c71c7e5e1cead9af M  src

-- 
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/20170103/5cc88fbb/attachment-0001.html>

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/i915_gem_evict.c

between commit:

  49d73912cbfc ("drm/i915: Convert vm->dev backpointer to vm->i915")

from the drm-intel tree and commit:

  9a71e277888b ("drm: Extract struct drm_mm_scan from struct drm_mm")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_gem_evict.c
index 6457fd0c33a8,85ceff1b74b6..
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@@ -96,7 -99,8 +99,8 @@@ i915_gem_evict_something(struct i915_ad
 u64 start, u64 end,
 unsigned flags)
  {
 -  struct drm_i915_private *dev_priv = to_i915(vm->dev);
 +  struct drm_i915_private *dev_priv = vm->i915;
+   struct drm_mm_scan scan;
struct list_head eviction_list;
struct list_head *phases[] = {
&vm->inactive_list,
@@@ -104,9 -108,10 +108,10 @@@
NULL,
}, **phase;
struct i915_vma *vma, *next;
+   struct drm_mm_node *node;
int ret;

 -  lockdep_assert_held(&vm->dev->struct_mutex);
 +  lockdep_assert_held(&vm->i915->drm.struct_mutex);
trace_i915_gem_evict(vm, min_size, alignment, flags);

/*
@@@ -122,21 -127,12 +127,19 @@@
 * On each list, the oldest objects lie at the HEAD with the freshest
 * object on the TAIL.
 */
-   if (start != 0 || end != vm->total) {
-   drm_mm_init_scan_with_range(&vm->mm, min_size,
-   alignment, cache_level,
-   start, end);
-   } else
-   drm_mm_init_scan(&vm->mm, min_size, alignment, cache_level);
+   drm_mm_scan_init_with_range(&scan, &vm->mm,
+   min_size, alignment, cache_level,
+   start, end,
+   flags & PIN_HIGH ? DRM_MM_CREATE_TOP : 0);

 -  if (flags & PIN_NONBLOCK)
 +  /* Retire before we search the active list. Although we have
 +   * reasonable accuracy in our retirement lists, we may have
 +   * a stray pin (preventing eviction) that can only be resolved by
 +   * retiring.
 +   */
 +  if (!(flags & PIN_NONBLOCK))
 +  i915_gem_retire_requests(dev_priv);
 +  else
phases[1] = NULL;

  search_again:

[PATCH 1/5] drm/ttm: add evict parameter to ttm_bo_driver::move_notify

[Christian König]

Am 21.12.2016 um 16:12 schrieb Nicolai Hähnle:
> On 16.12.2016 03:49, zhoucm1 wrote:
>> On 2016年12月16日 01:10, Nicolai Hähnle wrote:
>>> From: Nicolai Hähnle 
>>>
>>> Ensure that the driver can listen to evictions even when they don't
>>> take the
>>> path through ttm_bo_driver::move.
>>>
>>> This is crucial for amdgpu, which relies on an eviction counter to skip
>>> re-binding page tables when possible.
>>>
>>> Signed-off-by: Nicolai Hähnle 
>> Acked-by: Chunming Zhou 

Feel free to add my Reviewed-by: Christian König 
 to patch #1-#4 and V2 of patch #5 as well.

>
> Thanks. Ping for feedback from non-AMD people?

Ping once more. Would be nice if somebody else can take a look as well.

Christian.

>
> Nicolai
>
>
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  1 +
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  3 ++-
>>>   drivers/gpu/drm/nouveau/nouveau_bo.c   |  3 ++-
>>>   drivers/gpu/drm/qxl/qxl_ttm.c  |  1 +
>>>   drivers/gpu/drm/radeon/radeon_object.c |  1 +
>>>   drivers/gpu/drm/radeon/radeon_object.h |  1 +
>>>   drivers/gpu/drm/ttm/ttm_bo.c   |  8 
>>>   drivers/gpu/drm/virtio/virtgpu_ttm.c   |  1 +
>>>   drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |  1 +
>>>   include/drm/ttm/ttm_bo_driver.h| 10 --
>>>   10 files changed, 22 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> index bf79b73..c29db99 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>>> @@ -842,20 +842,21 @@ int amdgpu_bo_get_metadata(struct amdgpu_bo *bo,
>>> void *buffer,
>>> if (metadata_size)
>>>   *metadata_size = bo->metadata_size;
>>>   if (flags)
>>>   *flags = bo->metadata_flags;
>>> return 0;
>>>   }
>>> void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
>>> +   bool evict,
>>>  struct ttm_mem_reg *new_mem)
>>>   {
>>>   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
>>>   struct amdgpu_bo *abo;
>>>   struct ttm_mem_reg *old_mem = &bo->mem;
>>> if (!amdgpu_ttm_bo_is_amdgpu_bo(bo))
>>>   return;
>>> abo = container_of(bo, struct amdgpu_bo, tbo);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> index 5cbf59e..4306b2f 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>>> @@ -148,21 +148,22 @@ void amdgpu_bo_fini(struct amdgpu_device *adev);
>>>   int amdgpu_bo_fbdev_mmap(struct amdgpu_bo *bo,
>>>   struct vm_area_struct *vma);
>>>   int amdgpu_bo_set_tiling_flags(struct amdgpu_bo *bo, u64 
>>> tiling_flags);
>>>   void amdgpu_bo_get_tiling_flags(struct amdgpu_bo *bo, u64
>>> *tiling_flags);
>>>   int amdgpu_bo_set_metadata (struct amdgpu_bo *bo, void *metadata,
>>>   uint32_t metadata_size, uint64_t flags);
>>>   int amdgpu_bo_get_metadata(struct amdgpu_bo *bo, void *buffer,
>>>  size_t buffer_size, uint32_t *metadata_size,
>>>  uint64_t *flags);
>>>   void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
>>> -  struct ttm_mem_reg *new_mem);
>>> +   bool evict,
>>> +   struct ttm_mem_reg *new_mem);
>>>   int amdgpu_bo_fault_reserve_notify(struct ttm_buffer_object *bo);
>>>   void amdgpu_bo_fence(struct amdgpu_bo *bo, struct dma_fence *fence,
>>>bool shared);
>>>   u64 amdgpu_bo_gpu_offset(struct amdgpu_bo *bo);
>>>   int amdgpu_bo_backup_to_shadow(struct amdgpu_device *adev,
>>>  struct amdgpu_ring *ring,
>>>  struct amdgpu_bo *bo,
>>>  struct reservation_object *resv,
>>>  struct dma_fence **fence, bool direct);
>>>   int amdgpu_bo_restore_from_shadow(struct amdgpu_device *adev,
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> index e0c0007..6fa1521 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>>> @@ -1187,21 +1187,22 @@ nouveau_bo_move_flips(struct ttm_buffer_object
>>> *bo, bool evict, bool intr,
>>>   ret = nouveau_bo_move_m2mf(bo, true, intr, no_wait_gpu, new_mem);
>>>   if (ret)
>>>   goto out;
>>> out:
>>>   ttm_bo_mem_put(bo, &tmp_mem);
>>>   return ret;
>>>   }
>>> static void
>>> -nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, struct ttm_mem_reg
>>> *new_mem)
>>> +nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool evict,
>>> + struct ttm_mem_reg *new_mem)
>>>   {
>>>   struct nouveau_bo *nvbo = nouveau_bo(bo);
>>>   struct nvkm_vma *vma;
>>> /* ttm can now (stupidly) pass the driver bos it didn't
>>> create... */
>>>   if (bo->destroy != nouveau_bo_d

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Chris Wilson]

On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 12:13, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:46, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 11:05, Chris Wilson wrote:
> >The struct dma_fence carries a status field exposed to userspace by
> >sync_file. This is inspected after the fence is signaled and can convey
> >whether or not the request completed successfully, or in our case if we
> >detected a hang during the request (signaled via -EIO in
> >SYNC_IOC_FILE_INFO).
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Mika Kuoppala 
> >---
> >drivers/gpu/drm/i915/i915_gem.c | 6 --
> >1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 204c4a673bf3..bc99c0e292d8 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> >intel_engine_cs *engine)
> > ring_hung = false;
> > }
> >
> >-if (ring_hung)
> >+if (ring_hung) {
> > i915_gem_context_mark_guilty(request->ctx);
> >-else
> >+request->fence.status = -EIO;
> >+} else {
> > i915_gem_context_mark_innocent(request->ctx);
> >+}
> >
> > if (!ring_hung)
> > return;
> >
> 
> Reading what happens later in this function, should we set the
> status of all the other requests we are about to clear?
> 
> However one thing I don't understand is how this scheme interacts
> with the current userspace. We will clear/no-nop some of the
> submitted requests since the state is corrupt. But how will
> userspace notice this before it submits more requets?
> >>>
> >>>There is no mechanism currently for user space to be able to detect a
> >>>hung request. (It can use the uevent for async notification of the
> >>>hang/reset, but that will not tell you who caused the hang.) Userspace
> >>>can track the number of hangs it caused, but the delay makes any
> >>>roundtripping impractical (i.e. you have to synchronise before all
> >>>rendering if you must detect the event immediately). Note also that we
> >>>do not want to give out interprocess information (i.e. to allow one
> >>>client to spy on another), which makes things harder to get right.
> >>
> >>So idea is to clear already submitted requests _if_ the userspace is
> >>synchronising before all rendering and looking at reset stats, to
> >>make it theoretically possible to detect the corrupt state?
> >
> >No, I'm just don't see a way that userspace can detect the hang without
> >testing after seeing the request signaled (either by waiting on the
> >batch or by waiting on the fence), i.e. by being completely synchronous
> >(or at least chosing its synchronous points very carefully, such as
> >around IPC). It can either poll reset-count or use sync_file (which
> >requires fence exporting).
> >
> >The current robustness interfaces is a basic query on whether any reset
> >occurred within the context, not when.
> 
> Why do we bother with clearing the submitted requests then?

The same reason we ban processes from submitting new requests if they
cause repeated hangs. If before we ban that client, it has already
submitted 1000 hanging requests, it has successfully locked the machine
up for a couple of hours.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Tvrtko Ursulin]

On 03/01/2017 12:13, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:46, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:

 On 03/01/2017 11:05, Chris Wilson wrote:
> The struct dma_fence carries a status field exposed to userspace by
> sync_file. This is inspected after the fence is signaled and can convey
> whether or not the request completed successfully, or in our case if we
> detected a hang during the request (signaled via -EIO in
> SYNC_IOC_FILE_INFO).
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> b/drivers/gpu/drm/i915/i915_gem.c
> index 204c4a673bf3..bc99c0e292d8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   ring_hung = false;
>   }
>
> - if (ring_hung)
> + if (ring_hung) {
>   i915_gem_context_mark_guilty(request->ctx);
> - else
> + request->fence.status = -EIO;
> + } else {
>   i915_gem_context_mark_innocent(request->ctx);
> + }
>
>   if (!ring_hung)
>   return;
>

 Reading what happens later in this function, should we set the
 status of all the other requests we are about to clear?

 However one thing I don't understand is how this scheme interacts
 with the current userspace. We will clear/no-nop some of the
 submitted requests since the state is corrupt. But how will
 userspace notice this before it submits more requets?
>>>
>>> There is no mechanism currently for user space to be able to detect a
>>> hung request. (It can use the uevent for async notification of the
>>> hang/reset, but that will not tell you who caused the hang.) Userspace
>>> can track the number of hangs it caused, but the delay makes any
>>> roundtripping impractical (i.e. you have to synchronise before all
>>> rendering if you must detect the event immediately). Note also that we
>>> do not want to give out interprocess information (i.e. to allow one
>>> client to spy on another), which makes things harder to get right.
>>
>> So idea is to clear already submitted requests _if_ the userspace is
>> synchronising before all rendering and looking at reset stats, to
>> make it theoretically possible to detect the corrupt state?
>
> No, I'm just don't see a way that userspace can detect the hang without
> testing after seeing the request signaled (either by waiting on the
> batch or by waiting on the fence), i.e. by being completely synchronous
> (or at least chosing its synchronous points very carefully, such as
> around IPC). It can either poll reset-count or use sync_file (which
> requires fence exporting).
>
> The current robustness interfaces is a basic query on whether any reset
> occurred within the context, not when.

Why do we bother with clearing the submitted requests then?

Regards,

Tvrtko

Is drmWaitVBlank() or drmModePageFlip necessary after drmModeSetPlane()

[Randy Li]

Hello all,
   Recently, I meet a performance problem with drmModeSetPlane(), it 
works quite slow with drm_atomic_commit(), I have to force it use 
drm_atomic_async_commit() for drmModeSetPlane() which modifies the drm 
base system. I want to optimize the performance in standard way, so I 
think I could move those sync job to one of drmWaitVBlank() or 
drmModePageFlip.
   But I found most of atomic_commit() would have a sync internal, 
waiting vbank. So those functions like drmWaitVBlank() or 
drmModePageFlip are not necessary after drmModeSetPlane()?
-- 
Randy Li
The third produce department

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Chris Wilson]

On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 11:46, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>The struct dma_fence carries a status field exposed to userspace by
> >>>sync_file. This is inspected after the fence is signaled and can convey
> >>>whether or not the request completed successfully, or in our case if we
> >>>detected a hang during the request (signaled via -EIO in
> >>>SYNC_IOC_FILE_INFO).
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc: Tvrtko Ursulin 
> >>>Cc: Mika Kuoppala 
> >>>---
> >>>drivers/gpu/drm/i915/i915_gem.c | 6 --
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index 204c4a673bf3..bc99c0e292d8 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> >>>intel_engine_cs *engine)
> >>>   ring_hung = false;
> >>>   }
> >>>
> >>>-  if (ring_hung)
> >>>+  if (ring_hung) {
> >>>   i915_gem_context_mark_guilty(request->ctx);
> >>>-  else
> >>>+  request->fence.status = -EIO;
> >>>+  } else {
> >>>   i915_gem_context_mark_innocent(request->ctx);
> >>>+  }
> >>>
> >>>   if (!ring_hung)
> >>>   return;
> >>>
> >>
> >>Reading what happens later in this function, should we set the
> >>status of all the other requests we are about to clear?
> >>
> >>However one thing I don't understand is how this scheme interacts
> >>with the current userspace. We will clear/no-nop some of the
> >>submitted requests since the state is corrupt. But how will
> >>userspace notice this before it submits more requets?
> >
> >There is no mechanism currently for user space to be able to detect a
> >hung request. (It can use the uevent for async notification of the
> >hang/reset, but that will not tell you who caused the hang.) Userspace
> >can track the number of hangs it caused, but the delay makes any
> >roundtripping impractical (i.e. you have to synchronise before all
> >rendering if you must detect the event immediately). Note also that we
> >do not want to give out interprocess information (i.e. to allow one
> >client to spy on another), which makes things harder to get right.
> 
> So idea is to clear already submitted requests _if_ the userspace is
> synchronising before all rendering and looking at reset stats, to
> make it theoretically possible to detect the corrupt state?

No, I'm just don't see a way that userspace can detect the hang without
testing after seeing the request signaled (either by waiting on the
batch or by waiting on the fence), i.e. by being completely synchronous
(or at least chosing its synchronous points very carefully, such as
around IPC). It can either poll reset-count or use sync_file (which
requires fence exporting).

The current robustness interfaces is a basic query on whether any reset
occurred within the context, not when.

> Still with the fences do you agree error status needs to be set on
> those as well?

Yes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 1/5] drm: omapdrm: Handle events when enabling/disabling CRTCs

[Tomi Valkeinen]

Hi,

On 03/01/17 01:29, Laurent Pinchart wrote:
> The driver currently handles vblank events only when updating planes on
> an already enabled CRTC. The atomic update API however allows requesting
> an event when enabling or disabling a CRTC. This currently leads to
> event objects being leaked in the kernel and to events not being sent
> out. Fix it.
> 
> Signed-off-by: Laurent Pinchart 
> ---

> @@ -351,6 +363,13 @@ static void omap_crtc_disable(struct drm_crtc *crtc)
>  
>   DBG("%s", omap_crtc->name);
>  
> + spin_lock_irq(&crtc->dev->event_lock);
> + if (crtc->state->event) {
> + drm_crtc_send_vblank_event(crtc, crtc->state->event);
> + crtc->state->event = NULL;
> + }
> + spin_unlock_irq(&crtc->dev->event_lock);
> +
>   drm_crtc_vblank_off(crtc);
>  }

Hmm... How does this go... omap_crtc_dss_disable(), which is called via
the encoder's disable, is synchronous and waits until the output has
been disabled. Is omap_crtc_disable() called before or after that? If
before, we're sending the event too soon.

We need to fix the enable/disable call chains =).

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20170103/0285cc85/attachment-0001.sig>

[PATCH] drm: Constify drm_mode_config atomic helper private pointer

[Brian Starkey]

On Mon, Jan 02, 2017 at 11:16:13AM +0200, Laurent Pinchart wrote:
>The drm_mode_config helper private field points to a structure of
>function pointers that don't need to be modified at runtime. Make it
>const.
>
>Signed-off-by: Laurent Pinchart 

Acked-by: Brian Starkey 

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Tvrtko Ursulin]

On 03/01/2017 11:46, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:05, Chris Wilson wrote:
>>> The struct dma_fence carries a status field exposed to userspace by
>>> sync_file. This is inspected after the fence is signaled and can convey
>>> whether or not the request completed successfully, or in our case if we
>>> detected a hang during the request (signaled via -EIO in
>>> SYNC_IOC_FILE_INFO).
>>>
>>> Signed-off-by: Chris Wilson 
>>> Cc: Tvrtko Ursulin 
>>> Cc: Mika Kuoppala 
>>> ---
>>> drivers/gpu/drm/i915/i915_gem.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>>> b/drivers/gpu/drm/i915/i915_gem.c
>>> index 204c4a673bf3..bc99c0e292d8 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
>>> intel_engine_cs *engine)
>>> ring_hung = false;
>>> }
>>>
>>> -   if (ring_hung)
>>> +   if (ring_hung) {
>>> i915_gem_context_mark_guilty(request->ctx);
>>> -   else
>>> +   request->fence.status = -EIO;
>>> +   } else {
>>> i915_gem_context_mark_innocent(request->ctx);
>>> +   }
>>>
>>> if (!ring_hung)
>>> return;
>>>
>>
>> Reading what happens later in this function, should we set the
>> status of all the other requests we are about to clear?
>>
>> However one thing I don't understand is how this scheme interacts
>> with the current userspace. We will clear/no-nop some of the
>> submitted requests since the state is corrupt. But how will
>> userspace notice this before it submits more requets?
>
> There is no mechanism currently for user space to be able to detect a
> hung request. (It can use the uevent for async notification of the
> hang/reset, but that will not tell you who caused the hang.) Userspace
> can track the number of hangs it caused, but the delay makes any
> roundtripping impractical (i.e. you have to synchronise before all
> rendering if you must detect the event immediately). Note also that we
> do not want to give out interprocess information (i.e. to allow one
> client to spy on another), which makes things harder to get right.

So idea is to clear already submitted requests _if_ the userspace is 
synchronising before all rendering and looking at reset stats, to make 
it theoretically possible to detect the corrupt state?

Still with the fences do you agree error status needs to be set on those 
as well?

Regards,

Tvrtko

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Chris Wilson]

On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> 
> On 03/01/2017 11:05, Chris Wilson wrote:
> >The struct dma_fence carries a status field exposed to userspace by
> >sync_file. This is inspected after the fence is signaled and can convey
> >whether or not the request completed successfully, or in our case if we
> >detected a hang during the request (signaled via -EIO in
> >SYNC_IOC_FILE_INFO).
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Mika Kuoppala 
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 204c4a673bf3..bc99c0e292d8 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> >intel_engine_cs *engine)
> > ring_hung = false;
> > }
> >
> >-if (ring_hung)
> >+if (ring_hung) {
> > i915_gem_context_mark_guilty(request->ctx);
> >-else
> >+request->fence.status = -EIO;
> >+} else {
> > i915_gem_context_mark_innocent(request->ctx);
> >+}
> >
> > if (!ring_hung)
> > return;
> >
> 
> Reading what happens later in this function, should we set the
> status of all the other requests we are about to clear?
> 
> However one thing I don't understand is how this scheme interacts
> with the current userspace. We will clear/no-nop some of the
> submitted requests since the state is corrupt. But how will
> userspace notice this before it submits more requets?

There is no mechanism currently for user space to be able to detect a
hung request. (It can use the uevent for async notification of the
hang/reset, but that will not tell you who caused the hang.) Userspace
can track the number of hangs it caused, but the delay makes any
roundtripping impractical (i.e. you have to synchronise before all
rendering if you must detect the event immediately). Note also that we
do not want to give out interprocess information (i.e. to allow one
client to spy on another), which makes things harder to get right.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 5/5 v3] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID

[John Stultz]

I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors
on HiKey.

Investigating further, it seems some of the register state
in the regmap cache is somehow getting lost. Using the logic
in __adv7511_power_on/off() which syncs and dirtys the cache
avoids this issue.

Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index dbdb71c..24573e0 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -572,24 +572,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
unsigned int count;

/* Reading the EDID only works if the device is powered */
-   if (!adv7511->powered) {
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN, 0);
-   if (adv7511->i2c_main->irq) {
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
-ADV7511_INT1_DDC_ERROR);
-   }
-   adv7511->current_edid_segment = -1;
-   }
+   if (!adv7511->powered)
+   __adv7511_power_on(adv7511);

edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);

if (!adv7511->powered)
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN,
-  ADV7511_POWER_POWER_DOWN);
+   __adv7511_power_off(adv7511);

kfree(adv7511->edid);
adv7511->edid = edid;
-- 
2.7.4

[PATCH 4/5 v3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally

[John Stultz]

In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.

This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 4b90975..dbdb71c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -325,7 +325,7 @@ static void adv7511_set_link_config(struct adv7511 *adv7511,
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
 }

-static void adv7511_power_on(struct adv7511 *adv7511)
+static void __adv7511_power_on(struct adv7511 *adv7511)
 {
adv7511->current_edid_segment = -1;

@@ -359,24 +359,30 @@ static void adv7511_power_on(struct adv7511 *adv7511)
 * Most of the registers are reset during power down or when HPD is low.
 */
regcache_sync(adv7511->regmap);
+}

+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+   __adv7511_power_on(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_on(adv7511);
-
adv7511->powered = true;
 }

-static void adv7511_power_off(struct adv7511 *adv7511)
+static void __adv7511_power_off(struct adv7511 *adv7511)
 {
/* TODO: setup additional power down modes */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
   ADV7511_POWER_POWER_DOWN,
   ADV7511_POWER_POWER_DOWN);
regcache_mark_dirty(adv7511->regmap);
+}

+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+   __adv7511_power_off(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_off(adv7511);
-
adv7511->powered = false;
 }

-- 
2.7.4

[PATCH 3/5 v3] drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection

[John Stultz]

From: Archit Taneja 

On some adv7511 implementations, we can get some spurious
disconnect signals which can cause monitor probing to fail.

This patch enables HPD (hot plug detect) interrupt support
which allows the monitor to be properly re-initialized when
the spurious disconnect signal goes away.

This also enables proper hotplug support.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org
Acked-by: Laurent Pinchart 
Originally-by: Archit Taneja 
[jstultz: Added proper commit message]
Signed-off-by: John Stultz 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index d93d66f..4b90975 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -338,7 +338,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
 * Still, let's be safe and stick to the documentation.
 */
regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
+ADV7511_INT0_EDID_READY | ADV7511_INT0_HPD);
regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
 ADV7511_INT1_DDC_ERROR);
}
@@ -846,6 +846,10 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge)
if (adv->type == ADV7533)
ret = adv7533_attach_dsi(adv);

+   if (adv->i2c_main->irq)
+   regmap_write(adv->regmap, ADV7511_REG_INT_ENABLE(0),
+   ADV7511_INT0_HPD);
+
return ret;
 }

-- 
2.7.4

[PATCH 2/5 v3] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()

[John Stultz]

In chasing down a previous issue with EDID probing from calling
drm_helper_hpd_irq_event() from irq context, Laurent noticed
that the DRM documentation suggests that
drm_kms_helper_hotplug_event() should be used instead.

Thus this patch replaces drm_helper_hpd_irq_event() with
drm_kms_helper_hotplug_event(), which requires we update the
connector.status entry and only call _hotplug_event() when the
status changes.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: John Stultz 
---
v3: Update connector.status value and only call __hotplug_event()
when that status changes, as suggested by Laurent.

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 4fcea44..d93d66f 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -405,8 +405,22 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
 static void adv7511_hpd_work(struct work_struct *work)
 {
struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
+   enum drm_connector_status status;
+   unsigned int val;
+   int ret;
+
+   ret = regmap_read(adv7511->regmap, ADV7511_REG_STATUS, &val);
+   if (ret < 0)
+   status = connector_status_disconnected;
+   else if (val & ADV7511_STATUS_HPD)
+   status = connector_status_connected;
+   else
+   status = connector_status_disconnected;
+
+   if (adv7511->connector.status != status)
+   drm_kms_helper_hotplug_event(adv7511->connector.dev);

-   drm_helper_hpd_irq_event(adv7511->connector.dev);
+   adv7511->connector.status = status;
 }

 static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
-- 
2.7.4

[PATCH 1/5 v3] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context

[John Stultz]

I was recently seeing issues with EDID probing, where
the logic to wait for the EDID read bit to be set by the
IRQ wasn't happening and the code would time out and fail.

Digging deeper, I found this was due to the fact that
IRQs were disabled as we were running in IRQ context from
the HPD signal.

Thus this patch changes the logic to handle the HPD signal
via a work_struct so we can be out of irq context.

With this patch, the EDID probing on hotplug does not time
out.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Laurent Pinchart 
Signed-off-by: John Stultz 
---
v3: Rename irq_work to hpd_work and remove extra whitespace, as
suggested by Laurent

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 ++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 ++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 992d76c..0396791 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -317,6 +317,8 @@ struct adv7511 {
bool edid_read;

wait_queue_head_t wq;
+   struct work_struct hpd_work;
+
struct drm_bridge bridge;
struct drm_connector connector;

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 8dba729..4fcea44 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -402,6 +402,13 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
return false;
 }

+static void adv7511_hpd_work(struct work_struct *work)
+{
+   struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
+
+   drm_helper_hpd_irq_event(adv7511->connector.dev);
+}
+
 static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
 {
unsigned int irq0, irq1;
@@ -419,7 +426,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511, 
bool process_hpd)
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);

if (process_hpd && irq0 & ADV7511_INT0_HPD && adv7511->bridge.encoder)
-   drm_helper_hpd_irq_event(adv7511->connector.dev);
+   schedule_work(&adv7511->hpd_work);

if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
adv7511->edid_read = true;
@@ -1006,6 +1013,8 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
goto err_i2c_unregister_edid;
}

+   INIT_WORK(&adv7511->hpd_work, adv7511_hpd_work);
+
if (i2c->irq) {
init_waitqueue_head(&adv7511->wq);

-- 
2.7.4

[PATCH 0/5 v3] adv7511 EDID probing improvements

[John Stultz]

Hope everyone had a good newyears!

Wanted to re-send out v3 of this patch set improving the EDID
probing on the adv7511 used on HiKey, for consideration for
merging for 4.11

The first three patches are fixups that are hopefully straight
forward, integrating feedback I got from Laurant.

The last two patches try to clean up and resue code, which as
a side effect avoids an issue I'm seeing where something is
going wrong with the regmap cache state for the
ADV7511_REG_EDID_I2C_ADDR(0x43) register which results in
i2c_transfer errors if we don't do the
regcache_sync/_mark_dirty() calls. I suspect there might be a
better solution there, but have not gotten any other suggestions
so I wanted to go ahead and submit these.

Thoughts and feedback would be appreciated!

thanks
-john

New in v3:
* Addressed naming improvements and drm_kms_helper_hotplug_event
  usage corrections as suggested by Laurent.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel at lists.freedesktop.org

Archit Taneja (1):
  drm/bridge: adv7511: Enable HPD interrupts to support hotplug and
improve monitor detection

John Stultz (4):
  drm/bridge: adv7511: Use work_struct to defer hotplug handing to out
of irq context
  drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event()
  drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be
reused internally
  drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID

 drivers/gpu/drm/bridge/adv7511/adv7511.h |  2 +
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 62 +++-
 2 files changed, 44 insertions(+), 20 deletions(-)

-- 
2.7.4

[PATCH] drm: remove immutable flag from suggested X/Y connector properties

[Gerd Hoffmann]

  Hi,

> > Makes sense I think, but for merging we need:
> > - some driver to implement
> 
> This is where it starts getting tricky.  vboxvideo is out of tree.  In 
> theory I could look at getting it merged, but that needs time I am 
> rather short of (I am the only person maintaining that driver and it is 
> just one of my responsibilities; and there are some bits there that are 
> probably too ugly to merge as is).  I don't think I am really the person 
> to be doing this for qxl/virtio-gpu as that required adding the support 
> to qemu too.

Not only kernel driver and qemu.  Right now neither qxl nor virtio-gpu
can communicate the actual layout back to the host.  So this also
requires changes to the guest/host protocol (i.e. the virtual hardware).

> > - some userspace to take advantage of it
> 
> As I wrote, mutter would be the first candidate.

Do you have any feedback from mutter developers on the two approaches
(touchscreen-style autoconfig or x+y offsets)?

cheers,
  Gerd

[Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang

[Tvrtko Ursulin]

On 03/01/2017 11:05, Chris Wilson wrote:
> The struct dma_fence carries a status field exposed to userspace by
> sync_file. This is inspected after the fence is signaled and can convey
> whether or not the request completed successfully, or in our case if we
> detected a hang during the request (signaled via -EIO in
> SYNC_IOC_FILE_INFO).
>
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 204c4a673bf3..bc99c0e292d8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct 
> intel_engine_cs *engine)
>   ring_hung = false;
>   }
>
> - if (ring_hung)
> + if (ring_hung) {
>   i915_gem_context_mark_guilty(request->ctx);
> - else
> + request->fence.status = -EIO;
> + } else {
>   i915_gem_context_mark_innocent(request->ctx);
> + }
>
>   if (!ring_hung)
>   return;
>

Reading what happens later in this function, should we set the status of 
all the other requests we are about to clear?

However one thing I don't understand is how this scheme interacts with 
the current userspace. We will clear/no-nop some of the submitted 
requests since the state is corrupt. But how will userspace notice this 
before it submits more requets?

Regards,

Tvrtko

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[Ilia Mirkin]

On Mon, Jan 2, 2017 at 6:31 AM, vathsala nagaraju
 wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
>
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
> flickering is observed on psr2 panel.
>
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 +++
>  drivers/gpu/drm/i915/intel_dp.c  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 29 -
>  3 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5ca506a..0cbe564 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3600,6 +3600,12 @@ enum {
>  #define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
>  #define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
>  #define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
> +#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
> +#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)

Looks like you're defining the above 3 (maybe 4 - not enough context)
a second time.

  -ilia

To contribute

[Jani Nikula]

On Tue, 03 Jan 2017, Swapnil Pathak  wrote:
> I also want to contribute, But I don't know from where to start. Could 
> you please help me where to start.

That's easy. Get rid of the disclaimer at the bottom of your mails! :p

The serious answer really depends on you, and it's hard to give advice
that works for everyone. That said, learn to configure, build and run
upstream kernels from git. Find issues that bother you, look at
https://bugs.freedesktop.org for inspiration. Learn to do git bisect,
and bisect the issues if they're regressions. Debug them and fix them if
you can.


HTH,
Jani.


> Thanks
>
> Swapnil
>
> Disclaimer:- The information contained in this electronic message and
> any attachments to this message are intended for the exclusive use of
> the addressee(s) and may contain proprietary, confidential or
> privileged information. If you are not the intended recipient, you
> should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately and destroy all copies of this message and any
> attachments. The views expressed in this E-mail message (including the
> enclosure/(s) or attachment/(s) if any) are those of the individual
> sender, except where the sender expressly, and with authority, states
> them to be the views of GlobalEdge. Before opening any mail and
> attachments please check them for viruses .GlobalEdge does not accept
> any liability for virus infected mails.
>
> ___
> 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

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

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

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

Christian König  changed:

   What|Removed |Added

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

--- Comment #13 from Christian König  ---
Just pushed the patch after coming back from vacation.

Should eventually show up in stable releases as well.

-- 
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/20170103/89d102e1/attachment.html>

linux-next: manual merge of the drm-intel-fixes tree with the vfio-fixes tree

[Jani Nikula]

On Tue, 03 Jan 2017, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel-fixes tree got a conflict in:
>
>   drivers/gpu/drm/i915/gvt/kvmgt.c
>
> between commit:
>
>   99e3123e3d72 ("vfio-mdev: Make mdev_device private and abstract interfaces")
>
> from the vfio-fixes tree and commit:
>
>   364fb6b789ff ("drm/i915/gvt/kvmgt: prevent double-release of vgpu")
>
> from the drm-intel-fixes tree.

Hi Stephen, while GVT-g is part of i915, it has its own mailing list and
maintainers, listed under "INTEL GVT-g DRIVERS (Intel GPU
Virtualization)" in MAINTAINERS. Please include them wrt linux-next
conflicts in drivers/gpu/drm/i915/gvt/. Added now.

Thanks,
Jani.


> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/gvt/kvmgt.c
> index f8021a01df63,934963970288..
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@@ -497,10 -500,19 +500,19 @@@ static int intel_vgpu_open(struct mdev_
>   goto undo_iommu;
>   }
> 
> - return kvmgt_guest_init(mdev);
> + ret = kvmgt_guest_init(mdev);
> + if (ret)
> + goto undo_group;
> + 
> + atomic_set(&vgpu->vdev.released, 0);
> + return ret;
> + 
> + undo_group:
> + vfio_unregister_notifier(&mdev->dev, VFIO_GROUP_NOTIFY,
> + &vgpu->vdev.group_notifier);
> 
>   undo_iommu:
>  -vfio_unregister_notifier(&mdev->dev, VFIO_IOMMU_NOTIFY,
>  +vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
>   &vgpu->vdev.iommu_notifier);
>   out:
>   return ret;
> @@@ -513,10 -526,16 +526,16 @@@ static void __intel_vgpu_release(struc
>   if (!handle_valid(vgpu->handle))
>   return;
> 
> - vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev), VFIO_IOMMU_NOTIFY,
> + if (atomic_cmpxchg(&vgpu->vdev.released, 0, 1))
> + return;
> + 
>  -ret = vfio_unregister_notifier(&vgpu->vdev.mdev->dev, VFIO_IOMMU_NOTIFY,
> ++ret = vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev), 
> VFIO_IOMMU_NOTIFY,
>   &vgpu->vdev.iommu_notifier);
> - vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev), VFIO_GROUP_NOTIFY,
> + WARN(ret, "vfio_unregister_notifier for iommu failed: %d\n", ret);
> + 
>  -ret = vfio_unregister_notifier(&vgpu->vdev.mdev->dev, VFIO_GROUP_NOTIFY,
> ++ret = vfio_unregister_notifier(mdev_dev(vgpu->vdev.mdev), 
> VFIO_GROUP_NOTIFY,
>   &vgpu->vdev.group_notifier);
> + WARN(ret, "vfio_unregister_notifier for group failed: %d\n", ret);
> 
>   info = (struct kvmgt_guest_info *)vgpu->handle;
>   kvmgt_guest_exit(info);
> 
-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 99219] The Stanley Parable GPU hang when starting a new game

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

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

--- Comment #5 from Christoph Haag  ---
The game runs without hangs now. Thanks.

-- 
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/20170103/8afa7753/attachment-0001.html>

[PATCH v7 3/5] drm: bridge: add support for TI ths8135

[Sekhar Nori]

On Tuesday 03 January 2017 10:56 AM, Archit Taneja wrote:
> Hi Sekhar,
> 
> On 1/2/2017 4:38 PM, Sekhar Nori wrote:
>> Hi Archit,
>>
>> On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>>>
>>>
>>> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
 THS8135 is a configurable video DAC, but no configuration is actually
 necessary to make it work.

 For now use the dumb-vga-dac driver to support it.
>>>
>>> Queued to drm-misc-next
>>
>> This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
>> to v4.10?
> 
> These missed out on 4.10 because the drm related pull requests were
> already sent by then. These 2 patches are queued for 4.11.

Alright, thanks for the update.

Regards,
Sekhar