omap4: how to get the HDMI core IRQ?

[Hans Verkuil]

Hi Tomi,

On 03/30/2016 03:37 AM, Tomi Valkeinen wrote:
> Hi Hans,
>
> On 24/03/16 23:20, Hans Verkuil wrote:
>> Hi Tomi,
>>
>> I hope you (or someone else on this list) can help me find the problem in 
>> this code.
>>
>> I am working on a kernel framework for HDMI CEC (see 
>> https://lwn.net/Articles/680942/).
>> In order to get as much experience with different devices as possible I am 
>> trying to
>> implement it on my omap4430 Pandaboard. The big problem I am facing is that 
>> the CEC
>> interrupts come in through the HDMI_IRQ_CORE interrupt, and that just 
>> refuses to
>> trigger.
>>
>> The code below adds support for this core interrupt and it is supposed to 
>> trigger it
>> using the Software Induced interrupt to keep the code as simple as possible.
>
> So this irq is just for testing?

Yes, that was the easiest way to check the core irq without requiring lots of 
other changes.

>> On boot I get this debug line from the pr_info in my code:
>>
>> irqstat 0200 wp_irq 0601 raw 2001 intr_state 0001 intr1 
>> 0080 unmask1 0080 intr_ctrl 000a
>>
>> As far as I can see everything looks perfectly fine, except for the fact 
>> that bit 0
>> of the irqstat is stubbornly 0.
>>
>> This is using kernel 4.5 with only this patch applied.
>>
>> What am I missing?
>
> Set SYS_CTRL1:PD to 1 (I presume you have the NDA HDMI TRM?).

Yes, I have it.

> Apparently we set it always to 0 in
> hdmi4_core.c:hdmi_core_powerdown_disable(), but never enable it. I guess
> it only affects core irqs, so there have been no side effects.
>
> But it would make sense to either have a matching call in the enable
> path, or then just set it to 0 when initializing the IP.

I think it should be set in hdmi_core_video_config(). It sets other SYS_CTRL1 
bits there as
well, and that is probably why I missed it. I just never realized that the PD 
bit wasn't set
there.

Thank you very much! I'm abroad right now, but once I'm back I'll test this 
first thing.

>
>>
>> The reward for the right answer will be HDMI CEC support for omap4 (and any 
>> other TI device
>> with the same CEC IP).
>
> Ok. When is it ready? ;)

Once I get the irq working the omap4 support should be ready very quickly, 
getting the CEC framework
merged takes a bit longer, but I am aiming for kernel 4.7 pending some final 
tests. I'm cross-posting
the patch series to dri-devel, so with luck when I post v15 it will have an 
omap4 driver as well.

Regards,

Hans

[PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event

[Mark yao]

On 2016年03月30日 21:48, Tomeu Vizoso wrote:
> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
> updated is requested and there is an earlier updated pending".
>
> Also wait for the pending event to complete when a sync update is
> requested.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 14 +-
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++
>   3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index 3529f692edb8..37952eefd33d 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -69,6 +69,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
>   void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
>   int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
> int out_mode);
> +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc);
>   int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
>  struct device *dev);
>   void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index 3b8f652698f8..028fd2f8f47b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -280,7 +280,19 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
>   {
>   struct rockchip_drm_private *private = dev->dev_private;
>   struct rockchip_atomic_commit *commit = &private->commit;
> - int ret;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i, ret;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc->state->event ||
> + rockchip_drm_crtc_has_pending_event(crtc)) {
> + if (async)
> + return -EBUSY;
> + else
> + rockchip_crtc_wait_for_update(crtc);

> + }
> + }
>   
>   ret = drm_atomic_helper_prepare_planes(dev, state);
>   if (ret)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index e2118e62345b..5240bc8fe088 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -848,6 +848,12 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
>   }
>   EXPORT_SYMBOL_GPL(rockchip_drm_crtc_mode_config);
>   
> +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc)
> +{
> + return to_vop(crtc)->event;
> +}
> +EXPORT_SYMBOL_GPL(rockchip_drm_crtc_has_pending_event);
> +

No need to do EXPORT_SYMBOL_GPL, rockchip_drm_vop.c and rockchip_drm_fb.c will 
build into same object.


>   static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
>   {
>   struct vop *vop = to_vop(crtc);
Hi Tomeu

Since rockchip atomic async use "serialize outstanding asynchronous 
commits", async commit will wait on "flush_work(&commit->work);" to 
ensure last pending event is done, so vop->event should be NULL after 
flush. if not, it should be a BUG.

Anyway, serialize async commits is not a good way, but I don't think 
your patch is better way.

I think maybe we can check the "commit->work" status(finish or running) 
to judge return BUSY or not, instead of flush it.

Thanks.

-- 
ï¼­ark Yao

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

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

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

--- Comment #26 from Michel D�nzer  ---
I think the patch was only intended as a means to get more information, not as
a fix to be merged. Right, Maarten? Did you get more information from the
feedback on the patch so far, or what specifically do you need?

-- 
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/20160331/7963d8ae/attachment.html>

[PATCH 1/5] drm: Add new DCS commands in the enum list

[Andrzej Hajda]

On 03/30/2016 04:03 PM, Jani Nikula wrote:
> From: Deepak M 
>
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> v2: Sorted the Macro`s by value (Andrzej)
>
> v3 by Jani: sort all of enum, refer to MIPI DCS 1.3
>
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: David Airlie 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: 
> Suggested-by: Jani Nikula 
> Signed-off-by: Deepak M 
> Signed-off-by: Jani Nikula 

DCS 1.3 introduces also:
get_error_count_on_DSI 05h
get_image_checksum_ct 15h
get_image_checksum_rgb 14h
read_PPS_continue a9h
read_PPS_start A2h

It would be good to add them, but as the patch
says it adds only CABC related commands so no big deal.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

> ---
>  include/video/mipi_display.h | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca7316b..19aa65a35546 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -115,6 +115,14 @@ enum {
>   MIPI_DCS_READ_MEMORY_CONTINUE   = 0x3E,
>   MIPI_DCS_SET_TEAR_SCANLINE  = 0x44,
>   MIPI_DCS_GET_SCANLINE   = 0x45,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /* MIPI DCS 1.3 */
> + MIPI_DCS_WRITE_CONTROL_DISPLAY  = 0x53, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /* MIPI DCS 1.3 */
> + MIPI_DCS_WRITE_POWER_SAVE   = 0x55, /* MIPI DCS 1.3 */
> + MIPI_DCS_GET_POWER_SAVE = 0x56, /* MIPI DCS 1.3 */
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,/* MIPI DCS 1.3 */
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,/* MIPI DCS 1.3 */
>   MIPI_DCS_READ_DDB_START = 0xA1,
>   MIPI_DCS_READ_DDB_CONTINUE  = 0xA8,
>  };

[PATCH 02/11] drm/atomic: export drm_atomic_helper_wait_for_fences()

[Daniel Vetter]

On Wed, Mar 30, 2016 at 05:51:45PM -0300, Gustavo Padovan wrote:
> 2016-03-18 Rob Clark :
> 
> Hi Rob,
> 
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 15 +--
> >  include/drm/drm_atomic_helper.h |  2 ++
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Gustavo Padovan 

Applied to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm: Make uapi headers C89 pendantic compliant

[Daniel Vetter]

On Wed, Mar 30, 2016 at 09:06:33PM +0100, Emil Velikov wrote:
> On 30 March 2016 at 15:42, Daniel Vetter  wrote:
> > This ports the below libdrm commit to the kernel
> >
> > commit 0f4452bb51306024fbf4cbf77d8baab20cefba67
> > Author: Daniel Kurtz 
> > Date:   Mon Aug 26 23:39:16 2013 +0800
> >
> > libdrm: Make some drm headers compatible with gcc -std=c89 -pedantic
> >
> > The following minor changes were needed to these headers:
> >  * Convert // comments to /* */
> >  * No , after final member of enum
> >
> > With these changes, these header files can be included by a program that
> > is built with gcc options:
> >   -std=c89 -Werror -pedantic
> >
> > Signed-off-by: Daniel Kurtz 
> > Signed-off-by: Eric Anholt 
> > Reviewed-by: Eric Anholt 
> >
> > Signed-off-by: Daniel Vetter 
> Yes, please :-)
> 
> Reviewed-by: Emil Velikov 

Also applied, thanks for your review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH 1/5] drm: Add new DCS commands in the enum list

[Daniel Vetter]

On Thu, Mar 31, 2016 at 07:54:18AM +0200, Andrzej Hajda wrote:
> On 03/30/2016 04:03 PM, Jani Nikula wrote:
> > From: Deepak M 
> >
> > Adding new DCS commands which are specified in the
> > DCS 1.3 spec related to CABC.
> >
> > v2: Sorted the Macro`s by value (Andrzej)
> >
> > v3 by Jani: sort all of enum, refer to MIPI DCS 1.3
> >
> > Cc: Andrzej Hajda 
> > Cc: Thierry Reding 
> > Cc: David Airlie 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Cc: 
> > Suggested-by: Jani Nikula 
> > Signed-off-by: Deepak M 
> > Signed-off-by: Jani Nikula 
> 
> DCS 1.3 introduces also:
> get_error_count_on_DSI 05h
> get_image_checksum_ct 15h
> get_image_checksum_rgb 14h
> read_PPS_continue a9h
> read_PPS_start A2h
> 
> It would be good to add them, but as the patch
> says it adds only CABC related commands so no big deal.
> 
> Reviewed-by: Andrzej Hajda 

Applied to drm-misc, thanks.
-Daniel

> 
> Regards
> Andrzej
> 
> > ---
> >  include/video/mipi_display.h | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> > index ddcc8ca7316b..19aa65a35546 100644
> > --- a/include/video/mipi_display.h
> > +++ b/include/video/mipi_display.h
> > @@ -115,6 +115,14 @@ enum {
> > MIPI_DCS_READ_MEMORY_CONTINUE   = 0x3E,
> > MIPI_DCS_SET_TEAR_SCANLINE  = 0x44,
> > MIPI_DCS_GET_SCANLINE   = 0x45,
> > +   MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_WRITE_CONTROL_DISPLAY  = 0x53, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_GET_CONTROL_DISPLAY= 0x54, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_WRITE_POWER_SAVE   = 0x55, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_GET_POWER_SAVE = 0x56, /* MIPI DCS 1.3 */
> > +   MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,/* MIPI DCS 1.3 */
> > +   MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,/* MIPI DCS 1.3 */
> > MIPI_DCS_READ_DDB_START = 0xA1,
> > MIPI_DCS_READ_DDB_CONTINUE  = 0xA8,
> >  };
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 1/2] drm/radeon: Set vblank_disable_allowed = true

[Michel Dänzer]

From: Michel Dänzer 

Without this, since the conversion from drm_vblank_pre/post_modeset to
drm_vblank_on/off, the vblank interrupt could never be disabled after
userspace triggered enabling it.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 979f3bf..1e9304d 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -291,6 +291,8 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
if (r) {
return r;
}
+   rdev->ddev->vblank_disable_allowed = true;
+
/* enable msi */
rdev->msi_enabled = 0;

-- 
2.8.0.rc3

[PATCH 2/2] drm/amdgpu: Set vblank_disable_allowed = true

[Michel Dänzer]

From: Michel Dänzer 

Without this, since the conversion from drm_vblank_pre/post_modeset to
drm_vblank_on/off, the vblank interrupt could never be disabled after
userspace triggered enabling it.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index f594cfa..762cfdb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -219,6 +219,8 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
if (r) {
return r;
}
+   adev->ddev->vblank_disable_allowed = true;
+
/* enable msi */
adev->irq.msi_enabled = false;

-- 
2.8.0.rc3

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.6-rc1

[Michel Dänzer]

On 30.03.2016 19:36, Julian Margetson wrote:
> On 3/29/2016 11:49 PM, Michel Dänzer wrote:
>> On 29.03.2016 18:55, Julian Margetson wrote:
>>> On 3/28/2016 11:15 PM, Michel Dänzer wrote:
>>>> On 29.03.2016 08:47, Julian Margetson wrote:
>>>>> Seeing the following when booting kernel 4.6-rc1 on Acube Sam460ex
>>>>> Canyonlands board.
>>>>> This loops for a few times then the kernel boots.
>>>>> No problem with the 4.6-rc1 with an A-eon Tabor Freescale e500v2
>>>>> board.
>>>>>
>>>>> Regards
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>>[2.197839] [ cut here ]
>>>>>[2.197850] WARNING: CPU: 0 PID: 1 at
>>>>> drivers/gpu/drm/drm_irq.c:1368 drm_vblank_off+0x2c/0x1e0
>>>> That's
>>>>
>>>>  if (WARN_ON(pipe >= dev->num_crtcs))
>>>>
>>>> My best guess is that drm_vblank_off is called before drm_vblank_init,
>>>> so dev->num_crtcs is still 0.
>>>>
>>>>
>>>> Please provide the full dmesg output corresponding to the problem.
>>>>
>>>>
>>> Attached
>> [...]
>>
>>> [drm] radeon: irq initialized.
>>> [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
>>> (scratch(0x850C)=0xCAFEDEAD)
>>> radeon 0001:81:00.0: disabling GPU acceleration
>> Okay, so the problem is that acceleration fails to initialize, in which
>> case the driver calls drm_vblank_cleanup.
>>
>> I can see two basic options for a solution: Either don't call
>> radeon_irq_kms_fini/drm_vblank_cleanup if acceleration fails to
>> initialize, or check if acceleration is enabled before calling
>> drm_vblank_on/off. Any preferences?
>>
>>
> Thanks
> 
> No preferences .

Does the attached patch fix the problem?


> I would be interested in a fix for the acceleration problem if possible .

Beware that while the kernel side of this might be relatively easy to
fix, making the userspace radeonsi driver work on big endian hosts would
likely require substantial effort.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: radeon-guard-vblank-on-off.diff
Type: text/x-patch
Size: 1914 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/8afc3297/attachment.bin>

[PATCH 1/3] drm/dp: Add definition for Display Control DPCD Registers capability size

[Jani Nikula]

On Wed, 30 Mar 2016, Yetunde Adebisi  wrote:
> This is used when reading Display Control capability Registers on the sink
> device.
>
> cc: Jani Nikula 
> cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Yetunde Adebisi 

Reviewed-by: Jani Nikula 


> ---
>  include/drm/drm_dp_helper.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 1252108..92d9a52 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -621,6 +621,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  #define DP_BRANCH_OUI_HEADER_SIZE0xc
>  #define DP_RECEIVER_CAP_SIZE 0xf
>  #define EDP_PSR_RECEIVER_CAP_SIZE2
> +#define EDP_DISPLAY_CTL_CAP_SIZE 3
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]);
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]);

-- 
Jani Nikula, Intel Open Source Technology Center

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist 
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>> explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists 
>> with implicit sync. However, these two sync fences can't see same DMA buffer 
>> because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the 
>> reservation object of dmabuf object somehow. Otherwise, although they 
>> coexist together, are these fences - explicit and implicit - used for 
>> differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic 
kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using 
implicit fence. So while GPU(producer side) is accessing DMA buffer after 
registering its explicit fence to atomic kms, and if atomic commit is requested 
by user-space, then atomic helper framework will try to synchronize with the 
producer - waiting for the signal of GPU side(producer), and device specific 
page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit 
fence support is added to the atomic helper framework. This would definitely be 
duplication and it seems not clear enough even if one of them is just skipped 
in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects 
separately but is that these fences can be performed separately for same 
purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether 
DMA drivers support implicit fence or not so as soon as user uses explicit 
fence, the duplication would happen.

There may be something I missed so your comment would be helpful in 
understanding it.


Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
> 

[PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event

[Tomeu Vizoso]

On 31 March 2016 at 03:25, Mark yao  wrote:
> On 2016年03月30日 21:48, Tomeu Vizoso wrote:
>>
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> Also wait for the pending event to complete when a sync update is
>> requested.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 14 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++
>>   3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> index 3529f692edb8..37952eefd33d 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> @@ -69,6 +69,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
>>   void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
>>   int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int
>> connector_type,
>>   int out_mode);
>> +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc);
>>   int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
>>struct device *dev);
>>   void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index 3b8f652698f8..028fd2f8f47b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> @@ -280,7 +280,19 @@ int rockchip_drm_atomic_commit(struct drm_device
>> *dev,
>>   {
>> struct rockchip_drm_private *private = dev->dev_private;
>> struct rockchip_atomic_commit *commit = &private->commit;
>> -   int ret;
>> +   struct drm_crtc_state *crtc_state;
>> +   struct drm_crtc *crtc;
>> +   int i, ret;
>> +
>> +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> +   if (crtc->state->event ||
>> +   rockchip_drm_crtc_has_pending_event(crtc)) {
>> +   if (async)
>> +   return -EBUSY;
>> +   else
>> +   rockchip_crtc_wait_for_update(crtc);
>
>
>> +   }
>> +   }
>> ret = drm_atomic_helper_prepare_planes(dev, state);
>> if (ret)
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index e2118e62345b..5240bc8fe088 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -848,6 +848,12 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc
>> *crtc,
>>   }
>>   EXPORT_SYMBOL_GPL(rockchip_drm_crtc_mode_config);
>>   +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc)
>> +{
>> +   return to_vop(crtc)->event;
>> +}
>> +EXPORT_SYMBOL_GPL(rockchip_drm_crtc_has_pending_event);
>> +
>
>
> No need to do EXPORT_SYMBOL_GPL, rockchip_drm_vop.c and rockchip_drm_fb.c
> will build into same object.
>
>
>>   static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
>>   {
>> struct vop *vop = to_vop(crtc);
>
> Hi Tomeu
>
> Since rockchip atomic async use "serialize outstanding asynchronous
> commits", async commit will wait on "flush_work(&commit->work);" to ensure
> last pending event is done, so vop->event should be NULL after flush. if
> not, it should be a BUG.

I missed that, thanks.

> Anyway, serialize async commits is not a good way, but I don't think your
> patch is better way.

Per-CRTC workqueues should improve that, but I'm right now more
interested in correctness than performance.

> I think maybe we can check the "commit->work" status(finish or running) to
> judge return BUSY or not, instead of flush it.

That sounds better indeed.

Thanks,

Tomeu

> Thanks.
>
> --
> ï¼­ark Yao
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v2

[Tomeu Vizoso]

As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".

v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.

Signed-off-by: Tomeu Vizoso 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 3b8f652698f8..285f8cd5afe1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -282,6 +282,9 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
struct rockchip_atomic_commit *commit = &private->commit;
int ret;

+   if (async && work_busy(&commit->work))
+   return -EBUSY;
+
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
return ret;
-- 
2.5.5

[PATCH] dma-buf: Release module reference on creation failure

[Chris Wilson]

If we fail to create the anon file, we need to remember to release the
module reference on the owner.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Daniel Vetter 
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
---
 drivers/dma-buf/dma-buf.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 4a2c07ee6677..6f0f0b10a241 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
struct reservation_object *resv = exp_info->resv;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
+   int ret;

if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
@@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)

dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (!dmabuf) {
-   module_put(exp_info->owner);
-   return ERR_PTR(-ENOMEM);
+   ret = -ENOMEM;
+   goto free_module;
}

dmabuf->priv = exp_info->priv;
@@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
exp_info->flags);
if (IS_ERR(file)) {
-   kfree(dmabuf);
-   return ERR_CAST(file);
+   ret = PTR_ERR(file);
+   goto free_dmabuf;
}

file->f_mode |= FMODE_LSEEK;
@@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
mutex_unlock(&db_list.lock);

return dmabuf;
+
+free_dmabuf:
+   kfree(dmabuf);
+free_module:
+   module_put(exp_info->owner);
+   return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(dma_buf_export);

-- 
2.8.0.rc3

[RFC 0/6] drm/fences: add in-fences to DRM

[Daniel Stone]

Hi Inki,

On 31 March 2016 at 08:45, Inki Dae  wrote:
> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>> In addition, I wonder how explicit and implicit fences could coexist 
>>> together.
>>> Rob said,
>>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>>> explicit sync instead"
>>>
>>> This would mean that if we use explicit sync for user-space then it 
>>> coexists with implicit sync. However, these two sync fences can't see same 
>>> DMA buffer because explicit fence has a different file object from implicit 
>>> one.
>>> So in this case, I think explicit fence would need to be hung up on the 
>>> reservation object of dmabuf object somehow. Otherwise, although they 
>>> coexist together, are these fences - explicit and implicit - used for 
>>> differenct purpose separately?
>>>
>>
>> I'm not entirely sure about coexistance at the same time.  It ofc
>> shouldn't be a problem for one kernel to support both kinds of
>> userspace (pure explicit and pure implicit).  And how this would work
>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>> ie. some sort of flag, which if set user provides an explicit fence
>> fd, and if not set we fall back to current behaviour (ie. get fences
>> from resv object).
>
> With this patch series, users can register explicit fence(s) to atomic 
> kms(consumer side) through kms property interface for the explicit sync.
>
> However, now several DRM drivers(also consumer) already have beeen using 
> implicit fence. So while GPU(producer side) is accessing DMA buffer after 
> registering its explicit fence to atomic kms, and if atomic commit is 
> requested by user-space, then atomic helper framework will try to synchronize 
> with the producer - waiting for the signal of GPU side(producer), and device 
> specific page flip function will also try to do same thing.

Well, it has to be one or the other: mixing explicit and implicit,
defeats the purpose of using explicit fencing. So, when explicit
fencing is in use, implicit fences must be ignored.

> As of now, it seems that this wouldn't be optional but mandatory if explicit 
> fence support is added to the atomic helper framework. This would definitely 
> be duplication and it seems not clear enough even if one of them is just 
> skipped in runtime.

Drivers would have to opt in to explicit fencing support, and part of
that would be ensuring that the driver does not wait on implicit
fences when the user has requested explicit fencing be used.

Cheers,
Daniel

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

[Jose Abreu]

Hi Mark,

On 29-03-2016 19:22, Mark Brown wrote:
> On Tue, Mar 29, 2016 at 07:03:01PM +0100, Jose Abreu wrote:
>
>> The major part of this patch is the adding of an ALSA platform driver so that
>> audio comes out of the box in AXS boards but we also added functionalities to
>> the i2s driver and performed one bug fix related with the mask/unmask of
>> interrupts. I will split the patches but they will depend on each other.
> If you want to add a new platform driver you need to add a new platform
> driver, not shove the code into an existing driver for a seperate IP.
>

I can separate the platform driver into a new file but they will have to be
compiled into the same module as the new additions to the i2s driver depend on
functions of the platform driver (see i2s_irq_handler()). Or should I divide
this into two modules and add a Kconfig option to the platform driver? Besides
this I first wanted the driver to be compiled into the same module so that it is
compatible with kernel 3.18 where simple audio card requires that platform
driver == cpu driver.

Best regards,
Jose Miguel Abreu

[Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.6-rc1

[Julian Margetson]

On 3/31/2016 2:50 AM, Michel Dänzer wrote:
> On 30.03.2016 19:36, Julian Margetson wrote:
>> On 3/29/2016 11:49 PM, Michel Dänzer wrote:
>>> On 29.03.2016 18:55, Julian Margetson wrote:
 On 3/28/2016 11:15 PM, Michel Dänzer wrote:
> On 29.03.2016 08:47, Julian Margetson wrote:
>> Seeing the following when booting kernel 4.6-rc1 on Acube Sam460ex
>> Canyonlands board.
>> This loops for a few times then the kernel boots.
>> No problem with the 4.6-rc1 with an A-eon Tabor Freescale e500v2
>> board.
>>
>> Regards
>>
>> Julian
>>
>>
>> [2.197839] [ cut here ]
>> [2.197850] WARNING: CPU: 0 PID: 1 at
>> drivers/gpu/drm/drm_irq.c:1368 drm_vblank_off+0x2c/0x1e0
> That's
>
>   if (WARN_ON(pipe >= dev->num_crtcs))
>
> My best guess is that drm_vblank_off is called before drm_vblank_init,
> so dev->num_crtcs is still 0.
>
>
> Please provide the full dmesg output corresponding to the problem.
>
>
 Attached
>>> [...]
>>>
 [drm] radeon: irq initialized.
 [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
 (scratch(0x850C)=0xCAFEDEAD)
 radeon 0001:81:00.0: disabling GPU acceleration
>>> Okay, so the problem is that acceleration fails to initialize, in which
>>> case the driver calls drm_vblank_cleanup.
>>>
>>> I can see two basic options for a solution: Either don't call
>>> radeon_irq_kms_fini/drm_vblank_cleanup if acceleration fails to
>>> initialize, or check if acceleration is enabled before calling
>>> drm_vblank_on/off. Any preferences?
>>>
>>>
>> Thanks
>>
>> No preferences .
> Does the attached patch fix the problem?
>
>
>> I would be interested in a fix for the acceleration problem if possible .
> Beware that while the kernel side of this might be relatively easy to
> fix, making the userspace radeonsi driver work on big endian hosts would
> likely require substantial effort.
>
>

Thanks

The patch solved the problem .
Tested-by: Julian Margetson 

I  would indeed like to see the kernel side fix for the the acceleration 
problem. (Been hoping for it for almost 3 years now)
http://marc.info/?l=dri-devel&m=137881893518240&w=2
I also have Northern Islands cards  and  acceleration with these does 
work with my other powerpc board, an e500v2 .
It also requires the patch in the linked post by Hans Verkuil for Radeon 
NI and SI cards to work .

Regards
Julian



-- next part --

U-Boot 2015.a (May 16 2015 - 14:20:11)

CPU:   AMCC PowerPC 460EX Rev. B at 1155 MHz (PLB=231 OPB=115 EBC=115)
   No Security/Kasumi support
   Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
   Internal PCI arbiter enabled
   32 kB I-Cache 32 kB D-Cache
Board: Sam460ex/cr, PCIe 4x + PCIe 1x
I2C:   ready
DRAM:  2 GiB (ECC not enabled, 462 MHz, CL4)
PCI:   Bus Dev VenId DevId Class Int
00  04  1095  3512  0104  00
00  06  126f  0501  0380  00
PCIE0: successfully set as root-complex
03  00  1412  1724  0401  ff
02  00  1b21  1080  0604  00
PCIE1: successfully set as root-complex
05  00  1002  683f  0300  ff
Net:   ppc_4xx_eth0
FPGA:  Revision 03 (2010-10-07)
SM502: found
PERMD2:not found
VGA:   1
VESA:  OK
[0.00] Using Canyonlands machine description
[0.00] Linux version 4.6.0-rc1-sam460ex-jm (root at julian-VirtualBox) 
(gcc version 5.3.1 20160205 (Ubuntu 5.3.1-8ubuntu2) ) #24 PREEMPT Thu Mar 31 
05:31:56 AST 2016
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x2fff]
[0.00]   Normal   empty
[0.00]   HighMem  [mem 0x3000-0x7fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x7fff]
[0.00] Initmem setup node 0 [mem 0x-0x7fff]
[0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 522752
[0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 
console=tty0
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Sorting __ex_table...
[0.00] allocated 2097152 bytes of page_ext
[0.00] Memory: 1997104K/2097152K available (8428K kernel code, 344K 
rwdata, 4220K rodata, 256K init, 1410K bss, 100048K reserved, 0K cma-reserved, 
1310720K highmem)
[0.00] Kernel virtual memory layout:
[0.00]   * 0xfffcf000..0xf000  : fixmap
[0.00]   * 0xffc0..0xffe0  : highmem PTEs
[0.00]   * 0xffa0..0xffc0  : consistent mem
[0.00]   * 0xffa0..0xffa0  : early ioremap
[0.00]   * 0xf100

[RFC 0/6] drm/fences: add in-fences to DRM

[Daniel Vetter]

On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.

You can mix it, if you're careful. CrOS wants that to better mesh android
with Ozone, and we'll be discussing what needs to be added to be able to
make it work implicit and explicit fencing work together, in both
directions. Of course this should only be used for shared buffers, e.g.
explicit syncing in an android client running on top of implicitly synced
ozone/kms.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 31 March 2016 at 08:45, Inki Dae  wrote:
>> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
 In addition, I wonder how explicit and implicit fences could coexist 
 together.
 Rob said,
 "Implicit sync ofc remains the default, but userspace could opt-in to 
 explicit sync instead"

 This would mean that if we use explicit sync for user-space then it 
 coexists with implicit sync. However, these two sync fences can't see same 
 DMA buffer because explicit fence has a different file object from 
 implicit one.
 So in this case, I think explicit fence would need to be hung up on the 
 reservation object of dmabuf object somehow. Otherwise, although they 
 coexist together, are these fences - explicit and implicit - used for 
 differenct purpose separately?

>>>
>>> I'm not entirely sure about coexistance at the same time.  It ofc
>>> shouldn't be a problem for one kernel to support both kinds of
>>> userspace (pure explicit and pure implicit).  And how this would work
>>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>>> ie. some sort of flag, which if set user provides an explicit fence
>>> fd, and if not set we fall back to current behaviour (ie. get fences
>>> from resv object).
>>
>> With this patch series, users can register explicit fence(s) to atomic 
>> kms(consumer side) through kms property interface for the explicit sync.
>>
>> However, now several DRM drivers(also consumer) already have beeen using 
>> implicit fence. So while GPU(producer side) is accessing DMA buffer after 
>> registering its explicit fence to atomic kms, and if atomic commit is 
>> requested by user-space, then atomic helper framework will try to 
>> synchronize with the producer - waiting for the signal of GPU 
>> side(producer), and device specific page flip function will also try to do 
>> same thing.
> 
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
> 
>> As of now, it seems that this wouldn't be optional but mandatory if explicit 
>> fence support is added to the atomic helper framework. This would definitely 
>> be duplication and it seems not clear enough even if one of them is just 
>> skipped in runtime.
> 
> Drivers would have to opt in to explicit fencing support, and part of
> that would be ensuring that the driver does not wait on implicit
> fences when the user has requested explicit fencing be used.
> 

Then, existing drivers would need additional works for explicit fencing 
support. This wouldn't be really what the drivers have to but should be handled 
with this patch series because this would affect exising device drivers which 
use implicit fencing.


Thanks,
Inki Dae

> Cheers,
> Daniel
> 
> 

[v14, 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Thierry Reding]

On Wed, Mar 30, 2016 at 01:32:04PM -0700, Guenter Roeck wrote:
> Hi,
> 
> On Mon, Feb 15, 2016 at 07:09:36PM +0800, Yakir Yang wrote:
> > Split the dp core driver from exynos directory to bridge directory,
> > and rename the core driver to analogix_dp_*, rename the platform
> > code to exynos_dp.
> > 
> > Beside the new analogix_dp driver would export six hooks.
> > "analogix_dp_bind()" and "analogix_dp_unbind()"
> > "analogix_dp_suspned()" and "analogix_dp_resume()"
> > "analogix_dp_detect()" and "analogix_dp_get_modes()"
> > 
> > The bind/unbind symbols is used for analogix platform driver to connect
> > with analogix_dp core driver. And the detect/get_modes is used for analogix
> > platform driver to init the connector.
> > 
> > They reason why connector need register in helper driver is rockchip drm
> > haven't implement the atomic API, but Exynos drm have implement it, so
> > there would need two different connector helper functions, that's why we
> > leave the connector register in helper driver.
> > 
> > Signed-off-by: Yakir Yang 
> > 
> [ ... ]
> 
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > new file mode 100644
> > index 000..9107b86
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o
> 
> This results in the following build errors if DRM_ANALOGIX_DP
> is configured as module.
> 
> ERROR: "analogix_dp_start_video" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane0_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane1_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane2_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane3_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane_count" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_link_bandwidth" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> 
> [ and so on ]

Ugh... most of these functions shouldn't be there in the first place. We
have helpers in the core that already do this. Most of the functionality
is duplicated in this driver.

I realize that this is a problem that existed in the Exynos DP driver,
but somebody really ought to rewrite those parts to make use of the DRM
DP helpers.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/5f26b101/attachment-0001.sig>

[PATCH v14 0/17] Add Analogix Core Display Port Driver

[Daniel Vetter]

On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> 
> Hi all,
> 
>   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> share the same IP, so a lot of parts can be re-used. I split the common
> code into bridge directory, then rk3288 and exynos only need to keep
> some platform code. Cause I can't find the exact IP name of exynos dp
> controller, so I decide to name dp core driver with "analogix" which I
> find in rk3288 eDP TRM
> 
> But there are still three light registers setting different between
> exynos and rk3288.
> 1. RK3288 have five special pll registers which not indicate in exynos
>dp controller.
> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>between rk3288 and exynos.
> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
>register).
> 
> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> okay to use the ATOMIC helpers functions in connector_funcs. No need to splict
> the connector init to platform driver anymore, and this is the biggest change
> since version 11.
> 
> This v14 didn't have lots of new changes which seems not the correct time to
> upgrade the version number, but I have changed ordering of patches (adding 2
> more, and removing 2 out). Especially to prevent confusing people, so I 
> updated
> the whole series.

So I'm jumping into this part way late, but just noticed (well Thierry
pointed this out to me) that the exynos dp driver reinvents all the dp and
dp-aux helpers we already. That's somewhat okish for a private driver (and
exynos has a reputation for that kind of stuff), but imo not ok for a
shared driver.

Not saying this should block merging this patch, but it really needs to be
addressed. All the dp aux and edid read code in the current
exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
core i2c edid reading code.

Who's going to sign up to do this?
-Daniel

> 
> Thanks,
> - Yakir
> 
> 
> Changes in v14:
> - Rebase the new changes in imx-dp driver
> - Split up this patch into 3 parts, make this easy to review (Heiko)
> - Remove the Rockchip DP PHY to an separate thread (Heiko)
> https://patchwork.kernel.org/patch/8312701/
> 
> Changes in v13:
> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
> - Fix the missing parameters with drm_encoder_init() helper function. (Heiko)
> 
> Changes in v12:
> - Move the connector init to analogix_dp driver, and using ATOMIC helper 
> (Heiko)
> - Add the ack from Jingoo
> - Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
> (Jingoo)
> 
> Changes in v11:
> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
> - Add the ack from Rob Herring
> - Revert parts of Gustavo Padovan's changes in commit:
>   drm/exynos: do not start enabling DP at bind() phase
>   Add dp phy poweron function in bind time.
> - Move the panel prepare from get_modes time to bind time, and move
>   the panel unprepare from bridge->disable to unbind time. (Heiko)
> 
> Changes in v10:
> - Add the ack from Rob Herring
> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
> - Add the ack from Rob Herring
> - Remove the surplus "plat_data" check. (Heiko)
> -   switch (dp->plat_data && dp->plat_data->dev_type) {
> +   switch (dp->plat_data->dev_type) {
> 
> Changes in v9:
> - Document more details for 'ports' property.
> 
> Changes in v8:
> - Correct the right document path of display-timing.txt (Heiko)
> - Correct the misspell of 'from' to 'frm'. (Heiko)
> - Modify the commit subject name. (Heiko)
> 
> Changes in v7:
> - Back to use the of_property_read_bool() interfacs to provoid backward
>   compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>   to avoid -EOVERFLOW error (Krzysztof)
> 
> Changes in v6:
> - Fix the Kconfig recursive dependency (Javier)
> - Fix Peach Pit hpd property name error:
> -   hpd-gpio = <&gpx2 6 0>;
> +   hpd-gpios = <&gpx2 6 0>;
> 
> Changes in v5:
> - Correct the check condition of gpio_is_valid when driver try to get
>   the "hpd-gpios" DT propery. (Heiko)
> - Move the platform attach callback in the front of core driver bridge
>   attch function. Cause once platform failed at attach, core driver should
>   still failed, so no need to init connector before platform attached 
> (Krzysztof)
> - Keep code style no changes with the previous exynos_dp_code.c in this
>   patch, and update commit message about the new export symbol (Krzysztof)
> - Gather the device type patch (v4 11/16) into this one. (Krzysztof)
> - leave out the connector registration to analogix platform driver. (Thierry)
> - Resequence this patch after analogix_dp driver have been split
>   from exynos_dp code, and rephrase reasonable commit message, and
>   remove some controversial style (Krzysztof)
> - analogix_dp_write_

[PATCH v14 0/17] Add Analogix Core Display Port Driver

[Thierry Reding]

On Thu, Mar 31, 2016 at 12:15:35PM +0200, Daniel Vetter wrote:
> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
> > 
> > Hi all,
> > 
> >   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
> > share the same IP, so a lot of parts can be re-used. I split the common
> > code into bridge directory, then rk3288 and exynos only need to keep
> > some platform code. Cause I can't find the exact IP name of exynos dp
> > controller, so I decide to name dp core driver with "analogix" which I
> > find in rk3288 eDP TRM
> > 
> > But there are still three light registers setting different between
> > exynos and rk3288.
> > 1. RK3288 have five special pll registers which not indicate in exynos
> >dp controller.
> > 2. The address of DP_PHY_PD(dp phy power manager register) are different
> >between rk3288 and exynos.
> > 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
> >register).
> > 
> > Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
> > okay to use the ATOMIC helpers functions in connector_funcs. No need to 
> > splict
> > the connector init to platform driver anymore, and this is the biggest 
> > change
> > since version 11.
> > 
> > This v14 didn't have lots of new changes which seems not the correct time to
> > upgrade the version number, but I have changed ordering of patches (adding 2
> > more, and removing 2 out). Especially to prevent confusing people, so I 
> > updated
> > the whole series.
> 
> So I'm jumping into this part way late, but just noticed (well Thierry
> pointed this out to me) that the exynos dp driver reinvents all the dp and
> dp-aux helpers we already. That's somewhat okish for a private driver (and
> exynos has a reputation for that kind of stuff), but imo not ok for a
> shared driver.
> 
> Not saying this should block merging this patch, but it really needs to be
> addressed. All the dp aux and edid read code in the current
> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
> core i2c edid reading code.

Agreed. I think a first step would be to implement and register a
drm_dp_aux object for Analogix DP hardware. That will give you access to
a slew of helpers that allow to read DPCD, parse link status and use the
standard EDID reading routines that the DRM core already has. This
should remove a lot of duplication from this driver.

For extra incentive, doing this might even fix a bug or two.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/6a5cf18a/attachment.sig>

[PATCH 10/10] drm/tegra: Don't set a gamma table size

[Thierry Reding]

On Wed, Mar 30, 2016 at 11:51:25AM +0200, Daniel Vetter wrote:
> tegra doesn't have any functions to set gamma tables, so this is
> completely defunct.
> 
> Not nice to lie to userspace, so let's stop!
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/dc.c | 1 -
>  1 file changed, 1 deletion(-)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/322db032/attachment.sig>

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

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

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

--- Comment #27 from Maarten Lankhorst  ---
Indeed, this is not a fix. It only keeps the fence alive during wait.

Very likely radeon has a double free somewhere. :(

-- 
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/20160331/354cbb70/attachment.html>

[PATCH libdrm] tegra: Sync with Linux kernel UAPI header

[Thierry Reding]

From: Thierry Reding 

Update the UAPI header to the latest version in the Linux kernel. This
changes the struct drm_tegra_gem_mmap to properly handle offsets on 64-
bit architectures.

See commit bdf765071a8b ("drm/tegra: gem: Return 64-bit offset for
mmap(2)") in the Linux kernel (as of v4.1).

Signed-off-by: Thierry Reding 
---
 include/drm/tegra_drm.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
index 8dae8f334992..7c0fe0ed511b 100644
--- a/include/drm/tegra_drm.h
+++ b/include/drm/tegra_drm.h
@@ -36,7 +36,8 @@ struct drm_tegra_gem_create {

 struct drm_tegra_gem_mmap {
__u32 handle;
-   __u32 offset;
+   __u32 pad;
+   __u64 offset;
 };

 struct drm_tegra_syncpt_read {
-- 
2.7.1

[RFC 0/6] drm/fences: add in-fences to DRM

[Daniel Stone]

Hi Inki,

On 31 March 2016 at 11:05, Inki Dae  wrote:
> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>> On 31 March 2016 at 08:45, Inki Dae  wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>> explicit fence support is added to the atomic helper framework. This would 
>>> definitely be duplication and it seems not clear enough even if one of them 
>>> is just skipped in runtime.
>>
>> Drivers would have to opt in to explicit fencing support, and part of
>> that would be ensuring that the driver does not wait on implicit
>> fences when the user has requested explicit fencing be used.
>>
>
> Then, existing drivers would need additional works for explicit fencing 
> support. This wouldn't be really what the drivers have to but should be 
> handled with this patch series because this would affect exising device 
> drivers which use implicit fencing.

Well, yes. Anyone implementing their own atomic commit would need to
ensure that the commit works properly for fences. The helpers could
also add it, but the helpers are not mandatory, and you are not
required to use every part of the helper to use one part of the
helper. There is no magic wand you can wave that instantly makes it
work for every driver.

Cheers,
Daniel

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v3.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)

Cc: stable at vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_flip.flip-vs-rmfb-interruptible
References: 
https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom 
Cc: David Herrmann 
---
 drivers/gpu/drm/drm_crtc.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55ffde5a3a4a..743bece1f579 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3434,6 +3434,18 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
 }

+struct drm_mode_rmfb_work {
+   struct work_struct work;
+   struct drm_framebuffer *fb;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+   struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+   drm_framebuffer_remove(arg->fb);
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3474,7 +3486,22 @@ int drm_mode_rmfb(struct drm_device *dev,
mutex_unlock(&dev->mode_config.fb_lock);
mutex_unlock(&file_priv->fbs_lock);

-   drm_framebuffer_unreference(fb);
+   /*
+* drm_framebuffer_remove may fail with -EINTR on pending signals,
+* so run this in a separate stack as there's no way to correctly
+* handle this after the fb is already removed from the lookup table.
+*/
+   if (atomic_read(&fb->refcount.refcount) > 1) {
+   struct drm_mode_rmfb_work arg;
+
+   INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
+   arg.fb = fb;
+
+   schedule_work(&arg.work);
+   flush_work(&arg.work);
+   destroy_work_on_stack(&arg.work);
+   } else
+   drm_framebuffer_unreference(fb);

return 0;

-- 
2.1.0

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae  wrote:
>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>> On 31 March 2016 at 08:45, Inki Dae  wrote:
 As of now, it seems that this wouldn't be optional but mandatory if 
 explicit fence support is added to the atomic helper framework. This would 
 definitely be duplication and it seems not clear enough even if one of 
 them is just skipped in runtime.
>>>
>>> Drivers would have to opt in to explicit fencing support, and part of
>>> that would be ensuring that the driver does not wait on implicit
>>> fences when the user has requested explicit fencing be used.
>>>
>>
>> Then, existing drivers would need additional works for explicit fencing 
>> support. This wouldn't be really what the drivers have to but should be 
>> handled with this patch series because this would affect exising device 
>> drivers which use implicit fencing.
>
> Well, yes. Anyone implementing their own atomic commit would need to
> ensure that the commit works properly for fences. The helpers could
> also add it, but the helpers are not mandatory, and you are not
> required to use every part of the helper to use one part of the
> helper. There is no magic wand you can wave that instantly makes it
> work for every driver

I meant there are already several DRM drivers which work properly for
implicit fence. So if atomic helper framework of DRM core is
considered only for the explicit fence, then fencing operation would
affect the existing DRM drivers. So I hope this trying could consider
existing implicit fence users.

Thanks,
Inki Dae
. 
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016-03-31 19:04 GMT+09:00 Daniel Vetter :
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
>
> You can mix it, if you're careful. CrOS wants that to better mesh android
> with Ozone, and we'll be discussing what needs to be added to be able to
> make it work implicit and explicit fencing work together, in both
> directions. Of course this should only be used for shared buffers, e.g.
> explicit syncing in an android client running on top of implicitly synced
> ozone/kms.

Good idea. I hope fence things of mainline would be more discussed so
could be considered for many cases.

Thanks,
Inki Dae

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 0/6] drm/fences: add in-fences to DRM

[Daniel Stone]

Hi Inki,

On 31 March 2016 at 12:26, Inki Dae  wrote:
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> On 31 March 2016 at 11:05, Inki Dae  wrote:
>>> Then, existing drivers would need additional works for explicit fencing 
>>> support. This wouldn't be really what the drivers have to but should be 
>>> handled with this patch series because this would affect exising device 
>>> drivers which use implicit fencing.
>>
>> Well, yes. Anyone implementing their own atomic commit would need to
>> ensure that the commit works properly for fences. The helpers could
>> also add it, but the helpers are not mandatory, and you are not
>> required to use every part of the helper to use one part of the
>> helper. There is no magic wand you can wave that instantly makes it
>> work for every driver
>
> I meant there are already several DRM drivers which work properly for
> implicit fence. So if atomic helper framework of DRM core is
> considered only for the explicit fence, then fencing operation would
> affect the existing DRM drivers. So I hope this trying could consider
> existing implicit fence users.

Yes, absolutely. Implicit fencing is already part of userspace ABI
that we can effectively never remove: it would break everyone's
desktops on Intel alone, as well as many others. So explicit will be
opt-in from the user and the driver both, and only when the
combination is fully supported will explicit fencing be used.

Cheers,
Daniel

[Bug 94667] Artifacts on applications on discrete and kernel freezes

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

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

--- Comment #14 from Vladislav Kamenev  ---
Discrovered that artifacts is present only when FPS higher than 20-30

-- 
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/20160331/09c7c0bb/attachment-0001.html>

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

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

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

--- Comment #28 from Vladislav Kamenev  ---
Have been playing for hours and got only 
[62667.941234] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure
on pipe B (start=3758680 end=3758681) time 206 us, min 1017, max 1023, scanline
start 1010, end 1022

error in dmesg.
Using patched kernel.

-- 
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/20160331/75647d60/attachment.html>

[Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

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

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

--- Comment #6 from smidjar2.reg at email.cz ---
I disassembled ApplyConstants() where the game crashes when using OpenGL
override to 4.2. It is indeed a game bug, caused by possible NULL dereference.
Crash occurs at line marked by =>

   0x748467e0 <+0>:push   r15
   0x748467e2 <+2>:push   r14
   0x748467e4 <+4>:push   r12
   0x748467e6 <+6>:push   rbx
   0x748467e7 <+7>:push   rax
   0x748467e8 <+8>:movr14,rdi
   0x748467eb <+11>:moveax,DWORD PTR [r14+0x6f8]
   0x748467f2 <+18>:movrcx,QWORD PTR [rip+0xd297]#
0x74853a90
   0x748467f9 <+25>:cmpeax,DWORD PTR [rcx]
   0x748467fb <+27>:je 0x74846959
<_ZN3api14OpenGLRenderer14ApplyConstantsEv+377>
   0x74846801 <+33>:xorr15d,r15d
   0x74846804 <+36>:test   eax,0x3ff
   0x74846809 <+41>:je 0x74846845
<_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x7484680b <+43>:movzx  ecx,ax
   0x7484680e <+46>:movedx,DWORD PTR [r14+0xc4]
   0x74846815 <+53>:xorr15d,r15d
   0x74846818 <+56>:cmprcx,rdx
   0x7484681b <+59>:jae0x74846845
<_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x7484681d <+61>:shreax,0x10
   0x74846820 <+64>:movrdx,QWORD PTR [r14+0xe0]
   0x74846827 <+71>:xorr15d,r15d
   0x7484682a <+74>:movzx  edx,WORD PTR [rdx+rcx*2]
   0x7484682e <+78>:andeax,0x3ff
   0x74846833 <+83>:cmpeax,edx
   0x74846835 <+85>:jne0x74846845
<_ZN3api14OpenGLRenderer14ApplyConstantsEv+101>
   0x74846837 <+87>:imul   r15,rcx,0x110
   0x7484683e <+94>:addr15,QWORD PTR [r14+0xb8]
=> 0x74846845 <+101>:movrcx,QWORD PTR [r15+0x10]
   ..


//0x748467eb:
  eax = this->variable_at_offset_0x6f8
//0x748467f2:
  rcx = some_related_global_or_static_variable
//0x748467fb:
  if (eax != rcx) {
// 0x74846801:
r15 = NULL
if ((eax & 0x3ff) != 0) {
   // ...
   // r15 is set in this block to valid value
   // ...
}
// 0x74846845:
rcx = r15->variable_at_offset_0x10 // crash here because r15 can be NULL
  }
// function end

-- 
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/20160331/a340b2f3/attachment.html>

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

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

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

--- Comment #29 from russianneuromancer at ya.ru ---
> Now i use NFS:Underground to cause freezes.
> Have been playing for hours
Vladislav, NFS doesn't cause freezes for you this time? Or you played different
game?

-- 
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/20160331/78d4b3f4/attachment.html>

[Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

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

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

--- Comment #7 from Laurent carlier  ---
See https://lists.freedesktop.org/archives/mesa-dev/2016-March/109789.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/20160331/2e594acb/attachment.html>

[PATCH v9 0/7] Implement generic ASoC HDMI codec and use it in tda998x

[Jyri Sarha]

Couple of minor changes since v8 to ALSA/ASoC side patches. The series
is based on top of drm-next. However, it does not look like there is
enough attention to the DRM side so that the tda998x patches would get
in any time soon. So I am happy to rebase the first ALSA-side patches
on top of Mark Brown's for-next tree, for instance, if they would have
a change to go in on their own. The first two IEC958 helper patches
should apply as such.

There is currently two other patch series[2][3] that depend on the
first three (ALSA-) patches of this series. The third ("ASoC:
hdmi-codec: Add audio abort() callback for video side to use") is
currently not used and can be dropped if so decided. The rest depends
on those the first patches and adds hdmi-audio support for
Beaglebone-black.

Best regards,
Jyri

[1] "[PATCH v6 0/6] Implement generic ASoC HDMI codec and use it in tda998x"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105524.html
[2] "[PATCH v6 00/10] ASoC: Add mediatek HDMI codec support" by Philipp Zabel 
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105509.html
[3] "[RFC v2 0/6] sti: add audio interface to the hdmi driver"

http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103374.html
and "[PATCH v4 0/6] add IEC958 channel status control helpers"
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105502.html
by Arnaud Pouliquen

Changes since v8
* "ALSA: pcm: add IEC958 channel status helper for hw_params"
  - Split out the 32 bit support
  - add: "ALSA: pcm: Allow 32 bit sample format in IEC958 channel status helper"
* "ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders"
  - Set hw_params->msbits to 24 in hw_params() callback if sample width is
greater than 24 bits

Changes since v7
* "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
  - Remove the unused "int ret" variable from tda998x_configure_audio()

Changes since v6
* "ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders"
 - Add "Acked-by: Arnaud Pouliquen " and
   "Tested-by: Philipp Zabel ", no other changes
* "ALSA: pcm: add IEC958 channel status helper for hw_param"
 - Added kernel-doc for snd_pcm_create_iec958_consumer_hw_params()
* "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
 - Use PTR_ERR_OR_ZERO() in tda998x_audio_codec_init()
 - Fix possible uninitialized use of 'size' in tda998x_get_audio_ports()
 - Store audio configuration in tda998x_audio_hw_params() instead of
   tda998x_configure_audio().

Changes since v5
 - Rebased on top of the latest drm-next branch
 - Allow 32 bit samplewidth in snd_pcm_create_iec958_consumer() and
   snd_pcm_create_iec958_consumer_hw_params()
 - Propose new simpler DT binding for tda998x audio
 - Squash tda998x audio DT binding together with hdmi-codec integration

Changes since RFC v4,
 - Rebased on top of the latest drm-next branch
 - Split the hdmi-codec abort functionality into a separate patch for
   better visibility of what it is all about
   - This does not affect the tda998x patches as the abort
 functionality is not used
 - Drop S18_3* formats from I2S_FORMATS and add a comment about formats
   not supported by HDMI

Changes since RFC v3,
 ASoC side:
 - Add "ALSA: pcm: add IEC958 channel status helper for hw_params"
 - Add "tda998x: Improve tda998x_configure_audio() audio related pdata"
 - use snd_pcm_create_iec958_consumer_hw_params() to construct the stream header
 - Remove set_clk() callback from hdmi-codec. It is not needed for now.
 - Refer to stream header in AIF as specified in HDMI standard
 - Set current_stream to NULL only after video side audio_shutdown() has
   been called. Avoid potential race if video side attempts to abort audio
   at the same time.
 - No need to have video side device pointer in the hdmi codec's pdata as
   it is found from dev->parent.
 - Fix hdmi-codec enum: DAI_ID_I2C > DAI_ID_I2S
 - Improve audio_startup API comment
 - Make improved checkpatch happy 
   - BUG_ON > WARN_ON
   - put */ ending the block comment to a separate line

 DRM side:
 - Fix tda998x get_eld() locking
 - Change tda998x audio parameters in pdata to more generic, that can
   be readily used in tda998x_audio_config()
 - Rename and restructure audio port related private data members to
   be more descriptive
 - Require audio configuration trough ASoC hdmi-codec if HDMI audio is
   configured trough DT binding. 

 DTS:
 - Increase McASP fifo usage form 1 to 32

Jyri Sarha (7):
  ALSA: pcm: add IEC958 channel status helper for hw_params
  ALSA: pcm: Allow 32 bit sample format in IEC958 channel status helper
  ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders
  ASoC: hdmi-codec: Add audio abort() callback for video side to use
  drm/i2c: tda998x: Improve tda998x_configure_audio() audio related
pdata
  drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
  ARM: dts: am335x-boneblack: Add HDMI audio support

 .../devicet

[PATCH v9 1/7] ALSA: pcm: add IEC958 channel status helper for hw_params

[Jyri Sarha]

Add IEC958 channel status helper that gets the audio properties from
snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
produce the channel status bits already in audio stream configuration
phase.

Signed-off-by: Jyri Sarha 
---
 include/sound/pcm_iec958.h |  2 ++
 sound/core/pcm_iec958.c| 64 ++
 2 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/include/sound/pcm_iec958.h b/include/sound/pcm_iec958.h
index 0eed397..36f023a 100644
--- a/include/sound/pcm_iec958.h
+++ b/include/sound/pcm_iec958.h
@@ -6,4 +6,6 @@
 int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
size_t len);

+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len);
 #endif
diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
index 36b2d7a..e016871 100644
--- a/sound/core/pcm_iec958.c
+++ b/sound/core/pcm_iec958.c
@@ -9,30 +9,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 

-/**
- * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
- * @runtime: pcm runtime structure with ->rate filled in
- * @cs: channel status buffer, at least four bytes
- * @len: length of channel status buffer
- *
- * Create the consumer format channel status data in @cs of maximum size
- * @len corresponding to the parameters of the PCM runtime @runtime.
- *
- * Drivers may wish to tweak the contents of the buffer after creation.
- *
- * Returns: length of buffer, or negative error code if something failed.
- */
-int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
-   size_t len)
+static int create_iec958_consumer(uint rate, uint sample_width,
+ u8 *cs, size_t len)
 {
unsigned int fs, ws;

if (len < 4)
return -EINVAL;

-   switch (runtime->rate) {
+   switch (rate) {
case 32000:
fs = IEC958_AES3_CON_FS_32000;
break;
@@ -59,7 +47,7 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,
}

if (len > 4) {
-   switch (snd_pcm_format_width(runtime->format)) {
+   switch (sample_width) {
case 16:
ws = IEC958_AES4_CON_WORDLEN_20_16;
break;
@@ -92,4 +80,46 @@ int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime 
*runtime, u8 *cs,

return len;
 }
+
+/**
+ * snd_pcm_create_iec958_consumer - create consumer format IEC958 channel 
status
+ * @runtime: pcm runtime structure with ->rate filled in
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer(struct snd_pcm_runtime *runtime, u8 *cs,
+   size_t len)
+{
+   return create_iec958_consumer(runtime->rate,
+ snd_pcm_format_width(runtime->format),
+ cs, len);
+}
 EXPORT_SYMBOL(snd_pcm_create_iec958_consumer);
+
+/**
+ * snd_pcm_create_iec958_consumer_hw_params - create IEC958 channel status
+ * @hw_params: the hw_params instance for extracting rate and sample format
+ * @cs: channel status buffer, at least four bytes
+ * @len: length of channel status buffer
+ *
+ * Create the consumer format channel status data in @cs of maximum size
+ * @len corresponding to the parameters of the PCM runtime @runtime.
+ *
+ * Drivers may wish to tweak the contents of the buffer after creation.
+ *
+ * Returns: length of buffer, or negative error code if something failed.
+ */
+int snd_pcm_create_iec958_consumer_hw_params(struct snd_pcm_hw_params *params,
+u8 *cs, size_t len)
+{
+   return create_iec958_consumer(params_rate(params), params_width(params),
+ cs, len);
+}
+EXPORT_SYMBOL(snd_pcm_create_iec958_consumer_hw_params);
-- 
1.9.1

[PATCH v9 4/7] ASoC: hdmi-codec: Add audio abort() callback for video side to use

[Jyri Sarha]

Add audio abort() callback, that is provided at audio stream start,
for video side. This is for video side to use in case there is a
pressing need to tear down the audio playback for some reason.

Signed-off-by: Jyri Sarha 
---
 include/sound/hdmi-codec.h|  8 ++--
 sound/soc/codecs/hdmi-codec.c | 20 +++-
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index fc3a481..15fe70f 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -55,10 +55,14 @@ struct hdmi_codec_params {

 struct hdmi_codec_ops {
/*
-* Called when ASoC starts an audio stream setup.
+* Called when ASoC starts an audio stream setup. The call
+* provides an audio abort callback for stoping an ongoing
+* stream from video side driver if the HDMI audio becomes
+* unavailable.
 * Optional
 */
-   int (*audio_startup)(struct device *dev);
+   int (*audio_startup)(struct device *dev,
+void (*abort_cb)(struct device *dev));

/*
 * Configures HDMI-encoder for audio stream.
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index b46b8ed..35151a4 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -47,6 +47,23 @@ enum {
DAI_ID_SPDIF,
 };

+static void hdmi_codec_abort(struct device *dev)
+{
+   struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
+
+   dev_dbg(dev, "%s()\n", __func__);
+
+   mutex_lock(&hcp->current_stream_lock);
+   if (hcp->current_stream && hcp->current_stream->runtime &&
+   snd_pcm_running(hcp->current_stream)) {
+   dev_info(dev, "HDMI audio playback aborted\n");
+   snd_pcm_stream_lock_irq(hcp->current_stream);
+   snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
+   snd_pcm_stream_unlock_irq(hcp->current_stream);
+   }
+   mutex_unlock(&hcp->current_stream_lock);
+}
+
 static int hdmi_codec_new_stream(struct snd_pcm_substream *substream,
 struct snd_soc_dai *dai)
 {
@@ -78,7 +95,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream 
*substream,
return ret;

if (hcp->hcd.ops->audio_startup) {
-   ret = hcp->hcd.ops->audio_startup(dai->dev->parent);
+   ret = hcp->hcd.ops->audio_startup(dai->dev->parent,
+ hdmi_codec_abort);
if (ret) {
mutex_lock(&hcp->current_stream_lock);
hcp->current_stream = NULL;
-- 
1.9.1

[PATCH v9 5/7] drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata

[Jyri Sarha]

Define struct tda998x_audio_params in include/drm/i2c/tda998x.h and
use it in pdata and for tda998x_configure_audio() parameters. Also
updates tda998x_write_aif() to take struct hdmi_audio_infoframe *
directly as a parameter.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 77 ---
 include/drm/i2c/tda998x.h | 24 +++-
 2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f4315bc..f97b748 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -41,7 +41,7 @@ struct tda998x_priv {
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
-   struct tda998x_encoder_params params;
+   struct tda998x_audio_params audio_params;

wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
@@ -666,26 +666,16 @@ tda998x_write_if(struct tda998x_priv *priv, u8 bit, u16 
addr,
reg_set(priv, REG_DIP_IF_FLAGS, bit);
 }

-static void
-tda998x_write_aif(struct tda998x_priv *priv, struct tda998x_encoder_params *p)
+static int tda998x_write_aif(struct tda998x_priv *priv,
+struct hdmi_audio_infoframe *cea)
 {
union hdmi_infoframe frame;

-   hdmi_audio_infoframe_init(&frame.audio);
-
-   frame.audio.channels = p->audio_frame[1] & 0x07;
-   frame.audio.channel_allocation = p->audio_frame[4];
-   frame.audio.level_shift_value = (p->audio_frame[5] & 0x78) >> 3;
-   frame.audio.downmix_inhibit = (p->audio_frame[5] & 0x80) >> 7;
-
-   /*
-* L-PCM and IEC61937 compressed audio shall always set sample
-* frequency to "refer to stream".  For others, see the HDMI
-* specification.
-*/
-   frame.audio.sample_frequency = (p->audio_frame[2] & 0x1c) >> 2;
+   frame.audio = *cea;

tda998x_write_if(priv, DIP_IF_FLAGS_IF4, REG_IF4_HB0, &frame);
+
+   return 0;
 }

 static void
@@ -710,20 +700,21 @@ static void tda998x_audio_mute(struct tda998x_priv *priv, 
bool on)
}
 }

-static void
+static int
 tda998x_configure_audio(struct tda998x_priv *priv,
-   struct drm_display_mode *mode, struct tda998x_encoder_params *p)
+   struct tda998x_audio_params *params,
+   unsigned mode_clock)
 {
u8 buf[6], clksel_aip, clksel_fs, cts_n, adiv;
u32 n;

/* Enable audio ports */
-   reg_write(priv, REG_ENA_AP, p->audio_cfg);
-   reg_write(priv, REG_ENA_ACLK, p->audio_clk_cfg);
+   reg_write(priv, REG_ENA_AP, params->config);

/* Set audio input source */
-   switch (p->audio_format) {
+   switch (params->format) {
case AFMT_SPDIF:
+   reg_write(priv, REG_ENA_ACLK, 0);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_SPDIF);
clksel_aip = AIP_CLKSEL_AIP_SPDIF;
clksel_fs = AIP_CLKSEL_FS_FS64SPDIF;
@@ -731,15 +722,29 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

case AFMT_I2S:
+   reg_write(priv, REG_ENA_ACLK, 1);
reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
clksel_aip = AIP_CLKSEL_AIP_I2S;
clksel_fs = AIP_CLKSEL_FS_ACLK;
-   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   switch (params->sample_width) {
+   case 16:
+   cts_n = CTS_N_M(3) | CTS_N_K(1);
+   break;
+   case 18:
+   case 20:
+   case 24:
+   cts_n = CTS_N_M(3) | CTS_N_K(2);
+   break;
+   default:
+   case 32:
+   cts_n = CTS_N_M(3) | CTS_N_K(3);
+   break;
+   }
break;

default:
BUG();
-   return;
+   return -EINVAL;
}

reg_write(priv, REG_AIP_CLKSEL, clksel_aip);
@@ -755,11 +760,11 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * assume 100MHz requires larger divider.
 */
adiv = AUDIO_DIV_SERCLK_8;
-   if (mode->clock > 10)
+   if (mode_clock > 10)
adiv++; /* AUDIO_DIV_SERCLK_16 */

/* S/PDIF asks for a larger divider */
-   if (p->audio_format == AFMT_SPDIF)
+   if (params->format == AFMT_SPDIF)
adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */

reg_write(priv, REG_AUDIO_DIV, adiv);
@@ -768,7 +773,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
 * This is the approximate value of N, which happens to be
 * the recommended values for non-coherent clocks.
 */
-   n = 128 * p->audio_sample_rate / 1000;
+   n = 128 * params->sample_rate / 1000;

/* Write the CTS and N values */
buf[0] = 0x44;
@@ -787,19 +792,13 @@ tda99

[PATCH v9 2/7] ALSA: pcm: Allow 32 bit sample format in IEC958 channel status helper

[Jyri Sarha]

Treat 32 bit sample width as if it was 24 bits when generating IEC958
channel status bits. On some platforms 24 sample width is problematic
and to get full 24 bit precision a 32 bit format, using only the 24
most significant bits, may have to be used.

Signed-off-by: Jyri Sarha 
---
 sound/core/pcm_iec958.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/core/pcm_iec958.c b/sound/core/pcm_iec958.c
index e016871..5e6aed6 100644
--- a/sound/core/pcm_iec958.c
+++ b/sound/core/pcm_iec958.c
@@ -59,6 +59,7 @@ static int create_iec958_consumer(uint rate, uint 
sample_width,
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
case 24:
+   case 32: /* Assume 24-bit width for 32-bit samples. */
ws = IEC958_AES4_CON_WORDLEN_24_20 |
 IEC958_AES4_CON_MAX_WORDLEN_24;
break;
-- 
1.9.1

[PATCH v9 6/7] drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding

[Jyri Sarha]

Register ASoC HDMI codec for audio functionality and adds device tree
binding for audio configuration.

With the registered HDMI codec the tda998x node can be used like a
regular codec node in ASoC card configurations. HDMI audio info-frame
and audio stream header is generated by the ASoC HDMI codec. The codec
also applies constraints for available sample-rates based on Edid Like
Data from the display. The device tree binding document has been
updated [1].

Part of this patch has been inspired by Jean Francoise's "drm/i2c: tda998x:
Add support of a DT graph of ports"-patch [2]. There may still be some
identical lines left from the original patch and some of the ideas
have come from there.

[1] Documentation/devicetree/bindings/display/bridge/tda998x.txt
[2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/095255.html

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 198 -
 include/drm/i2c/tda998x.h  |   4 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 5 files changed, 223 insertions(+), 5 deletions(-)
 create mode 100644 include/dt-bindings/display/tda998x.h

diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index e178e6b..24cc246 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -21,8 +21,19 @@ Optional properties:
   - video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>

+  - audio-ports: array of 8-bit values, 2 values per one DAI[1].
+   The first value defines the DAI type: TDA998x_SPDIF or TDA998x_I2S[2].
+   The second value defines the tda998x AP_ENA reg content when the DAI
+   in question is used. The implementation allows one or two DAIs. If two
+   DAIs are defined, they must be of different type.
+
+[1] Documentation/sound/alsa/soc/DAI.txt
+[2] include/dt-bindings/display/tda998x.h
+
 Example:

+#include 
+
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
@@ -30,4 +41,11 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
+   video-ports = <0x230145>;
+
+   #sound-dai-cells = <2>;
+/* DAI-format  AP_ENA reg value */
+   audio-ports = < TDA998x_SPDIF   0x04
+   TDA998x_I2S 0x03>;
+
};
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 22c7ed6..088f278 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -28,6 +28,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f97b748..9d37493 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -30,6 +31,11 @@

 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)

+struct tda998x_audio_port {
+   u8 format;  /* AFMT_xxx */
+   u8 config;  /* AP value */
+};
+
 struct tda998x_priv {
struct i2c_client *cec;
struct i2c_client *hdmi;
@@ -43,6 +49,8 @@ struct tda998x_priv {
u8 vip_cntrl_2;
struct tda998x_audio_params audio_params;

+   struct platform_device *audio_pdev;
+
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;

@@ -53,6 +61,8 @@ struct tda998x_priv {

struct drm_encoder encoder;
struct drm_connector connector;
+
+   struct tda998x_audio_port audio_port[2];
 };

 #define conn_to_tda998x_priv(x) \
@@ -743,7 +753,7 @@ tda998x_configure_audio(struct tda998x_priv *priv,
break;

default:
-   BUG();
+   dev_err(&priv->hdmi->dev, "Unsupported I2S format\n");
return -EINVAL;
}

@@ -1160,6 +1170,8 @@ static int tda998x_connector_get_modes(struct 
drm_connector *connector)
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+   drm_edid_to_eld(connector, edid);
+
kfree(edid);

return n;
@@ -1181,6 +1193,9 @@ static void tda998x_destroy(struct tda998x_priv *priv)
cec_write(priv, REG_CEC_R

[PATCH v9 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Jyri Sarha]

The hdmi-codec is a platform device driver to be registered from
drivers of external HDMI encoders with I2S and/or spdif interface. The
driver in turn registers an ASoC codec for the HDMI encoder's audio
functionality.

The structures and definitions in the API header are mostly redundant
copies of similar structures in ASoC headers. This is on purpose to
avoid direct dependencies to ASoC structures in video side driver.

Signed-off-by: Jyri Sarha 
---
 include/sound/hdmi-codec.h| 100 +++
 sound/soc/codecs/Kconfig  |   6 +
 sound/soc/codecs/Makefile |   2 +
 sound/soc/codecs/hdmi-codec.c | 396 ++
 4 files changed, 504 insertions(+)
 create mode 100644 include/sound/hdmi-codec.h
 create mode 100644 sound/soc/codecs/hdmi-codec.c

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
new file mode 100644
index 000..fc3a481
--- /dev/null
+++ b/include/sound/hdmi-codec.h
@@ -0,0 +1,100 @@
+/*
+ * hdmi-codec.h - HDMI Codec driver API
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#ifndef __HDMI_CODEC_H__
+#define __HDMI_CODEC_H__
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Protocol between ASoC cpu-dai and HDMI-encoder
+ */
+struct hdmi_codec_daifmt {
+   enum {
+   HDMI_I2S,
+   HDMI_RIGHT_J,
+   HDMI_LEFT_J,
+   HDMI_DSP_A,
+   HDMI_DSP_B,
+   HDMI_AC97,
+   HDMI_SPDIF,
+   } fmt;
+   int bit_clk_inv:1;
+   int frame_clk_inv:1;
+   int bit_clk_master:1;
+   int frame_clk_master:1;
+};
+
+/*
+ * HDMI audio parameters
+ */
+struct hdmi_codec_params {
+   struct hdmi_audio_infoframe cea;
+   struct snd_aes_iec958 iec;
+   int sample_rate;
+   int sample_width;
+   int channels;
+};
+
+struct hdmi_codec_ops {
+   /*
+* Called when ASoC starts an audio stream setup.
+* Optional
+*/
+   int (*audio_startup)(struct device *dev);
+
+   /*
+* Configures HDMI-encoder for audio stream.
+* Mandatory
+*/
+   int (*hw_params)(struct device *dev,
+struct hdmi_codec_daifmt *fmt,
+struct hdmi_codec_params *hparms);
+
+   /*
+* Shuts down the audio stream.
+* Mandatory
+*/
+   void (*audio_shutdown)(struct device *dev);
+
+   /*
+* Mute/unmute HDMI audio stream.
+* Optional
+*/
+   int (*digital_mute)(struct device *dev, bool enable);
+
+   /*
+* Provides EDID-Like-Data from connected HDMI device.
+* Optional
+*/
+   int (*get_eld)(struct device *dev, uint8_t *buf, size_t len);
+};
+
+/* HDMI codec initalization data */
+struct hdmi_codec_pdata {
+   const struct hdmi_codec_ops *ops;
+   uint i2s:1;
+   uint spdif:1;
+   int max_i2s_channels;
+};
+
+#define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
+
+#endif /* __HDMI_CODEC_H__ */
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 50693c8..62b62fe 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -86,6 +86,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_MC13783 if MFD_MC13XXX
select SND_SOC_ML26124 if I2C
select SND_SOC_NAU8825 if I2C
+   select SND_SOC_HDMI_CODEC
select SND_SOC_PCM1681 if I2C
select SND_SOC_PCM179X if SPI_MASTER
select SND_SOC_PCM3008
@@ -473,6 +474,11 @@ config SND_SOC_BT_SCO
 config SND_SOC_DMIC
tristate

+config SND_SOC_HDMI_CODEC
+   tristate
+   select SND_PCM_ELD
+   select SND_PCM_IEC958
+
 config SND_SOC_ES8328
tristate "Everest Semi ES8328 CODEC"

diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index d44f7d3..5f7b002 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -79,6 +79,7 @@ snd-soc-max9850-objs := max9850.o
 snd-soc-mc13783-objs := mc13783.o
 snd-soc-ml26124-objs := ml26124.o
 snd-soc-nau8825-objs := nau8825.o
+snd-soc-hdmi-codec-objs := hdmi-codec.o
 snd-soc-pcm1681-objs := pcm1681.o
 snd-soc-pcm179x-codec-objs := pcm179x.o
 snd-soc-pcm3008-objs := pcm3008.o
@@ -283,6 +284,7 @@ obj-$(CONFIG_SND_SOC_MAX9850)   += snd-soc-max9850.o
 obj-$(CONFIG_SND_SOC_MC13783)  += snd-soc-mc13783.o
 obj-$(CONFIG_SND_SOC_ML26124)  += snd-soc-ml26124.o
 obj-$(CONFIG_SND_SOC_NAU8825)   += snd-soc-nau8825.o
+obj-$(CONFIG_SND_SOC_HDMI_CODEC)   += snd-soc-hdmi-c

[PATCH v9 7/7] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jyri Sarha]

Add HDMI audio support. Adds mcasp0_pins, clk_mcasp0_fixed,
clk_mcasp0, mcasp0, sound node, and updates the tda19988 node to
follow the new binding.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 71 --
 1 file changed, 67 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 55c0e95..2bae4d1 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@

 #include "am33xx.dtsi"
 #include "am335x-bone-common.dtsi"
+#include 

 / {
model = "TI AM335x BeagleBone Black";
@@ -64,6 +65,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr0 */
>;
};
+
+   mcasp0_pins: mcasp0_pins {
+   pinctrl-single,pins = <
+   AM33XX_IOPAD(0x9ac, PIN_INPUT_PULLUP | MUX_MODE0) /* 
mcasp0_ahcklx.mcasp0_ahclkx */
+   AM33XX_IOPAD(0x99c, PIN_OUTPUT_PULLDOWN | MUX_MODE2) /* 
mcasp0_ahclkr.mcasp0_axr2*/
+   AM33XX_IOPAD(0x994, PIN_OUTPUT_PULLUP | MUX_MODE0) /* 
mcasp0_fsx.mcasp0_fsx */
+   AM33XX_IOPAD(0x990, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
mcasp0_aclkx.mcasp0_aclkx */
+   AM33XX_IOPAD(0x86c, PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* 
gpmc_a11.GPIO1_27 */
+   >;
+   };
 };

 &lcdc {
@@ -76,16 +87,22 @@
 };

 &i2c0 {
-   tda19988 {
+   tda19988: tda19988 {
compatible = "nxp,tda998x";
reg = <0x70>;
+
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;

-   port {
-   hdmi_0: endpoint at 0 {
-   remote-endpoint = <&lcdc_0>;
+   #sound-dai-cells = <0>;
+   audio-ports = < AFMT_I2S0x03>;
+
+   ports {
+   port at 0 {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <&lcdc_0>;
+   };
};
};
};
@@ -94,3 +111,49 @@
 &rtc {
system-power-controller;
 };
+
+&mcasp0{
+   #sound-dai-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&mcasp0_pins>;
+   status = "okay";
+   op-mode = <0>;  /* MCASP_IIS_MODE */
+   tdm-slots = <2>;
+   serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 1 0
+   >;
+   tx-num-evt = <32>;
+   rx-num-evt = <32>;
+};
+
+/ {
+   clk_mcasp0_fixed: clk_mcasp0_fixed {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <24576000>;
+   };
+
+   clk_mcasp0: clk_mcasp0 {
+   #clock-cells = <0>;
+   compatible = "gpio-gate-clock";
+   clocks = <&clk_mcasp0_fixed>;
+   enable-gpios = <&gpio1 27 0>; /* BeagleBone Black Clk enable on 
GPIO1_27 */
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "TI BeagleBone Black";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,bitclock-master = <&dailink0_master>;
+   simple-audio-card,frame-master = <&dailink0_master>;
+
+   dailink0_master: simple-audio-card,cpu {
+   sound-dai = <&mcasp0>;
+   clocks = <&clk_mcasp0>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <&tda19988>;
+   };
+   };
+};
-- 
1.9.1

[PATCH v9 1/7] ALSA: pcm: add IEC958 channel status helper for hw_params

[Takashi Iwai]

On Thu, 31 Mar 2016 15:35:58 +0200,
Jyri Sarha wrote:
> 
> Add IEC958 channel status helper that gets the audio properties from
> snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> produce the channel status bits already in audio stream configuration
> phase.
> 
> Signed-off-by: Jyri Sarha 

Reviewed-by: Takashi Iwai 


Takashi

[PATCH v9 2/7] ALSA: pcm: Allow 32 bit sample format in IEC958 channel status helper

[Takashi Iwai]

On Thu, 31 Mar 2016 15:35:59 +0200,
Jyri Sarha wrote:
> 
> Treat 32 bit sample width as if it was 24 bits when generating IEC958
> channel status bits. On some platforms 24 sample width is problematic
> and to get full 24 bit precision a 32 bit format, using only the 24
> most significant bits, may have to be used.
> 
> Signed-off-by: Jyri Sarha 

Reviewed-by: Takashi Iwai 


Takashi

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

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

 !
Mar 29 19:38:58 xubuntu-beta kernel: [16940.103692] radeon :01:00.0: Wait
for MC idle timedout !
Mar 29 19:38:58 xubuntu-beta kernel: [16940.106141] [drm] PCIE GART of 1024M
enabled (table at 0x00274000).
Mar 29 19:38:58 xubuntu-beta kernel: [16940.106235] radeon :01:00.0: WB
enabled
Mar 29 19:38:58 xubuntu-beta kernel: [16940.106238] radeon :01:00.0: fence
driver on ring 0 use gpu addr 0x4c00 and cpu addr
0x880035a44c00
Mar 29 19:38:58 xubuntu-beta kernel: [16940.106240] radeon :01:00.0: fence
driver on ring 3 use gpu addr 0x4c0c and cpu addr
0x880035a44c0c
Mar 29 19:38:58 xubuntu-beta kernel: [16940.107690] radeon :01:00.0: fence
driver on ring 5 use gpu addr 0x00072118 and cpu addr
0xc90001832118
Mar 29 19:38:58 xubuntu-beta kernel: [16940.339852] [drm:r600_ring_test
[radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
Mar 29 19:38:58 xubuntu-beta kernel: [16940.339884] [drm:evergreen_resume
[radeon]] *ERROR* evergreen startup failed on resume
Mar 29 19:39:08 xubuntu-beta kernel: [16950.200641] radeon :01:00.0: ring 0
stalled for more than 10080msec
Mar 29 19:39:08 xubuntu-beta kernel: [16950.200655] radeon :01:00.0: GPU
lockup (current fence id 0x00254b78 last fence id 0x00254b82 on
ring 0)
Mar 29 19:39:09 xubuntu-beta kernel: [16950.700615] radeon :01:00.0: ring 0
stalled for more than 10580msec

I will post my kern.log so u could use it. Don't try to open in anything but
cat.

-- 
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/20160331/467d5254/attachment-0001.html>

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

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

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

Vladislav Kamenev  changed:

   What|Removed |Added

 Attachment #122639|0   |1
is obsolete||

--- Comment #31 from Vladislav Kamenev  ---
Created attachment 122647
  --> https://bugs.freedesktop.org/attachment.cgi?id=122647&action=edit
Binary kernel log on freeze.

Don't use anything but cat to watch it.
I copied some string on my last comment.

-- 
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/20160331/58fe8fcd/attachment.html>

DRMJanitors

[Daniel Vetter]

Welcome Rob!

On Thu, Mar 31, 2016 at 3:35 PM, Robert Foss  wrote:
> Hey,
>
> I'm new to DRM development, but was thinking about getting into the shallow
> side of pool, and doing some DRMJanitors development.
>
> Do you have a preference for a task for me to look at? Is there one that
> would be particularly easy to get started with?

Say hi on #dri-devel irc channel on irc and just jump in. Ime doing
something that's somewhat relevant to yourself (driver for hw you're
using or similar) is good for the motivation. And if you want to
test-drive the patch submission process you can also do a simple
cleanup patch first (coding style or similar work like for
drivers/staging) and submit it.

Also, please include always mailing lists, maybe someone else is
interested or has ideas. I added them.

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

[PATCH libdrm] tegra: Sync with Linux kernel UAPI header

[Daniel Vetter]

On Thu, Mar 31, 2016 at 12:41:10PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Update the UAPI header to the latest version in the Linux kernel. This
> changes the struct drm_tegra_gem_mmap to properly handle offsets on 64-
> bit architectures.
> 
> See commit bdf765071a8b ("drm/tegra: gem: Return 64-bit offset for
> mmap(2)") in the Linux kernel (as of v4.1).
> 
> Signed-off-by: Thierry Reding 

/me remembers that discussion again ...

Reviewed-by: Daniel Vetter 
> ---
>  include/drm/tegra_drm.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
> index 8dae8f334992..7c0fe0ed511b 100644
> --- a/include/drm/tegra_drm.h
> +++ b/include/drm/tegra_drm.h
> @@ -36,7 +36,8 @@ struct drm_tegra_gem_create {
>  
>  struct drm_tegra_gem_mmap {
>   __u32 handle;
> - __u32 offset;
> + __u32 pad;
> + __u64 offset;
>  };
>  
>  struct drm_tegra_syncpt_read {
> -- 
> 2.7.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[RFC 0/6] drm/fences: add in-fences to DRM

[Rob Clark]

On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae  wrote:
> Hi Daniel,
>
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> Hi Inki,
>>
>> On 31 March 2016 at 11:05, Inki Dae  wrote:
>>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
 On 31 March 2016 at 08:45, Inki Dae  wrote:
> As of now, it seems that this wouldn't be optional but mandatory if 
> explicit fence support is added to the atomic helper framework. This 
> would definitely be duplication and it seems not clear enough even if one 
> of them is just skipped in runtime.

 Drivers would have to opt in to explicit fencing support, and part of
 that would be ensuring that the driver does not wait on implicit
 fences when the user has requested explicit fencing be used.

>>>
>>> Then, existing drivers would need additional works for explicit fencing 
>>> support. This wouldn't be really what the drivers have to but should be 
>>> handled with this patch series because this would affect exising device 
>>> drivers which use implicit fencing.
>>
>> Well, yes. Anyone implementing their own atomic commit would need to
>> ensure that the commit works properly for fences. The helpers could
>> also add it, but the helpers are not mandatory, and you are not
>> required to use every part of the helper to use one part of the
>> helper. There is no magic wand you can wave that instantly makes it
>> work for every driver
>
> I meant there are already several DRM drivers which work properly for
> implicit fence. So if atomic helper framework of DRM core is
> considered only for the explicit fence, then fencing operation would
> affect the existing DRM drivers. So I hope this trying could consider
> existing implicit fence users.
>

Note that there would be a new flag on the atomic ioctl to request
explicit fencing, and with an old kernel or a driver that does not
support it, the ioctl would be rejected and an error returned.  The
atomic/kms framework would of course continue to support implicit
fencing.   And an explicit-fencing userspace would require a
sufficiently new kernel and possibly some minor driver support (above
and beyond 'struct fence' conversion).

BR,
-R

[PATCH v2 6/8] drm/fsl-dcu: add TCON driver

[Rob Herring]

On Mon, Mar 28, 2016 at 07:00:00PM -0700, Stefan Agner wrote:
> Add driver for the TCON (timing controller) module. The TCON module
> is a separate module attached after the DCU (display controller
> unit). Each DCU instance has its own, directly connected TCON
> instance. The DCU's RGB and timing signals are passing through
> the TCON module. TCON can provide timing signals for raw TFT panels
> or operate in a bypass mode which leaves all signals unaltered.
> 
> The driver currently only supports the bypass mode.
> 
> Signed-off-by: Stefan Agner 
> ---
>  .../devicetree/bindings/display/fsl,dcu.txt|   2 +
>  .../devicetree/bindings/display/fsl,tcon.txt   |  18 
>  drivers/gpu/drm/fsl-dcu/Makefile   |   3 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c  |   3 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  |   1 +
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  |  11 +++
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 108 
> +
>  drivers/gpu/drm/fsl-dcu/fsl_tcon.h |  33 +++
>  8 files changed, 178 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/display/fsl,tcon.txt
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.c
>  create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_tcon.h
> 
> diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt 
> b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> index f299e1e..b19bf12 100644
> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> @@ -14,6 +14,7 @@ Required properties:
>  Optional properties:
>  - clocks:Second handle for pixel clock.
>  - clock-names:   Second name "pix" for pixel clock.
> +- fsl,tcon:  The phandle to the timing controller node.
>  
>  Examples:
>  dcu: dcu at 2ce {
> @@ -23,4 +24,5 @@ dcu: dcu at 2ce {
>   clock-names = "dcu";
>   big-endian;
>   fsl,panel = <&panel>;
> + fsl,tcon = <&tcon>;
>  };
> diff --git a/Documentation/devicetree/bindings/display/fsl,tcon.txt 
> b/Documentation/devicetree/bindings/display/fsl,tcon.txt
> new file mode 100644
> index 000..2e1015e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/fsl,tcon.txt
> @@ -0,0 +1,18 @@
> +Device Tree bindings for Freescale TCON Driver
> +
> +Required properties:
> +- compatible:Should be one of
> + * "fsl,vf610-tcon".
> +
> +- reg:   Address and length of the register set for dcu.

s/dcu/tcon/

With that,

Acked-by: Rob Herring 


> +- clocks:From common clock binding: handle to tcon ipg clock.
> +- clock-names:   From common clock binding: Shall be "ipg".
> +
> +Examples:
> +timing-controller at 4003d000 {
> + compatible = "fsl,vf610-tcon";
> + reg = <0x4003d000 0x1000>;
> + clocks = <&clks VF610_CLK_TCON0>;
> + clock-names = "ipg";
> + status = "okay";
> +};

[PATCH v2 4/8] drm/fsl-dcu: add extra clock for pixel clock

[Rob Herring]

On Mon, Mar 28, 2016 at 06:59:58PM -0700, Stefan Agner wrote:
> The Vybrid DCU variant has two independent clock inputs, one
> for the registers (IPG bus clock) and one for the pixel clock.
> Support this distinction in the DCU DRM driver while staying
> backward compatible with devices providing only a single clock
> (e.g. LS1021a SoC's).

I'd suspect that both have 2 clocks, just the LS1021a either didn't 
model the IPG clock or connects both to the same source. The driver 
should support both, but all the dts's should be updated to have 2 
clocks.

> 
> Signed-off-by: Stefan Agner 
> ---
>  Documentation/devicetree/bindings/display/fsl,dcu.txt |  4 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c|  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 16 +++-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 +
>  4 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt 
> b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> index ebf1be9..f299e1e 100644
> --- a/Documentation/devicetree/bindings/display/fsl,dcu.txt
> +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt
> @@ -11,6 +11,10 @@ Required properties:
>  - big-endian Boolean property, LS1021A DCU registers are big-endian.
>  - fsl,panel: The phandle to panel node.
>  
> +Optional properties:
> +- clocks:Second handle for pixel clock.
> +- clock-names:   Second name "pix" for pixel clock.

Document these in one place and just add a note that LS1021a only has 1 
clock.

> +
>  Examples:
>  dcu: dcu at 2ce {
>   compatible = "fsl,ls1021a-dcu";
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c

[Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

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

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

--- Comment #8 from Kamil P�ral  ---
Would somebody care to contact the game developers and describe the issue in
detail? And if you did, do you have a link (to a forum topic, public bug
report, etc)? 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/20160331/fafa5f99/attachment.html>

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

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

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

--- Comment #8 from Andy Furniss  ---
Fixing commit = 

commit d3adac51fcce66e8c79b77299fef9e5f6c4c646e
Author: Tom Stellard 
Date:   Wed Mar 30 16:35:09 2016 +

AMDGPU/SI: Enable lanemask tracking in misched

Summary:
This results in higher register usage, but should make it easier for
the compiler to hide latency.

This pass is a prerequisite for some more scheduler improvements, and I
think the increase register usage with this patch is acceptable, because
when combined with the scheduler improvements, the total register usage
will decrease.

shader-db stats:

2382 shaders in 478 tests
Totals:
SGPRS: 48672 -> 49088 (0.85 %)
VGPRS: 34148 -> 34847 (2.05 %)
Code Size: 1285816 -> 1289128 (0.26 %) bytes
LDS: 28 -> 28 (0.00 %) blocks
Scratch: 492544 -> 573440 (16.42 %) bytes per wave
Max Waves: 6856 -> 6846 (-0.15 %)
Wait states: 0 -> 0 (0.00 %)

Depends on D18451

Reviewers: nhaehnle, arsenm

Subscribers: arsenm, llvm-commits

Differential Revision: http://reviews.llvm.org/D18452

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 264876
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
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/20160331/6a8ddfd7/attachment.html>

[Bug 94012] Tonga OpenCL clpeak vm faults

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

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #2 from Andy Furniss  ---
fixed by llvm commit

commit d3adac51fcce66e8c79b77299fef9e5f6c4c646e
Author: Tom Stellard 
Date:   Wed Mar 30 16:35:09 2016 +

AMDGPU/SI: Enable lanemask tracking in misched

Summary:
This results in higher register usage, but should make it easier for
the compiler to hide latency.

This pass is a prerequisite for some more scheduler improvements, and I
think the increase register usage with this patch is acceptable, because
when combined with the scheduler improvements, the total register usage
will decrease.

shader-db stats:

2382 shaders in 478 tests
Totals:
SGPRS: 48672 -> 49088 (0.85 %)
VGPRS: 34148 -> 34847 (2.05 %)
Code Size: 1285816 -> 1289128 (0.26 %) bytes
LDS: 28 -> 28 (0.00 %) blocks
Scratch: 492544 -> 573440 (16.42 %) bytes per wave
Max Waves: 6856 -> 6846 (-0.15 %)
Wait states: 0 -> 0 (0.00 %)

Depends on D18451

Reviewers: nhaehnle, arsenm

Subscribers: arsenm, llvm-commits

Differential Revision: http://reviews.llvm.org/D18452

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 264876
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
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/20160331/d8a1c3fc/attachment.html>

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

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

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

--- Comment #9 from Andy Furniss  ---
Leaving open to see if other peoples test cases are also fixed.

Or maybe the "fixing" commit is just hiding some other issue?

-- 
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/20160331/89d14f4f/attachment.html>

[Bug 93551] Divinity: Original Sin Enhanced Edition(Native) crash on start

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

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

--- Comment #9 from smidjar2.reg at email.cz ---
(In reply to Kamil P�ral from comment #8)
> Would somebody care to contact the game developers and describe the issue in
> detail? And if you did, do you have a link (to a forum topic, public bug
> report, etc)? Thanks.

I posted it as a reply to nouveau issue topic in forum. Maybe someone will pick
it up there.

http://larian.com/forums/ubbthreads.php?ubb=showflat&Number=580880&#Post580880

-- 
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/20160331/a846b2b5/attachment.html>

[PATCH 2/2] drm/amdgpu: Set vblank_disable_allowed = true

[Alex Deucher]

On Thu, Mar 31, 2016 at 2:46 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Without this, since the conversion from drm_vblank_pre/post_modeset to
> drm_vblank_on/off, the vblank interrupt could never be disabled after
> userspace triggered enabling it.
>
> Signed-off-by: Michel Dänzer 

Applied the series.

Thanks,

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index f594cfa..762cfdb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -219,6 +219,8 @@ int amdgpu_irq_init(struct amdgpu_device *adev)
> if (r) {
> return r;
> }
> +   adev->ddev->vblank_disable_allowed = true;
> +
> /* enable msi */
> adev->irq.msi_enabled = false;
>
> --
> 2.8.0.rc3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] dma-buf: Release module reference on creation failure

[Joonas Lahtinen]

On to, 2016-03-31 at 09:35 +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> Cc: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> ---
>  drivers/dma-buf/dma-buf.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4a2c07ee6677..6f0f0b10a241 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -333,6 +333,7 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  struct reservation_object *resv = exp_info->resv;
>  struct file *file;
>  size_t alloc_size = sizeof(struct dma_buf);
> + int ret;
>  
>  if (!exp_info->resv)
>  alloc_size += sizeof(struct reservation_object);
> @@ -356,8 +357,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  
>  dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>  if (!dmabuf) {
> - module_put(exp_info->owner);
> - return ERR_PTR(-ENOMEM);
> + ret = -ENOMEM;
> + goto free_module;
>  }
>  
>  dmabuf->priv = exp_info->priv;
> @@ -378,8 +379,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf,
>  exp_info->flags);
>  if (IS_ERR(file)) {
> - kfree(dmabuf);
> - return ERR_CAST(file);
> + ret = PTR_ERR(file);
> + goto free_dmabuf;
>  }
>  
>  file->f_mode |= FMODE_LSEEK;
> @@ -393,6 +394,12 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
>  mutex_unlock(&db_list.lock);
>  
>  return dmabuf;
> +
> +free_dmabuf:
> + kfree(dmabuf);
> +free_module:
> + module_put(exp_info->owner);
> + return ERR_PTR(ret);

Labels could really be err_dmabuf (/ out_dmabuf). That's more in line
with rest of the codebase and kernel coding style: 'An example of a
good name could be "out_buffer:" if the goto frees "buffer".'

"free_dmabuf" does sound to me like it could also be executed on the
normal execution path of the function.

Other than that,

Reviewed-by: Joonas Lahtinen 

>  }
>  EXPORT_SYMBOL_GPL(dma_buf_export);
>  
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

[Bug 94445] Tonga llvm assert since RegisterCoalescer: Need to check DstReg+SrcReg for missing undef flags

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

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

--- Comment #10 from Vedran Miletić  ---
(In reply to Andy Furniss from comment #7)
> Working for me with current llvm/mesa.

Same here, tested on Kabini and Bonaire.

-- 
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/20160331/64d1dfdd/attachment.html>

[PATCH 2/3 v2] ASoC: dwc: Add I2S HDMI audio support

[Mark Brown]

On Thu, Mar 31, 2016 at 10:37:20AM +0100, Jose Abreu wrote:
> On 29-03-2016 19:22, Mark Brown wrote:

> > If you want to add a new platform driver you need to add a new platform
> > driver, not shove the code into an existing driver for a seperate IP.

> I can separate the platform driver into a new file but they will have to be
> compiled into the same module as the new additions to the i2s driver depend on
> functions of the platform driver (see i2s_irq_handler()). Or should I divide

No, that's not at all acceptable.  The Designware IP is not specific to
your system, you can't make it depend on your platform driver.  The
kernel needs to work on other people's systems too.  You need to work
through and/or extend the abstractions the framework provides to
separate the drivers for different IPs.

> this into two modules and add a Kconfig option to the platform driver? Besides
> this I first wanted the driver to be compiled into the same module so that it 
> is
> compatible with kernel 3.18 where simple audio card requires that platform
> driver == cpu driver.

That's not OK upstream, we're working on the current kernel not on
random old kernels.  We don't carry compatibility code to enable current
kernel code to be run on years old kernels.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160331/22fcdcbc/attachment.sig>

[PATCH 1/4] gpu: ipu-v3: ipu-dmfc: Protect function ipu_dmfc_init_channel() with mutex

[Philipp Zabel]

Hi Liu,

Am Montag, den 14.03.2016, 16:10 +0800 schrieb Liu Ying:
> To avoid race condition issue, we should protect the function
> ipu_dmfc_init_channel() with the mutex dmfc->priv->mutex, since it
> configures the register DMFC_GENERAL1 at runtime which contains
> several control bits for various display channels.  This matches
> better with fine grained locking logic in upper layer.

Applied all four patches, thank you.

regards
Philipp

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #91 from Orlando Nigro  ---
it didn't work :(. I downloaded the firmware (the k one) changed the name and
replaced the old one. I reboot and without change the DPM value it freezes
after a while. 
Now I'm back using the echo-command when I login and it's the only way to make
the GPU work. Do I maybe have to do more after replacing the file? Run some
command?

-- 
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/20160331/2bcee43d/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #92 from Alex Deucher  ---
(In reply to Orlando Nigro from comment #91)
> it didn't work :(. I downloaded the firmware (the k one) changed the name
> and replaced the old one. I reboot and without change the DPM value it
> freezes after a while. 
> Now I'm back using the echo-command when I login and it's the only way to
> make the GPU work. Do I maybe have to do more after replacing the file? Run
> some command?

If you are using an initrd, you'll need to update the copy of the firmware in
your initrd.

-- 
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/20160331/177b38a7/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #93 from Christoffer  ---
(In reply to Orlando Nigro from comment #91)
> it didn't work :(. I downloaded the firmware (the k one) changed the name
> and replaced the old one. I reboot and without change the DPM value it
> freezes after a while. 
> Now I'm back using the echo-command when I login and it's the only way to
> make the GPU work. Do I maybe have to do more after replacing the file? Run
> some command?

I think only MSI 390X and XFX 390 users confirmed that hawaii_k_smc.bin works
for them. I also own R9 390 from MSI and it does not work for me either. Tried
in both Arch and Fedora, with updated initrd.

@Alex, is the firmware in radeon_ucode/k/ folder the same that was just updated
in the linux-firmware git tree?
http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=6e767c2b85c62fb7325fdc00f51b90f6747c13ab

-- 
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/20160331/7092a6bf/attachment-0001.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #94 from Alex Deucher  ---
(In reply to Christoffer from comment #93)
> @Alex, is the firmware in radeon_ucode/k/ folder the same that was just
> updated in the linux-firmware git tree?
> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
> commit/?id=6e767c2b85c62fb7325fdc00f51b90f6747c13ab

No, they are different.

-- 
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/20160331/c5b5fcc5/attachment.html>

[Bug 107001] Radeon HDMI audio lost after resuming from suspend

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

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

--- Comment #2 from Timo Valtoaho  ---
git bisected this to d57c0edfe00d3274b50f91ce3076ed0e82d28782.

Reverting this solves the problem, at least with 4.5.0 in which I'm testing the
revert.

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

[PATCH 01/11] reservation: add reservation_object_get_excl_unlocked()

[Rob Clark]

In the atomic modesetting path, each driver simply wants to grab a ref
to the exclusive fence from a reservation object to store in the incoming
drm_plane_state, without doing the whole RCU dance.  Since each driver
will need to do this, lets make a helper.

v2: rename to _rcu instead of _unlocked to be more consistent

Signed-off-by: Rob Clark 
---
Note that danvet also suggested addition of headerdoc.  But it was a
trap!  In the process I discovered that some files were missing from
the DocBook tmpl, some fixup needed, and complete lack of reservation
related headerdoc.

So the patchset to fixup all that will follow in a few minutes.  But
danvet's punishment for tricking me into fixing that all up is that
the headerdoc he wants applies on top of the patch that I want ;-)

 include/linux/reservation.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 5a0b64c..49d0576 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -120,6 +120,24 @@ reservation_object_get_excl(struct reservation_object *obj)
 reservation_object_held(obj));
 }

+static inline struct fence *
+reservation_object_get_excl_rcu(struct reservation_object *obj)
+{
+   struct fence *fence;
+   unsigned seq;
+retry:
+   seq = read_seqcount_begin(&obj->seq);
+   rcu_read_lock();
+   fence = rcu_dereference(obj->fence_excl);
+   if (read_seqcount_retry(&obj->seq, seq)) {
+   rcu_read_unlock();
+   goto retry;
+   }
+   fence = fence_get(fence);
+   rcu_read_unlock();
+   return fence;
+}
+
 int reservation_object_reserve_shared(struct reservation_object *obj);
 void reservation_object_add_shared_fence(struct reservation_object *obj,
 struct fence *fence);
-- 
2.5.5

[PATCH 0/4] dma-buf/reservation doc updates

[Rob Clark]

Some dma-buf headerdoc fixes (turns out dma-buf.h wasn't getting pulled
into doc build), add reservation headerdoc, and fixup a bit the section
in device-drivers.tmpl.

Rob Clark (4):
  reservation: sprinkle some WARN_ON()s
  dma-buf: headerdoc fixes
  reservation: add headerdoc comments
  doc: update/fixup dma-buf related DocBook

 Documentation/DocBook/device-drivers.tmpl | 36 --
 drivers/dma-buf/reservation.c | 78 +--
 include/linux/dma-buf.h   | 13 --
 include/linux/reservation.h   | 53 +
 4 files changed, 169 insertions(+), 11 deletions(-)

-- 
2.5.5

[PATCH 3/4] reservation: add headerdoc comments

[Rob Clark]

Signed-off-by: Rob Clark 
---
 drivers/dma-buf/reservation.c | 72 ---
 include/linux/reservation.h   | 53 +++
 2 files changed, 121 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 0de3ea6..0d18952 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -35,6 +35,17 @@
 #include 
 #include 

+/**
+ * DOC: Reservation Object Overview
+ *
+ * The reservation object provides a mechanism to manage shared and
+ * exclusive fences associated with a buffer.  A reservation object
+ * can have attached one exclusive fence (normally associated with
+ * write operations) or N shared fences (read operations).  The RCU
+ * mechanism is used to protect read access to fences from locked
+ * write-side updates.
+ */
+
 DEFINE_WW_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);

@@ -43,9 +54,17 @@ EXPORT_SYMBOL(reservation_seqcount_class);

 const char reservation_seqcount_string[] = "reservation_seqcount";
 EXPORT_SYMBOL(reservation_seqcount_string);
-/*
- * Reserve space to add a shared fence to a reservation_object,
- * must be called with obj->lock held.
+
+/**
+ * reservation_object_reserve_shared - Reserve space to add a shared
+ * fence to a reservation_object.
+ * @obj: reservation object
+ *
+ * Should be called before reservation_object_add_shared_fence().  Must
+ * be called with obj->lock held.
+ *
+ * RETURNS
+ * Zero for success, or -errno
  */
 int reservation_object_reserve_shared(struct reservation_object *obj)
 {
@@ -182,7 +201,11 @@ done:
fence_put(old_fence);
 }

-/*
+/**
+ * reservation_object_add_shared_fence - Add a fence to a shared slot
+ * @obj: the reservation object
+ * @fence: the shared fence to add
+ *
  * Add a fence to a shared slot, obj->lock must be held, and
  * reservation_object_reserve_shared_fence has been called.
  */
@@ -204,6 +227,13 @@ void reservation_object_add_shared_fence(struct 
reservation_object *obj,
 }
 EXPORT_SYMBOL(reservation_object_add_shared_fence);

+/**
+ * reservation_object_add_excl_fence - Add an exclusive fence.
+ * @obj: the reservation object
+ * @fence: the shared fence to add
+ *
+ * Add a fence to the exclusive slot.  The obj->lock must be held.
+ */
 void reservation_object_add_excl_fence(struct reservation_object *obj,
   struct fence *fence)
 {
@@ -239,6 +269,18 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
 }
 EXPORT_SYMBOL(reservation_object_add_excl_fence);

+/**
+ * reservation_object_get_fences_rcu - Get an object's shared and exclusive
+ * fences without update side lock held
+ * @obj: the reservation object
+ * @pfence_excl: the returned exclusive fence (or NULL)
+ * @pshared_count: the number of shared fences returned
+ * @pshared: the array of shared fence ptrs returned (array is krealloc'd to
+ * the required size, and must be freed by caller)
+ *
+ * RETURNS
+ * Zero or -errno
+ */
 int reservation_object_get_fences_rcu(struct reservation_object *obj,
  struct fence **pfence_excl,
  unsigned *pshared_count,
@@ -325,6 +367,18 @@ unlock:
 }
 EXPORT_SYMBOL_GPL(reservation_object_get_fences_rcu);

+/**
+ * reservation_object_wait_timeout_rcu - Wait on reservation's objects
+ * shared and/or exclusive fences.
+ * @obj: the reservation object
+ * @wait_all: if true, wait on all fences, else wait on just exclusive fence
+ * @intr: if true, do interruptible wait
+ * @timeout: timeout value in jiffies or zero to return immediately
+ *
+ * RETURNS
+ * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or
+ * greater than zer on success.
+ */
 long reservation_object_wait_timeout_rcu(struct reservation_object *obj,
 bool wait_all, bool intr,
 unsigned long timeout)
@@ -422,6 +476,16 @@ reservation_object_test_signaled_single(struct fence 
*passed_fence)
return ret;
 }

+/**
+ * reservation_object_test_signaled_rcu - Test if a reservation object's
+ * fences have been signaled.
+ * @obj: the reservation object
+ * @test_all: if true, test all fences, otherwise only test the exclusive
+ * fence
+ *
+ * RETURNS
+ * true if all fences signaled, else false
+ */
 bool reservation_object_test_signaled_rcu(struct reservation_object *obj,
  bool test_all)
 {
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 49d0576..b0f305e 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -49,12 +49,27 @@ extern struct ww_class reservation_ww_class;
 extern struct lock_class_key reservation_seqcount_class;
 extern const char reservation_seqcount_string[];

+/**
+ * struct reservation_object_list - a list of shared fences
+ * @rcu: for internal use
+ * @shared_count

[PATCH 4/4] doc: update/fixup dma-buf related DocBook

[Rob Clark]

Split out dma-buf related parts into their own section, add missing
files, and write a bit of overview about how it all fits together.

Signed-off-by: Rob Clark 
---
 Documentation/DocBook/device-drivers.tmpl | 36 +++
 1 file changed, 32 insertions(+), 4 deletions(-)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index cdd8b24..9c41af9 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,14 +128,42 @@ X!Edrivers/base/interface.c
 !Edrivers/base/platform.c
 !Edrivers/base/bus.c
  
- Device Drivers DMA Management
+ 
+   Buffer Sharing and Synchronization
+   
+ The dma-buf subsystem provides the framework for sharing buffers
+ for hardware (DMA) access across multiple device drivers and
+ subsystems, and for synchronizing asynchronous hardware access.
+   
+   
+ This is used, for example, by drm "prime" multi-GPU support, but
+ is of course not limited to GPU use cases.
+   
+   
+ The three main components of this are: (1) dma-buf, representing
+ a sg_table and exposed to userspace as a file descriptor to allow
+ passing between devices, (2) fence, which provides a mechanism
+ to signal when one device as finished access, and (3) reservation,
+ which manages the shared or exclusive fence(s) associated with
+ the buffer.
+   
+   dma-buf
 !Edrivers/dma-buf/dma-buf.c
+!Iinclude/linux/dma-buf.h
+   
+   reservation
+!Pdrivers/dma-buf/reservation.c Reservation Object Overview
+!Edrivers/dma-buf/reservation.c
+!Iinclude/linux/reservation.h
+   
+   fence
 !Edrivers/dma-buf/fence.c
-!Edrivers/dma-buf/seqno-fence.c
 !Iinclude/linux/fence.h
+!Edrivers/dma-buf/seqno-fence.c
 !Iinclude/linux/seqno-fence.h
-!Edrivers/dma-buf/reservation.c
-!Iinclude/linux/reservation.h
+   
+ 
+ Device Drivers DMA Management
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
  
-- 
2.5.5

[PATCH 1/4] reservation: sprinkle some WARN_ON()s

[Rob Clark]

A bit overkill since, for example, the rcu_dereference_protected() in
reservation_object_get_list() will WARN.  But this is much less subtle
for folks reading the code.

Signed-off-by: Rob Clark 
---
 drivers/dma-buf/reservation.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index c0bd572..0de3ea6 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -52,6 +52,8 @@ int reservation_object_reserve_shared(struct 
reservation_object *obj)
struct reservation_object_list *fobj, *old;
u32 max;

+   WARN_ON(!ww_mutex_is_locked(&obj->lock));
+
old = reservation_object_get_list(obj);

if (old && old->shared_max) {
@@ -189,6 +191,8 @@ void reservation_object_add_shared_fence(struct 
reservation_object *obj,
 {
struct reservation_object_list *old, *fobj = obj->staged;

+   WARN_ON(!ww_mutex_is_locked(&obj->lock));
+
old = reservation_object_get_list(obj);
obj->staged = NULL;

@@ -207,6 +211,8 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
struct reservation_object_list *old;
u32 i = 0;

+   WARN_ON(!ww_mutex_is_locked(&obj->lock));
+
old = reservation_object_get_list(obj);
if (old)
i = old->shared_count;
-- 
2.5.5

[PATCH 2/4] dma-buf: headerdoc fixes

[Rob Clark]

Apparently nobody noticed that dma-buf.h wasn't actually pulled into
docbook build.  And as a result the headerdoc comments bitrot a bit.
Add missing params/fields.

Signed-off-by: Rob Clark 
---
 include/linux/dma-buf.h | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index f98bd70..6befeed 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -114,19 +114,24 @@ struct dma_buf_ops {
  * @file: file pointer used for sharing buffers across, and for refcounting.
  * @attachments: list of dma_buf_attachment that denotes all devices attached.
  * @ops: dma_buf_ops associated with this buffer object.
+ * @lock: used internally to serialize list manipulation, attach/detach and 
vmap/unmap
+ * @vmapping_counter: used internally to refcnt the vmaps
+ * @vmap_ptr: the current vmap ptr if vmapping_counter > 0
  * @exp_name: name of the exporter; useful for debugging.
  * @owner: pointer to exporter module; used for refcounting when exporter is a
  * kernel module.
  * @list_node: node for dma_buf accounting and debugging.
  * @priv: exporter specific private data for this buffer object.
  * @resv: reservation object linked to this dma-buf
+ * @poll: for userspace poll support
+ * @cb_excl: for userspace poll support
+ * @cb_shared: for userspace poll support
  */
 struct dma_buf {
size_t size;
struct file *file;
struct list_head attachments;
const struct dma_buf_ops *ops;
-   /* mutex to serialize list manipulation, attach/detach and vmap/unmap */
struct mutex lock;
unsigned vmapping_counter;
void *vmap_ptr;
@@ -190,9 +195,11 @@ struct dma_buf_export_info {

 /**
  * helper macro for exporters; zeros and fills in most common values
+ *
+ * @name: export-info name
  */
-#define DEFINE_DMA_BUF_EXPORT_INFO(a)  \
-   struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+#define DEFINE_DMA_BUF_EXPORT_INFO(name)   \
+   struct dma_buf_export_info name = { .exp_name = KBUILD_MODNAME, \
 .owner = THIS_MODULE }

 /**
-- 
2.5.5

[Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

[Ville Syrjälä]

On Thu, Mar 31, 2016 at 07:25:36PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-02-23 às 18:46 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > Add a helper which aids in he identification of DP dual mode (aka.
> > DP++)
> > adaptors. There are several types of adaptors specified:
> > type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
> > 
> > Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2
> > adaptors
> > may go as high as 300MHz and they provide a register informing the
> > source device what the actual limit is. Supposedly also type 1
> > adaptors
> > may optionally implement this register. This TMDS clock limit is the
> > main reason why we need to identify these adaptors.
> > 
> > Type 1 adaptors provide access to their internal registers and the
> > sink
> > DDC bus through I2C. Type 2 adaptors provide this access both via I2C
> > and I2C-over-AUX. A type 2 source device may choose to implement
> > either
> > or both of these methods. If a source device implements only the
> > I2C-over-AUX method, then the driver will obviously need specific
> > support for such adaptors since the port is driven like an HDMI port,
> > but DDC communication happes over the AUX channel.
> > 
> > This helper should be enough to identify the adaptor type (some
> > type 1 DVI adaptors may be a slight exception) and the maximum TMDS
> > clock limit. Another feature that may be available is control over
> > the TMDS output buffers on the adaptor, possibly allowing for some
> > power saving when the TMDS link is down.
> > 
> > Other user controllable features that may be available in the
> > adaptors
> > are downstream i2c bus speed control when using i2c-over-aux, and
> > some control over the CEC pin. I chose not to provide any helper
> > functions for those since I have no use for them in i915 at this
> > time.
> > The rest of the registers in the adaptor are mostly just information,
> > eg. IEEE OUI, hardware and firmware revision, etc.
> 
> Please run a spell checker and do some proof-reading both in the commit
> message and in the code comments. Multiple instances of "sizo",
> "Hoever", "adator", "Identyfy", etc. I also spotted some typos in the
> next commits.
> 
> 
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/Makefile                  |   2 +-
> >  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328
> > ++
> >  include/drm/drm_dp_dual_mode_helper.h     |  80 
> >  3 files changed, 409 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >  create mode 100644 include/drm/drm_dp_dual_mode_helper.h
> > 
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 6eb94fc561dc..8ef50f36 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> >  
> >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> > drm_probe_helper.o \
> >    drm_plane_helper.o drm_dp_mst_topology.o
> > drm_atomic_helper.o \
> > -   drm_kms_helper_common.o
> > +   drm_kms_helper_common.o drm_dp_dual_mode_helper.o
> >  
> >  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> > b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> > new file mode 100644
> > index ..bfe511c09568
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> > @@ -0,0 +1,328 @@
> > +/*
> > + * Copyright © 2016 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be
> > included in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> > USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#i

[Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Ville Syrjälä]

On Thu, Mar 31, 2016 at 07:26:25PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-02-25 às 14:51 +0200, ville.syrjala at linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > To save a bit of power, let's try to turn off the TMDS output buffers
> > in DP++ adaptors when we're not driving the port.
> > 
> > v2: Let's not forget DDI, toss in a debug message while at it
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  | 12 
> >  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
> >  drivers/gpu/drm/i915/intel_hdmi.c | 31
> > +--
> >  3 files changed, 43 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 21a9b83f3bfc..458c41788b80 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct
> > intel_encoder *intel_encoder)
> >    enum port port = intel_ddi_get_encoder_port(intel_encoder);
> >    int type = intel_encoder->type;
> >  
> > +   if (type == INTEL_OUTPUT_HDMI) {
> > +   struct intel_hdmi *intel_hdmi =
> > enc_to_intel_hdmi(encoder);
> > +
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> > true);
> > +   }
> > +
> >    intel_prepare_ddi_buffer(intel_encoder);
> >  
> >    if (type == INTEL_OUTPUT_EDP) {
> > @@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct
> > intel_encoder *intel_encoder)
> >    DPLL_CTRL2_DDI_CLK_OFF(port)
> > ));
> >    else if (INTEL_INFO(dev)->gen < 9)
> >    I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> > +
> > +   if (type == INTEL_OUTPUT_HDMI) {
> > +   struct intel_hdmi *intel_hdmi =
> > enc_to_intel_hdmi(encoder);
> > +
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> > false);
> > +   }
> >  }
> >  
> >  static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 944eacbfb6a9..2e4fa4337c59 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -706,6 +706,7 @@ struct intel_hdmi {
> >    int ddc_bus;
> >    struct {
> >    int max_tmds_clock;
> > +   bool tmds_output_control;
> >    } dp_dual_mode;
> >    bool limited_color_range;
> >    bool color_range_auto;
> > @@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct
> > intel_digital_port *intel_dig_port,
> >  struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> >  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> >           struct intel_crtc_state
> > *pipe_config);
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> > bool enable);
> >  
> >  
> >  /* intel_lvds.c */
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 1e8cfdb18dc7..4b528a669f8e 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct
> > drm_encoder *encoder,
> >    intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
> >  }
> >  
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> > bool enable)
> > +{
> > +   if (hdmi->dp_dual_mode.tmds_output_control) {
> 
> Or you could just do an early return here and save an indentation level
> :)

Indeed. I had the code inlined originally so the extra indentation
made sense, and the I just copypasted it to this separate function,
and in my haste forgot to flatten it.

> 
> > +   struct drm_i915_private *dev_priv =
> > to_i915(intel_hdmi_to_dev(hdmi));
> > +   struct i2c_adapter *adapter =
> > +   intel_gmbus_get_adapter(dev_priv, hdmi-
> > >ddc_bus);
> > +
> > +   DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS
> > output\n",
> > +         enable ? "Enabling" : "Disabling");
> > +
> > +   drm_dp_dual_mode_set_tmds_output(adapter, enable);
> > +   }
> > +}
> > +
> >  static void intel_hdmi_prepare(struct intel_encoder *encoder)
> >  {
> >    struct drm_device *dev = encoder->base.dev;
> > @@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct
> > intel_encoder *encoder)
> >    const struct drm_display_mode *adjusted_mode = &crtc-
> > >config->base.adjusted_mode;
> >    u32 hdmi_val;
> >  
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> > +
> >    hdmi_val = SDVO_ENCODING_HDMI;
> >    if (!HAS_PCH_SPLIT(dev) && crtc->config-
> > >limited_color_range)
> >    hdmi_val |= HDMI_COLOR_RANGE_16_235;
> > @@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct
> > intel_encoder *encoder)
> >    }
> >  
> >    intel_hdmi->set_infoframes(&encoder->base, false, NULL);
> > +
> > +   intel_dp_dual_mode_set_tmd

[PATCH] drm/i915/hdmi: Fix weak connector detection

[Ezequiel Garcia]

Currently, our implementation of drm_connector_funcs.detect is
based on getting a valid EDID.

This requirement makes the driver fail to detect connected
connectors in case of EDID corruption, which prevents from falling
back to modes provided by builtin or user-provided EDIDs.

Let's fix this by improving the detection, with a DDC probe,
if the current EDID-based detection failed.

Note that a better way of dealing with this could calling
drm_probe_ddc in drm_connector_funcs.detect, and do the
EDID full reading and parsing in drm_connector_helper_funcs.get_modes,
when it's actually needed.

However, this would be more invasive and thus more error-prone.
The current commit is an attempt to get some uninvasive fix,
and allow for easier backporting.

Signed-off-by: Ezequiel Garcia 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a0d8daed2470..c079206e6681 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1428,6 +1428,20 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
} else
status = connector_status_disconnected;

+   /*
+* The above call to intel_hdmi_set_edid() checked for a valid EDID.
+* However, the EDID can get corrupted for several reasons, resulting
+* in a disconnected status despite the connector being connected.
+* Hence, let's try one more time, by only probing the DDC.
+*
+* This allows the DRM core to fallback to builtin or user-provided
+* EDID firmware, e.g. in drm_helper_probe_single_connector_modes.
+*/
+   if (status == connector_status_disconnected)
+   if (drm_probe_ddc(intel_gmbus_get_adapter(dev_priv,
+   intel_hdmi->ddc_bus)))
+   status = connector_status_connected;
+
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);

return status;
-- 
2.7.0

[Bug 93767] Glitches with soft shadows and MSAA in Knights of the Old Republic 2

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

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

--- Comment #1 from almos  ---
With the ATI_fs patch series v4 applied (even the ones that are not in master
yet), I see no such glitches in KotOR 2. Shadows are correct, and fog is
correct. The only problem I see is that enabling soft shadows makes the shadows
so faint they are barely visible, but I think that's a bug in the game.

I'm using latest Mesa from git, llvm 3.7.1, Wine 1.9.6.

Note that Steam only offers the remastered version of KotOR2 now, which doesn't
use ATI_fs anymore. The screenshots on the store page may be from the old
version though.

-- 
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/20160331/7d3edb98/attachment.html>

[Bug 93767] Glitches with soft shadows and MSAA in Knights of the Old Republic 2

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

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

--- Comment #2 from Daniel Scharrer  ---
> Note that Steam only offers the remastered version of KotOR2 now, which
> doesn't use ATI_fs anymore.

Yes, I'm talking about the remastered version (the only one that has a native
linux release). Did you test the original?

Anyway, I'm still seeing the glitches here. Soft shadows aren't any fainter
than hard shadows as far as I can tell.

GPU: R9 380X (tonga)
Mesa 11.3.0-devel (git-9076e04)
LLVM r265023

-- 
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/20160331/bfa3523a/attachment.html>

[v14, 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Doug Anderson]

Hi,

On Wed, Mar 30, 2016 at 1:32 PM, Guenter Roeck  wrote:
> This results in the following build errors if DRM_ANALOGIX_DP
> is configured as module.
>
> ERROR: "analogix_dp_start_video" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane0_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane1_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane2_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane3_link_training" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_lane_count" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
> ERROR: "analogix_dp_get_link_bandwidth" 
> [drivers/gpu/drm/bridge/analogix/analogix_dp_core.ko] undefined!
>
> [ and so on ]
>
> It should probably be something like
>
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o

Sounds like this is a major problem.  Presumably Yakir should fix and
send a new pull request?

-Doug

[PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()

[Boris Brezillon]

Hi Dmitry,

On Thu, 31 Mar 2016 10:38:58 -0700
Dmitry Torokhov  wrote:

> Hi Boris,
> 
> On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > Prefix those function as deprecated to encourage all existing users to
> > switch to pwm_apply_state().
> 
> Why not keep at least some of them as wrappers where we do not need to
> chnage several parameters at once? It is much easier to have a driver
> do:
> 
>   error = pwm_enable(pwm);
>   if (error)
>   ...
> 
> rather than declaring the state variable, fectch it, adjust and then
> apply.

True. Actually deprecating the non-atomic API was not my primary goal.
Thierry would you mind if we keep both APIs around?

> 
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  include/linux/pwm.h | 24 
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> > index 4aad4eb..9bac10f 100644
> > --- a/include/linux/pwm.h
> > +++ b/include/linux/pwm.h
> > @@ -225,8 +225,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct 
> > pwm_state *state);
> >   *
> >   * Returns: 0 on success or a negative error code on failure.
> >   */
> > -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> > -int period_ns)
> > +static inline int __deprecated pwm_config(struct pwm_device *pwm, int 
> > duty_ns,
> > + int period_ns)
> >  {
> > struct pwm_state pstate;
> >  
> > @@ -252,8 +252,8 @@ static inline int pwm_config(struct pwm_device *pwm, 
> > int duty_ns,
> >   *
> >   * Returns: 0 on success or a negative error code on failure.
> >   */
> > -static inline int pwm_set_polarity(struct pwm_device *pwm,
> > -  enum pwm_polarity polarity)
> > +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> > +   enum pwm_polarity polarity)
> >  {
> > struct pwm_state pstate;
> >  
> > @@ -284,7 +284,7 @@ static inline int pwm_set_polarity(struct pwm_device 
> > *pwm,
> >   *
> >   * Returns: 0 on success or a negative error code on failure.
> >   */
> > -static inline int pwm_enable(struct pwm_device *pwm)
> > +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> >  {
> > struct pwm_state pstate;
> >  
> > @@ -303,7 +303,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
> >   * pwm_disable() - stop a PWM output toggling
> >   * @pwm: PWM device
> >   */
> > -static inline void pwm_disable(struct pwm_device *pwm)
> > +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> >  {
> > struct pwm_state pstate;
> >  
> > @@ -360,24 +360,24 @@ static inline int pwm_apply_state(struct pwm_device 
> > *pwm,
> > return -ENOTSUPP;
> >  }
> >  
> > -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> > -int period_ns)
> > +static inline int __deprecated pwm_config(struct pwm_device *pwm, int 
> > duty_ns,
> > + int period_ns)
> >  {
> > return -EINVAL;
> >  }
> >  
> > -static inline int pwm_set_polarity(struct pwm_device *pwm,
> > -  enum pwm_polarity polarity)
> > +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> > +   enum pwm_polarity polarity)
> >  {
> > return -ENOTSUPP;
> >  }
> >  
> > -static inline int pwm_enable(struct pwm_device *pwm)
> > +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
> >  {
> > return -EINVAL;
> >  }
> >  
> > -static inline void pwm_disable(struct pwm_device *pwm)
> > +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
> >  {
> >  }
> >  
> > -- 
> > 2.5.0
> > 
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

[Zanoni, Paulo R]

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Add a helper which aids in he identification of DP dual mode (aka.
> DP++)
> adaptors. There are several types of adaptors specified:
> type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
> 
> Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2
> adaptors
> may go as high as 300MHz and they provide a register informing the
> source device what the actual limit is. Supposedly also type 1
> adaptors
> may optionally implement this register. This TMDS clock limit is the
> main reason why we need to identify these adaptors.
> 
> Type 1 adaptors provide access to their internal registers and the
> sink
> DDC bus through I2C. Type 2 adaptors provide this access both via I2C
> and I2C-over-AUX. A type 2 source device may choose to implement
> either
> or both of these methods. If a source device implements only the
> I2C-over-AUX method, then the driver will obviously need specific
> support for such adaptors since the port is driven like an HDMI port,
> but DDC communication happes over the AUX channel.
> 
> This helper should be enough to identify the adaptor type (some
> type 1 DVI adaptors may be a slight exception) and the maximum TMDS
> clock limit. Another feature that may be available is control over
> the TMDS output buffers on the adaptor, possibly allowing for some
> power saving when the TMDS link is down.
> 
> Other user controllable features that may be available in the
> adaptors
> are downstream i2c bus speed control when using i2c-over-aux, and
> some control over the CEC pin. I chose not to provide any helper
> functions for those since I have no use for them in i915 at this
> time.
> The rest of the registers in the adaptor are mostly just information,
> eg. IEEE OUI, hardware and firmware revision, etc.

Please run a spell checker and do some proof-reading both in the commit
message and in the code comments. Multiple instances of "sizo",
"Hoever", "adator", "Identyfy", etc. I also spotted some typos in the
next commits.



> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/Makefile                  |   2 +-
>  drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328
> ++
>  include/drm/drm_dp_dual_mode_helper.h     |  80 
>  3 files changed, 409 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
>  create mode 100644 include/drm/drm_dp_dual_mode_helper.h
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 6eb94fc561dc..8ef50f36 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
>  
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o
> drm_probe_helper.o \
>  drm_plane_helper.o drm_dp_mst_topology.o
> drm_atomic_helper.o \
> - drm_kms_helper_common.o
> + drm_kms_helper_common.o drm_dp_dual_mode_helper.o
>  
>  drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> new file mode 100644
> index ..bfe511c09568
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> @@ -0,0 +1,328 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> obtaining a
> + * copy of this software and associated documentation files (the
> "Software"),
> + * to deal in the Software without restriction, including without
> limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> the
> + * Software is furnished to do so, subject to the following
> conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * DOC: DP dual mode (aka. DP++) adaptor helpers
> + *
> + * Helper functions to deal with DP dual mode adaptors.
> + *
> + * Type 1:
> + * Adaptor registers (if any) and the sink DDC bus may be accessed
> via I2C.
> + *
> + * Type 2:
> +

[v14, 01/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Doug Anderson]

Hi,

On Thu, Mar 31, 2016 at 2:56 AM, Thierry Reding  wrote:
> Ugh... most of these functions shouldn't be there in the first place. We
> have helpers in the core that already do this. Most of the functionality
> is duplicated in this driver.
>
> I realize that this is a problem that existed in the Exynos DP driver,
> but somebody really ought to rewrite those parts to make use of the DRM
> DP helpers.

As I understand it from discussions in
 and
, we
shouldn't block merging the series but someone should pick up this
work after the merge.

So probably Yakir should fixup the problem pointed out by Guenter and
send a new pull.

-Doug

[PATCH v5 36/46] input: misc: max77693: switch to the atomic API

[Dmitry Torokhov]

Hi Boris,

On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> pwm_config/enable/disable() have been deprecated and should be replaced
> by pwm_apply_state().
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/input/misc/max77693-haptic.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/misc/max77693-haptic.c 
> b/drivers/input/misc/max77693-haptic.c
> index cf6aac0..aef7dc4 100644
> --- a/drivers/input/misc/max77693-haptic.c
> +++ b/drivers/input/misc/max77693-haptic.c
> @@ -70,13 +70,16 @@ struct max77693_haptic {
>  
>  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
>  {
> + struct pwm_state pstate;
>   struct pwm_args pargs = { };
> - int delta;
>   int error;
>  
>   pwm_get_args(haptic->pwm_dev, &pargs);
> - delta = (pargs.period + haptic->pwm_duty) / 2;
> - error = pwm_config(haptic->pwm_dev, delta, pargs.period);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> +
> + pstate.period = pargs.period;
> + pstate.duty_cycle = (pargs.period + haptic->pwm_duty) / 2;
> + error = pwm_apply_state(haptic->pwm_dev, &pstate);

This does not make sense with regard to the atomic API. If you look in
max77693_haptic_play_work(), right after calling
max77693_haptic_set_duty_cycle() we either try to enable or disable the
pwm. When switching to this new API we should combine both actions.

>   if (error) {
>   dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
>   return error;
> @@ -161,12 +164,16 @@ static int max77693_haptic_lowsys(struct 
> max77693_haptic *haptic, bool enable)
>  
>  static void max77693_haptic_enable(struct max77693_haptic *haptic)
>  {
> + struct pwm_state pstate;
>   int error;
>  
>   if (haptic->enabled)
>   return;
>  
> - error = pwm_enable(haptic->pwm_dev);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> + pstate.enabled = true;
> +
> + error = pwm_apply_state(haptic->pwm_dev, &pstate);

As I mentioned I'd rather we did not deprecate pwm_enable() and
pwm_disable() (and maybe others), as it forces us to add unnecessary
boilerplate code to the drivers.

>   if (error) {
>   dev_err(haptic->dev,
>   "failed to enable haptic pwm device: %d\n", error);
> @@ -188,11 +195,13 @@ static void max77693_haptic_enable(struct 
> max77693_haptic *haptic)
>  err_enable_config:
>   max77693_haptic_lowsys(haptic, false);
>  err_enable_lowsys:
> - pwm_disable(haptic->pwm_dev);
> + pstate.enabled = false;
> + pwm_apply_state(haptic->pwm_dev, &pstate);
>  }
>  
>  static void max77693_haptic_disable(struct max77693_haptic *haptic)
>  {
> + struct pwm_state pstate;
>   int error;
>  
>   if (!haptic->enabled)
> @@ -206,7 +215,9 @@ static void max77693_haptic_disable(struct 
> max77693_haptic *haptic)
>   if (error)
>   goto err_disable_lowsys;
>  
> - pwm_disable(haptic->pwm_dev);
> + pwm_get_state(haptic->pwm_dev, &pstate);
> + pstate.enabled = false;
> + pwm_apply_state(haptic->pwm_dev, &pstate);

Same here.

>   haptic->enabled = false;
>  
>   return;
> -- 
> 2.5.0
> 

Thanks.

-- 
Dmitry

[Intel-gfx] [PATCH v2 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Zanoni, Paulo R]

Em Qui, 2016-02-25 às 14:51 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
> 
> v2: Let's not forget DDI, toss in a debug message while at it
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c  | 12 
>  drivers/gpu/drm/i915/intel_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 31
> +--
>  3 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 21a9b83f3bfc..458c41788b80 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2301,6 +2301,12 @@ static void intel_ddi_pre_enable(struct
> intel_encoder *intel_encoder)
>  enum port port = intel_ddi_get_encoder_port(intel_encoder);
>  int type = intel_encoder->type;
>  
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> true);
> + }
> +
>  intel_prepare_ddi_buffer(intel_encoder);
>  
>  if (type == INTEL_OUTPUT_EDP) {
> @@ -2367,6 +2373,12 @@ static void intel_ddi_post_disable(struct
> intel_encoder *intel_encoder)
>  DPLL_CTRL2_DDI_CLK_OFF(port)
> ));
>  else if (INTEL_INFO(dev)->gen < 9)
>  I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> +
> + if (type == INTEL_OUTPUT_HDMI) {
> + struct intel_hdmi *intel_hdmi =
> enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi,
> false);
> + }
>  }
>  
>  static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 944eacbfb6a9..2e4fa4337c59 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -706,6 +706,7 @@ struct intel_hdmi {
>  int ddc_bus;
>  struct {
>  int max_tmds_clock;
> + bool tmds_output_control;
>  } dp_dual_mode;
>  bool limited_color_range;
>  bool color_range_auto;
> @@ -1355,6 +1356,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
>  struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
>  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>         struct intel_crtc_state
> *pipe_config);
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable);
>  
>  
>  /* intel_lvds.c */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1e8cfdb18dc7..4b528a669f8e 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -837,6 +837,20 @@ static void hsw_set_infoframes(struct
> drm_encoder *encoder,
>  intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
>  }
>  
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi,
> bool enable)
> +{
> + if (hdmi->dp_dual_mode.tmds_output_control) {

Or you could just do an early return here and save an indentation level
:)

> + struct drm_i915_private *dev_priv =
> to_i915(intel_hdmi_to_dev(hdmi));
> + struct i2c_adapter *adapter =
> + intel_gmbus_get_adapter(dev_priv, hdmi-
> >ddc_bus);
> +
> + DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS
> output\n",
> +       enable ? "Enabling" : "Disabling");
> +
> + drm_dp_dual_mode_set_tmds_output(adapter, enable);
> + }
> +}
> +
>  static void intel_hdmi_prepare(struct intel_encoder *encoder)
>  {
>  struct drm_device *dev = encoder->base.dev;
> @@ -846,6 +860,8 @@ static void intel_hdmi_prepare(struct
> intel_encoder *encoder)
>  const struct drm_display_mode *adjusted_mode = &crtc-
> >config->base.adjusted_mode;
>  u32 hdmi_val;
>  
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> +
>  hdmi_val = SDVO_ENCODING_HDMI;
>  if (!HAS_PCH_SPLIT(dev) && crtc->config-
> >limited_color_range)
>  hdmi_val |= HDMI_COLOR_RANGE_16_235;
> @@ -1144,6 +1160,8 @@ static void intel_disable_hdmi(struct
> intel_encoder *encoder)
>  }
>  
>  intel_hdmi->set_infoframes(&encoder->base, false, NULL);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
>  }
>  
>  static void g4x_disable_hdmi(struct intel_encoder *encoder)
> @@ -1369,6 +1387,7 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
>  intel_hdmi->rgb_quant_range_selectable = false;
>  
>  intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> + intel_hdmi->dp_dual_mode.tmds_output_control = false;
>  
>  kfree(to_intel_connector(connector)->detect_edid

[PATCH 1/3 v2] drm/i2c/adv7511: Add audio support

[Jose Abreu]

Hi Archit,


On 29-03-2016 18:03, Archit Taneja wrote:
>
>
> On 3/29/2016 4:22 PM, Jose Abreu wrote:
>> Hi Archit,
>>
>> On 29-03-2016 09:05, Archit Taneja wrote:
>>> Hi,
>>>
>>> On 03/28/2016 08:06 PM, Jose Abreu wrote:
 This patch adds audio support for the ADV7511 HDMI transmitter
 using ALSA SoC.

 The code was ported from Analog Devices linux tree from
 commit 1770c4a1e32b ("Merge remote-tracking branch
 'xilinx/master' into xcomm_zynq"), which is available at:
  - https://github.com/analogdevicesinc/linux/

 The main core file was renamed from adv7511.c to adv7511_core.c
 so that audio and video compile into a single adv7511.ko module
 and to keep up with Analog Devices kernel tree.

 The audio can be disabled using menu-config so it is possible
 to use only video mode.

 The HDMI mode is automatically started at boot and the audio
 (when enabled) registers as a codec into ALSA.
>>>
>>> Is there a reason why we set the mode to HDMI at probe itself?
>>> Shouldn't it be okay to set the mode later once we read the
>>> EDID off the panel?
>>>
>>> Some more comments below.
>>>
>>
>> Well, when I was using this in kernel 3.18 (with an older version of the 
>> driver)
>> I noticed that DVI mode was being used even when HDMI was connected so I 
>> forced
>> the driver to start in HDMI mode. There were some changes in the driver so 
>> it is
>> possible that this is no longer needed. Should I drop it?
>
> Mode selection works fine with ADV7533 on a 4.5 kernel. I'm assuming it
> should work out of the box for ADV7511 too. We should drop this.
>
>

Ok, will drop.

>>

 SPDIF DAI format was also added to ASoC as it is required
 by adv7511 audio.

 Signed-off-by: Jose Abreu 
 ---

 No changes v1 -> v2.

drivers/gpu/drm/i2c/Kconfig |   11 +
drivers/gpu/drm/i2c/Makefile|2 +
drivers/gpu/drm/i2c/adv7511.c   | 1024
 ---
drivers/gpu/drm/i2c/adv7511.h   |   41 ++
drivers/gpu/drm/i2c/adv7511_audio.c |  310 +++
drivers/gpu/drm/i2c/adv7511_core.c  | 1005
 ++
include/sound/soc-dai.h |1 +
7 files changed, 1370 insertions(+), 1024 deletions(-)
delete mode 100644 drivers/gpu/drm/i2c/adv7511.c
create mode 100644 drivers/gpu/drm/i2c/adv7511_audio.c
create mode 100644 drivers/gpu/drm/i2c/adv7511_core.c
>>>
>>> 
>>>
 +
 +static int adv7511_probe(struct i2c_client *i2c, const struct 
 i2c_device_id
 *id)
 +{
 +struct adv7511_link_config link_config;
 +struct adv7511 *adv7511;
 +struct device *dev = &i2c->dev;
 +unsigned int val;
 +int ret;
 +
 +if (!dev->of_node)
 +return -EINVAL;
 +
 +adv7511 = devm_kzalloc(dev, sizeof(*adv7511), GFP_KERNEL);
 +if (!adv7511)
 +return -ENOMEM;
 +
 +adv7511->powered = false;
 +adv7511->status = connector_status_disconnected;
 +
 +ret = adv7511_parse_dt(dev->of_node, &link_config);
 +if (ret)
 +return ret;
 +
 +/*
 + * The power down GPIO is optional. If present, toggle it from active 
 to
 + * inactive to wake up the encoder.
 + */
 +adv7511->gpio_pd = devm_gpiod_get_optional(dev, "pd", GPIOD_OUT_HIGH);
 +if (IS_ERR(adv7511->gpio_pd))
 +return PTR_ERR(adv7511->gpio_pd);
 +
 +if (adv7511->gpio_pd) {
 +mdelay(5);
 +gpiod_set_value_cansleep(adv7511->gpio_pd, 0);
 +}
 +
 +adv7511->regmap = devm_regmap_init_i2c(i2c, &adv7511_regmap_config);
 +if (IS_ERR(adv7511->regmap))
 +return PTR_ERR(adv7511->regmap);
 +
 +ret = regmap_read(adv7511->regmap, ADV7511_REG_CHIP_REVISION, &val);
 +if (ret)
 +return ret;
 +dev_dbg(dev, "Rev. %d\n", val);
 +
 +ret = regmap_register_patch(adv7511->regmap, adv7511_fixed_registers,
 +ARRAY_SIZE(adv7511_fixed_registers));
 +if (ret)
 +return ret;
 +
 +regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, 
 edid_i2c_addr);
 +regmap_write(adv7511->regmap, ADV7511_REG_PACKET_I2C_ADDR,
 + packet_i2c_addr);
 +regmap_write(adv7511->regmap, ADV7511_REG_CEC_I2C_ADDR, cec_i2c_addr);
 +adv7511_packet_disable(adv7511, 0x);
 +
 +adv7511->i2c_main = i2c;
 +adv7511->i2c_edid = i2c_new_dummy(i2c->adapter, edid_i2c_addr >> 1);
 +if (!adv7511->i2c_edid)
 +return -ENOMEM;
 +
 +if (i2c->irq) {
 +init_waitqueue_head(&adv7511->wq);
 +
 +ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
 +adv7511_irq_handler,
 

[PATCH v5 32/46] pwm: deprecate pwm_config(), pwm_enable() and pwm_disable()

[Dmitry Torokhov]

Hi Boris,

On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> Prefix those function as deprecated to encourage all existing users to
> switch to pwm_apply_state().

Why not keep at least some of them as wrappers where we do not need to
chnage several parameters at once? It is much easier to have a driver
do:

error = pwm_enable(pwm);
if (error)
...

rather than declaring the state variable, fectch it, adjust and then
apply.

> 
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/pwm.h | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 4aad4eb..9bac10f 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -225,8 +225,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct 
> pwm_state *state);
>   *
>   * Returns: 0 on success or a negative error code on failure.
>   */
> -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> -  int period_ns)
> +static inline int __deprecated pwm_config(struct pwm_device *pwm, int 
> duty_ns,
> +   int period_ns)
>  {
>   struct pwm_state pstate;
>  
> @@ -252,8 +252,8 @@ static inline int pwm_config(struct pwm_device *pwm, int 
> duty_ns,
>   *
>   * Returns: 0 on success or a negative error code on failure.
>   */
> -static inline int pwm_set_polarity(struct pwm_device *pwm,
> -enum pwm_polarity polarity)
> +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> + enum pwm_polarity polarity)
>  {
>   struct pwm_state pstate;
>  
> @@ -284,7 +284,7 @@ static inline int pwm_set_polarity(struct pwm_device *pwm,
>   *
>   * Returns: 0 on success or a negative error code on failure.
>   */
> -static inline int pwm_enable(struct pwm_device *pwm)
> +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
>  {
>   struct pwm_state pstate;
>  
> @@ -303,7 +303,7 @@ static inline int pwm_enable(struct pwm_device *pwm)
>   * pwm_disable() - stop a PWM output toggling
>   * @pwm: PWM device
>   */
> -static inline void pwm_disable(struct pwm_device *pwm)
> +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
>  {
>   struct pwm_state pstate;
>  
> @@ -360,24 +360,24 @@ static inline int pwm_apply_state(struct pwm_device 
> *pwm,
>   return -ENOTSUPP;
>  }
>  
> -static inline int pwm_config(struct pwm_device *pwm, int duty_ns,
> -  int period_ns)
> +static inline int __deprecated pwm_config(struct pwm_device *pwm, int 
> duty_ns,
> +   int period_ns)
>  {
>   return -EINVAL;
>  }
>  
> -static inline int pwm_set_polarity(struct pwm_device *pwm,
> -enum pwm_polarity polarity)
> +static inline int __deprecated pwm_set_polarity(struct pwm_device *pwm,
> + enum pwm_polarity polarity)
>  {
>   return -ENOTSUPP;
>  }
>  
> -static inline int pwm_enable(struct pwm_device *pwm)
> +static inline int __deprecated pwm_enable(struct pwm_device *pwm)
>  {
>   return -EINVAL;
>  }
>  
> -static inline void pwm_disable(struct pwm_device *pwm)
> +static inline void __deprecated pwm_disable(struct pwm_device *pwm)
>  {
>  }
>  
> -- 
> 2.5.0
> 

-- 
Dmitry

[PATCH v5 36/46] input: misc: max77693: switch to the atomic API

[Boris Brezillon]

On Thu, 31 Mar 2016 10:48:01 -0700
Dmitry Torokhov  wrote:

> Hi Boris,
> 
> On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > pwm_config/enable/disable() have been deprecated and should be replaced
> > by pwm_apply_state().
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/input/misc/max77693-haptic.c | 23 +--
> >  1 file changed, 17 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/input/misc/max77693-haptic.c 
> > b/drivers/input/misc/max77693-haptic.c
> > index cf6aac0..aef7dc4 100644
> > --- a/drivers/input/misc/max77693-haptic.c
> > +++ b/drivers/input/misc/max77693-haptic.c
> > @@ -70,13 +70,16 @@ struct max77693_haptic {
> >  
> >  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> >  {
> > +   struct pwm_state pstate;
> > struct pwm_args pargs = { };
> > -   int delta;
> > int error;
> >  
> > pwm_get_args(haptic->pwm_dev, &pargs);
> > -   delta = (pargs.period + haptic->pwm_duty) / 2;
> > -   error = pwm_config(haptic->pwm_dev, delta, pargs.period);
> > +   pwm_get_state(haptic->pwm_dev, &pstate);
> > +
> > +   pstate.period = pargs.period;
> > +   pstate.duty_cycle = (pargs.period + haptic->pwm_duty) / 2;
> > +   error = pwm_apply_state(haptic->pwm_dev, &pstate);
> 
> This does not make sense with regard to the atomic API. If you look in
> max77693_haptic_play_work(), right after calling
> max77693_haptic_set_duty_cycle() we either try to enable or disable the
> pwm. When switching to this new API we should combine both actions.

True. I'll address that, unless Thierry is fine keeping the non-atomic
API, in which case I'll just drop patches 32 to 46.

> 
> > if (error) {
> > dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
> > return error;
> > @@ -161,12 +164,16 @@ static int max77693_haptic_lowsys(struct 
> > max77693_haptic *haptic, bool enable)
> >  
> >  static void max77693_haptic_enable(struct max77693_haptic *haptic)
> >  {
> > +   struct pwm_state pstate;
> > int error;
> >  
> > if (haptic->enabled)
> > return;
> >  
> > -   error = pwm_enable(haptic->pwm_dev);
> > +   pwm_get_state(haptic->pwm_dev, &pstate);
> > +   pstate.enabled = true;
> > +
> > +   error = pwm_apply_state(haptic->pwm_dev, &pstate);
> 
> As I mentioned I'd rather we did not deprecate pwm_enable() and
> pwm_disable() (and maybe others), as it forces us to add unnecessary
> boilerplate code to the drivers.
>  
> > if (error) {
> > dev_err(haptic->dev,
> > "failed to enable haptic pwm device: %d\n", error);
> > @@ -188,11 +195,13 @@ static void max77693_haptic_enable(struct 
> > max77693_haptic *haptic)
> >  err_enable_config:
> > max77693_haptic_lowsys(haptic, false);
> >  err_enable_lowsys:
> > -   pwm_disable(haptic->pwm_dev);
> > +   pstate.enabled = false;
> > +   pwm_apply_state(haptic->pwm_dev, &pstate);
> >  }
> >  
> >  static void max77693_haptic_disable(struct max77693_haptic *haptic)
> >  {
> > +   struct pwm_state pstate;
> > int error;
> >  
> > if (!haptic->enabled)
> > @@ -206,7 +215,9 @@ static void max77693_haptic_disable(struct 
> > max77693_haptic *haptic)
> > if (error)
> > goto err_disable_lowsys;
> >  
> > -   pwm_disable(haptic->pwm_dev);
> > +   pwm_get_state(haptic->pwm_dev, &pstate);
> > +   pstate.enabled = false;
> > +   pwm_apply_state(haptic->pwm_dev, &pstate);
> 
> Same here.
> 
> > haptic->enabled = false;
> >  
> > return;
> > -- 
> > 2.5.0
> > 
> 
> Thanks.
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCHv14 05/18] HID: add HDMI CEC specific keycodes

[Dmitry Torokhov]

On Fri, Mar 25, 2016 at 02:10:03PM +0100, Hans Verkuil wrote:
> From: Kamil Debski 
> 
> Add HDMI CEC specific keycodes to the keycodes definition.
> 
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 

Acked-by: Dmitry Torokhov 

> ---
>  include/uapi/linux/input-event-codes.h | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/include/uapi/linux/input-event-codes.h 
> b/include/uapi/linux/input-event-codes.h
> index 87cf351..02b7b3a 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -611,6 +611,36 @@
>  #define KEY_KBDINPUTASSIST_ACCEPT0x264
>  #define KEY_KBDINPUTASSIST_CANCEL0x265
>  
> +/* Diagonal movement keys */
> +#define KEY_RIGHT_UP 0x266
> +#define KEY_RIGHT_DOWN   0x267
> +#define KEY_LEFT_UP  0x268
> +#define KEY_LEFT_DOWN0x269
> +
> +#define KEY_ROOT_MENU0x26a /* Show Device's Root 
> Menu */
> +#define KEY_MEDIA_TOP_MENU   0x26b /* Show Top Menu of the Media 
> (e.g. DVD) */
> +#define KEY_NUMERIC_11   0x26c
> +#define KEY_NUMERIC_12   0x26d
> +/*
> + * Toggle Audio Description: refers to an audio service that helps blind and
> + * visually impaired consumers understand the action in a program. Note: in
> + * some countries this is referred to as "Video Description".
> + */
> +#define KEY_AUDIO_DESC   0x26e
> +#define KEY_3D_MODE  0x26f
> +#define KEY_NEXT_FAVORITE0x270
> +#define KEY_STOP_RECORD  0x271
> +#define KEY_PAUSE_RECORD 0x272
> +#define KEY_VOD  0x273 /* Video on Demand */
> +#define KEY_UNMUTE   0x274
> +#define KEY_FASTREVERSE  0x275
> +#define KEY_SLOWREVERSE  0x276
> +/*
> + * Control a data application associated with the currently viewed channel,
> + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.)
> + */
> +#define KEY_DATA 0x275
> +
>  #define BTN_TRIGGER_HAPPY0x2c0
>  #define BTN_TRIGGER_HAPPY1   0x2c0
>  #define BTN_TRIGGER_HAPPY2   0x2c1
> -- 
> 2.7.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Dmitry

[Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Zanoni, Paulo R]

Em Ter, 2016-02-23 às 18:46 +0200, ville.syrjala at linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way to
> do that. So as a last resort, check the VBT to see if the HDMI
> port is in fact a dual mode capable DP port.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_bios.h |  3 +++
>  drivers/gpu/drm/i915/intel_dp.c   | 28 
>  drivers/gpu/drm/i915/intel_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
>  4 files changed, 53 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index 350d4e0f75a4..50d1659efe47 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -730,6 +730,7 @@ struct bdb_psr {
>  #define  DEVICE_TYPE_INT_TV0x1009
>  #define  DEVICE_TYPE_HDMI  0x60D2
>  #define  DEVICE_TYPE_DP0x68C6
> +#define   DEVICE_TYPE_DP_DUAL_MODE  0x60D6
>  #define  DEVICE_TYPE_eDP   0x78C6
>  
>  #define  DEVICE_TYPE_CLASS_EXTENSION  (1 << 15)
> @@ -764,6 +765,8 @@ struct bdb_psr {
>   DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
>   DEVICE_TYPE_ANALOG_OUTPUT)
>  
> +#define DEVICE_TYPE_DP_DUAL_MODE_BITS ~DEVICE_TYPE_NOT_HDMI_OUTPUT
> +
>  /* define the DVO port for HDMI output type */
>  #define DVO_B   1
>  #define DVO_C   2
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index cbc06596659a..f3edacf517ac 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device *dev,
> enum port port)
>  return false;
>  }
>  
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port)
> +{
> + const union child_device_config *p_child;
> + int i;
> + static const short port_mapping[] = {
> + [PORT_B] = DVO_PORT_DPB,
> + [PORT_C] = DVO_PORT_DPC,
> + [PORT_D] = DVO_PORT_DPD,
> + [PORT_E] = DVO_PORT_DPE,
> + };
> +
> + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> + return false;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = &dev_priv->vbt.child_dev[i];
> +
> + if (p_child->common.dvo_port == port_mapping[port]
> &&
> +     (p_child->common.device_type &
> DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> +     (DEVICE_TYPE_DP_DUAL_MODE &
> DEVICE_TYPE_DP_DUAL_MODE_BITS))
> + return true;
> + }

Some thoughts:

This is going to be implemented for all VBT versions. Since there's no
real history about anything before version 155, is this really what we
want? A huge part of the "we don't trust the VBT" culture we have on
our team is because of those old versions being completely unreliable.
If this is the case, we could make this implementation just be a small
patch in parse_ddi_port(). I'm kinda afraid we may somehow break old
machines yet again.

- Instead of creating these complicated bit masks, why don't we just
specifically check "if bit 2 and bit 4 are enabled, we're using an
adaptor"? Much simpler IMHO.

- Jani's recent patch suggests you may want to move this function to
intel_bios.c in order to avoid including intel_vbt_defs.h from
intel_hdmi.c. Anyway, you'll have to rebase.

> + return false;
> +}
> +
>  void
>  intel_dp_add_properties(struct intel_dp *intel_dp, struct
> drm_connector *connector)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3ca29a181e64..c7d1ea4dbe42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1248,6 +1248,7 @@ int intel_dp_sink_crc(struct intel_dp
> *intel_dp, u8 *crc);
>  bool intel_dp_compute_config(struct intel_encoder *encoder,
>       struct intel_crtc_state *pipe_config);
>  bool intel_dp_is_edp(struct drm_device *dev, enum port port);
> +bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum
> port port);
>  enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port,
>    bool long_hpd);
>  void intel_edp_backlight_on(struct intel_dp *intel_dp);
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 660a65f48fd8..1476f3afb7e2 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1390,14 +1390,33 @@ intel_hdmi_unset_edid(struct drm_connector
> *connector)
>  }
>  
>  static void
> -int

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

[Stephen Rothwell]

Hi all,

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

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

between commit:

  257bf15a4b97 ("drm/amdgpu: add slap cache for sync objects as well")

from Linus' tree and commit:

  44debe7a123c ("vgacon: dummy implementation for vgacon_text_force")

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/amd/amdgpu/amdgpu_drv.c
index f1e17d60055a,fba20bd59cfa..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@@ -555,8 -539,6 +555,7 @@@ static struct pci_driver amdgpu_kms_pci

  static int __init amdgpu_init(void)
  {
 +  amdgpu_sync_init();
- #ifdef CONFIG_VGA_CONSOLE
if (vgacon_text_force()) {
DRM_ERROR("VGACON disables amdgpu kernel modesetting.\n");
return -EINVAL;

i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> We've fixed piles of those in recent kernels, but didn't backport all the
> fixes (since usually it's a silent failure, but it can correlate with
> black screens).

Not quite completely, it seems ...

I have built drm-intel-nightly (f261f82359), and I'm getting this:

| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun
| [   15.855007] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* 
pipe B underrun
| [   15.855007] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe B FIFO underrun
| [   15.863175] [drm] RC6 disabled, disabling runtime PM support
| [   15.863543] [drm] initialized overlay support
| [   15.98] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun
| [   15.997130] i915 :00:02.0: fb0: inteldrmfb frame buffer device
| [   16.061856] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* 
pipe A underrun
| [   16.725274] [drm] Initialized i915 1.6.0 20160330 for :00:02.0 on 
minor 0
| [   16.805727] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun

> > | [ 2520.457732] WARNING: CPU: 0 PID: 3193 at 
> > drivers/gpu/drm/i915/i915_gem.c:4508 i915_gem_free_object+0x277/0x280 
> > [i915]()
> > | [ 2520.457736] WARN_ON(obj->frontbuffer_bits)
> 
> Hm, this one should be fixed, and the patches should all be correctly
> marked for stable. Either there's a backlog somewhere, or we failed.
> 
> Would be great if you can test a drm-intel-nightly build (or 4.6-rc1) for
> either and confirm that they're gone. And for the later we really should
> hunt down the bugfix if it's stuck.

| [  141.999803] [ cut here ]
| [  141.16] WARNING: CPU: 0 PID: 3349 at 
drivers/gpu/drm/i915/i915_gem.c:4568 i915_gem_free_object+0x25f/0x270 [i915]
| [  141.23] WARN_ON(obj->frontbuffer_bits)
| [  141.28] Modules linked in: ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_CT 
iptable_raw xt_nat xt_tcpudp xt_addrtype iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables dummy tun 
nfsd exportfs nfs lockd grace sunrpc ipv6 fbcon bitblit softcursor font loop 
mousedev i915 i2c_algo_bit drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea snd_intel8x0 drm snd_ac97_codec 
ac97_bus i2c_core snd_pcm_oss fb snd_mixer_oss fbdev snd_pcm ipw2200 snd_timer 
snd libipw soundcore lib80211 nsc_ircc thinkpad_acpi cfg80211 pcmcia psmouse 
sdhci_pci irda uhci_hcd ehci_pci sdhci crc_ccitt ehci_hcd serio_raw e1000 
mmc_core nvram evdev usbcore parport_pc yenta_socket hwmon parport pcmcia_rsrc 
video usb_common pcmcia_core backlight ac battery acpi_cpufreq intel_agp 
processor button intel_gtt agpgart twofish_generic twofish_i586 twofish_common 
xts gf128mul dm_crypt dm_mod thermal
| [  142.000114] CPU: 0 PID: 3349 Comm: Xorg Not tainted 4.6.0-rc1+ #1
| [  142.000120] Hardware name: IBM 23716JG/23716JG, BIOS 1UETD3WW (2.08 ) 
12/21/2006
| [  142.000127]  c11b8f7a c1037247 f8dea59b c0051dc4 0d15 f8dda000 
11d8 f8d3ff2f
| [  142.000141]  f8d3ff2f 11d8 f3ef1dcc f3ef1e30 f3ef1dcc f3ef1dc0 
c1037309 0009
| [  142.000154]   c0051dac f8dea59b c0051dc4 f8d3ff2f f8dda000 
11d8 f8dea59b
| [  142.000168] Call Trace:
| [  142.000185]  [] ? dump_stack+0xa/0x20
| [  142.000197]  [] ? __warn+0xe7/0x100
| [  142.000269]  [] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000337]  [] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000347]  [] ? warn_slowpath_fmt+0x39/0x40
| [  142.000416]  [] ? i915_gem_free_object+0x25f/0x270 [i915]
| [  142.000452]  [] ? drm_gem_object_free+0x23/0x40 [drm]
| [  142.000478]  [] ? 
drm_gem_object_handle_unreference_unlocked+0xcf/0xe0 [drm]
| [  142.000504]  [] ? drm_gem_object_release_handle+0x47/0x90 [drm]
| [  142.000529]  [] ? drm_gem_handle_delete+0x4e/0x80 [drm]
| [  142.000554]  [] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000580]  [] ? drm_ioctl+0x230/0x570 [drm]
| [  142.000606]  [] ? drm_gem_handle_create+0x30/0x30 [drm]
| [  142.000618]  [] ? unmap_page_range+0x433/0x530
| [  142.000627]  [] ? __rb_erase_color+0xf3/0x250
| [  142.000637]  [] ? unlink_file_vma+0x36/0x70
| [  142.000645]  [] ? tlb_finish_mmu+0x9/0x30
| [  142.000671]  [] ? drm_ioctl_permit+0x80/0x80 [drm]
| [  142.000682]  [] ? do_vfs_ioctl+0x80/0x6a0
| [  142.000690]  [] ? timerqueue_del+0x20/0x70
| [  142.000699]  [] ? kmem_cache_free+0x95/0xa0
| [  142.000708]  [] ? remove_vma+0x3e/0x50
| [  142.000717]  [] ? do_munmap+0x219/0x2d0
| [  142.000726]  [] ? SyS_ioctl+0x43/0x80
| [  142.000735]  [] ? do_fast_syscall_32+0x82/0x110
| [  142.000745]  [] ? sysenter_past_esp+0x40/0x6a
| [  142.000777] ---[ end trace c0f77cdb5434 ]---

Each time an Xv window disappears from view--sometimes with slight
variations in the stacktrace. Do you need full debug info or a bunch more
stacktraces or is this enough to get an idea?

> > Also, I have occasional X se