[PATCH] drm/exynos: fix kernel panic issue at drm releasing

[Inki Dae]

+ Rob Clark,

Hi Daniel and Rob,

2016년 01월 05일 20:08에 Daniel Vetter 이(가) 쓴 글:
> On Tue, Jan 05, 2016 at 07:55:52PM +0900, Inki Dae wrote:
>> Hi Daniel,
>>
>> 2016년 01월 05일 05:24에 Daniel Stone 이(가) 쓴 글:
>>> Hi Inki,
>>>
>>> On 4 January 2016 at 12:57, Inki Dae  wrote:
 2015년 12월 24일 22:32에 Daniel Stone 이(가) 쓴 글:
> On 24 December 2015 at 09:10, Inki Dae  wrote:
>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>> +{
>> +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>> +   unsigned long flags;
>> +
>> +   spin_lock_irqsave(>dev->event_lock, flags);
>> +   exynos_crtc->event = NULL;
>> +   spin_unlock_irqrestore(>dev->event_lock, flags);
>> +}
>
> This will leak the event and event space; you should call
> event->base.destroy() here. With that fixed:

 Right. we don't use exynos specific page flip function anymore which 
 managed the event as a list so that the event objects can be freed by 
 postclose callback.
 Anyway, would it be better for event->base.destory() to be called between 
 spin lock/unlock?
>>>
>>> You must increment event->base.file_priv->event_space (see
>>> drm_atomic.c:destroy_vblank_event), as well as calling
>>
>> Reasonable to me. Seems other DRM drivers don't increment event_space.
>>
>>> event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
>>> yes.
>>
>> In addition, only event objects belonging to the request process should be 
>> destroyed.
> 
> Just random comment out of the far left field, but robclark had a bunch of
> patches to clean up all that event alloc/cleanup code a bit and extract it
> into core functions. Might be good to ping him on irc to figure out where
> that series is and whether you could take it over.

Good news. I'll try to ping him on irc.

To Rob,
Can you let me know where your bunch of patches are? I'd like to look into the 
patches. I'd planned to have pull request so that this patch can go to 4.4.
As you had already relevant patch set maybe, we would need to check whether my 
patch can be replaced with your patch set or there is any corner case.

Thanks,
Inki Dae

> 
> Cheers, Daniel
> 

[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors

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

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

Vedran Miletić  changed:

   What|Removed |Added

Summary|output to DVI-I is blank|Output to DVI-I (or DVI-D)
   ||is blank on Tonga (R9 285
   ||and 380X) with multiple
   ||monitors

--- Comment #8 from Vedran Miletić  ---
I am using XFX R9 380X: 01:00.0 VGA compatible controller [0300]: Advanced
Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition / R9
380X] [1002:6938] (rev f1)

This bug affects me as well. Interesting part is this: when I plug in just
DVI-I on boot, monitor works fine, and plugging DVI-D makes the monitor
connected to DVI-D blank. However, if I change monitor setup using e.g. GNOME
Displays, the DVI-I will turn blank and DVI-D will work. Disconnecting DVI-D
afterwards does not help, DVI-I remains blank.

I have three HDMI monitors, two of them are connected via DVI->HDMI adapters,
and I can do further testing if it could be helpful.

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

[Bug 103561] unable to handle kernel paging request with csgo in wine+nine, ttm_bo_del_from_lru

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

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

--- Comment #5 from Christoph Haag  ---
It's annoying because after this happens the GPU doesn't power off with runpm
anymore and requires a reboot.

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

[Intel-gfx] [PATCH] drm/i915: intel_hpd_init(): Don't check connectors for an encoder

[Daniel Vetter]

On Tue, Jan 05, 2016 at 09:05:49PM +0100, Daniel Vetter wrote:
> On Tue, Jan 05, 2016 at 02:53:08PM -0500, Lyude wrote:
> > There's no reason to check for an active encoder when setting up hpd,
> > especially since a disconnected connector isn't going to have an encoder
> > in the first place. This fixes reprobing display connectors on resume.
> > 
> > Signed-off-by: Lyude 
> > ---
> > After some talking with danvet on IRC, I learned that calling
> > drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
> > connector's status. It turns out this is the actual reason reprobing on 
> > resume
> > hasn't been working (this was observed on a T440s):
> > 
> > - We call hpd_init()
> > - We check each connector for a couple of things before marking
> >   connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
> >   active encoder. Of course, a disconnected port won't have an active
> >   encoder, so we don't add the flag to any of the connector's.
> > - We call drm_helper_hpd_irq_event()
> > - drm_helper_irq_event() checks each connector for the
> >   DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we
> >   skip reprobing each connector except that one.
> 
> The above explanation should be part of the commit message, otherwise it's
> hard to understand the impact of this fix.
> 
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: stable at vger.kernel.org
> 
> Unfortunately Dave doesn't explain in his MST commit why he's done this.
> Dave? I can't come up with a reason, but better to test that. Lyude?
> 
> Anyway looks good to me.
> 
> Reviewed-by: Daniel Vetter 

Need to retract my r-b. MST connectors don't have a fixed fake encoder,
and the intel_connector->encoder link is done at link time and not static.

We need to filter out MST connectors here, otherwise this will go boom.
While at it, can you please line-break this properly to appease
checkpatch?
-Daniel

> 
> > 
> >  drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> > b/drivers/gpu/drm/i915/intel_hotplug.c
> > index b177857..18797bc 100644
> > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > @@ -468,7 +468,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
> > list_for_each_entry(connector, _config->connector_list, head) {
> > struct intel_connector *intel_connector = 
> > to_intel_connector(connector);
> > connector->polled = intel_connector->polled;
> > -   if (connector->encoder && !connector->polled && 
> > I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
> > +   if (!connector->polled && I915_HAS_HOTPLUG(dev) && 
> > intel_connector->encoder->hpd_pin > HPD_NONE)
> > connector->polled = DRM_CONNECTOR_POLL_HPD;
> > if (intel_connector->mst_port)
> > connector->polled = DRM_CONNECTOR_POLL_HPD;
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

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

[Intel-gfx] [PATCH] drm/i915: intel_hpd_init(): Don't check connectors for an encoder

[Daniel Vetter]

On Tue, Jan 05, 2016 at 02:53:08PM -0500, Lyude wrote:
> There's no reason to check for an active encoder when setting up hpd,
> especially since a disconnected connector isn't going to have an encoder
> in the first place. This fixes reprobing display connectors on resume.
> 
> Signed-off-by: Lyude 
> ---
> After some talking with danvet on IRC, I learned that calling
> drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
> connector's status. It turns out this is the actual reason reprobing on resume
> hasn't been working (this was observed on a T440s):
> 
>   - We call hpd_init()
>   - We check each connector for a couple of things before marking
> connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
> active encoder. Of course, a disconnected port won't have an active
> encoder, so we don't add the flag to any of the connector's.
>   - We call drm_helper_hpd_irq_event()
>   - drm_helper_irq_event() checks each connector for the
> DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we
> skip reprobing each connector except that one.

The above explanation should be part of the commit message, otherwise it's
hard to understand the impact of this fix.

Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: stable at vger.kernel.org

Unfortunately Dave doesn't explain in his MST commit why he's done this.
Dave? I can't come up with a reason, but better to test that. Lyude?

Anyway looks good to me.

Reviewed-by: Daniel Vetter 

> 
>  drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index b177857..18797bc 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -468,7 +468,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
>   list_for_each_entry(connector, _config->connector_list, head) {
>   struct intel_connector *intel_connector = 
> to_intel_connector(connector);
>   connector->polled = intel_connector->polled;
> - if (connector->encoder && !connector->polled && 
> I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
> + if (!connector->polled && I915_HAS_HOTPLUG(dev) && 
> intel_connector->encoder->hpd_pin > HPD_NONE)
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
>   if (intel_connector->mst_port)
>   connector->polled = DRM_CONNECTOR_POLL_HPD;
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Cannot enforce DVI-I output with Nouveau driver with FX 5200

[Thomas Richter]

Hi folks,

there seems to be no method to enforce a specific output for the Nouveau 
kernel module and to override the auto-detection.

The problem here persists for two systems behind a KVM switch (an ATEN 
CS22D) that is not recognized as a valid monitor by the current 
auto-detection algorithm.

I tried the following:

*) Enforce a correct EDID even without a monitor connection by kernel 
parameters:

drm_kms_helper.edid_firmware=edid/edid.bin

The edid is validated correctly (with parse-edid) and stems from the 
monitor. I also validated (in the kernel log and by checking 
/sys/modules/drm-kms-helper/parameters/edid-firmware) that the edid was 
loaded.

Still, if the monitor is not connected at boot time, the frame buffer 
remains at 1024x768, and Xorg does not display anything at all.

The relevant section in xorg.conf is as follows:

Section "Device"
 Identifier  "NVIDIA"
 Driver  "nouveau"
#   BusID   "PCI:6:0:0"
 Option  "Monitor-DVI-I-1"   "SyncMaster"
EndSection

so I'm enforcing output on DVI-I-1, which is the name of the connection 
according to xrandr.

*) I also tried the "video" kernel parameter, namely "video=DVI-I-1:e". 
According to the kernel log, this force-enables the DVI-I-1 output (it 
was recognized correctly), but if I insert it into kernel command line, 
I get *no image at all* regardless whether I connect the monitor at boot 
time or not. Supposedly, it places the VGA console on the DVI-I-1 
output, and hence locks out the nouveau frame buffer.

This is a rather aged FX 5200 Nvidia card, which is no longer supported 
by the proprietary driver (which, otherwise, worked fine and included an 
option in xorg.conf to enforce the DVI-I-1 output).

The kernel is the longterm 4.1.15 support kernel - which otherwise works 
"fine enough" (3D acceleration is broken, i.e. etracer does not render 
at all, but that's a different problem).

Anything else I should try?

Greetings,
Thomas

[PATCH RFC 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Russell King - ARM Linux]

Some comments from an ARM architecture point of view.  I haven't
reviewed it from a DRM point of view yet.

On Tue, Jan 05, 2016 at 07:40:11PM +0100, Jean-Francois Moine wrote:
> +struct tcon {
> + u32 gctl;
> +#define  TCON_GCTL_TCON_En 0x8000
> + u32 gint0;
> +#define  TCON_GINT0_TCON1_Vb_Int_En 0x4000
> +#define  TCON_GINT0_TCON1_Vb_Int_Flag 0x1000
> + u32 gint1;
> + u32 dum0[13];
> + u32 tcon0_ctl;
> +#define  TCON0_CTL_TCON_En 0x8000
> + u32 dum1[19];
> + u32 tcon1_ctl;
> +#define  TCON1_CTL_TCON_En 0x8000
> +#define  TCON1_CTL_Interlace_En 0x0010
> +#define  TCON1_CTL_Start_Delay_SHIFT 4
> +#define  TCON1_CTL_Start_Delay_MASK 0x01f0
> + u32 basic0; /* XI/YI */
> + u32 basic1; /* LS_XO/LS_YO */
> + u32 basic2; /* XO/YO */
> + u32 basic3; /* HT/HBP */
> + u32 basic4; /* VT/VBP */
> + u32 basic5; /* HSPW/VSPW */
> + u32 dum2;
> + u32 ps_sync;
> + u32 dum3[15];
> + u32 io_pol;
> +#define  TCON1_IO_POL_IO0_inv 0x0100
> +#define  TCON1_IO_POL_IO1_inv 0x0200
> +#define  TCON1_IO_POL_IO2_inv 0x0400
> + u32 io_tri;
> + u32 dum4[2];
> +
> + u32 ceu_ctl;/* 100 */
> +#define TCON_CEU_CTL_ceu_en 0x8000
> + u32 dum5[3];
> + u32 ceu_rr;
> + u32 ceu_rg;
> + u32 ceu_rb;
> + u32 ceu_rc;
> + u32 ceu_gr;
> + u32 ceu_gg;
> + u32 ceu_gb;
> + u32 ceu_gc;
> + u32 ceu_br;
> + u32 ceu_bg;
> + u32 ceu_bb;
> + u32 ceu_bc;
> + u32 ceu_rv;
> + u32 ceu_gv;
> + u32 ceu_bv;
> + u32 dum6[45];
> +
> + u32 mux_ctl;/* 200 */
> +#define  TCON_MUX_CTL_HDMI_SRC_SHIFT 8
> +#define  TCON_MUX_CTL_HDMI_SRC_MASK 0x0300
> + u32 dum7[63];
> +
> + u32 fill_ctl;   /* 300 */
> + u32 fill_start0;
> + u32 fill_end0;
> + u32 fill_data0;
> +};

This sets off warnings bells for me...

> +static void de2_set_frame_timings(struct lcd *lcd)
> +{
> + struct drm_crtc *crtc = >crtc;
> + const struct drm_display_mode *mode = >mode;
> + struct tcon *p_tcon = lcd->mmio;
> + int interlace = mode->flags & DRM_MODE_FLAG_INTERLACE ? 2 : 1;
> + int start_delay;
> + u32 data;
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + data = XY(mode->hdisplay - 1, mode->vdisplay / interlace - 1);
> + p_tcon->basic0 = data;
> + p_tcon->basic1 = data;
> + p_tcon->basic2 = data;
> + p_tcon->basic3 = XY(mode->htotal - 1,
> + mode->htotal - mode->hsync_start - 1);
> + p_tcon->basic4 = XY(mode->vtotal * (3 - interlace),
> + mode->vtotal - mode->vsync_start - 1);
> + p_tcon->basic5 = XY(mode->hsync_end - mode->hsync_start - 1,
> + mode->vsync_end - mode->vsync_start - 1);
> +
> + p_tcon->ps_sync = XY(1, 1);
> +
> + data = TCON1_IO_POL_IO2_inv;
> + if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> + data |= TCON1_IO_POL_IO0_inv;
> + if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> + data |= TCON1_IO_POL_IO1_inv;
> + p_tcon->io_pol = data;
> +
> + p_tcon->ceu_ctl &= ~TCON_CEU_CTL_ceu_en;
> +
> + if (interlace == 2)
> + p_tcon->tcon1_ctl |= TCON1_CTL_Interlace_En;
> + else
> + p_tcon->tcon1_ctl &= ~TCON1_CTL_Interlace_En;
> +
> + p_tcon->fill_ctl = 0;
> + p_tcon->fill_start0 = mode->vtotal + 1;
> + p_tcon->fill_end0 = mode->vtotal;
> + p_tcon->fill_data0 = 0;
> +
> + start_delay = (mode->vtotal - mode->vdisplay) / interlace - 5;
> + if (start_delay > 31)
> + start_delay = 31;
> + p_tcon->tcon1_ctl &= ~TCON1_CTL_Start_Delay_MASK;
> + p_tcon->tcon1_ctl |= start_delay << TCON1_CTL_Start_Delay_SHIFT;

Here, the compiler might read tcon1_ctl, clear the bits, merge the
new bits in, and write them back.  Or it might decide to read,
clear bits, write back, set the new bits, and write back again.
What happens if start_delay were written as zero?

> +
> + p_tcon->io_tri = 0x0fff;

This whole thing even more so - the compiler is free to reorder
these accesses, merge them together, etc.  If the compiler decides
to inline this into callers, then it can merge these accesses with
accesses in the caller functions too.

This is why we have IO accessors; they prevent the compiler doing
these kinds of optimisations, and to ensure correctness, we have
sparse, and we mark MMIO memory with __iomem to prevent this kind
of programming mistake.

Please use sparse to check your work, and also use the IO accessors.

The same comments apply elsewhere.

> +}
> +
> +static void de2_crtc_enable(struct drm_crtc *crtc)
> +{
> + 

[PATCH RFC 0/2] Add a display driver to the Allwinner H3

[Jean-Francois Moine]

The proposed DRM driver works on a Orange PI 2 with a kernel 4.4-rc1
and the H3 patches found in Hans de Goede's GIT repository.

As there is no documentation about the DE2 nor about the HDMI which
are found in the H3, this driver has been built from Allwiiner's
sources.

So, there may be license problems, especially for the file
de2_hdmi_h3.c which contains a lot of magic values.

The associated DT and documentation will be submitted when the H3 DTs
will be in the kernel.

Jean-Francois Moine (2):
  clk: sunxi: Add sun8i display support
  drm: sunxi: Add a basic DRM driver for Allwinner DE2

 drivers/clk/sunxi/Makefile|   1 +
 drivers/clk/sunxi/clk-sun8i-display.c | 257 ++
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/sunxi/Kconfig |  21 ++
 drivers/gpu/drm/sunxi/Makefile|   8 +
 drivers/gpu/drm/sunxi/de2_crtc.c  | 409 +
 drivers/gpu/drm/sunxi/de2_crtc.h  |  42 +++
 drivers/gpu/drm/sunxi/de2_de.c| 467 +
 drivers/gpu/drm/sunxi/de2_drm.h   |  51 
 drivers/gpu/drm/sunxi/de2_drv.c   | 376 ++
 drivers/gpu/drm/sunxi/de2_hdmi.c  | 381 +++
 drivers/gpu/drm/sunxi/de2_hdmi.h  |  34 +++
 drivers/gpu/drm/sunxi/de2_hdmi_h3.c   | 478 ++
 drivers/gpu/drm/sunxi/de2_hdmi_h3.h   |  14 +
 drivers/gpu/drm/sunxi/de2_plane.c | 102 
 16 files changed, 2644 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-sun8i-display.c
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_h3.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_h3.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

-- 
2.6.4

[PATCH] drm/exynos: fix kernel panic issue at drm releasing

[Inki Dae]

Hi Daniel,

2016년 01월 05일 05:24에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 4 January 2016 at 12:57, Inki Dae  wrote:
>> 2015년 12월 24일 22:32에 Daniel Stone 이(가) 쓴 글:
>>> On 24 December 2015 at 09:10, Inki Dae  wrote:
 +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
 +{
 +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 +   unsigned long flags;
 +
 +   spin_lock_irqsave(>dev->event_lock, flags);
 +   exynos_crtc->event = NULL;
 +   spin_unlock_irqrestore(>dev->event_lock, flags);
 +}
>>>
>>> This will leak the event and event space; you should call
>>> event->base.destroy() here. With that fixed:
>>
>> Right. we don't use exynos specific page flip function anymore which managed 
>> the event as a list so that the event objects can be freed by postclose 
>> callback.
>> Anyway, would it be better for event->base.destory() to be called between 
>> spin lock/unlock?
> 
> You must increment event->base.file_priv->event_space (see
> drm_atomic.c:destroy_vblank_event), as well as calling

Reasonable to me. Seems other DRM drivers don't increment event_space.

> event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
> yes.

In addition, only event objects belonging to the request process should be 
destroyed.

Thanks,
Inki Dae

> 
> Cheers,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

[PATCH v2] drm/exynos: fix kernel panic issue at drm releasing

[Inki Dae]

This patch fixes a kernel panic issue which happened
when drm driver is closed while modetest.

This issue could be reproduced easily by launching modetest
with page flip repeatedly.

The reason is that invalid drm_file object could be accessed by
send_vblank_event function when finishing page flip if the drm_file
object was removed by drm_release and there was a pended page
flip event which was already committed to hardware.

So this patch makes the pended page flip event to be cancelled by
preclose callback which is called at front of drm_release function.

Changelog v2:
- free vblank event objects belonging to the request process,
  increment event space and decrease pending_update when cancelling
  the event

Signed-off-by: Inki Dae 
Reviewed-by: Daniel Stone 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 18 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |  4 
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  5 +
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index f3589a3..a3c2c71 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -238,3 +238,21 @@ void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
if (exynos_crtc->ops->te_handler)
exynos_crtc->ops->te_handler(exynos_crtc);
 }
+
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc,
+   struct drm_file *file)
+{
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+   struct drm_pending_vblank_event *e;
+   unsigned long flags;
+
+   spin_lock_irqsave(>dev->event_lock, flags);
+   e = exynos_crtc->event;
+   if (e && e->base.file_priv == file) {
+   exynos_crtc->event = NULL;
+   e->base.destroy(>base);
+   file->event_space += sizeof(e->event);
+   atomic_dec(_crtc->pending_update);
+   }
+   spin_unlock_irqrestore(>dev->event_lock, flags);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 6a581a8..cfdcf3e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -40,4 +40,8 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device 
*drm_dev,
  */
 void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);

+/* This function cancels a page flip request. */
+void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc,
+   struct drm_file *file);
+
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2c6019d..b9a9fd6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -369,7 +369,12 @@ err_file_priv_free:
 static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
 {
+   struct drm_crtc *crtc;
+
exynos_drm_subdrv_close(dev, file);
+
+   list_for_each_entry(crtc, >mode_config.crtc_list, head)
+   exynos_drm_crtc_cancel_page_flip(crtc, file);
 }

 static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-- 
1.9.1

[PATCH RFC 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2

[Jean-Francois Moine]

In recent SoCs, as the H3, Allwinner uses a new display interface, DE2.
This patch adds a DRM video driver for this interface,
and also a driver for the HDMI connector found in the H3.

Signed-off-by: Jean-Francois Moine 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/sunxi/Kconfig   |  21 ++
 drivers/gpu/drm/sunxi/Makefile  |   8 +
 drivers/gpu/drm/sunxi/de2_crtc.c| 409 ++
 drivers/gpu/drm/sunxi/de2_crtc.h|  42 
 drivers/gpu/drm/sunxi/de2_de.c  | 467 +++
 drivers/gpu/drm/sunxi/de2_drm.h |  51 
 drivers/gpu/drm/sunxi/de2_drv.c | 376 
 drivers/gpu/drm/sunxi/de2_hdmi.c| 381 
 drivers/gpu/drm/sunxi/de2_hdmi.h|  34 +++
 drivers/gpu/drm/sunxi/de2_hdmi_h3.c | 478 
 drivers/gpu/drm/sunxi/de2_hdmi_h3.h |  14 ++
 drivers/gpu/drm/sunxi/de2_plane.c   | 102 
 14 files changed, 2386 insertions(+)
 create mode 100644 drivers/gpu/drm/sunxi/Kconfig
 create mode 100644 drivers/gpu/drm/sunxi/Makefile
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_de.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_drm.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_drv.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_h3.c
 create mode 100644 drivers/gpu/drm/sunxi/de2_hdmi_h3.h
 create mode 100644 drivers/gpu/drm/sunxi/de2_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1..edef0c8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
 source "drivers/gpu/drm/imx/Kconfig"

 source "drivers/gpu/drm/vc4/Kconfig"
+
+source "drivers/gpu/drm/sunxi/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c..597c246 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -75,3 +75,4 @@ obj-y += i2c/
 obj-y  += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
+obj-$(CONFIG_DRM_SUNXI) += sunxi/
diff --git a/drivers/gpu/drm/sunxi/Kconfig b/drivers/gpu/drm/sunxi/Kconfig
new file mode 100644
index 000..9b4d414
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Kconfig
@@ -0,0 +1,21 @@
+#
+# Allwinner Video configuration
+#
+
+config DRM_SUNXI
+   tristate "DRM Support for Allwinner Video"
+   depends on DRM && ARCH_SUNXI
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   help
+ Choose this option if you have a Allwinner chipset.
+
+config DRM_SUNXI_DE2
+   tristate "Support for Allwinner Video with DE2 interface"
+   depends on DRM_SUNXI && MACH_SUN8I
+   select REGMAP_MMIO
+   help
+ Choose this option if your Allwinner chipset has the DE2 interface
+ as the H3.
diff --git a/drivers/gpu/drm/sunxi/Makefile b/drivers/gpu/drm/sunxi/Makefile
new file mode 100644
index 000..8bb533f
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for Allwinner's DRM device driver
+#
+
+sunxi-de2-drm-objs := de2_drv.o de2_de.o de2_crtc.o de2_plane.o
+sunxi-de2-hdmi-objs := de2_hdmi.o de2_hdmi_h3.o
+
+obj-$(CONFIG_DRM_SUNXI_DE2) += sunxi-de2-drm.o sunxi-de2-hdmi.o
diff --git a/drivers/gpu/drm/sunxi/de2_crtc.c b/drivers/gpu/drm/sunxi/de2_crtc.c
new file mode 100644
index 000..92c20d0
--- /dev/null
+++ b/drivers/gpu/drm/sunxi/de2_crtc.c
@@ -0,0 +1,409 @@
+/*
+ * Allwinner DRM driver - DE2 CRTC
+ *
+ * Copyright (C) 2016 Jean-Francois Moine 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+
+#include "de2_drm.h"
+#include "de2_crtc.h"
+
+/* I/O map */
+
+struct tcon {
+   u32 gctl;
+#defineTCON_GCTL_TCON_En 0x8000
+   u32 gint0;
+#defineTCON_GINT0_TCON1_Vb_Int_En 0x4000
+#defineTCON_GINT0_TCON1_Vb_Int_Flag 0x1000
+   u32 gint1;
+   u32 dum0[13];
+   u32 tcon0_ctl;
+#defineTCON0_CTL_TCON_En 0x8000
+   u32 dum1[19];
+   u32 tcon1_ctl;
+#defineTCON1_CTL_TCON_En 0x8000
+#defineTCON1_CTL_Interlace_En 0x0010
+#defineTCON1_CTL_Start_Delay_SHIFT 4
+#defineTCON1_CTL_Start_Delay_MASK 0x01f0
+   u32 basic0; /* XI/YI */
+   u32 basic1; /* LS_XO/LS_YO */
+   u32 

[PATCH RFC 1/2] clk: sunxi: Add sun8i display support

[Jean-Francois Moine]

Add the clock types which are used by the sun8i family for video.

Signed-off-by: Jean-Francois Moine 
---
 drivers/clk/sunxi/Makefile|   1 +
 drivers/clk/sunxi/clk-sun8i-display.c | 247 ++
 2 files changed, 258 insertions(+)
 create mode 100644 drivers/clk/sunxi/clk-sun8i-display.c

diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index cb4c299..145c078 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,6 +10,7 @@ obj-y += clk-a10-pll2.o
 obj-y += clk-a20-gmac.o
 obj-y += clk-mod0.o
 obj-y += clk-simple-gates.o
+obj-y += clk-sun8i-display.o
 obj-y += clk-sun8i-mbus.o
 obj-y += clk-sun9i-core.o
 obj-y += clk-sun9i-mmc.o
diff --git a/drivers/clk/sunxi/clk-sun8i-display.c 
b/drivers/clk/sunxi/clk-sun8i-display.c
new file mode 100644
index 000..eded572
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun8i-display.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright 2015 Jean-Francois Moine 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_SPINLOCK(sun8i_display_lock);
+
+/* PLL3 (video) and PLL10 (de) */
+struct clk_fact {
+   struct clk_hw hw;
+   void __iomem *reg;
+};
+#define to_clk_fact(_hw) container_of(_hw, struct clk_fact, hw)
+
+#define SUN8I_PLL3_MSHIFT  0
+#define SUN8I_PLL3_MMASK   0x0f
+#define SUN8I_PLL3_NSHIFT  8
+#define SUN8I_PLL3_NMASK   0x7f
+#define SUN8I_PLL3_MODE_SEL0x0100
+#define SUN8I_PLL3_FRAC_CLK0x0200
+
+static int sun8i_pll3_get_fact(unsigned long rate,
+   unsigned long parent_rate,
+   unsigned long *n, unsigned long *m)
+{
+   if (rate == 29700)
+   return 1;
+   if (rate == 27000)
+   return 0;
+   rational_best_approximation(rate, parent_rate,
+   SUN8I_PLL3_NMASK + 1, SUN8I_PLL3_MMASK + 1,
+   n, m);
+   return -1;
+}
+
+static unsigned long sun8i_pll3_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct clk_fact *fact = to_clk_fact(hw);
+   u32 reg;
+   u32 n, m;
+
+   reg = readl(fact->reg);
+   if (reg & SUN8I_PLL3_MODE_SEL) {
+   n = (reg >> SUN8I_PLL3_NSHIFT) & SUN8I_PLL3_NMASK;
+   m = (reg >> SUN8I_PLL3_MSHIFT) & SUN8I_PLL3_MMASK;
+   return parent_rate / (m + 1) * (n + 1);
+   }
+   if (reg & SUN8I_PLL3_FRAC_CLK)
+   return 29700;
+   return 27000;
+}
+
+static long sun8i_pll3_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *parent_rate)
+{
+   int frac;
+   unsigned long n, m;
+
+   frac = sun8i_pll3_get_fact(rate, *parent_rate, , );
+   if (frac == 1)
+   return 29700;
+   if (frac == 0)
+   return 27000;
+   return (*parent_rate * n) / m;
+}
+
+static int sun8i_pll3_set_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long parent_rate)
+{
+   struct clk_fact *fact = to_clk_fact(hw);
+   u32 reg;
+   int frac;
+   unsigned long n, m;
+
+   reg = readl(fact->reg) &
+   ~(SUN8I_PLL3_MODE_SEL |
+ SUN8I_PLL3_FRAC_CLK |
+ (SUN8I_PLL3_NMASK << SUN8I_PLL3_NSHIFT) |
+ (SUN8I_PLL3_MMASK << SUN8I_PLL3_MSHIFT));
+
+   frac = sun8i_pll3_get_fact(rate, parent_rate, , );
+   if (frac == 1)
+   reg |= SUN8I_PLL3_FRAC_CLK; /* 297MHz */
+   else if (frac == 0)
+   ;   /* 270MHz */
+   else
+   reg |= SUN8I_PLL3_MODE_SEL |
+   ((n - 1) << SUN8I_PLL3_NSHIFT) |
+   ((m - 1) << SUN8I_PLL3_MSHIFT);
+
+   writel(reg, fact->reg);
+
+   /* delay 500us so pll stabilizes */
+   __delay(500);
+
+   return 0;
+}
+
+static const struct clk_ops clk_sun8i_pll3_fact_ops = {
+   .recalc_rate = sun8i_pll3_recalc_rate,
+   .round_rate = sun8i_pll3_round_rate,
+   .set_rate = sun8i_pll3_set_rate,
+};
+
+static void __init sun8i_pll3_setup(struct device_node *node)
+{
+   const char *clk_name = node->name, *parent;
+   struct clk_fact *fact;
+   struct clk_gate *gate;
+   void __iomem *reg;
+   struct clk *clk;
+
+   of_property_read_string(node, 

[PATCH 0/8] Add ASoC support for AMD APUs [v6]

[Mark Brown]

On Wed, Dec 23, 2015 at 02:01:08PM -0500, Alex Deucher wrote:

> for the i2s codec.  Since the alsa changes depend on the drm changes,
> I'd like to take the alsa patches in via the drm tree.

If the ALSA changes depend on the DRM changes I'd expect to see
something in Kconfig otherwise I'd expect we'll see either build or link
failures?  Or is the dependency runtime only (in which case there's no
need to worry about it for applying the patches)?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/11b339de/attachment.sig>

[PATCH 8/8] ASoC: AMD: Manage ACP 2.x SRAM banks power

[Mark Brown]

On Wed, Dec 23, 2015 at 02:01:15PM -0500, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu 
> 
> ACP SRAM banks gets turned on when ACP is powered on.
> Not all banks are used for playback/capture. So, power on
> required banks during audio device open and power off during
> audio device close.

This looks good.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/093db8db/attachment.sig>

[PATCH 7/8] ASoC: AMD: add pm ops

[Mark Brown]

On Wed, Dec 23, 2015 at 02:01:14PM -0500, Alex Deucher wrote:

> + stream = adata->play_stream;
> + rtd = stream ? stream->runtime : NULL;
> + if (rtd != NULL) {
> + /* Resume playback stream from a suspended state */
> + sdata = rtd->private_data;
> + config_acp_dma(adata->acp_mmio, sdata);
> + }

Please don't use the ternery operator like this, it's not bad to write
if statements and they're much more legible.  I was having to think far
too much about the various variables and if we were safely handling all
of them before I realised the next block overwrites them all anyway.
This is really

stream = adata->play_stream;
if (stream && stream->rtd)
config_acp_dma(adata->acp_mmio, stream->rtd->private_data);

or a couple of nested if statements.  Otherwise this patch looks OK.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/8f2e15d4/attachment-0001.sig>

[PATCH 6/8] ASoC: AMD: add AMD ASoC ACP 2.x DMA driver

[Mark Brown]

On Tue, Jan 05, 2016 at 06:43:43PM +, Mark Brown wrote:
> On Wed, Dec 23, 2015 at 02:01:13PM -0500, Alex Deucher wrote:

> > +#include "include/acp_2_2_d.h"
> > +#include "include/acp_2_2_sh_mask.h"

> I can't find these headers anywhere in the kernel tree or earlier in
> this patch series, this will break the build.  The fact that they've got
> include in the filename is also a bit interesting...

Ugh, your cover letter says (after pages of changelog) that they're in a
patch 5 which you didn't send :(  Please don't do this, I can't apply or
review code that isn't sent to me.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/9e3a8f5f/attachment.sig>

[PATCH 6/8] ASoC: AMD: add AMD ASoC ACP 2.x DMA driver

[Mark Brown]

On Wed, Dec 23, 2015 at 02:01:13PM -0500, Alex Deucher wrote:

> --- /dev/null
> +++ b/sound/soc/amd/Kconfig
> @@ -0,0 +1,4 @@
> +config SND_SOC_AMD_ACP
> + tristate "AMD Audio Coprocessor support"
> + help
> +  This option enables ACP DMA support on AMD platform.

This has no dependencies?

> +
> + /* Designware I2S driver requries proper capabilities
> +  * from mmACP_I2SMICSP_COMP_PARAM_1 register. The register
> +  * reports playback and capture capabilities though the
> +  * MIC instance of DW I2S controller supports capture only
> +  * Provide a workaround by masking the capability into a
> +  * scratch register and provide scratch register offset as
> +  * though it is mmACP_I2SMICSP_COMP_PARAM_1
> +  */
> +
> + val = acp_reg_read(acp_mmio, mmACP_I2SMICSP_COMP_PARAM_1);
> + val = val & ~BIT(5);
> + acp_reg_write(val, acp_mmio, mmACP_SCRATCH_REG_0);

Ugh, right.  So the hardware doesn't actually have the register moved at
all.  Why are we doing this, if the capabilities really are buggy the
more idiomatic thing would be to provide an override for the
capabilities via platform data?  Requiring some other driver to poke the
hardware to set the capabilities is a very roundabout way to deal with
things.

We should probably revert that quirk unless I'm missing something here...

> +++ b/sound/soc/amd/acp.h
> @@ -0,0 +1,119 @@
> +#ifndef __ACP_HW_H
> +#define __ACP_HW_H
> +
> +#include "include/acp_2_2_d.h"
> +#include "include/acp_2_2_sh_mask.h"

I can't find these headers anywhere in the kernel tree or earlier in
this patch series, this will break the build.  The fact that they've got
include in the filename is also a bit interesting...

> +#define PAGE_SIZE_4K 4096

SZ_4K exists for this.

> +#define PAGE_SIZE_4K_ENABLE  0x02
> +
> +#define PLAYBACK_PTE_OFFSET  10
> +#define CAPTURE_PTE_OFFSET   0

These defines could all use namespacing, as could some of the others
later than don't mention ACP.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/7d216c85/attachment.sig>

[PATCH] gpu: ipu-v3: Do not bail out on missing optional port nodes

[Philipp Zabel]

The port nodes are documented as optional, treat them accordingly.

Reported-by: Martin Fuzzey 
Signed-off-by: Philipp Zabel 
Fixes: 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to 
corresponding ports")
---
 drivers/gpu/ipu-v3/ipu-common.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index f2e13eb..8b248c6 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1062,10 +1062,11 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
/* Associate subdevice with the corresponding port node */
pdev->dev.of_node = of_graph_get_port_by_id(dev->of_node, i);
if (!pdev->dev.of_node) {
-   dev_err(dev, "missing port@%d node in %s\n", i,
-   dev->of_node->full_name);
-   ret = -ENODEV;
-   goto err_register;
+   dev_info(dev,
+"no port@%d node in %s, not using %s%d\n",
+i, dev->of_node->full_name,
+(i / 2) ? "DI" : "CSI", i % 2);
+   continue;
}

ret = platform_device_add_data(pdev, >pdata,
-- 
2.6.4

[Bug 93144] [radeonsi] Alien: Isolation feature request

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

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

Stepan Bakshaev <step2back+freedesktop at gmail.com> changed:

   What|Removed |Added

Summary|[radeonsi] Alien: Isolation |[radeonsi] Alien: Isolation
   |bug |feature request

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

[PATCH 27/29] drm/vgem: Move get_pages to gem_create

[poma]

On 23.11.2015 10:33, Daniel Vetter wrote:
> vgem doesn't have a shrinker or anything like that and drops backing
> storage only at object_free time. There's no use in trying to be
> clever and allocating backing storage delayed, it only causes trouble
> by requiring locking.
> 
> Instead grab pages when we allocate the object right away.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 63026d4324ad..1a609347236b 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -154,6 +154,10 @@ static struct drm_gem_object *vgem_gem_create(struct 
> drm_device *dev,
>   if (err)
>   goto out;
>  
> + ret = vgem_gem_get_pages(to_vgem_bo(obj));
> + if (ret)
> + goto out;
> +
>   err = drm_gem_handle_create(file, gem_object, handle);
>   if (err)
>   goto handle_out;
> @@ -216,16 +220,8 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
> drm_device *dev,
>  
>   obj->filp->private_data = obj;
>  
> - ret = vgem_gem_get_pages(to_vgem_bo(obj));
> - if (ret)
> - goto fail_get_pages;
> -
>   *offset = drm_vma_node_offset_addr(>vma_node);
>  
> - goto unref;
> -
> -fail_get_pages:
> - drm_gem_free_mmap_offset(obj);
>  unref:
>   drm_gem_object_unreference(obj);
>  unlock:
> 


drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_fault':
drivers/gpu/drm/vgem/vgem_drv.c:92:21: warning: unused variable 'dev' 
[-Wunused-variable]
  struct drm_device *dev = obj->base.dev;
 ^
drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_create':
drivers/gpu/drm/vgem/vgem_drv.c:153:2: error: 'ret' undeclared (first use in 
this function)
  ret = vgem_gem_get_pages(to_vgem_bo(obj));
  ^
drivers/gpu/drm/vgem/vgem_drv.c:153:2: note: each undeclared identifier is 
reported only once for each function it appears in
In file included from include/linux/list.h:8:0,
 from include/linux/module.h:9,
 from drivers/gpu/drm/vgem/vgem_drv.c:33:
include/linux/kernel.h:813:48: warning: initialization from incompatible 
pointer type [-Wincompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/gpu/drm/vgem/vgem_drv.h:35:23: note: in expansion of macro 
'container_of'
 #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
   ^
drivers/gpu/drm/vgem/vgem_drv.c:153:27: note: in expansion of macro 'to_vgem_bo'
  ret = vgem_gem_get_pages(to_vgem_bo(obj));
   ^

This breaks the build, therefore "armada" batch cannot be tested entirely.

WARNING: CPU: 3 PID: 914 at include/drm/drm_gem.h:146 udl_dumb_create+0xdd/0xf0 [udl]()

[poma]

On 05.01.2016 09:49, Daniel Vetter wrote:
> On Tue, Jan 05, 2016 at 08:46:19AM +0100, poma wrote:
>>
>> Hi Fi
>>
>> Please take a loo kat
>> https://bugzilla.redhat.com/show_bug.cgi?id=1295646
> 
> Patches to fix these have been hanging around on the list for weeks,
> looking for review ... The entire series starts with "drm/armada: Use
> unlocked gem unreferencing". Care to review them all?
> 
> Thanks, Daniel
> 

https://patchwork.freedesktop.org/project/intel-gfx/patches/?page=9

"armada" batch for udl builds and works OK.

Tested-by: poma 

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

[Jean-Michel Hautbois]

Hi Russell,

2015-08-27 10:42 GMT+02:00 Philipp Zabel :
>
> Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM
> Linux:
> > Following on from the previous sub-series, this sub-series adds audio
> > support to dw-hdmi.
> >
> > The two different variants are now in this patch: AHB audio support
> > found on iMX6 platforms, and I2S support found on Rockchip patches.
> > Thanks to Yakir Yang for contributing the I2S support.
> >
> > I suspect that there is still some discussion to be had on this
> > series, though I would like to see it moving forward so that we can
> > get something merged.
>
> Tested-by: Philipp Zabel 
> on i.MX6 GK802 via HDMI connected to a TV (stereo only).
>
> except for the i2s patch, which is broken in this series.
>
> regards
> Philipp


What is the status of this series ?
I would like to use audio output in HDMI on my i.MX6 board, but I
don't know if you have some pending WIP on this ?

Thanks,
JM

[PATCH 1/3] drm/ttm: add ttm_bo_move_to_lru_tail function

[Alex Deucher]

On Tue, Jan 5, 2016 at 7:16 AM, Christian König  
wrote:
> From: Christian König 
>
> This allows the drivers to move a BO to the end of the LRU
> without removing and adding it again.
>
> Signed-off-by: Christian König 
> Reviewed-by: Chunming Zhou 

This series is:
Reviewed-by: Alex Deucher 

Unless there are any objections to the ttm patch, I'd like to pull
this series into my drm-next tree.

Alex

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 20 
>  include/drm/ttm/ttm_bo_api.h | 10 ++
>  2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 745e996..9e91cc3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -228,6 +228,26 @@ void ttm_bo_del_sub_from_lru(struct ttm_buffer_object 
> *bo)
>  }
>  EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);
>
> +void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
> +{
> +   struct ttm_bo_device *bdev = bo->bdev;
> +   struct ttm_mem_type_manager *man;
> +
> +   lockdep_assert_held(>resv->lock.base);
> +
> +   if (!list_empty(>swap)) {
> +   list_del(>swap);
> +   list_add_tail(>swap, >glob->swap_lru);
> +   }
> +
> +   if (!list_empty(>lru)) {
> +   man = >man[bo->mem.mem_type];
> +   list_del(>lru);
> +   list_add_tail(>lru, >lru);
> +   }
> +}
> +EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
> +
>  /*
>   * Call bo->mutex locked.
>   */
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index c768ddf..afae231 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -383,6 +383,16 @@ extern void ttm_bo_add_to_lru(struct ttm_buffer_object 
> *bo);
>   */
>  extern int ttm_bo_del_from_lru(struct ttm_buffer_object *bo);
>
> +/**
> + * ttm_bo_move_to_lru_tail
> + *
> + * @bo: The buffer object.
> + *
> + * Move this BO to the tail of all lru lists used to lookup and reserve an
> + * object. This function must be called with struct ttm_bo_global::lru_lock
> + * held, and is used to make a BO less likely to be considered for eviction.
> + */
> +extern void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo);
>
>  /**
>   * ttm_bo_lock_delayed_workqueue
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Daniel Vetter]

On Tue, Jan 05, 2016 at 04:22:15PM +0100, Daniel Vetter wrote:
> Another pile of vfuncs from the old gpu.tmpl xml documentation that
> I've forgotten to delete. I spotted a few more things to
> clarify/extend in the new kerneldoc while going through this once
> more.
> 
> v2: Spelling fixes (Thierry).
> 
> v3: More spelling fixes and use Thierry's proposal to clarify why
> drivers need to validate modes both in ->mode_fixup and ->mode_valid.
> 
> Cc: Laurent Pinchart 
> Cc: Thierry Reding 
> Acked-by: Thierry Reding 
> Signed-off-by: Daniel Vetter 

... and pulled into drm-misc.
-Daniel

> ---
>  Documentation/DocBook/gpu.tmpl   | 188 
> ---
>  include/drm/drm_modeset_helper_vtables.h |  44 +++-
>  2 files changed, 41 insertions(+), 191 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 225a246c5f53..faa5e0d4208d 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
>entities.
>  
>  
> -  Legacy CRTC Helper Operations
> -  
> -
> -  bool (*mode_fixup)(struct drm_crtc *crtc,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode);
> -  
> -Let CRTCs adjust the requested mode or reject it completely. This
> -operation returns true if the mode is accepted (possibly after 
> being
> -adjusted) or false if it is rejected.
> -  
> -  
> -The mode_fixup operation should reject 
> the
> -mode if it can't reasonably use it. The definition of 
> "reasonable"
> -is currently fuzzy in this context. One possible behaviour would 
> be
> -to set the adjusted mode to the panel timings when a fixed-mode
> -panel is used with hardware capable of scaling. Another behaviour
> -would be to accept any input mode and adjust it to the closest 
> mode
> -supported by the hardware (FIXME: This needs to be clarified).
> -  
> -
> -
> -  int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
> - struct drm_framebuffer *old_fb)
> -  
> -Move the CRTC on the current frame buffer (stored in
> -crtc-fb) to position (x,y). Any of the 
> frame
> -buffer, x position or y position may have been modified.
> -  
> -  
> -This helper operation is optional. If not provided, the
> -drm_crtc_helper_set_config function will 
> fall
> -back to the mode_set helper operation.
> -  
> -  
> -FIXME: Why are x and y passed as arguments, as they can be 
> accessed
> -through crtc-x and
> -crtc-y?
> -  
> -
> -
> -  void (*prepare)(struct drm_crtc *crtc);
> -  
> -Prepare the CRTC for mode setting. This operation is called after
> -validating the requested mode. Drivers use it to perform
> -device-specific operations required before setting the new mode.
> -  
> -
> -
> -  int (*mode_set)(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode, int x, int y,
> -struct drm_framebuffer *old_fb);
> -  
> -Set a new mode, position and frame buffer. Depending on the 
> device
> -requirements, the mode can be stored internally by the driver and
> -applied in the commit operation, or
> -programmed to the hardware immediately.
> -  
> -  
> -The mode_set operation returns 0 on 
> success
> - or a negative error code if an error occurs.
> -  
> -
> -
> -  void (*commit)(struct drm_crtc *crtc);
> -  
> -Commit a mode. This operation is called after setting the new 
> mode.
> -Upon return the device must use the new mode and be fully
> -operational.
> -  
> -
> -  
> -
> -
> -  Encoder Helper Operations
> -  
> -
> -  bool (*mode_fixup)(struct drm_encoder *encoder,
> -   const struct drm_display_mode *mode,
> -   struct drm_display_mode *adjusted_mode);
> -  
> -Let encoders adjust the requested mode or reject it completely. 
> This
> -operation returns true if the mode is accepted (possibly after 
> being
> -adjusted) or false if it is rejected. See the
> -mode_fixup CRTC helper
> -operation for an explanation of the allowed adjustments.
> -  
> -
> -
> -  void (*prepare)(struct drm_encoder 

[PATCH 2/2] drm: Remove opencoded drm_gem_object_release_handle()

[Daniel Vetter]

On Tue, Jan 05, 2016 at 04:15:46PM +0100, Thierry Reding wrote:
> On Tue, Jan 05, 2016 at 09:42:31AM +, Chris Wilson wrote:
> > drm_gem_handle_delete() contains its own version of
> > drm_gem_object_release_handle(), so lets just call the release method
> > instead.
> > 
> > Reported-by: Ville Syrjälä 
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_gem.c | 55 
> > +--
> >  1 file changed, 24 insertions(+), 31 deletions(-)
> 
> Reviewed-by: Thierry Reding 

Both applied to drm-misc, thanks for patches
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Daniel Vetter]

Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.

v2: Spelling fixes (Thierry).

v3: More spelling fixes and use Thierry's proposal to clarify why
drivers need to validate modes both in ->mode_fixup and ->mode_valid.

Cc: Laurent Pinchart 
Cc: Thierry Reding 
Acked-by: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl   | 188 ---
 include/drm/drm_modeset_helper_vtables.h |  44 +++-
 2 files changed, 41 insertions(+), 191 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 225a246c5f53..faa5e0d4208d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
   entities.
 
 
-  Legacy CRTC Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let CRTCs adjust the requested mode or reject it completely. This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected.
-  
-  
-The mode_fixup operation should reject the
-mode if it can't reasonably use it. The definition of "reasonable"
-is currently fuzzy in this context. One possible behaviour would be
-to set the adjusted mode to the panel timings when a fixed-mode
-panel is used with hardware capable of scaling. Another behaviour
-would be to accept any input mode and adjust it to the closest mode
-supported by the hardware (FIXME: This needs to be clarified).
-  
-
-
-  int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
-  
-Move the CRTC on the current frame buffer (stored in
-crtc-fb) to position (x,y). Any of the frame
-buffer, x position or y position may have been modified.
-  
-  
-This helper operation is optional. If not provided, the
-drm_crtc_helper_set_config function will fall
-back to the mode_set helper operation.
-  
-  
-FIXME: Why are x and y passed as arguments, as they can be accessed
-through crtc-x and
-crtc-y?
-  
-
-
-  void (*prepare)(struct drm_crtc *crtc);
-  
-Prepare the CRTC for mode setting. This operation is called after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  int (*mode_set)(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode, int x, int y,
-struct drm_framebuffer *old_fb);
-  
-Set a new mode, position and frame buffer. Depending on the device
-requirements, the mode can be stored internally by the driver and
-applied in the commit operation, or
-programmed to the hardware immediately.
-  
-  
-The mode_set operation returns 0 on 
success
-   or a negative error code if an error occurs.
-  
-
-
-  void (*commit)(struct drm_crtc *crtc);
-  
-Commit a mode. This operation is called after setting the new mode.
-Upon return the device must use the new mode and be fully
-operational.
-  
-
-  
-
-
-  Encoder Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let encoders adjust the requested mode or reject it completely. 
This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected. See the
-mode_fixup CRTC helper
-operation for an explanation of the allowed adjustments.
-  
-
-
-  void (*prepare)(struct drm_encoder *encoder);
-  
-Prepare the encoder for mode setting. This operation is called 
after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  void (*mode_set)(struct drm_encoder *encoder,
- struct 

[PATCH v2] drm/i915: intel_hpd_init(): Fix suspend/resume reprobing

[Lyude]

This fixes reprobing of display connectors on resume. After some talking
with danvet on IRC, I learned that calling drm_helper_hpd_irq_event() does
actually trigger a full reprobe of each connector's status. It turns out
this is the actual reason reprobing on resume hasn't been working (this was
observed on a T440s):

- We call hpd_init()
- We check each connector for a couple of things before marking
  connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
  active encoder. Of course, a disconnected port won't have an
  active encoder, so we don't add the flag to any of the
  connectors.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
  DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1,
  so we skip reprobing each connector except for that one.

In addition, we now avoid setting connector->polled to
DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is handled
by the mst helpers. This is probably what was originally intended to happen
here anyway.

Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: stable at vger.kernel.org
Signed-off-by: Lyude 
---
Changes
* Use the explanation of the issue as the commit message instead
* Change the title of the commit, since this does more then just stop a check
  for an encoder now
* Add "Fixes" line for the patch that introduced this regression
* Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors

 drivers/gpu/drm/i915/intel_hotplug.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index b177857..51ecf0b4 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -468,9 +468,9 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
list_for_each_entry(connector, _config->connector_list, head) {
struct intel_connector *intel_connector = 
to_intel_connector(connector);
connector->polled = intel_connector->polled;
-   if (connector->encoder && !connector->polled && 
I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
-   if (intel_connector->mst_port)
+   if (!connector->polled && !intel_connector->mst_port &&
+   I915_HAS_HOTPLUG(dev) &&
+   intel_connector->encoder->hpd_pin > HPD_NONE)
connector->polled = DRM_CONNECTOR_POLL_HPD;
}

-- 
2.5.0

[PATCH 1/2] drm: Do not set outparam on error during GEM handle allocation

[Thierry Reding]

On Tue, Jan 05, 2016 at 09:42:30AM +, Chris Wilson wrote:
> Good practice dictates that we do not leak stale information to our
> callers, and should avoid overwriting an outparam on an error path.
> 
> Reported-by: Ville Syrjälä 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_gem.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/9f1f5b5e/attachment-0001.sig>

[PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Thierry Reding]

> > can't support? Also looking at drm_helper_probe_single_connector_modes()
> > this isn't quite true. That helper is used by all connectors except
> > vmwgfx. It also calls drm_mode_prune_invalid(), which will remove all
> > modes from the connector's mode list that don't have status == MODE_OK.
> > As far as I can see after they've been removed from the connector's mode
> > list they will no longer be exposed to userspace.
> 
> Maybe I need to hammer this in more, but it's a common misconception that
> userspace can only ask for modes in the connector list. Generally that's
> what's happening, but there's not restrictions on userspace to ask for a
> mode which is _not_ in the connector's mode list.
> 
> If you don't believe that, look at xrandr --addmode and try yourself.
> 
> That's why drivers MUST filter modes in both mode_valid and mode_fixup.
> Any suggestions for how to make this even more clear?

Currently that's not very explicit in the text, since it only suggests
that modes aren't filtered out. It doesn't say anything about the
possibility of modes being manually added by userspace. How about
something along these lines:

While the list of modes that is advertised to userspace is filtered
using the connector's ->mode_valid() callback, neither the core nor
the helpers do any filtering on modes passed in from userspace when
setting a mode. It is therefore possible for userspace to pass in a
mode that was previously filtered out using ->mode_valid() or add a
custom mode that wasn't probed from EDID or similar to begin with.
Even though this is an advanced feature and rarely used nowadays,
some users rely on being able to specify modes manually so drivers
must be prepared to deal with it. Specifically this means that all
drivers need not only validate modes in ->mode_valid() but also in
    ->mode_fixup() to make sure invalid modes passed in from userspace
are rejected.

> Aside, I tried looking into untangling this a bit with a helper to
> implement mode_valid in terms of mode_fixup (by just passing a dummy
> adjusted_mode in). But figuring out which encoder/crtc to take (in
> general) stopped that idea. Maybe we just need to iterate over all
> possible configurations. The other problem was that mode_fixup was allowed
> to change software state in legacy drivers, but atomic fixed that.

Yeah, it sounds fine to me to keep this as-is, as long as everybody is
clear on how it works.

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

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

[Russell King - ARM Linux]

On Tue, Jan 05, 2016 at 04:40:54PM +0100, Jean-Michel Hautbois wrote:
> Hi Russell,
> 
> 2015-08-27 10:42 GMT+02:00 Philipp Zabel :
> >
> > Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM
> > Linux:
> > > Following on from the previous sub-series, this sub-series adds audio
> > > support to dw-hdmi.
> > >
> > > The two different variants are now in this patch: AHB audio support
> > > found on iMX6 platforms, and I2S support found on Rockchip patches.
> > > Thanks to Yakir Yang for contributing the I2S support.
> > >
> > > I suspect that there is still some discussion to be had on this
> > > series, though I would like to see it moving forward so that we can
> > > get something merged.
> >
> > Tested-by: Philipp Zabel 
> > on i.MX6 GK802 via HDMI connected to a TV (stereo only).
> >
> > except for the i2s patch, which is broken in this series.
> >
> > regards
> > Philipp
> 
> 
> What is the status of this series ?
> I would like to use audio output in HDMI on my i.MX6 board, but I
> don't know if you have some pending WIP on this ?

The I2S part has been dropped.  The DesignWare HDMI block is configurable
when it is synthesized - it can contain either the AHB audio interface or
an I2S interface.  Freescale chose to synthesize it with the AHB audio
interface, and this is what my patches are geared up to provide.

On Rockchip devices, they chose to synthesize it with the I2S audio
block, and so they need a different driver for it.  Yakir Yang has been
working on that, but I've not seen anything recently.  After merging
his I2S patch, I found some problems and decided with Yakir that the
best thing to do was to drop it.

So, the result is we support HDMI audio on iMX6.

The changes were merged into mainline during the 4.4 merge window, so
Linux 4.4 will support iMX6 HDMI audio.

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

drm/i915/intel_drv.h - RPM wakelock ref not held during HW access

[Andrea Gelmini]

://mail.gelma.net/i915

Thanks a lot for your work,
Andrea
-- next part --
A non-text attachment was scrubbed...
Name: config.gz
Type: application/gzip
Size: 41290 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/e2fd3d46/attachment-0004.bin>
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.gz
Type: application/gzip
Size: 21097 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/e2fd3d46/attachment-0005.bin>
-- next part --
A non-text attachment was scrubbed...
Name: dmidecode.gz
Type: application/gzip
Size: 4066 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/e2fd3d46/attachment-0006.bin>
-- next part --
A non-text attachment was scrubbed...
Name: lspci.gz
Type: application/gzip
Size: 497 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/e2fd3d46/attachment-0007.bin>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/e2fd3d46/attachment-0001.sig>

[PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Thierry Reding]

On Mon, Jan 04, 2016 at 07:53:36AM +0100, Daniel Vetter wrote:
> Another pile of vfuncs from the old gpu.tmpl xml documentation that
> I've forgotten to delete. I spotted a few more things to
> clarify/extend in the new kerneldoc while going through this once
> more.
> 
> v2: Spelling fixes (Thierry).

Found a couple more.

> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index 29e0dc50031d..ce5cbf63b5cf 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -131,6 +131,12 @@ struct drm_crtc_helper_funcs {
>* Atomic drivers which need to inspect and adjust more state should
>* instead use the @atomic_check callback.
>*
> +  * Also beware that the neither core nor helpers filter modes before

I'd drop the "the" above: "... that neither core nor helpers..."

> +  * passing the to the driver. More specifically modes rejected by the

"passing them"?

> +  * ->mode_valid callback from #drm_connector_helper_funcs can still be
> +  * requested by userspace and therefore also need to be rejected in
> +  * either this hook, or the one in #drm_encoder_helper_funcs.
> +  *
>* RETURNS:
>*
>* True if an acceptable configuration is possible, false if the modeset
> @@ -188,7 +194,9 @@ struct drm_crtc_helper_funcs {
>* This callback is used by the legacy CRTC helpers to set a new
>* framebuffer and scanout position. It is optional and used as an
>* optimized fast-path instead of a full mode set operation with all the
> -  * resulting flickering. Since it can't update other planes it's
> +  * resulting flickering. If it is not present
> +  * drm_crtc_helper_set_config() will fall back to a full modeset, using
> +  * the ->mode_set() callbac. Since it can't update other planes it's

"callback"

>* incompatible with atomic modeset support.
>*
>* This callback is only used by the CRTC helpers and deprecated.
> @@ -439,6 +447,12 @@ struct drm_encoder_helper_funcs {
>* Atomic drivers which need to inspect and adjust more state should
>* instead use the @atomic_check callback.
>*
> +  * Also beware that the neither core nor helpers filter modes before
> +  * passing the to the driver. More specifically modes rejected by the

Same as above.

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

[PATCH] drm/amd/powerplay: fix compare_const_fl.cocci warnings

[Julia Lawall]

X != NULL, or even !X is more normmal in the kernel.

Generated by: scripts/coccinelle/misc/compare_const_fl.cocci

CC: Jammy Zhou 
Signed-off-by: Fengguang Wu 
Signed-off-by: Julia Lawall 
---

 smumgr.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smumgr.c
@@ -70,7 +70,7 @@ int smum_fini(struct pp_smumgr *smumgr)

 int smum_get_argument(struct pp_smumgr *smumgr)
 {
-   if (NULL != smumgr->smumgr_funcs->get_argument)
+   if (smumgr->smumgr_funcs->get_argument != NULL)
return smumgr->smumgr_funcs->get_argument(smumgr);

return 0;
@@ -79,7 +79,7 @@ int smum_get_argument(struct pp_smumgr *
 int smum_download_powerplay_table(struct pp_smumgr *smumgr,
void **table)
 {
-   if (NULL != smumgr->smumgr_funcs->download_pptable_settings)
+   if (smumgr->smumgr_funcs->download_pptable_settings != NULL)
return smumgr->smumgr_funcs->download_pptable_settings(smumgr,
table);

@@ -88,7 +88,7 @@ int smum_download_powerplay_table(struct

 int smum_upload_powerplay_table(struct pp_smumgr *smumgr)
 {
-   if (NULL != smumgr->smumgr_funcs->upload_pptable_settings)
+   if (smumgr->smumgr_funcs->upload_pptable_settings != NULL)
return smumgr->smumgr_funcs->upload_pptable_settings(smumgr);

return 0;

[PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[dbasehore .]

On Tue, Jan 5, 2016 at 4:48 AM, Rafael J. Wysocki  wrote:
> On Monday, January 04, 2016 06:27:18 PM Derek Basehore wrote:
>> On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
>> >
>> > I've queued up this series for the second half of the v4.4 merge window.
>> >
>> > Thanks,
>> > Rafael
>> >
>> >
>> > ___
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>> What's the status of this patch series? I haven't seen the patches
>> posted for v4.4, plus there's the issue that Dan found that needs to be
>> addressed.
>>
>> Is there a new revision of the patch series being worked on?
>
> Tomeu is not working on one AFAICS, but I may just revive his series.
>
> Do you have a pointer to the Dan's report?
>
> Thanks,
> Rafael
>

It was a reply to the second patch in the series. Here's a link to it
https://lkml.org/lkml/2015/11/10/107

[PATCH 2/4] drm/ttm: zero allocation only for CPU domain

[Lucas Stach]

Hi David,

why is this patch 2/4 if it's just a single patch?

Am Dienstag, den 05.01.2016, 11:55 +0800 schrieb david1.zhou at amd.com:
> From: Chunming Zhou 
> 
> Change-Id: I653d61e32faaa11c39bb978bf90301513a0c35b8

This change-id is just pure noise when you submit something upstream.

Please add a proper change log on why the change below is
necessary/helpful.

Regards,
Lucas

> Signed-off-by: Chunming Zhou 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> b/drivers/gpu/drm/ttm/ttm_bo.c
> index 745e996..0633b65 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -301,6 +301,7 @@ static int ttm_bo_handle_move_mem(struct
> ttm_buffer_object *bo,
>  if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
>  if (bo->ttm == NULL) {
>  bool zero = !(old_man->flags &
> TTM_MEMTYPE_FLAG_FIXED);
> + zero = (mem->mem_type == TTM_PL_SYSTEM) ?
> zero : false;
>  ret = ttm_bo_add_ttm(bo, zero);
>  if (ret)
>  goto out_err;

[PATCH libdrm] tests: util: Fixup util_open() parameter order

[Thierry Reding]

From: Thierry Reding 

util_open() takes a device parameter, followed by a module parameter.
The existing tests used the drmOpen() function, which uses a different
ordering of the parameters, and the old ordering was accidentally kept
during the conversion.

Signed-off-by: Thierry Reding 
---
Evidently I didn't properly test this. Things do work in most cases
with the current code because of the auto-detection, but there will
be cases where it fails.

 tests/modetest/modetest.c | 2 +-
 tests/proptest/proptest.c | 2 +-
 tests/vbltest/vbltest.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 22e3e81bd3cc..f665240a53c5 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1603,7 +1603,7 @@ int main(int argc, char **argv)
if (!args)
encoders = connectors = crtcs = planes = framebuffers = 1;

-   dev.fd = util_open(module, device);
+   dev.fd = util_open(device, module);
if (dev.fd < 0)
return -1;

diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
index 24c634569f2f..4bd08665461c 100644
--- a/tests/proptest/proptest.c
+++ b/tests/proptest/proptest.c
@@ -295,7 +295,7 @@ int main(int argc, char *argv[])

args = argc - optind;

-   fd = util_open(module, device);
+   fd = util_open(device, module);
if (fd < 0)
return 1;

diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 183332122978..4475b49b7b9a 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -120,7 +120,7 @@ int main(int argc, char **argv)
}
}

-   fd = util_open(module, device);
+   fd = util_open(device, module);
if (fd < 0)
return 1;

-- 
2.5.0

[Bug 93594] Flickering Shadows in The Talos Principle

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

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

Bug ID: 93594
   Summary: Flickering Shadows in The Talos Principle
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: haagch at frickel.club
QA Contact: dri-devel at lists.freedesktop.org

I haven't seen specifically this bug mentioned here yet. Apparently this has
been an issue for some time and with latest mesa git and llvm svn 256490 it
still happens.

Video demonstrating the flickering (ignore the long pause):
https://www.youtube.com/watch?v=UyZu_71LgGE

My hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M] (rev ff)

Here is a trace (657MB uncompressed, 409MB compressed):
http://haagch.frickel.club/files/talos.trace.xz

Replaying the trace on radeonsi shows flickering shadows.

When replaying the trace on intel, the shadows don't seem to flicker.

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

[PATCH] drm/i915: intel_hpd_init(): Don't check connectors for an encoder

[Lyude]

There's no reason to check for an active encoder when setting up hpd,
especially since a disconnected connector isn't going to have an encoder
in the first place. This fixes reprobing display connectors on resume.

Signed-off-by: Lyude 
---
After some talking with danvet on IRC, I learned that calling
drm_helper_hpd_irq_event() does actually trigger a full reprobe of each
connector's status. It turns out this is the actual reason reprobing on resume
hasn't been working (this was observed on a T440s):

- We call hpd_init()
- We check each connector for a couple of things before marking
  connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an
  active encoder. Of course, a disconnected port won't have an active
  encoder, so we don't add the flag to any of the connector's.
- We call drm_helper_hpd_irq_event()
- drm_helper_irq_event() checks each connector for the
  DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we
  skip reprobing each connector except that one.

 drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index b177857..18797bc 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -468,7 +468,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
list_for_each_entry(connector, _config->connector_list, head) {
struct intel_connector *intel_connector = 
to_intel_connector(connector);
connector->polled = intel_connector->polled;
-   if (connector->encoder && !connector->polled && 
I915_HAS_HOTPLUG(dev) && intel_connector->encoder->hpd_pin > HPD_NONE)
+   if (!connector->polled && I915_HAS_HOTPLUG(dev) && 
intel_connector->encoder->hpd_pin > HPD_NONE)
connector->polled = DRM_CONNECTOR_POLL_HPD;
if (intel_connector->mst_port)
connector->polled = DRM_CONNECTOR_POLL_HPD;
-- 
2.5.0

[patch] drm/amd/powerplay: fix a reversed condition

[Dan Carpenter]

Yes.  This was a Smatch warning but Coccinelle can also find this kinds
of inconsistent NULL checking.

regards,
dan carpenter

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

[Fabio Estevam]

On Tue, Jan 5, 2016 at 1:40 PM, Jean-Michel Hautbois
 wrote:

> What is the status of this series ?
> I would like to use audio output in HDMI on my i.MX6 board, but I
> don't know if you have some pending WIP on this ?

This series is in mainline since 4.4-rc1.

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

[Marek Szyprowski]

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

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  1 -
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 68 ---
 drivers/gpu/drm/exynos/exynos_mixer.c | 19 +++--
 3 files changed, 34 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 17b5ded72ff1..244ae6c4482c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -217,7 +217,6 @@ struct exynos_drm_private {
 * this array is used to be aware of which crtc did it request vblank.
 */
struct drm_crtc *crtc[MAX_CRTC];
-   struct drm_property *plane_zpos_property;

unsigned long da_start;
unsigned long da_space_size;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d86227236f55..4afa5dfda9e0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -137,9 +137,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

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

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

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

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

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

 static int
@@ -302,20 +262,27 @@ static const struct drm_plane_helper_funcs 
plane_helper_funcs = {
 };

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

-   prop = dev_priv->plane_zpos_property;
-   if (!prop) {
-   prop = drm_property_create_range(dev, 0, "zpos",
-0, MAX_PLANE - 1);
-   if (!prop)
+   if (immutable) {
+   if (!dev->mode_config.zpos_immutable_property)
+   dev->mode_config.zpos_immutable_property =
+   drm_plane_create_zpos_immutable_property(dev);
+   if 

[PATCH 3/4] drm/exynos: mixer: properly update all planes on the same vblank event

[Marek Szyprowski]

This patch also moves mixer_vsync_set_update() to newly introduced
mixer_atomic_begin/flush callbacks. This ensures that all mixer planes
will be updated on the same vsync event.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index bf148dc3623c..b5fbc1cbf024 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -516,7 +516,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
}

spin_lock_irqsave(>reg_slock, flags);
-   mixer_vsync_set_update(ctx, false);

/* interlace or progressive scan mode */
val = (ctx->interlace ? ~0 : 0);
@@ -567,7 +566,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
mixer_cfg_vp_blend(ctx);
mixer_run(ctx);

-   mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(>reg_slock, flags);

mixer_regs_dump(ctx);
@@ -642,7 +640,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
ctx->interlace = false;

spin_lock_irqsave(>reg_slock, flags);
-   mixer_vsync_set_update(ctx, false);

/* setup format */
mixer_reg_writemask(res, MXR_GRAPHIC_CFG(win),
@@ -691,7 +688,6 @@ static void mixer_graph_buffer(struct mixer_context *ctx,

mixer_run(ctx);

-   mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(>reg_slock, flags);

mixer_regs_dump(ctx);
@@ -718,7 +714,6 @@ static void mixer_win_reset(struct mixer_context *ctx)
unsigned long flags;

spin_lock_irqsave(>reg_slock, flags);
-   mixer_vsync_set_update(ctx, false);

mixer_reg_writemask(res, MXR_CFG, MXR_CFG_DST_HDMI, MXR_CFG_DST_MASK);

@@ -749,7 +744,6 @@ static void mixer_win_reset(struct mixer_context *ctx)
if (ctx->vp_enabled)
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);

-   mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(>reg_slock, flags);
 }

@@ -980,6 +974,16 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
mixer_reg_writemask(res, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
 }

+static void mixer_atomic_begin(struct exynos_drm_crtc *crtc)
+{
+   struct mixer_context *mixer_ctx = crtc->ctx;
+
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
+   return;
+
+   mixer_vsync_set_update(mixer_ctx, false);
+}
+
 static void mixer_update_plane(struct exynos_drm_crtc *crtc,
   struct exynos_drm_plane *plane)
 {
@@ -1009,12 +1013,18 @@ static void mixer_disable_plane(struct exynos_drm_crtc 
*crtc,
return;

spin_lock_irqsave(>reg_slock, flags);
-   mixer_vsync_set_update(mixer_ctx, false);
-
mixer_cfg_layer(mixer_ctx, plane->index, 0, false);
+   spin_unlock_irqrestore(>reg_slock, flags);
+}
+
+static void mixer_atomic_flush(struct exynos_drm_crtc *crtc)
+{
+   struct mixer_context *mixer_ctx = crtc->ctx;
+
+   if (!test_bit(MXR_BIT_POWERED, _ctx->flags))
+   return;

mixer_vsync_set_update(mixer_ctx, true);
-   spin_unlock_irqrestore(>reg_slock, flags);
 }

 static void mixer_wait_for_vblank(struct exynos_drm_crtc *crtc)
@@ -1055,6 +1065,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)

pm_runtime_get_sync(ctx->dev);

+   mixer_vsync_set_update(ctx, false);
+
mixer_reg_writemask(res, MXR_STATUS, ~0, MXR_STATUS_SOFT_RESET);

if (test_bit(MXR_BIT_VSYNC, >flags)) {
@@ -1063,6 +1075,8 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
}
mixer_win_reset(ctx);

+   mixer_vsync_set_update(ctx, true);
+
set_bit(MXR_BIT_POWERED, >flags);
 }

@@ -1113,8 +1127,10 @@ static const struct exynos_drm_crtc_ops mixer_crtc_ops = 
{
.enable_vblank  = mixer_enable_vblank,
.disable_vblank = mixer_disable_vblank,
.wait_for_vblank= mixer_wait_for_vblank,
+   .atomic_begin   = mixer_atomic_begin,
.update_plane   = mixer_update_plane,
.disable_plane  = mixer_disable_plane,
+   .atomic_flush   = mixer_atomic_flush,
.atomic_check   = mixer_atomic_check,
 };

-- 
1.9.2

[PATCH 2/4] drm/exynos: crtc: rework atomic_{begin,flush}

[Marek Szyprowski]

Some CRTC drivers (like Exynos DRM Mixer) can handle blocking register
updates only on per-device level, not per-plane level. This patch changes
exynos_crts atomic_begin/atomic_flush callbacks to handle the entire crtc,
instead of given planes, so driver can handle both cases on their own.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 14 --
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 --
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 20 
 drivers/gpu/drm/exynos/exynos_drm_drv.h   | 10 --
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 --
 5 files changed, 32 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 77073d8faaa3..1bf6a21130c7 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -248,15 +248,16 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx, int win,
   protect ? ~0 : 0);
 }

-static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
+static void decon_atomic_begin(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
+   int i;

if (test_bit(BIT_SUSPENDED, >flags))
return;

-   decon_shadow_protect_win(ctx, plane->index, true);
+   for (i = ctx->first_win; i < WINDOWS_NR; i++)
+   decon_shadow_protect_win(ctx, i, true);
 }

 #define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
@@ -336,15 +337,16 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
 }

-static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
+static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
+   int i;

if (test_bit(BIT_SUSPENDED, >flags))
return;

-   decon_shadow_protect_win(ctx, plane->index, false);
+   for (i = ctx->first_win; i < WINDOWS_NR; i++)
+   decon_shadow_protect_win(ctx, i, false);

if (ctx->out_type == IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, >flags);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 8911f965b06c..52bda3b42fe0 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -385,15 +385,16 @@ static void decon_shadow_protect_win(struct decon_context 
*ctx,
writel(val, ctx->regs + SHADOWCON);
 }

-static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
+static void decon_atomic_begin(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
+   int i;

if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, plane->index, true);
+   for (i = 0; i < WINDOWS_NR; i++)
+   decon_shadow_protect_win(ctx, i, true);
 }

 static void decon_update_plane(struct exynos_drm_crtc *crtc,
@@ -517,15 +518,16 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
writel(val, ctx->regs + DECON_UPDATE);
 }

-static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
-   struct exynos_drm_plane *plane)
+static void decon_atomic_flush(struct exynos_drm_crtc *crtc)
 {
struct decon_context *ctx = crtc->ctx;
+   int i;

if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, plane->index, false);
+   for (i = 0; i < WINDOWS_NR; i++)
+   decon_shadow_protect_win(ctx, i, false);
 }

 static void decon_init(struct decon_context *ctx)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index efecd916f797..150a43025861 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -68,32 +68,20 @@ static void exynos_crtc_atomic_begin(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
-   struct drm_plane *plane;

exynos_crtc->event = crtc->state->event;

-   drm_atomic_crtc_for_each_plane(plane, crtc) {
-   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
-
-   if (exynos_crtc->ops->atomic_begin)
-   exynos_crtc->ops->atomic_begin(exynos_crtc,
-   exynos_plane);
-   }
+   if (exynos_crtc->ops->atomic_begin)
+   exynos_crtc->ops->atomic_begin(exynos_crtc);
 }

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

[Marek Szyprowski]

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

Signed-off-by: Marek Szyprowski 
---
 Documentation/DocBook/gpu.tmpl  | 14 --
 drivers/gpu/drm/drm_atomic.c|  4 +++
 drivers/gpu/drm/drm_atomic_helper.c | 52 +
 drivers/gpu/drm/drm_crtc.c  | 13 ++
 include/drm/drm_atomic_helper.h |  2 ++
 include/drm/drm_crtc.h  | 13 ++
 6 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 6c6e81a9eaf4..e81acd999891 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2004,7 +2004,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -2256,7 +2256,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
+   Optional
“scaling mode”
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2280,6 +2280,16 @@ void intel_crt_init(struct drm_device *dev)
TBD


+"zpos" 
+   RANGE
+   Min=0, Max=255
+   Plane
+   Plane's 'z' position during blending (0 for 
background, 255 for frontmost).
+   If two planes assigned to same CRTC have equal zpos values, the 
plane with higher plane
+   id is treated as closer to front. Can be IMMUTABLE if driver 
doesn't support changing
+   plane's order.
+   
+   
i915
Generic
"Broadcast RGB"
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 6a21e5c378c1..97bb069cb6a3 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -614,6 +614,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+   } else if (property == config->zpos_property) {
+   state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -670,6 +672,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+   } else if (property == config->zpos_property) {
+   *val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 268d37f26960..de3ca33eb696 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * DOC: overview
@@ -2781,3 +2782,54 @@ void drm_atomic_helper_connector_destroy_state(struct 
drm_connector *connector,
kfree(state);
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_destroy_state);
+
+/**
+ * __drm_atomic_helper_plane_zpos_cmp - compare zpos value of two planes
+ * @a: pointer to first plane
+ * @b: pointer to second plane
+ *
+ * This function is used for comparing two planes while sorting them to assign
+ * a normalized zpos values. Planes are compared first by their zpos values,
+ * then in case they equal, by plane id.
+ */
+static int __drm_atomic_helper_plane_zpos_cmp(const void *a, const void *b)
+{
+   const struct drm_plane *pa = *(struct drm_plane **)a;
+   const struct drm_plane *pb = *(struct drm_plane **)b;
+   int zpos_a = 0, zpos_b = 0;
+
+   if (pa->state)
+   zpos_a = pa->state->zpos << 16;
+   if (pb->state)
+   zpos_b = pb->state->zpos << 16;
+
+   zpos_a += pa->base.id;
+   zpos_b += pb->base.id;
+
+   return zpos_a - zpos_b;
+}
+
+/**
+ * drm_atomic_helper_normalize_zpos - calculate normalized zpos values
+ * @planes: arrays of pointer to planes to consider for normalization
+ * @count: number of planes in the above array
+ *
+ * This function takes arrays of pointers to planes and calculates normalized
+ * zpos value for them taking into account each planes[i]->state->zpos value
+ * and plane's id (if zpos equals). The plane[i]->state->normalized_zpos is
+ * then filled with uniqe values from 0 to count-1.
+ * Note: a side effect of this function is the fact that the planes array will
+ * be 

[PATCH 0/4] drm/exynos: introduce generic zpos property

[Marek Szyprowski]

Hello all,

This patch series is a continuation of rework of blending support in
Exynos DRM driver. Some background can be found here:
http://www.spinics.net/lists/dri-devel/msg96969.html

Daniel Vetter suggested that zpos property should be made generic, with
well-defined semantics. This patchset is my proposal for such generic
zpos property:
- added zpos properties to drm core and plane state structures,
- added helpers for normalizing zpos properties of given set of planes,
- well defined semantics: planes are sorted by zpos values and then plane
  id value if zpos equals.

Patches 2/4 and 3/4 are fixes for Exynos DRM driver, which are required
to properly implement generic zpos handling. However they can be also
merged regardless of the rest of the patches (if there is a need for
further discussion on the generic zpos property feature).

Patches are based on top of latest exynos-drm-next branch.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Patch summary:

Marek Szyprowski (4):
  drm: add generic zpos property
  drm/exynos: crtc: rework atomic_{begin,flush}
  drm/exynos: mixer: properly update all planes on the same vblank event
  drm/exynos: use generic code for managing zpos plane property

 Documentation/DocBook/gpu.tmpl| 14 +-
 drivers/gpu/drm/drm_atomic.c  |  4 ++
 drivers/gpu/drm/drm_atomic_helper.c   | 52 
 drivers/gpu/drm/drm_crtc.c| 13 +
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 14 +++---
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 20 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   | 11 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 14 +++---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 68 +++
 drivers/gpu/drm/exynos/exynos_mixer.c | 53 -
 include/drm/drm_atomic_helper.h   |  2 +
 include/drm/drm_crtc.h| 13 +
 13 files changed, 187 insertions(+), 105 deletions(-)

-- 
1.9.2

[PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Rafael J. Wysocki]

On Monday, January 04, 2016 06:27:18 PM Derek Basehore wrote:
> On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
> > 
> > I've queued up this series for the second half of the v4.4 merge window.
> > 
> > Thanks,
> > Rafael
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> What's the status of this patch series? I haven't seen the patches
> posted for v4.4, plus there's the issue that Dan found that needs to be
> addressed.
> 
> Is there a new revision of the patch series being worked on?

Tomeu is not working on one AFAICS, but I may just revive his series.

Do you have a pointer to the Dan's report?

Thanks,
Rafael

drm/amd/powerplay: fix a reversed condition

[SF Markus Elfring]

> Yes.  This was a Smatch warning

Thanks for this acknowledgement.

How do you think about to indicate such a detail more often in
your update suggestions and bug reports?

Would it make sense to mark contributions from automatic static
source code analysis by a dedicated tag in the commit message?


> but Coccinelle can also find this kinds of inconsistent NULL checking.

Should we try together to extend the script collection for the
semantic patch language around such use cases?

Regards,
Markus

DRM support in Android

[vijay kumar]

Hii all,
  I want to know some information regarding DRI and DRM support
in android.Does Android uses DRI drivers in MESA for Direct rendering.Can
DRI drivers alone can be used without DRM ? I am pretty confused that how
Direct rendering is performed in android whether by DRI or some other
method.Struggling with this problem since many days but did n't find any
answer .Please do help me.

Thanks and Regards.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/ec176b37/attachment.html>

[PATCH 3/3] drm/amdgpu: validate duplicates first

[Christian König]

From: Christian König 

Most VM BOs end up in the duplicates list, validate it
first make -ENOMEM less likely.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index f532f70..0868921 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -421,11 +421,11 @@ static int amdgpu_cs_parser_relocs(struct 
amdgpu_cs_parser *p)

amdgpu_vm_get_pt_bos(p->adev, >vm, );

-   r = amdgpu_cs_list_validate(p->adev, >vm, >validated);
+   r = amdgpu_cs_list_validate(p->adev, >vm, );
if (r)
goto error_validate;

-   r = amdgpu_cs_list_validate(p->adev, >vm, );
+   r = amdgpu_cs_list_validate(p->adev, >vm, >validated);

 error_validate:
if (r)
-- 
2.5.0

[PATCH 2/3] drm/amdgpu: move VM page tables to the LRU end on CS

[Christian König]

From: Christian König 

This makes it less likely to run into an ENOMEM because
VM page tables are evicted last.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  | 10 --
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f7dc9ca..72504bf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -987,7 +987,8 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct 
amdgpu_vm *vm);
 void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
 struct list_head *validated,
 struct amdgpu_bo_list_entry *entry);
-void amdgpu_vm_get_pt_bos(struct amdgpu_vm *vm, struct list_head *duplicates);
+void amdgpu_vm_get_pt_bos(struct amdgpu_device *adev, struct amdgpu_vm *vm,
+ struct list_head *duplicates);
 int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct amdgpu_ring *ring,
  struct amdgpu_sync *sync);
 void amdgpu_vm_flush(struct amdgpu_ring *ring,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index cb9c93c..f532f70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -419,7 +419,7 @@ static int amdgpu_cs_parser_relocs(struct amdgpu_cs_parser 
*p)
if (unlikely(r != 0))
goto error_reserve;

-   amdgpu_vm_get_pt_bos(>vm, );
+   amdgpu_vm_get_pt_bos(p->adev, >vm, );

r = amdgpu_cs_list_validate(p->adev, >vm, >validated);
if (r)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index c9f26df..e3bce52 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -467,7 +467,7 @@ static void amdgpu_gem_va_update_vm(struct amdgpu_device 
*adev,
if (r)
goto error_print;

-   amdgpu_vm_get_pt_bos(bo_va->vm, );
+   amdgpu_vm_get_pt_bos(adev, bo_va->vm, );
list_for_each_entry(entry, , head) {
domain = amdgpu_mem_type_to_domain(entry->bo->mem.mem_type);
/* if anything is swapped out don't swap it in here,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f3b07bf..5ff742f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -106,19 +106,25 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
  * Add the page directory to the BO duplicates list
  * for command submission.
  */
-void amdgpu_vm_get_pt_bos(struct amdgpu_vm *vm, struct list_head *duplicates)
+void amdgpu_vm_get_pt_bos(struct amdgpu_device *adev, struct amdgpu_vm *vm,
+ struct list_head *duplicates)
 {
+   struct ttm_bo_global *glob = adev->mman.bdev.glob;
unsigned i;

-   /* add the vm page table to the list */
+   /* add the vm page table to the list and move them to the LRU tail */
+   spin_lock(>lru_lock);
for (i = 0; i <= vm->max_pde_used; ++i) {
struct amdgpu_bo_list_entry *entry = >page_tables[i].entry;

if (!entry->robj)
continue;

+   ttm_bo_move_to_lru_tail(>robj->tbo);
list_add(>tv.head, duplicates);
}
+
+   spin_unlock(>lru_lock);
 }

 /**
-- 
2.5.0

[PATCH 1/3] drm/ttm: add ttm_bo_move_to_lru_tail function

[Christian König]

From: Christian König 

This allows the drivers to move a BO to the end of the LRU
without removing and adding it again.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 20 
 include/drm/ttm/ttm_bo_api.h | 10 ++
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 745e996..9e91cc3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -228,6 +228,26 @@ void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
 }
 EXPORT_SYMBOL(ttm_bo_del_sub_from_lru);

+void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo)
+{
+   struct ttm_bo_device *bdev = bo->bdev;
+   struct ttm_mem_type_manager *man;
+
+   lockdep_assert_held(>resv->lock.base);
+
+   if (!list_empty(>swap)) {
+   list_del(>swap);
+   list_add_tail(>swap, >glob->swap_lru);
+   }
+
+   if (!list_empty(>lru)) {
+   man = >man[bo->mem.mem_type];
+   list_del(>lru);
+   list_add_tail(>lru, >lru);
+   }
+}
+EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
+
 /*
  * Call bo->mutex locked.
  */
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index c768ddf..afae231 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -383,6 +383,16 @@ extern void ttm_bo_add_to_lru(struct ttm_buffer_object 
*bo);
  */
 extern int ttm_bo_del_from_lru(struct ttm_buffer_object *bo);

+/**
+ * ttm_bo_move_to_lru_tail
+ *
+ * @bo: The buffer object.
+ *
+ * Move this BO to the tail of all lru lists used to lookup and reserve an
+ * object. This function must be called with struct ttm_bo_global::lru_lock
+ * held, and is used to make a BO less likely to be considered for eviction.
+ */
+extern void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo);

 /**
  * ttm_bo_lock_delayed_workqueue
-- 
2.5.0

[Bug 93591] [TONGA] ARK Survival Evolved: corruption of main menu textures

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

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

EoD  changed:

   What|Removed |Added

 Attachment #120812|0   |1
is obsolete||

--- Comment #1 from EoD  ---
Created attachment 120813
  --> https://bugs.freedesktop.org/attachment.cgi?id=120813=edit
apitrace trace

wrong mime type of attachment

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

[Bug 93591] [TONGA] ARK Survival Evolved: corruption of main menu textures

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

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

Bug ID: 93591
   Summary: [TONGA] ARK Survival Evolved: corruption of main menu
textures
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: EoD at xmw.de
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 120812
  --> https://bugs.freedesktop.org/attachment.cgi?id=120812=edit
apitrace trace

I get flickering textures on buttons in the menus of ARK Survival Evolved on my
Tonga.

A video of the corruption: https://www.youtube.com/watch?v=29OP-wlashA

$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TONGA (DRM 3.1.0, LLVM 3.8.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel
(git-14f21f5)
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

I am using the current kernel "4.4.0-rc3-geafbbd9" from
cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.5 with powerplay enabled.


This issue does not appear on llvmpipe (neither in the apitrace replay, nor
with the game).

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

[PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c

[Masanari Iida]

This patch fix some spelling typos found in Documentation/Docbook
gpu/ch04s03.html.  This file was generated from comments within
source, so I have to fix typos in i915_gem_fence.c.

Signed-off-by: Masanari Iida 
---
 drivers/gpu/drm/i915/i915_gem_fence.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 5981985..a2b938e 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -34,8 +34,8 @@
  * set of these objects.
  *
  * Fences are used to detile GTT memory mappings. They're also connected to the
- * hardware frontbuffer render tracking and hence interract with frontbuffer
- * conmpression. Furthermore on older platforms fences are required for tiled
+ * hardware frontbuffer render tracking and hence interact with frontbuffer
+ * compression. Furthermore on older platforms fences are required for tiled
  * objects used by the display engine. They can also be used by the render
  * engine - they're required for blitter commands and are optional for render
  * commands. But on gen4+ both display (with the exception of fbc) and 
rendering
@@ -46,8 +46,8 @@
  *
  * Finally note that because fences are such a restricted resource they're
  * dynamically associated with objects. Furthermore fence state is committed to
- * the hardware lazily to avoid unecessary stalls on gen2/3. Therefore code 
must
- * explictly call i915_gem_object_get_fence() to synchronize fencing status
+ * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code 
must
+ * explicitly call i915_gem_object_get_fence() to synchronize fencing status
  * for cpu access. Also note that some code wants an unfenced view, for those
  * cases the fence can be removed forcefully with i915_gem_object_put_fence().
  *
@@ -527,7 +527,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
  * required.
  *
  * When bit 17 is XORed in, we simply refuse to tile at all.  Bit
- * 17 is not just a page offset, so as we page an objet out and back in,
+ * 17 is not just a page offset, so as we page an object out and back in,
  * individual pages in it will have different bit 17 addresses, resulting in
  * each 64 bytes being swapped with its neighbor!
  *
-- 
2.7.0.rc3

[Bug 91251] [APITRACE] [r600g] "ARK: Survival Evolved" game: shader errors

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

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

EoD  changed:

   What|Removed |Added

 CC||EoD at xmw.de

--- Comment #2 from EoD  ---
The replay looks completely broken on my Tonga (amdgpu/radeonsi, kernel
4.5-drm-next) and current mesa git.

But I could not reproduce the problem on my Tonga when playing the native
version of ARK.

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

[PATCH] drm/exynos: fix kernel panic issue at drm releasing

[Daniel Vetter]

On Tue, Jan 05, 2016 at 07:55:52PM +0900, Inki Dae wrote:
> Hi Daniel,
> 
> 2016년 01월 05일 05:24에 Daniel Stone 이(가) 쓴 글:
> > Hi Inki,
> > 
> > On 4 January 2016 at 12:57, Inki Dae  wrote:
> >> 2015년 12월 24일 22:32에 Daniel Stone 이(가) 쓴 글:
> >>> On 24 December 2015 at 09:10, Inki Dae  wrote:
>  +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc)
>  +{
>  +   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>  +   unsigned long flags;
>  +
>  +   spin_lock_irqsave(>dev->event_lock, flags);
>  +   exynos_crtc->event = NULL;
>  +   spin_unlock_irqrestore(>dev->event_lock, flags);
>  +}
> >>>
> >>> This will leak the event and event space; you should call
> >>> event->base.destroy() here. With that fixed:
> >>
> >> Right. we don't use exynos specific page flip function anymore which 
> >> managed the event as a list so that the event objects can be freed by 
> >> postclose callback.
> >> Anyway, would it be better for event->base.destory() to be called between 
> >> spin lock/unlock?
> > 
> > You must increment event->base.file_priv->event_space (see
> > drm_atomic.c:destroy_vblank_event), as well as calling
> 
> Reasonable to me. Seems other DRM drivers don't increment event_space.
> 
> > event->base.destroy (see drm_fops.c:drm_read) underneath event_lock,
> > yes.
> 
> In addition, only event objects belonging to the request process should be 
> destroyed.

Just random comment out of the far left field, but robclark had a bunch of
patches to clean up all that event alloc/cleanup code a bit and extract it
into core functions. Might be good to ping him on irc to figure out where
that series is and whether you could take it over.

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

[PATCH v2 3/3] dt-bindings: add document for rk3229-vop

[Yakir Yang]

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v2:
- acked by Rob

 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index 5489b59..75ebc20 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -7,6 +7,7 @@ buffer to an external LCD interface.
 Required properties:
 - compatible: value should be one of the following
"rockchip,rk3288-vop";
+   "rockchip,rk3229-vop";
"rockchip,rk3036-vop";

 - interrupts: should contain a list of all VOP IP block interrupts in the
-- 
1.9.1

[PATCH v2 2/3] drm/rockchip: vop: add rk3229 vop support

[Yakir Yang]

RK3229 registers layout is simalar to RK3288 layout, only the
interruput registers is different to RK3288.

RK3229 support two overlay plane and one hwc plane, max output
resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Separate the write-mask changes out, and remove the DUMMY_INTR marcos (Heiko)

 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 110 
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  90 +++
 2 files changed, 200 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7fbaf76..f1358f9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -191,6 +191,114 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
 };

+static const struct vop_scl_extension rk3229_win_full_scl_ext = {
+   .cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
+   .cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
+   .cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
+   .cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
+   .cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
+   .yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
+   .yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
+   .yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
+   .yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
+   .yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
+   .line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
+   .cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
+   .yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
+   .vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
+   .vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
+   .vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
+   .vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
+   .bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
+   .cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
+   .yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
+   .lb_mode = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 5),
+};
+
+static const struct vop_scl_regs rk3229_win_full_scl = {
+   .ext = _win_full_scl_ext,
+   .scale_yrgb_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+   .scale_yrgb_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+   .scale_cbcr_x = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+   .scale_cbcr_y = VOP_REG(RK3229_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3229_win01_data = {
+   .scl = _win_full_scl,
+   .data_formats = formats_win_full,
+   .nformats = ARRAY_SIZE(formats_win_full),
+   .enable = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 0),
+   .format = VOP_REG(RK3229_WIN0_CTRL0, 0x7, 1),
+   .rb_swap = VOP_REG(RK3229_WIN0_CTRL0, 0x1, 12),
+   .act_info = VOP_REG(RK3229_WIN0_ACT_INFO, 0x1fff1fff, 0),
+   .dsp_info = VOP_REG(RK3229_WIN0_DSP_INFO, 0x0fff0fff, 0),
+   .dsp_st = VOP_REG(RK3229_WIN0_DSP_ST, 0x1fff1fff, 0),
+   .yrgb_mst = VOP_REG(RK3229_WIN0_YRGB_MST, 0x, 0),
+   .uv_mst = VOP_REG(RK3229_WIN0_CBR_MST, 0x, 0),
+   .yrgb_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 0),
+   .uv_vir = VOP_REG(RK3229_WIN0_VIR, 0x3fff, 16),
+   .src_alpha_ctl = VOP_REG(RK3229_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+   .dst_alpha_ctl = VOP_REG(RK3229_WIN0_DST_ALPHA_CTRL, 0xff, 0),
+};
+
+static const struct vop_win_data rk3229_vop_win_data[] = {
+   { .base = 0x00, .phy = _win01_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+   { .base = 0x40, .phy = _win01_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const struct vop_ctrl rk3229_ctrl_data = {
+   .cfg_done = VOP_REG(RK3229_REG_CFG_DONE, 0x1, 0),
+   .standby = VOP_REG(RK3229_SYS_CTRL, 0x1, 22),
+   .gate_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 23),
+   .mmu_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 20),
+   .rgb_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 12),
+   .hdmi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 13),
+   .edp_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 14),
+   .mipi_en = VOP_REG(RK3229_SYS_CTRL, 0x1, 15),
+   .data_blank = VOP_REG(RK3229_DSP_CTRL0, 0x1, 19),
+   .out_mode = VOP_REG(RK3229_DSP_CTRL0, 0xf, 0),
+   .pin_pol = VOP_REG(RK3229_DSP_CTRL1, 0xf, 20),
+   .dither_up = VOP_REG(RK3229_DSP_CTRL1, 0x1, 6),
+   .htotal_pw = VOP_REG(RK3229_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+   .hact_st_end = VOP_REG(RK3229_DSP_HACT_ST_END, 0x1fff1fff, 0),
+   .vtotal_pw = VOP_REG(RK3229_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+   .vact_st_end = VOP_REG(RK3229_DSP_VACT_ST_END, 0x1fff1fff, 0),
+   .hpost_st_end = VOP_REG(RK3229_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
+   .vpost_st_end = VOP_REG(RK3229_POST_DSP_VACT_INFO, 

[PATCH 2/4] drm/ttm: zero allocation only for CPU domain

[david1.z...@amd.com]

From: Chunming Zhou 

Change-Id: I653d61e32faaa11c39bb978bf90301513a0c35b8
Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 745e996..0633b65 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -301,6 +301,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
if (!(new_man->flags & TTM_MEMTYPE_FLAG_FIXED)) {
if (bo->ttm == NULL) {
bool zero = !(old_man->flags & TTM_MEMTYPE_FLAG_FIXED);
+   zero = (mem->mem_type == TTM_PL_SYSTEM) ? zero : false;
ret = ttm_bo_add_ttm(bo, zero);
if (ret)
goto out_err;
-- 
1.9.1

[PATCH v2 1/3] drm/rockchip: vop: Add support for interrupt registers using write-masks

[Yakir Yang]

Some new display-controllers are need to set write-masks to enable writes
to interrupt registers. Allow this to be set on a per-vop basis.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- Add this patch in v2 (Heiko)

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d83bf87..3c83097 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -63,9 +63,12 @@
 #define VOP_INTR_SET_TYPE(vop, name, type, v) \
do { \
int i, reg = 0; \
-   for (i = 0; i < vop->data->intr->nintrs; i++) { \
-   if (vop->data->intr->intrs[i] & type) \
+   const struct vop_intr *intr = vop->data->intr; \
+   for (i = 0; i < intr->nintrs; i++) { \
+   if (intr->intrs[i] & type) { \
reg |= (v) << i; \
+   reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
+   } \
} \
VOP_INTR_SET(vop, name, reg); \
} while (0)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 071ff0b..f1bb84d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -60,6 +60,7 @@ struct vop_ctrl {
 };

 struct vop_intr {
+   bool write_mask;
const int *intrs;
uint32_t nintrs;
struct vop_reg enable;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..7fbaf76 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
 };

 static const struct vop_intr rk3288_vop_intr = {
+   .write_mask = false,
.intrs = rk3288_vop_intrs,
.nintrs = ARRAY_SIZE(rk3288_vop_intrs),
.status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
@@ -240,6 +241,7 @@ static const int rk3036_vop_intrs[] = {
 };

 static const struct vop_intr rk3036_intr = {
+   .write_mask = false,
.intrs = rk3036_vop_intrs,
.nintrs = ARRAY_SIZE(rk3036_vop_intrs),
.status = VOP_REG(RK3036_INT_STATUS, 0xf, 0),
-- 
1.9.1

[PATCH v2 0/3] Add RK3229 vop support

[Yakir Yang]

Based on Mark Yao's drm-next branch
[https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2015-12-28]


Changes in v2:
- Add this patch in v2 (Heiko)
- Separate the write-mask changes out, and remove the DUMMY_INTR marcos (Heiko)
- acked by Rob

Yakir Yang (3):
  drm/rockchip: vop: Add support for interrupt registers using
write-masks
  drm/rockchip: vop: add rk3229 vop support
  dt-bindings: add document for rk3229-vop

 .../bindings/display/rockchip/rockchip-vop.txt |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 112 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h|  90 +
 5 files changed, 209 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 4.2.y-ckt 088/211] drm: Use userspace compatible type in fourcc_mod_code macro

[Kamal Mostafa]

4.2.8-ckt1 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Tvrtko Ursulin 

commit 6172180c6b37ea164bf8a9bad70bb348d0a16563 upstream.

__u64 should be used instead of u64.

Feature originally added in:

commit e3eb3250d84ef97b766312345774367b6a310db8
Author: Rob Clark 
Date:   Thu Feb 5 14:41:52 2015 +

drm: add support for tiled/compressed/etc modifier in addfb2

Signed-off-by: Tvrtko Ursulin 
Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Daniel Vetter 
Cc: dri-devel at lists.freedesktop.org
Fixes: e3eb3250d84e ("drm: add support for tiled/compressed/etc modifier in 
addfb2")
Reviewed-by: Ville Syrjälä 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1442999431-28568-1-git-send-email-tvrtko.ursulin
 at linux.intel.com
Signed-off-by: Jani Nikula 
Signed-off-by: Kamal Mostafa 
---
 include/uapi/drm/drm_fourcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 2f295cd..904c798 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -151,7 +151,7 @@
 /* add more to the end as needed */

 #define fourcc_mod_code(vendor, val) \
-   u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))
+   __u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
0x00ffULL))

 /*
  * Format Modifier tokens:
-- 
1.9.1

[RFC PATCH v1 1/2] drm/rockchip: vop: add rk3229 vop support

[Yakir Yang]

Hi Heiko,

On 01/04/2016 08:23 PM, Heiko Stuebner wrote:
> Hi Yakir,
>
> Am Montag, 4. Januar 2016, 19:53:58 schrieb Yakir Yang:
>> RK3229 registers layout is simalar to RK3288 layout, only the
>> interruput registers is different to RK3288.
>>
>> RK3229 support two overlay plane and one hwc plane, max output
>> resolution is 4K. it support IOMMU, and its IOMMU same as rk3288's.
>>
>> Signed-off-by: Yakir Yang 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   7 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h |   2 +
>>   drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 120
>>  drivers/gpu/drm/rockchip/rockchip_vop_reg.h
>> |  90 + 4 files changed, 217 insertions(+), 2
>> deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index d83bf87..3c83097
>> 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -63,9 +63,12 @@
>>   #define VOP_INTR_SET_TYPE(vop, name, type, v) \
>>  do { \
>>  int i, reg = 0; \
>> -for (i = 0; i < vop->data->intr->nintrs; i++) { \
>> -if (vop->data->intr->intrs[i] & type) \
>> +const struct vop_intr *intr = vop->data->intr; \
>> +for (i = 0; i < intr->nintrs; i++) { \
>> +if (intr->intrs[i] & type) { \
>>  reg |= (v) << i; \
>> +reg |= intr->write_mask ? (1 << (i + 16)) : 0; \
>> +} \
>>  } \
>>  VOP_INTR_SET(vop, name, reg); \
>>  } while (0)
> I do believe this part, as well as setting the default .write_mask = false
> for the existing parts should get its own patch + a bit more explanation
> on what this does and why it's needed.
>
>  8< 
> drm/rockchip: Add support for interrupt registers using write-masks
>
> Some new display-controllers are need to set write-masks to enable writes
> to interrupt registers. Allow this to be set on a per-vop basis.
>  8< 
>
> or something like that, and then patches 2+3 being the rk3229 support +
> binding.

Great, will send the new version out.

>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 071ff0b..1e839e8
>> 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
>> @@ -60,6 +60,7 @@ struct vop_ctrl {
>>   };
>>
>>   struct vop_intr {
>> +bool write_mask;
>>  const int *intrs;
>>  uint32_t nintrs;
>>  struct vop_reg enable;
>> @@ -136,6 +137,7 @@ struct vop_data {
>>   };
>>
>>   /* interrupt define */
>> +#define DUMMY_INTR  (0 << 0)
>>   #define DSP_HOLD_VALID_INTR(1 << 0)
>>   #define FS_INTR(1 << 1)
>>   #define LINE_FLAG_INTR (1 << 2)
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
>> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c index 3166b46..bbcd128
>> 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
>> @@ -174,6 +174,7 @@ static const int rk3288_vop_intrs[] = {
>>   };
>>
>>   static const struct vop_intr rk3288_vop_intr = {
>> +.write_mask = false,
>>  .intrs = rk3288_vop_intrs,
>>  .nintrs = ARRAY_SIZE(rk3288_vop_intrs),
>>  .status = VOP_REG(RK3288_INTR_CTRL0, 0xf, 0),
>> @@ -190,6 +191,122 @@ static const struct vop_data rk3288_vop = {
>>  .win_size = ARRAY_SIZE(rk3288_vop_win_data),
>>   };
>>
>> +static const struct vop_scl_extension rk3229_win_full_scl_ext = {
>> +.cbcr_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 31),
>> +.cbcr_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 30),
>> +.cbcr_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 28),
>> +.cbcr_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 26),
>> +.cbcr_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 24),
>> +.yrgb_vsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 23),
>> +.yrgb_vsu_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 22),
>> +.yrgb_hsd_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 20),
>> +.yrgb_ver_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 18),
>> +.yrgb_hor_scl_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 16),
>> +.line_load_mode = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 15),
>> +.cbcr_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0x7, 12),
>> +.yrgb_axi_gather_num = VOP_REG(RK3229_WIN0_CTRL1, 0xf, 8),
>> +.vsd_cbcr_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 7),
>> +.vsd_cbcr_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 6),
>> +.vsd_yrgb_gt2 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 5),
>> +.vsd_yrgb_gt4 = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 4),
>> +.bic_coe_sel = VOP_REG(RK3229_WIN0_CTRL1, 0x3, 2),
>> +.cbcr_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 1),
>> +.yrgb_axi_gather_en = VOP_REG(RK3229_WIN0_CTRL1, 0x1, 0),
>> +

[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-vop

[Yakir Yang]

Thanks, Rob

- Yakir

On 01/04/2016 10:11 PM, Rob Herring wrote:
> On Mon, Jan 04, 2016 at 07:50:30PM +0800, Yakir Yang wrote:
>> Signed-off-by: Yakir Yang 
>> ---
>>   Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 1 +
>>   1 file changed, 1 insertion(+)
> Acked-by: Rob Herring 
>
>
>

[PATCH] Fix no fb check

[Meng Yi]

For state->fb may be NULL in fsl_dcu_drm_plane_atomic_check function, if
so, return 0. No need check in fsl_dcu_drm_plane_atomic_update anymore.

Signed-off-by: Meng Yi 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
index 4b13cf9..8965580 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -41,6 +41,9 @@ static int fsl_dcu_drm_plane_atomic_check(struct drm_plane 
*plane,
 {
struct drm_framebuffer *fb = state->fb;

+   if (!state->fb || !state->crtc)
+   return 0;
+
switch (fb->pixel_format) {
case DRM_FORMAT_RGB565:
case DRM_FORMAT_RGB888:
@@ -85,9 +88,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct drm_plane 
*plane,
unsigned int alpha, bpp;
int index, ret;

-   if (!fb)
-   return;
-
index = fsl_dcu_drm_plane_index(plane);
if (index < 0)
return;
-- 
2.1.0.27.g96db324

drm/vc4: v3d: called object '0u' is not a function (next-20160104)

[Eric Anholt]

Stefan Wahren  writes:

> Hi Eric,
>
> i tried to build Linux next-20160104, but vc4 failed with the following
> messages:
>
> ...
>   CC  drivers/gpu/drm/vc4/vc4_v3d.o
> drivers/gpu/drm/vc4/vc4_v3d.c: In function 'vc4_v3d_set_power':
> drivers/gpu/drm/vc4/vc4_v3d.c:157:29: error: called object '0u' is not a
> function
> drivers/gpu/drm/vc4/vc4_v3d.c:159:27: error: called object '0u' is not a
> function
> drivers/gpu/drm/vc4/vc4_v3d.c:160:1: warning: control reaches end of non-void
> function [-Wreturn-type]
> make[4]: *** [drivers/gpu/drm/vc4/vc4_v3d.o] Error 1
> make[3]: *** [drivers/gpu/drm/vc4] Error 2
> make[2]: *** [drivers/gpu/drm] Error 2
> make[1]: *** [drivers/gpu] Error 2
> make: *** [drivers] Error 2
>
> Here the relevant settings:
>
> CONFIG_DRM_VC4=y
> CONFIG_PM_SLEEP=n
>
> It looks like pm_generic_poweroff and pm_generic_resume aren't used as 
> intended.
> They could be NULL.

http://lists.freedesktop.org/archives/dri-devel/2015-December/097509.html

Sadly, the genpd stuff didn't actually work for reset like I thought it
would.  That means reset is broken upstream, for now.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160105/aad7c167/attachment.sig>

[PATCH v4 0/6] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Hi Thierry,

Can you pick up these DSI patches, or would it make more sense for
these to go via someone else?

Thanks,
Archit

On 12/10/2015 06:11 PM, Archit Taneja wrote:
> We are currently restricted when it comes to supporting DSI on devices
> that have a non-DSI control bus. For example, DSI encoder chips are
> available in the market that are configured via i2c. Configuring their
> registers via DSI bus is either optional or not available at all.
>
> These devices still need to pass DSI parameters (data lanes, mode flags
> etc) to the DSI host they are connected to. We don't have a way to do
> that at the moment.
>
> After some discussions on the previous RFC[1], we decided to support this
> by providing additional API in drm_mipi_dsi which lets us create new DSI
> devices without the need of them to have a DT node.
>
> [1]: https://lkml.org/lkml/2015/6/30/42
>
> Changes in v4:
> - Added a new patch that fixes build issues when CONFIG_OF is not set.
>
> Changes in v3:
>
> - Incorporated misc comments by Andrzej. Changed from RFC to a PATCH set.
> - Fixed htmldocs warnings.
>
> Archit Taneja (6):
>drm/dsi: check for CONFIG_OF when defining of_mipi_dsi_device_add
>drm/dsi: Refactor device creation
>drm/dsi: Try to match non-DT dsi devices
>drm/dsi: Check for used channels
>drm/dsi: Add routine to unregister dsi device
>drm/dsi: Get DSI host by DT device node
>
>   drivers/gpu/drm/drm_mipi_dsi.c | 144 
> -
>   include/drm/drm_mipi_dsi.h |  29 +
>   2 files changed, 141 insertions(+), 32 deletions(-)
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

[Bug 93575] Unigine Heaven shows unexpected light stripes

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

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

Vladimir Usikov  changed:

   What|Removed |Added

 Attachment #120790|video/webm  |video/x-matroska
  mime type||

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

[Bug 93575] Unigine Heaven shows unexpected light stripes

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

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

Vladimir Usikov  changed:

   What|Removed |Added

 Attachment #120790|video/x-matroska|video/webm
  mime type||

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

[Bug 93575] Unigine Heaven shows unexpected light stripes

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

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

Vladimir Usikov  changed:

   What|Removed |Added

 Attachment #120790|text/plain  |video/x-matroska
  mime type||

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

[Intel-gfx] [PATCH v2 5/6] drm/i915: Update connector_mask during readout.

[Maarten Lankhorst]

Op 05-01-16 om 10:10 schreef Daniel Vetter:
> On Tue, Jan 05, 2016 at 10:05:21AM +0100, Maarten Lankhorst wrote:
>> Op 05-01-16 om 09:35 schreef Daniel Vetter:
>>> On Mon, Jan 04, 2016 at 12:53:19PM +0100, Maarten Lankhorst wrote:
 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/intel_display.c | 11 ---
  1 file changed, 8 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 1e42309ec40a..b76778d76035 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -15421,6 +15421,7 @@ static void intel_sanitize_crtc(struct intel_crtc 
 *crtc)
WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) < 
 0);
crtc->base.state->active = crtc->active;
crtc->base.enabled = crtc->active;
 +  crtc->base.state->connector_mask = 0;
  
/* Because we only establish the connector -> encoder ->
 * crtc links if something is active, this means the
 @@ -15456,20 +15457,24 @@ static void intel_sanitize_encoder(struct 
 intel_encoder *encoder)
  {
struct intel_connector *connector;
struct drm_device *dev = encoder->base.dev;
 +  struct drm_crtc *crtc = encoder->base.crtc;
bool active = false;
  
/* We need to check both for a crtc link (meaning that the
 * encoder is active and trying to read from a pipe) and the
 * pipe itself being active. */
 -  bool has_active_crtc = encoder->base.crtc &&
 -  to_intel_crtc(encoder->base.crtc)->active;
 +  bool has_active_crtc = crtc && crtc->state->active;
  
for_each_intel_connector(dev, connector) {
if (connector->base.encoder != >base)
continue;
  
active = true;
 -  break;
 +  if (!has_active_crtc)
 +  break;
 +
 +  crtc->state->connector_mask |=
 +  1 << drm_connector_index(>base);
>>> I still think this is the wrong place. Imo this should be done in
>>> intel_modeset_update_connector_atomic_state. It'd be great if we could
>>> somehow share the logic with drm_atomic_set_crtc_for_connector even, but
>>> that's probably over the top.
>>>
>> No it should be done sooner. I want to be able use it anywhere in the
>> .crtc_disable calls without worrying about it..
> Well I don't want to split things up all over. Atm our state recover is a
> complete mess, and we need to start recovering some order in it. Updating
> related things at completely different places without even a comment
> stating why that's required is imo a no-go.
Ok so if I resubmit with a comment in this hunk it will be acceptable?

~Maarten

[Intel-gfx] [PATCH v2 5/6] drm/i915: Update connector_mask during readout.

[Daniel Vetter]

On Tue, Jan 05, 2016 at 10:05:21AM +0100, Maarten Lankhorst wrote:
> Op 05-01-16 om 09:35 schreef Daniel Vetter:
> > On Mon, Jan 04, 2016 at 12:53:19PM +0100, Maarten Lankhorst wrote:
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 11 ---
> >>  1 file changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 1e42309ec40a..b76778d76035 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -15421,6 +15421,7 @@ static void intel_sanitize_crtc(struct intel_crtc 
> >> *crtc)
> >>WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) < 
> >> 0);
> >>crtc->base.state->active = crtc->active;
> >>crtc->base.enabled = crtc->active;
> >> +  crtc->base.state->connector_mask = 0;
> >>  
> >>/* Because we only establish the connector -> encoder ->
> >> * crtc links if something is active, this means the
> >> @@ -15456,20 +15457,24 @@ static void intel_sanitize_encoder(struct 
> >> intel_encoder *encoder)
> >>  {
> >>struct intel_connector *connector;
> >>struct drm_device *dev = encoder->base.dev;
> >> +  struct drm_crtc *crtc = encoder->base.crtc;
> >>bool active = false;
> >>  
> >>/* We need to check both for a crtc link (meaning that the
> >> * encoder is active and trying to read from a pipe) and the
> >> * pipe itself being active. */
> >> -  bool has_active_crtc = encoder->base.crtc &&
> >> -  to_intel_crtc(encoder->base.crtc)->active;
> >> +  bool has_active_crtc = crtc && crtc->state->active;
> >>  
> >>for_each_intel_connector(dev, connector) {
> >>if (connector->base.encoder != >base)
> >>continue;
> >>  
> >>active = true;
> >> -  break;
> >> +  if (!has_active_crtc)
> >> +  break;
> >> +
> >> +  crtc->state->connector_mask |=
> >> +  1 << drm_connector_index(>base);
> > I still think this is the wrong place. Imo this should be done in
> > intel_modeset_update_connector_atomic_state. It'd be great if we could
> > somehow share the logic with drm_atomic_set_crtc_for_connector even, but
> > that's probably over the top.
> >
> No it should be done sooner. I want to be able use it anywhere in the
> .crtc_disable calls without worrying about it..

Well I don't want to split things up all over. Atm our state recover is a
complete mess, and we need to start recovering some order in it. Updating
related things at completely different places without even a comment
stating why that's required is imo a no-go.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm/amd/powerplay: fix a reversed condition

[SF Markus Elfring]

> This test was reversed so it would end up leading to a NULL dereference.
> 
> Fixes: 4630f0faae80 ('drm/amd/powerplay: add Carrizo smu support')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c 
> b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> index e74023b..873a8d2 100644
> --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> @@ -818,7 +818,7 @@ static int cz_smu_fini(struct pp_smumgr *smumgr)
>   return -EINVAL;
>  
>   cz_smu = (struct cz_smumgr *)smumgr->backend;
> - if (!cz_smu) {
> + if (cz_smu) {
>   cgs_free_gpu_mem(smumgr->device,
>   cz_smu->toc_buffer.handle);
>   cgs_free_gpu_mem(smumgr->device,

Was this issue found by an automatic static source code analysis of a tool
like "Smatch"?
https://blogs.oracle.com/linuxkernel/entry/smatch_static_analysis_tool_overview
http://smatch.sourceforge.net/


Would it be useful to detect similar update candidates by the reuse of scripts
for the semantic patch language?
How do you think about to get additional help and support from a software
like Coccinelle for such search patterns?

Regards,
Markus

[PATCH v2 3/3] dt-bindings: add document for rk3229-vop

[Rob Herring]

On Mon, Jan 4, 2016 at 10:00 PM, Yakir Yang  wrote:
> Signed-off-by: Yakir Yang 
> Acked-by: Rob Herring 
> ---
> Changes in v2:
> - acked by Rob

It doesn't hurt, but there is no point to send a new version just to
add acks. The maintainer should add any for the current version. If
you do send a new version with changes, then it is your responsibility
to add acks. Maintainers are not going to look at older versions.

Rob

[Intel-gfx] [PATCH v2 5/6] drm/i915: Update connector_mask during readout.

[Maarten Lankhorst]

Op 05-01-16 om 09:35 schreef Daniel Vetter:
> On Mon, Jan 04, 2016 at 12:53:19PM +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 1e42309ec40a..b76778d76035 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -15421,6 +15421,7 @@ static void intel_sanitize_crtc(struct intel_crtc 
>> *crtc)
>>  WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) < 
>> 0);
>>  crtc->base.state->active = crtc->active;
>>  crtc->base.enabled = crtc->active;
>> +crtc->base.state->connector_mask = 0;
>>  
>>  /* Because we only establish the connector -> encoder ->
>>   * crtc links if something is active, this means the
>> @@ -15456,20 +15457,24 @@ static void intel_sanitize_encoder(struct 
>> intel_encoder *encoder)
>>  {
>>  struct intel_connector *connector;
>>  struct drm_device *dev = encoder->base.dev;
>> +struct drm_crtc *crtc = encoder->base.crtc;
>>  bool active = false;
>>  
>>  /* We need to check both for a crtc link (meaning that the
>>   * encoder is active and trying to read from a pipe) and the
>>   * pipe itself being active. */
>> -bool has_active_crtc = encoder->base.crtc &&
>> -to_intel_crtc(encoder->base.crtc)->active;
>> +bool has_active_crtc = crtc && crtc->state->active;
>>  
>>  for_each_intel_connector(dev, connector) {
>>  if (connector->base.encoder != >base)
>>  continue;
>>  
>>  active = true;
>> -break;
>> +if (!has_active_crtc)
>> +break;
>> +
>> +crtc->state->connector_mask |=
>> +1 << drm_connector_index(>base);
> I still think this is the wrong place. Imo this should be done in
> intel_modeset_update_connector_atomic_state. It'd be great if we could
> somehow share the logic with drm_atomic_set_crtc_for_connector even, but
> that's probably over the top.
>
No it should be done sooner. I want to be able use it anywhere in the 
.crtc_disable calls without worrying about it..

~Maarten

[Intel-gfx] [PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

[Daniel Vetter]

On Tue, Dec 08, 2015 at 12:01:57PM +, Daniel Stone wrote:
> Hi,
> 
> On 8 December 2015 at 08:49, Daniel Vetter  wrote:
> > We want this for consistency with existing page_flip semantics.
> >
> > Since this spurred quite a discussion on IRC also document why we
> > reject even generation when the pipe is off: It's not that it's hard
> > to implement, but userspace has a track recording proofing that it's
> > way too easy to accidentally abuse and cause havoc. We want to make
> > sure userspace doesn't get away with that.
> >
> > v2: Somehow thought we do reject events already, but that code only
> > existed in my imagination ... Also suggestions from Thierry.
> 
> What a beautifully-coloured shed.
> 
> Reviewed-by: Daniel Stone 

Added Ilia's spelling fixes and merged to drm-misc, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] [trivial] drm/i915 Fix typos in i915_gem_fence.c

[Randy Dunlap]

On 01/04/16 19:29, Masanari Iida wrote:
> This patch fix some spelling typos found in Documentation/Docbook
> gpu/ch04s03.html.  This file was generated from comments within
> source, so I have to fix typos in i915_gem_fence.c.
> 
> Signed-off-by: Masanari Iida 
> ---
>  drivers/gpu/drm/i915/i915_gem_fence.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Acked-by: Randy Dunlap 

Thanks.


-- 
~Randy

WARNING: CPU: 3 PID: 914 at include/drm/drm_gem.h:146 udl_dumb_create+0xdd/0xf0 [udl]()

[Daniel Vetter]

On Tue, Jan 05, 2016 at 08:46:19AM +0100, poma wrote:
> 
> Hi Fi
> 
> Please take a loo kat
> https://bugzilla.redhat.com/show_bug.cgi?id=1295646

Patches to fix these have been hanging around on the list for weeks,
looking for review ... The entire series starts with "drm/armada: Use
unlocked gem unreferencing". Care to review them all?

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

[Intel-gfx] [PATCH v2 6/6] drm/atomic: Remove drm_atomic_connectors_for_crtc.

[Daniel Vetter]

On Mon, Jan 04, 2016 at 12:53:20PM +0100, Maarten Lankhorst wrote:
> Now that connector_mask is reliable there's no need for this
> function any more.
> 
> Signed-off-by: Maarten Lankhorst 

Since this doesn't touch i915 I figured I can merge this one too. So
except for the previous i915 patch it's now all in drm-misc.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c| 30 --
>  drivers/gpu/drm/drm_atomic_helper.c | 10 --
>  drivers/gpu/drm/vc4/vc4_crtc.c  |  2 +-
>  include/drm/drm_atomic.h|  4 
>  4 files changed, 5 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 14b321580517..d3ed12447fbb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1183,36 +1183,6 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
> *state,
>  EXPORT_SYMBOL(drm_atomic_add_affected_planes);
>  
>  /**
> - * drm_atomic_connectors_for_crtc - count number of connected outputs
> - * @state: atomic state
> - * @crtc: DRM crtc
> - *
> - * This function counts all connectors which will be connected to @crtc
> - * according to @state. Useful to recompute the enable state for @crtc.
> - */
> -int
> -drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
> -struct drm_crtc *crtc)
> -{
> - struct drm_connector *connector;
> - struct drm_connector_state *conn_state;
> -
> - int i, num_connected_connectors = 0;
> -
> - for_each_connector_in_state(state, connector, conn_state, i) {
> - if (conn_state->crtc == crtc)
> - num_connected_connectors++;
> - }
> -
> - DRM_DEBUG_ATOMIC("State %p has %i connectors for [CRTC:%d:%s]\n",
> -  state, num_connected_connectors,
> -  crtc->base.id, crtc->name);
> -
> - return num_connected_connectors;
> -}
> -EXPORT_SYMBOL(drm_atomic_connectors_for_crtc);
> -
> -/**
>   * drm_atomic_legacy_backoff - locking backoff for legacy ioctls
>   * @state: atomic state
>   *
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 27dd68f946e6..13b771cb0d35 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -464,7 +464,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>* crtc only changed its mode but has the same set of connectors.
>*/
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - int num_connectors;
> + bool has_connectors =
> + !!crtc_state->connector_mask;
>  
>   /*
>* We must set ->active_changed after walking connectors for
> @@ -493,10 +494,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (ret != 0)
>   return ret;
>  
> - num_connectors = drm_atomic_connectors_for_crtc(state,
> - crtc);
> -
> - if (crtc_state->enable != !!num_connectors) {
> + if (crtc_state->enable != has_connectors) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled/connectors 
> mismatch\n",
>crtc->base.id, crtc->name);
>  
> @@ -1755,7 +1753,7 @@ static int update_output_state(struct drm_atomic_state 
> *state,
>   if (crtc == set->crtc)
>   continue;
>  
> - if (!drm_atomic_connectors_for_crtc(state, crtc)) {
> + if (!crtc_state->connector_mask) {
>   ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
>   NULL);
>   if (ret < 0)
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 2168a99d59aa..aa7ed24a41c7 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -327,7 +327,7 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
>   /* The pixelvalve can only feed one encoder (and encoders are
>* 1:1 with connectors.)
>*/
> - if (drm_atomic_connectors_for_crtc(state->state, crtc) > 1)
> + if (hweight32(state->connector_mask) > 1)
>   return -EINVAL;
>  
>   drm_atomic_crtc_state_for_each_plane(plane, state) {
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index d8576ac55693..d3eaa5df187a 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -130,10 +130,6 @@ int __must_check
>  drm_atomic_add_affected_planes(struct drm_atomic_state *state,
>  struct drm_crtc *crtc);
>  
> -int
> -drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
> -struct drm_crtc *crtc);
> -
>  void drm_atomic_legacy_backoff(struct drm_atomic_state *state);
>  
>  void
> -- 
> 2.1.0
> 

[Intel-gfx] [PATCH v2 4/6] drm/atomic: add connector mask to drm_crtc_state.

[Daniel Vetter]

On Mon, Jan 04, 2016 at 12:53:18PM +0100, Maarten Lankhorst wrote:
> It can be useful to iterate over connectors without grabbing
> connection_mutex. It can also be used to see how many connectors
> are on a crtc without iterating over the list.
> 
> Signed-off-by: Maarten Lankhorst 

Merged up to this patch here, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c | 11 +++
>  include/drm/drm_crtc.h   |  3 +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 6a21e5c378c1..14b321580517 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1063,10 +1063,21 @@ drm_atomic_set_crtc_for_connector(struct 
> drm_connector_state *conn_state,
>  {
>   struct drm_crtc_state *crtc_state;
>  
> + if (conn_state->crtc && conn_state->crtc != crtc) {
> + crtc_state = 
> drm_atomic_get_existing_crtc_state(conn_state->state,
> + 
> conn_state->crtc);
> +
> + crtc_state->connector_mask &=
> + ~(1 << drm_connector_index(conn_state->connector));
> + }
> +
>   if (crtc) {
>   crtc_state = drm_atomic_get_crtc_state(conn_state->state, crtc);
>   if (IS_ERR(crtc_state))
>   return PTR_ERR(crtc_state);
> +
> + crtc_state->connector_mask |=
> + 1 << drm_connector_index(conn_state->connector);
>   }
>  
>   conn_state->crtc = crtc;
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index c2f98ba2bb98..dd0db4ceab26 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -301,6 +301,7 @@ struct drm_plane_helper_funcs;
>   * @active_changed: crtc_state->active has been toggled.
>   * @connectors_changed: connectors to this crtc have been updated
>   * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
> + * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of 
> attached connectors
>   * @last_vblank_count: for helpers and drivers to capture the vblank of the
>   *   update to ensure framebuffer cleanup isn't done too early
>   * @adjusted_mode: for use by helpers and drivers to compute adjusted mode 
> timings
> @@ -334,6 +335,8 @@ struct drm_crtc_state {
>*/
>   u32 plane_mask;
>  
> + u32 connector_mask;
> +
>   /* last_vblank_count: for vblank waits before cleanup */
>   u32 last_vblank_count;
>  
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH v2 2/6] drm/atomic: Add __drm_atomic_helper_connector_reset, v2.

[Daniel Vetter]

On Mon, Jan 04, 2016 at 12:53:16PM +0100, Maarten Lankhorst wrote:
> This is useful for drivers that subclass connector_state, like tegra.
> 
> Changes since v1:
> - Docbook updates.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 30 ++
>  include/drm/drm_atomic_helper.h |  2 ++
>  2 files changed, 28 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 63f925b75357..27dd68f946e6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2607,6 +2607,28 @@ void drm_atomic_helper_plane_destroy_state(struct 
> drm_plane *plane,
>  EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
>  
>  /**
> + * __drm_atomic_helper_connector_reset - reset state on connector
> + * @connector: drm connector
> + * @conn_state: connector state to assign
> + *
> + * Initializes the newly allocated @conn_state and assigns it to
> + * #connector ->state, usually required when initializing the drivers
> + * or when called from the ->reset hook.
> + *
> + * This is useful for drivers that subclass the connector state.
> + */
> +void
> +__drm_atomic_helper_connector_reset(struct drm_connector *connector,
> + struct drm_connector_state *conn_state)
> +{
> + if (conn_state)
> + conn_state->connector = connector;
> +
> + connector->state = conn_state;
> +}
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_reset);

It's a bit strange that we don't have __*reset functions for crtc/plane
now, especially since that would uncover that probably we should move
cleaning up the old state into this helper (to share more code). That can
be done by simply calling ->atomic_state_destroy. Callers would then only
allocate a suitable struct, call this func and init any driver-private
state.

But this here won't hurt, so merged it.
-Daniel

> +
> +/**
>   * drm_atomic_helper_connector_reset - default ->reset hook for connectors
>   * @connector: drm connector
>   *
> @@ -2616,11 +2638,11 @@ EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
>   */
>  void drm_atomic_helper_connector_reset(struct drm_connector *connector)
>  {
> - kfree(connector->state);
> - connector->state = kzalloc(sizeof(*connector->state), GFP_KERNEL);
> + struct drm_connector_state *conn_state =
> + kzalloc(sizeof(*conn_state), GFP_KERNEL);
>  
> - if (connector->state)
> - connector->state->connector = connector;
> + kfree(connector->state);
> + __drm_atomic_helper_connector_reset(connector, conn_state);
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
>  
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index a286cce98720..89d008dc08e2 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -126,6 +126,8 @@ void __drm_atomic_helper_plane_destroy_state(struct 
> drm_plane *plane,
>  void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
>  
> +void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> +  struct drm_connector_state 
> *conn_state);
>  void drm_atomic_helper_connector_reset(struct drm_connector *connector);
>  void
>  __drm_atomic_helper_connector_duplicate_state(struct drm_connector 
> *connector,
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 2/2] drm: Remove opencoded drm_gem_object_release_handle()

[Chris Wilson]

drm_gem_handle_delete() contains its own version of
drm_gem_object_release_handle(), so lets just call the release method
instead.

Reported-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_gem.c | 55 +--
 1 file changed, 24 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 320e406b..2e8c77e71e1f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -244,6 +244,29 @@ drm_gem_object_handle_unreference_unlocked(struct 
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
 }

+/*
+ * Called at device or object close to release the file's
+ * handle references on objects.
+ */
+static int
+drm_gem_object_release_handle(int id, void *ptr, void *data)
+{
+   struct drm_file *file_priv = data;
+   struct drm_gem_object *obj = ptr;
+   struct drm_device *dev = obj->dev;
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_gem_remove_prime_handles(obj, file_priv);
+   drm_vma_node_revoke(>vma_node, file_priv->filp);
+
+   if (dev->driver->gem_close_object)
+   dev->driver->gem_close_object(obj, file_priv);
+
+   drm_gem_object_handle_unreference_unlocked(obj);
+
+   return 0;
+}
+
 /**
  * drm_gem_handle_delete - deletes the given file-private handle
  * @filp: drm file-private structure to use for the handle look up
@@ -282,14 +305,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(>object_idr, handle);
spin_unlock(>table_lock);

-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_gem_remove_prime_handles(obj, filp);
-   drm_vma_node_revoke(>vma_node, filp->filp);
-
-   if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, filp);
-   drm_gem_object_handle_unreference_unlocked(obj);
-
+   drm_gem_object_release_handle(handle, obj, filp);
return 0;
 }
 EXPORT_SYMBOL(drm_gem_handle_delete);
@@ -726,29 +742,6 @@ drm_gem_open(struct drm_device *dev, struct drm_file 
*file_private)
spin_lock_init(_private->table_lock);
 }

-/*
- * Called at device close to release the file's
- * handle references on objects.
- */
-static int
-drm_gem_object_release_handle(int id, void *ptr, void *data)
-{
-   struct drm_file *file_priv = data;
-   struct drm_gem_object *obj = ptr;
-   struct drm_device *dev = obj->dev;
-
-   if (drm_core_check_feature(dev, DRIVER_PRIME))
-   drm_gem_remove_prime_handles(obj, file_priv);
-   drm_vma_node_revoke(>vma_node, file_priv->filp);
-
-   if (dev->driver->gem_close_object)
-   dev->driver->gem_close_object(obj, file_priv);
-
-   drm_gem_object_handle_unreference_unlocked(obj);
-
-   return 0;
-}
-
 /**
  * drm_gem_release - release file-private GEM resources
  * @dev: drm_device which is being closed by userspace
-- 
2.6.4

[PATCH 1/2] drm: Do not set outparam on error during GEM handle allocation

[Chris Wilson]

Good practice dictates that we do not leak stale information to our
callers, and should avoid overwriting an outparam on an error path.

Reported-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_gem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1b0c2c127072..320e406b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -331,6 +331,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
   u32 *handlep)
 {
struct drm_device *dev = obj->dev;
+   u32 handle;
int ret;

WARN_ON(!mutex_is_locked(>object_name_lock));
@@ -353,7 +354,7 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
if (ret < 0)
goto err_unref;

-   *handlep = ret;
+   handle = ret;

ret = drm_vma_node_allow(>vma_node, file_priv->filp);
if (ret)
@@ -365,13 +366,14 @@ drm_gem_handle_create_tail(struct drm_file *file_priv,
goto err_revoke;
}

+   *handlep = handle;
return 0;

 err_revoke:
drm_vma_node_revoke(>vma_node, file_priv->filp);
 err_remove:
spin_lock(_priv->table_lock);
-   idr_remove(_priv->object_idr, *handlep);
+   idr_remove(_priv->object_idr, handle);
spin_unlock(_priv->table_lock);
 err_unref:
drm_gem_object_handle_unreference_unlocked(obj);
-- 
2.6.4

[Intel-gfx] [PATCH v2 5/6] drm/i915: Update connector_mask during readout.

[Daniel Vetter]

On Mon, Jan 04, 2016 at 12:53:19PM +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1e42309ec40a..b76778d76035 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15421,6 +15421,7 @@ static void intel_sanitize_crtc(struct intel_crtc 
> *crtc)
>   WARN_ON(drm_atomic_set_mode_for_crtc(crtc->base.state, NULL) < 
> 0);
>   crtc->base.state->active = crtc->active;
>   crtc->base.enabled = crtc->active;
> + crtc->base.state->connector_mask = 0;
>  
>   /* Because we only establish the connector -> encoder ->
>* crtc links if something is active, this means the
> @@ -15456,20 +15457,24 @@ static void intel_sanitize_encoder(struct 
> intel_encoder *encoder)
>  {
>   struct intel_connector *connector;
>   struct drm_device *dev = encoder->base.dev;
> + struct drm_crtc *crtc = encoder->base.crtc;
>   bool active = false;
>  
>   /* We need to check both for a crtc link (meaning that the
>* encoder is active and trying to read from a pipe) and the
>* pipe itself being active. */
> - bool has_active_crtc = encoder->base.crtc &&
> - to_intel_crtc(encoder->base.crtc)->active;
> + bool has_active_crtc = crtc && crtc->state->active;
>  
>   for_each_intel_connector(dev, connector) {
>   if (connector->base.encoder != >base)
>   continue;
>  
>   active = true;
> - break;
> + if (!has_active_crtc)
> + break;
> +
> + crtc->state->connector_mask |=
> + 1 << drm_connector_index(>base);

I still think this is the wrong place. Imo this should be done in
intel_modeset_update_connector_atomic_state. It'd be great if we could
somehow share the logic with drm_atomic_set_crtc_for_connector even, but
that's probably over the top.
-Daniel

>   }
>  
>   if (active && !has_active_crtc) {
> -- 
> 2.1.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 1/1] apple-gmux: Add initial documentation

[Bruno Prémont]

On Mon, 4 Jan 2016 17:52:06 +0100 Lukas Wunner wrote:
> Document what I've learned so far about the gmux so that we can
> collaboratively reverse-engineer its remaining unknown bits
> without everyone having to start from scratch.
> 
> The DOC sections are bound together in the gpu.tmpl DocBook
> under a new vga_switcheroo "Handlers" chapter. Eventually
> this should be amended with documentation about the four other
> handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM,
> radeon ATPX, amdgpu ATPX).
> 
> Requires kernel-doc with asciidoc support.
> 
> The EFI variable was reverse-engineered by Bruno Bierbaumer
>  and Andreas Heider .
> 
> Some of the remaining open questions:
> 
> * How are vblank intervals synchronized on retinas to achieve seamless
>   switching? Is the DP mux capable of this? It's not mentioned in the
>   data sheets. Or is it done at the OS level, i.e. do we have to
>   synchronize vblank intervals between DRM drivers? There's a signal
>   coming from the panel connector and going into gmux, could this be
>   the vblank signal as received by the panel to properly time the
>   switch?
> 
> * On retinas there's an I2C bus between gmux and the connector of the
>   right I/O board, apparently leading to the Parade PS8401A HDMI
>   repeater. What is this for, is it controlled via gmux registers?
>   Data sheet:
>   http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/
> 
> * On retinas there's an I2C bus between gmux and the LED driver.
>   Pre-retinas connected the LED driver to SMBUS. Are there additional
>   gmux registers on retinas to control it?
> 
> * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the
>   retina MacBook Pro. The Mac Pro doesn't have a built-in display,
>   so what is its purpose? Power control of the dual FirePro GPUs?
>   Switching of the external DP/Thunderbolt ports? The iFixit teardown
>   clearly shows one TI HD3SS212 DisplayPort mux on the logic board next
>   to one of the three Thunderbolt controllers. However six muxes would
>   be necessary to switch all six ports between GPUs. The mux is probably
>   necessary for one of the display configurations allowed by Apple,
>   but which one?
>   https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778
>   https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge
>   https://support.apple.com/en-us/HT202801
> 
> * Registers we haven't decoded yet:
>   0x700 32 Bit configmap?
>   0x708 32 Bit power sequence?
>   0x712  8 Bit status of clock from panel on retinas?
>   0x713  8 Bit dito?
>   0x724 16 Bit backlight, raw value?
>   0x760 32 Bit backlight
>   0x764 32 Bit backlight
>   0x768  8 Bit backlight
>   0x76a 16 Bit backlight
>   0x76c 16 Bit backlight
>   0x76e 16 Bit backlight
>   0x77fedp/dp/hdmi probe? retina only.

Missing is also precise knowledge as to what the gmux depends on.

[PATCH 3/3] drm: Use a normal idr allocation for the obj->name

[Daniel Vetter]

On Mon, Jan 04, 2016 at 05:31:14PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 10:11:01AM +, Chris Wilson wrote:
> > Unlike the handle, the name table uses a sleeping mutex rather than a
> > spinlock. The allocation is in a normal context, and we can use the
> > simpler sleeping gfp_t, rather than have to take from the atomic
> > reserves.
> > 
> > Signed-off-by: Chris Wilson 
> 
> Reviewed-by: Ville Syrjälä 

All 3 merged to drm-misc, thanks for patches
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_gem.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index ad955d7c99fd..1b0c2c127072 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -642,7 +642,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> > return -ENOENT;
> >  
> > mutex_lock(>object_name_lock);
> > -   idr_preload(GFP_KERNEL);
> > /* prevent races with concurrent gem_close. */
> > if (obj->handle_count == 0) {
> > ret = -ENOENT;
> > @@ -650,7 +649,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> > }
> >  
> > if (!obj->name) {
> > -   ret = idr_alloc(>object_name_idr, obj, 1, 0, GFP_NOWAIT);
> > +   ret = idr_alloc(>object_name_idr, obj, 1, 0, GFP_KERNEL);
> > if (ret < 0)
> > goto err;
> >  
> > @@ -661,7 +660,6 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> > ret = 0;
> >  
> >  err:
> > -   idr_preload_end();
> > mutex_unlock(>object_name_lock);
> > drm_gem_object_unreference_unlocked(obj);
> > return ret;
> > -- 
> > 2.6.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

答复: [PATCHv7 0/5] Add initial support for slimport anx78xx

[Chengxiang Jiao]

Hi Enric,

Just to confirm with you.
This version is from https://chromium-review.googlesource.com/#/c/308442/11, 
right?

Chengxiang
2016/1/5


-邮件原件-
发件人: Enric Balletbo i Serra [mailto:eballetbo at gmail.com] 
发送时间: 2016年1月4日 5:38
收件人: devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; 
dri-devel at lists.freedesktop.org; devel at driverdev.osuosl.org; treding at 
nvidia.com
抄送: robh+dt at kernel.org; pawel.moll at arm.com; mark.rutland at arm.com; 
ijc+devicetree at hellion.org.uk; galak at codeaurora.org; airlied at linux.ie; 
gregkh at linuxfoundation.org; sjoerd.simons at collabora.co.uk; javier at 
dowhile0.org; Sheng Pan; nathan.chung at mediatek.com; djkurtz at chromium.org; 
drinkcat at chromium.org; laurent.pinchart at ideasonboard.com; dan.carpenter 
at oracle.com; jb.tsai at mediatek.com; cawa.cheng at mediatek.com; eddie.huang 
at mediatek.com; Chengxiang Jiao; emil.l.velikov at gmail.com
主题: [PATCHv7 0/5] Add initial support for slimport anx78xx

Hi all,

This is another version of the patch set to introduce the anx7814 transmitter.
Any comments are welcome.

The following series add initial support for the Slimport ANX7814 transmitter, 
a ultra-low power Full-HD (1080p60) transmitter designed for portable device.

The driver was originally created and based from the work of Junhua Xia from 
Analogix. This driver is a refactor of the original driver and fixes different 
coding style lines, and different errors/warnings reported by checkpatch. Also 
there were things that I noticed that we need to change like:

 - Convert the numbered GPIO API to the new descriptor based GPIO API.
 - Review the DT binding
 - Add missing MODULE_DEVICE_TABLE(of, ...);
 - Fix Makefiles and Kconfig to build conditionally.
 - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and
  .resume callbacks.
 - Move to use managed device resources.
 - Remove dead/unused code.
 - And others ...

Enric Balletbo i Serra (5):
  drm/dp: add DPCD definitions from DP 1.1
  hdmi: added functions for MPEG InfoFrames
  of: Add vendor prefix for Analogix Semiconductor, Inc.
  devicetree: Add new ANX7814 SlimPort transmitter binding.
  drm: bridge: anx78xx: Add anx78xx driver support by analogix.

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 .../devicetree/bindings/video/bridge/anx7814.txt   |   39 +
 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig |5 +
 drivers/gpu/drm/bridge/anx78xx/Makefile|4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h   |   44 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c  |  334 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c   | 3194 
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h   |  110 +
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h   |  737 +
 drivers/video/hdmi.c   |  156 +
 include/drm/drm_dp_helper.h|   10 +
 include/linux/hdmi.h   |   24 +
 14 files changed, 4661 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

--
2.1.0

WARNING: CPU: 3 PID: 914 at include/drm/drm_gem.h:146 udl_dumb_create+0xdd/0xf0 [udl]()

[poma]

Hi Fi

Please take a loo kat
https://bugzilla.redhat.com/show_bug.cgi?id=1295646

[Bug 93471] [radeonsi] power consumption on pitcairn card stays high after 2. monitor disconnected

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

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

Michel Dänzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|DRM/Radeon  |Driver/Radeon
Version|XOrg git|git
 Resolution|--- |FIXED
   Assignee|dri-devel at lists.freedesktop |xorg-driver-ati at 
lists.x.org
   |.org|
Product|DRI |xorg
 QA Contact||xorg-team at lists.x.org

--- Comment #8 from Michel Dänzer  ---
(In reply to Malte from comment #7)
> I used the source from Debian, added the source of the mentioned patch and
> build a new .deb packet. Now
> xrandr --output HDMI-0 --off
> reduces power as expected, thanks for pointing to the patch :)

No worries, thanks for testing. Resolving this report as fixed.


> But the question remains if it is possible to get the lower power
> consumption even with two screens (showing the same picture).

If both screens are using HDMI connections and the exact same timings, using
the same CRTC for both may work.

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