[PATCHv3 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[Dan Carpenter]

On Thu, Sep 10, 2015 at 06:35:52PM +0200, Enric Balletbo i Serra wrote:
> diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx.h 
> b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
> new file mode 100644
> index 000..4f6dd1d
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef __ANX78xx_H
> +#define __ANX78xx_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AUX_ERR  1
> +#define AUX_OK   0

Get rid of these.  They aren't used much and we could easily use normal
error codes instead.

> +
> +struct anx78xx_platform_data {
> + struct gpio_desc *gpiod_pd;
> + struct gpio_desc *gpiod_reset;
> + spinlock_t lock;
> +};
> +
> +struct anx78xx {
> + struct i2c_client *client;
> + struct anx78xx_platform_data *pdata;
> + struct delayed_work work;
> + struct workqueue_struct *workqueue;
> + struct mutex lock;
> +};
> +
> +void anx78xx_poweron(struct anx78xx *data);
> +void anx78xx_poweroff(struct anx78xx *data);
> +
> +#endif
> diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c 
> b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
> new file mode 100644
> index 000..b92d2bc
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "anx78xx.h"
> +#include "slimport_tx_drv.h"
> +
> +void anx78xx_poweron(struct anx78xx *anx78xx)
> +{
> + struct device *dev = >client->dev;
> + struct anx78xx_platform_data *pdata = anx78xx->pdata;
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value_cansleep(pdata->gpiod_pd, 0);
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 1);
> +
> + dev_dbg(dev, "power on\n");

Remove these debug printks.  Use ftrace instead.

> +}
> +
> +void anx78xx_poweroff(struct anx78xx *anx78xx)
> +{
> + struct device *dev = >client->dev;
> + struct anx78xx_platform_data *pdata = anx78xx->pdata;
> +
> + gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
> + usleep_range(1000, 2000);
> +
> + gpiod_set_value_cansleep(pdata->gpiod_pd, 1);
> + usleep_range(1000, 2000);
> +
> + dev_dbg(dev, "power down\n");

Delete.

> +}
> +
> +static int anx78xx_init_gpio(struct anx78xx *anx78xx)
> +{
> + struct device *dev = >client->dev;
> + struct anx78xx_platform_data *pdata = anx78xx->pdata;
> + int ret;
> +
> + /* gpio for chip power down */
> + pdata->gpiod_pd = devm_gpiod_get(dev, "pd", GPIOD_OUT_HIGH);
> + if (IS_ERR(pdata->gpiod_pd)) {
> + dev_err(dev, "unable to claim pd gpio\n");
> + ret = PTR_ERR(pdata->gpiod_pd);
> + return ret;


The ret variable isn't necessary in this function.

> + }
> +
> + /* gpio for chip reset */
> + pdata->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(pdata->gpiod_reset)) {
> + dev_err(dev, "unable to claim reset gpio\n");
> + ret = PTR_ERR(pdata->gpiod_reset);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int anx78xx_system_init(struct anx78xx *anx78xx)
> +{
> + struct device *dev = >client->dev;
> + int ret;
> +
> + ret = sp_chip_detect(anx78xx);

Make sp_chip_detect() use normal error codes.

> + if (ret == 0) {
> + anx78xx_poweroff(anx78xx);
> + dev_err(dev, "failed to detect anx78xx\n");
> + return -ENODEV;
> + }
> +
> + sp_tx_variable_init();
> + return 0;
> +}
> +
> +static void anx78xx_work_func(struct work_struct *work)
> +{
> + struct anx78xx *anx78xx = container_of(work, struct anx78xx,
> 

[Bug 92082] Build on Solaris: xf86drm.c:3021: error: 'PATH_MAX' undeclared (first use in this function)

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

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

Bug ID: 92082
   Summary: Build on Solaris: xf86drm.c:3021: error: 'PATH_MAX'
undeclared (first use in this function)
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Solaris
Status: NEW
  Severity: normal
  Priority: medium
 Component: libdrm
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: evgeny.v.litvinenko at gmail.com

commit 291b2bb92c5fc90101417b80bbdc6c994be5fff2 (xf86drm: move ifdef __linux__
guards where needed)
introduces the following error when build on illumos (OpenIndiana):

xf86drm.c: In function 'drmGetDevices':
xf86drm.c:3021: error: 'PATH_MAX' undeclared (first use in this function)
xf86drm.c:3021: error: (Each undeclared identifier is reported only once
xf86drm.c:3021: error: for each function it appears in.)

OpenIndiana has the line
#define PATH_MAX1024/* max # of characters in a path name */
in /usr/include/limits.h

May be xf86drm.c should #include limits.h?

-- 
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/20150922/795c17bb/attachment.html>

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90()

[Borislav Petkov]

Hi Alex,

On Tue, Sep 22, 2015 at 03:58:03PM -0400, Alex Deucher wrote:
> What system is this?

my workstation - an

"To be filled by O.E.M. To be filled by O.E.M./M5A97 EVO R2.0, BIOS 1503 
01/16/2013"

you gotta love the "To be filled" crap. In any case, it is an ASUS M5A97
EVO R2.0. RD890 chip AFAICT.

> What GPU are you using?

RV635. Here's some dmesg:

[6.489016] [drm] initializing kernel modesetting (RV635 0x1002:0x9598 
0x1043:0x01DA).
[7.509177] radeon :01:00.0: VRAM: 512M 0x - 
0x1FFF (512M used)
[7.518010] radeon :01:00.0: GTT: 512M 0x2000 - 
0x3FFF
[7.525724] [drm] Detected VRAM RAM=512M, BAR=256M
[7.530608] [drm] RAM width 128bits DDR
[7.535168] [TTM] Zone  kernel: Available graphics memory: 8132226 kiB
[7.541779] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[7.548420] [TTM] Initializing pool allocator
[7.552896] [TTM] Initializing DMA pool allocator
[7.558176] [drm] radeon: 512M of VRAM memory ready
[7.563131] [drm] radeon: 512M of GTT memory ready.
[7.568151] [drm] Loading RV635 Microcode
[7.577382] [drm] Internal thermal controller without fan control
[7.584349] [drm] radeon: power management initialized
[7.590443] [drm] GART: num cpu pages 131072, num gpu pages 131072
[7.597266] [drm] enabling PCIE gen 2 link speeds, disable with 
radeon.pcie_gen2=0
[7.624386] [drm] PCIE GART of 512M enabled (table at 0x00254000).
[7.631544] radeon :01:00.0: WB enabled
[7.635794] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x2c00 and cpu addr 0x880427ef7c00
[7.647039] radeon :01:00.0: fence driver on ring 5 use gpu addr 
0x000521d0 and cpu addr 0xc98121d0
[7.657924] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[7.664601] [drm] Driver supports precise vblank timestamp query.
[7.670780] radeon :01:00.0: radeon: MSI limited to 32-bit
[7.676801] radeon :01:00.0: radeon: using MSI.
[7.681863] [drm] radeon: irq initialized.
[7.717757] [drm] ring test on 0 succeeded in 0 usecs
[7.897466] [drm] ring test on 5 succeeded in 1 usecs
[7.902585] [drm] UVD initialized successfully.
[7.908108] [drm] ib test on ring 0 succeeded in 0 usecs
[8.558968] [drm] ib test on ring 5 succeeded
[8.568734] [drm] Radeon Display Connectors
[8.573005] [drm] Connector 0:
[8.576189] [drm]   DVI-I-1
[8.579062] [drm]   HPD1
[8.581657] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 
0x7e5c
[8.589172] [drm]   Encoders:
[8.592234] [drm] DFP1: INTERNAL_UNIPHY
[8.596492] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[8.601182] [drm] Connector 1:
[8.604302] [drm]   DIN-1
[8.607012] [drm]   Encoders:
[8.610043] [drm] TV1: INTERNAL_KLDSCP_DAC2
[8.614642] [drm] Connector 2:
[8.617760] [drm]   DVI-I-2
[8.620621] [drm]   HPD2
[8.623226] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
0x7e4c
[8.630719] [drm]   Encoders:
[8.633749] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[8.638436] [drm] DFP2: INTERNAL_KLDSCP_LVTMA
[8.719815] [drm] fb mappable at 0xC0355000
[8.724089] [drm] vram apper at 0xC000
[8.728243] [drm] size 9216000
[8.731371] [drm] fb depth is 24
[8.734664] [drm]pitch is 7680
[8.739009] fbcon: radeondrmfb (fb0) is primary device
[8.802887] Console: switching to colour frame buffer device 240x75
[8.818487] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[8.824948] radeon :01:00.0: registered panic notifier
[8.846452] [drm] Initialized radeon 2.42.0 20080528 for :01:00.0 on 
minor 0

> Can you bisect?

It is my workstation so it will take longer but I'll try.

If you can think of some particular commits I should try, let me know.

Btw, I have the following things selected in my config, maybe
something's missing there:

CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_TTM=y
# CONFIG_DRM_I2C_ADV7511 is not set
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_USERPTR is not set
# CONFIG_DRM_RADEON_UMS is not set
CONFIG_DRM_AMDGPU=y
# CONFIG_DRM_AMDGPU_CIK is not set
# CONFIG_DRM_AMDGPU_USERPTR is not set
# CONFIG_DRM_NOUVEAU is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_DRM_VGEM is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_QXL is not set
# CONFIG_DRM_BOCHS is not set
# 

[regression] [git pull] drm for 4.3

[Dave Jones]

On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote:
 > On Tue, Sep 22, 2015 at 05:13:55PM +0200, Daniel Vetter wrote:
 > > On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
 > > > Cc'ing Maarten and Matt; I'm guessing this may be related to one of
 > > > their recent patches.
 > 
 > Sounds like this showed up before my recent work, but I think I might
 > have seen similar problems while working on atomic watermarks; the
 > issues I was seeing were because the initial hardware readout could
 > leave primary->visible set to true even when the CRTC was off.  My
 > series (which is still under development) contains this patch to fix
 > that:
 > 
 > http://patchwork.freedesktop.org/patch/59564/
 > 
 > Does applying that help with the problems reported here?

No difference at all for me.

Dave

block device backed by DRM buffer object

[Steven Newbury]

On Mon, 2015-09-21 at 15:05 +0200, Christian König wrote:
> In general a rather interesting idea and actually shouldn't be to
> hard to implement.
> 
> The crux is that allocating memory is device driver dependent, so
> there isn't a general purpose API for doing so.
> 
> Additional to that the CPU invisible VRAM is only accessible by the
> GPU so you at least need to be able to submit DMA commands to copy
> the data back and forth.
> 
> For an experiment I suggest you do this with Radeon first and if that
> works generalize from there.
> 
Thanks for the feedback.  I've been studying the code, and it looks
like everything I need for Radeon is in radeon_test.c.  As a proof of
concept I'm going to initially hack it into an mtd device driver with
static allocation through module params.

This is pushing my knowledge quite a bit.  Just to make sure I'm on the
right track, this is what I'm attempting:

- Grab the pointer to class drm (how? I really need some help here)

- Walk the enumerated drm devices

- For the specified drm card if it's radeon:
  - use radeon_bo_create() to create a bo in RADEON_GEM_DOMAIN_VRAM of
specified size
  - create a bo in gtt for DMA to/from GPU memory

For reads/writes DMA from/to card VRAM bo and copy from/to gtt bo and
userspace


I guess it would be easier to do this as an add-on to the radeon drm
driver since it wouldn't require walking the drm devices to get the
radeon_device pointer but it makes more sense to me to just add a
reference count to the drm device as an external module.

> Regards,
> Christian.
> 
> On 21.09.2015 13:33, Steven Newbury wrote:
> > I have a mostly* headless server containing a Radeon discrete GPU.
> >  It
> > occured to me that having a GiB or two of high speed memory sitting
> > unused is pretty wasteful. Not an original thought; indeed there's
> > a
> > Gentoo wiki which describes how to map the memory as a mtd device:
> >  
> > http://www.gentoo-wiki.info/TIP_Use_memory_on_video_card_as_swap
> > 
> > There's also a driver (cudaram) written by Piotr Jaroszyński which
> > allocates memory through CUDA and maps it to a block device:
> > 
> > http://blog.piotrj.org/2011/03/cudaram-block-device-exposing-nvidia
> > .htm
> > l
> > 
> > The Gentoo method is extremely limited, and of course isn't exactly
> > safe, although using pci-stub would probably help.  There's no
> > arbitration between the DRM driver and the mtd phram driver.  Most
> > of
> > all, it can only expose the memory mapped into the PCI aperture,
> > likely
> > somewhat less than the full VMEM.
> > 
> > The second method obviously requires the proprietary NVidia driver
> > and
> > an NVidia gfx card, but it's good proof of concept at utilising a
> > driver managed buffer object as a block device.
> > 
> > I'm looking into creating a volatile block device driver which
> > allocates VMEM from DRM, what if any is the right API to use?  The
> > DRM
> > userspace API is well documented, but I'd like to make this a
> > kernel
> > module, so using a userspace API would seem inappropriate at best.
> >  Ideally I'd like to create something like the bcache
> > flash_vol_create
> > interface except expose a /sys/fs/drm-block/card0/vol_create (where
> > drm-block is a placeholder for the proposed driver name) for each
> > DRM
> > device in the system, and likewise persistence through udev.
> > 
> > So is there an API I can (mis-)use for this?  Any suggestions?
> > 
> > * There's a screen attached for maintainence, but it usually turned
> > off.
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150922/7865cd62/attachment.sig>

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Ville Syrjälä]

On Tue, Sep 22, 2015 at 10:48:06AM -0700, Rafael Antognolli wrote:
> On Tue, Sep 22, 2015 at 10:59:51AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > dev node per DP AUX channel, named drm_aux-N.
> > > 
> > > It's possible to know which connector owns this aux channel by looking
> > > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > > the connector device pointer was correctly set in the aux helper struct.
> > > 
> > > Two main operations are provided on the registers: read and write. The
> > > address of the register to be read or written is given using lseek.
> > > Reading or writing does not update the offset of the file.
> > 
> > I think not updating the read position is very surprising. Would it be
> > hard to fix that?
> 
> No, not hard at all. But I assume then I should update the write
> position too, right?
> 
> BTW, i2c-dev doesn't update either of them, but I'm not sure why.

I think there's just no standard definition of what an offset would mean
for an i2c device. For standard eeproms it would work as one would expect,
but generally it's device specific.

> 
> > > 
> > > Signed-off-by: Rafael Antognolli 
> > > ---
> > >  drivers/gpu/drm/Kconfig   |   4 +
> > >  drivers/gpu/drm/Makefile  |   1 +
> > >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > > ++
> > >  3 files changed, 331 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > > 
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 1a0a8df..eae847c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > >   bool
> > >   depends on DRM
> > >  
> > > +config DRM_AUX_CHARDEV
> > > + tristate "DRM DP AUX Interface"
> > > + depends on DRM
> > > +
> > >  config DRM_KMS_HELPER
> > >   tristate
> > >   depends on DRM
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 45e7719..a1a94306 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> > >  
> > >  obj-$(CONFIG_DRM)+= drm.o
> > >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> > >  obj-$(CONFIG_DRM_TTM)+= ttm/
> > >  obj-$(CONFIG_DRM_TDFX)   += tdfx/
> > >  obj-$(CONFIG_DRM_R128)   += r128/
> > > diff --git a/drivers/gpu/drm/drm_aux-dev.c b/drivers/gpu/drm/drm_aux-dev.c
> > > new file mode 100644
> > > index 000..fcc334a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > > @@ -0,0 +1,326 @@
> > > +/*
> > > + * Copyright © 2015 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a
> > > + * copy of this software and associated documentation files (the 
> > > "Software"),
> > > + * to deal in the Software without restriction, including without 
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the 
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of 
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + *
> > > + * Authors:
> > > + *Rafael Antognolli 
> > > + *
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct drm_aux_dev {
> > > + struct list_head list;
> > > + unsigned index;
> > > + struct drm_dp_aux *aux;
> > > + struct device *dev;
> > > +};
> > > +
> > > +#define DRM_AUX_MINORS   256
> > > +static int drm_aux_dev_count = 0;
> > > +static LIST_HEAD(drm_aux_dev_list);
> > > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > > +
> > > +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> > > +{
> > > + struct drm_aux_dev *aux_dev;
> > > +
> > > + spin_lock(_aux_dev_list_lock);
> > > + list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > > + if 

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90()

[Borislav Petkov]

On Mon, Sep 21, 2015 at 03:31:26PM +0200, Borislav Petkov wrote:
> Hi guys,
> 
> this assert_drm_connector_list_read_locked() thing fires here when
> suspending to disk with Linus' master from around a week ago and
> tip/master merged ontop.
> 
> After I resume, box comes up but wedges solid. I've managed to capture
> that splat in its whole glory too, see the end of this mail.

Btw, this happens on rc2+tip too.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

[Bug 92079] Crash on wine d3dadapter during Heroes of the Storm loading

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

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

Patrick Nicolas  changed:

   What|Removed |Added

Summary|Crash during load on wine   |Crash on wine d3dadapter
   |d3dadapter during Heroes of |during Heroes of the Storm
   |the Storm loading   |loading

-- 
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/20150922/76e69f85/attachment.html>

[Bug 92079] Crash during load on wine d3dadapter during Heroes of the Storm loading

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

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

Bug ID: 92079
   Summary: Crash during load on wine d3dadapter during Heroes of
the Storm loading
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: patricknicolas at laposte.net
QA Contact: dri-devel at lists.freedesktop.org

Since mesa 11, most of the times game loading crashes, either with a freeze or
a blizzard error window.
I use a Sandy Bridge IGP and a Radeon HD 7970 with DRI_PRIME, using dri3 and
wine with d3dadapter (so it uses mesa d3d state tracker).

Sometimes, an error is printed in kernel messages:
[ 7481.648047] radeon :01:00.0: GPU fault detected: 146 0x0feb6014
[ 7481.648051] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0xEEFF
[ 7481.648052] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0B060014

I have bisected and the issue seems to come from

commit 719f124620d3c9b4d6ce14db3dbfc7af05626e5b
Author: Axel Davy 
Date:   Sun Aug 9 19:06:01 2015 +0200

st/nine: Catch setting the same shader

This is quite rare that an app does set again
the same shaders, but it isn't an expensive check
either.

Signed-off-by: Axel Davy 

How can I provide more debugging info so we can find the specific issue in the
commit ?

-- 
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/20150922/361d61a9/attachment.html>

[PATCH 05/23] drm: Add structure to set/get a CTM color property

[Ville Syrjälä]

On Wed, Sep 16, 2015 at 11:07:02PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi 
> 
> Color Manager framework defines a color correction property for color
> space transformation and Gamut mapping. This property is called CTM (Color
> Transformation Matrix).
> 
> This patch adds a new structure in DRM layer for CTM.
> This structure can be used by all user space agents to
> configure CTM coefficients for color correction.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  include/uapi/drm/drm.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index f72b916..9580772 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -867,6 +867,18 @@ struct drm_palette {
>   struct drm_r32g32b32 lut[0];
>  };
>  
> +struct drm_ctm {
> + /* Structure version. Should be 1 currently */
> + __u32 version;
> + /*
> +  * Each value is in S31.32 format.
> +  * This is 3x3 matrix in row major format.

I'm not sure that exlains things. Maybe sketch the math equation here
(something like what I put in i915_reg.h for the CHV sprite CSC). Which
reminds me: what are we going to do about the pre/post offset stuff? I
was sort of expecting to see it here, but maybe you put those into
separate properties?

> +  * Integer part will be clipped to nearest
> +  * max/min boundary as supported by the HW platform.
> +  */
> + __s64 ctm_coeff[9];

ctm_ prefix seems superfluous. Also could maybe use some comment
explaining what ctm is?

> +};
> +
>  /* typedef area */
>  #ifndef __KERNEL__
>  typedef struct drm_clip_rect drm_clip_rect_t;
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[PATCH v2 5/6] virtio-gpu: add basic prime support

[Daniel Vetter]

On Tue, Sep 22, 2015 at 05:24:29PM +0200, Gerd Hoffmann wrote:
> > > +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> > > +struct vm_area_struct *area)
> > > +{
> > > + WARN_ONCE(1, "not implemented");
> > > + return ENOSYS;
> > 
> > This can get called by userspace, so please don't WARN here. Also missing
> > negate sign:
> > 
> > return -ENOSYS;
> 
> Hmm now checkpatch throws a warning at me:
> 
> 
>WARNING: ENOSYS means 'invalid syscall nr' and nothing else
>#12: FILE: drivers/gpu/drm/virtio/virtgpu_prime.c:70:
>+   return -ENOSYS;
> 
> 
> I guess I should use something else then (here and elsewhere in the
> file)?  Maybe -EINVAL?  Other suggestions?

-ENODEV is what we occasionally pick. drm is fairly creative at errno
abuse, e.g. we already use -ENOENT to signal any kind of lookup failure in
ioctls (even if the fd itself is obviously there so not possible that the
fd isn't there).

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

[PATCH 04/23] drm: Add drm structures for palette color property

[Ville Syrjälä]

On Tue, Sep 22, 2015 at 02:53:54PM +0100, Emil Velikov wrote:
> On 22 September 2015 at 14:08, Daniel Vetter  wrote:
> > On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
> >> From: Kausal Malladi 
> >>
> >> This patch adds new structures in DRM layer for Palette color
> >> correction.These structures will be used by user space agents
> >> to configure appropriate number of samples and Palette LUT for
> >> a platform.
> >>
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Kausal Malladi 
> >> ---
> >>  include/uapi/drm/drm.h | 27 +++
> >>  1 file changed, 27 insertions(+)
> >>
> >> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> >> index e3c642f..f72b916 100644
> >> --- a/include/uapi/drm/drm.h
> >> +++ b/include/uapi/drm/drm.h
> [snip]
> >> +struct drm_palette {
> [snip]
> > ... extending the ioctl struct at the end ...
> Is this really going to work, considering that we currently have a
> zero sized drm_r32g32b32 array at the end ?

Well in this particular case it would be ugly. Sure, it can be done,
but we couldn't actually define the struct for it using C. Would be
a neat feature though. Someone should propose it for the next C
standard :)

In any case, for blobs I think we shouldn't extend them like ioctls.
In this case the blob is just an array of something, so the blob size
can of course vary depending how many elements are required for the
particual platform.

> Iirc someone mentioned that using a pointer to the data (over an
> array) has drawbacks, although for the sake of me I cannot think of
> any. Can anyone care to enlighten me, please ?

I guess an extensible array at the end of the struct is simply a nice
fit sometimes. Also makes it more obvious how much junk gets copied over
I suppose.

-- 
Ville Syrjälä
Intel OTC

[PATCH 13/13] exynos: bump version number

[Tobias Jakobi]

The Exynos API was extended quite a bit, so reflect this in the
version number.

Signed-off-by: Tobias Jakobi 
---
 exynos/libdrm_exynos.pc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/exynos/libdrm_exynos.pc.in b/exynos/libdrm_exynos.pc.in
index 5ce9118..ff1c432 100644
--- a/exynos/libdrm_exynos.pc.in
+++ b/exynos/libdrm_exynos.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@

 Name: libdrm_exynos
 Description: Userspace interface to exynos kernel DRM services
-Version: 0.6
+Version: 0.7
 Libs: -L${libdir} -ldrm_exynos
 Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/exynos
 Requires.private: libdrm
-- 
2.0.5

[PATCH 12/13] exynos/fimg2d: add g2d_reset() to public API

[Tobias Jakobi]

After the rewrite of the command buffer submission
handling g2d_reset() is no longer called internally.

Still the user might want to reset the G2D
context so expose this call.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos-symbol-check |  1 +
 exynos/exynos_fimg2d.c | 28 ++--
 exynos/exynos_fimg2d.h |  1 +
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index 2e4ba56..57dd684 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -32,6 +32,7 @@ g2d_exec2
 g2d_config_event
 g2d_fini
 g2d_init
+g2d_reset
 g2d_scale_and_blend
 g2d_solid_fill
 EOF
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 8703629..cc5d9f4 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -255,20 +255,6 @@ static void g2d_set_direction(struct g2d_context *ctx,
 }

 /*
- * g2d_reset - reset fimg2d hardware.
- *
- * @ctx: a pointer to g2d_context structure.
- *
- */
-static void g2d_reset(struct g2d_context *ctx)
-{
-   ctx->cmd_nr = 0;
-   ctx->cmd_buf_nr = 0;
-
-   g2d_add_cmd(ctx, SOFT_RESET_REG, 0x01);
-}
-
-/*
  * g2d_flush - submit all commands and values in user side command buffer
  * to command queue aware of fimg2d dma.
  *
@@ -356,6 +342,20 @@ void g2d_fini(struct g2d_context *ctx)
free(ctx);
 }

+/*
+ * g2d_reset - reset fimg2d hardware.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ *
+ */
+void g2d_reset(struct g2d_context *ctx)
+{
+   ctx->cmd_nr = 0;
+   ctx->cmd_buf_nr = 0;
+
+   g2d_add_cmd(ctx, SOFT_RESET_REG, 0x01);
+}
+
 /**
  * g2d_config_event - setup userdata configuration for a g2d event.
  * The next invocation of a g2d call (e.g. g2d_solid_fill) is
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 2700686..03391c1 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -333,6 +333,7 @@ struct g2d_context;

 struct g2d_context *g2d_init(int fd);
 void g2d_fini(struct g2d_context *ctx);
+void g2d_reset(struct g2d_context *ctx);
 void g2d_config_event(struct g2d_context *ctx, void *userdata);
 int g2d_exec(struct g2d_context *ctx);
 int g2d_exec2(struct g2d_context *ctx, unsigned int flags);
-- 
2.0.5

[PATCH 11/13] exynos/fimg2d: add exynos_bo_unmap()

[Tobias Jakobi]

This unmaps a previously mapped (via exynos_bo_map())
buffer object.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos-symbol-check |  1 +
 exynos/exynos_drm.c| 20 
 exynos/exynos_drmif.h  |  1 +
 3 files changed, 22 insertions(+)

diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index 2bb7718..2e4ba56 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -17,6 +17,7 @@ exynos_bo_get_info
 exynos_bo_get_name
 exynos_bo_handle
 exynos_bo_map
+exynos_bo_unmap
 exynos_device_create
 exynos_device_destroy
 exynos_prime_fd_to_handle
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
index 7a400ad..e086a00 100644
--- a/exynos/exynos_drm.c
+++ b/exynos/exynos_drm.c
@@ -309,6 +309,26 @@ void *exynos_bo_map(struct exynos_bo *bo)
return bo->vaddr;
 }

+int exynos_bo_unmap(struct exynos_bo *bo)
+{
+   int ret = 0;
+
+   if (!bo->vaddr)
+   goto out;
+
+   ret = munmap(bo->vaddr, bo->size);
+   if (ret) {
+   fprintf(stderr, "failed to unmap buffer [%s].\n",
+   strerror(errno));
+   goto out;
+   }
+
+   bo->vaddr = NULL;
+
+out:
+   return ret;
+}
+
 /*
  * Export gem object to dmabuf as file descriptor.
  *
diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
index 626e399..3b26ebf 100644
--- a/exynos/exynos_drmif.h
+++ b/exynos/exynos_drmif.h
@@ -91,6 +91,7 @@ struct exynos_bo * exynos_bo_from_name(struct exynos_device 
*dev, uint32_t name)
 int exynos_bo_get_name(struct exynos_bo *bo, uint32_t *name);
 uint32_t exynos_bo_handle(struct exynos_bo *bo);
 void * exynos_bo_map(struct exynos_bo *bo);
+int exynos_bo_unmap(struct exynos_bo *bo);
 int exynos_prime_handle_to_fd(struct exynos_device *dev, uint32_t handle,
int *fd);
 int exynos_prime_fd_to_handle(struct exynos_device *dev, int fd,
-- 
2.0.5

[PATCH 10/13] tests/exynos: add test for g2d_move

[Tobias Jakobi]

To check if g2d_move() works properly we create a small checkerboard
pattern in the center of the screen and then shift this pattern
around with g2d_move(). The pattern should be properly preserved
by the operation.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/exynos_fimg2d_test.c | 132 ++
 1 file changed, 132 insertions(+)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index dfb00a0..797fb6e 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -313,6 +313,130 @@ fail:
return ret;
 }

+static int g2d_move_test(struct exynos_device *dev,
+   struct exynos_bo *tmp,
+   struct exynos_bo *buf,
+   enum e_g2d_buf_type type)
+{
+   struct g2d_context *ctx;
+   struct g2d_image img = {0}, tmp_img = {0};
+   unsigned int img_w, img_h, count;
+   int cur_x, cur_y;
+   void *checkerboard;
+   int ret;
+
+   static const struct g2d_step {
+   int x, y;
+   } steps[] = {
+   { 1,  0}, { 0,  1},
+   {-1,  0}, { 0, -1},
+   { 1,  1}, {-1, -1},
+   { 1, -1}, {-1,  1},
+   { 2,  1}, { 1,  2},
+   {-2, -1}, {-1, -2},
+   { 2, -1}, { 1, -2},
+   {-2,  1}, {-1,  2}
+   };
+   static const unsigned int num_steps =
+   sizeof(steps) / sizeof(struct g2d_step);
+
+   ctx = g2d_init(dev->fd);
+   if (!ctx)
+   return -EFAULT;
+
+   img.bo[0] = buf->handle;
+
+   /* create pattern of half the screen size */
+   checkerboard = create_checkerboard_pattern(screen_width / 64, 
screen_height / 64, 32);
+   if (!checkerboard) {
+   ret = -EFAULT;
+   goto fail;
+   }
+
+   img_w = (screen_width / 64) * 32;
+   img_h = (screen_height / 64) * 32;
+
+   switch (type) {
+   case G2D_IMGBUF_GEM:
+   memcpy(tmp->vaddr, checkerboard, img_w * img_h * 4);
+   tmp_img.bo[0] = tmp->handle;
+   break;
+   case G2D_IMGBUF_USERPTR:
+   tmp_img.user_ptr[0].userptr = (unsigned long)checkerboard;
+   tmp_img.user_ptr[0].size = img_w * img_h * 4;
+   break;
+   case G2D_IMGBUF_COLOR:
+   default:
+   ret = -EFAULT;
+   goto fail;
+   }
+
+   /* solid fill framebuffer with white color */
+   img.width = screen_width;
+   img.height = screen_height;
+   img.stride = screen_width * 4;
+   img.buf_type = G2D_IMGBUF_GEM;
+   img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+   img.color = 0x;
+
+   /* put checkerboard pattern in the center of the framebuffer */
+   cur_x = (screen_width - img_w) / 2;
+   cur_y = (screen_height - img_h) / 2;
+   tmp_img.width = img_w;
+   tmp_img.height = img_h;
+   tmp_img.stride = img_w * 4;
+   tmp_img.buf_type = type;
+   tmp_img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+
+   ret = g2d_solid_fill(ctx, , 0, 0, screen_width, screen_height) ||
+   g2d_copy(ctx, _img, , 0, 0, cur_x, cur_y, img_w, img_h);
+
+   if (!ret)
+   ret = g2d_exec(ctx);
+   if (ret < 0)
+   goto fail;
+
+   printf("move test with %s.\n",
+   type == G2D_IMGBUF_GEM ? "gem" : "userptr");
+
+   srand(time(NULL));
+   for (count = 0; count < 256; ++count) {
+   const struct g2d_step *s;
+
+   /* select step and validate it */
+   while (1) {
+   s = [random() % num_steps];
+
+   if (cur_x + s->x < 0 || cur_y + s->y < 0 ||
+   cur_x + img_w + s->x >= screen_width ||
+   cur_y + img_h + s->y >= screen_height)
+   continue;
+   else
+   break;
+   }
+
+   ret = g2d_move(ctx, , cur_x, cur_y, cur_x + s->x, cur_y + 
s->y,
+   img_w, img_h);
+   if (!ret)
+   ret = g2d_exec(ctx);
+
+   if (ret < 0)
+   goto fail;
+
+   cur_x += s->x;
+   cur_y += s->y;
+
+   usleep(10);
+   }
+
+fail:
+   g2d_fini(ctx);
+
+   free(checkerboard);
+
+   return ret;
+}
+
 static int g2d_copy_with_scale_test(struct exynos_device *dev,
struct exynos_bo *src,
struct exynos_bo *dst,
@@ -708,6 +832,14 @@ int main(int argc, char **argv)

wait_for_user_input(0);

+   ret = g2d_move_test(dev, src, bo, G2D_IMGBUF_GEM);
+   if (ret < 0) {
+   fprintf(stderr, "failed to test move operation.\n");
+ 

[PATCH 09/13] exynos/fimg2d: add g2d_move

[Tobias Jakobi]

We already have g2d_copy() which implements G2D copy
operations from one buffer to another. However we can't
do a overlapping copy operation in one buffer.

Add g2d_move() which acts like the standard memmove()
and properly handles overlapping copies.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 94 ++
 exynos/exynos_fimg2d.h |  3 ++
 2 files changed, 97 insertions(+)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 4d5419c..8703629 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -540,6 +540,100 @@ g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
 }

 /**
+ * g2d_move - move content inside single buffer.
+ * Similar to 'memmove' this moves a rectangular region
+ * of the provided buffer to another location (the source
+ * and destination region potentially overlapping).
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @img: a pointer to g2d_image structure providing
+ * buffer information.
+ * @src_x: x position of source rectangle.
+ * @src_y: y position of source rectangle.
+ * @dst_x: x position of destination rectangle.
+ * @dst_y: y position of destination rectangle.
+ * @w: width of rectangle to move.
+ * @h: height of rectangle to move.
+ */
+int
+g2d_move(struct g2d_context *ctx, struct g2d_image *img,
+   unsigned int src_x, unsigned int src_y,
+   unsigned int dst_x, unsigned dst_y, unsigned int w,
+   unsigned int h)
+{
+   union g2d_rop4_val rop4;
+   union g2d_point_val pt;
+   union g2d_direction_val dir;
+   unsigned int src_w, src_h, dst_w, dst_h;
+
+   src_w = w;
+   src_h = h;
+   if (src_x + img->width > w)
+   src_w = img->width - src_x;
+   if (src_y + img->height > h)
+   src_h = img->height - src_y;
+
+   dst_w = w;
+   dst_h = w;
+   if (dst_x + img->width > w)
+   dst_w = img->width - dst_x;
+   if (dst_y + img->height > h)
+   dst_h = img->height - dst_y;
+
+   w = MIN(src_w, dst_w);
+   h = MIN(src_h, dst_h);
+
+   if (w == 0 || h == 0) {
+   fprintf(stderr, MSG_PREFIX "invalid width or height.\n");
+   return -EINVAL;
+   }
+
+   if (g2d_check_space(ctx, 13, 2))
+   return -ENOSPC;
+
+   g2d_add_cmd(ctx, DST_SELECT_REG, G2D_SELECT_MODE_BGCOLOR);
+   g2d_add_cmd(ctx, SRC_SELECT_REG, G2D_SELECT_MODE_NORMAL);
+
+   g2d_add_cmd(ctx, DST_COLOR_MODE_REG, img->color_mode);
+   g2d_add_cmd(ctx, SRC_COLOR_MODE_REG, img->color_mode);
+
+   g2d_add_base_addr(ctx, img, g2d_dst);
+   g2d_add_base_addr(ctx, img, g2d_src);
+
+   g2d_add_cmd(ctx, DST_STRIDE_REG, img->stride);
+   g2d_add_cmd(ctx, SRC_STRIDE_REG, img->stride);
+
+   dir.val[0] = dir.val[1] = 0;
+
+   if (dst_x >= src_x)
+   dir.data.src_x_direction = dir.data.dst_x_direction = 1;
+   if (dst_y >= src_y)
+   dir.data.src_y_direction = dir.data.dst_y_direction = 1;
+
+   g2d_set_direction(ctx, );
+
+   pt.data.x = src_x;
+   pt.data.y = src_y;
+   g2d_add_cmd(ctx, SRC_LEFT_TOP_REG, pt.val);
+   pt.data.x = src_x + w;
+   pt.data.y = src_y + h;
+   g2d_add_cmd(ctx, SRC_RIGHT_BOTTOM_REG, pt.val);
+
+   pt.data.x = dst_x;
+   pt.data.y = dst_y;
+   g2d_add_cmd(ctx, DST_LEFT_TOP_REG, pt.val);
+   pt.data.x = dst_x + w;
+   pt.data.y = dst_y + h;
+   g2d_add_cmd(ctx, DST_RIGHT_BOTTOM_REG, pt.val);
+
+   rop4.val = 0;
+   rop4.data.unmasked_rop3 = G2D_ROP3_SRC;
+   g2d_add_cmd(ctx, ROP4_REG, rop4.val);
+
+   return g2d_flush(ctx);
+}
+
+/**
  * g2d_copy_with_scale - copy contents in source buffer to destination buffer
  * scaling up or down properly.
  *
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 9eee7c0..2700686 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -343,6 +343,9 @@ int g2d_copy(struct g2d_context *ctx, struct g2d_image *src,
struct g2d_image *dst, unsigned int src_x,
unsigned int src_y, unsigned int dst_x, unsigned int dst_y,
unsigned int w, unsigned int h);
+int g2d_move(struct g2d_context *ctx, struct g2d_image *img,
+   unsigned int src_x, unsigned int src_y, unsigned int dst_x,
+   unsigned dst_y, unsigned int w, unsigned int h);
 int g2d_copy_with_scale(struct g2d_context *ctx, struct g2d_image *src,
struct g2d_image *dst, unsigned int src_x,
unsigned int src_y, unsigned int src_w,
-- 
2.0.5

[PATCH 08/13] exynos: fimg2d: add g2d_set_direction

[Tobias Jakobi]

This allows setting the two direction registers, which specify how
the engine blits pixels. This can be used for overlapping blits,
which happen e.g. when 'moving' a rectangular region inside a
fixed buffer.

Signed-off-by: Tobias Jakobi 
---
 exynos/exynos_fimg2d.c | 13 +
 exynos/exynos_fimg2d.h | 38 ++
 2 files changed, 51 insertions(+)

diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index e997d4b..4d5419c 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -242,6 +242,19 @@ static void g2d_add_base_addr(struct g2d_context *ctx, 
struct g2d_image *img,
 }

 /*
+ * g2d_set_direction - setup direction register (useful for overlapping blits).
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @dir: a pointer to the g2d_direction_val structure.
+ */
+static void g2d_set_direction(struct g2d_context *ctx,
+   const union g2d_direction_val *dir)
+{
+   g2d_add_cmd(ctx, SRC_MASK_DIRECT_REG, dir->val[0]);
+   g2d_add_cmd(ctx, DST_PAT_DIRECT_REG, dir->val[1]);
+}
+
+/*
  * g2d_reset - reset fimg2d hardware.
  *
  * @ctx: a pointer to g2d_context structure.
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index c6b58ac..9eee7c0 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -189,6 +189,11 @@ enum e_g2d_exec_flag {
G2D_EXEC_FLAG_ASYNC = (1 << 0)
 };

+enum e_g2d_dir_mode {
+   G2D_DIR_MODE_POSITIVE = 0,
+   G2D_DIR_MODE_NEGATIVE = 1
+};
+
 union g2d_point_val {
unsigned int val;
struct {
@@ -269,6 +274,39 @@ union g2d_blend_func_val {
} data;
 };

+union g2d_direction_val {
+   unsigned int val[2];
+   struct {
+   /* SRC_MSK_DIRECT_REG [0:1] (source) */
+   enum e_g2d_dir_mode src_x_direction:1;
+   enum e_g2d_dir_mode src_y_direction:1;
+
+   /* SRC_MSK_DIRECT_REG [2:3] */
+   unsigned intreversed1:2;
+
+   /* SRC_MSK_DIRECT_REG [4:5] (mask) */
+   enum e_g2d_dir_mode mask_x_direction:1;
+   enum e_g2d_dir_mode mask_y_direction:1;
+
+   /* SRC_MSK_DIRECT_REG [6:31] */
+   unsigned intpadding1:26;
+
+   /* DST_PAT_DIRECT_REG [0:1] (destination) */
+   enum e_g2d_dir_mode dst_x_direction:1;
+   enum e_g2d_dir_mode dst_y_direction:1;
+
+   /* DST_PAT_DIRECT_REG [2:3] */
+   unsigned intreversed2:2;
+
+   /* DST_PAT_DIRECT_REG [4:5] (pattern) */
+   enum e_g2d_dir_mode pat_x_direction:1;
+   enum e_g2d_dir_mode pat_y_direction:1;
+
+   /* DST_PAT_DIRECT_REG [6:31] */
+   unsigned intpadding2:26;
+   } data;
+};
+
 struct g2d_image {
enum e_g2d_select_mode  select_mode;
enum e_g2d_color_mode   color_mode;
-- 
2.0.5

[PATCH 07/13] tests/exynos: use XRGB8888 for framebuffer

[Tobias Jakobi]

This matches the G2D color mode that is used in the entire code.
The previous (incorrect) RGBA would only work since the
Exynos mixer did its configuration based on the bpp, and not
based on the actual pixelformat.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/exynos_fimg2d_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/exynos/exynos_fimg2d_test.c 
b/tests/exynos/exynos_fimg2d_test.c
index 8794dac..dfb00a0 100644
--- a/tests/exynos/exynos_fimg2d_test.c
+++ b/tests/exynos/exynos_fimg2d_test.c
@@ -675,7 +675,7 @@ int main(int argc, char **argv)
offsets[0] = 0;

ret = drmModeAddFB2(dev->fd, screen_width, screen_height,
-   DRM_FORMAT_RGBA, handles,
+   DRM_FORMAT_XRGB, handles,
pitches, offsets, _id, 0);
if (ret < 0)
goto err_destroy_buffer;
-- 
2.0.5

[PATCH 06/13] tests/exynos: add fimg2d event test

[Tobias Jakobi]

This tests async processing of G2D jobs. A separate thread is spawned
to monitor the DRM fd for events and check whether a G2D job was
completed.

v2: Add GPLv2 header, argument handling and documentation.
Test is only installed when requested.
v3: Allocate G2D jobs with calloc which fixes 'busy' being
potentially uninitialized. Also enable timeout for poll()
in the monitor thread. This fixes pthread_join() not working
because of poll() not returning.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/Makefile.am   |  11 +-
 tests/exynos/exynos_fimg2d_event.c | 326 +
 2 files changed, 335 insertions(+), 2 deletions(-)
 create mode 100644 tests/exynos/exynos_fimg2d_event.c

diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index e82d199..357d6b8 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -20,16 +20,23 @@ endif

 if HAVE_INSTALL_TESTS
 bin_PROGRAMS += \
-   exynos_fimg2d_perf
+   exynos_fimg2d_perf \
+   exynos_fimg2d_event
 else
 noinst_PROGRAMS += \
-   exynos_fimg2d_perf
+   exynos_fimg2d_perf \
+   exynos_fimg2d_event
 endif

 exynos_fimg2d_perf_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/exynos/libdrm_exynos.la

+exynos_fimg2d_event_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/exynos/libdrm_exynos.la \
+   -lpthread
+
 exynos_fimg2d_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/libkms/libkms.la \
diff --git a/tests/exynos/exynos_fimg2d_event.c 
b/tests/exynos/exynos_fimg2d_event.c
new file mode 100644
index 000..c03dcff
--- /dev/null
+++ b/tests/exynos/exynos_fimg2d_event.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2015 - Tobias Jakobi
+ *
+ * This 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.
+ *
+ * It is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * You should have received a copy of the GNU General Public License
+ * along with it. If not, see .
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include "exynos_drm.h"
+#include "exynos_drmif.h"
+#include "exynos_fimg2d.h"
+
+struct g2d_job {
+   unsigned int id;
+   unsigned int busy;
+};
+
+struct exynos_evhandler {
+   struct pollfd fds;
+   struct exynos_event_context evctx;
+};
+
+struct threaddata {
+   unsigned int stop;
+   struct exynos_device *dev;
+   struct exynos_evhandler evhandler;
+};
+
+static void g2d_event_handler(int fd, unsigned int cmdlist_no, unsigned int 
tv_sec,
+   unsigned int tv_usec, 
void *user_data)
+{
+   struct g2d_job *job = user_data;
+
+   fprintf(stderr, "info: g2d job (id = %u, cmdlist number = %u) 
finished!\n",
+   job->id, cmdlist_no);
+
+   job->busy = 0;
+}
+
+static void setup_g2d_event_handler(struct exynos_evhandler *evhandler, int fd)
+{
+   evhandler->fds.fd = fd;
+   evhandler->fds.events = POLLIN;
+   evhandler->evctx.base.version = DRM_EVENT_CONTEXT_VERSION;
+   evhandler->evctx.version = EXYNOS_EVENT_CONTEXT_VERSION;
+   evhandler->evctx.g2d_event_handler = g2d_event_handler;
+}
+
+static void* threadfunc(void *arg) {
+   const int timeout = 0;
+   struct threaddata *data;
+
+   data = arg;
+
+   while (1) {
+   if (data->stop) break;
+
+   usleep(500);
+
+   data->evhandler.fds.revents = 0;
+
+   if (poll(>evhandler.fds, 1, timeout) < 0)
+   continue;
+
+   if (data->evhandler.fds.revents & (POLLHUP | POLLERR))
+   continue;
+
+   if (data->evhandler.fds.revents & POLLIN)
+   exynos_handle_event(data->dev, >evhandler.evctx);
+   }
+
+   pthread_exit(0);
+}
+
+/*
+ * We need to wait until all G2D jobs are finished, otherwise we
+ * potentially remove a BO which the engine still operates on.
+ * This results in the following kernel message:
+ * [drm:exynos_drm_gem_put_dma_addr] *ERROR* failed to lookup gem object.
+ * Also any subsequent BO allocations fail then with:
+ * [drm:exynos_drm_alloc_buf] *ERROR* failed to allocate buffer.
+ */
+static void wait_all_jobs(struct g2d_job* jobs, unsigned num_jobs)
+{
+   unsigned i;
+
+   for (i = 0; i < num_jobs; ++i) {
+   while (jobs[i].busy)
+   usleep(500);
+   }
+
+}
+
+static struct g2d_job* free_job(struct g2d_job* jobs, unsigned num_jobs)
+{
+   unsigned i;

[PATCH 05/13] exynos: fimg2d: add g2d_exec2

[Tobias Jakobi]

This is a more 'flexible' version of g2d_exec allowing to pass
some flags which modify the behaviour of g2d_exec. Currently
only the 'async' operation flag is supported.

v2: Add g2d_exec2() to Exynos symbol test.
Signed-off-by: Tobias Jakobi 
---
 exynos/exynos-symbol-check |  1 +
 exynos/exynos_fimg2d.c | 15 +--
 exynos/exynos_fimg2d.h |  6 ++
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index bb12315..2bb7718 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -27,6 +27,7 @@ g2d_blend
 g2d_copy
 g2d_copy_with_scale
 g2d_exec
+g2d_exec2
 g2d_config_event
 g2d_fini
 g2d_init
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index b10620b..e997d4b 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -366,13 +366,24 @@ void g2d_config_event(struct g2d_context *ctx, void 
*userdata)
  */
 int g2d_exec(struct g2d_context *ctx)
 {
-   struct drm_exynos_g2d_exec exec;
+   return g2d_exec2(ctx, G2D_EXEC_FLAG_NORMAL);
+}
+
+/**
+ * g2d_exec2 - same as 'g2d_exec' but allow to pass some flags.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ */
+int g2d_exec2(struct g2d_context *ctx, unsigned int flags)
+{
+   struct drm_exynos_g2d_exec exec = {0};
int ret;

if (ctx->cmdlist_nr == 0)
return -EINVAL;

-   exec.async = 0;
+   if (flags & G2D_EXEC_FLAG_ASYNC)
+   exec.async = 1;

ret = drmIoctl(ctx->fd, DRM_IOCTL_EXYNOS_G2D_EXEC, );
if (ret < 0) {
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index a2c22da..c6b58ac 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -184,6 +184,11 @@ enum e_g2d_acoeff_mode {
G2D_ACOEFF_MODE_MASK
 };

+enum e_g2d_exec_flag {
+   G2D_EXEC_FLAG_NORMAL = (0 << 0),
+   G2D_EXEC_FLAG_ASYNC = (1 << 0)
+};
+
 union g2d_point_val {
unsigned int val;
struct {
@@ -292,6 +297,7 @@ struct g2d_context *g2d_init(int fd);
 void g2d_fini(struct g2d_context *ctx);
 void g2d_config_event(struct g2d_context *ctx, void *userdata);
 int g2d_exec(struct g2d_context *ctx);
+int g2d_exec2(struct g2d_context *ctx, unsigned int flags);
 int g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img,
unsigned int x, unsigned int y, unsigned int w,
unsigned int h);
-- 
2.0.5

[PATCH 04/13] exynos/fimg2d: add g2d_config_event

[Tobias Jakobi]

This enables us to pass command buffers to the kernel which
trigger an event on the DRM fd upon completion.
The final goal is to enable asynchronous operation of the
G2D engine, similar to async page flips.

Passing the event userdata pointer through the G2D context
was chosen to not change the current API (e.g. by adding
a userdata argument to each public functions).

v2: Add g2d_config_event() to Exynos symbol test.
Signed-off-by: Tobias Jakobi 
---
 exynos/exynos-symbol-check |  1 +
 exynos/exynos_fimg2d.c | 28 ++--
 exynos/exynos_fimg2d.h |  1 +
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index c3ddbe4..bb12315 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -27,6 +27,7 @@ g2d_blend
 g2d_copy
 g2d_copy_with_scale
 g2d_exec
+g2d_config_event
 g2d_fini
 g2d_init
 g2d_scale_and_blend
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index e734144..b10620b 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/exynos_fimg2d.c
@@ -57,6 +57,7 @@ struct g2d_context {
unsigned intcmd_nr;
unsigned intcmd_buf_nr;
unsigned intcmdlist_nr;
+   void*event_userdata;
 };

 enum g2d_base_addr_reg {
@@ -280,8 +281,15 @@ static int g2d_flush(struct g2d_context *ctx)
cmdlist.cmd_buf = (uint64_t)(uintptr_t)>cmd_buf[0];
cmdlist.cmd_nr = ctx->cmd_nr;
cmdlist.cmd_buf_nr = ctx->cmd_buf_nr;
-   cmdlist.event_type = G2D_EVENT_NOT;
-   cmdlist.user_data = 0;
+
+   if (ctx->event_userdata) {
+   cmdlist.event_type = G2D_EVENT_NONSTOP;
+   cmdlist.user_data = (uint64_t)(uintptr_t)(ctx->event_userdata);
+   ctx->event_userdata = NULL;
+   } else {
+   cmdlist.event_type = G2D_EVENT_NOT;
+   cmdlist.user_data = 0;
+   }

ctx->cmd_nr = 0;
ctx->cmd_buf_nr = 0;
@@ -336,6 +344,22 @@ void g2d_fini(struct g2d_context *ctx)
 }

 /**
+ * g2d_config_event - setup userdata configuration for a g2d event.
+ * The next invocation of a g2d call (e.g. g2d_solid_fill) is
+ * then going to flag the command buffer as 'nonstop'.
+ * Completion of the command buffer execution can then be
+ * determined by using drmHandleEvent on the DRM fd.
+ * The userdata is 'consumed' in the process.
+ *
+ * @ctx: a pointer to g2d_context structure.
+ * @userdata: a pointer to the user data
+ */
+void g2d_config_event(struct g2d_context *ctx, void *userdata)
+{
+   ctx->event_userdata = userdata;
+}
+
+/**
  * g2d_exec - start the dma to process all commands summited by g2d_flush().
  *
  * @ctx: a pointer to g2d_context structure.
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
index 4aa1568..a2c22da 100644
--- a/exynos/exynos_fimg2d.h
+++ b/exynos/exynos_fimg2d.h
@@ -290,6 +290,7 @@ struct g2d_context;

 struct g2d_context *g2d_init(int fd);
 void g2d_fini(struct g2d_context *ctx);
+void g2d_config_event(struct g2d_context *ctx, void *userdata);
 int g2d_exec(struct g2d_context *ctx);
 int g2d_solid_fill(struct g2d_context *ctx, struct g2d_image *img,
unsigned int x, unsigned int y, unsigned int w,
-- 
2.0.5

[PATCH 03/13] tests/exynos: add fimg2d performance analysis

[Tobias Jakobi]

Currently only fast solid color clear performance is measured.
A large buffer is allocated and solid color clear operations
are executed on it with randomly chosen properties (position
and size of the region, clear color). Execution time is
measured and output together with the amount of pixels
processed.

The 'simple' variant only executes one G2D command buffer at
a time, while the 'multi' variant executes multiple ones. This
can be used to measure setup/exec overhead.

The test also serves a stability check. If clocks/voltages are
too high or low respectively, the test quickly reveals this.

v2: Add GPLv2 header, argument handling and documentation.
Tool is only installed when requested.

Signed-off-by: Tobias Jakobi 
---
 tests/exynos/Makefile.am  |  19 ++-
 tests/exynos/exynos_fimg2d_perf.c | 320 ++
 2 files changed, 337 insertions(+), 2 deletions(-)
 create mode 100644 tests/exynos/exynos_fimg2d_perf.c

diff --git a/tests/exynos/Makefile.am b/tests/exynos/Makefile.am
index b21d016..e82d199 100644
--- a/tests/exynos/Makefile.am
+++ b/tests/exynos/Makefile.am
@@ -5,16 +5,31 @@ AM_CFLAGS = \
-I $(top_srcdir)/exynos \
-I $(top_srcdir)

+bin_PROGRAMS =
+noinst_PROGRAMS =
+
 if HAVE_LIBKMS
 if HAVE_INSTALL_TESTS
-bin_PROGRAMS = \
+bin_PROGRAMS += \
exynos_fimg2d_test
 else
-noinst_PROGRAMS = \
+noinst_PROGRAMS += \
exynos_fimg2d_test
 endif
 endif

+if HAVE_INSTALL_TESTS
+bin_PROGRAMS += \
+   exynos_fimg2d_perf
+else
+noinst_PROGRAMS += \
+   exynos_fimg2d_perf
+endif
+
+exynos_fimg2d_perf_LDADD = \
+   $(top_builddir)/libdrm.la \
+   $(top_builddir)/exynos/libdrm_exynos.la
+
 exynos_fimg2d_test_LDADD = \
$(top_builddir)/libdrm.la \
$(top_builddir)/libkms/libkms.la \
diff --git a/tests/exynos/exynos_fimg2d_perf.c 
b/tests/exynos/exynos_fimg2d_perf.c
new file mode 100644
index 000..73d28ea
--- /dev/null
+++ b/tests/exynos/exynos_fimg2d_perf.c
@@ -0,0 +1,320 @@
+/*
+ * Copyright (C) 2015 - Tobias Jakobi
+ *
+ * This 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.
+ *
+ * It is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * You should have received a copy of the GNU General Public License
+ * along with it. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "exynos_drm.h"
+#include "exynos_drmif.h"
+#include "exynos_fimg2d.h"
+
+static int output_mathematica = 0;
+
+static int fimg2d_perf_simple(struct exynos_bo *bo, struct g2d_context *ctx,
+   unsigned buf_width, unsigned buf_height, unsigned 
iterations)
+{
+   struct timespec tspec = { 0 };
+   struct g2d_image img = { 0 };
+
+   unsigned long long g2d_time;
+   unsigned i;
+   int ret = 0;
+
+   img.width = buf_width;
+   img.height = buf_height;
+   img.stride = buf_width * 4;
+   img.color_mode = G2D_COLOR_FMT_ARGB | G2D_ORDER_AXRGB;
+   img.buf_type = G2D_IMGBUF_GEM;
+   img.bo[0] = bo->handle;
+
+   srand(time(NULL));
+
+   printf("starting simple G2D performance test\n");
+   printf("buffer width = %u, buffer height = %u, iterations = %u\n",
+   buf_width, buf_height, iterations);
+
+   if (output_mathematica)
+   putchar('{');
+
+   for (i = 0; i < iterations; ++i) {
+   unsigned x, y, w, h;
+
+   x = rand() % buf_width;
+   y = rand() % buf_height;
+
+   if (x == (buf_width - 1))
+   x -= 1;
+   if (y == (buf_height - 1))
+   y -= 1;
+
+   w = rand() % (buf_width - x);
+   h = rand() % (buf_height - y);
+
+   if (w == 0) w = 1;
+   if (h == 0) h = 1;
+
+   img.color = rand();
+
+   ret = g2d_solid_fill(ctx, , x, y, w, h);
+
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   if (ret == 0)
+   ret = g2d_exec(ctx);
+
+   if (ret != 0) {
+   fprintf(stderr, "error: iteration %u failed (x = %u, y 
= %u, w = %u, h = %u)\n",
+   i, x, y, w, h);
+   break;
+   } else {
+   struct timespec end = { 0 };
+   clock_gettime(CLOCK_MONOTONIC, );
+
+   g2d_time = (end.tv_sec - tspec.tv_sec) * 10ULL;
+   g2d_time += (end.tv_nsec - tspec.tv_nsec);
+
+   if (output_mathematica) {
+  

[PATCH 02/13] exynos: Introduce exynos_handle_event()

[Tobias Jakobi]

Used to handle kernel events specific to the Exynos platform.
Currently only G2D events are handled.

v2: Adapt to container approach.
v3: Add exynos_handle_event() to Exynos symbol test.
Signed-off-by: Tobias Jakobi 
---
 exynos/exynos-symbol-check |  1 +
 exynos/exynos_drm.c| 28 
 exynos/exynos_drm.h| 12 
 exynos/exynos_drmif.h  | 26 ++
 4 files changed, 67 insertions(+)

diff --git a/exynos/exynos-symbol-check b/exynos/exynos-symbol-check
index 1a1be89..c3ddbe4 100755
--- a/exynos/exynos-symbol-check
+++ b/exynos/exynos-symbol-check
@@ -22,6 +22,7 @@ exynos_device_destroy
 exynos_prime_fd_to_handle
 exynos_prime_handle_to_fd
 exynos_vidi_connection
+exynos_handle_event
 g2d_blend
 g2d_copy
 g2d_copy_with_scale
diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
index df9b8ed..7a400ad 100644
--- a/exynos/exynos_drm.c
+++ b/exynos/exynos_drm.c
@@ -42,6 +42,8 @@
 #include "exynos_drm.h"
 #include "exynos_drmif.h"

+#define U642VOID(x) ((void *)(unsigned long)(x))
+
 /*
  * Create exynos drm device object.
  *
@@ -374,3 +376,29 @@ exynos_vidi_connection(struct exynos_device *dev, uint32_t 
connect,

return 0;
 }
+
+static void
+exynos_handle_vendor(int fd, struct drm_event *e, void *ctx)
+{
+   struct drm_exynos_g2d_event *g2d;
+   struct exynos_event_context *ectx = ctx;
+
+   switch (e->type) {
+   case DRM_EXYNOS_G2D_EVENT:
+   if (ectx->version < 1 || ectx->g2d_event_handler == 
NULL)
+   break;
+   g2d = (struct drm_exynos_g2d_event *)e;
+   ectx->g2d_event_handler(fd, g2d->cmdlist_no, 
g2d->tv_sec,
+   g2d->tv_usec, 
U642VOID(g2d->user_data));
+   break;
+
+   default:
+   break;
+   }
+}
+
+int
+exynos_handle_event(struct exynos_device *dev, struct exynos_event_context 
*ctx)
+{
+   return drmHandleEvent2(dev->fd, >base, exynos_handle_vendor);
+}
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index 256c02f..c3af0ac 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -157,4 +157,16 @@ struct drm_exynos_g2d_exec {
 #define DRM_IOCTL_EXYNOS_G2D_EXEC  DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_G2D_EXEC, struct drm_exynos_g2d_exec)

+/* EXYNOS specific events */
+#define DRM_EXYNOS_G2D_EVENT   0x8000
+
+struct drm_exynos_g2d_event {
+   struct drm_eventbase;
+   __u64   user_data;
+   __u32   tv_sec;
+   __u32   tv_usec;
+   __u32   cmdlist_no;
+   __u32   reserved;
+};
+
 #endif
diff --git a/exynos/exynos_drmif.h b/exynos/exynos_drmif.h
index c7c1d44..626e399 100644
--- a/exynos/exynos_drmif.h
+++ b/exynos/exynos_drmif.h
@@ -54,6 +54,25 @@ struct exynos_bo {
uint32_tname;
 };

+#define EXYNOS_EVENT_CONTEXT_VERSION 1
+
+/*
+ * Exynos Event Context structure.
+ *
+ * @base: base context (for core events).
+ * @version: version info similar to the one in 'drmEventContext'.
+ * @g2d_event_handler: handler for G2D events.
+ */
+struct exynos_event_context {
+   drmEventContext base;
+
+   int version;
+
+   void (*g2d_event_handler)(int fd, unsigned int cmdlist_no,
+ unsigned int tv_sec, 
unsigned int tv_usec,
+ void *user_data);
+};
+
 /*
  * device related functions:
  */
@@ -83,4 +102,11 @@ int exynos_prime_fd_to_handle(struct exynos_device *dev, 
int fd,
 int exynos_vidi_connection(struct exynos_device *dev, uint32_t connect,
uint32_t ext, void *edid);

+/*
+ * event handling related functions:
+ */
+int exynos_handle_event(struct exynos_device *dev,
+   struct exynos_event_context *ctx);
+
+
 #endif /* EXYNOS_DRMIF_H_ */
-- 
2.0.5

[PATCH 01/13] drm: Implement drmHandleEvent2()

[Tobias Jakobi]

Basically this is an extended version of drmHandleEvent().

drmHandleEvent() only handles core events (like e.g. page flips),
but since kernel DRM drivers might use vendor-specific events
to signal userspace the completion of pending jobs, etc., its
desirable to provide a way to handle these without putting
vendor-specific code in the core libdrm.

To use this you provide drmHandleEvent2() with a function that
handles your non-core events.

The signature of that function looks like this:
void vendor(int fd, struct drm_event *e, void *ctx);

'fd' is the DRM file descriptor, 'e' the non-core event
and 'ctx' the event context (casted to void).

This way we don't have to maintain a copy of drmHandleEvent()
in the vendor code.

v2: Remove the opaque pointer, since this can be better
handled with a container approach.

Signed-off-by: Tobias Jakobi 
---
 xf86drm.h | 21 +
 xf86drmMode.c | 10 +-
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/xf86drm.h b/xf86drm.h
index 481d882..1e474a3 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -750,8 +750,29 @@ typedef struct _drmEventContext {

 } drmEventContext, *drmEventContextPtr;

+typedef void (*drmEventVendorHandler)(int fd, struct drm_event *e, void *ctx);
+
 extern int drmHandleEvent(int fd, drmEventContextPtr evctx);

+/*
+ * drmHandleEvent2() is an extended variant of drmHandleEvent() which
+ * allows handling of vendor-specific/non-core events.
+ * The function pointer 'vendorhandler' is used (if non-zero) to
+ * process non-core events. Users of have to prepare a container struct
+ * in the following way:
+ *
+ * struct vendor_event_context {
+ * drmEventContext base;
+ * int vendor_specific_data[num];
+ * };
+ *
+ * And then call:
+ * struct vendor_event_context ctx = {0};
+ * drmHandleEvent2(fd, , handler);
+ */
+extern int drmHandleEvent2(int fd, drmEventContextPtr evctx,
+   drmEventVendorHandler vendorhandler);
+
 extern char *drmGetDeviceNameFromFd(int fd);
 extern int drmGetNodeTypeFromFd(int fd);

diff --git a/xf86drmMode.c b/xf86drmMode.c
index ab6b519..89698da 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -867,7 +867,8 @@ int drmModeCrtcSetGamma(int fd, uint32_t crtc_id, uint32_t 
size,
return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETGAMMA, );
 }

-int drmHandleEvent(int fd, drmEventContextPtr evctx)
+int drmHandleEvent2(int fd, drmEventContextPtr evctx,
+   drmEventVendorHandler vendorhandler)
 {
char buffer[1024];
int len, i;
@@ -910,6 +911,8 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
 U642VOID (vblank->user_data));
break;
default:
+   if (vendorhandler)
+   vendorhandler(fd, e, evctx);
break;
}
i += e->length;
@@ -918,6 +921,11 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
return 0;
 }

+int drmHandleEvent(int fd, drmEventContextPtr evctx)
+{
+   return drmHandleEvent2(fd, evctx, NULL);
+}
+
 int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t fb_id,
uint32_t flags, void *user_data)
 {
-- 
2.0.5

[PATCH 00/13] drm/exynos: async G2D and g2d_move()

[Tobias Jakobi]

Hello,

this series mostly touches G2D code. It introduces the following:

(1) drmHandleEvent2() is added to enable processing of vendor-specific
events. This will be used to expose asynchronous operation of the
G2D. The necessary kernel infrastructure is already there since
a lot of kernel versions. [This touches libdrm core code!]

(2) The necessary infrastructure to handle G2D events. This includes
adding g2d_config_event() and g2d_exec2() to the public API.
A test application is provided to ensure that everything works
as expected.

(3) A small performance test application which can be used to measure
the speed of solid color clear operations. Interesting for
benchmarking and plotting colorful graphs (e.g. through
Mathematica).

(4) g2d_move() which works similar to g2d_copy() but like the C
memmove() properly handles overlapping buffer copies.
Again a test application is present to check that this
indeed does what it should.

(5) Various small changes. A framebuffer colorformat fix for the
general G2D test application. Moving the currently unused
g2d_reset() to the public API. Adding a counterpart to
exynos_bo_map() to unmap buffers again.

(6) Last but not least a small bump of the Exynos version number.

Please review and let me know what I should change/improve.


With best wishes,
Tobias

P.S.: Most patches were submitted already some time ago but never
made it upstream. So if something looks familiar, don't worry! ;)

Tobias Jakobi (13):
  drm: Implement drmHandleEvent2()
  exynos: Introduce exynos_handle_event()
  tests/exynos: add fimg2d performance analysis
  exynos/fimg2d: add g2d_config_event
  exynos: fimg2d: add g2d_exec2
  tests/exynos: add fimg2d event test
  tests/exynos: use XRGB for framebuffer
  exynos: fimg2d: add g2d_set_direction
  exynos/fimg2d: add g2d_move
  tests/exynos: add test for g2d_move
  exynos/fimg2d: add exynos_bo_unmap()
  exynos/fimg2d: add g2d_reset() to public API
  exynos: bump version number

 exynos/exynos-symbol-check |   5 +
 exynos/exynos_drm.c|  48 ++
 exynos/exynos_drm.h|  12 ++
 exynos/exynos_drmif.h  |  27 +++
 exynos/exynos_fimg2d.c | 164 +--
 exynos/exynos_fimg2d.h |  49 ++
 exynos/libdrm_exynos.pc.in |   2 +-
 tests/exynos/Makefile.am   |  26 ++-
 tests/exynos/exynos_fimg2d_event.c | 326 +
 tests/exynos/exynos_fimg2d_perf.c  | 320 
 tests/exynos/exynos_fimg2d_test.c  | 134 ++-
 xf86drm.h  |  21 +++
 xf86drmMode.c  |  10 +-
 13 files changed, 1128 insertions(+), 16 deletions(-)
 create mode 100644 tests/exynos/exynos_fimg2d_event.c
 create mode 100644 tests/exynos/exynos_fimg2d_perf.c

-- 
2.0.5

[PATCH 04/23] drm: Add drm structures for palette color property

[Emil Velikov]

Hi Ville,

On 22 September 2015 at 16:00, Ville Syrjälä
 wrote:
> On Tue, Sep 22, 2015 at 02:53:54PM +0100, Emil Velikov wrote:
>> On 22 September 2015 at 14:08, Daniel Vetter  wrote:
>> > On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
>> >> From: Kausal Malladi 
>> >>
>> >> This patch adds new structures in DRM layer for Palette color
>> >> correction.These structures will be used by user space agents
>> >> to configure appropriate number of samples and Palette LUT for
>> >> a platform.
>> >>
>> >> Signed-off-by: Shashank Sharma 
>> >> Signed-off-by: Kausal Malladi 
>> >> ---
>> >>  include/uapi/drm/drm.h | 27 +++
>> >>  1 file changed, 27 insertions(+)
>> >>
>> >> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> >> index e3c642f..f72b916 100644
>> >> --- a/include/uapi/drm/drm.h
>> >> +++ b/include/uapi/drm/drm.h
>> [snip]
>> >> +struct drm_palette {
>> [snip]
>> > ... extending the ioctl struct at the end ...
>> Is this really going to work, considering that we currently have a
>> zero sized drm_r32g32b32 array at the end ?
>
> Well in this particular case it would be ugly. Sure, it can be done,
> but we couldn't actually define the struct for it using C. Would be
> a neat feature though. Someone should propose it for the next C
> standard :)
>
> In any case, for blobs I think we shouldn't extend them like ioctls.
> In this case the blob is just an array of something, so the blob size
> can of course vary depending how many elements are required for the
> particual platform.
>
Sure it makes sense on its own. I'm curious how likely it will be for
people to get confused/carried away and miss that part. Just a food
for thought.

>> Iirc someone mentioned that using a pointer to the data (over an
>> array) has drawbacks, although for the sake of me I cannot think of
>> any. Can anyone care to enlighten me, please ?
>
> I guess an extensible array at the end of the struct is simply a nice
> fit sometimes. Also makes it more obvious how much junk gets copied over
> I suppose.
>
So no serious 'issues' there, but it's mostly done for convenience.
Thanks for clarifying.

Regards,
Emil

[patch 4/4 v2] drm/qxl: integer overflow in qxl_alloc_surf_ioctl()

[Dan Carpenter]

The size calculation can overflow.  I don't know if this leads to
memory corruption, but it causes a static checker warning.

Signed-off-by: Dan Carpenter 
---
v2: I don't know think the size is capped anywhere.  In my first version
of this patch, I introduced a divide by zero bug.

diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index b2db482..49b3158 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -396,12 +396,14 @@ static int qxl_alloc_surf_ioctl(struct drm_device *dev, 
void *data,
struct qxl_bo *qobj;
int handle;
int ret;
-   int size, actual_stride;
+   u64 size, actual_stride;
struct qxl_surface surf;

/* work out size allocate bo with handle */
actual_stride = param->stride < 0 ? -param->stride : param->stride;
size = actual_stride * param->height + actual_stride;
+   if (size > INT_MAX)
+   return -EINVAL;

surf.format = param->format;
surf.width = param->width;

[PATCH v2 5/6] virtio-gpu: add basic prime support

[Gerd Hoffmann]

> > +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> > +  struct vm_area_struct *area)
> > +{
> > +   WARN_ONCE(1, "not implemented");
> > +   return ENOSYS;
> 
> This can get called by userspace, so please don't WARN here. Also missing
> negate sign:
> 
>   return -ENOSYS;

Hmm now checkpatch throws a warning at me:


   WARNING: ENOSYS means 'invalid syscall nr' and nothing else
   #12: FILE: drivers/gpu/drm/virtio/virtgpu_prime.c:70:
   +   return -ENOSYS;


I guess I should use something else then (here and elsewhere in the
file)?  Maybe -EINVAL?  Other suggestions?

thanks,
  Gerd

[PATCH v2 4/6] virtio-gpu: add 3d/virgl support

[Gerd Hoffmann]

  Hi,

> >  static unsigned int features[] = {
> > +#ifdef __LITTLE_ENDIAN
> > +   VIRTIO_GPU_FEATURE_VIRGL,
> > +#endif
> >  };
> 
> Why is virgl LE specific? Just curious.

gallium command stream is native endian, and we only support little
endian guests on little endian hosts for that reason.

Supporting bigendian guests on bigendian hosts should be possible too
(with a VIRGl_BE feature flag), but with even the powerpc world moving
to little endian I see little reason to actually bother.

To be clear: this affects 3d acceleration only, 2d mode works fine on
every host/guest endian combination.

> > +#ifdef __LITTLE_ENDIAN
> > +   if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_FEATURE_VIRGL))
> > +   vgdev->has_virgl_3d = true;
> > +#endif
> 
> You might be able to get by without this ifdef as
> VIRTIO_GPU_FEATURE_VIRGL won't be set without it.

Yes, right, this #ifdef can go away.

> > +int virtio_gpu_cmd_get_capset_info(struct virtio_gpu_device *vgdev, int 
> > idx)
> > +{
> > +   struct virtio_gpu_get_capset_info *cmd_p;
> > +   struct virtio_gpu_vbuffer *vbuf;
> > +   void *resp_buf;
> > +
> > +   resp_buf = kzalloc(sizeof(struct virtio_gpu_resp_capset_info),
> > +  GFP_KERNEL);
> > +   if (!resp_buf)
> > +   return -ENOMEM;
> > +
> > +   cmd_p = virtio_gpu_alloc_cmd_resp
> > +   (vgdev, _gpu_cmd_get_capset_info_cb, ,
> > +sizeof(*cmd_p), sizeof(struct virtio_gpu_resp_capset_info),
> > +resp_buf);
> > +   memset(cmd_p, 0, sizeof(*cmd_p));
> > +
> > +   cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_GET_CAPSET_INFO);
> > +   cmd_p->capset_index = cpu_to_le32(idx);
> > +   virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
> > +   return 0;
> > +}
> > +
> 
> I note that all callers ignore the recurn code from
> virtio_gpu_queue_ctrl_buffer.
> 
> Is there a reason it can't fail?

It can only fail when vgdev->vqs_ready is false.  Which can only happen
when we are about to unload the driver.  In that case we probably don't
worry much about the failure ...

> Shouldn't it be made void then?

I guess we should ...

> > +   cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_CTX_CREATE);
> > +   cmd_p->hdr.ctx_id = cpu_to_le32(id);
> > +   cmd_p->nlen = cpu_to_le32(nlen);
> > +   strncpy(cmd_p->debug_name, name, 63);
> > +   cmd_p->debug_name[63] = 0;
> 
> sizeof (cmd_p->debug_name) - 1 will be a but prettier.

Agree.

> > diff --git a/include/uapi/linux/virtio_gpu.h 
> > b/include/uapi/linux/virtio_gpu.h
> > index 478be52..7f4f9ce 100644
> > --- a/include/uapi/linux/virtio_gpu.h
> > +++ b/include/uapi/linux/virtio_gpu.h
> > @@ -40,6 +40,8 @@
> >  
> >  #include 
> >  
> > +#define VIRTIO_GPU_FEATURE_VIRGL 0
> > +
> 
> I'd prefer it named VIRTIO_GPU_F_VIRGL for consistency with other
> devices.

Makes sense, I'll change it.

thanks,
  Gerd

[regression] [git pull] drm for 4.3

[Daniel Vetter]

On Tue, Sep 22, 2015 at 08:00:17AM -0700, Jesse Barnes wrote:
> Cc'ing Maarten and Matt; I'm guessing this may be related to one of
> their recent patches.

Adding Jairo to track this regression.
-Daniel

>
> Jesse
>
> On 09/21/2015 11:48 AM, Dave Jones wrote:
> > On Mon, Sep 07, 2015 at 02:45:59PM -0400, Dave Jones wrote:
> >  > On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote:
> >  >  >
> >  >  > Hi Linus,
> >  >  >
> >  >  > This is the main pull request for the drm for 4.3. Nouveau is 
> > probably the biggest
> >  >  > amount of changes in here, since it missed 4.2. Highlights below, 
> > along with the usual
> >  >  > bunch of fixes. There are a few minor conflicts with your tree but 
> > nothing
> >  >  > you can't handle. All stuff outside drm should have applicable acks.
> >  >  >
> >  >  > Highlights:
> >  >  >
> >  >  > ...
> >  >  > i915:
> >  >  > Skylake support enabled by default
> >  >  > legacy modesetting using atomic infrastructure
> >  >  > Skylake fixes
> >  >  > GEN9 workarounds
> >  >
> >  > Since this merge, I'm seeing this twice during boot..
> >
> > And still there in -rc2.  Several other people reported this too,
> > and they also got no reponse.
> >
> > I'll start bisecting when I get home tonight. It shouldn't be too hard,
> > as 4.2 was fine.
> >
> > Dave
> >
> >  > [ cut here ]
> >  > WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 
> > assert_planes_disabled+0xdf/0x140()
> >  > plane A assertion failure, should be disabled but not
> >  > CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9
> >  > Workqueue: events_unbound async_run_entry_fn
> >  >  0561 88050392b6f8 8d7dccce 88050392b740
> >  >  88050392b730 8d079ee2 880500a6 
> >  >    8805008e99c8 88050392b790
> >  > Call Trace:
> >  >  [] dump_stack+0x4e/0x79
> >  >  [] warn_slowpath_common+0x82/0xc0
> >  >  [] warn_slowpath_fmt+0x4c/0x50
> >  >  [] assert_planes_disabled+0xdf/0x140
> >  >  [] intel_disable_pipe+0x4b/0x2c0
> >  >  [] haswell_crtc_disable+0x8a/0x2e0
> >  >  [] intel_atomic_commit+0xff/0x1320
> >  >  [] ? drm_atomic_check_only+0x21e/0x550
> >  >  [] drm_atomic_commit+0x37/0x60
> >  >  [] drm_atomic_helper_set_config+0x1c5/0x430
> >  >  [] drm_mode_set_config_internal+0x65/0x110
> >  >  [] restore_fbdev_mode+0xbe/0xe0
> >  >  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70
> >  >  [] drm_fb_helper_set_par+0x2d/0x50
> >  >  [] intel_fbdev_set_par+0x1a/0x60
> >  >  [] fbcon_init+0x545/0x5d0
> >  >  [] visual_init+0xca/0x130
> >  >  [] do_bind_con_driver+0x1c5/0x3b0
> >  >  [] do_take_over_console+0x149/0x1a0
> >  >  [] do_fbcon_takeover+0x57/0xb0
> >  >  [] fbcon_event_notify+0x66c/0x760
> >  >  [] notifier_call_chain+0x3e/0xb0
> >  >  [] __blocking_notifier_call_chain+0x4d/0x70
> >  >  [] blocking_notifier_call_chain+0x16/0x20
> >  >  [] fb_notifier_call_chain+0x1b/0x20
> >  >  [] register_framebuffer+0x1e7/0x300
> >  >  [] drm_fb_helper_initial_config+0x252/0x3e0
> >  >  [] intel_fbdev_initial_config+0x1b/0x20
> >  >  [] async_run_entry_fn+0x4a/0x140
> >  >  [] process_one_work+0x1fd/0x670
> >  >  [] ? process_one_work+0x16c/0x670
> >  >  [] worker_thread+0x4e/0x450
> >  >  [] ? process_one_work+0x670/0x670
> >  >  [] kthread+0x101/0x120
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  >  [] ret_from_fork+0x3f/0x70
> >  >  [] ? kthread_create_on_node+0x250/0x250
> >  > ---[ end trace 54cab2e0c772d5d9 ]---
> >  >
> >  >
> >  > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 
> > Processor Integrated Graphics Controller (rev 06)
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
>
> ___
> 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

[Intel-gfx] [PATCH 0/8] [RFC] Link training test

[Daniel Vetter]

Thierry Redding is working on some improved dp helper libraries for link
training. Would make lots of sense to have all that aligned. Adding him
and dri-devel.
-Daniel

On Tue, Sep 8, 2015 at 2:27 PM, Ander Conselvan de Oliveira 
 wrote:
> Hi,
>
> There's been some discussion on improving our link training code, with
> one of the ideas being a complete rewrite of the state machine. However,
> a concern was raised over the risk of regressions. The code we have has
> seen a lot of real world testing, and it would take a long time for any
> new code to get that same exposure. On top of that, there is no explicit
> igt coverage for link training since it is very dependent on the hw
> setup.
>
> Since gathering an extensive set of hardware combinations for getting the
> appropriate test coverage is really difficult, I believe that we should
> aim at testing the link training code in isolation. That's what this RFC
> is about.
>
> Most of the kernel patches in this series are small changes to the hw
> independent part of the link training code that make it possible to move
> it to a separate file.  Then, in the igt patch, a test is created the
> wraps a fake DP sink device around the link training code. The behavior
> of that sink device is pretty simple for now, it just tries to get the
> maximum voltage swing and pre-emphasis level supported. We could do some
> git archeology of the link training code to try to find some more tests
> that would make sense.
>
> I had to make a lot of hacks to get that thing to compile, so that's
> one of the things I'd like to hear comments on. And also on the general
> approach.
>
> Thanks,
> Ander
>
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

[PATCH 2/2] drm/core: Preserve the fb id on close.

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 4:40 PM, Maarten Lankhorst
 wrote:
> Keep the fb_id, which means that any application exiting without
> unsetting the framebuffer from all planes will preserve its contents.
>
> This is similar to preserving the initial framebuffer, except all
> planes are preserved.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_crtc.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)

Same as 1/2:

Reviewed-by: David Herrmann 

Thanks
David

> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 626b0a57efbf..9d55c0c6aa95 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3320,9 +3320,6 @@ int drm_mode_rmfb(struct drm_device *dev,
> if (!found)
> goto fail_lookup;
>
> -   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
> -   __drm_framebuffer_unregister(dev, fb);
> -
> list_del_init(>filp_head);
> mutex_unlock(>mode_config.fb_lock);
> mutex_unlock(_priv->fbs_lock);
> @@ -3508,15 +3505,9 @@ void drm_fb_release(struct drm_file *priv)
>  * at it any more.
>  */
> list_for_each_entry_safe(fb, tfb, >fbs, filp_head) {
> -
> -   mutex_lock(>mode_config.fb_lock);
> -   /* Mark fb as reaped, we still have a ref from fpriv->fbs. */
> -   __drm_framebuffer_unregister(dev, fb);
> -   mutex_unlock(>mode_config.fb_lock);
> -
> list_del_init(>filp_head);
>
> -   /* This will also drop the fpriv->fbs reference. */
> +   /* This drops the fpriv->fbs reference. */
> drm_framebuffer_unreference(fb);
> }
>  }
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90()

[Alex Deucher]

On Tue, Sep 22, 2015 at 4:21 PM, Borislav Petkov  wrote:
> Hi Alex,
>
> On Tue, Sep 22, 2015 at 03:58:03PM -0400, Alex Deucher wrote:
>> What system is this?
>
> my workstation - an
>
> "To be filled by O.E.M. To be filled by O.E.M./M5A97 EVO R2.0, BIOS 1503 
> 01/16/2013"
>
> you gotta love the "To be filled" crap. In any case, it is an ASUS M5A97
> EVO R2.0. RD890 chip AFAICT.
>
>> What GPU are you using?
>
> RV635. Here's some dmesg:
>
> [6.489016] [drm] initializing kernel modesetting (RV635 0x1002:0x9598 
> 0x1043:0x01DA).
> [7.509177] radeon :01:00.0: VRAM: 512M 0x - 
> 0x1FFF (512M used)
> [7.518010] radeon :01:00.0: GTT: 512M 0x2000 - 
> 0x3FFF
> [7.525724] [drm] Detected VRAM RAM=512M, BAR=256M
> [7.530608] [drm] RAM width 128bits DDR
> [7.535168] [TTM] Zone  kernel: Available graphics memory: 8132226 kiB
> [7.541779] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [7.548420] [TTM] Initializing pool allocator
> [7.552896] [TTM] Initializing DMA pool allocator
> [7.558176] [drm] radeon: 512M of VRAM memory ready
> [7.563131] [drm] radeon: 512M of GTT memory ready.
> [7.568151] [drm] Loading RV635 Microcode
> [7.577382] [drm] Internal thermal controller without fan control
> [7.584349] [drm] radeon: power management initialized
> [7.590443] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [7.597266] [drm] enabling PCIE gen 2 link speeds, disable with 
> radeon.pcie_gen2=0
> [7.624386] [drm] PCIE GART of 512M enabled (table at 0x00254000).
> [7.631544] radeon :01:00.0: WB enabled
> [7.635794] radeon :01:00.0: fence driver on ring 0 use gpu addr 
> 0x2c00 and cpu addr 0x880427ef7c00
> [7.647039] radeon :01:00.0: fence driver on ring 5 use gpu addr 
> 0x000521d0 and cpu addr 0xc98121d0
> [7.657924] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [7.664601] [drm] Driver supports precise vblank timestamp query.
> [7.670780] radeon :01:00.0: radeon: MSI limited to 32-bit
> [7.676801] radeon :01:00.0: radeon: using MSI.
> [7.681863] [drm] radeon: irq initialized.
> [7.717757] [drm] ring test on 0 succeeded in 0 usecs
> [7.897466] [drm] ring test on 5 succeeded in 1 usecs
> [7.902585] [drm] UVD initialized successfully.
> [7.908108] [drm] ib test on ring 0 succeeded in 0 usecs
> [8.558968] [drm] ib test on ring 5 succeeded
> [8.568734] [drm] Radeon Display Connectors
> [8.573005] [drm] Connector 0:
> [8.576189] [drm]   DVI-I-1
> [8.579062] [drm]   HPD1
> [8.581657] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 
> 0x7e5c
> [8.589172] [drm]   Encoders:
> [8.592234] [drm] DFP1: INTERNAL_UNIPHY
> [8.596492] [drm] CRT2: INTERNAL_KLDSCP_DAC2
> [8.601182] [drm] Connector 1:
> [8.604302] [drm]   DIN-1
> [8.607012] [drm]   Encoders:
> [8.610043] [drm] TV1: INTERNAL_KLDSCP_DAC2
> [8.614642] [drm] Connector 2:
> [8.617760] [drm]   DVI-I-2
> [8.620621] [drm]   HPD2
> [8.623226] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
> 0x7e4c
> [8.630719] [drm]   Encoders:
> [8.633749] [drm] CRT1: INTERNAL_KLDSCP_DAC1
> [8.638436] [drm] DFP2: INTERNAL_KLDSCP_LVTMA
> [8.719815] [drm] fb mappable at 0xC0355000
> [8.724089] [drm] vram apper at 0xC000
> [8.728243] [drm] size 9216000
> [8.731371] [drm] fb depth is 24
> [8.734664] [drm]pitch is 7680
> [8.739009] fbcon: radeondrmfb (fb0) is primary device
> [8.802887] Console: switching to colour frame buffer device 240x75
> [8.818487] radeon :01:00.0: fb0: radeondrmfb frame buffer device
> [8.824948] radeon :01:00.0: registered panic notifier
> [8.846452] [drm] Initialized radeon 2.42.0 20080528 for :01:00.0 on 
> minor 0
>
>> Can you bisect?
>
> It is my workstation so it will take longer but I'll try.
>
> If you can think of some particular commits I should try, let me know.

Sorry, I can't think of anything off hand.  I suspect it was some
change or cleanup in the core drm code.

Alex

[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[David Herrmann]

Hi

On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin
 wrote:
> On 09/10/2015 10:56 AM, Daniel Vetter wrote:
>> That's not different from the compositor just freezing instead of
>> crashing: Screen contents stays on and nothing happens. Imo this really is
>> all just broken userspace, and the kernel can't make sure userspace
>> doesn't randomly fall over.
>>
>> What we need to make sure is that assuming things work ok-ish there's no
>> observed regression. And I still think that's the case here.
>
>
> I would disagree on the no regressions when things work okay-ish principle,
> there should be no regressions in the pessimistic scenario when security is
> concerned.
>
> If we can agree the stuck frame on screen is not desirable from the security
> point of view, then this change does enlarge the attack surface.
>
> Because, apart from freezing the compositor, it now also works to crash it
> and prevent restart. Maybe it is far fetched, but as I said, attackers have
> much better imagination with these things.

I'd much more prefer a FB flag that forces a modeset on ID removal.
Anyone who cares for it can set it, and the kernel will make sure to
never keep such FBs around. However, for most use-cases, we want the
FB to stay around after close() or FB removal.

Btw., I also don't see the attack scenario at all. If an attacker
makes your compositor crash at the same moment a security-relevant
information is shown on screen, then the information is already
visible. Who cares that it stays visible? Sure, I can make up an
hypothetical use-case where that matters, but I cannot think of
something real.
Also, if the hypothetical scenario we go for is "if the compositor
crashes", then I guess there's bigger problems than the FB content.

Thanks
David

[PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 5:02 PM, Daniel Vetter  wrote:
> On Wed, Sep 09, 2015 at 04:40:56PM +0200, Maarten Lankhorst wrote:
>> Previously RMFB and fd close chose to disable any plane that had
>> an active framebuffer from this file. If it was a primary plane the
>> crtc was disabled. However the fbdev code or any system compositor
>> should restore the planes anyway so there's no need to do it twice.
>>
>> The old fb_id is zero'd, so there's no danger of being able to
>> restore the fb from fb_id.
>>
>> Signed-off-by: Maarten Lankhorst 
>
> I think the current behaviour was just a side-effect of the original
> implementation and not too intentional - with no refcounting for fbs they
> _had_ to be synchronously reaped. And when I've done the conversion to
> refcounting I kept this to avoid gettting tangled up in an ABI-change
> mess.
>
> But I don't the current behaviour makes much sense and worth an attemp to
> rectify it. And as long as we still clear the fb ids there's no real
> information leak either.
>
> Reviewed-by: Daniel Vetter 
>
> But I do want other people's opinion before I pull this in.

We _REALLY_ want this! It makes a lot of our life much easier when
trying to get rid of flicker during boot-up. It currently sucks that
neither the boot-loader screen, nor the boot-splash screen, nor the
login-manager screen can be left around after they quit and handover
to the next stage. We have to stay around for hand-over, which is
nasty and requires a back-channel which is otherwise not needed at
all.

Reviewed-by: David Herrmann 

Thanks
David

[PATCH v1.1 03/15] vga_switcheroo: Set active attribute to false for audio clients

[Lukas Wunner]

The active attribute in struct vga_switcheroo_client denotes whether
the outputs are currently switched to this client. The attribute is
only meaningful for vga clients. It is never used for audio clients.

The function vga_switcheroo_register_audio_client() misuses this
attribute to store whether the audio device is fully initialized.
Most likely there was a misunderstanding about the meaning of
"active" when this was added.

Set the active attribute to false for audio clients. Remove the
active parameter from vga_switcheroo_register_audio_client() and
its sole caller, hda_intel.c:register_vga_switcheroo().

vga_switcheroo_register_audio_client() was introduced by 3e9e63dbd374
("vga_switcheroo: Add the support for audio clients"). Its use in
hda_intel.c was introduced by a82d51ed24bb ("ALSA: hda - Support
VGA-switcheroo").

v1.1: The changes above imply that in find_active_client() the call
to client_is_vga() is now superfluous. Drop it.

Cc: Takashi Iwai 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 7 +++
 include/linux/vga_switcheroo.h   | 4 ++--
 sound/pci/hda/hda_intel.c| 3 +--
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 2e7e2f8e..563b82f 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -290,7 +290,6 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  * @pdev: client pci device
  * @ops: client callbacks
  * @id: client identifier, see enum vga_switcheroo_client_id
- * @active: whether the audio device is fully initialized
  *
  * Register audio client (audio device on a GPU). The power state of the
  * client is assumed to be ON.
@@ -299,9 +298,9 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  */
 int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
 const struct vga_switcheroo_client_ops 
*ops,
-int id, bool active)
+int id)
 {
-   return register_client(pdev, ops, id | ID_BIT_AUDIO, active, false);
+   return register_client(pdev, ops, id | ID_BIT_AUDIO, false, false);
 }
 EXPORT_SYMBOL(vga_switcheroo_register_audio_client);

@@ -333,7 +332,7 @@ find_active_client(struct list_head *head)
struct vga_switcheroo_client *client;

list_for_each_entry(client, head, list)
-   if (client->active && client_is_vga(client))
+   if (client->active)
return client;
return NULL;
 }
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index fe90bfc..3764991 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -128,7 +128,7 @@ int vga_switcheroo_register_client(struct pci_dev *dev,
   bool driver_power_control);
 int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
 const struct vga_switcheroo_client_ops 
*ops,
-int id, bool active);
+int id);

 void vga_switcheroo_client_fb_set(struct pci_dev *dev,
  struct fb_info *info);
@@ -154,7 +154,7 @@ static inline void vga_switcheroo_client_fb_set(struct 
pci_dev *dev, struct fb_i
 static inline int vga_switcheroo_register_handler(struct 
vga_switcheroo_handler *handler) { return 0; }
 static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
const struct vga_switcheroo_client_ops *ops,
-   int id, bool active) { return 0; }
+   int id) { return 0; }
 static inline void vga_switcheroo_unregister_handler(void) {}
 static inline int vga_switcheroo_process_delayed_switch(void) { return 0; }
 static inline int vga_switcheroo_get_client_state(struct pci_dev *dev) { 
return VGA_SWITCHEROO_ON; }
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index c38c68f..e819013 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1143,8 +1143,7 @@ static int register_vga_switcheroo(struct azx *chip)
 * is there any machine with two switchable HDMI audio controllers?
 */
err = vga_switcheroo_register_audio_client(chip->pci, _vs_ops,
-   VGA_SWITCHEROO_DIS,
-   hda->probe_continued);
+  VGA_SWITCHEROO_DIS);
if (err < 0)
return err;
hda->vga_switcheroo_registered = 1;
-- 
1.8.5.2 (Apple Git-48)

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Ville Syrjälä]

On Tue, Sep 22, 2015 at 02:59:24PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2015 at 03:35:13PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 22, 2015 at 02:17:51PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 22, 2015 at 03:00:54PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > > > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > > > dev node per DP AUX channel, named drm_aux-N.
> > > > > 
> > > > > It's possible to know which connector owns this aux channel by looking
> > > > > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > > > > the connector device pointer was correctly set in the aux helper 
> > > > > struct.
> > > > > 
> > > > > Two main operations are provided on the registers: read and write. The
> > > > > address of the register to be read or written is given using lseek.
> > > > > Reading or writing does not update the offset of the file.
> > > > > 
> > > > > Signed-off-by: Rafael Antognolli 
> > > > > ---
> > > > >  drivers/gpu/drm/Kconfig   |   4 +
> > > > >  drivers/gpu/drm/Makefile  |   1 +
> > > > >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > > > > ++
> > > > >  3 files changed, 331 insertions(+)
> > > > >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > > index 1a0a8df..eae847c 100644
> > > > > --- a/drivers/gpu/drm/Kconfig
> > > > > +++ b/drivers/gpu/drm/Kconfig
> > > > > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > > > >   bool
> > > > >   depends on DRM
> > > > >  
> > > > > +config DRM_AUX_CHARDEV
> > > > > + tristate "DRM DP AUX Interface"
> > > > > + depends on DRM
> > > > > +
> > > > >  config DRM_KMS_HELPER
> > > > >   tristate
> > > > >   depends on DRM
> > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > > index 45e7719..a1a94306 100644
> > > > > --- a/drivers/gpu/drm/Makefile
> > > > > +++ b/drivers/gpu/drm/Makefile
> > > > > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> > > > >  
> > > > >  obj-$(CONFIG_DRM)+= drm.o
> > > > >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > > > > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> > > > >  obj-$(CONFIG_DRM_TTM)+= ttm/
> > > > >  obj-$(CONFIG_DRM_TDFX)   += tdfx/
> > > > >  obj-$(CONFIG_DRM_R128)   += r128/
> > > > > diff --git a/drivers/gpu/drm/drm_aux-dev.c 
> > > > > b/drivers/gpu/drm/drm_aux-dev.c
> > > > > new file mode 100644
> > > > > index 000..fcc334a
> > > > > --- /dev/null
> > > > > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > > > > @@ -0,0 +1,326 @@
> > > > > +/*
> > > > > + * Copyright © 2015 Intel Corporation
> > > > > + *
> > > > > + * Permission is hereby granted, free of charge, to any person 
> > > > > obtaining a
> > > > > + * copy of this software and associated documentation files (the 
> > > > > "Software"),
> > > > > + * to deal in the Software without restriction, including without 
> > > > > limitation
> > > > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > > > sublicense,
> > > > > + * and/or sell copies of the Software, and to permit persons to whom 
> > > > > the
> > > > > + * Software is furnished to do so, subject to the following 
> > > > > conditions:
> > > > > + *
> > > > > + * The above copyright notice and this permission notice (including 
> > > > > the next
> > > > > + * paragraph) shall be included in all copies or substantial 
> > > > > portions of the
> > > > > + * Software.
> > > > > + *
> > > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > > > EXPRESS OR
> > > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > > > MERCHANTABILITY,
> > > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
> > > > > EVENT SHALL
> > > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
> > > > > OR OTHER
> > > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > > > ARISING
> > > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 
> > > > > OTHER DEALINGS
> > > > > + * IN THE SOFTWARE.
> > > > > + *
> > > > > + * Authors:
> > > > > + *Rafael Antognolli 
> > > > > + *
> > > > > + */
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +struct drm_aux_dev {
> > > > > + struct list_head list;
> > > > > + unsigned index;
> > > > > + struct drm_dp_aux *aux;
> > > > > + struct device *dev;
> > > > > +};
> > > > > +
> > > > > +#define DRM_AUX_MINORS   256
> > > > > +static int drm_aux_dev_count = 0;
> > > > > +static LIST_HEAD(drm_aux_dev_list);
> > > > > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > > > > +
> > > > > 

[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Tvrtko Ursulin]

On 09/22/2015 03:53 PM, David Herrmann wrote:
> Hi
>
> On Thu, Sep 10, 2015 at 12:15 PM, Tvrtko Ursulin
>  wrote:
>> On 09/10/2015 10:56 AM, Daniel Vetter wrote:
>>> That's not different from the compositor just freezing instead of
>>> crashing: Screen contents stays on and nothing happens. Imo this really is
>>> all just broken userspace, and the kernel can't make sure userspace
>>> doesn't randomly fall over.
>>>
>>> What we need to make sure is that assuming things work ok-ish there's no
>>> observed regression. And I still think that's the case here.
>>
>>
>> I would disagree on the no regressions when things work okay-ish principle,
>> there should be no regressions in the pessimistic scenario when security is
>> concerned.
>>
>> If we can agree the stuck frame on screen is not desirable from the security
>> point of view, then this change does enlarge the attack surface.
>>
>> Because, apart from freezing the compositor, it now also works to crash it
>> and prevent restart. Maybe it is far fetched, but as I said, attackers have
>> much better imagination with these things.
>
> I'd much more prefer a FB flag that forces a modeset on ID removal.
> Anyone who cares for it can set it, and the kernel will make sure to
> never keep such FBs around. However, for most use-cases, we want the
> FB to stay around after close() or FB removal.
>
> Btw., I also don't see the attack scenario at all. If an attacker
> makes your compositor crash at the same moment a security-relevant
> information is shown on screen, then the information is already
> visible. Who cares that it stays visible? Sure, I can make up an
> hypothetical use-case where that matters, but I cannot think of
> something real.
> Also, if the hypothetical scenario we go for is "if the compositor
> crashes", then I guess there's bigger problems than the FB content.

It allows losing control of the sensitive information in a new way and 
so by definition results in a less secure system.

Apparently for the goal of less flicker and easier userspace 
programming. Ie. avoiding the need for a back channel, apart from the 
fact back channel has now just been moved to the kernel.

I would recommend passing this by some more security conscious eyes.

Regards,

Tvrtko

[PATCH v5 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 24 +++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 90c4fda..5f8fc11 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)

 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,24 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;

+   if (dp->plat_data && dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EINVAL;
+   }
+   }
+
+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(dp->connector, edid);
+   num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 3a136b8..089489d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5

+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];

struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR   0x50
-#define I2C_E_EDID_DEVICE_ADDR 0x30
-
-#define EDID_BLOCK_LENGTH  0x80
-#define EDID_HEADER_PATTERN0x00
-#define EDID_EXTENSION_FLAG0x7e
-#define EDID_CHECKSUM  0x7f
-
-/* DP_MAX_LANE_COUNT */
-#define 

[PATCH v5 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7e83738..90c4fda 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)

 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
-- 
1.9.1

[RFC] Docs: drm: Move KMS properties table out to source files

[Danilo Cesar Lemes de Paula]

On 09/22/2015 07:22 AM, Graham Whaley wrote:
> On Wed, Sep 02, 2015 at 02:50:52PM +0100, Graham Whaley wrote:
>>> (RFC/test - not for merging)
>>> The below is a test of moving the large HTML KMS properties table
>>> out
>>> to markdown style in the appropriate files.
>>> In the test we only use the first few rows of the existing KMS
>>> table
>>> an example.
>>> We use a fixed width table as the other styles of table supported
>>> by
>>> pandoc markdown do not support multi-column cells.
>>>
>>> The test shows a couple of issues:
>>>  1) double quote characters are being expanded in the fixed width
>>> table
>>>  which then breaks the table alignment and leaves html style
>>>  tags
>>>  in the text
> 
> Further to this item:
>  Before I continue working on splitting the tables and converting to
> markdown (which btw Daniel does look feasible so far...), I thought we
> should understand what was going on with the markdown table quote
> breakage.
>  I think I know what is happenig.
>  The problem revolves around highlight expansion in the kenrel-doc
> script. In the output_highlight function we can see that first the
> script does highlight expansion (with the eval of @dohighlight), and
> then it invokes the markdown processing.
>  Done that way around what happens is:
>  - @dohighlight expands any "X" to html/xml quote tag sequences
>  - which can push the text beyond the table column widths,
>  - and then the markdown tries to split the text over columns, and
> manages to put the break in the middle of a tag, and thus breaks the
> tag formatting (see below)
> 
> At least that is what I think is happening.
> I had thought maybe we could swap the markdown and highlight processing
> order, but then that presents a different issue - the markdown table
> contains metadata with quoted items (such as cols="5"), which the
> highligh processing then expands into tags, and hence breaks the table
> format metadata.
> 
> As an example, using the following table !Pinclude'd into drm.tmpl:
> /**
>  * DOC: DRM generic
>  *
>  * : DRM generic properties
>  *
>  * +--+++-+
> +
>  * |Property  |Type|Property Values |Object  
>  |Description/Restrictions|
>  *
> +==+++=+===
> =+
>  * |"rotation"|BITMASK |{ 0, "rotate-0" }, {|CRTC,|rotate-(degrees)
> rotates|
>  * +--+++-+
> +
>  *
>  */
> 
> The post-highlight pre-markdown text captured as the $orig_context in
> the markdown_to_docbook function is:
> 
> +--+++-+---
> -+
> |Property  |Type|Property Values |Object  
>  |Description/Restrictions|
> +==+++=+===
> =+
> |rotation|BITMASK |{ 0, rotate-0 },
> {|CRTC,|rotate-(degrees) rotates|
> +--+++-+---
> -+
> 
> which when processed (and you can do this by hand with 'pandoc -
> -columns=80 -f markdown -t docbook ...' generates the broken tags
> example:
> 
> ...
> 
>  
>
>  
>rota
>  
>
>
>  
>tion/quo
>  
>
>
>  
>te|BITMASK |{ 0, qu
>  
>
>
>  
>oterotate
>  
>
>
>  
>-0 }, {|CRTC, |rotate-(degrees) rotates
>  
> ...
> 
> where you can see the quote tag processing has gone horribly wrong.
> 
> I believe we'll have the same problem for the other 'highlight'
> processed items from kern-doc as well, meaning:
>  funcname()
>  $ENVVAR
>  _name
>  @parameter
>  %CONST
>  
> As the kern-doc processing has no knowledge of when it is about to
> process a markdown table I can't think of an obvious way around this.
> At present I think the implicit rule is 'no highlight/expansion items
> allowed in markdown tables', which means all those quoted strings for
> the DRM properties cannot currently be migrated to look like strings.
> 
> Danilo, or anybody, any ideas?

Your debugging is pretty precise. The "+=+===" format is rigid. I
don't know if it's a bug in pandoc or something from the spec itself.

May I suggest another format?

| Property   |  Type   |
||:---:|
| "rotation" | BITMASK |

This format looks to work pretty well even if "rotation" is replaced by
some very long string (which seems to be the problem). I didn't test it
with kernel-doc, but pandoc looks to work fine with it.

I'm not sure if we can call it a proper fix, but it should allow you to
keep the ball rolling.

--
Danilo Cesar

[PATCH v5 15/17] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Yakir Yang]

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../devicetree/bindings/drm/bridge/analogix_dp.txt |  4 ++-
 .../bindings/video/analogix_dp-rockchip.txt|  1 +
 .../devicetree/bindings/video/exynos_dp.txt|  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 36 +++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
 6 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
index f54dc3e..c310367 100644
--- a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".

 Optional properties for dp-controller:
+   -analogix,need-force-hpd:
+   Indicate driver need force hpd when hpd detect failed, this
+   is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/video/exynos_dp.txt
* 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt

-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 ---

diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
index ec93917..be18388 100644
--- a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -31,6 +31,7 @@ For the below properties, please refer to Analogix DP binding 
document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- analogix,need-force-hpd (optional)
 ---

 Example:
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index ea03b3a..4f06e80 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding 
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+   -analogix,need-force-hpd (optional)
-video interfaces (optional)

 Deprecated properties for DisplayPort:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3efae33..7e83738 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 {
int timeout_loop = 0;

-   while (analogix_dp_get_plug_in_status(dp) != 0) {
+   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+   if (analogix_dp_get_plug_in_status(dp) == 0)
+   return 0;
+
timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "failed to get hpd plug status\n");
-   return -ETIMEDOUT;
-   }
usleep_range(10, 11);
}

+   /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+   if (!dp->need_force_hpd)
+   return -ETIMEDOUT;
+
+   /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+   dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+   analogix_dp_force_hpd(dp);
+
+   if (analogix_dp_get_plug_in_status(dp) != 0) {
+   dev_err(dp->dev, "failed to get hpd plug in status\n");
+   return -EINVAL;
+   }
+
+   dev_dbg(dp->dev, "success to get plug in status after force hpd\n");
+
return 0;
 }

@@ -1243,6 +1266,9 @@ int analogix_dp_bind(struct device 

[PATCH v5 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Yakir Yang]

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 24 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6be139b..3efae33 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1153,18 +1153,27 @@ static int analogix_dp_create_bridge(struct drm_device 
*drm_dev,
 static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
 {
struct device_node *dp_node = dp->dev->of_node;
-   struct video_info *video_info = >video_info
+   struct video_info *video_info = >video_info;

-   if (of_property_read_u32(dp_node, "samsung,link-rate",
-_info->link_rate)) {
-   dev_err(dev, "failed to get link-rate\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32(dp_node, "samsung,lane-count",
-_info->lane_count)) {
-   dev_err(dev, "failed to get lane-count\n");
-   return -EINVAL;
+   switch (dp->plat_data && dp->plat_data->dev_type) {
+   case RK3288_DP:
+   /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+   video_info->max_link_rate = 0x0A;
+   video_info->max_lane_count = 0x04;
+   break;
+   case EXYNOS_DP:
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,link-rate",
+_info->max_link_rate);
+   of_property_read_u32(dp_node, "samsung,lane-count",
+_info->max_lane_count);
+   break;
}

return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 730486d..f4cb799 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;

-   enum link_rate_type link_rate;
-   enum link_lane_count_type lane_count;
+   enum link_rate_type max_link_rate;
+   enum link_lane_count_type max_lane_count;
 };

 struct link_train {
-- 
1.9.1

WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90()

[Alex Deucher]

On Mon, Sep 21, 2015 at 9:31 AM, Borislav Petkov  wrote:
> Hi guys,
>
> this assert_drm_connector_list_read_locked() thing fires here when
> suspending to disk with Linus' master from around a week ago and
> tip/master merged ontop.
>
> After I resume, box comes up but wedges solid. I've managed to capture
> that splat in its whole glory too, see the end of this mail.
>
> Let me know if you need more info.
>
> Thanks.
>

What system is this?  What GPU are you using?  Can you bisect?

Alex

[PATCH v5 13/17] drm: bridge: analogix/dp: add some rk3288 special registers setting

[Yakir Yang]

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include 
 #include 

+#include 
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"

@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);

+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+   writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+   writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+   writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+   }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);

@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
   bool enable)
 {
u32 reg;
+   u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   phy_pd_addr = ANALOGIX_DP_PD;

switch (block) {
case AUX_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH3_BLOCK:
if (enable) {
-  

[PATCH v5 12/17] drm: rockchip: vop: add bpc and color mode setting

[Yakir Yang]

From: Mark Yao 

Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.

Signed-off-by: Mark Yao 
Signed-off-by: Yakir Yang 
---
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
+   struct drm_connector *cn = >connector;
+   int ret = -1;
u32 val;
-   int ret;

-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+   DRM_MODE_CONNECTOR_eDP,
+   10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
 {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
 }

 static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs = 
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev, 
int pipe);
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {

 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
  int connector_type,
- int out_mode)
+ int bpc, int color)
 {
struct vop *vop = to_vop(crtc);

+   /*
+* RK3288 vop only support RGB Color output.
+*/
+   if (color != 

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

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

--- Comment #14 from Ilia Mirkin  ---
(In reply to Kai from comment #13)
> So I'm not sure if the game actually *needs* the extension?

It does. Without the ext, the shader in question is invalid.

Mesa has partial support for the ext which gets enabled (along with every other
available ext) by the force_glsl_bla thing, and that partial support is
apparently sufficient for the needs of this 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/20150922/bcde4ba7/attachment.html>

[PATCH v5 11/17] Documentation: phy: add document for rockchip dp phy

[Yakir Yang]

This phy driver is binded with the Rockchip DisplayPort
driver, here are the brief properties:
edp_phy: edp-phy at ff770274 {
compatible = "rockchip,rk3288-dp-phy";
rockchip,grf = <>;
clocks = < SCLK_EDP_24M>;
clock-names = "24m";
#phy-cells = <0>;
};

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..505194e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy at ff770274 {
+   compatible = "rockchip,rk3288-dp-phy";
+   rockchip,grf = <>;
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+};
-- 
1.9.1

[PATCH v5 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

This phy driver would control the Rockchip DisplayPort module
phy clock and phy power, it is relate to analogix_dp-rockchip
dp driver. If you want DP works rightly on rockchip platform,
then you should select both of them.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 47da573..8f2bc4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -310,6 +310,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.

+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a5b18c1..e281f35 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -34,6 +34,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3a2ac120
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+#define GRF_EDP_REF_CLK_SEL_INTER  BIT(4)
+#define GRF_EDP_PHY_SIDDQ_WRITE_EN  BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = clk_prepare_enable(dp->phy_24m);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable clock 24m %d\n", ret);
+   return ret;
+   }
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_WRITE_EN |
+  GRF_EDP_PHY_SIDDQ_ON);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_WRITE_EN |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, false);
+}
+
+static const struct phy_ops rockchip_dp_phy_ops = {
+   .power_on   = rockchip_dp_phy_power_on,
+   .power_off  = rockchip_dp_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
+static int rockchip_dp_phy_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+   struct phy_provider *phy_provider;
+   struct rockchip_dp_phy *dp;
+  

[PATCH v5 09/17] Documentation: drm/bridge: add document for analogix_dp

[Yakir Yang]

Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../bindings/video/analogix_dp-rockchip.txt| 90 ++
 1 file changed, 90 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt

diff --git a/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
new file mode 100644
index 000..ec93917
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
@@ -0,0 +1,90 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp at ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "dp";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in: port at 0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+
+   edp_out: port at 1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>
+   };
+   };
+   };
+   };
+
+   pinctrl {
+   edp {
+   edp_hpd: edp-hpd {
+   rockchip,pins = <7 11 RK_FUNC_2 
_pull_none>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH v5 08/17] drm: rockchip: dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+tristate "Rockchip specific extensions for Analogix DP driver"
+depends on DRM_ROCKCHIP
+select DRM_ANALOGIX_DP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan 
+ * Yakir Yang 
+ * Jeff Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+   struct drm_device*drm_dev;
+   struct device*dev;
+   struct drm_encoder   encoder;
+   struct drm_connector connector;
+   struct drm_display_mode  mode;
+
+   struct clk   *pclk;
+   struct regmap*grf;
+   struct reset_control *rst;
+
+   struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+   reset_control_assert(dp->rst);
+   usleep_range(10, 20);
+   reset_control_deassert(dp->rst);
+
+   return 0;
+}
+
+static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
+{
+   struct rockchip_dp_device *dp = to_dp(plat_data);
+   int ret;
+
+   ret = 

[PATCH v5 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts   | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 2 --
 arch/arm/boot/dts/exynos5250-snow.dts  | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts| 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 4 +---
 7 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index db3f65f..4636862 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
  {
status = "okay";
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index c625e71..cd424d6 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@

  {
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 0720caa..242b621 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -244,12 +244,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
-   samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
 };

  {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..7433683 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 0>;
+   hpd-gpio = < 6 0>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 98871f9..b3df3c1 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -92,8 +92,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..b89bff5 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -142,12 +142,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

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

--- Comment #13 from Kai  ---
(In reply to Ilia Mirkin from comment #12)
> (In reply to Kai from comment #11)
> > (In reply to Ilia Mirkin from comment #10)
> > > (In reply to Timothy Arceri from comment #9)
> > > > (In reply to Ilia Mirkin from comment #7)
> > > > > (In reply to Kai from comment #5)
> > > > > > Also, the game seems to choke on the missing AoA functionality or 
> > > > > > at least
> > > > > > doesn't check whether it can use AoA:
> > > > > > > 0:9(23): error: GL_ARB_arrays_of_arrays required for defining 
> > > > > > > arrays of arrays
> > > > > 
> > > > > I guess line 9 is: out vec4 vControlPoint[][2];
> > > > > 
> > > > > Which should work without AoA. I wonder if this was recently broken 
> > > > > by the
> > > > > AoA support patches... Or maybe it started out broken.
> > > > 
> > > > It seems to me that this should fail, and is correctly doing so. From 
> > > > the
> > > > tessellation spec:
> > > >
> > > > [...]
> > > > 
> > > > Is there something I'm missing?
> > > 
> > > Quite right. I forgot about that little bit in the spec. So the issue here
> > > is that (a) AoA isn't supported in mesa, (b) even if it was, the shader
> > > doesn't enable it. Without that, you can't have plain per-vertex array
> > > outputs in TCS.
> > 
> > So, I should probably report this bug to Ferral Interactive (studio
> > responsible for the Linux port), right?
> 
> That would be ideal.

Done (by e-mail). Lets see, if I hear back from them or if they fix it.

> > > You could force-enable it by setting force_glsl_extensions_warn=1 and
> > > MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays ... I think.
> > 
> > The correct override is:
> > # force_glsl_extensions_warn=true
> > MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays
> > Setting force_glsl_extension_warn=1 leads to an error. And indeed, setting
> > those two environment variables leads to visible characters in the game, see
> > the attached screenshot.
> > 
> > Should this bug be renamed to »[radeonsi] Implement GL_ARB_arrays_of_arrays
> > for "Middle-earth: Shadow of Mordor"« then?
> 
> As I mentioned, merely having the ext available wouldn't make that shader
> compile. The ext would also have to be enabled in the shader.

Yes, I understand. But this would still leave radeonsi without required
functionality. So making this bug about enabling GL_ARB_arrays_of_arrays for an
application that (pretends*) to need it, seemed reasonable and more
descriptive.

* I've played about 30 minutes now with those environment variables set and
haven't noticed any visual corruption on radeonsi which doesn't expose
GL_ARB_arrays_of_arrays. So I'm not sure if the game actually *needs* the
extension?

-- 
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/20150922/85cac19e/attachment.html>

[PATCH v5 06/17] Documentation: drm/bridge: add document for analogix_dp

[Yakir Yang]

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"

Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../devicetree/bindings/drm/bridge/analogix_dp.txt | 50 +
 .../devicetree/bindings/video/exynos_dp.txt| 63 --
 2 files changed, 71 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
new file mode 100644
index 000..f54dc3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be "dp".
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+   -hpd-gpios:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug detection
+   -port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+   * Documentation/devicetree/bindings/video/exynos_dp.txt
+   * 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+   dp-controller {
+   compatible = "samsung,exynos5-dp";
+   reg = <0x145b 0x1>;
+   interrupts = <10 3>;
+   interrupt-parent = <>;
+   clocks = < 342>;
+   clock-names = "dp";
+
+   phys = <_phy>;
+   phy-names = "dp";
+   };
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 7a3a9cd..ea03b3a 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung,link-rate:
-   link rate supported by the panel.
-   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
-   -samsung,lane-count:
-   number of lanes supported by the panel.
-   LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+
+Optional properties for dp-controller:
- display-timings: timings for the connected panel 

[PATCH v5 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 144 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   8 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 104 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1e3c8d3..6be139b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector->display_info;
+   struct video_info *video = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the original
+* values and wouldn't be modified.
+*/
+   of_property_read_u32(dp_node, "samsung,color-space",
+>color_space);
+   of_property_read_u32(dp_node, "samsung,dynamic-range",
+>dynamic_range);
+   of_property_read_u32(dp_node, "samsung,ycbcr-coeff",
+

[PATCH 11/11] drm: Fix vblank timestamp races

[Ville Syrjälä]

On Tue, Sep 22, 2015 at 11:10:50AM +0200, Daniel Vetter wrote:
> On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrjälä 
> > 
> > The vblank timestamp ringbuffer only has two entries, so if the
> > vblank->count is incremented by an even number readers may end up seeing
> > the new vblank timestamp alongside the old vblank counter value.
> > 
> > Fix the problem by storing the vblank counter in a ringbuffer as well,
> > and always increment the ringbuffer "slot" by one when storing a new
> > timestamp+counter pair.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Imo if we bother with this we might as well just switch over to using
> full-blown seqlocks. They internally use a two-stage update which means
> race-free even with just one copy of the data we protect. Also more
> standardized to boot.

Any volunteers for that? I don't have time to start redoing this right
now.

> 
> Series looks good otherwise, I'll wait for Maarten to r-b it and then pull
> it in.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/drm_irq.c | 40 
> >  include/drm/drmP.h| 12 ++--
> >  2 files changed, 30 insertions(+), 22 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 88fbee4..8de236a 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -43,8 +43,10 @@
> >  #include 
> >  
> >  /* Access macro for slots in vblank timestamp ringbuffer. */
> > -#define vblanktimestamp(dev, pipe, count) \
> > -   ((dev)->vblank[pipe].time[(count) % DRM_VBLANKTIME_RBSIZE])
> > +#define vblanktimestamp(dev, pipe, slot) \
> > +   ((dev)->vblank[pipe].time[(slot) % DRM_VBLANK_RBSIZE])
> > +#define vblankcount(dev, pipe, slot) \
> > +   ((dev)->vblank[pipe].count[(slot) % DRM_VBLANK_RBSIZE])
> >  
> >  /* Retry timestamp calculation up to 3 times to satisfy
> >   * drm_timestamp_precision before giving up.
> > @@ -76,20 +78,23 @@ module_param_named(timestamp_monotonic, 
> > drm_timestamp_monotonic, int, 0600);
> >  
> >  static void store_vblank(struct drm_device *dev, unsigned int pipe,
> >  u32 vblank_count_inc,
> > -struct timeval *t_vblank, u32 last)
> > +const struct timeval *t_vblank, u32 last)
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > -   u32 tslot;
> > +   u32 slot;
> >  
> > assert_spin_locked(>vblank_time_lock);
> >  
> > +   slot = vblank->slot + 1;
> > +
> > vblank->last = last;
> >  
> > /* All writers hold the spinlock, but readers are serialized by
> > -* the latching of vblank->count below.
> > +* the latching of vblank->slot below.
> >  */
> > -   tslot = vblank->count + vblank_count_inc;
> > -   vblanktimestamp(dev, pipe, tslot) = *t_vblank;
> > +   vblankcount(dev, pipe, slot) =
> > +   vblankcount(dev, pipe, vblank->slot) + vblank_count_inc;
> > +   vblanktimestamp(dev, pipe, slot) = *t_vblank;
> >  
> > /*
> >  * vblank timestamp updates are protected on the write side with
> > @@ -100,7 +105,7 @@ static void store_vblank(struct drm_device *dev, 
> > unsigned int pipe,
> >  * The read-side barriers for this are in drm_vblank_count_and_time.
> >  */
> > smp_wmb();
> > -   vblank->count += vblank_count_inc;
> > +   vblank->slot = slot;
> > smp_wmb();
> >  }
> >  
> > @@ -202,7 +207,7 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> > const struct timeval *t_old;
> > u64 diff_ns;
> >  
> > -   t_old = (dev, pipe, vblank->count);
> > +   t_old = (dev, pipe, vblank->slot);
> > diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
> >  
> > /*
> > @@ -223,7 +228,8 @@ static void drm_update_vblank_count(struct drm_device 
> > *dev, unsigned int pipe,
> >  
> > DRM_DEBUG("updating vblank count on crtc %u:"
> >   " current=%u, diff=%u, hw=%u hw_last=%u\n",
> > - pipe, vblank->count, diff, cur_vblank, vblank->last);
> > + pipe, vblankcount(dev, pipe, vblank->slot),
> > + diff, cur_vblank, vblank->last);
> >  
> > if (diff == 0) {
> > WARN_ON_ONCE(cur_vblank != vblank->last);
> > @@ -883,7 +889,7 @@ u32 drm_vblank_count(struct drm_device *dev, int pipe)
> > if (WARN_ON(pipe >= dev->num_crtcs))
> > return 0;
> >  
> > -   return vblank->count;
> > +   return vblankcount(dev, pipe, vblank->slot);
> >  }
> >  EXPORT_SYMBOL(drm_vblank_count);
> >  
> > @@ -923,7 +929,8 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
> > unsigned int pipe,
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[pipe];
> > int count = DRM_TIMESTAMP_MAXRETRIES;
> > -   u32 cur_vblank;
> > +   u32 vblankcount;
> > +   u32 slot;
> >  
> > if (WARN_ON(pipe >= dev->num_crtcs))
> > return 0;
> > @@ -934,13 +941,14 @@ u32 

[PATCH v5 04/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fa9eb19..1e3c8d3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);

if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);

-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 14d20be..9a90a18 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP 5

 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };

 enum link_lane_count_type {
-- 
1.9.1

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Ville Syrjälä]

On Tue, Sep 22, 2015 at 02:17:51PM +0200, Daniel Vetter wrote:
> On Tue, Sep 22, 2015 at 03:00:54PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > dev node per DP AUX channel, named drm_aux-N.
> > > 
> > > It's possible to know which connector owns this aux channel by looking
> > > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > > the connector device pointer was correctly set in the aux helper struct.
> > > 
> > > Two main operations are provided on the registers: read and write. The
> > > address of the register to be read or written is given using lseek.
> > > Reading or writing does not update the offset of the file.
> > > 
> > > Signed-off-by: Rafael Antognolli 
> > > ---
> > >  drivers/gpu/drm/Kconfig   |   4 +
> > >  drivers/gpu/drm/Makefile  |   1 +
> > >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > > ++
> > >  3 files changed, 331 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > > 
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 1a0a8df..eae847c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > >   bool
> > >   depends on DRM
> > >  
> > > +config DRM_AUX_CHARDEV
> > > + tristate "DRM DP AUX Interface"
> > > + depends on DRM
> > > +
> > >  config DRM_KMS_HELPER
> > >   tristate
> > >   depends on DRM
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 45e7719..a1a94306 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> > >  
> > >  obj-$(CONFIG_DRM)+= drm.o
> > >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> > >  obj-$(CONFIG_DRM_TTM)+= ttm/
> > >  obj-$(CONFIG_DRM_TDFX)   += tdfx/
> > >  obj-$(CONFIG_DRM_R128)   += r128/
> > > diff --git a/drivers/gpu/drm/drm_aux-dev.c b/drivers/gpu/drm/drm_aux-dev.c
> > > new file mode 100644
> > > index 000..fcc334a
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > > @@ -0,0 +1,326 @@
> > > +/*
> > > + * Copyright © 2015 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a
> > > + * copy of this software and associated documentation files (the 
> > > "Software"),
> > > + * to deal in the Software without restriction, including without 
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the 
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of 
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + *
> > > + * Authors:
> > > + *Rafael Antognolli 
> > > + *
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +struct drm_aux_dev {
> > > + struct list_head list;
> > > + unsigned index;
> > > + struct drm_dp_aux *aux;
> > > + struct device *dev;
> > > +};
> > > +
> > > +#define DRM_AUX_MINORS   256
> > > +static int drm_aux_dev_count = 0;
> > > +static LIST_HEAD(drm_aux_dev_list);
> > > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > > +
> > > +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> > > +{
> > > + struct drm_aux_dev *aux_dev;
> > > +
> > > + spin_lock(_aux_dev_list_lock);
> > > + list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > > + if (aux_dev->index == index)
> > > + goto found;
> > > + }
> > > +
> > > + aux_dev = NULL;
> > > +found:
> > > + spin_unlock(_aux_dev_list_lock);
> > > + return aux_dev;
> > > +}
> > > +
> > > +static struct drm_aux_dev *drm_aux_dev_get_by_aux(struct drm_dp_aux *aux)
> > > +{
> > > + struct drm_aux_dev *aux_dev;
> > > +
> > > + spin_lock(_aux_dev_list_lock);
> > > + list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > > + if 

[PATCH v5 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 3 files changed, 163 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8a7ba12..fa9eb19 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)

while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;

@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");

/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}

analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}

-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-   edid[EDID_CHECKSUM]);
+   DP_TEST_EDID_CHECKSUM, edid[EDID_CHECKSUM]);
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_RESPONSE,
-  

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Daniel Vetter]

On Tue, Sep 22, 2015 at 04:25:17PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2015 at 02:59:24PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2015 at 03:35:13PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 22, 2015 at 02:17:51PM +0200, Daniel Vetter wrote:
> > > > Iirc short reads are ok in all cases, so we could even punt the 
> > > > restarting
> > > > to userspace by just doing short reads/writes (like sockets do).
> > > 
> > > Yeah, short writes due to -EFAULT sound more dangerous than short reads.
> > > But I'm not sure there's any point in allowing short reads either in
> > > this case, so just returning the error upfront if access_ok() complains
> > > seems like a sane option to me.
> > 
> > access_ok _only_ does static checks (on x86 it only checks that it's a
> > userspace address). Which means any kind of real faults will only happen
> > later on in the actual copy_to/from_user. I'd say we can go meh if that
> > happens - it's guaranteed to be userspace doing something silly since we
> > don't need to hold any of the mm locks ;-)
> 
> Hmm, true. So I guess on -EFAULT we should:
> 
> if (copy_{to,from}_user())
>   return num_bytes_processed ? num_bytes_processed : -EFAULT;
> 
> Sound reasonable?

Yeah that's what I'd go with.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm/layerscape: fix a signedness bug

[Dan Carpenter]

"index" needs to be signed for the error handling to work.  Really "ret"
should be an int as well.

Fixes: 109eee2f2a18 ('drm/layerscape: Add Freescale DCU DRM driver')
Signed-off-by: Dan Carpenter 

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 82be6b8..d1e300d 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
@@ -58,7 +58,8 @@ static void fsl_dcu_drm_plane_atomic_disable(struct drm_plane 
*plane,
 struct drm_plane_state *old_state)
 {
struct fsl_dcu_drm_device *fsl_dev = plane->dev->dev_private;
-   unsigned int index, value, ret;
+   unsigned int value;
+   int index, ret;

index = fsl_dcu_drm_plane_index(plane);
if (index < 0)

[PATCH v5 02/17] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Yakir Yang]

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export four hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
---
Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)

Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
  add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)

Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell

 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix/Kconfig|4 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 .../analogix/analogix_dp_core.c}   |  768 +---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  277 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1263 
 .../analogix/analogix_dp_reg.h}|  258 ++--
 drivers/gpu/drm/exynos/Kconfig |3 +-
 drivers/gpu/drm/exynos/Makefile|2 +-
 drivers/gpu/drm/exynos/exynos_dp.c |  366 ++
 drivers/gpu/drm/exynos/exynos_dp_core.h|  282 -
 drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 
 include/drm/bridge/analogix_dp.h   |   41 +
 14 files changed, 2379 insertions(+), 2152 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
 rename drivers/gpu/drm/{exynos/exynos_dp_core.c => 
bridge/analogix/analogix_dp_core.c} (50%)
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
 rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => 
bridge/analogix/analogix_dp_reg.h} (64%)
 create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 create mode 100644 include/drm/bridge/analogix_dp.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..7b5b77a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..5366c6b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..5ff6551
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,4 @@
+config DRM_ANALOGIX_DP
+   tristate
+   depends on DRM
+   select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
new file mode 100644
index 000..9107b86
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp_core.o analogix_dp_reg.o

[Intel-gfx] [PATCH 00/23] Color Management for DRM

[Daniel Vetter]

On Wed, Sep 16, 2015 at 11:06:57PM +0530, Shashank Sharma wrote:
> This patch set adds Color Manager implementation in DRM layer. Color Manager
> is an extension in DRM framework to support color correction/enhancement.
> 
> Various Hardware platforms can support several color correction capabilities.
> Color Manager provides abstraction of these capabilities and allows a user
> space UI agent to correct/enhance the display using the DRM property 
> interface.
> 
> How is this going to work?
> ==
> 1. This patch series adds a few new properties in DRM framework. These 
> properties are:
> a. color_capabilities property (type blob)
> b. Color Transformation Matrix property for corrections like CSC 
> (called CTM, type blob)
> c. Palette correction properties for corrections like gamma fixup 
> (called palette_correction, type blob) 
> 2. Also, this patch series adds few structures to indicate specifications of 
> a property like size, no_of_samples for correction etc.
> 3. These properties are present in mode_config.
> 4. When the platform's display driver loads, it fills up the values of 
> color_capabilities property using the standard structures (added in step 2).
>For example, Intel's I915 driver adds following color correction 
> capabilities:
> a. gamma correction capability as palette correction property, with 
> 257 correction coefficients and a max/min value
> b. csc correction capability as CTM correction property, with 3x3 
> transformation matrix values and max/min values 
> 5. Now when userspace comes up, it queries the platform's color capabilities 
> by doing a get_property() on color_capabilities DRM property
> 6. Reading the blob, the userspace understands the color capabilities of the 
> platform.
>For example, userspace will understand it can support:
> a. palette_correction with 257 coefficients
> b. CSC correction with 3x3 = 9 values 
> 7. To set color correction values, userspace:
> a. creates a blob using the create_blob_ioctl in standard 
> palette_correction structure format, with the correction values
> b. calls the set_property_ioctl with the blob_id as value for the 
> property 
> 8. Driver refers to the blob, gets the correction values and applies the 
> correction in HW.
> 9. To get currently applied color correction values, userspace:
> a. calls a get_property_ioctl on that color property
> b. gets the blob_id for the currently applied correction from DRM 
> infrastructure
> c. gets the blob using get_blob_ioctl and hence the currently applied 
> values
> 
> That's all! :)
> 
> About the patch series:
> ===
> The patch series first adds the color management support in DRM layer.
> Then it adds the color management framework in I915 layer. 
> After that, it implements platform specific core color correction functios. 
> 
> Intel color manager registers color correction with DRM color manager in this 
> way:
>  - CSC transformation is registered as CTM DRM property
>  - Gamma correction is registered as palette_after_ctm DRM property
>  - Degamma correction is registered as palette_before_ctm DRM property
> 
> Our thanks to all the reviewers who have given valuable comments in terms
> of design and implementation to our previous sets of patches. Special mention
> of thanks should go to Matt Roper for all his inputs/suggestions in 
> implementation
> of this module, using DRM atomic CRTC commit path.
> 
> V2: Worked on review comments from Matt, Jim, Thierry, Rob.
> V3: Worked on review comments from Matt, Jim, Rob:
>  - Jim, Rob:
>
>Re-arranged the whole patch series in the sequence of features, currently:
>First 5 patches add color management support in DRM layer
>Next 7 patches add Intel color management framework in I915 driver
>Next 5 patches add color correction for CHV (gamma, degamma and CSC)
>Next 2 patches enable color management, by attaching the properties to 
> CRTC(Matt)
>Next 4 patches add color correction for BDW (gamma, degamma)
>  - Matt:
>=
>Patch 3: Added refernce/unreference for blob
>Patch 7: return -EINVAL and added debug message
>Patch 8: check for valid blob, from create blob
> moved call to intel_crtc_attach_color_prop in the end of full 
> implementation (CHV)
>Patch 9: DRM_ERROR->DRM_DEBUG for NULL blob case
>Patch 13: Added static for internal functions
>Patch 20-24: renamed gen9_* functions to bdw_*
>Added new variables in device_info structure num_samples_after_ctm and 
> num_samples_before_ctm
>Added new function in patch 8 to load capabilities based on device_info 
> across all platforms

Ok I finally got around to look at the kernel/userspace and drm core parts
in detail. There's a few minor bits to polish but nothing serious I think,
looks good overall (but I didn't really look at the i915 side).

One thing 

[PATCH v5 01/17] drm: exynos: dp: convert to drm bridge mode

[Yakir Yang]

In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.

Signed-off-by: Yakir Yang 
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Keep author name list no changed (Jingoo)

 drivers/gpu/drm/exynos/exynos_dp_core.c | 104 +++-
 drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
 2 files changed, 78 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..e0818c1 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
 {
int ret;

-   encoder->bridge = dp->bridge;
-   dp->bridge->encoder = encoder;
-   ret = drm_bridge_attach(encoder->dev, dp->bridge);
+   encoder->bridge->next = dp->ptn_bridge;
+   dp->ptn_bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }

-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
+   struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;

/* Pre-empt DP connector creation if there's a bridge */
-   if (dp->bridge) {
+   if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder 
*encoder)
return ret;
 }

-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
 }

-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);

if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,68 @@ static void exynos_dp_disable(struct drm_encoder 
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+   .enable = exynos_dp_bridge_enable,
+   .disable = exynos_dp_bridge_disable,
+   .pre_enable = exynos_dp_bridge_nop,
+   .post_disable = exynos_dp_bridge_nop,
+   .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_device *drm_dev = dp->drm_dev;
+   struct drm_bridge *bridge;
+   int ret;
+
+   bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+   if (!bridge) {
+   DRM_ERROR("failed to allocate for drm bridge\n");
+   return -ENOMEM;
+   }
+
+   dp->bridge = bridge;
+
+   bridge->driver_private = dp;
+   bridge->encoder = encoder;
+   bridge->funcs = _dp_bridge_funcs;
+
+   ret = drm_bridge_attach(drm_dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach drm bridge\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
+const struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void exynos_dp_mode_set(struct drm_encoder *encoder,

[Intel-gfx] [PATCH 09/23] drm/i915: Register pipe color capabilities

[Daniel Vetter]

On Wed, Sep 16, 2015 at 11:07:06PM +0530, Shashank Sharma wrote:
> DRM color manager contains these color properties:
> 
> 1. "crtc_palette_capabilities_property": to allow a
> core driver to load and showcase its color correction
> capabilities to user space.
> 2. "ctm": Color transformation matrix property, where a
> color transformation matrix of 9 correction values gets
> applied as correction.
> 3. "palette_before_ctm": for corrections which get applied
> beore color transformation matrix correction.
> 4. "palette_after_ctm": for corrections which get applied
> after color transformation matrix correction.
> 
> Intel color manager registers:
> 1. Gamma correction property as "palette_after_ctm" property
> 2. Degamma correction capability as "palette_bafore_ctm" property
> capability as "palette_after_ctm" DRM color property hook.
> 3. CSC as "ctm" property.
> 
> This patch does the following:
> 1. Add a function which loads the platform's color correction
> capabilities in the cm_crtc_palette_capabilities_property structure.
> 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
> getting initiaized.
> 3. Adds two new parameters "num_samples_after_ctm" and
> "num_samples_before_ctm" in intel_device_info as gamma and
> degamma coefficients vary per platform basis.
> 
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/intel_color_manager.c | 45 
> ++
>  drivers/gpu/drm/i915/intel_color_manager.h |  2 ++
>  3 files changed, 49 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3bf8a9b..22de2cb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -798,6 +798,8 @@ struct intel_device_info {
>   u8 num_sprites[I915_MAX_PIPES];
>   u8 gen;
>   u8 ring_mask; /* Rings supported by the HW */
> + u16 num_samples_after_ctm;
> + u16 num_samples_before_ctm;
>   DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
>   /* Register offsets for the various display pipes and transcoders */
>   int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 7357d99..77f58f2 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,7 +27,52 @@
>  
>  #include "intel_color_manager.h"
>  
> +int get_pipe_capabilities(struct drm_device *dev,
> + struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
> +{
> + struct drm_property_blob *blob;
> +
> + /*
> +  * This function loads best capability for gamma correction
> +  * For example:
> +  * CHV best Gamma correction (CGM unit, 10 bit)
> +  * has 257 entries, best degamma is 65 entries
> +  */
> + palette_caps->version = COLOR_STRUCT_VERSION;
> + palette_caps->num_samples_after_ctm =
> + INTEL_INFO(dev)->num_samples_after_ctm;
> + palette_caps->num_samples_before_ctm =
> + INTEL_INFO(dev)->num_samples_before_ctm;
> + blob = drm_property_create_blob(dev, sizeof(struct drm_palette_caps),
> + (const void *) palette_caps);
> + if (IS_ERR_OR_NULL(blob)) {
> + DRM_ERROR("Create blob for capabilities failed\n");
> + return PTR_ERR(blob);
> + }
> +
> + return blob->base.id;
> +}
> +
>  void intel_attach_color_properties_to_crtc(struct drm_device *dev,
>   struct drm_mode_object *mode_obj)
>  {
> + struct drm_mode_config *config = >mode_config;
> + struct drm_palette_caps *palette_caps;
> + struct drm_crtc *crtc;
> + int capabilities_blob_id;
> +
> + crtc = obj_to_crtc(mode_obj);
> + palette_caps = kzalloc(sizeof(struct drm_palette_caps),
> + GFP_KERNEL);
> + capabilities_blob_id = get_pipe_capabilities(dev,
> + palette_caps, crtc);
> +
> + if (config->cm_crtc_palette_capabilities_property) {
> + drm_object_attach_property(mode_obj,
> + config->cm_crtc_palette_capabilities_property,
> + capabilities_blob_id);

I didn't find any code to attach the before/after_ctm gamma properties and
the ctm property. Also I think a small helper would be really nice here in
the drm core:

drm_crtc_attach_cc_properties(struct drm_crtc *crtc,
  int gamma_before_ctm,
  bool ctm,
  int gamm_after_ctm)

And then that directly constructs the palette caps from the given values
(if they're non-0) and also attaches the properties to the crtc (if
they're non-0 for gamma, treu for the ctm).

If that attach_property code really isn't there I wonder a bit how this
all works, we /should/ be filtering out properties which 

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

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM :)

This time I create this version on linux-next branch (tag is next-20150918),
and also applied this version to Heiko github eDP branch to verify the function.
(https://github.com/mmind/linux-rockchip/tree/tmp/edp-with-veyron)
Glad to say my chromebook "cnm,n116bgeea2" eDP panel just lighted rightly on
Heiko branch. And after back port this series to chromeos-3.14 tree, my rk3288
SDK board still can light my 2K DisplayPort monitor. So this time would be okay
on mainline kernel and chromeos-3.14 tree. ;)

Due to no Exynos board in my side, so I haven't verified the eDP function on
samsung platform, I only ensure that there are no obvious compiled error. Any
help would be greatly appreciated. :)

Thanks,
- Yakir

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04
- Provide backword compatibility with samsung. (Krzysztof)
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"
- Separate all DTS changes to a separate patch. (Krzysztof)
- Remove some deprecated DT properties in rockchip dp document.
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)
- Seprate the link-rate and lane-count limit 

[Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

[Daniel Vetter]

On Tue, Sep 22, 2015 at 03:15:11PM +0200, Daniel Vetter wrote:
> On Wed, Sep 16, 2015 at 11:07:07PM +0530, Shashank Sharma wrote:
> > I915 driver registers gamma correction as palette correction
> > property with DRM layer. This patch adds set_property() and get_property()
> > handlers for pipe level gamma correction.
> > 
> > The set function attaches the Gamma correction blob to CRTC state, these
> > values will be committed during atomic commit.
> > 
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Kausal Malladi 
> > ---
> >  drivers/gpu/drm/i915/intel_atomic.c| 20 
> >  drivers/gpu/drm/i915/intel_color_manager.c | 21 +
> >  drivers/gpu/drm/i915/intel_drv.h   |  5 +
> >  3 files changed, 46 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> > b/drivers/gpu/drm/i915/intel_atomic.c
> > index 500d2998..0b61fef 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -315,6 +315,13 @@ int intel_crtc_atomic_set_property(struct drm_crtc 
> > *crtc,
> >struct drm_property *property,
> >uint64_t val)
> >  {
> > +   struct drm_device *dev = crtc->dev;
> > +   struct drm_mode_config *config = >mode_config;
> > +
> > +   if (property == config->cm_palette_after_ctm_property)
> > +   return intel_color_manager_set_pipe_gamma(dev, state,
> > +   >base, val);
> > +
> > DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
> > return -EINVAL;
> >  }
> > @@ -324,6 +331,19 @@ int intel_crtc_atomic_get_property(struct drm_crtc 
> > *crtc,
> >struct drm_property *property,
> >uint64_t *val)
> >  {
> > +   struct drm_device *dev = crtc->dev;
> > +   struct drm_mode_config *config = >mode_config;
> > +
> > +   if (property == config->cm_palette_after_ctm_property) {
> > +   *val = (state->palette_after_ctm_blob) ?
> > +   state->palette_after_ctm_blob->base.id : 0;
> > +   goto found;
> > +   }
> 
> Since color manager properties are meant as a new standardize KMS
> extension (we put them into the core drm_crtc_state) the get/set support
> should also be in the core. See e.g. how the rotation property is handled
> in drm_atomic_plane_get/set_property. So all this code should be added to
> drm_atomic_crtc_get/set_property.

I've forgotten to explain how drivers can then opt-in KMS extensions if we
have the decode support unconditionally there and also register the props
unconditionally: That's done by only attaching these standardized props to
a crtc/plane if the corresponding object supports it.
-Daniel

> 
> 
> > +
> > DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
> > return -EINVAL;
> > +
> > +found:
> > +   DRM_DEBUG_KMS("Found property %s\n", property->name);
> > +   return 0;
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> > b/drivers/gpu/drm/i915/intel_color_manager.c
> > index 77f58f2..9421bb6 100644
> > --- a/drivers/gpu/drm/i915/intel_color_manager.c
> > +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> > @@ -27,6 +27,27 @@
> >  
> >  #include "intel_color_manager.h"
> >  
> > +int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
> > +   struct drm_crtc_state *crtc_state,
> > +   struct drm_mode_object *obj, uint32_t blob_id)
> > +{
> > +   struct drm_property_blob *blob;
> > +
> > +   blob = drm_property_lookup_blob(dev, blob_id);
> > +   if (!blob) {
> > +   DRM_DEBUG_KMS("Invalid Blob ID\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (crtc_state->palette_after_ctm_blob)
> > +   drm_property_unreference_blob(
> > +   crtc_state->palette_after_ctm_blob);
> > +
> > +   /* Attach the blob to be committed in state */
> > +   crtc_state->palette_after_ctm_blob = blob;
> > +   return 0;
> > +}
> 
> What is this used for? It looks a bit like legacy property code, and we
> have a generic helper to make that happen
> (drm_atomic_helper_crtc_set_property).
> 
> Generally please don't add functions/structs without also adding a user,
> it means that reviewers have to constantly jump around in your patch
> series to figure out how something is used. Instead if you want to split
> things up really fine add a stub function frist (but including relevant
> callers) and then fill out the bits separately.
> -Daniel
> 
> > +
> >  int get_pipe_capabilities(struct drm_device *dev,
> > struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
> >  {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e27e754..d0193e2 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1466,4 +1466,9 @@ void intel_plane_destroy_state(struct drm_plane 
> > *plane,
> >

[Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

[Daniel Vetter]

On Wed, Sep 16, 2015 at 11:07:07PM +0530, Shashank Sharma wrote:
> I915 driver registers gamma correction as palette correction
> property with DRM layer. This patch adds set_property() and get_property()
> handlers for pipe level gamma correction.
> 
> The set function attaches the Gamma correction blob to CRTC state, these
> values will be committed during atomic commit.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c| 20 
>  drivers/gpu/drm/i915/intel_color_manager.c | 21 +
>  drivers/gpu/drm/i915/intel_drv.h   |  5 +
>  3 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 500d2998..0b61fef 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -315,6 +315,13 @@ int intel_crtc_atomic_set_property(struct drm_crtc *crtc,
>  struct drm_property *property,
>  uint64_t val)
>  {
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (property == config->cm_palette_after_ctm_property)
> + return intel_color_manager_set_pipe_gamma(dev, state,
> + >base, val);
> +
>   DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
>   return -EINVAL;
>  }
> @@ -324,6 +331,19 @@ int intel_crtc_atomic_get_property(struct drm_crtc *crtc,
>  struct drm_property *property,
>  uint64_t *val)
>  {
> + struct drm_device *dev = crtc->dev;
> + struct drm_mode_config *config = >mode_config;
> +
> + if (property == config->cm_palette_after_ctm_property) {
> + *val = (state->palette_after_ctm_blob) ?
> + state->palette_after_ctm_blob->base.id : 0;
> + goto found;
> + }

Since color manager properties are meant as a new standardize KMS
extension (we put them into the core drm_crtc_state) the get/set support
should also be in the core. See e.g. how the rotation property is handled
in drm_atomic_plane_get/set_property. So all this code should be added to
drm_atomic_crtc_get/set_property.


> +
>   DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
>   return -EINVAL;
> +
> +found:
> + DRM_DEBUG_KMS("Found property %s\n", property->name);
> + return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
> b/drivers/gpu/drm/i915/intel_color_manager.c
> index 77f58f2..9421bb6 100644
> --- a/drivers/gpu/drm/i915/intel_color_manager.c
> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> @@ -27,6 +27,27 @@
>  
>  #include "intel_color_manager.h"
>  
> +int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
> + struct drm_crtc_state *crtc_state,
> + struct drm_mode_object *obj, uint32_t blob_id)
> +{
> + struct drm_property_blob *blob;
> +
> + blob = drm_property_lookup_blob(dev, blob_id);
> + if (!blob) {
> + DRM_DEBUG_KMS("Invalid Blob ID\n");
> + return -EINVAL;
> + }
> +
> + if (crtc_state->palette_after_ctm_blob)
> + drm_property_unreference_blob(
> + crtc_state->palette_after_ctm_blob);
> +
> + /* Attach the blob to be committed in state */
> + crtc_state->palette_after_ctm_blob = blob;
> + return 0;
> +}

What is this used for? It looks a bit like legacy property code, and we
have a generic helper to make that happen
(drm_atomic_helper_crtc_set_property).

Generally please don't add functions/structs without also adding a user,
it means that reviewers have to constantly jump around in your patch
series to figure out how something is used. Instead if you want to split
things up really fine add a stub function frist (but including relevant
callers) and then fill out the bits separately.
-Daniel

> +
>  int get_pipe_capabilities(struct drm_device *dev,
>   struct drm_palette_caps *palette_caps, struct drm_crtc *crtc)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e27e754..d0193e2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1466,4 +1466,9 @@ void intel_plane_destroy_state(struct drm_plane *plane,
>  struct drm_plane_state *state);
>  extern const struct drm_plane_helper_funcs intel_plane_helper_funcs;
>  
> +/* intel_color_manager.c */
> +int intel_color_manager_set_pipe_gamma(struct drm_device *dev,
> + struct drm_crtc_state *crtc_state,
> + struct drm_mode_object *obj, uint32_t blob_id);
> +
>  #endif /* __INTEL_DRV_H__ */
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> 

[Intel-gfx] [PATCH 05/23] drm: Add structure to set/get a CTM color property

[Daniel Vetter]

On Wed, Sep 16, 2015 at 11:07:02PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi 
> 
> Color Manager framework defines a color correction property for color
> space transformation and Gamut mapping. This property is called CTM (Color
> Transformation Matrix).
> 
> This patch adds a new structure in DRM layer for CTM.
> This structure can be used by all user space agents to
> configure CTM coefficients for color correction.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  include/uapi/drm/drm.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index f72b916..9580772 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -867,6 +867,18 @@ struct drm_palette {
>   struct drm_r32g32b32 lut[0];
>  };
>  
> +struct drm_ctm {
> + /* Structure version. Should be 1 currently */
> + __u32 version;

Same thing here, no version needed for properties.

> + /*
> +  * Each value is in S31.32 format.
> +  * This is 3x3 matrix in row major format.
> +  * Integer part will be clipped to nearest
> +  * max/min boundary as supported by the HW platform.
> +  */
> + __s64 ctm_coeff[9];
> +};
> +
>  /* typedef area */
>  #ifndef __KERNEL__
>  typedef struct drm_clip_rect drm_clip_rect_t;
> -- 
> 1.9.1
> 
> ___
> 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 04/23] drm: Add drm structures for palette color property

[Daniel Vetter]

On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
> From: Kausal Malladi 
> 
> This patch adds new structures in DRM layer for Palette color
> correction.These structures will be used by user space agents
> to configure appropriate number of samples and Palette LUT for
> a platform.
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Kausal Malladi 
> ---
>  include/uapi/drm/drm.h | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index e3c642f..f72b916 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -840,6 +840,33 @@ struct drm_palette_caps {
>   __u32 num_samples_after_ctm;
>  };
>  
> +struct drm_r32g32b32 {
> + /*
> +  * Data is in U8.24 fixed point format.
> +  * All platforms support values within [0, 1.0] range,
> +  * for Red, Green and Blue colors.
> +  */
> + __u32 r32;
> + __u32 g32;
> + __u32 b32;

It's not strictly required, but adding a __u32 reserved here to align the
struct to 64 bits seems good imo. Slight overhead but meh about that.

> +};
> +
> +struct drm_palette {
> + /* Structure version. Should be 1 currently */
> + __u32 version;

Definitely great practice to take compat into account and definitely
needed for the first design using ioctls but I don't think we need this
here. Properties are already extinsible themselves: We can just greate a
"ctm-v2", "ctm-v3" if the layout changes, and since the actual ctm matrix
is stored in the drm_crtc_state any compat code on the kernel will be
shared.

Aside: For an ioctl the recommended way to handle backwards compat and
extensions in drm is with a flags bitfield. That's more flexible than a
linear version field, and extending the ioctl struct at the end is already
handled by the drm core in a transparent fashion (it 0-fills either kernel
or userspace side).

> + /*
> +  * This has to be a supported value during get call.
> +  * Feature will be disabled if this is 0 while set
> +  */
> + __u32 num_samples;

blob properties already have a size, storing it again in the blob is
redundnant. Instead I think a small helper to get the number of samples
for a given gamma table blob would be needed.

Cheers, Daniel

> + /*
> +  * Starting of palette LUT in R32G32B32 format.
> +  * Each of RGB value is in U8.24 fixed point format.
> +  * Actual number of samples will depend upon num_samples
> +  */
> + struct drm_r32g32b32 lut[0];
> +};
> +
>  /* typedef area */
>  #ifndef __KERNEL__
>  typedef struct drm_clip_rect drm_clip_rect_t;
> -- 
> 1.9.1
> 
> ___
> 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 02/23] drm: Add structure for querying palette color capabilities

[Daniel Vetter]

On Wed, Sep 16, 2015 at 10:51:31AM -0700, Matt Roper wrote:
> On Wed, Sep 16, 2015 at 11:06:59PM +0530, Shashank Sharma wrote:
> > From: Kausal Malladi 
> > 
> > The DRM color management framework is targeting various hardware
> > platforms and drivers. Different platforms can have different color
> > correction and enhancement capabilities.
> > 
> > A commom user space application can query these capabilities using the
> > DRM property interface. Each driver can fill this property with its
> > platform's palette color capabilities.
> > 
> > This patch adds new structure in DRM layer for querying palette color
> > capabilities. This structure will be used by all user space
> > agents to configure appropriate color configurations.
> > 
> > Signed-off-by: Shashank Sharma 
> > Signed-off-by: Kausal Malladi 
> 
> I think you provided an explanation on a previous code review cycle, but
> I forget the details now...what's the benefit to using a blob for caps
> rather than having these be individual properties?  Individual
> properties seems more natural to me, but I think you had a justification
> for blobbing them together; that reasoning would be good to include in
> the commit message.

Yeah I'm leaning slightly towards individual props too, that would give us
a bit more freedom with placing them (e.g. if someone comes up with funky
hw where before_ctm and ctm are per-plane and after_ctm is on the crtc,
with only some planes support the before_ctm gamma table).

Also if you do per-prop properties instead of the blob you can drop the
version/reserved fields, since properties are inheritedly designed to be
extendible. So no need to revision them again (it only leads to more code
that might break).
-Daniel

> 
> 
> Matt
> 
> > ---
> >  include/uapi/drm/drm.h | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index 3801584..e3c642f 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -829,6 +829,17 @@ struct drm_event_vblank {
> > __u32 reserved;
> >  };
> >  
> > +struct drm_palette_caps {
> > +   /* Structure version. Should be 1 currently */
> > +   __u32 version;
> > +   /* For padding and future use */
> > +   __u32 reserved;
> > +   /* This may be 0 if not supported. e.g. plane palette or VLV pipe */
> > +   __u32 num_samples_before_ctm;
> > +   /* This will be non-zero for pipe. May be zero for planes on some HW */
> > +   __u32 num_samples_after_ctm;
> > +};
> > +
> >  /* typedef area */
> >  #ifndef __KERNEL__
> >  typedef struct drm_clip_rect drm_clip_rect_t;
> > -- 
> > 1.9.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> 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 RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Ville Syrjälä]

On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_aux-N.
> 
> It's possible to know which connector owns this aux channel by looking
> at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> the connector device pointer was correctly set in the aux helper struct.
> 
> Two main operations are provided on the registers: read and write. The
> address of the register to be read or written is given using lseek.
> Reading or writing does not update the offset of the file.
> 
> Signed-off-by: Rafael Antognolli 
> ---
>  drivers/gpu/drm/Kconfig   |   4 +
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_aux-dev.c | 326 
> ++
>  3 files changed, 331 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1a0a8df..eae847c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
>   bool
>   depends on DRM
>  
> +config DRM_AUX_CHARDEV
> + tristate "DRM DP AUX Interface"
> + depends on DRM
> +
>  config DRM_KMS_HELPER
>   tristate
>   depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719..a1a94306 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
>  
>  obj-$(CONFIG_DRM)+= drm.o
>  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
>  obj-$(CONFIG_DRM_TTM)+= ttm/
>  obj-$(CONFIG_DRM_TDFX)   += tdfx/
>  obj-$(CONFIG_DRM_R128)   += r128/
> diff --git a/drivers/gpu/drm/drm_aux-dev.c b/drivers/gpu/drm/drm_aux-dev.c
> new file mode 100644
> index 000..fcc334a
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_aux-dev.c
> @@ -0,0 +1,326 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Rafael Antognolli 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct drm_aux_dev {
> + struct list_head list;
> + unsigned index;
> + struct drm_dp_aux *aux;
> + struct device *dev;
> +};
> +
> +#define DRM_AUX_MINORS   256
> +static int drm_aux_dev_count = 0;
> +static LIST_HEAD(drm_aux_dev_list);
> +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> +
> +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> +{
> + struct drm_aux_dev *aux_dev;
> +
> + spin_lock(_aux_dev_list_lock);
> + list_for_each_entry(aux_dev, _aux_dev_list, list) {
> + if (aux_dev->index == index)
> + goto found;
> + }
> +
> + aux_dev = NULL;
> +found:
> + spin_unlock(_aux_dev_list_lock);
> + return aux_dev;
> +}
> +
> +static struct drm_aux_dev *drm_aux_dev_get_by_aux(struct drm_dp_aux *aux)
> +{
> + struct drm_aux_dev *aux_dev;
> +
> + spin_lock(_aux_dev_list_lock);
> + list_for_each_entry(aux_dev, _aux_dev_list, list) {
> + if (aux_dev->aux == aux)
> + goto found;
> + }
> +
> + aux_dev = NULL;
> +found:
> + spin_unlock(_aux_dev_list_lock);
> + return aux_dev;
> +}
> +
> +static struct drm_aux_dev *get_free_drm_aux_dev(struct drm_dp_aux *aux)
> +{
> + struct drm_aux_dev *aux_dev;
> + int index;
> +
> + spin_lock(_aux_dev_list_lock);
> + index = drm_aux_dev_count;
> + spin_unlock(_aux_dev_list_lock);
> + if (index >= DRM_AUX_MINORS) {
> + printk(KERN_ERR "i2c-dev: Out of device minors (%d)\n",
> +index);
> + return 

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Daniel Vetter]

On Tue, Sep 22, 2015 at 03:35:13PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2015 at 02:17:51PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2015 at 03:00:54PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > > dev node per DP AUX channel, named drm_aux-N.
> > > > 
> > > > It's possible to know which connector owns this aux channel by looking
> > > > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > > > the connector device pointer was correctly set in the aux helper struct.
> > > > 
> > > > Two main operations are provided on the registers: read and write. The
> > > > address of the register to be read or written is given using lseek.
> > > > Reading or writing does not update the offset of the file.
> > > > 
> > > > Signed-off-by: Rafael Antognolli 
> > > > ---
> > > >  drivers/gpu/drm/Kconfig   |   4 +
> > > >  drivers/gpu/drm/Makefile  |   1 +
> > > >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > > > ++
> > > >  3 files changed, 331 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > > > 
> > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > index 1a0a8df..eae847c 100644
> > > > --- a/drivers/gpu/drm/Kconfig
> > > > +++ b/drivers/gpu/drm/Kconfig
> > > > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > > > bool
> > > > depends on DRM
> > > >  
> > > > +config DRM_AUX_CHARDEV
> > > > +   tristate "DRM DP AUX Interface"
> > > > +   depends on DRM
> > > > +
> > > >  config DRM_KMS_HELPER
> > > > tristate
> > > > depends on DRM
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 45e7719..a1a94306 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> > > >  
> > > >  obj-$(CONFIG_DRM)  += drm.o
> > > >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > > > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> > > >  obj-$(CONFIG_DRM_TTM)  += ttm/
> > > >  obj-$(CONFIG_DRM_TDFX) += tdfx/
> > > >  obj-$(CONFIG_DRM_R128) += r128/
> > > > diff --git a/drivers/gpu/drm/drm_aux-dev.c 
> > > > b/drivers/gpu/drm/drm_aux-dev.c
> > > > new file mode 100644
> > > > index 000..fcc334a
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > > > @@ -0,0 +1,326 @@
> > > > +/*
> > > > + * Copyright © 2015 Intel Corporation
> > > > + *
> > > > + * Permission is hereby granted, free of charge, to any person 
> > > > obtaining a
> > > > + * copy of this software and associated documentation files (the 
> > > > "Software"),
> > > > + * to deal in the Software without restriction, including without 
> > > > limitation
> > > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > > sublicense,
> > > > + * and/or sell copies of the Software, and to permit persons to whom 
> > > > the
> > > > + * Software is furnished to do so, subject to the following conditions:
> > > > + *
> > > > + * The above copyright notice and this permission notice (including 
> > > > the next
> > > > + * paragraph) shall be included in all copies or substantial portions 
> > > > of the
> > > > + * Software.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > > EXPRESS OR
> > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > > MERCHANTABILITY,
> > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > > SHALL
> > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
> > > > OR OTHER
> > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > > ARISING
> > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > > DEALINGS
> > > > + * IN THE SOFTWARE.
> > > > + *
> > > > + * Authors:
> > > > + *Rafael Antognolli 
> > > > + *
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +struct drm_aux_dev {
> > > > +   struct list_head list;
> > > > +   unsigned index;
> > > > +   struct drm_dp_aux *aux;
> > > > +   struct device *dev;
> > > > +};
> > > > +
> > > > +#define DRM_AUX_MINORS 256
> > > > +static int drm_aux_dev_count = 0;
> > > > +static LIST_HEAD(drm_aux_dev_list);
> > > > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > > > +
> > > > +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> > > > +{
> > > > +   struct drm_aux_dev *aux_dev;
> > > > +
> > > > +   spin_lock(_aux_dev_list_lock);
> > > > +   list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > > > +   if (aux_dev->index == index)
> > > > +  

[PATCH 11/11] drm: Fix vblank timestamp races

[Daniel Vetter]

On Tue, Sep 22, 2015 at 03:36:44PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2015 at 11:10:50AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala at linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > The vblank timestamp ringbuffer only has two entries, so if the
> > > vblank->count is incremented by an even number readers may end up seeing
> > > the new vblank timestamp alongside the old vblank counter value.
> > > 
> > > Fix the problem by storing the vblank counter in a ringbuffer as well,
> > > and always increment the ringbuffer "slot" by one when storing a new
> > > timestamp+counter pair.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Imo if we bother with this we might as well just switch over to using
> > full-blown seqlocks. They internally use a two-stage update which means
> > race-free even with just one copy of the data we protect. Also more
> > standardized to boot.
> 
> Any volunteers for that? I don't have time to start redoing this right
> now.

I guess we can keep it as a low-hanging thing for now, didn't seem to have
annoyed anyone yet. It should be fairly simple since all the vblank
counter access goes through the 2 functions I created a while back while
polishing the barriers a bit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[patch] drm/layerscape: fix a signedness bug

[Andrzej Hajda]

Hi,

I have posted the same patch yesterday [1].

http://permalink.gmane.org/gmane.comp.video.dri.devel/136945

Regards
Andrzej

On 09/22/2015 02:31 PM, Dan Carpenter wrote:
> "index" needs to be signed for the error handling to work.  Really "ret"
> should be an int as well.
> 
> Fixes: 109eee2f2a18 ('drm/layerscape: Add Freescale DCU DRM driver')
> Signed-off-by: Dan Carpenter 
> 
> 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 82be6b8..d1e300d 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> @@ -58,7 +58,8 @@ static void fsl_dcu_drm_plane_atomic_disable(struct 
> drm_plane *plane,
>struct drm_plane_state *old_state)
>  {
>   struct fsl_dcu_drm_device *fsl_dev = plane->dev->dev_private;
> - unsigned int index, value, ret;
> + unsigned int value;
> + int index, ret;
>  
>   index = fsl_dcu_drm_plane_index(plane);
>   if (index < 0)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH 04/23] drm: Add drm structures for palette color property

[Emil Velikov]

On 22 September 2015 at 14:08, Daniel Vetter  wrote:
> On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
>> From: Kausal Malladi 
>>
>> This patch adds new structures in DRM layer for Palette color
>> correction.These structures will be used by user space agents
>> to configure appropriate number of samples and Palette LUT for
>> a platform.
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>  include/uapi/drm/drm.h | 27 +++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index e3c642f..f72b916 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
[snip]
>> +struct drm_palette {
[snip]
> ... extending the ioctl struct at the end ...
Is this really going to work, considering that we currently have a
zero sized drm_r32g32b32 array at the end ?

Iirc someone mentioned that using a pointer to the data (over an
array) has drawbacks, although for the sake of me I cannot think of
any. Can anyone care to enlighten me, please ?

Thanks
Emil

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

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

--- Comment #12 from Ilia Mirkin  ---
(In reply to Kai from comment #11)
> Created attachment 118397 [details]
> Setting environment variables yields visible bodies.
> 
> (In reply to Ilia Mirkin from comment #10)
> > (In reply to Timothy Arceri from comment #9)
> > > (In reply to Ilia Mirkin from comment #7)
> > > > (In reply to Kai from comment #5)
> > > > > Also, the game seems to choke on the missing AoA functionality or at 
> > > > > least
> > > > > doesn't check whether it can use AoA:
> > > > > > 0:9(23): error: GL_ARB_arrays_of_arrays required for defining 
> > > > > > arrays of arrays
> > > > 
> > > > I guess line 9 is: out vec4 vControlPoint[][2];
> > > > 
> > > > Which should work without AoA. I wonder if this was recently broken by 
> > > > the
> > > > AoA support patches... Or maybe it started out broken.
> > > 
> > > It seems to me that this should fail, and is correctly doing so. From the
> > > tessellation spec:
> > >
> > > [...]
> > > 
> > > Is there something I'm missing?
> > 
> > Quite right. I forgot about that little bit in the spec. So the issue here
> > is that (a) AoA isn't supported in mesa, (b) even if it was, the shader
> > doesn't enable it. Without that, you can't have plain per-vertex array
> > outputs in TCS.
> 
> So, I should probably report this bug to Ferral Interactive (studio
> responsible for the Linux port), right?

That would be ideal.

> 
> > You could force-enable it by setting force_glsl_extensions_warn=1 and
> > MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays ... I think.
> 
> The correct override is:
> # force_glsl_extensions_warn=true
> MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays
> Setting force_glsl_extension_warn=1 leads to an error. And indeed, setting
> those two environment variables leads to visible characters in the game, see
> the attached screenshot.
> 
> Should this bug be renamed to »[radeonsi] Implement GL_ARB_arrays_of_arrays
> for "Middle-earth: Shadow of Mordor"« then?

As I mentioned, merely having the ext available wouldn't make that shader
compile. The ext would also have to be enabled in the shader.

However perhaps the game would detect the availability of the ext and stick a
"#extension GL_ARB_arrays_of_arrays: enable" into that shader, which would make
it work -- no way of knowing that.

-- 
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/20150922/3e1e3ab8/attachment-0001.html>

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

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

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

--- Comment #17 from Andy Pillip  ---
This is not a cable issue.

I just figured out that for me the issue only occurs on a dual screen setup.

Now I'm running the 3840 resolution on my external screen while switching off
the internal one – without any issues.

Tvrtko, do you have a dual or single setup?

-- 
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/20150922/3de64d27/attachment.html>

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Daniel Vetter]

On Tue, Sep 22, 2015 at 03:00:54PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > This module is heavily based on i2c-dev. Once loaded, it provides one
> > dev node per DP AUX channel, named drm_aux-N.
> > 
> > It's possible to know which connector owns this aux channel by looking
> > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > the connector device pointer was correctly set in the aux helper struct.
> > 
> > Two main operations are provided on the registers: read and write. The
> > address of the register to be read or written is given using lseek.
> > Reading or writing does not update the offset of the file.
> > 
> > Signed-off-by: Rafael Antognolli 
> > ---
> >  drivers/gpu/drm/Kconfig   |   4 +
> >  drivers/gpu/drm/Makefile  |   1 +
> >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > ++
> >  3 files changed, 331 insertions(+)
> >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 1a0a8df..eae847c 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > bool
> > depends on DRM
> >  
> > +config DRM_AUX_CHARDEV
> > +   tristate "DRM DP AUX Interface"
> > +   depends on DRM
> > +
> >  config DRM_KMS_HELPER
> > tristate
> > depends on DRM
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 45e7719..a1a94306 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> >  
> >  obj-$(CONFIG_DRM)  += drm.o
> >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> >  obj-$(CONFIG_DRM_TTM)  += ttm/
> >  obj-$(CONFIG_DRM_TDFX) += tdfx/
> >  obj-$(CONFIG_DRM_R128) += r128/
> > diff --git a/drivers/gpu/drm/drm_aux-dev.c b/drivers/gpu/drm/drm_aux-dev.c
> > new file mode 100644
> > index 000..fcc334a
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > @@ -0,0 +1,326 @@
> > +/*
> > + * Copyright © 2015 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + * Authors:
> > + *Rafael Antognolli 
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct drm_aux_dev {
> > +   struct list_head list;
> > +   unsigned index;
> > +   struct drm_dp_aux *aux;
> > +   struct device *dev;
> > +};
> > +
> > +#define DRM_AUX_MINORS 256
> > +static int drm_aux_dev_count = 0;
> > +static LIST_HEAD(drm_aux_dev_list);
> > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > +
> > +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> > +{
> > +   struct drm_aux_dev *aux_dev;
> > +
> > +   spin_lock(_aux_dev_list_lock);
> > +   list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > +   if (aux_dev->index == index)
> > +   goto found;
> > +   }
> > +
> > +   aux_dev = NULL;
> > +found:
> > +   spin_unlock(_aux_dev_list_lock);
> > +   return aux_dev;
> > +}
> > +
> > +static struct drm_aux_dev *drm_aux_dev_get_by_aux(struct drm_dp_aux *aux)
> > +{
> > +   struct drm_aux_dev *aux_dev;
> > +
> > +   spin_lock(_aux_dev_list_lock);
> > +   list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > +   if (aux_dev->aux == aux)
> > +   goto found;
> > +   }
> > +
> > +   aux_dev = NULL;
> > +found:
> > +   spin_unlock(_aux_dev_list_lock);
> > +   return aux_dev;
> > +}
> > +
> > +static struct drm_aux_dev *get_free_drm_aux_dev(struct drm_dp_aux *aux)
> > +{
> > +   struct drm_aux_dev *aux_dev;
> > +   int 

[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"

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

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

--- Comment #11 from Kai  ---
Created attachment 118397
  --> https://bugs.freedesktop.org/attachment.cgi?id=118397=edit
Setting environment variables yields visible bodies.

(In reply to Ilia Mirkin from comment #10)
> (In reply to Timothy Arceri from comment #9)
> > (In reply to Ilia Mirkin from comment #7)
> > > (In reply to Kai from comment #5)
> > > > Also, the game seems to choke on the missing AoA functionality or at 
> > > > least
> > > > doesn't check whether it can use AoA:
> > > > > 0:9(23): error: GL_ARB_arrays_of_arrays required for defining arrays 
> > > > > of arrays
> > > 
> > > I guess line 9 is: out vec4 vControlPoint[][2];
> > > 
> > > Which should work without AoA. I wonder if this was recently broken by the
> > > AoA support patches... Or maybe it started out broken.
> > 
> > It seems to me that this should fail, and is correctly doing so. From the
> > tessellation spec:
> >
> > [...]
> > 
> > Is there something I'm missing?
> 
> Quite right. I forgot about that little bit in the spec. So the issue here
> is that (a) AoA isn't supported in mesa, (b) even if it was, the shader
> doesn't enable it. Without that, you can't have plain per-vertex array
> outputs in TCS.

So, I should probably report this bug to Ferral Interactive (studio responsible
for the Linux port), right?

> You could force-enable it by setting force_glsl_extensions_warn=1 and
> MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays ... I think.

The correct override is:
# force_glsl_extensions_warn=true
MESA_EXTENSION_OVERRIDE=GL_ARB_arrays_of_arrays
Setting force_glsl_extension_warn=1 leads to an error. And indeed, setting
those two environment variables leads to visible characters in the game, see
the attached screenshot.

Should this bug be renamed to »[radeonsi] Implement GL_ARB_arrays_of_arrays for
"Middle-earth: Shadow of Mordor"« then?

-- 
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/20150922/f1a1c34c/attachment.html>

[PATCH 11/11] drm: Fix vblank timestamp races

[Daniel Vetter]

On Tue, Sep 22, 2015 at 01:15:01PM +0200, Maarten Lankhorst wrote:
> Op 22-09-15 om 11:10 schreef Daniel Vetter:
> > On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala at linux.intel.com 
> > wrote:
> >> From: Ville Syrjälä 
> >>
> >> The vblank timestamp ringbuffer only has two entries, so if the
> >> vblank->count is incremented by an even number readers may end up seeing
> >> the new vblank timestamp alongside the old vblank counter value.
> >>
> >> Fix the problem by storing the vblank counter in a ringbuffer as well,
> >> and always increment the ringbuffer "slot" by one when storing a new
> >> timestamp+counter pair.
> >>
> >> Signed-off-by: Ville Syrjälä 
> > Imo if we bother with this we might as well just switch over to using
> > full-blown seqlocks. They internally use a two-stage update which means
> > race-free even with just one copy of the data we protect. Also more
> > standardized to boot.
> >
> > Series looks good otherwise, I'll wait for Maarten to r-b it and then pull
> > it in.
> >
> R-b for 1-10.

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

[PATCH 04/23] drm: Add drm structures for palette color property

[Sharma, Shashank]

Regards
Shashank

On 9/21/2015 10:16 PM, Ville Syrjälä wrote:
> On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote:
>> From: Kausal Malladi 
>>
>> This patch adds new structures in DRM layer for Palette color
>> correction.These structures will be used by user space agents
>> to configure appropriate number of samples and Palette LUT for
>> a platform.
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>   include/uapi/drm/drm.h | 27 +++
>>   1 file changed, 27 insertions(+)
>>
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index e3c642f..f72b916 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -840,6 +840,33 @@ struct drm_palette_caps {
>>  __u32 num_samples_after_ctm;
>>   };
>>
>> +struct drm_r32g32b32 {
>> +/*
>> + * Data is in U8.24 fixed point format.
>> + * All platforms support values within [0, 1.0] range,
>> + * for Red, Green and Blue colors.
>> + */
>> +__u32 r32;
>> +__u32 g32;
>> +__u32 b32;
>> +};
>> +
>> +struct drm_palette {
>> +/* Structure version. Should be 1 currently */
>> +__u32 version;
>
> I don't think we want to version the blobs. For one, we don't have a way
> for userspace to ask for a specific version, so the kernel wouldn't know
> which version it should return to each client.
>
> If we ever need to come up with new version of a specific blob, I think we
> just have to define another property for it. Either that or we'd some kind
> of client cap stuff to negotiate the used version between the kernel and
> a specific client.
>
> Well, I suppose we migth be able to borrow the "flags+extend at the end"
> trick we sometimes use for ioctl parameters to work for blobs too. But I
> have a feeling we don't want to go there.
>
> So yeah, I think we should go with the "blob layout is fixed for each
> property" approach. Versioning then happens by introducing new versions
> of the same property if needed.
>
Well, reason behind adding this version was, as this framework was a new 
development, we wanted to keep scope for further changes on request from 
other drivers/modules. But yes, I agree, its kind of overhead, so we can 
also remove it. Will do that in next patch set.
>> +/*
>> + * This has to be a supported value during get call.
>> + * Feature will be disabled if this is 0 while set
>> + */
>> +__u32 num_samples;
>> +/*
>> + * Starting of palette LUT in R32G32B32 format.
>> + * Each of RGB value is in U8.24 fixed point format.
>> + * Actual number of samples will depend upon num_samples
>> + */
>> +struct drm_r32g32b32 lut[0];
>> +};
>> +
>>   /* typedef area */
>>   #ifndef __KERNEL__
>>   typedef struct drm_clip_rect drm_clip_rect_t;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 11/11] drm: Fix vblank timestamp races

[Maarten Lankhorst]

Op 22-09-15 om 11:10 schreef Daniel Vetter:
> On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala at linux.intel.com 
> wrote:
>> From: Ville Syrjälä 
>>
>> The vblank timestamp ringbuffer only has two entries, so if the
>> vblank->count is incremented by an even number readers may end up seeing
>> the new vblank timestamp alongside the old vblank counter value.
>>
>> Fix the problem by storing the vblank counter in a ringbuffer as well,
>> and always increment the ringbuffer "slot" by one when storing a new
>> timestamp+counter pair.
>>
>> Signed-off-by: Ville Syrjälä 
> Imo if we bother with this we might as well just switch over to using
> full-blown seqlocks. They internally use a two-stage update which means
> race-free even with just one copy of the data we protect. Also more
> standardized to boot.
>
> Series looks good otherwise, I'll wait for Maarten to r-b it and then pull
> it in.
>
R-b for 1-10.

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 12:56 PM, Daniel Vetter  
wrote:
> From: Matt Roper 
>
> Starting with commit
>
> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
> Author: Rob Clark 
> Date:   Tue Aug 25 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that 
> appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> v3: git add everything. Oops.
>
> Cc: Rob Clark 
> Cc: intel-gfx at lists.freedesktop.org
> Signed-off-by: Matt Roper  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..8af522afdfc1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
> drm_for_each_plane(plane, dev) {
> struct drm_plane_state *plane_state;
>
> +   plane->old_fb = plane->fb;
> +
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state)) {
> ret = PTR_ERR(plane_state);
> @@ -382,6 +384,21 @@ retry:
> }
>
> ret = drm_atomic_commit(state);
> +
> +   drm_for_each_plane(plane, dev) {
> +   if (ret == 0) {
> +   struct drm_framebuffer *new_fb = plane->state->fb;
> +   if (new_fb)
> +   drm_framebuffer_reference(new_fb);
> +   plane->fb = new_fb;
> +   plane->crtc = plane->state->crtc;
> +
> +   if (plane->old_fb)
> +   drm_framebuffer_unreference(plane->old_fb);
> +   }
> +   plane->old_fb = NULL;

You still leak "old_fb" if something jumps to "fail:" before
drm_atomic_commit() is called. But I don't mind:

Reviewed-by: David Herrmann 

Thanks
David

> +   }
> +
> if (ret != 0)
> goto fail;
>
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[Daniel Vetter]

From: Matt Roper 

Starting with commit

commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
Author: Rob Clark 
Date:   Tue Aug 25 15:36:00 2015 -0400

drm/i915: enable atomic fb-helper

I've been seeing some panics on i915 when the DRM master shuts down that appear
to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
dropping our initial FB's reference count to 0 and freeing it, which causes a
crash when we try to restore it later).  Digging deeper, the state FB
refcounting is working as expected, but we seem to be missing proper
refcounting on the legacy plane->fb pointers in the new atomic fbdev code.

Tracking plane->old_fb and then doing a ref/unref at the end of the
fbdev restore like we do in the legacy ioctl's ensures we don't miscount
references on plane->fb and avoids the panics.

v2 from Daniel:

Really do what the atomic ioctl does:
- Also update plane->fb and plane->crtc.
- Clear out plane->old_fb on failures too.

v3: git add everything. Oops.

Cc: Rob Clark 
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Matt Roper  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64fc5ca8fda2..8af522afdfc1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -352,6 +352,8 @@ retry:
drm_for_each_plane(plane, dev) {
struct drm_plane_state *plane_state;

+   plane->old_fb = plane->fb;
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -382,6 +384,21 @@ retry:
}

ret = drm_atomic_commit(state);
+
+   drm_for_each_plane(plane, dev) {
+   if (ret == 0) {
+   struct drm_framebuffer *new_fb = plane->state->fb;
+   if (new_fb)
+   drm_framebuffer_reference(new_fb);
+   plane->fb = new_fb;
+   plane->crtc = plane->state->crtc;
+
+   if (plane->old_fb)
+   drm_framebuffer_unreference(plane->old_fb);
+   }
+   plane->old_fb = NULL;
+   }
+
if (ret != 0)
goto fail;

-- 
2.5.1

[Bug 48772] Signal unstable over Display Port on 2560x1440 monitor

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

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

--- Comment #16 from Grigori Goronzy  ---
Note that this could also be a cable issue. Bad quality DP cables are prone to
cause various display issues. I once had a bad cable that even had trouble
driving standard 1080p without dropouts. So maybe just try another cable.

-- 
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/20150922/e2a301b2/attachment.html>

[RFC v2 4/4] drm/mediatek: Add DRM-based framebuffer device

[Philipp Zabel]

Hi Daniel,

Am Dienstag, den 22.09.2015, 11:29 +0200 schrieb Daniel Vetter:
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index 5343cf1..fa581fb 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -14,3 +14,15 @@ config DRM_MEDIATEK
> >   This driver provides kernel mode setting and
> >   buffer management to userspace.
> >  
> > +config DRM_MEDIATEK_FBDEV
> > +   bool "Enable legacy fbdev support for Mediatek DRM"
> > +   depends on DRM_MEDIATEK
> > +   select FB_SYS_FILLRECT
> > +   select FB_SYS_COPYAREA
> > +   select FB_SYS_IMAGEBLIT
> > +   select DRM_KMS_FB_HELPER
> > +   help
> > + Choose this option if you have a need for the legacy
> > + fbdev support.  Note that this support also provides
> > + the Linux console on top of the Mediatek DRM mode
> > + setting driver.
> 
> With the new Kconfig for fbdev emulation in 4.3 and the module option to
> disable it queued up for 4.4 driver-private Kconfig entries for fbdev
> aren't needed any more.
> -Daniel

I'll drop it for the next patch submission, thanks.

regards
Philipp

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 12:33 PM, Maarten Lankhorst
 wrote:
> Hey,
>
> Op 22-09-15 om 11:55 schreef Daniel Vetter:
>> From: Matt Roper 
>>
>> Starting with commit
>>
>> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
>> Author: Rob Clark 
>> Date:   Tue Aug 25 15:36:00 2015 -0400
>>
>> drm/i915: enable atomic fb-helper
>>
>> I've been seeing some panics on i915 when the DRM master shuts down that 
>> appear
>> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
>> dropping our initial FB's reference count to 0 and freeing it, which causes a
>> crash when we try to restore it later).  Digging deeper, the state FB
>> refcounting is working as expected, but we seem to be missing proper
>> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>>
>> Tracking plane->old_fb and then doing a ref/unref at the end of the
>> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
>> references on plane->fb and avoids the panics.
>>
>> v2 from Daniel:
>>
>> Really do what the atomic ioctl does:
>> - Also update plane->fb and plane->crtc.
>> - Clear out plane->old_fb on failures too.
>>
>> Cc: Rob Clark 
>> Cc: intel-gfx at lists.freedesktop.org
>> Signed-off-by: Matt Roper  (v1)
>> Signed-off-by: Daniel Vetter 
>> ---
>>  drivers/gpu/drm/drm_fb_helper.c | 16 
>>  1 file changed, 16 insertions(+)
>
> Looks sane, but I see a lot of this boilerplate for the plane->fb updates, 
> and we often get it wrong. Like for example in drm_mode_atomic_ioctl.
>
> Could all the plane->fb and old_fb updates be done by drm_atomic_commit or 
> async_commit instead?

If we decide to not care for stale "old_fb" pointers, I agree we
should make the commit-helpers do it.

Thanks
David

[PATCH 03/11] drm/i915: Mark debug mod options as _unsafe

[Jani Nikula]

On Tue, 08 Sep 2015, Daniel Vetter  wrote:
> We don't want random people to touch these.
>
> Especially true since we've just screwed up SKL by holding it way too
> long under the preliminary flag because of some ABI issues. And now
> there's howtos all over the internets about how to set this. Same
> pretty much for anything else.
>
> Cc: Jani Nikula 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/i915_params.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 05053e2e9ff0..39a8f560fad7 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -62,7 +62,7 @@ MODULE_PARM_DESC(modeset,
>   "Use kernel modesetting [KMS] (0=disable, "
>   "1=on, -1=force vga console preference [default])");
>  
> -module_param_named(panel_ignore_lid, i915.panel_ignore_lid, int, 0600);
> +module_param_named_unsafe(panel_ignore_lid, i915.panel_ignore_lid, int, 
> 0600);
>  MODULE_PARM_DESC(panel_ignore_lid,
>   "Override lid status (0=autodetect, 1=autodetect disabled [default], "
>   "-1=force lid closed, -2=force lid open)");
> @@ -85,17 +85,17 @@ MODULE_PARM_DESC(enable_fbc,
>   "Enable frame buffer compression for power savings "
>   "(default: -1 (use per-chip default))");
>  
> -module_param_named(lvds_channel_mode, i915.lvds_channel_mode, int, 0600);
> +module_param_named_unsafe(lvds_channel_mode, i915.lvds_channel_mode, int, 
> 0600);
>  MODULE_PARM_DESC(lvds_channel_mode,
>"Specify LVDS channel mode "
>"(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
>  
> -module_param_named(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
> +module_param_named_unsafe(lvds_use_ssc, i915.panel_use_ssc, int, 0600);
>  MODULE_PARM_DESC(lvds_use_ssc,
>   "Use Spread Spectrum Clock with panels [LVDS/eDP] "
>   "(default: auto from VBT)");
>  
> -module_param_named(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, int, 0600);
> +module_param_named_unsafe(vbt_sdvo_panel_type, i915.vbt_sdvo_panel_type, 
> int, 0600);
>  MODULE_PARM_DESC(vbt_sdvo_panel_type,
>   "Override/Ignore selection of SDVO panel mode in the VBT "
>   "(-2=ignore, -1=auto [default], index in VBT BIOS table)");
> @@ -103,7 +103,7 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
>  module_param_named_unsafe(reset, i915.reset, bool, 0600);
>  MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
>  
> -module_param_named(enable_hangcheck, i915.enable_hangcheck, bool, 0644);
> +module_param_named_unsafe(enable_hangcheck, i915.enable_hangcheck, bool, 
> 0644);
>  MODULE_PARM_DESC(enable_hangcheck,
>   "Periodically check GPU activity for detecting hangs. "
>   "WARNING: Disabling this can cause system wide hangs. "
> @@ -114,26 +114,26 @@ MODULE_PARM_DESC(enable_ppgtt,
>   "Override PPGTT usage. "
>   "(-1=auto [default], 0=disabled, 1=aliasing, 2=full)");
>  
> -module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
> +module_param_named_unsafe(enable_execlists, i915.enable_execlists, int, 
> 0400);
>  MODULE_PARM_DESC(enable_execlists,
>   "Override execlists usage. "
>   "(-1=auto [default], 0=disabled, 1=enabled)");
>  
> -module_param_named(enable_psr, i915.enable_psr, int, 0600);
> +module_param_named_unsafe(enable_psr, i915.enable_psr, int, 0600);
>  MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
>  
> -module_param_named(preliminary_hw_support, i915.preliminary_hw_support, int, 
> 0600);
> +module_param_named_unsafe(preliminary_hw_support, 
> i915.preliminary_hw_support, int, 0600);
>  MODULE_PARM_DESC(preliminary_hw_support,
>   "Enable preliminary hardware support.");
>  
> -module_param_named(disable_power_well, i915.disable_power_well, int, 0600);
> +module_param_named_unsafe(disable_power_well, i915.disable_power_well, int, 
> 0600);
>  MODULE_PARM_DESC(disable_power_well,
>   "Disable the power well when possible (default: true)");
>  
> -module_param_named(enable_ips, i915.enable_ips, int, 0600);
> +module_param_named_unsafe(enable_ips, i915.enable_ips, int, 0600);
>  MODULE_PARM_DESC(enable_ips, "Enable IPS (default: true)");
>  
> -module_param_named(fastboot, i915.fastboot, bool, 0600);
> +module_param_named_unsafe(fastboot, i915.fastboot, bool, 0600);
>  MODULE_PARM_DESC(fastboot,
>   "Try to skip unnecessary mode sets at boot time (default: false)");
>  
> @@ -147,7 +147,7 @@ MODULE_PARM_DESC(load_detect_test,
>   "Force-enable the VGA load detect code for testing (default:false). "
>   "For developers only.");
>  
> -module_param_named(invert_brightness, i915.invert_brightness, int, 0600);
> +module_param_named_unsafe(invert_brightness, i915.invert_brightness, int, 
> 0600);
>  MODULE_PARM_DESC(invert_brightness,
>   "Invert backlight brightness "
>   "(-1 force normal, 0 machine defaults, 

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:55 AM, Daniel Vetter  
wrote:
> From: Matt Roper 
>
> Starting with commit
>
> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
> Author: Rob Clark 
> Date:   Tue Aug 25 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that 
> appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> Cc: Rob Clark 
> Cc: intel-gfx at lists.freedesktop.org
> Signed-off-by: Matt Roper  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..1b564a69f561 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
> drm_for_each_plane(plane, dev) {
> struct drm_plane_state *plane_state;
>
> +   plane->old_fb = plane->fb;
> +
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state)) {
> ret = PTR_ERR(plane_state);
> @@ -382,6 +384,20 @@ retry:
> }
>
> ret = drm_atomic_commit(state);
> +
> +   drm_for_each_plane(plane, dev) {
> +   if (ret == 0) {
> +   struct drm_framebuffer *new_fb = plane->state->fb;
> +   if (new_fb)
> +   drm_framebuffer_reference(new_fb);
> +   plane->fb = new_fb;
> +   plane->crtc = plane->state->crtc;
> +
> +   if (plane->old_fb)
> +   drm_framebuffer_unreference(plane->old_fb);
> +   }
> +   }
> +
> if (ret != 0)
> goto fail;

Why move the fixup _before_ the error-check? drm_atomic_ioctl() does
this to make sure it never leaves stale "old_fb" pointers, but this is
clearly not what you do here. So either move it after the error-check
and drop the then redundant "if (ret ==0)" from the loop, or move it
into the "fail:" condition (maybe rename it) and properly take care of
"old_fb" and not-freeing "state".

Thanks
David

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[Maarten Lankhorst]

Hey,

Op 22-09-15 om 11:55 schreef Daniel Vetter:
> From: Matt Roper 
>
> Starting with commit
>
> commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
> Author: Rob Clark 
> Date:   Tue Aug 25 15:36:00 2015 -0400
>
> drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that 
> appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> Cc: Rob Clark 
> Cc: intel-gfx at lists.freedesktop.org
> Signed-off-by: Matt Roper  (v1)
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 16 
>  1 file changed, 16 insertions(+)

Looks sane, but I see a lot of this boilerplate for the plane->fb updates, and 
we often get it wrong. Like for example in drm_mode_atomic_ioctl.

Could all the plane->fb and old_fb updates be done by drm_atomic_commit or 
async_commit instead?

> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..1b564a69f561 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
>   drm_for_each_plane(plane, dev) {
>   struct drm_plane_state *plane_state;
>  
> + plane->old_fb = plane->fb;
> +
>   plane_state = drm_atomic_get_plane_state(state, plane);
>   if (IS_ERR(plane_state)) {
>   ret = PTR_ERR(plane_state);
> @@ -382,6 +384,20 @@ retry:
>   }
>  
>   ret = drm_atomic_commit(state);
> +
> + drm_for_each_plane(plane, dev) {
> + if (ret == 0) {
> + struct drm_framebuffer *new_fb = plane->state->fb;
> + if (new_fb)
> + drm_framebuffer_reference(new_fb);
> + plane->fb = new_fb;
> + plane->crtc = plane->state->crtc;
> +
> + if (plane->old_fb)
> + drm_framebuffer_unreference(plane->old_fb);
> + }
> + }
> +
>   if (ret != 0)
>   goto fail;
>  

[RFC v2 2/4] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Philipp Zabel]

Hi Daniel,

thank you for the comments.

Am Dienstag, den 22.09.2015, 11:38 +0200 schrieb Daniel Vetter:
[...]
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > new file mode 100644
> > index 000..fc071fe
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -0,0 +1,471 @@
[...]
> > +static int mtk_atomic_commit(struct drm_device *dev,
> > +struct drm_atomic_state *state,
> > +bool async)
> > +{
> > +   return drm_atomic_helper_commit(dev, state, false);
> 
> This isn't a proper async commit operation, it will still block userspace
> unecessarily. See e.g. the vc4 patches for a proper one.

I'll drop this function and assign .atomic_commit to
drm_atomic_helper_commit directly.

[...]
> > +static int mtk_plane_atomic_check(struct drm_plane *plane,
> > +   struct drm_plane_state *state)
> > +{
[...]
> > +   ret = drm_plane_helper_check_update(plane, state->crtc, fb,
> > +   , , ,
> > +   DRM_PLANE_HELPER_NO_SCALING,
> > +   DRM_PLANE_HELPER_NO_SCALING,
> > +   true, true, );
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (!visible)
> > +   return 0;
> > +
> > +   mtk_plane->disp_size = (dest.y2 - dest.y1) << 16 | (dest.x2 - dest.x1);
> 
> I think it might work out ok but it's very fragile to update object state
> from your atomic_check hooks - atomic allows a TEST_ONLY mode and if
> that's used (generic userspace will do that a few times for each frame at
> least) then you clobber shared state. Instead it's better to store that in
> your own mtk_plane_state which subclasses drm_plane_state.

Ok, will do.

[...]
> > +static void mtk_plane_attach_zpos_property(struct drm_plane *plane,
> > +   unsigned int zpos, unsigned int max_plane)
> > +{
> > +   struct drm_device *dev = plane->dev;
> > +   struct mtk_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, DRM_MODE_PROP_IMMUTABLE,
> > +"zpos", 0, max_plane - 1);
> 
> I know that there's lots of other drivers exposing zpos already, but I
> really think we should standardize this properly and document what it
> means. So
> - add a bit more text to the kerneldoc/doobook, especially what should
>   happen when there's a conflict in zpos.
> - move zpos registration/decoding into drm core, which means adding it to
>   drm_plane_state
> - have an open-source implementation using this somewhere (ddx, wayland,
>   hwc, ...).
> 
> I think for now it's better to drop the zpos property from initial
> mediatek enabling.

Alright, I'll separate this from the initial patchset.

best regards
Philipp

[PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore

[Daniel Vetter]

From: Matt Roper 

Starting with commit

commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
Author: Rob Clark 
Date:   Tue Aug 25 15:36:00 2015 -0400

drm/i915: enable atomic fb-helper

I've been seeing some panics on i915 when the DRM master shuts down that appear
to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
dropping our initial FB's reference count to 0 and freeing it, which causes a
crash when we try to restore it later).  Digging deeper, the state FB
refcounting is working as expected, but we seem to be missing proper
refcounting on the legacy plane->fb pointers in the new atomic fbdev code.

Tracking plane->old_fb and then doing a ref/unref at the end of the
fbdev restore like we do in the legacy ioctl's ensures we don't miscount
references on plane->fb and avoids the panics.

v2 from Daniel:

Really do what the atomic ioctl does:
- Also update plane->fb and plane->crtc.
- Clear out plane->old_fb on failures too.

Cc: Rob Clark 
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Matt Roper  (v1)
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 64fc5ca8fda2..1b564a69f561 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -352,6 +352,8 @@ retry:
drm_for_each_plane(plane, dev) {
struct drm_plane_state *plane_state;

+   plane->old_fb = plane->fb;
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
@@ -382,6 +384,20 @@ retry:
}

ret = drm_atomic_commit(state);
+
+   drm_for_each_plane(plane, dev) {
+   if (ret == 0) {
+   struct drm_framebuffer *new_fb = plane->state->fb;
+   if (new_fb)
+   drm_framebuffer_reference(new_fb);
+   plane->fb = new_fb;
+   plane->crtc = plane->state->crtc;
+
+   if (plane->old_fb)
+   drm_framebuffer_unreference(plane->old_fb);
+   }
+   }
+
if (ret != 0)
goto fail;

-- 
2.5.1

[PATCH 03/11] drm/i915: Mark debug mod options as _unsafe

[Daniel Vetter]

On Tue, Sep 22, 2015 at 12:34:23PM +0300, Jani Nikula wrote:
> On Tue, 08 Sep 2015, Daniel Vetter  wrote:
> > We don't want random people to touch these.
> >
> > Especially true since we've just screwed up SKL by holding it way too
> > long under the preliminary flag because of some ABI issues. And now
> > there's howtos all over the internets about how to set this. Same
> > pretty much for anything else.
> >
> > Cc: Jani Nikula 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 00/38] Fixes related to incorrect usage of unsigned types

[Jacek Anaszewski]

On 09/22/2015 11:13 AM, Andrzej Hajda wrote:
> On 09/21/2015 03:42 PM, David Howells wrote:
>> Andrzej Hajda  wrote:
>>
>>> Semantic patch finds comparisons of types:
>>>  unsigned < 0
>>>  unsigned >= 0
>>> The former is always false, the latter is always true.
>>> Such comparisons are useless, so theoretically they could be
>>> safely removed, but their presence quite often indicates bugs.
>>
>> Or someone has left them in because they don't matter and there's the
>> possibility that the type being tested might be or become signed under some
>> circumstances.  If the comparison is useless, I'd expect the compiler to just
>> discard it - for such cases your patch is pointless.
>>
>> If I have, for example:
>>
>>  unsigned x;
>>
>>  if (x == 0 || x > 27)
>>  give_a_range_error();
>>
>> I will write this as:
>>
>>  unsigned x;
>>
>>  if (x <= 0 || x > 27)
>>  give_a_range_error();
>>
>> because it that gives a way to handle x being changed to signed at some point
>> in the future for no cost.  In which case, your changing the <= to an ==
>> "because the < part of the case is useless" is arguably wrong.
>
> This is why I have not checked for such cases - I have skipped checks of type
>   unsigned <= 0
> exactly for the reasons above.
>
> However I have left two other checks as they seems to me more suspicious - 
> they
> are always true or false. But as Dmitry and Andrew pointed out Linus have 
> quite
> strong opinion against removing range checks in such cases as he finds it
> clearer. I think it applies to patches 29-36. I am not sure about patches 
> 26-28,37.

Dropped 30/38 and 31/38 from LED tree then.

-- 
Best Regards,
Jacek Anaszewski

[PATCH 03/38] drm/i915: fix handling gen8_emit_flush_coherentl3_wa result

[Daniel Vetter]

On Mon, Sep 21, 2015 at 04:59:58PM +0300, Jani Nikula wrote:
> On Mon, 21 Sep 2015, Andrzej Hajda  wrote:
> > The function can return negative value.
> >
> > The problem has been detected using proposed semantic patch
> > scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
> >
> > [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
> >
> > Signed-off-by: Andrzej Hajda 
> 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 5/6] virtio-gpu: add basic prime support

[Daniel Vetter]

On Mon, Sep 21, 2015 at 11:40:16AM +0200, Gerd Hoffmann wrote:
> From: Dave Airlie 
> 
> This is enough to enable DRI3.
> 
> Signed-off-by: Dave Airlie 
> Signed-off-by: Gerd Hoffmann 
> ---
>  drivers/gpu/drm/virtio/Makefile|  2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c   | 13 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.h   | 12 ++
>  drivers/gpu/drm/virtio/virtgpu_prime.c | 72 
> ++
>  4 files changed, 97 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/virtio/virtgpu_prime.c
> 
> diff --git a/drivers/gpu/drm/virtio/Makefile b/drivers/gpu/drm/virtio/Makefile
> index da7bf19..3fb8eac 100644
> --- a/drivers/gpu/drm/virtio/Makefile
> +++ b/drivers/gpu/drm/virtio/Makefile
> @@ -7,6 +7,6 @@ ccflags-y := -Iinclude/drm
>  virtio-gpu-y := virtgpu_drv.o virtgpu_kms.o virtgpu_drm_bus.o virtgpu_gem.o \
>   virtgpu_fb.o virtgpu_display.o virtgpu_vq.o virtgpu_ttm.o \
>   virtgpu_fence.o virtgpu_object.o virtgpu_debugfs.o virtgpu_plane.o \
> - virtgpu_ioctl.o
> + virtgpu_ioctl.o virtgpu_prime.o
>  
>  obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio-gpu.o
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
> b/drivers/gpu/drm/virtio/virtgpu_drv.c
> index 957e455..1245d09 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -113,7 +113,7 @@ static const struct file_operations 
> virtio_gpu_driver_fops = {
>  
>  
>  static struct drm_driver driver = {
> - .driver_features = DRIVER_MODESET | DRIVER_GEM,
> + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
>   .set_busid = drm_virtio_set_busid,
>   .load = virtio_gpu_driver_load,
>   .unload = virtio_gpu_driver_unload,
> @@ -128,6 +128,17 @@ static struct drm_driver driver = {
>   .debugfs_init = virtio_gpu_debugfs_init,
>   .debugfs_cleanup = virtio_gpu_debugfs_takedown,
>  #endif
> + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> + .gem_prime_export = drm_gem_prime_export,
> + .gem_prime_import = drm_gem_prime_import,
> + .gem_prime_pin = virtgpu_gem_prime_pin,
> + .gem_prime_unpin = virtgpu_gem_prime_unpin,
> + .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
> + .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
> + .gem_prime_vmap = virtgpu_gem_prime_vmap,
> + .gem_prime_vunmap = virtgpu_gem_prime_vunmap,
> + .gem_prime_mmap = virtgpu_gem_prime_mmap,
>  
>   .gem_free_object = virtio_gpu_gem_free_object,
>   .gem_open_object = virtio_gpu_gem_object_open,
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 2719108..79f0abe 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -359,6 +359,18 @@ int virtio_gpu_object_get_sg_table(struct 
> virtio_gpu_device *qdev,
>  void virtio_gpu_object_free_sg_table(struct virtio_gpu_object *bo);
>  int virtio_gpu_object_wait(struct virtio_gpu_object *bo, bool no_wait);
>  
> +/* virtgpu_prime.c */
> +int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
> +void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
> +struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
> +struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> +struct drm_device *dev, struct dma_buf_attachment *attach,
> +struct sg_table *sgt);
> +void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
> +void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
> +int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
> +struct vm_area_struct *vma);
> +
>  static inline struct virtio_gpu_object*
>  virtio_gpu_object_ref(struct virtio_gpu_object *bo)
>  {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
> b/drivers/gpu/drm/virtio/virtgpu_prime.c
> new file mode 100644
> index 000..724c231
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
> @@ -0,0 +1,72 @@
> +/*
> + * Copyright 2014 Canonical
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT 

[RFC v2 2/4] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Daniel Vetter]

On Fri, Sep 18, 2015 at 06:12:00PM +0200, Philipp Zabel wrote:
> From: CK Hu 
> 
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: YT Shen 
> Signed-off-by: Philipp Zabel 

Bunch of comments related to atomic below. I didn't look at anything else
really.

> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/mediatek/Kconfig|  16 +
>  drivers/gpu/drm/mediatek/Makefile   |  10 +
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 515 
> 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |  84 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 231 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  39 +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 378 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  61 
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 471 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  46 +++
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c   | 151 
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h   |  29 ++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c  | 207 +++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.h  |  56 +++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c| 193 +++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.h|  38 ++
>  18 files changed, 2528 insertions(+)
>  create mode 100644 drivers/gpu/drm/mediatek/Kconfig
>  create mode 100644 drivers/gpu/drm/mediatek/Makefile
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1a0a8df..9e9987b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>  
>  source "drivers/gpu/drm/imx/Kconfig"
> +
> +source "drivers/gpu/drm/mediatek/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719..af6b592 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
>  obj-$(CONFIG_DRM_TEGRA) += tegra/
>  obj-$(CONFIG_DRM_STI) += sti/
>  obj-$(CONFIG_DRM_IMX) += imx/
> +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
>  obj-y+= i2c/
>  obj-y+= panel/
>  obj-y+= bridge/
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> new file mode 100644
> index 000..5343cf1
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -0,0 +1,16 @@
> +config DRM_MEDIATEK
> + tristate "DRM Support for Mediatek SoCs"
> + depends on DRM
> + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
> + select MTK_SMI
> + select DRM_PANEL
> + select DRM_MIPI_DSI
> + select DRM_PANEL_SIMPLE
> + select DRM_KMS_HELPER
> + select IOMMU_DMA
> + help
> +   Choose this option if you have a Mediatek SoCs.
> +   The module will be called mediatek-drm
> +   This driver provides kernel mode setting and
> +   buffer management to userspace.
> +
> diff --git a/drivers/gpu/drm/mediatek/Makefile 
> b/drivers/gpu/drm/mediatek/Makefile
> new file mode 100644
> index 000..d801572
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -0,0 +1,10 @@
> +mediatek-drm-y := mtk_drm_drv.o \
> +  mtk_drm_crtc.o \
> +  mtk_drm_ddp.o \
> +  mtk_drm_ddp_comp.o \
> +  mtk_drm_fb.o \
> +  mtk_drm_gem.o \
> +  mtk_drm_plane.o
> +
> +obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
> +
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> new file mode 100644
> index 000..c06b7d4
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -0,0 +1,515 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + 

[RFC v2 4/4] drm/mediatek: Add DRM-based framebuffer device

[Daniel Vetter]

On Fri, Sep 18, 2015 at 06:12:02PM +0200, Philipp Zabel wrote:
> From: CK Hu 
> 
> Add Mediatek legacy framebuffer support.
> 
> Signed-off-by: CK Hu 
> Signed-off-by: YT Shen 
> ---
>  drivers/gpu/drm/mediatek/Kconfig   |  12 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  13 +++
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c  | 192 
> +
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h  |   1 +
>  4 files changed, 218 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> index 5343cf1..fa581fb 100644
> --- a/drivers/gpu/drm/mediatek/Kconfig
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -14,3 +14,15 @@ config DRM_MEDIATEK
> This driver provides kernel mode setting and
> buffer management to userspace.
>  
> +config DRM_MEDIATEK_FBDEV
> + bool "Enable legacy fbdev support for Mediatek DRM"
> + depends on DRM_MEDIATEK
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select DRM_KMS_FB_HELPER
> + help
> +   Choose this option if you have a need for the legacy
> +   fbdev support.  Note that this support also provides
> +   the Linux console on top of the Mediatek DRM mode
> +   setting driver.

With the new Kconfig for fbdev emulation in 4.3 and the module option to
disable it queued up for 4.4 driver-private Kconfig entries for fbdev
aren't needed any more.
-Daniel

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index fc071fe..b67c582 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -46,6 +46,9 @@ static const struct drm_mode_config_funcs 
> mtk_drm_mode_config_funcs = {
>   .fb_create = mtk_drm_mode_fb_create,
>   .atomic_check = drm_atomic_helper_check,
>   .atomic_commit = mtk_atomic_commit,
> +#ifdef CONFIG_DRM_MEDIATEK_FBDEV
> + .output_poll_changed = mtk_drm_mode_output_poll_changed,
> +#endif
>  };
>  
>  static const enum mtk_ddp_comp_type mtk_ddp_main[] = {
> @@ -140,6 +143,12 @@ static int mtk_drm_kms_init(struct drm_device *dev)
>   drm_kms_helper_poll_init(dev);
>   drm_mode_config_reset(dev);
>  
> +#ifdef CONFIG_DRM_MEDIATEK_FBDEV
> + err = mtk_fbdev_create(dev);
> + if (err)
> + goto err_larb_get;
> +#endif
> +
>   return 0;
>  
>  err_larb_get:
> @@ -160,6 +169,10 @@ static void mtk_drm_kms_deinit(struct drm_device *dev)
>  {
>   drm_kms_helper_poll_fini(dev);
>  
> +#ifdef CONFIG_DRM_MEDIATEK_FBDEV
> + mtk_fbdev_destroy(dev);
> +#endif
> +
>   drm_vblank_cleanup(dev);
>   drm_mode_config_cleanup(dev);
>  }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> index dfa931b..9295ad3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
> @@ -102,6 +102,198 @@ static struct mtk_drm_fb 
> *mtk_drm_framebuffer_init(struct drm_device *dev,
>   return mtk_fb;
>  }
>  
> +#ifdef CONFIG_DRM_MEDIATEK_FBDEV
> +static int mtk_drm_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> + struct drm_fb_helper *helper = info->par;
> + struct mtk_drm_fb *mtk_fb = to_mtk_fb(helper->fb);
> +
> + return mtk_drm_gem_mmap_buf(mtk_fb->gem_obj[0], vma);
> +}
> +
> +static struct fb_ops mtk_fb_ops = {
> + .owner = THIS_MODULE,
> + .fb_fillrect = sys_fillrect,
> + .fb_copyarea = sys_copyarea,
> + .fb_imageblit = sys_imageblit,
> + .fb_check_var = drm_fb_helper_check_var,
> + .fb_set_par = drm_fb_helper_set_par,
> + .fb_blank = drm_fb_helper_blank,
> + .fb_pan_display = drm_fb_helper_pan_display,
> + .fb_setcmap = drm_fb_helper_setcmap,
> + .fb_mmap = mtk_drm_fb_mmap,
> +};
> +
> +static int mtk_fbdev_probe(struct drm_fb_helper *helper,
> +struct drm_fb_helper_surface_size *sizes)
> +{
> + struct drm_device *dev = helper->dev;
> + struct drm_mode_fb_cmd2 mode = { 0 };
> + struct mtk_drm_fb *mtk_fb;
> + struct mtk_drm_gem_obj *mtk_gem;
> + struct drm_gem_object *gem;
> + struct fb_info *info;
> + struct drm_framebuffer *fb;
> + unsigned long offset;
> + size_t size;
> + int err;
> +
> + mode.width = sizes->surface_width;
> + mode.height = sizes->surface_height;
> + mode.pitches[0] = sizes->surface_width * ((sizes->surface_bpp + 7) / 8);
> + mode.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> +   sizes->surface_depth);
> +
> + mode.height = mode.height;/* << 1; for fb use? */
> + size = mode.pitches[0] * mode.height;
> + dev_info(dev->dev, "mtk_fbdev_probe %dx%d bpp %d pitch %d size %zu\n",
> +  mode.width, mode.height, sizes->surface_bpp, mode.pitches[0],
> +  size);
> +
> + mtk_gem = mtk_drm_gem_create(dev, size, true);
> + if