drm-tip/drm-tip boot: 83 boots: 1 failed, 79 passed with 3 offline (v4.11-rc5-1747-g7aafd5c8395f)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 83 boots: 1 failed, 79 passed with 3 offline 
(v4.11-rc5-1747-g7aafd5c8395f)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1747-g7aafd5c8395f/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1747-g7aafd5c8395f/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1747-g7aafd5c8395f
Git Commit: 7aafd5c8395fea9a79fbee82de4ffc63c04790d6
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 12 unique boards, 9 SoC families, 20 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
exynos5800-peach-pi: 1 offline lab

multi_v7_defconfig+CONFIG_SMP=n:
rk3288-rock2-square: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5800-peach-pi: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 4/4] drm: zte: add VGA driver support

2017-04-06 Thread Shawn Guo
On Thu, Apr 06, 2017 at 01:12:51PM -0400, Sean Paul wrote:
> On Thu, Apr 06, 2017 at 11:01:10PM +0800, Shawn Guo wrote:
> > +static int zx_vga_connector_get_modes(struct drm_connector *connector)
> > +{
> > +   struct zx_vga *vga = to_zx_vga(connector);
> > +   unsigned long flags;
> > +   struct edid *edid;
> > +   int ret;
> > +
> > +   /*
> > +* Clear both detection bits to switch I2C bus from device
> > +* detecting to EDID reading.
> > +*/
> > +   spin_lock_irqsave(>lock, flags);
> > +   zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
> > +   spin_unlock_irqrestore(>lock, flags);
> > +
> > +   edid = drm_get_edid(connector, >ddc->adap);
> > +   if (!edid)
> > +   return 0;
> > +
> > +   /*
> > +* As edid reading succeeds, device must be connected, so we set
> > +* up detection bit for unplug interrupt here.
> > +*/
> > +   spin_lock_irqsave(>lock, flags);
> > +   zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
> > +   spin_unlock_irqrestore(>lock, flags);
> > +
> > +   drm_mode_connector_update_edid_property(connector, edid);
> > +   ret = drm_add_edid_modes(connector, edid);
> > +   kfree(edid);
> > +
> > +   return ret;
> > +}



> > +static irqreturn_t zx_vga_irq_handler(int irq, void *dev_id)
> > +{
> > +   struct zx_vga *vga = dev_id;
> > +   u32 status;
> > +
> > +   status = zx_readl(vga->mmio + VGA_I2C_STATUS);
> > +
> > +   /* Clear interrupt status */
> > +   zx_writel_mask(vga->mmio + VGA_I2C_STATUS, VGA_CLEAR_IRQ,
> > +  VGA_CLEAR_IRQ);
> > +
> > +   if (status & VGA_DEVICE_CONNECTED) {
> > +   /*
> > +* Since VGA_DETECT_SEL bits need to be reset for switching DDC
> > +* bus from device detection to EDID read, rather than setting
> > +* up HAS_DEVICE bit here, we need to do that in .get_modes
> > +* hook for unplug detecting after EDID read succeeds.
> > +*/
> > +   vga->connected = true;
> > +   return IRQ_WAKE_THREAD;
> > +   }
> > +
> > +   if (status & VGA_DEVICE_DISCONNECTED) {
> > +   spin_lock(>lock);
> > +   zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
> > + VGA_DETECT_SEL_NO_DEVICE);
> > +   spin_unlock(>lock);
> 
> I think you still have the race here. If you get a disconnect between get_edid
> successfully finishing, and resetting the DETECT_SEL register, you will end up
> with the device being disconnected and DETECT_SEL == 
> VGA_DETECT_SEL_HAS_DEVICE.
> 
> In order to close this, you'll need to hold the lock across the edid read.

We cannot hold a spin lock across the EDID read procedure, which does
sleep.

When you suggested to have a lock for DETECT_SEL register access, I
thought we are accessing it in a read-modify-write way and thus agreed
to add a lock.  However, I just found that it's not the case actually.
All the accesses to the register are single direct write.

And here is my understanding about the condition you described above.
Once DETECT_SEL register gets reset (both bits cleared), the hardware
switches DDC bus for EDID read, and hotplug detection will stop working
right away (this is how ZTE hardware works).  That said, if we get a
disconnect before drm_get_edid() successfully finishes, two points:

- The irq handler will not be triggered, so it will not get a chance to
  update DETECT_SEL register.
- The drm_get_edid() fails, and .get_modes returns with both detect bits
  kept cleared.

I think what we can do better in this case is that we should set the
device state into disconnected, before returning from .get_modes,
something like the code below.  But still, I do not see we need a lock
for that.

Shawn

static int zx_vga_connector_get_modes(struct drm_connector *connector)
{
struct zx_vga *vga = to_zx_vga(connector);
unsigned long flags;
struct edid *edid;
int ret;

/*
 * Clear both detection bits to switch I2C bus from device
 * detecting to EDID reading.
 */
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);

edid = drm_get_edid(connector, >ddc->adap);
if (!edid) {
/*
 * If EDID reading fails, we set the device state into
 * disconnected.
 */
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
  VGA_DETECT_SEL_NO_DEVICE);
vga->connected = false;
return 0;
}

/*
 * As edid reading succeeds, device must be connected, so we set
 * up detection bit for unplug interrupt here.
 */
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);

drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);

return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1747-g7aafd5c8395f)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1747-g7aafd5c8395f)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1747-g7aafd5c8395f/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1747-g7aafd5c8395f
Git Commit: 7aafd5c8395fea9a79fbee82de4ffc63c04790d6
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 77 boots: 1 failed, 71 passed with 5 offline (v4.11-rc5-1644-g3d39d8905c14)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 77 boots: 1 failed, 71 passed with 5 offline 
(v4.11-rc5-1644-g3d39d8905c14)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1644-g3d39d8905c14/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1644-g3d39d8905c14/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1644-g3d39d8905c14
Git Commit: 3d39d8905c145cdae5a79fe6d0a3c6fd70ff8a2f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 12 unique boards, 8 SoC families, 19 builds out of 207

Boot Failure Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_LKDTM=y:
rk3288-rock2-square: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y:
exynos4412-odroidx2: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5800-peach-pi: 1 offline lab

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
exynos4412-odroidx2: 1 offline lab

exynos_defconfig:
exynos5800-peach-pi: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

2017-04-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100306

--- Comment #15 from MirceaKitsune  ---
(In reply to Michel Dänzer from comment #14)

Yes, but it's due to an issue in one of the system components. I'm talking
about it there for the packaging related aspect, but figured this is helpful
for debugging the issue itself.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

2017-04-06 Thread Michel Dänzer
On 02/04/17 07:58 AM, Keith Packard wrote:
> 
>  2. Provide a way to hide some monitors from other clients using EDID
> manufacturer ids and product codes. Outputs with EDID properties
> matching the grab will report 'disconnected' to all clients other
> than the grabbing client. This way, the desktop environment never
> knows that an HMD has been plugged in, so there's no transient
> flicker of desktop being presented to it.

When no such special client (Steam?) is running, the desktop environment
will try to use the HMD anyway, right? So the expected use case would be
for the user to start a special client first and only plug in the HMD
afterwards? That seems a bit inconvenient.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted

2017-04-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100306

--- Comment #14 from Michel Dänzer  ---
This is the upstream bug tracker. For openSUSE related help, talk to openSUSE
folks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 10/12] drm/rockchip: Reoder drm bind/unbind sequence

2017-04-06 Thread Jeffy Chen
Current drm bind/unbind sequence would cause some memory issues.
For example we should not cleanup iommu before cleanup mode config.

Reorder bind/unbind sequence, follow exynos drm.

Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 49 +++--
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index cd7d02e1..f24968f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -136,21 +136,24 @@ static int rockchip_drm_bind(struct device *dev)
INIT_LIST_HEAD(>psr_list);
spin_lock_init(>psr_list_lock);
 
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
+   goto err_free;
+
drm_mode_config_init(drm_dev);
 
rockchip_drm_mode_config_init(drm_dev);
 
-   ret = rockchip_drm_init_iommu(drm_dev);
-   if (ret)
-   goto err_config_cleanup;
-
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
if (ret)
-   goto err_iommu_cleanup;
+   goto err_mode_config_cleanup;
 
-   /* init kms poll for handling hpd */
-   drm_kms_helper_poll_init(drm_dev);
+   ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
+   if (ret)
+   goto err_unbind_all;
+
+   drm_mode_config_reset(drm_dev);
 
/*
 * enable drm irq mode.
@@ -158,15 +161,12 @@ static int rockchip_drm_bind(struct device *dev)
 */
drm_dev->irq_enabled = true;
 
-   ret = drm_vblank_init(drm_dev, ROCKCHIP_MAX_CRTC);
-   if (ret)
-   goto err_kms_helper_poll_fini;
-
-   drm_mode_config_reset(drm_dev);
+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(drm_dev);
 
ret = rockchip_drm_fbdev_init(drm_dev);
if (ret)
-   goto err_vblank_cleanup;
+   goto err_kms_helper_poll_fini;
 
ret = drm_dev_register(drm_dev, 0);
if (ret)
@@ -175,17 +175,17 @@ static int rockchip_drm_bind(struct device *dev)
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
-err_vblank_cleanup:
-   drm_vblank_cleanup(drm_dev);
 err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
+   drm_vblank_cleanup(drm_dev);
+err_unbind_all:
component_unbind_all(dev, drm_dev);
-err_iommu_cleanup:
-   rockchip_iommu_cleanup(drm_dev);
-err_config_cleanup:
+err_mode_config_cleanup:
drm_mode_config_cleanup(drm_dev);
-   drm_dev->dev_private = NULL;
+   rockchip_iommu_cleanup(drm_dev);
 err_free:
+   drm_dev->dev_private = NULL;
+   dev_set_drvdata(dev, NULL);
drm_dev_unref(drm_dev);
return ret;
 }
@@ -194,16 +194,19 @@ static void rockchip_drm_unbind(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
 
+   drm_dev_unregister(drm_dev);
+
rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
-   drm_dev_unregister(drm_dev);
-   drm_dev_unref(drm_dev);
dev_set_drvdata(dev, NULL);
+   drm_dev_unref(drm_dev);
 }
 
 static void rockchip_drm_lastclose(struct drm_device *dev)
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

2017-04-06 Thread jeffy

Hi Sean,

On 04/06/2017 08:26 PM, Sean Paul wrote:

On Thu, Apr 06, 2017 at 10:47:59AM +0800, jeffy wrote:

Hi Sean,

On 04/06/2017 12:28 AM, Sean Paul wrote:

On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:

After unbinding drm, the userspace may still has a chance to access
gem buf.

Add a sanity check for a NULL dev_private to prevent that from
happening.


I still don't understand how this is happening. You're saying that these hooks
can be called after rockchip_drm_unbind() has finished?


yes, tested on chromebook rk3399 kevin with kernel 4.4, if trigger unbind
without killing display service(ui or frecon):

[   31.276889] [] dump_backtrace+0x0/0x164
[   31.282288] [] show_stack+0x24/0x30
[   31.287338] [] dump_stack+0x98/0xb8
[   31.292389] [] rockchip_gem_create_object+0x6c/0x2ec
[   31.298910] []
rockchip_gem_create_with_handle+0x38/0x10c
[   31.305868] [] rockchip_gem_create_ioctl+0x38/0x50
[   31.312221] [] drm_ioctl+0x2bc/0x438
[   31.317359] [] drm_compat_ioctl+0x3c/0x70
[   31.322935] [] compat_SyS_ioctl+0x134/0x1048
[   31.328766] [] __sys_trace_return+0x0/0x4


Hi Jeffy,
I'm not suggesting this doesn't happen, I believe you :-). I'd really like to
know *why* it happens.

Are you sure that unbind has completely finished before this trace occurs?
Perhaps this is results from a race between unbind and gem allocate?
yes, that unbind is finished. and it looks like the display server still 
holds drm dev fd(even it been deleted after unbind).


sometimes i can see it trigger ioctl even seconds later.

i'll send a patch to break drm_ioctl after unbind.


Sean




Sean



Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

   drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 
   1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..205a3dc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;

+   if (!private)
+   return -ENODEV;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)

   static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
   {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->dev_private)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
--
2.1.4










___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/5] i915: schedule while freeing the lists of gem objects

2017-04-06 Thread Andrea Arcangeli
Add cond_resched().

Signed-off-by: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 612fde3..c81baeb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4205,6 +4205,8 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
GEM_BUG_ON(!RB_EMPTY_ROOT(>vma_tree));
 
list_del(>global_link);
+
+   cond_resched();
}
intel_runtime_pm_put(i915);
mutex_unlock(>drm.struct_mutex);
@@ -4230,6 +4232,8 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
 
kfree(obj->bit_17);
i915_gem_object_free(obj);
+
+   cond_resched();
}
 }
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 5/5] i915: fence workqueue optimization

2017-04-06 Thread Andrea Arcangeli
Insist to run llist_del_all() until the free_list is found empty, this
may avoid having to schedule more workqueues.

Signed-off-by: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/intel_display.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 24f303e..931f0c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14374,9 +14374,9 @@ static void intel_atomic_helper_free_state(struct 
drm_i915_private *dev_priv)
struct intel_atomic_state *state, *next;
struct llist_node *freed;
 
-   freed = llist_del_all(_priv->atomic_helper.free_list);
-   llist_for_each_entry_safe(state, next, freed, freed)
-   drm_atomic_state_put(>base);
+   while ((freed = llist_del_all(_priv->atomic_helper.free_list)))
+   llist_for_each_entry_safe(state, next, freed, freed)
+   drm_atomic_state_put(>base);
 }
 
 static void intel_atomic_helper_free_state_worker(struct work_struct *work)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 01/12] drm: bridge: analogix: Detach panel when unbinding analogix dp

2017-04-06 Thread Your Name
From: Jeffy Chen 

The panel is attached when binding analogix dp.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Your Name 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
Fix some commit messages.

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c26997a..28144a1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1443,6 +1443,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
DRM_ERROR("failed to turnoff the panel\n");
+   if (drm_panel_detach(dp->plat_data->panel))
+   DRM_ERROR("failed to detach the panel\n");
}
 
pm_runtime_disable(dev);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 01/12] drm: bridge: analogix: Detach panel when unbinding analogix dp

2017-04-06 Thread Jeffy Chen
The panel is attached when binding analogix dp.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
---

Changes in v5:
Fix wrong git account.

Changes in v4: None
Changes in v3: None
Changes in v2:
Fix some commit messages.

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index c26997a..28144a1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1443,6 +1443,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
DRM_ERROR("failed to turnoff the panel\n");
+   if (drm_panel_detach(dp->plat_data->panel))
+   DRM_ERROR("failed to detach the panel\n");
}
 
pm_runtime_disable(dev);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 07/12] drm/rockchip: vop: Enable pm domain before vop_initial

2017-04-06 Thread Your Name
From: Jeffy Chen 

We're trying to access vop registers here, so need to make sure
the pm domain is on.

Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.

And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

Changes in v4: None
Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2151e1c..b65b296 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -506,7 +506,7 @@ static int vop_enable(struct drm_crtc *crtc)
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   goto err_put_pm_runtime;
+   return ret;
}
 
ret = clk_enable(vop->hclk);
@@ -1405,10 +1405,16 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
 
+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   return ret;
+   }
+
ret = clk_prepare(vop->dclk);
if (ret < 0) {
dev_err(vop->dev, "failed to prepare dclk\n");
-   return ret;
+   goto err_put_pm_runtime;
}
 
/* Enable both the hclk and aclk to setup the vop */
@@ -1468,6 +1474,8 @@ static int vop_initial(struct vop *vop)
 
vop->is_enabled = false;
 
+   pm_runtime_put_sync(vop->dev);
+
return 0;
 
 err_disable_aclk:
@@ -1476,6 +1484,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);
return ret;
 }
 
@@ -1576,12 +1586,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;
 
-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1608,8 +1612,17 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
 
pm_runtime_enable(>dev);
 
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }
+
return 0;
 
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
+   vop_destroy_crtc(vop);
 err_enable_irq:
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/5] i915: avoid kernel hang caused by synchronize rcu struct_mutex deadlock

2017-04-06 Thread Andrea Arcangeli
synchronize_rcu/synchronize_sched/synchronize_rcu_expedited() will
hang until its own workqueues are run. The i915 gem workqueues will
wait on the struct_mutex to be released. So we cannot wait for a
quiescent state using those rcu primitives while holding the
struct_mutex or it creates a circular lock dependency resulting in
kernel hangs (which is reproducible but goes undetected by lockdep).

This started in commit 3d3d18f086cdda72ee18a454db70ca72c6e3246c and
lockdep didn't detect it apparently.

kswapd0 D0   700  2 0x
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? _synchronize_rcu_expedited.constprop.65+0x2ef/0x300
? wake_up_bit+0x20/0x20
? rcu_stall_kick_kthreads.part.54+0xc0/0xc0
? rcu_exp_wait_wake+0x530/0x530
? i915_gem_shrink+0x34b/0x4b0
? i915_gem_shrinker_scan+0x7c/0x90
? i915_gem_shrinker_scan+0x7c/0x90
? shrink_slab.part.61.constprop.72+0x1c1/0x3a0
? shrink_zone+0x154/0x160
? kswapd+0x40a/0x720
? kthread+0xf4/0x130
? try_to_free_pages+0x450/0x450
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30
plasmashell D0  4657   4614 0x
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? i915_gem_close_object+0x26/0xc0
? i915_gem_close_object+0x26/0xc0
? drm_gem_object_release_handle+0x48/0x90
? drm_gem_handle_delete+0x50/0x80
? drm_ioctl+0x1fa/0x420
? drm_gem_handle_create+0x40/0x40
? pipe_write+0x391/0x410
? __vfs_write+0xc6/0x120
? do_vfs_ioctl+0x8b/0x5d0
? SyS_ioctl+0x3b/0x70
? entry_SYSCALL_64_fastpath+0x13/0x94
kworker/0:0 D0 29186  2 0x
Workqueue: events __i915_gem_free_work
Call Trace:
? __schedule+0x1a5/0x660
? schedule+0x36/0x80
? schedule_preempt_disabled+0xe/0x10
? __mutex_lock.isra.4+0x1c9/0x790
? del_timer_sync+0x44/0x50
? update_curr+0x57/0x110
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_objects+0x31/0x300
? __i915_gem_free_work+0x2d/0x40
? process_one_work+0x13a/0x3b0
? worker_thread+0x4a/0x460
? kthread+0xf4/0x130
? process_one_work+0x3b0/0x3b0
? kthread_create_on_node+0x40/0x40
? ret_from_fork+0x23/0x30

Signed-off-by: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/i915_gem.c  |  9 +
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 ++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 67b1fc5..3982489 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4742,6 +4742,13 @@ int i915_gem_freeze(struct drm_i915_private *dev_priv)
i915_gem_shrink_all(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
 
+   /*
+* Cannot call synchronize_rcu() inside the struct_mutex
+* because it may block until workqueues complete, and the
+* running workqueue may wait on the struct_mutex.
+*/
+   synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */
+
intel_runtime_pm_put(dev_priv);
 
return 0;
@@ -4781,6 +4788,8 @@ int i915_gem_freeze_late(struct drm_i915_private 
*dev_priv)
}
mutex_unlock(_priv->drm.struct_mutex);
 
+   synchronize_rcu_expedited();
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index d5d2b4c..fea1454 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -235,9 +235,6 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
if (unlock)
mutex_unlock(_priv->drm.struct_mutex);
 
-   /* expedite the RCU grace period to free some request slabs */
-   synchronize_rcu_expedited();
-
return count;
 }
 
@@ -263,7 +260,6 @@ unsigned long i915_gem_shrink_all(struct drm_i915_private 
*dev_priv)
I915_SHRINK_BOUND |
I915_SHRINK_UNBOUND |
I915_SHRINK_ACTIVE);
-   synchronize_rcu(); /* wait for our earlier RCU delayed slab frees */
 
return freed;
 }
@@ -324,6 +320,16 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct 
shrink_control *sc)
if (unlock)
mutex_unlock(>struct_mutex);
 
+   if (likely(__mutex_owner(>struct_mutex) != current))
+   /*
+* If reclaim was invoked by an allocation done while
+* holding the struct mutex, we cannot call
+* synchronize_rcu_expedited() as it depends on
+* workqueues to run but the running workqueue may be
+* blocked waiting on us to release struct_mutex.
+*/
+   synchronize_rcu_expedited();
+
return freed;
 }
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 03/12] drm: bridge: analogix: Disable clock when unbinding

2017-04-06 Thread Jeffy Chen
The clock is enabled when binding analogix dp.

Signed-off-by: Jeffy Chen 
---

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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7b75f82..d05ade4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1449,6 +1449,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
 
drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
+   clk_disable_unprepare(dp->clock);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
 
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 05/12] drm/rockchip: cdn-dp: Don't try to release firmware when not loaded

2017-04-06 Thread Your Name
From: Jeffy Chen 

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

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

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 4e55d63..ee4195d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1053,6 +1053,7 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->connected = false;
dp->active = false;
dp->active_port = -1;
+   dp->fw_loaded = false;
 
INIT_WORK(>event_work, cdn_dp_pd_event_work);
 
@@ -1133,7 +1134,8 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
connector->funcs->destroy(connector);
 
pm_runtime_disable(dev);
-   release_firmware(dp->fw);
+   if (dp->fw_loaded)
+   release_firmware(dp->fw);
kfree(dp->edid);
dp->edid = NULL;
 }
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 08/12] drm/rockchip: vop: Unprepare clocks when unbinding

2017-04-06 Thread Jeffy Chen
The clocks are prepared when binding vop.

Signed-off-by: Jeffy Chen 
---

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

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b65b296..3f7a82d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1634,6 +1634,10 @@ static void vop_unbind(struct device *dev, struct device 
*master, void *data)
 
pm_runtime_disable(dev);
vop_destroy_crtc(vop);
+
+   clk_unprepare(vop->aclk);
+   clk_unprepare(vop->hclk);
+   clk_unprepare(vop->dclk);
 }
 
 const struct component_ops vop_component_ops = {
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 07/12] drm/rockchip: vop: Enable pm domain before vop_initial

2017-04-06 Thread Jeffy Chen
We're trying to access vop registers here, so need to make sure
the pm domain is on.

Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.

And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.

Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2151e1c..b65b296 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -506,7 +506,7 @@ static int vop_enable(struct drm_crtc *crtc)
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   goto err_put_pm_runtime;
+   return ret;
}
 
ret = clk_enable(vop->hclk);
@@ -1405,10 +1405,16 @@ static int vop_initial(struct vop *vop)
return PTR_ERR(vop->dclk);
}
 
+   ret = pm_runtime_get_sync(vop->dev);
+   if (ret < 0) {
+   dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
+   return ret;
+   }
+
ret = clk_prepare(vop->dclk);
if (ret < 0) {
dev_err(vop->dev, "failed to prepare dclk\n");
-   return ret;
+   goto err_put_pm_runtime;
}
 
/* Enable both the hclk and aclk to setup the vop */
@@ -1468,6 +1474,8 @@ static int vop_initial(struct vop *vop)
 
vop->is_enabled = false;
 
+   pm_runtime_put_sync(vop->dev);
+
return 0;
 
 err_disable_aclk:
@@ -1476,6 +1484,8 @@ static int vop_initial(struct vop *vop)
clk_disable_unprepare(vop->hclk);
 err_unprepare_dclk:
clk_unprepare(vop->dclk);
+err_put_pm_runtime:
+   pm_runtime_put_sync(vop->dev);
return ret;
 }
 
@@ -1576,12 +1586,6 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
if (!vop->regsbak)
return -ENOMEM;
 
-   ret = vop_initial(vop);
-   if (ret < 0) {
-   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
-   return ret;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "cannot find irq for vop\n");
@@ -1608,8 +1612,17 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
 
pm_runtime_enable(>dev);
 
+   ret = vop_initial(vop);
+   if (ret < 0) {
+   dev_err(>dev, "cannot initial vop dev - err %d\n", ret);
+   goto err_disable_pm_runtime;
+   }
+
return 0;
 
+err_disable_pm_runtime:
+   pm_runtime_disable(>dev);
+   vop_destroy_crtc(vop);
 err_enable_irq:
enable_irq(vop->irq); /* To balance out the disable_irq above */
return ret;
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 06/12] drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

2017-04-06 Thread Jeffy Chen
After snd_soc_unregister_codec, the dai link would remain bound to
the invalid codec. That would cause crashes after unbind dp driver.

Let's unregister audio codec when removing dp driver to prevent that.

Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index ee4195d..a2169dd 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1092,8 +1092,6 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
goto err_free_connector;
}
 
-   cdn_dp_audio_codec_init(dp, dev);
-
for (i = 0; i < dp->ports; i++) {
port = dp->port[i];
 
@@ -1128,7 +1126,6 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
struct drm_connector *connector = >connector;
 
cancel_work_sync(>event_work);
-   platform_device_unregister(dp->audio_pdev);
cdn_dp_encoder_disable(encoder);
encoder->funcs->destroy(encoder);
connector->funcs->destroy(connector);
@@ -1221,6 +1218,8 @@ static int cdn_dp_probe(struct platform_device *pdev)
mutex_init(>lock);
dev_set_drvdata(dev, dp);
 
+   cdn_dp_audio_codec_init(dp, dev);
+
return component_add(dev, _dp_component_ops);
 }
 
@@ -1228,6 +1227,7 @@ static int cdn_dp_remove(struct platform_device *pdev)
 {
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
 
+   platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(>dev, _dp_component_ops);
 
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 11/12] drm/rockchip: Shutdown all crtcs when unbinding drm

2017-04-06 Thread Jeffy Chen
Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4: None
Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f24968f..c6b1b7f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -199,6 +199,7 @@ static void rockchip_drm_unbind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
 
+   drm_atomic_helper_shutdown(drm_dev);
drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 09/12] drm/rockchip: analogix_dp: Disable clock when unbinding

2017-04-06 Thread Jeffy Chen
The clock is enabled when binding cdn dp.

Signed-off-by: Jeffy Chen 
---

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

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 91ebe5c..c3b9f1d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -417,7 +417,8 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
 
rockchip_drm_psr_unregister(>encoder);
 
-   return analogix_dp_unbind(dev, master, data);
+   analogix_dp_unbind(dev, master, data);
+   clk_disable_unprepare(dp->pclk);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1644-g3d39d8905c14)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1644-g3d39d8905c14)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1644-g3d39d8905c14/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1644-g3d39d8905c14
Git Commit: 3d39d8905c145cdae5a79fe6d0a3c6fd70ff8a2f
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings (v4.11-rc5-1635-g6732aaa5e8d9)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 204 warnings 
(v4.11-rc5-1635-g6732aaa5e8d9)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1635-g6732aaa5e8d9/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1635-g6732aaa5e8d9
Git Commit: 6732aaa5e8d9f1bfa454efed21a548715b9b07d4
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

[PATCH 0/5] Re: [Intel-gfx] [BUG][REGRESSION] i915 gpu hangs under load

2017-04-06 Thread Andrea Arcangeli
I'm also getting kernel hangs every couple of days. For me it's still
not fixed here in 4.11-rc5. It's hard to reproduce, the best
reproducer is to build lineageos 14.1 on host while running LTP in a
guest to stress the guest VM.

Initially I thought it was related to the fact I upgraded the xf86
intel driver just a few weeks ago (I deferred any upgrade of the
userland intel driver since last July because of a regression that
never got fixed and broke xterm for me). After I found a workaround
for the userland regression (appended at the end for reference) I
started getting kernel hangs but they are separate issues as far as I
can tell.

It's not well tested so beware... (it survived a couple of builds and
some VM reclaim but that's it).

The first patch 1/5 is the potential fix for the i915 kernel hang. The
rest are incremental improvements.

And I've no great solution for when the shrinker was invoked with the
struct_mutex held and and recurse on the lock. I don't think we can
possibly wait in such case (other than flush work that the second
patch does) but then practically it shouldn't be a big deal, the big
RAM eater is unlikely to be i915 when the system is low on memory.

Andrea Arcangeli (5):
  i915: avoid kernel hang caused by synchronize rcu struct_mutex
deadlock
  i915: flush gem obj freeing workqueues to add accuracy to the i915
shrinker
  i915: initialize the free_list of the fencing atomic_helper
  i915: schedule while freeing the lists of gem objects
  i915: fence workqueue optimization

 drivers/gpu/drm/i915/i915_gem.c  | 15 +++
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 15 +++
 drivers/gpu/drm/i915/intel_display.c |  7 ---
 3 files changed, 30 insertions(+), 7 deletions(-)

===
Userland workaround for unusable xterm after commit
3d3d18f086cdda72ee18a454db70ca72c6e3246c (unrelated to this kernel
issue, just for reference of what I'm running in userland).

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 11beb90..d349203 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -17430,11 +17430,15 @@ sna_flush_callback(CallbackListPtr *list, pointer 
user_data, pointer call_data)
 {
struct sna *sna = user_data;
 
+#if 0
if (!sna->needs_dri_flush)
return;
+#endif
 
sna_accel_flush(sna);
+#if 0
sna->needs_dri_flush = false;
+#endif
 }
 
 static void

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 00/12] drm: rockchip: Fix rockchip drm unbind crash error

2017-04-06 Thread Your Name

Verified on rk3399 chromebook kevin:
1/ stop ui && pkill -9 frecon
2/ unbind/bind drm

Changes in v4:
Address Andrzej Hajda 's comments.

Changes in v3:
Update commit message.
Address Sean Paul 's comments.
Update commit message.
Address Sean Paul 's comments.
Update commit message.
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2:
Fix some commit messages.

Jeffy Chen (12):
  drm: bridge: analogix: Detach panel when unbinding analogix dp
  drm: bridge: analogix: Unregister dp aux when unbinding
  drm: bridge: analogix: Disable clock when unbinding
  drm: bridge: analogix: Destroy connector & encoder when unbinding
  drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
  drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding
  drm/rockchip: vop: Enable pm domain before vop_initial
  drm/rockchip: vop: Unprepare clocks when unbinding
  drm/rockchip: analogix_dp: Disable clock when unbinding
  drm/rockchip: Reoder drm bind/unbind sequence
  drm/rockchip: Shutdown all crtcs when unbinding drm
  drm/drm_ioctl.c: Break ioctl when drm device not registered

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 +++
 drivers/gpu/drm/drm_ioctl.c|  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  3 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 50 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 33 ++
 6 files changed, 67 insertions(+), 37 deletions(-)

-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: DRM Display driver for Intel FPGA Video and Image Processing Suite

2017-04-06 Thread Ong, Hean Loong
Hi All,

Any comments for the patch below?

Thanks

Hean Loong

On Tue, 2017-04-04 at 04:01 +, Ong, Hean Loong wrote:
> Hi All,
> 
> Apologies for the attachment earlier. Below are the inline changes
> for the patch
> 
> From 0de293e3646a1780ed603cf8e1f2a19d9aebbe83 Mon Sep 17 00:00:00
> 2001
> From: Ong, Hean Loong 
> Date: Thu, 30 Mar 2017 18:02:22 +0800
> Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite Frame
> Buffer II driver
> 
> Signed-off-by: Ong, Hean Loong 
> ---
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/ivip/Kconfig  |   22 
>  drivers/gpu/drm/ivip/Makefile |9 ++
>  drivers/gpu/drm/ivip/intel_vip_conn.c |  145 ++
>  drivers/gpu/drm/ivip/intel_vip_core.c |  215
> +
>  drivers/gpu/drm/ivip/intel_vip_crtc.c |  161
> 
>  drivers/gpu/drm/ivip/intel_vip_drv.h  |   55 +
>  drivers/gpu/drm/ivip/intel_vip_of.c   |  146 ++
>  9 files changed, 756 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpu/drm/ivip/Kconfig
>  create mode 100644 drivers/gpu/drm/ivip/Makefile
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_crtc.c
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
>  create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe840..c487507 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -167,6 +167,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
>  
>  source "drivers/gpu/drm/i915/Kconfig"
>  
> +source "drivers/gpu/drm/ivip/Kconfig"
> +
>  config DRM_VGEM
>   tristate "Virtual GEM provider"
>   depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index b9ae428..945cf53 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
>  obj-$(CONFIG_DRM_MGA)+= mga/
>  obj-$(CONFIG_DRM_I810)   += i810/
>  obj-$(CONFIG_DRM_I915)   += i915/
> +obj-$(CONFIG_DRM_IVIP)   += ivip/
>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
>  obj-$(CONFIG_DRM_VC4)  += vc4/
>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
> diff --git a/drivers/gpu/drm/ivip/Kconfig
> b/drivers/gpu/drm/ivip/Kconfig
> new file mode 100644
> index 000..ddf3cb5
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Kconfig
> @@ -0,0 +1,22 @@
> +config DRM_IVIP
> +tristate "Intel FGPA Video and Image Processing"
> +depends on DRM
> +select DRM_GEM_CMA_HELPER
> +select DRM_KMS_HELPER
> +select DRM_KMS_FB_HELPER
> +select DRM_KMS_CMA_HELPER
> +help
> +Choose this option if you have a Intel FPGA Arria 10
> system
> +and above with a Display Port IP. This does not
> support legacy
> +Intel FPGA Cyclone V display port. Currently only
> single frame
> +buffer is supported. Note that ACPI and X_86
> architecture is yet
> +to be supported.
> +
> +config DRM_IVIP_OF
> +tristate "Intel FGPA Video and Image Processing Open
> Firmware Systems"
> +depends on DRM_IVIP && OF
> +help
> +Choose this option if the Intel FPGA system is using
> Open
> +Firmware systems (Arria 10). If M is selected the
> module would
> +be called ivip.
> +
> diff --git a/drivers/gpu/drm/ivip/Makefile
> b/drivers/gpu/drm/ivip/Makefile
> new file mode 100644
> index 000..7be1e99
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# Makefile for the drm device driver.  This driver provides support
> for the
> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
> +
> +ccflags-y := -Iinclude/drm
> +
> +obj-$(CONFIG_DRM_IVIP_OF) += ivip.o
> +ivip-objs := intel_vip_of.o intel_vip_core.o \
> +intel_vip_conn.o intel_vip_crtc.o
> diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
> b/drivers/gpu/drm/ivip/intel_vip_conn.c
> new file mode 100644
> index 000..89ab587
> --- /dev/null
> +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
> @@ -0,0 +1,145 @@
> +/*
> + * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
> + * Frame Buffer II driver
> + *
> + * This driver supports the Intel VIP Frame Reader component.
> + * More info on the hardware can be found in the Intel Video
> + * and Image Processing Suite User Guide at this address
> + * http://www.altera.com/literature/ug/ug_vip.pdf.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * 

drm-tip/drm-tip boot: 154 boots: 13 failed, 133 passed with 8 offline (v4.11-rc5-1635-g6732aaa5e8d9)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 154 boots: 13 failed, 133 passed with 8 offline 
(v4.11-rc5-1635-g6732aaa5e8d9)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1635-g6732aaa5e8d9/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1635-g6732aaa5e8d9/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1635-g6732aaa5e8d9
Git Commit: 6732aaa5e8d9f1bfa454efed21a548715b9b07d4
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 20 unique boards, 11 SoC families, 27 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1145-ge7d4ec79b24f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_EFI=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_LKDTM=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1145-ge7d4ec79b24f - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_SMP=n:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc6-1156-g48b47c95517f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1622-gbdea8c440d1d)

Boot Failures Detected:

arm64:

allmodconfig
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
x86-kvm: 1 failed lab

tinyconfig
x86-kvm: 1 failed lab

allmodconfig
x86-kvm: 1 failed lab

allmodconfig+CONFIG_OF=n
x86-kvm: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_EFI=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_LKDTM=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-arndale: 1 failed lab
exynos5250-snow: 1 failed lab
hisi-x5hd2-dkb: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y:
hip04-d01: 1 offline lab

multi_v7_defconfig:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_LKDTM=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_SMP=n:
hip04-d01: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

2017-04-06 Thread jeffy

Hi Sean,

On 04/06/2017 12:28 AM, Sean Paul wrote:

On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:

After unbinding drm, the userspace may still has a chance to access
gem buf.

Add a sanity check for a NULL dev_private to prevent that from
happening.


I still don't understand how this is happening. You're saying that these hooks
can be called after rockchip_drm_unbind() has finished?

yes, tested on chromebook rk3399 kevin with kernel 4.4, if trigger 
unbind without killing display service(ui or frecon):


[   31.276889] [] dump_backtrace+0x0/0x164
[   31.282288] [] show_stack+0x24/0x30
[   31.287338] [] dump_stack+0x98/0xb8
[   31.292389] [] rockchip_gem_create_object+0x6c/0x2ec
[   31.298910] [] 
rockchip_gem_create_with_handle+0x38/0x10c

[   31.305868] [] rockchip_gem_create_ioctl+0x38/0x50
[   31.312221] [] drm_ioctl+0x2bc/0x438
[   31.317359] [] drm_compat_ioctl+0x3c/0x70
[   31.322935] [] compat_SyS_ioctl+0x134/0x1048
[   31.328766] [] __sys_trace_return+0x0/0x4


Sean



Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..205a3dc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;

+   if (!private)
+   return -ENODEV;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)

  static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
  {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->dev_private)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
--
2.1.4






___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip boot: 156 boots: 15 failed, 133 passed with 8 offline (v4.11-rc5-1643-ge087f8395ca3)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 156 boots: 15 failed, 133 passed with 8 offline 
(v4.11-rc5-1643-ge087f8395ca3)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1643-ge087f8395ca3/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1643-ge087f8395ca3/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1643-ge087f8395ca3
Git Commit: e087f8395ca39c6988de8680bd6f80a20b08c0f4
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 22 unique boards, 12 SoC families, 25 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_EFI=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_LKDTM=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1164-g4b60513d8a00 - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_SMP=n:
highbank:
lab-cambridge: new failure (last pass: v4.11-rc5-1632-g7303b362817a)
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc6-1156-g48b47c95517f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1164-g4b60513d8a00 - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

Boot Failures Detected:

arm64:

defconfig+CONFIG_KASAN=y
apm-mustang: 1 failed lab

defconfig+CONFIG_RANDOMIZE_BASE=y
apm-mustang: 1 failed lab

allmodconfig
apm-mustang: 1 failed lab
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
x86-kvm: 1 failed lab

tinyconfig
x86-kvm: 1 failed lab

allmodconfig
x86-kvm: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_EFI=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_LKDTM=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-arndale: 1 failed lab
highbank: 1 failed lab
hisi-x5hd2-dkb: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y:
hip04-d01: 1 offline lab

multi_v7_defconfig:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_LKDTM=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_SMP=n:
hip04-d01: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1643-ge087f8395ca3)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1643-ge087f8395ca3)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1643-ge087f8395ca3/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1643-ge087f8395ca3
Git Commit: e087f8395ca39c6988de8680bd6f80a20b08c0f4
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

drm-tip/drm-tip boot: 123 boots: 12 failed, 103 passed with 8 offline (v4.11-rc5-1632-g7303b362817a)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 123 boots: 12 failed, 103 passed with 8 offline 
(v4.11-rc5-1632-g7303b362817a)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1632-g7303b362817a/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1632-g7303b362817a/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1632-g7303b362817a
Git Commit: 7303b362817aa4b4c62cdc2dfa586c272982917d
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 18 unique boards, 10 SoC families, 24 builds out of 197

Boot Regressions Detected:

arm:

multi_v7_defconfig:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1145-ge7d4ec79b24f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_EFI=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_LKDTM=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1164-g4b60513d8a00 - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_SMP=n:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc6-1156-g48b47c95517f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1622-gbdea8c440d1d)

Boot Failures Detected:

x86:

allnoconfig
x86-kvm: 1 failed lab

tinyconfig
x86-kvm: 1 failed lab

allmodconfig
x86-kvm: 1 failed lab

allmodconfig+CONFIG_OF=n
x86-kvm: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_EFI=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_LKDTM=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-arndale: 1 failed lab
exynos5250-snow: 1 failed lab
hisi-x5hd2-dkb: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y:
hip04-d01: 1 offline lab

multi_v7_defconfig:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_LKDTM=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_SMP=n:
hip04-d01: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 12/12] drm/drm_ioctl.c: Break ioctl when drm device not registered

2017-04-06 Thread Your Name
From: Jeffy Chen 

After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.

Add a sanity check here to prevent that from happening.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

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

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

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7d6deaa..15beb11 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -674,7 +674,7 @@ long drm_ioctl(struct file *filp,
 
dev = file_priv->minor->dev;
 
-   if (drm_device_is_unplugged(dev))
+   if (drm_device_is_unplugged(dev) || !dev->registered)
return -ENODEV;
 
is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1642-gf64b9ef53ade)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings 
(v4.11-rc5-1642-gf64b9ef53ade)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1642-gf64b9ef53ade/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1642-gf64b9ef53ade
Git Commit: f64b9ef53ade03adaee05cae1bbeebb426c8f1fe
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 4 unique architectures

Build Failure Detected:

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig+CONFIG_OF=n: FAIL

Warnings Detected:

arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

defconfig+CONFIG_KASAN=y: 4 warnings

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  

[PATCH v5 00/12] drm: rockchip: Fix rockchip drm unbind crash error

2017-04-06 Thread Jeffy Chen

Verified on rk3399 chromebook kevin:
1/ stop ui && pkill -9 frecon
2/ unbind/bind drm

Changes in v5:
Fix wrong git account.

Changes in v4:
Address Andrzej Hajda 's comments.

Changes in v3:
Update commit message.
Address Sean Paul 's comments.
Update commit message.
Address Sean Paul 's comments.
Update commit message.
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2:
Fix some commit messages.

Jeffy Chen (12):
  drm: bridge: analogix: Detach panel when unbinding analogix dp
  drm: bridge: analogix: Unregister dp aux when unbinding
  drm: bridge: analogix: Disable clock when unbinding
  drm: bridge: analogix: Destroy connector & encoder when unbinding
  drm/rockchip: cdn-dp: Don't try to release firmware when not loaded
  drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding
  drm/rockchip: vop: Enable pm domain before vop_initial
  drm/rockchip: vop: Unprepare clocks when unbinding
  drm/rockchip: analogix_dp: Disable clock when unbinding
  drm/rockchip: Reoder drm bind/unbind sequence
  drm/rockchip: Shutdown all crtcs when unbinding drm
  drm/drm_ioctl.c: Break ioctl when drm device not registered

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 +++
 drivers/gpu/drm/drm_ioctl.c|  2 +-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c|  3 +-
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 10 +++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 50 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 33 ++
 6 files changed, 67 insertions(+), 37 deletions(-)

-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [PATCH] drm/atomic: Add connector atomic_check function.

2017-04-06 Thread Pandiyan, Dhinakaran
On Wed, 2017-04-05 at 12:06 +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
> > The connector atomic check function may be called multiple times,
> > or not at all. It's mostly useful for implementing properties but if you
> > call check_modeset twice it can be used for other modeset related checks
> > as well.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 25 +
> >  include/drm/drm_modeset_helper_vtables.h | 37 
> > 
> >  2 files changed, 58 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index c3994b4d5f32..d550e79e8347 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
> >   *
> >   * Check the state object to see if the requested state is physically 
> > possible.
> >   * This does all the crtc and connector related computations for an atomic
> > - * update and adds any additional connectors needed for full modesets and 
> > calls
> > - * down into _crtc_helper_funcs.mode_fixup and
> > - * _encoder_helper_funcs.mode_fixup or
> > - * _encoder_helper_funcs.atomic_check functions of the driver backend.
> > + * update and adds any additional connectors needed for full modesets. It 
> > calls
> > + * the various per-object callbacks in the follow order:
> > + *
> > + * 1. _connector_helper_funcs.atomic_best_encoder for determining the 
> > new encoder.
> > + * 2. _connector_helper_funcs.atomic_check to validate the connector 
> > state.
> > + * 3. If it's determined a modeset is needed then all connectors on the 
> > affected crtc
> > + *crtc are added.
Typo - 'crtc' typed twice.

update_output_state which is called before _helper_check_modeset() also
adds all affected connectors. Why is that not considered when you say
affected connectors are added in Step 3? Is that because
update_output_state() is in the legacy modeset path?


> > + * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
> > + * 5. _encoder_helper_funcs.atomic_check is called to validate any 
> > encoder state.
> > + *This function is only called when the encoder will be part of a 
> > configured crtc,
> > + *it must not be used for implementing connector property validation.
> > + *If this function is NULL, 
> > _atomic_encoder_helper_funcs.mode_fixup is called
> > + *instead.
> > + * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
> > with crtc constraints.
> 
> Line too I think. And maybe insert empty lines between each item, to make
> them stand out more. Shouldn't affect rendering, but better to recheck.
> 
> >   *
> >   * _crtc_state.mode_changed is set when the input mode is changed.
> >   * _crtc_state.connectors_changed is set when a connector is added or
> > @@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > return ret;
> >  
> > for_each_oldnew_connector_in_state(state, connector, 
> > old_connector_state, new_connector_state, i) {
> > +   const struct drm_connector_helper_funcs *funcs = 
> > connector->helper_private;
> > +
> > /*
> >  * This only sets crtc->connectors_changed for routing changes,
> >  * drivers must set crtc->connectors_changed themselves when
> > @@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > new_connector_state->link_status)
> > new_crtc_state->connectors_changed = true;
> > }
> > +
> > +   if (funcs->atomic_check)
> > +   ret = funcs->atomic_check(connector, 
> > new_connector_state);
> > +   if (ret)
> > +   return ret;
> > }
> >  
> > /*
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index b304950b402d..7b5dd909f189 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_check:
> > +*
> > +* Drivers should check connector properties in this
> > +* hook. This function is called from _atomic_helper_check_modeset.
> > +*
> > +* This function may not be called at all on a modeset or connector
> > +* change, so it should only be used to validate properties.

I did not understand this part - "function may not be called at all on a
modeset or connector change". Why is that?

> > +* If it's required to 

Re: [Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLLl

2017-04-06 Thread David Tribe


Sent from my iPhone
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/5] i915: initialize the free_list of the fencing atomic_helper

2017-04-06 Thread Andrea Arcangeli
Just in case the llist model changes and NULL isn't valid
initialization.

Signed-off-by: Andrea Arcangeli 
---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ed1f4f2..24f303e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16630,6 +16630,7 @@ int intel_modeset_init(struct drm_device *dev)
 
dev->mode_config.funcs = _mode_funcs;
 
+   init_llist_head(_priv->atomic_helper.free_list);
INIT_WORK(_priv->atomic_helper.free_work,
  intel_atomic_helper_free_state_worker);
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 02/12] drm: bridge: analogix: Unregister dp aux when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

The dp aux is registered when binding analogix dp.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Your Name 
---

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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 28144a1..7b75f82 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1447,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
DRM_ERROR("failed to detach the panel\n");
}
 
+   drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 08/12] drm/rockchip: vop: Unprepare clocks when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

The clocks are prepared when binding vop.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

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

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b65b296..3f7a82d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1634,6 +1634,10 @@ static void vop_unbind(struct device *dev, struct device 
*master, void *data)
 
pm_runtime_disable(dev);
vop_destroy_crtc(vop);
+
+   clk_unprepare(vop->aclk);
+   clk_unprepare(vop->hclk);
+   clk_unprepare(vop->dclk);
 }
 
 const struct component_ops vop_component_ops = {
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid

2017-04-06 Thread jeffy

Hi Daniel,

On 04/06/2017 04:26 PM, Daniel Vetter wrote:

On Wed, Apr 05, 2017 at 12:28:40PM -0400, Sean Paul wrote:

On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote:

After unbinding drm, the userspace may still has a chance to access
gem buf.

Add a sanity check for a NULL dev_private to prevent that from
happening.


I still don't understand how this is happening. You're saying that these hooks
can be called after rockchip_drm_unbind() has finished?


Yeah this is supposed to be impossible. If it isn't, we need to debug and
fix this properly. This smells like pretty bad duct-tape ...


it looks like after unbind, the user space may still own drm dev fd, and 
could be able to call ioctl:

lrwx--. 1 chronos chronos 64 Mar 15 12:53 28 -> /dev/dri/card1 (deleted)

and the drm_unplug_dev may help it, maybe we should call it in unbind? 
or just break drm_ioctl when drm_dev not registered?



-Daniel



Sean



Signed-off-by: Jeffy Chen 
---

Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e570..205a3dc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct 
rockchip_gem_object *rk_obj,
struct drm_device *drm = obj->dev;
struct rockchip_drm_private *private = drm->dev_private;

+   if (!private)
+   return -ENODEV;
+
if (private->domain)
return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap);
else
@@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct 
rockchip_gem_object *rk_obj)

  static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj)
  {
+   struct drm_device *drm = rk_obj->base.dev;
+
+   if (!drm->dev_private)
+   return;
+
if (rk_obj->pages)
rockchip_gem_free_iommu(rk_obj);
else
--
2.1.4



--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 06/12] drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

After snd_soc_unregister_codec, the dai link would remain bound to
the invalid codec. That would cause crashes after unbind dp driver.

Let's unregister audio codec when removing dp driver to prevent that.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

Changes in v4: None
Changes in v3:
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index ee4195d..a2169dd 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1092,8 +1092,6 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
goto err_free_connector;
}
 
-   cdn_dp_audio_codec_init(dp, dev);
-
for (i = 0; i < dp->ports; i++) {
port = dp->port[i];
 
@@ -1128,7 +1126,6 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
struct drm_connector *connector = >connector;
 
cancel_work_sync(>event_work);
-   platform_device_unregister(dp->audio_pdev);
cdn_dp_encoder_disable(encoder);
encoder->funcs->destroy(encoder);
connector->funcs->destroy(connector);
@@ -1221,6 +1218,8 @@ static int cdn_dp_probe(struct platform_device *pdev)
mutex_init(>lock);
dev_set_drvdata(dev, dp);
 
+   cdn_dp_audio_codec_init(dp, dev);
+
return component_add(dev, _dp_component_ops);
 }
 
@@ -1228,6 +1227,7 @@ static int cdn_dp_remove(struct platform_device *pdev)
 {
struct cdn_dp_device *dp = platform_get_drvdata(pdev);
 
+   platform_device_unregister(dp->audio_pdev);
cdn_dp_suspend(dp->dev);
component_del(>dev, _dp_component_ops);
 
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 03/12] drm: bridge: analogix: Disable clock when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

The clock is enabled when binding analogix dp.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7b75f82..d05ade4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1449,6 +1449,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
 
drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
+   clk_disable_unprepare(dp->clock);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
 
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 04/12] drm: bridge: analogix: Destroy connector & encoder when unbinding

2017-04-06 Thread Jeffy Chen
Normally we do this in drm_mode_config_cleanup. But:
1/ analogix dp's connector is allocated in bind, and freed after unbind.
So we need to destroy it in unbind to avoid further access.
2/ the drm bridge is attached in bind, and detached in encoder cleanup.
So we need to destroy encoder in unbind.

Signed-off-by: Jeffy Chen 
---

Changes in v5: None
Changes in v4:
Address Andrzej Hajda 's comments.

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d05ade4..4c758ed 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1439,6 +1439,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+   dp->connector.funcs->destroy(>connector);
+   dp->encoder->funcs->destroy(dp->encoder);
 
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 12/12] drm/drm_ioctl.c: Break ioctl when drm device not registered

2017-04-06 Thread Jeffy Chen
After unbinding drm, the user space may still owns the drm dev fd,
and may still be able to call drm ioctl.

Add a sanity check here to prevent that from happening.

Signed-off-by: Jeffy Chen 
---

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

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

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7d6deaa..15beb11 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -674,7 +674,7 @@ long drm_ioctl(struct file *filp,
 
dev = file_priv->minor->dev;
 
-   if (drm_device_is_unplugged(dev))
+   if (drm_device_is_unplugged(dev) || !dev->registered)
return -ENODEV;
 
is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 3/9] drm: bridge: analogix: Destroy connector when unbinding

2017-04-06 Thread jeffy

Hi Andrzej,

On 04/06/2017 03:19 PM, Andrzej Hajda wrote:

On 05.04.2017 10:29, Jeffy Chen wrote:

Normally we do this in drm_mode_config_cleanup. But analogix dp's
connector is allocated in bind, and freed after unbind. So we need
to destroy it in unbind to avoid further access.

Signed-off-by: Jeffy Chen 


Reviewed-by: Andrzej Hajda 

One comment below


---

Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7b75f82..a96fd55 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1439,6 +1439,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);

analogix_dp_bridge_disable(dp->bridge);


Not related to the patch, but what about bridge,  above it is only
disabled, but not detached, encoder cleanup code should do it but it is
also missing.
right, i should notice there's a drm_encoder_cleanup(dp->encoder) when 
failed to create bridge...thanx for pointing that out :)


Regards
Andrzej


+   dp->connector.funcs->destroy(>connector);

if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))









___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip boot: 157 boots: 15 failed, 134 passed with 8 offline (v4.11-rc5-1642-gf64b9ef53ade)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip boot: 157 boots: 15 failed, 134 passed with 8 offline 
(v4.11-rc5-1642-gf64b9ef53ade)

Full Boot Summary: 
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1642-gf64b9ef53ade/
Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1642-gf64b9ef53ade/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1642-gf64b9ef53ade
Git Commit: f64b9ef53ade03adaee05cae1bbeebb426c8f1fe
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Tested: 22 unique boards, 12 SoC families, 26 builds out of 207

Boot Regressions Detected:

arm:

multi_v7_defconfig:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_EFI=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_LKDTM=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1164-g4b60513d8a00 - first fail: v4.11-rc5-1620-g0a7572e89d6f)

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
exynos5422-odroidxu3:
lab-collabora: new failure (last pass: v4.11-rc5-1635-g6732aaa5e8d9)
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1276-g2bcf98e5debf - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_SMP=n:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc6-1156-g48b47c95517f - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hisi-x5hd2-dkb:
lab-cambridge: failing since 1 day (last pass: 
v4.10-rc7-1164-g4b60513d8a00 - first fail: v4.11-rc5-1590-gbf30bc2a70b8)

Boot Failures Detected:

arm64:

defconfig+CONFIG_KASAN=y
apm-mustang: 1 failed lab

defconfig+CONFIG_RANDOMIZE_BASE=y
apm-mustang: 1 failed lab

allmodconfig
apm-mustang: 1 failed lab
meson-gxbb-p200: 1 failed lab

x86:

allnoconfig
x86-kvm: 1 failed lab

tinyconfig
x86-kvm: 1 failed lab

allmodconfig
x86-kvm: 1 failed lab

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_EFI=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
exynos5422-odroidxu3: 1 failed lab
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_LKDTM=y
hisi-x5hd2-dkb: 1 failed lab

multi_v7_defconfig+CONFIG_SMP=n
exynos5250-snow: 1 failed lab
hisi-x5hd2-dkb: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y:
hip04-d01: 1 offline lab

multi_v7_defconfig:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_LKDTM=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_ARM_LPAE=y:
hip04-d01: 1 offline lab

multi_v7_defconfig+CONFIG_SMP=n:
hip04-d01: 1 offline lab

---
For more info write to 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 02/12] drm: bridge: analogix: Unregister dp aux when unbinding

2017-04-06 Thread Jeffy Chen
The dp aux is registered when binding analogix dp.

Signed-off-by: Jeffy Chen 
Reviewed-by: Andrzej Hajda 
---

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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 28144a1..7b75f82 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1447,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
DRM_ERROR("failed to detach the panel\n");
}
 
+   drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 11/12] drm/rockchip: Shutdown all crtcs when unbinding drm

2017-04-06 Thread Your Name
From: Jeffy Chen 

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

Changes in v4: None
Changes in v3:
Address Daniel Vetter 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f24968f..c6b1b7f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -199,6 +199,7 @@ static void rockchip_drm_unbind(struct device *dev)
rockchip_drm_fbdev_fini(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
 
+   drm_atomic_helper_shutdown(drm_dev);
drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
drm_mode_config_cleanup(drm_dev);
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm-tip/drm-tip build: 197 builds: 0 failed, 197 passed, 202 warnings (v4.11-rc5-1632-g7303b362817a)

2017-04-06 Thread kernelci . org bot
drm-tip/drm-tip build: 197 builds: 0 failed, 197 passed, 202 warnings 
(v4.11-rc5-1632-g7303b362817a)

Full Build Summary: 
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1632-g7303b362817a/

Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc5-1632-g7303b362817a
Git Commit: 7303b362817aa4b4c62cdc2dfa586c272982917d
Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git
Built: 3 unique architectures

Warnings Detected:

arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)

imx_v6_v7_defconfig: 1 warning
multi_v7_defconfig: 4 warnings
multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y: 4 warnings
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings
multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings
multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings
multi_v7_defconfig+CONFIG_SMP=n: 4 warnings
multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 
warnings

mips:gcc version 6.3.0 (GCC)

allnoconfig: 1 warning
ar7_defconfig: 2 warnings
ath25_defconfig: 2 warnings
ath79_defconfig: 2 warnings
bcm47xx_defconfig: 2 warnings
bcm63xx_defconfig: 1 warning
bigsur_defconfig: 6 warnings
bmips_be_defconfig: 1 warning
bmips_stb_defconfig: 1 warning
capcella_defconfig: 2 warnings
cavium_octeon_defconfig: 6 warnings
ci20_defconfig: 1 warning
cobalt_defconfig: 2 warnings
db1xxx_defconfig: 1 warning
decstation_defconfig: 2 warnings
defconfig+CONFIG_LKDTM=y: 2 warnings
e55_defconfig: 2 warnings
fuloong2e_defconfig: 6 warnings
generic_defconfig: 3 warnings
gpr_defconfig: 2 warnings
ip22_defconfig: 2 warnings
ip27_defconfig: 6 warnings
ip28_defconfig: 6 warnings
ip32_defconfig: 6 warnings
jazz_defconfig: 2 warnings
jmr3927_defconfig: 1 warning
lasat_defconfig: 1 warning
lemote2f_defconfig: 6 warnings
loongson1b_defconfig: 2 warnings
loongson1c_defconfig: 2 warnings
loongson3_defconfig: 6 warnings
malta_defconfig: 2 warnings
malta_kvm_defconfig: 2 warnings
malta_kvm_guest_defconfig: 2 warnings
malta_qemu_32r6_defconfig: 2 warnings
maltaaprp_defconfig: 2 warnings
maltasmvp_defconfig: 2 warnings
maltasmvp_eva_defconfig: 2 warnings
maltaup_defconfig: 2 warnings
maltaup_xpa_defconfig: 2 warnings
markeins_defconfig: 2 warnings
mips_paravirt_defconfig: 6 warnings
mpc30x_defconfig: 2 warnings
msp71xx_defconfig: 2 warnings
mtx1_defconfig: 2 warnings
nlm_xlp_defconfig: 6 warnings
nlm_xlr_defconfig: 2 warnings
pic32mzda_defconfig: 2 warnings
pistachio_defconfig: 2 warnings
pnx8335_stb225_defconfig: 2 warnings
qi_lb60_defconfig: 2 warnings
rb532_defconfig: 2 warnings
rbtx49xx_defconfig: 2 warnings
rm200_defconfig: 2 warnings
rt305x_defconfig: 2 warnings
sb1250_swarm_defconfig: 4 warnings
tb0219_defconfig: 2 warnings
tb0226_defconfig: 2 warnings
tb0287_defconfig: 2 warnings
tinyconfig: 1 warning
workpad_defconfig: 2 warnings
xilfpga_defconfig: 1 warning
xway_defconfig: 2 warnings

x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

allmodconfig: 1 warning
defconfig+CONFIG_KASAN=y: 5 warnings


Warnings summary:

159  :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
  9  arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' 
invalid for ROCKCHIP_INNO_HDMI
  9  arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_MIPI_DSI
  9  arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' 
invalid for ROCKCHIP_DW_HDMI
  9  arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' 
invalid for ROCKCHIP_ANALOGIX_DP
  2  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning: 
'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
  1  net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes 
is larger than 2048 bytes [-Wframe-larger-than=]
  1  drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 
bytes is larger than 2048 bytes [-Wframe-larger-than=]



Detailed per-defconfig build reports:


acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches


[PATCH v5 05/12] drm/rockchip: cdn-dp: Don't try to release firmware when not loaded

2017-04-06 Thread Jeffy Chen
Signed-off-by: Jeffy Chen 
---

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

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 4e55d63..ee4195d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1053,6 +1053,7 @@ static int cdn_dp_bind(struct device *dev, struct device 
*master, void *data)
dp->connected = false;
dp->active = false;
dp->active_port = -1;
+   dp->fw_loaded = false;
 
INIT_WORK(>event_work, cdn_dp_pd_event_work);
 
@@ -1133,7 +1134,8 @@ static void cdn_dp_unbind(struct device *dev, struct 
device *master, void *data)
connector->funcs->destroy(connector);
 
pm_runtime_disable(dev);
-   release_firmware(dp->fw);
+   if (dp->fw_loaded)
+   release_firmware(dp->fw);
kfree(dp->edid);
dp->edid = NULL;
 }
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/9] drm: bridge: analogix: Unregister dp aux when unbinding

2017-04-06 Thread jeffy

Hi Andrzej,

On 04/06/2017 03:11 PM, Andrzej Hajda wrote:

On 05.04.2017 10:29, Jeffy Chen wrote:

The dp aux is registered when binding analogix dp.

Signed-off-by: Jeffy Chen 

Reviewed-by: Andrzej Hajda 

Btw, if you are working already in this area you can check also to
analogix_dp bind and unbind routines they looks suspiciously asymmetric.
I guess component framework deals correctly with devm_* stuff but I see
for example clk_prepare_enable not paired with clk_unprepare*.

ok, well do...


--
Regards
Andrzej

---

Changes in v3: None
Changes in v2: None

  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 28144a1..7b75f82 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1447,6 +1447,7 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
DRM_ERROR("failed to detach the panel\n");
}

+   drm_dp_aux_unregister(>aux);
pm_runtime_disable(dev);
  }
  EXPORT_SYMBOL_GPL(analogix_dp_unbind);









___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats

2017-04-06 Thread Laurent Vivier
On 05/04/2017 19:11, Ville Syrjälä wrote:
> On Wed, Apr 05, 2017 at 10:09:15AM +0200, Laurent Vivier wrote:
>> When we use virtio-vga with a big-endian guest,
>> the mouse pointer disappears.
>>
>> To fix that, on big-endian use DRM_FORMAT_BGRA
>> instead of DRM_FORMAT_ARGB.
>>
>> Signed-off-by: Laurent Vivier 
>> ---
>>  drivers/gpu/drm/virtio/virtgpu_plane.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
>> b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> index 11288ff..3ed7174 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> @@ -39,7 +39,11 @@ static const uint32_t virtio_gpu_formats[] = {
>>  };
>>  
>>  static const uint32_t virtio_gpu_cursor_formats[] = {
>> +#ifdef __BIG_ENDIAN
>> +DRM_FORMAT_BGRA,
>> +#else
>>  DRM_FORMAT_ARGB,
>> +#endif
> 
> DRM formats are supposed to be little endian, so this isn't really
> correct.

In a big endian kernel, we need to swap the bytes order, where do you
think is the best place to do that?

Thanks,
Laurent
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] [PATCH] drm/atomic: Add connector atomic_check function.

2017-04-06 Thread Dhinakaran Pandiyan
On Thu, Apr 6, 2017 at 12:34 AM Maarten Lankhorst <
maarten.lankho...@linux.intel.com> wrote:

> Op 06-04-17 om 03:27 schreef Pandiyan, Dhinakaran:
> > On Wed, 2017-04-05 at 12:06 +0200, Daniel Vetter wrote:
> >> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
> >>> The connector atomic check function may be called multiple times,
> >>> or not at all. It's mostly useful for implementing properties but if
> you
> >>> call check_modeset twice it can be used for other modeset related
> checks
> >>> as well.
> >>>
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>>  drivers/gpu/drm/drm_atomic_helper.c  | 25 +
> >>>  include/drm/drm_modeset_helper_vtables.h | 37
> 
> >>>  2 files changed, 58 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> >>> index c3994b4d5f32..d550e79e8347 100644
> >>> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >>> @@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
> >>>   *
> >>>   * Check the state object to see if the requested state is physically
> possible.
> >>>   * This does all the crtc and connector related computations for an
> atomic
> >>> - * update and adds any additional connectors needed for full modesets
> and calls
> >>> - * down into _crtc_helper_funcs.mode_fixup and
> >>> - * _encoder_helper_funcs.mode_fixup or
> >>> - * _encoder_helper_funcs.atomic_check functions of the driver
> backend.
> >>> + * update and adds any additional connectors needed for full
> modesets. It calls
> >>> + * the various per-object callbacks in the follow order:
> >>> + *
> >>> + * 1. _connector_helper_funcs.atomic_best_encoder for determining
> the new encoder.
> >>> + * 2. _connector_helper_funcs.atomic_check to validate the
> connector state.
> >>> + * 3. If it's determined a modeset is needed then all connectors on
> the affected crtc
> >>> + *crtc are added.
> > Typo - 'crtc' typed twice.
> >
> > update_output_state which is called before _helper_check_modeset() also
> > adds all affected connectors. Why is that not considered when you say
> > affected connectors are added in Step 3? Is that because
> > update_output_state() is in the legacy modeset path?
> Yes. update_output_state is just a legacy function.
>
> When a crtc is cloned, a atomic update may only disable 1 connector and
> leave the other one enabled. In this case there's a modeset
> but all connectors are not checked yet.
>
> Similar for changing crtc_state->active, which may also result in a
> modeset with no connectors added yet.
> >
> >>> + * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
> >>> + * 5. _encoder_helper_funcs.atomic_check is called to validate
> any encoder state.
> >>> + *This function is only called when the encoder will be part of a
> configured crtc,
> >>> + *it must not be used for implementing connector property
> validation.
> >>> + *If this function is NULL,
> _atomic_encoder_helper_funcs.mode_fixup is called
> >>> + *instead.
> >>> + * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the
> mode with crtc constraints.
> >> Line too I think. And maybe insert empty lines between each item, to
> make
> >> them stand out more. Shouldn't affect rendering, but better to recheck.
> >>
> >>>   *
> >>>   * _crtc_state.mode_changed is set when the input mode is changed.
> >>>   * _crtc_state.connectors_changed is set when a connector is
> added or
> >>> @@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device
> *dev,
> >>> return ret;
> >>>
> >>> for_each_oldnew_connector_in_state(state, connector,
> old_connector_state, new_connector_state, i) {
> >>> +   const struct drm_connector_helper_funcs *funcs =
> connector->helper_private;
> >>> +
> >>> /*
> >>>  * This only sets crtc->connectors_changed for routing
> changes,
> >>>  * drivers must set crtc->connectors_changed themselves
> when
> >>> @@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device
> *dev,
> >>> new_connector_state->link_status)
> >>> new_crtc_state->connectors_changed = true;
> >>> }
> >>> +
> >>> +   if (funcs->atomic_check)
> >>> +   ret = funcs->atomic_check(connector,
> new_connector_state);
> >>> +   if (ret)
> >>> +   return ret;
> >>> }
> >>>
> >>> /*
> >>> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> >>> index b304950b402d..7b5dd909f189 100644
> >>> --- a/include/drm/drm_modeset_helper_vtables.h
> >>> +++ b/include/drm/drm_modeset_helper_vtables.h
> >>> @@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
> >>>  */
> >>> struct drm_encoder 

[PATCH v4 10/12] drm/rockchip: Reoder drm bind/unbind sequence

2017-04-06 Thread Your Name
From: Jeffy Chen 

Current drm bind/unbind sequence would cause some memory issues.
For example we should not cleanup iommu before cleanup mode config.

Reorder bind/unbind sequence, follow exynos drm.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

Changes in v4: None
Changes in v3:
Address Sean Paul 's comments.
Update commit message.

Changes in v2: None

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 49 +++--
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index cd7d02e1..f24968f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -136,21 +136,24 @@ static int rockchip_drm_bind(struct device *dev)
INIT_LIST_HEAD(>psr_list);
spin_lock_init(>psr_list_lock);
 
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
+   goto err_free;
+
drm_mode_config_init(drm_dev);
 
rockchip_drm_mode_config_init(drm_dev);
 
-   ret = rockchip_drm_init_iommu(drm_dev);
-   if (ret)
-   goto err_config_cleanup;
-
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
if (ret)
-   goto err_iommu_cleanup;
+   goto err_mode_config_cleanup;
 
-   /* init kms poll for handling hpd */
-   drm_kms_helper_poll_init(drm_dev);
+   ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
+   if (ret)
+   goto err_unbind_all;
+
+   drm_mode_config_reset(drm_dev);
 
/*
 * enable drm irq mode.
@@ -158,15 +161,12 @@ static int rockchip_drm_bind(struct device *dev)
 */
drm_dev->irq_enabled = true;
 
-   ret = drm_vblank_init(drm_dev, ROCKCHIP_MAX_CRTC);
-   if (ret)
-   goto err_kms_helper_poll_fini;
-
-   drm_mode_config_reset(drm_dev);
+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(drm_dev);
 
ret = rockchip_drm_fbdev_init(drm_dev);
if (ret)
-   goto err_vblank_cleanup;
+   goto err_kms_helper_poll_fini;
 
ret = drm_dev_register(drm_dev, 0);
if (ret)
@@ -175,17 +175,17 @@ static int rockchip_drm_bind(struct device *dev)
return 0;
 err_fbdev_fini:
rockchip_drm_fbdev_fini(drm_dev);
-err_vblank_cleanup:
-   drm_vblank_cleanup(drm_dev);
 err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
+   drm_vblank_cleanup(drm_dev);
+err_unbind_all:
component_unbind_all(dev, drm_dev);
-err_iommu_cleanup:
-   rockchip_iommu_cleanup(drm_dev);
-err_config_cleanup:
+err_mode_config_cleanup:
drm_mode_config_cleanup(drm_dev);
-   drm_dev->dev_private = NULL;
+   rockchip_iommu_cleanup(drm_dev);
 err_free:
+   drm_dev->dev_private = NULL;
+   dev_set_drvdata(dev, NULL);
drm_dev_unref(drm_dev);
return ret;
 }
@@ -194,16 +194,19 @@ static void rockchip_drm_unbind(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
 
+   drm_dev_unregister(drm_dev);
+
rockchip_drm_fbdev_fini(drm_dev);
-   drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
+
+   drm_vblank_cleanup(drm_dev);
component_unbind_all(dev, drm_dev);
-   rockchip_iommu_cleanup(drm_dev);
drm_mode_config_cleanup(drm_dev);
+   rockchip_iommu_cleanup(drm_dev);
+
drm_dev->dev_private = NULL;
-   drm_dev_unregister(drm_dev);
-   drm_dev_unref(drm_dev);
dev_set_drvdata(dev, NULL);
+   drm_dev_unref(drm_dev);
 }
 
 static void rockchip_drm_lastclose(struct drm_device *dev)
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 09/12] drm/rockchip: analogix_dp: Disable clock when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

The clock is enabled when binding cdn dp.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

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

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 91ebe5c..c3b9f1d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -417,7 +417,8 @@ static void rockchip_dp_unbind(struct device *dev, struct 
device *master,
 
rockchip_drm_psr_unregister(>encoder);
 
-   return analogix_dp_unbind(dev, master, data);
+   analogix_dp_unbind(dev, master, data);
+   clk_disable_unprepare(dp->pclk);
 }
 
 static const struct component_ops rockchip_dp_component_ops = {
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 04/12] drm: bridge: analogix: Destroy connector & encoder when unbinding

2017-04-06 Thread Your Name
From: Jeffy Chen 

Normally we do this in drm_mode_config_cleanup. But:
1/ analogix dp's connector is allocated in bind, and freed after unbind.
So we need to destroy it in unbind to avoid further access.
2/ the drm bridge is attached in bind, and detached in encoder cleanup.
So we need to destroy encoder in unbind.

Signed-off-by: Jeffy Chen 
Signed-off-by: Your Name 
---

Changes in v4:
Address Andrzej Hajda 's comments.

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d05ade4..4c758ed 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1439,6 +1439,8 @@ void analogix_dp_unbind(struct device *dev, struct device 
*master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+   dp->connector.funcs->destroy(>connector);
+   dp->encoder->funcs->destroy(dp->encoder);
 
if (dp->plat_data->panel) {
if (drm_panel_unprepare(dp->plat_data->panel))
-- 
2.1.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC PATCH 0/2] dmabuf import interfaces for vgem

2017-04-06 Thread Laura Abbott
Hi,

Ion[1] is making progress towards moving out of staging. I'd like to take
advantage of the vgem driver for development of unit tests for Ion. To
do this properly, vgem needs to support importing of foreign handles. This
is an RFC to add that support. This passes the existing vgem_basic unit
test. I plan to extend that test with support for testing import as well.
RFC is for general direction and feedback since I'm not that familiar with
DRM internals.

Thanks,
Laura

[1] lkml.kernel.org/r/<1491245884-15852-1-git-send-email-labb...@redhat.com>

Laura Abbott (2):
  drm/vgem: Add a dummy platform device
  drm/vgem: Enable dmabuf import interfaces

 drivers/gpu/drm/vgem/vgem_drv.c | 147 
 drivers/gpu/drm/vgem/vgem_drv.h |   3 +
 2 files changed, 122 insertions(+), 28 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC PATCH 2/2] drm/vgem: Enable dmabuf import interfaces

2017-04-06 Thread Laura Abbott

Enable the GEM dma-buf import interfaces in addition to the export
interfaces. This lets vgem be used as a test source for other allocators
(e.g. Ion).

Signed-off-by: Laura Abbott 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 135 
 drivers/gpu/drm/vgem/vgem_drv.h |   3 +
 2 files changed, 111 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index b94feef..abc72e1 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -34,6 +34,9 @@
 #include 
 #include 
 #include 
+
+#include 
+
 #include "vgem_drv.h"
 
 #define DRIVER_NAME"vgem"
@@ -42,40 +45,67 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+#define VGEM_BO_IMPORT BIT(0)
+
+void vgem_gem_put_pages(struct drm_vgem_gem_object *obj)
+{
+   drm_gem_put_pages(>base, obj->pages, false, false);
+   obj->pages = NULL;
+}
+
 static void vgem_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
 
+   if (vgem_obj->pages) {
+   if (vgem_obj->flags & VGEM_BO_IMPORT)
+   drm_free_large(vgem_obj->pages);
+   else
+   vgem_gem_put_pages(vgem_obj);
+   }
+
+   if (obj->import_attach)
+   drm_prime_gem_destroy(obj, vgem_obj->table);
+
drm_gem_object_release(obj);
kfree(vgem_obj);
 }
 
+int vgem_gem_get_pages(struct drm_vgem_gem_object *obj)
+{
+   struct page **pages;
+
+   if (obj->pages)
+   return 0;
+
+   pages = drm_gem_get_pages(>base);
+   if (IS_ERR(pages)) {
+   return PTR_ERR(pages);
+   }
+
+   obj->pages = pages;
+
+   return 0;
+}
+
 static int vgem_gem_fault(struct vm_fault *vmf)
 {
struct vm_area_struct *vma = vmf->vma;
struct drm_vgem_gem_object *obj = vma->vm_private_data;
/* We don't use vmf->pgoff since that has the fake offset */
unsigned long vaddr = vmf->address;
-   struct page *page;
+   loff_t num_pages;
+   pgoff_t page_offset;
+   page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
 
-   page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
-  (vaddr - vma->vm_start) >> PAGE_SHIFT);
-   if (!IS_ERR(page)) {
-   vmf->page = page;
-   return 0;
-   } else switch (PTR_ERR(page)) {
-   case -ENOSPC:
-   case -ENOMEM:
-   return VM_FAULT_OOM;
-   case -EBUSY:
-   return VM_FAULT_RETRY;
-   case -EFAULT:
-   case -EINVAL:
-   return VM_FAULT_SIGBUS;
-   default:
-   WARN_ON_ONCE(PTR_ERR(page));
-   return VM_FAULT_SIGBUS;
-   }
+   num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
+
+   if (page_offset > num_pages)
+   return VM_FAULT_SIGBUS;
+
+   get_page(obj->pages[page_offset]);
+   vmf->page = obj->pages[page_offset];
+   return 0;
 }
 
 static const struct vm_operations_struct vgem_gem_vm_ops = {
@@ -112,7 +142,30 @@ static void vgem_preclose(struct drm_device *dev, struct 
drm_file *file)
kfree(vfile);
 }
 
-/* ioctls */
+static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
+   unsigned long size)
+{
+   struct drm_vgem_gem_object *obj;
+   int ret;
+
+   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
+   if (ret) {
+   kfree(obj);
+   return ERR_PTR(ret);
+   }
+
+   return obj;
+}
+
+static void __vgem_gem_destroy(struct drm_vgem_gem_object *obj)
+{
+   drm_gem_object_release(>base);
+   kfree(obj);
+}
 
 static struct drm_gem_object *vgem_gem_create(struct drm_device *dev,
  struct drm_file *file,
@@ -122,24 +175,25 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
struct drm_vgem_gem_object *obj;
int ret;
 
-   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
-   if (!obj)
-   return ERR_PTR(-ENOMEM);
+   obj = __vgem_gem_create(dev, size);
+   if (IS_ERR(obj))
+   return ERR_CAST(obj);
 
-   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
+   ret = vgem_gem_get_pages(obj);
if (ret)
goto err_free;
 
ret = drm_gem_handle_create(file, >base, handle);
drm_gem_object_unreference_unlocked(>base);
if (ret)
-   goto err;
+   goto err_pages;
 
return >base;
 
+err_pages:
+   vgem_gem_put_pages(obj);
 err_free:
-   kfree(obj);
-err:
+   

[RFC PATCH 1/2] drm/vgem: Add a dummy platform device

2017-04-06 Thread Laura Abbott
The vgem driver is currently registered independent of any actual
device. Some usage of the dmabuf APIs require an actual device structure
to do anything. Register a dummy platform device for use with dmabuf.

Signed-off-by: Laura Abbott 
---
I realize the original driver had a note about 'drop platform support'. I
strongly dislike platform devices but they are the easiest way to get a device
structure for use with APIs like dmabuf.
---
 drivers/gpu/drm/vgem/vgem_drv.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index a1f42d1..b94feef 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -329,12 +329,19 @@ static struct drm_driver vgem_driver = {
 };
 
 static struct drm_device *vgem_device;
+static struct platform_device *vgem_pdev;
 
 static int __init vgem_init(void)
 {
int ret;
 
-   vgem_device = drm_dev_alloc(_driver, NULL);
+   vgem_pdev = platform_device_register_simple("vgem", -1, NULL, 0);
+   if (IS_ERR(vgem_pdev))
+   return PTR_ERR(vgem_pdev);
+
+   dma_coerce_mask_and_coherent(_pdev->dev, DMA_BIT_MASK(64));
+
+   vgem_device = drm_dev_alloc(_driver, _pdev->dev);
if (IS_ERR(vgem_device)) {
ret = PTR_ERR(vgem_device);
goto out;
@@ -349,6 +356,8 @@ static int __init vgem_init(void)
 out_unref:
drm_dev_unref(vgem_device);
 out:
+   platform_device_unregister(vgem_pdev);
+
return ret;
 }
 
@@ -356,6 +365,7 @@ static void __exit vgem_exit(void)
 {
drm_dev_unregister(vgem_device);
drm_dev_unref(vgem_device);
+   platform_device_unregister(vgem_pdev);
 }
 
 module_init(vgem_init);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[GIT PULL] drm/tegra: Changes for v4.12-rc1

2017-04-06 Thread Thierry Reding
Hi Dave,

The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c:

  Linux 4.11-rc3 (2017-03-19 19:09:39 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.12-rc1

for you to fetch changes up to b0d36daa0ab54714e05164f6e21d22f974a5eec1:

  gpu: host1x: Fix host1x driver shutdown (2017-04-05 18:11:50 +0200)

Note that this pulls in a branch from Joerg's IOMMU tree that is required
to resolve some build time dependencies. I've included it in the diffstat
below.

Thierry


drm/tegra: Changes for v4.12-rc1

This contains various fixes to the host1x driver as well as a plug for a
leak of kernel pointers to userspace.

A fairly big addition this time around is the Video Image Composer (VIC)
support that can be used to accelerate some 2D and image compositing
operations.

Furthermore the driver now supports FB modifiers, so we no longer rely
on a custom IOCTL to set those.

Finally this contains a few preparatory patches for Tegra186 support
which unfortunately didn't quite make it this time, but will hopefully
be ready for v4.13.


Alexandre Courbot (1):
  drm/tegra: Add tiling FB modifiers

Arto Merilainen (2):
  drm/tegra: Add falcon helper library
  drm/tegra: Add VIC support

Joerg Roedel (1):
  iommu/iova: Fix compile error with CONFIG_IOMMU_IOVA=m

Marek Szyprowski (1):
  iommu/iova: Consolidate code for adding new node to iovad domain rbtree

Mikko Perttunen (3):
  gpu: host1x: Add IOMMU support
  drm/tegra: Add Tegra DRM allocation API
  dt-bindings: Add bindings for the Tegra VIC

Thierry Reding (10):
  MAINTAINERS: Add related headers to IOMMU section
  iommu: Add dummy implementations for !IOMMU_IOVA
  Merge branch 'core' of git://git.kernel.org/.../joro/iommu into 
drm/tegra/for-next
  gpu: host1x: Fix potential out-of-bounds access
  drm/tegra: Enable IOVA API when IOMMU support is enabled
  drm/tegra: Protect IOMMU operations by mutex
  drm/tegra: Don't leak kernel pointer to userspace
  gpu: host1x: Sort includes alphabetically
  gpu: host1x: Support module reset
  gpu: host1x: Fix host1x driver shutdown

 .../display/tegra/nvidia,tegra20-host1x.txt|  13 +
 MAINTAINERS|   2 +
 drivers/gpu/drm/tegra/Kconfig  |   1 +
 drivers/gpu/drm/tegra/Makefile |   4 +-
 drivers/gpu/drm/tegra/drm.c| 283 ---
 drivers/gpu/drm/tegra/drm.h|  15 +-
 drivers/gpu/drm/tegra/falcon.c | 259 ++
 drivers/gpu/drm/tegra/falcon.h | 127 +++
 drivers/gpu/drm/tegra/fb.c |  23 +-
 drivers/gpu/drm/tegra/gem.c|  12 +-
 drivers/gpu/drm/tegra/vic.c| 396 +
 drivers/gpu/drm/tegra/vic.h|  31 ++
 drivers/gpu/host1x/bus.c   |  68 ++--
 drivers/gpu/host1x/cdma.c  |  74 +++-
 drivers/gpu/host1x/cdma.h  |   6 +-
 drivers/gpu/host1x/dev.c   |  76 +++-
 drivers/gpu/host1x/dev.h   |  14 +-
 drivers/gpu/host1x/hw/cdma_hw.c|  16 +-
 drivers/gpu/host1x/job.c   |  72 +++-
 drivers/gpu/host1x/job.h   |   1 +
 drivers/gpu/host1x/syncpt.c|   2 +-
 drivers/iommu/iova.c   |  87 ++---
 include/linux/host1x.h |   1 +
 include/linux/iova.h   |  91 +
 include/uapi/drm/drm_fourcc.h  |  45 +++
 25 files changed, 1517 insertions(+), 202 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/falcon.c
 create mode 100644 drivers/gpu/drm/tegra/falcon.h
 create mode 100644 drivers/gpu/drm/tegra/vic.c
 create mode 100644 drivers/gpu/drm/tegra/vic.h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] devicetree: add vendor prefix for Winstar Display Corp.

2017-04-06 Thread Thierry Reding
On Fri, Mar 03, 2017 at 04:21:55PM +0100, Richard Genoud wrote:
> Winstar Display Corp. is specialized in LCD displays for embedded
> products.
> cf: http://www.winstar.com.tw
> 
> Signed-off-by: Richard Genoud 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 2/2] drm/panel: Add driver for sitronix ST7789V LCD controller

2017-04-06 Thread Thierry Reding
On Mon, Apr 03, 2017 at 03:38:32PM +0200, Maxime Ripard wrote:
> The Sitronix ST7789v controller is used to drive 240x320 LCD panels through
> various interfaces, including SPI and RGB/Parallel.
> 
> The current driver is configuring it for the latter. Support for tinyDRM
> can always be added later.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/panel/Kconfig  |   7 +-
>  drivers/gpu/drm/panel/Makefile |   1 +-
>  drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 449 ++-
>  3 files changed, 457 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7789v.c

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] dt-bindings: display: panel: Add bindings for the Sitronix ST7789V panel

2017-04-06 Thread Thierry Reding
On Mon, Apr 03, 2017 at 03:38:31PM +0200, Maxime Ripard wrote:
> The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
> can drive 18-bits 240x320 LCD displays.
> 
> Signed-off-by: Maxime Ripard 
> Acked-by: Rob Herring 
> ---
>  Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37 
> +
>  1 file changed, 37 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v11 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

2017-04-06 Thread Thierry Reding
On Wed, Mar 08, 2017 at 10:42:36AM +0900, Hoegeun Kwon wrote:
> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
> driver. This panel has 1440x2560 resolution in 5.7-inch physical
> panel in the TM2 device.
> 
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Tested-by: Chanwoo Choi 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/panel/Kconfig |   6 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 739 
> ++
>  3 files changed, 746 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4] drm: Add DPCD definitions for DP 1.4 DSC feature

2017-04-06 Thread Manasi Navare
Hi Ander,

Could you take a look at this?

Manasi

On Mon, Apr 03, 2017 at 03:51:10PM -0700, Manasi Navare wrote:
> From: "Navare, Manasi D" 
> 
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
> 
> v4:
> * Add DSC Enable DPCD register def (Ander)
> v3:
> * Add some SHIFTS and MASKS for uniformity (Jani Nikula)
> v2:
> * Rebased on drm-tip
> 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Paulo Zanoni 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  include/drm/drm_dp_helper.h | 107 
> 
>  1 file changed, 107 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c0bd0d7..f6258ed 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -179,6 +179,111 @@
>  
>  #define DP_GUID  0x030   /* 1.2 */
>  
> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> +
> +#define DP_DSC_REV  0x061
> +# define DP_DSC_MAJOR_MASK  (0xf << 0)
> +# define DP_DSC_MINOR_MASK  (0xf << 4)
> +# define DP_DSC_MAJOR_SHIFT 0
> +# define DP_DSC_MINOR_SHIFT 4
> +
> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> +
> +#define DP_DSC_RC_BUF_SIZE  0x063
> +
> +#define DP_DSC_SLICE_CAP_1  0x064
> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> +
> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (0xf << 0)
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> +
> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> +
> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> +# define DP_DSC_RGB (1 << 0)
> +# define DP_DSC_YCbCr444(1 << 1)
> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> +# define DP_DSC_YCbCr422_Native (1 << 3)
> +# define DP_DSC_YCbCr420_Native (1 << 4)
> +
> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> +# define DP_DSC_8_BPC   (1 << 1)
> +# define DP_DSC_10_BPC  (1 << 2)
> +# define DP_DSC_12_BPC  (1 << 3)
> +
> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> +# define DP_DSC_THROUGHPUT_MODE_0_MASK  (0xf << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_SHIFT 0
> +# define DP_DSC_THROUGHPUT_MODE_0_340   (1 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_400   (2 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_450   (3 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_500   (4 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_550   (5 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_600   (6 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_650   (7 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_700   (8 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_750   (9 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_800   (10 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_850   (11 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_900   (12 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_950   (13 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_0_1000  (14 << 0)
> +# define DP_DSC_THROUGHPUT_MODE_1_MASK  (0xf << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
> +# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_600 

Re: [PATCH v11 1/3] dt-bindings: Add support for samsung s6e3ha2 panel binding

2017-04-06 Thread Thierry Reding
On Wed, Mar 08, 2017 at 10:42:35AM +0900, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
> 
> Signed-off-by: Donghwa Lee 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Hoegeun Kwon 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Javier Martinez Canillas 
> Acked-by: Rob Herring 
> ---
>  .../bindings/display/panel/samsung,s6e3ha2.txt | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 06/10] drm/panel: simple: Add support for Ampire AM-480272H3TMQW-T01H

2017-04-06 Thread Thierry Reding
On Tue, Mar 28, 2017 at 11:44:49AM +0200, Yannick Fertre wrote:
> Add simple-panel support for the Ampire AM-480272H3TMQW-T01H,
> which is a 4.3" WQVGA panel.
> 
> Signed-off-by: Yannick Fertre 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 29 +
>  1 file changed, 29 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 05/10] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

2017-04-06 Thread Thierry Reding
On Tue, Mar 28, 2017 at 11:44:48AM +0200, Yannick Fertre wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Ampire AM-480272H3TMQW-T01H.
> 
> Acked-by: Rob Herring 
> Signed-off-by: Yannick Fertre 
> ---
>  .../display/panel/ampire,am-480272h3tmqw-t01h.txt  | 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 0/4] drm/atomic: Cleanups for adding connector atomic check function.

2017-04-06 Thread Sean Paul
On Thu, Apr 06, 2017 at 08:48:36AM -0400, Sean Paul wrote:
> On Thu, Apr 06, 2017 at 01:18:59PM +0200, Maarten Lankhorst wrote:
> > Some small cleanups I came across to make drm_atomic_helper_check_modeset
> > more readable.
> > 
> > This makes it a lot more clear what atomic_check does and why it's called in
> > the place it is.
> > 
> > Maarten Lankhorst (4):
> >   drm/atomic: Unify conflicting encoder handling.
> >   drm/atomic: Set all the changed flags in one place.
> >   drm/atomic: Move enable/connector check up in check_modeset()
> >   drm/atomic: Add connector atomic_check function, v2.
> 
> Hi Maarten,
> For the set,
> 
> Reviewed-by: Sean Paul 

Applied to -misc-next with reviews from v1

Sean

> 
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c  | 84 
> > ++--
> >  include/drm/drm_atomic.h |  2 -
> >  include/drm/drm_modeset_helper_vtables.h | 34 +
> >  3 files changed, 93 insertions(+), 27 deletions(-)
> > 
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 0/5] DRM OF graph clean-up

2017-04-06 Thread Sean Paul
On Wed, Mar 22, 2017 at 9:26 AM, Rob Herring  wrote:
> I've been unhappy with the OF graph API for some time and decided to
> do something about it. The problem is drivers have to do too much of the
> graph parsing and walking themselves. This has led to the same pattern
> duplicated over and over. This series adapts DRM drivers to use a new OF
> graph helper and added DRM helper.
>
> The DT dependency went into 4.11, so this series can be applied to the DRM
> tree without any cross tree dependencies.
>
> I've done some build testing only, so testing appreciated. A git branch is
> here[1].
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
> of-graph-helpers
>
>
> Rob Herring (5):
>   drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL
>   drm: of: introduce drm_of_find_panel_or_bridge
>   drm: convert drivers to use of_graph_get_remote_node
>   drm: convert drivers to use drm_of_find_panel_or_bridge
>   drm: omap: use common OF graph helpers
>

Hi Rob,
Thank you for the series, and sorry for the delay. I've fixed the 2
conflicts and applied to -misc-next.

Sean


>  drivers/gpu/drm/arm/hdlcd_drv.c  |  22 +
>  drivers/gpu/drm/arm/malidp_drv.c |  28 +--
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  73 +---
>  drivers/gpu/drm/bridge/adv7511/adv7533.c |  12 +--
>  drivers/gpu/drm/bridge/dumb-vga-dac.c|  15 +---
>  drivers/gpu/drm/bridge/nxp-ptn3460.c |  16 +---
>  drivers/gpu/drm/bridge/parade-ps8622.c   |  16 +---
>  drivers/gpu/drm/bridge/tc358767.c|  27 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c   |  15 ++--
>  drivers/gpu/drm/drm_of.c |  52 
>  drivers/gpu/drm/exynos/exynos_dp.c   |  35 +++-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  16 +---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  13 +--
>  drivers/gpu/drm/exynos/exynos_drm_mic.c  |  25 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c|  39 ++---
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |  27 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |  30 +--
>  drivers/gpu/drm/imx/imx-ldb.c|  27 ++
>  drivers/gpu/drm/imx/parallel-display.c   |  36 +---
>  drivers/gpu/drm/mediatek/mtk_dpi.c   |  12 +--
>  drivers/gpu/drm/mediatek/mtk_dsi.c   |  23 ++---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c  |  26 +-
>  drivers/gpu/drm/meson/meson_venc_cvbs.c  |  19 +
>  drivers/gpu/drm/msm/dsi/dsi_host.c   |   2 +-
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c  |  28 +--
>  drivers/gpu/drm/mxsfb/mxsfb_out.c|  40 ++---
>  drivers/gpu/drm/omapdrm/dss/dpi.c|   2 +-
>  drivers/gpu/drm/omapdrm/dss/dsi.c|   3 +-
>  drivers/gpu/drm/omapdrm/dss/dss-of.c | 102 
> +--
>  drivers/gpu/drm/omapdrm/dss/dss.c|  61 +++---
>  drivers/gpu/drm/omapdrm/dss/hdmi4.c  |   3 +-
>  drivers/gpu/drm/omapdrm/dss/hdmi5.c  |   3 +-
>  drivers/gpu/drm/omapdrm/dss/omapdss.h|  11 ---
>  drivers/gpu/drm/omapdrm/dss/sdi.c|   2 +-
>  drivers/gpu/drm/omapdrm/dss/venc.c   |   3 +-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  |  26 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |  18 ++--
>  drivers/gpu/drm/sun4i/sun4i_rgb.c|  11 +--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   |  90 ++--
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  12 +--
>  drivers/gpu/drm/tilcdc/tilcdc_external.c |  68 ++-
>  drivers/gpu/drm/vc4/vc4_dpi.c|  15 +---
>  include/drm/drm_of.h |  13 +++
>  include/drm/drm_panel.h  |   2 +-
>  44 files changed, 238 insertions(+), 881 deletions(-)
>
> --
> 2.10.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: Take mode_config.mutex in setcrtc ioctl

2017-04-06 Thread Daniel Vetter
On Thu, Apr 06, 2017 at 03:09:04PM -0400, Alex Deucher wrote:
> On Thu, Apr 6, 2017 at 3:06 PM, Daniel Vetter  wrote:
> > Legacy drivers insist that we really take all the locks in this path,
> > and the harm in doing so is minimal.
> >
> > v2: Like git add, it exists :(
> >
> > Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around 
> > ->set_config")
> > Cc: Harry Wentland 
> > Cc: Daniel Vetter 
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Alex Deucher 
> > Reported-by: Alex Deucher 
> > Signed-off-by: Daniel Vetter 
> 
> This actually matches what I tested locally.
> 
> Acked-and-tested-by: Alex Deucher 

Thanks for quickly testing this, applied.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d69e180fc563..5af25ce5bf7c 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -576,6 +576,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> > }
> > DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
> >
> > +   mutex_lock(>dev->mode_config.mutex);
> > drm_modeset_acquire_init(, 0);
> >  retry:
> > ret = drm_modeset_lock_all_ctx(crtc->dev, );
> > @@ -721,6 +722,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> > }
> > drm_modeset_drop_locks();
> > drm_modeset_acquire_fini();
> > +   mutex_unlock(>dev->mode_config.mutex);
> >
> > return ret;
> >  }
> > --
> > 2.11.0
> >

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


[PATCH] drm/vmwgfx: Fix fbdev emulation using legacy functions

2017-04-06 Thread Daniel Vetter
I've broken this by removing the backoff handling from the
set_config2atomic helper in

commit 38b6441e4e75c0b319cfe4d9364c1059fc1e3c2b
Author: Daniel Vetter 
Date:   Wed Mar 22 22:50:58 2017 +0100

drm/atomic-helper: Remove the backoff hack from set_config

Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.

Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.

Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 58 --
 1 file changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index 09e120d50e65..6f4cb4678cbc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -418,6 +418,60 @@ static int vmw_fb_compute_depth(struct fb_var_screeninfo 
*var,
return 0;
 }
 
+static int vmwgfx_set_config_internal(struct drm_mode_set *set)
+{
+   struct drm_crtc *crtc = set->crtc;
+   struct drm_framebuffer *fb;
+   struct drm_crtc *tmp;
+   struct drm_modeset_acquire_ctx *ctx;
+   struct drm_device *dev = set->crtc->dev;
+   int ret;
+
+   ctx = dev->mode_config.acquire_ctx;
+
+restart:
+   /*
+* NOTE: ->set_config can also disable other crtcs (if we steal all
+* connectors from it), hence we need to refcount the fbs across all
+* crtcs. Atomic modeset will have saner semantics ...
+*/
+   drm_for_each_crtc(tmp, dev)
+   tmp->primary->old_fb = tmp->primary->fb;
+
+   fb = set->fb;
+
+   ret = crtc->funcs->set_config(set, ctx);
+   if (ret == 0) {
+   crtc->primary->crtc = crtc;
+   crtc->primary->fb = fb;
+   }
+
+   drm_for_each_crtc(tmp, dev) {
+   if (tmp->primary->fb)
+   drm_framebuffer_get(tmp->primary->fb);
+   if (tmp->primary->old_fb)
+   drm_framebuffer_put(tmp->primary->old_fb);
+   tmp->primary->old_fb = NULL;
+   }
+
+   if (ret == -EDEADLK) {
+   dev->mode_config.acquire_ctx = NULL;
+
+retry_locking:
+   drm_modeset_backoff(ctx);
+
+   ret = drm_modeset_lock_all_ctx(dev, ctx);
+   if (ret)
+   goto retry_locking;
+
+   dev->mode_config.acquire_ctx = ctx;
+
+   goto restart;
+   }
+
+   return ret;
+}
+
 static int vmw_fb_kms_detach(struct vmw_fb_par *par,
 bool detach_bo,
 bool unref_bo)
@@ -436,7 +490,7 @@ static int vmw_fb_kms_detach(struct vmw_fb_par *par,
set.fb = NULL;
set.num_connectors = 0;
set.connectors = >con;
-   ret = drm_mode_set_config_internal();
+   ret = vmwgfx_set_config_internal();
if (ret) {
DRM_ERROR("Could not unset a mode.\n");
return ret;
@@ -578,7 +632,7 @@ static int vmw_fb_set_par(struct fb_info *info)
set.num_connectors = 1;
set.connectors = >con;
 
-   ret = drm_mode_set_config_internal();
+   ret = vmwgfx_set_config_internal();
if (ret)
goto out_unlock;
 
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: drm-next-misc merge breaks vmwgfx

2017-04-06 Thread Daniel Vetter
On Thu, Apr 6, 2017 at 8:01 PM, Thomas Hellstrom  wrote:
> On 04/06/2017 04:46 PM, Daniel Vetter wrote:
>> On Thu, Apr 6, 2017 at 4:10 PM, Thomas Hellstrom  
>> wrote:
>>> On 04/06/2017 02:34 PM, Daniel Vetter wrote:
 Hi Thomas,

 Bisected an offender already? Afaik there's no one else who reported
 issues thus far, and for our own CI it seems all still fine.
 -Daniel
>>> Hi, Daniel,
>>>
>>> Yes, I rebased drm-misc-next on top of vmwgfx-next and found the culprit
>>> to be
>>>
>>> 38b6441e "drm/atomic-helper: Remove the backoff hack from set_config.."
>>>
>>> Reverting first 1fa4da04 and then
>>> 38b6441e
>>>
>>> fixes the problem.
>> Yeah, we seem to have a solid functional conflict between the vmwgfx
>> atomic conversion, and the changes in drm-misc-next. Preliminary
>> analysis, but I think what's going on is:
>> - With the above changes in -misc we punt the deadlock retry loop to
>> the callers of ->set_config.
>> - But since it would have been way too invasive, I only fixed up the
>> atomic callers (in most places we have special paths for atomic and
>> non-atomic due to slightly different semantics), which means for
>> legacy functions we in some cases pass a NULL ctx down to
>> ->set_config. But since legacy paths only get called on legacy
>> drivers, no problem.
>> - Well except I've done that audit before vmwgfx became atomic, and
>> that audit is now wrong, and I've forgotten to properly re-audit when
>> the conflicts happened all around. But since I half-expect to hit a
>> mid-driver conversion with this I did sprinkle
>> WARN_ON(drm_drv_uses_atomic_modeset()) over all these paths.
>>
>> So assuming this is correct, you should see a pile of WARN_ON
>> backtraces that you're hitting in the atomic-vmwgfx+drm-misc-next
>> combo. The proper fix would be to switch over to atomic primitives for
>> all these cases. On a quick look I see some in the vmwgfx fbdev
>> emulation code, might even be worth it to check whether we could reuse
>> the core helpers (which do this split handling alread) in some cases.
>>
>> Cheers, Daniel
>
> So with the two reverts previously mentioned applied, I see the
> following. Is this consistent with the above.
>
> FWIW I did a pretty big vmwgfx fbdev rewrite some time ago, but at that
> time we didn't have the callbacks
> necessary to use the helpers. Maybe that has changed with the atomic
> implementation.
>
> Considering that Sinclair just had a baby, I'm not 100% sure though,
> that I have time to fix this up in the vmwgfx driver for this merge
> window...
>
> /Thomas
>
>
> [9.547101] WARNING: CPU: 3 PID: 359 at
> drivers/gpu/drm/drm_modeset_lock.c:107 drm_modeset_lock_all+0xb8/0xc0 [drm]
> [9.547102] Modules linked in: snd_rawmidi snd_timer
> ghash_clmulni_intel intel_rapl_perf ppdev snd_seq_device vmw_balloon snd
> rfkill joydev soundcore nfit parport_pc parport acpi_cpufreq tpm_tis
> tpm_tis_core tpm shpchp vmw_vmci i2c_piix4 nfsd auth_rpcgss nfs_acl
> lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi
> scsi_transport_spi mptscsih crc32c_intel e1000 mptbase ata_generic
> serio_raw pata_acpi uas usb_storage
> [9.547122] CPU: 3 PID: 359 Comm: plymouthd Tainted: GW
> 4.11.0-rc4+ #2
> [9.547122] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
> Desktop Reference Platform, BIOS 6.00 01/24/2017
> [9.547123] Call Trace:
> [9.547128]  dump_stack+0x63/0x86
> [9.547130]  __warn+0xcb/0xf0
> [9.547131]  warn_slowpath_null+0x1d/0x20
> [9.547137]  drm_modeset_lock_all+0xb8/0xc0 [drm]
> [9.547143]  vmw_framebuffer_dmabuf_dirty+0x4c/0x200 [vmwgfx]
> [9.547145]  ? __check_object_size+0x100/0x19d
> [9.547152]  drm_mode_dirtyfb_ioctl+0x178/0x1a0 [drm]
> [9.547158]  drm_ioctl+0x209/0x4c0 [drm]
> [9.547164]  ? drm_mode_getfb+0x100/0x100 [drm]
> [9.547165]  ? __do_fault+0x1e/0x110
> [9.547169]  vmw_generic_ioctl+0x193/0x2d0 [vmwgfx]
> [9.547175]  ? drm_getunique+0xa0/0xa0 [drm]
> [9.547179]  vmw_unlocked_ioctl+0x15/0x20 [vmwgfx]
> [9.547180]  do_vfs_ioctl+0xa3/0x5f0
> [9.547181]  SyS_ioctl+0x79/0x90
> [9.547182]  do_syscall_64+0x67/0x180
> [9.547184]  entry_SYSCALL64_slow_path+0x25/0x25
> [9.547185] RIP: 0033:0x7fd4c93b7787
> [9.547186] RSP: 002b:7fff17d06b88 EFLAGS: 0246 ORIG_RAX:
> 0010
> [9.547187] RAX: ffda RBX: 0c80 RCX:
> 7fd4c93b7787
> [9.547187] RDX: 7fff17d06bc0 RSI: c01864b1 RDI:
> 0009
> [9.547188] RBP: 7fff17d06bc0 R08: 7fd4c7554000 R09:
> 7fd4ca1e9010
> [9.547188] R10: 558ffe14ca40 R11: 0246 R12:
> c01864b1
> [9.547188] R13: 0009 R14:  R15:
> 0258
> [9.547190] ---[ end trace 46a3554c8816a28b ]---

This is an artifact of the two reverts, I've forgotten to properly
clear config->acquire_ctx again in the intermediate states.


Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

2017-04-06 Thread Dave Airlie
On 5 April 2017 at 16:51, Laurent Pinchart
 wrote:
> As the DRM LVDS panel driver uses a different approach to DT bindings
> compared to what Thierry Reding advocates, add a specific MAINTAINERS
> entry to avoid bothering Thierry with requests related to that driver.

Could you document a bit more in the patch summary the finer points of
panel/dt doctrine,
as I haven't got as much knowledge as I'd like.

Just I believe, Thierry believes.

Otherwise just send a follow up git pull with this patch.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[pull] amdgpu drm-next-4.12

2017-04-06 Thread Alex Deucher
Hi Dave,

A few more things for 4.12:
- ttm and amdgpu support for non-contiguous vram CPU mappings
- lots of bug fixes and cleanups for vega10
- misc bug fixes and code cleanups

The following changes since commit e1b489d207c73e67810659a88c45b8db4bd62773:

  Merge tag 'omapdrm-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
(2017-04-04 05:45:49 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.12

for you to fetch changes up to f4e7c7c1b4ed4c28caf679bc94ca5aa096310c10:

  drm/amdgpu: use uintptr_t instead of unsigned long to store pointer 
(2017-04-06 13:28:08 -0400)


Alex Deucher (4):
  drm/amdgpu/powerplay: fix locking typo
  drm/amdgpu/soc15: Fix static checker warnings
  drm/amdgpu/vi: add defines for KIQ packets
  drm/amdgpu/gfx8: KIQ is also disabled when MEC is disabled

Alex Xie (3):
  drm/amdgpu: Move function amdgpu_has_atpx near other similar functions
  drm/amdgpu: Avoid using signed integer to store pointer value
  drm/amdgpu: use uintptr_t instead of unsigned long to store pointer

Christian König (17):
  drm/amdgpu: use a 64bit interval tree for VM management v2
  drm/ttm: cleanup and optimize ttm_bo_mem_compat v2
  drm/ttm: add io_mem_pfn callback
  drm/ttm: add TTM_PL_FLAG_CONTIGUOUS v2
  drm/amdgpu: drop alpha support
  drm/amdgpu: fix VMHUB order to match the hardware
  drm/amdgpu: move VM related defines into amdgpu_vm.h
  drm/amdgpu: remove VMID first tracking
  drm/amdgpu: coding style of amdgpu_vm_is_gpu_reset
  drm/amdgpu: cleanup coding style in amdgpu_vm_flush
  drm/amdgpu: cleanup logic in amdgpu_vm_flush
  drm/amdgpu: move adjust_mc_addr into amdgpu_gart_funcs
  drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS v2
  drm/amdgpu: handle CPU access for split VRAM buffers (v2)
  drm/amdgpu: cleanup VMHUB bit definitions v2
  drm/amdgpu: cleanup get_invalidate_req v2
  drm/amdgpu: fix over allocating of IRQ sources

Dan Carpenter (3):
  drm/amd/powerplay: fix pp_dpm_get_current_power_state() (v2)
  drm/amd/powerplay: fix a couple locking issues
  drm/amdgpu: Fix a NULL deref in amdgpu_vm_add_prt_cb()

Evan Quan (1):
  drm/amdgpu/smu9: update to latest driver interface

Harry Wentland (1):
  drm/amdgpu: Read vram width from integrated system info table

Monk Liu (6):
  drm/amdgpu:add PSP block only load_type=PSP (v2)
  drm/amdgpu:no need to involv HDP in KIQ
  drm/amdgpu:fix typo for mxgpu_ai
  drm/amdgpu:implement the reset MB func for vega10
  drm/amdgpu/vega10:timeout set to equal with VI
  drm/amdgpu:invoke new implemented AI MB func

Rex Zhu (2):
  drm/amdgpu: when resume failed, return error to avoid system hang.
  drm/amdgpu: various cleanups for uvd/vce.

Tom St Denis (18):
  drm/amd/amdgpu: Clean up gfx_v8_0_kiq_set_interrupt_state()
  drm/amd/amdgpu: Clean up gfx_v8_0_inactive_hqd()
  drm/amd/amdgpu: clean up gfx_v8_0_kiq_init_register()
  drm/amd/amdgpu: de-numberify HQD_ACTIVE check.
  drm/amd/amdgpu: Clean up gfx_v8_0_mqd_init()
  drm/amd/amdgpu: Fix srbm_indexing in init/inactive hqd code
  drm/amd/amdgpu: Fix psp_v3_1 compare sram
  drm/amd/amdgpu: Clean up psp reload_quirk()
  drm/amd/amdgpu: cleanup gfx_v9_0_init_queue()
  drm/amd/amdgpu: cleanup gfx_v9_0_set_priv_inst_fault_state()
  drm/amd/amdgpu: cleanup gfx_v9_0_set_priv_reg_fault_state()
  drm/amd/amdgpu: cleanup gfx_v9_0_set_gfx_eop_interrupt_state()
  drm/amd/amdgpu: Drop gfx_v9_0_print_status()
  drm/amd/amdgpu: cleanup gfx_v9_0_kiq_init_register()
  drm/amd/amdgpu: simplify gfx_v9_0_cp_gfx_enable()
  drm/amd/amdgpu: cleanup gfx_v9_0_rlc_start()
  drm/amd/amdgpu: cleanup gfx_v9_0_rlc_reset()
  drm/amd/amdgpu: cleanup gfx_v9_0_gpu_init()

Zhang, Jerry (2):
  drm/amdgpu: create a func to check vm size
  drm/amdgpu: fix vm size and block size for VMPT (v5)

kbuild test robot (1):
  drm/amdgpu: fix semicolon.cocci warnings

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  31 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c   |  29 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.h   |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  64 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  |  12 +-
 

Re: [PATCH] drm: Take mode_config.mutex in setcrtc ioctl

2017-04-06 Thread Alex Deucher
On Thu, Apr 6, 2017 at 3:06 PM, Daniel Vetter  wrote:
> Legacy drivers insist that we really take all the locks in this path,
> and the harm in doing so is minimal.
>
> v2: Like git add, it exists :(
>
> Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around 
> ->set_config")
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Alex Deucher 
> Reported-by: Alex Deucher 
> Signed-off-by: Daniel Vetter 

This actually matches what I tested locally.

Acked-and-tested-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_crtc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d69e180fc563..5af25ce5bf7c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -576,6 +576,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> }
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>
> +   mutex_lock(>dev->mode_config.mutex);
> drm_modeset_acquire_init(, 0);
>  retry:
> ret = drm_modeset_lock_all_ctx(crtc->dev, );
> @@ -721,6 +722,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> }
> drm_modeset_drop_locks();
> drm_modeset_acquire_fini();
> +   mutex_unlock(>dev->mode_config.mutex);
>
> return ret;
>  }
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: Take mode_config.mutex in setcrtc ioctl

2017-04-06 Thread Daniel Vetter
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.

v2: Like git add, it exists :(

Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around 
->set_config")
Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: Alex Deucher 
Reported-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d69e180fc563..5af25ce5bf7c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -576,6 +576,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
 
+   mutex_lock(>dev->mode_config.mutex);
drm_modeset_acquire_init(, 0);
 retry:
ret = drm_modeset_lock_all_ctx(crtc->dev, );
@@ -721,6 +722,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
+   mutex_unlock(>dev->mode_config.mutex);
 
return ret;
 }
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: Take mode_config.mutex in setcrtc ioctl

2017-04-06 Thread Alex Deucher
On Thu, Apr 6, 2017 at 2:55 PM, Daniel Vetter  wrote:
> Legacy drivers insist that we really take all the locks in this path,
> and the harm in doing so is minimal.
>
> Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around 
> ->set_config")
> Cc: Harry Wentland 
> Cc: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Alex Deucher 
> Reported-by: Alex Deucher 
> Signed-off-by: Daniel Vetter 

Acked-and-tested-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_crtc.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d69e180fc563..42257f373c59 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -576,6 +576,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> }
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>
> +   mutex_lock(crtc->dev->mode.config.mutex);
> drm_modeset_acquire_init(, 0);
>  retry:
> ret = drm_modeset_lock_all_ctx(crtc->dev, );
> @@ -721,6 +722,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> }
> drm_modeset_drop_locks();
> drm_modeset_acquire_fini();
> +   mutex_unlock(crtc->dev->mode.config.mutex);
>
> return ret;
>  }
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: Take mode_config.mutex in setcrtc ioctl

2017-04-06 Thread Daniel Vetter
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.

Fixes: 2ceb585a956c ("drm: Add explicit acquire ctx handling around 
->set_config")
Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc: Alex Deucher 
Reported-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d69e180fc563..42257f373c59 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -576,6 +576,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
 
+   mutex_lock(crtc->dev->mode.config.mutex);
drm_modeset_acquire_init(, 0);
 retry:
ret = drm_modeset_lock_all_ctx(crtc->dev, );
@@ -721,6 +722,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
}
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
+   mutex_unlock(crtc->dev->mode.config.mutex);
 
return ret;
 }
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4.

2017-04-06 Thread Maarten Lankhorst
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.

Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.

This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.

Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
  WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)

Signed-off-by: Maarten Lankhorst 
Cc: Boris Brezillon 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_probe_helper.c   | 100 ---
 drivers/gpu/drm/i915/intel_crt.c |  25 
 drivers/gpu/drm/i915/intel_display.c |  25 
 drivers/gpu/drm/i915/intel_dp.c  |  21 +++
 drivers/gpu/drm/i915/intel_drv.h |   8 +--
 drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
 drivers/gpu/drm/i915/intel_tv.c  |  21 +++
 include/drm/drm_connector.h  |   6 ++
 include/drm/drm_crtc_helper.h|   3 +
 include/drm/drm_modeset_helper_vtables.h |  36 +++
 10 files changed, 187 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index efb5e5e8ce62..1b0c14ab3fff 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -169,12 +169,73 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
 
 static enum drm_connector_status
-drm_connector_detect(struct drm_connector *connector, bool force)
+drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
 {
-   return connector->funcs->detect ?
-   connector->funcs->detect(connector, force) :
-   connector_status_connected;
+   const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
+   drm_modeset_acquire_init(, 0);
+
+retry:
+   ret = drm_modeset_lock(>dev->mode_config.connection_mutex, 
);
+   if (!ret) {
+   if (funcs->detect_ctx)
+   ret = funcs->detect_ctx(connector, , force);
+   else if (connector->funcs->detect)
+   ret = connector->funcs->detect(connector, force);
+   else
+   ret = connector_status_connected;
+   }
+
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   if (WARN_ON(ret < 0))
+   ret = connector_status_unknown;
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
+   return ret;
+}
+
+/**
+ * drm_helper_probe_detect - probe connector status
+ * @connector: connector to probe
+ * @ctx: acquire_ctx, or NULL to let this function handle locking.
+ * @force: Whether destructive probe operations should be performed.
+ *
+ * This function calls the detect callbacks of the connector.
+ * This function returns _connector_status, or
+ * if @ctx is set, it might also return -EDEADLK.
+ */
+int
+drm_helper_probe_detect(struct drm_connector *connector,
+   struct drm_modeset_acquire_ctx *ctx,
+   bool force)
+{
+   const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
+   struct drm_device *dev = connector->dev;
+   int ret;
+
+   if (!ctx)
+   return drm_helper_probe_detect_ctx(connector, force);
+
+   ret = drm_modeset_lock(>mode_config.connection_mutex, ctx);
+   if (ret)
+   return ret;
+
+   if (funcs->detect_ctx)
+   return funcs->detect_ctx(connector, ctx, force);
+   else if (connector->funcs->detect)
+   return connector->funcs->detect(connector, force);
+   else
+   return connector_status_connected;
 }
+EXPORT_SYMBOL(drm_helper_probe_detect);
 
 /**
  * drm_helper_probe_single_connector_modes - get complete set of display modes
@@ -239,15 +300,27 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
struct drm_display_mode *mode;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
-   int count = 0;
+   int count = 0, ret;
int mode_flags = 0;
bool 

Re: drm-next-misc merge breaks vmwgfx

2017-04-06 Thread Thomas Hellstrom
On 04/06/2017 04:46 PM, Daniel Vetter wrote:
> On Thu, Apr 6, 2017 at 4:10 PM, Thomas Hellstrom  
> wrote:
>> On 04/06/2017 02:34 PM, Daniel Vetter wrote:
>>> Hi Thomas,
>>>
>>> Bisected an offender already? Afaik there's no one else who reported
>>> issues thus far, and for our own CI it seems all still fine.
>>> -Daniel
>> Hi, Daniel,
>>
>> Yes, I rebased drm-misc-next on top of vmwgfx-next and found the culprit
>> to be
>>
>> 38b6441e "drm/atomic-helper: Remove the backoff hack from set_config.."
>>
>> Reverting first 1fa4da04 and then
>> 38b6441e
>>
>> fixes the problem.
> Yeah, we seem to have a solid functional conflict between the vmwgfx
> atomic conversion, and the changes in drm-misc-next. Preliminary
> analysis, but I think what's going on is:
> - With the above changes in -misc we punt the deadlock retry loop to
> the callers of ->set_config.
> - But since it would have been way too invasive, I only fixed up the
> atomic callers (in most places we have special paths for atomic and
> non-atomic due to slightly different semantics), which means for
> legacy functions we in some cases pass a NULL ctx down to
> ->set_config. But since legacy paths only get called on legacy
> drivers, no problem.
> - Well except I've done that audit before vmwgfx became atomic, and
> that audit is now wrong, and I've forgotten to properly re-audit when
> the conflicts happened all around. But since I half-expect to hit a
> mid-driver conversion with this I did sprinkle
> WARN_ON(drm_drv_uses_atomic_modeset()) over all these paths.
>
> So assuming this is correct, you should see a pile of WARN_ON
> backtraces that you're hitting in the atomic-vmwgfx+drm-misc-next
> combo. The proper fix would be to switch over to atomic primitives for
> all these cases. On a quick look I see some in the vmwgfx fbdev
> emulation code, might even be worth it to check whether we could reuse
> the core helpers (which do this split handling alread) in some cases.
>
> Cheers, Daniel

So with the two reverts previously mentioned applied, I see the
following. Is this consistent with the above.

FWIW I did a pretty big vmwgfx fbdev rewrite some time ago, but at that
time we didn't have the callbacks
necessary to use the helpers. Maybe that has changed with the atomic
implementation.

Considering that Sinclair just had a baby, I'm not 100% sure though,
that I have time to fix this up in the vmwgfx driver for this merge
window...

/Thomas


[9.547101] WARNING: CPU: 3 PID: 359 at
drivers/gpu/drm/drm_modeset_lock.c:107 drm_modeset_lock_all+0xb8/0xc0 [drm]
[9.547102] Modules linked in: snd_rawmidi snd_timer
ghash_clmulni_intel intel_rapl_perf ppdev snd_seq_device vmw_balloon snd
rfkill joydev soundcore nfit parport_pc parport acpi_cpufreq tpm_tis
tpm_tis_core tpm shpchp vmw_vmci i2c_piix4 nfsd auth_rpcgss nfs_acl
lockd grace sunrpc vmwgfx drm_kms_helper ttm drm mptspi
scsi_transport_spi mptscsih crc32c_intel e1000 mptbase ata_generic
serio_raw pata_acpi uas usb_storage
[9.547122] CPU: 3 PID: 359 Comm: plymouthd Tainted: GW  
4.11.0-rc4+ #2
[9.547122] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 01/24/2017
[9.547123] Call Trace:
[9.547128]  dump_stack+0x63/0x86
[9.547130]  __warn+0xcb/0xf0
[9.547131]  warn_slowpath_null+0x1d/0x20
[9.547137]  drm_modeset_lock_all+0xb8/0xc0 [drm]
[9.547143]  vmw_framebuffer_dmabuf_dirty+0x4c/0x200 [vmwgfx]
[9.547145]  ? __check_object_size+0x100/0x19d
[9.547152]  drm_mode_dirtyfb_ioctl+0x178/0x1a0 [drm]
[9.547158]  drm_ioctl+0x209/0x4c0 [drm]
[9.547164]  ? drm_mode_getfb+0x100/0x100 [drm]
[9.547165]  ? __do_fault+0x1e/0x110
[9.547169]  vmw_generic_ioctl+0x193/0x2d0 [vmwgfx]
[9.547175]  ? drm_getunique+0xa0/0xa0 [drm]
[9.547179]  vmw_unlocked_ioctl+0x15/0x20 [vmwgfx]
[9.547180]  do_vfs_ioctl+0xa3/0x5f0
[9.547181]  SyS_ioctl+0x79/0x90
[9.547182]  do_syscall_64+0x67/0x180
[9.547184]  entry_SYSCALL64_slow_path+0x25/0x25
[9.547185] RIP: 0033:0x7fd4c93b7787
[9.547186] RSP: 002b:7fff17d06b88 EFLAGS: 0246 ORIG_RAX:
0010
[9.547187] RAX: ffda RBX: 0c80 RCX:
7fd4c93b7787
[9.547187] RDX: 7fff17d06bc0 RSI: c01864b1 RDI:
0009
[9.547188] RBP: 7fff17d06bc0 R08: 7fd4c7554000 R09:
7fd4ca1e9010
[9.547188] R10: 558ffe14ca40 R11: 0246 R12:
c01864b1
[9.547188] R13: 0009 R14:  R15:
0258
[9.547190] ---[ end trace 46a3554c8816a28b ]---


4.824456] WARNING: CPU: 2 PID: 359 at drivers/gpu/drm/drm_crtc.c:499
drm_mode_set_config_internal+0x40/0x50 [drm]
[4.824457] Modules linked in: vmwgfx drm_kms_helper ttm drm mptspi
scsi_transport_spi mptscsih crc32c_intel e1000(+) mptbase ata_generic
serio_raw pata_acpi uas usb_storage
[4.824467] CPU: 2 PID: 359 Comm: plymouthd Tainted: GW   

Re: [PATCH 12/15] drm: Add acquire ctx to ->gamma_set hook

2017-04-06 Thread Daniel Vetter
On Thu, Apr 6, 2017 at 6:51 PM, Eric Anholt  wrote:
> Daniel Vetter  writes:
>> Atomic helpers really want this instead of the hacked-up legacy
>> backoff trick, which unfortunately prevents drivers from using their
>> own private drm_modeset_locks.
>>
>> Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
>> don't yet use the new atomic color mgmt/gamma table stuff. Would be
>> nice if they could switch over and just hook up
>> drm_atomic_helper_legacy_gamma_set() instead.
>
> For notes like this, it would be helpful to have a pointer to a driver
> doing it cleanly the current way.

Yeah, good point. And the kernel-doc for legacy_gamma_set is also not
all that awesome. So we currently have i915, mediatek and omapdrm
using this, and for the new atomic gamma stuff we do have fairly
reasonable docs (just a bit harder to find that I thought they'd be):
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#color-management-properties

I'll try and type up a patch to sprinkle a few more hints around and
connect the pieces.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

2017-04-06 Thread Ville Syrjälä
On Thu, Apr 06, 2017 at 08:27:47PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > >  static const uint32_t virtio_gpu_cursor_formats[] = {
> > > > +#ifdef __BIG_ENDIAN
> > > > +   DRM_FORMAT_BGRA,
> > > > +#else
> > > > DRM_FORMAT_ARGB,
> > > > +#endif
> > > 
> > > DRM formats are supposed to be little endian, so this isn't really
> > > correct.
> > 
> > Well, maybe they where *intended* to be little endian at some point in
> > the past.  The actual code appears to interpret them as native endian
> > though.
> > 
> > Lets take a simple example, the bochs driver (qemu sdvga).  It supports
> > 32 bpp with depth 24 (DRM_FORMAT_XRGB) as the one and only
> > framebuffer format (see bochs_user_framebuffer_create).  We still had to
> > add a special register to the virtual hardware so the guest can signal
> > to the host whenever the framebuffer is big endian or little endian (see
> > bochs_hw_init), so both ppc64 and ppc64le guests work properly with the
> > qemu stdvga.
> > 
> > So, bigendian guests assume that DRM_FORMAT_XRGB is big endian not
> > little endian.  And given that the fourcc codes are used in the
> > userspace/kernel API too (see DRM_IOCTL_MODE_ADDFB2) I think we can't
> > change that any more ...
> 
> Sigh. That makes mixed endian systems pretty much hopeless :(

Hmm. Maybe it's still possible to salvage something by redefining the
BIG_ENDIAN format bit to mean the "the other endianness". Ugly but it
might still result in something usable.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: DRM_FORMAT_* byte order (was: Re: [PATCH] drm: virtio: fix virtio_gpu_cursor_formats)

2017-04-06 Thread Ville Syrjälä
On Thu, Apr 06, 2017 at 10:29:43AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > >  static const uint32_t virtio_gpu_cursor_formats[] = {
> > > +#ifdef __BIG_ENDIAN
> > > + DRM_FORMAT_BGRA,
> > > +#else
> > >   DRM_FORMAT_ARGB,
> > > +#endif
> > 
> > DRM formats are supposed to be little endian, so this isn't really
> > correct.
> 
> Well, maybe they where *intended* to be little endian at some point in
> the past.  The actual code appears to interpret them as native endian
> though.
> 
> Lets take a simple example, the bochs driver (qemu sdvga).  It supports
> 32 bpp with depth 24 (DRM_FORMAT_XRGB) as the one and only
> framebuffer format (see bochs_user_framebuffer_create).  We still had to
> add a special register to the virtual hardware so the guest can signal
> to the host whenever the framebuffer is big endian or little endian (see
> bochs_hw_init), so both ppc64 and ppc64le guests work properly with the
> qemu stdvga.
> 
> So, bigendian guests assume that DRM_FORMAT_XRGB is big endian not
> little endian.  And given that the fourcc codes are used in the
> userspace/kernel API too (see DRM_IOCTL_MODE_ADDFB2) I think we can't
> change that any more ...

Sigh. That makes mixed endian systems pretty much hopeless :(
It's a shame people didn't read the docuemntation.

It's also doubly disappointing because eg. the more standardized YUV
formats are definitely little endian as far the official fourccs are
concerned. So if we now make everything follow the host endianness
these things become a huge mess for anyone wanting to do video
playback etc.

Oh well, at least I tried to make it sane from the start. I'll just
go back to my blissful little endian world now.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 4/4] drm: zte: add VGA driver support

2017-04-06 Thread Sean Paul
On Thu, Apr 06, 2017 at 11:01:10PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> It adds VGA driver support, which needs to configure corresponding VOU
> interface in RGB_888 format, and thus the following changes are needed
> on zx_vou.
> 
> - Rename the CSC block of Graphic Layer a bit to make it more specific,
>   and add CSC of Channel to support RGB output.
> - Bypass Dither block for RGB output.
> 
> Signed-off-by: Shawn Guo 
> Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/zte/Makefile  |   1 +
>  drivers/gpu/drm/zte/zx_drm_drv.c  |   1 +
>  drivers/gpu/drm/zte/zx_drm_drv.h  |   1 +
>  drivers/gpu/drm/zte/zx_vga.c  | 530 
> ++
>  drivers/gpu/drm/zte/zx_vga_regs.h |  36 +++
>  drivers/gpu/drm/zte/zx_vou.c  |  33 ++-
>  drivers/gpu/drm/zte/zx_vou_regs.h |  12 +-
>  7 files changed, 610 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/zte/zx_vga.c
>  create mode 100644 drivers/gpu/drm/zte/zx_vga_regs.h
> 
> diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
> index 01352b56c418..9df7766a7f9d 100644
> --- a/drivers/gpu/drm/zte/Makefile
> +++ b/drivers/gpu/drm/zte/Makefile
> @@ -3,6 +3,7 @@ zxdrm-y := \
>   zx_hdmi.o \
>   zx_plane.o \
>   zx_tvenc.o \
> + zx_vga.o \
>   zx_vou.o
>  
>  obj-$(CONFIG_DRM_ZTE) += zxdrm.o
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c 
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 5c6944a1e72c..8a6892eeb44f 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -248,6 +248,7 @@ static int zx_drm_remove(struct platform_device *pdev)
>   _crtc_driver,
>   _hdmi_driver,
>   _tvenc_driver,
> + _vga_driver,
>   _drm_platform_driver,
>  };
>  
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.h 
> b/drivers/gpu/drm/zte/zx_drm_drv.h
> index 5ca035b079c7..2a8cdc5f8be4 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.h
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.h
> @@ -14,6 +14,7 @@
>  extern struct platform_driver zx_crtc_driver;
>  extern struct platform_driver zx_hdmi_driver;
>  extern struct platform_driver zx_tvenc_driver;
> +extern struct platform_driver zx_vga_driver;
>  
>  static inline u32 zx_readl(void __iomem *reg)
>  {
> diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
> new file mode 100644
> index ..0d850d9ea700
> --- /dev/null
> +++ b/drivers/gpu/drm/zte/zx_vga.c
> @@ -0,0 +1,530 @@
> +/*
> + * Copyright (C) 2017 Sanechips Technology Co., Ltd.
> + * Copyright 2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "zx_drm_drv.h"
> +#include "zx_vga_regs.h"
> +#include "zx_vou.h"
> +
> +struct zx_vga_pwrctrl {
> + struct regmap *regmap;
> + u32 reg;
> + u32 mask;
> +};
> +
> +struct zx_vga_i2c {
> + struct i2c_adapter adap;
> + struct mutex lock;
> +};
> +
> +struct zx_vga {
> + struct drm_connector connector;
> + struct drm_encoder encoder;
> + struct zx_vga_i2c *ddc;
> + struct device *dev;
> + void __iomem *mmio;
> + struct clk *i2c_wclk;
> + struct zx_vga_pwrctrl pwrctrl;
> + spinlock_t lock;
> + struct completion complete;
> + bool connected;
> +};
> +
> +#define to_zx_vga(x) container_of(x, struct zx_vga, x)
> +
> +static void zx_vga_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct zx_vga *vga = to_zx_vga(encoder);
> + struct zx_vga_pwrctrl *pwrctrl = >pwrctrl;
> +
> + /* Set bit to power up VGA DACs */
> + regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask,
> +pwrctrl->mask);
> +
> + vou_inf_enable(VOU_VGA, encoder->crtc);
> +}
> +
> +static void zx_vga_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct zx_vga *vga = to_zx_vga(encoder);
> + struct zx_vga_pwrctrl *pwrctrl = >pwrctrl;
> +
> + vou_inf_disable(VOU_VGA, encoder->crtc);
> +
> + /* Clear bit to power down VGA DACs */
> + regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask, 0);
> +}
> +
> +static const struct drm_encoder_helper_funcs zx_vga_encoder_helper_funcs = {
> + .enable = zx_vga_encoder_enable,
> + .disable = zx_vga_encoder_disable,
> +};
> +
> +static const struct drm_encoder_funcs zx_vga_encoder_funcs = {
> + .destroy = drm_encoder_cleanup,
> +};
> +
> +static int zx_vga_connector_get_modes(struct drm_connector *connector)
> +{
> + struct zx_vga *vga = to_zx_vga(connector);
> + unsigned long flags;
> + struct edid *edid;
> + int ret;
> +
> + /*
> +  * Clear both detection bits to switch I2C bus from device
> +  * detecting to EDID reading.
> +

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-04-06 Thread Manasi Navare
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> >> Manasi Navare  writes:
> >> 
> >> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
> >> >> Manasi Navare  writes:
> >> >> 
> >> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
> >> >> >> Martin Peres  writes:
> >> >> >> 
> >> >> >> > On 26/01/17 14:37, Martin Peres wrote:
> >> >> >> >> Despite all the careful planing of the kernel, a link may become
> >> >> >> >> insufficient to handle the currently-set mode. At this point, the
> >> >> >> >> kernel should mark this particular configuration as being broken
> >> >> >> >> and potentially prune the mode before setting the offending 
> >> >> >> >> connector's
> >> >> >> >> link-status to BAD and send the userspace a hotplug event. This 
> >> >> >> >> may
> >> >> >> >> happen right after a modeset or later on.
> >> >> >> >>
> >> >> >> >> When available, we should use the link-status information to reset
> >> >> >> >> the wanted mode.
> >> >> >> >>
> >> >> >> >> Signed-off-by: Martin Peres 
> >> >> >> >
> >> >> >> > The relevant kernel patches have landed in drm-tip about a month 
> >> >> >> > ago.
> >> >> >> >
> >> >> >> > Eric, would you mind providing feedback on or merging this patch?
> >> >> >> 
> >> >> >> The later discussion has sounded like the kernel will (always) prune 
> >> >> >> the
> >> >> >> mode when we re-query, meaning that it doesn't make any sense to try 
> >> >> >> to
> >> >> >> re-set to the old mode.  Is this not the case?
> >> >> >
> >> >> >
> >> >> > No the kernel will simply send a hotplug with link status as bad
> >> >> > and then after that point its userspace driver's responsibility
> >> >> > to check if link status is BAD, retry the same mode and if it fails
> >> >> > then re probe.
> >> >> 
> >> >> So the kernel will sometimes allow the same mode to be re-set with the
> >> >> same bpp?
> >> >
> >> > So when userspace driver re-sets the same mode, the kernel will call the
> >> > mode valid function where it will see it can allow the sam mode perhaps
> >> > at a lower bpp now since the link parameters are lowered.
> >> > So the mode which failed at 30 bpp, might still work at 18bpp and is
> >> > better going to a lower resolution.
> >> 
> >> The question was whether the kernel will ever allow the same mode at the
> >> same bpp, since that's what this patch tries to do.
> >
> > Yes, this can happen. Doing a full modeset with recomputing clocks and
> > everything behind userspace's back might not be something the kernel
> > driver can pull of with a reasonable amount of effort, hence why we punt
> > to userspace. The interface spec makes this a CAN, not WILL, to allow less
> > unreasonable hw to handle these cases directly in the kernel driver. E.g.
> > plain link-retraining is handled in i915.ko still.
> 
> So in that case you do need userspace to re-request the same mode at the
> same bpp?

Hi Eric,

Yes so we do need userspace to re-request the same mode at the same bpp/pixel 
rate.
Kernel will try that at that bpp or lower it. Its fully in kernel's control.
If it fails then the atomic_check phase will return a failure and in that case
the Gnome/KDE will have to do a full reprobe.

Eric, do you have any more concerns about this patch or can this be pushed to 
Xserver?

Its critical for thsi patch to be pushed to Xserver so that the entire Gfx 
stack can handle
link failures and we can see some of the bugs going away.

Regards
Manasi

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

2017-04-06 Thread Tobias Jakobi
Hello Inki,


Inki Dae wrote:
> This patch removes unnecessary descriptions on
> exynos_drm_crtc structure and adds one description
> which specifies what pipe_clk member does.
> 
> pipe_clk support had been added by below patch without any description,
>drm/exynos: add support for pipeline clock to the framework
I would put the commit id here. That makes it easier to look up the
commit your refer to.


> Signed-off-by: Inki Dae 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 527bf1d..b0462cc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -152,12 +152,10 @@ struct exynos_drm_clk {
>   *
>   * @base: crtc object.
>   * @type: one of EXYNOS_DISPLAY_TYPE_LCD and HDMI.
> - * @enabled: if the crtc is enabled or not
> - * @event: vblank event that is currently queued for flip
> - * @wait_update: wait all pending planes updates to finish
> - * @pending_update: number of pending plane updates in this crtc
>   * @ops: pointer to callbacks for exynos drm specific functionality
>   * @ctx: A pointer to the crtc's implementation specific context
> + * @pipe_clk: A pipe clock structure which includes a callback function
> +   for enabling DP clock of FIMD and HDMI PHY clock.
This is wrong/inconsistent with the rest of the documentation. pipe_clk
is not a struct, but a pointer.

I would suggest to follow. Just document that we have a pointer to  here (compare docu for 'ops' and 'ctx').
And then put the later bits ("...callback function for enabling DP
clock...") directly to the definition of 'struct exynos_drm_clk' (which
is currently lacking any kind of docu).


- Tobias

>   */
>  struct exynos_drm_crtc {
>   struct drm_crtc base;
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

2017-04-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100465

--- Comment #10 from Alex Deucher  ---
(In reply to Julien Isorce from comment #9)
> 
> So I have 4 questions:
>  1: Can an application causes a "ring 0 stalled" ? or is it a driver bug
> (kernel side or mesa/drm or xserver) ?

driver bug.  Probably mesa or kernel.

>  2: About these atombios failures, does it mean that it fails to load the
> gpu microcode/firmware ?

Most likely the GPU reset was not actually successful and the atombios errors
are a symptom of that.

>  3: Does it try to do a gpu softreset because I added R600_DEBUG=check_vm ?
> Or this one just help to flush the traces on vm fault (like mentioned in a
> commit msg related to that env var in mesa) ?

check_vm doesn't not change anything with respect to gpu reset.

>  4: For the deallocation failure / leak above (radeon_ttm_bo_destroy
> warning), does it mean the memory is lost until next reboot or does a gpu
> soft reset allow to recover these leaks ? 

I'm not quite sure what you are referring to, but if the GPU reset is
successful, all fences should be signalled so any memory that is pinned due to
a command buffer being in flight could be freed.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 12/15] drm: Add acquire ctx to ->gamma_set hook

2017-04-06 Thread Eric Anholt
Daniel Vetter  writes:

> Atomic helpers really want this instead of the hacked-up legacy
> backoff trick, which unfortunately prevents drivers from using their
> own private drm_modeset_locks.
>
> Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
> don't yet use the new atomic color mgmt/gamma table stuff. Would be
> nice if they could switch over and just hook up
> drm_atomic_helper_legacy_gamma_set() instead.

For notes like this, it would be helpful to have a pointer to a driver
doing it cleanly the current way.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100

2017-04-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=100465

--- Comment #9 from Julien Isorce  ---
When using R600_DEBUG=check_vm on both Xorg and the gl app I can get some
output in kern.log. It looks like a "ring 0 stalled" is detected and then
follow a gpu softreset which succeeds ("GPU reset succeeded, trying to resume")
but fails to resume because:

[drm:atom_execute_table_locked [radeon]] [kworker/0:1H, 434] *ERROR* atombios
stuck executing C483 (len 254, WS 0, PS 4) @ 0xC4AD
[drm:atom_execute_table_locked [radeon]] [kworker/0:1H, 434] *ERROR* atombios
stuck executing BC59 (len 74, WS 0, PS 8) @ 0xBC8E

Then there is two: radeon_mc_wait_for_idle failure "Wait for MC idle timedout"
from si_mc_program

Finally si_startup fails because si_cp_resume fails because r600_ring_test
fails with: "radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)"

But it seems it keeps looping trying to do a gpu softreset and at some point it
freezes. I need to confirm this ending scenario though but these atombios
failures are worring in the first place.

At the same time I get some "radeon_ttm_bo_destroy" notified by
"WARN_ON(!list_empty(>va));" from kernel radeon driver. So it seems to leak
some buffers. 

I will attach the full log tomorrow, it is mess-up with my traces atm but the
essential is above I hope.

So I have 4 questions:
 1: Can an application causes a "ring 0 stalled" ? or is it a driver bug
(kernel side or mesa/drm or xserver) ?
 2: About these atombios failures, does it mean that it fails to load the gpu
microcode/firmware ?
 3: Does it try to do a gpu softreset because I added R600_DEBUG=check_vm ? Or
this one just help to flush the traces on vm fault (like mentioned in a commit
msg related to that env var in mesa) ?
 4: For the deallocation failure / leak above (radeon_ttm_bo_destroy warning),
does it mean the memory is lost until next reboot or does a gpu soft reset
allow to recover these leaks ? 

Thx !

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/virtio: don't leak bo on drm_gem_object_init failure

2017-04-06 Thread Gerd Hoffmann
Reported-by: 李强 
Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/virtio/virtgpu_object.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 1483dae..6f66b73 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -81,8 +81,10 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev,
return -ENOMEM;
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(vgdev->ddev, >gem_base, size);
-   if (ret != 0)
+   if (ret != 0) {
+   kfree(bo);
return ret;
+   }
bo->dumb = false;
virtio_gpu_init_ttm_placement(bo, pinned);
 
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 3/4] dt-bindings: display: add support for ZTE VGA device

2017-04-06 Thread Rob Herring
On Thu, Apr 6, 2017 at 10:01 AM, Shawn Guo  wrote:
> From: Shawn Guo 
>
> It adds bindings doc for ZTE VOU VGA output device.
>
> Signed-off-by: Shawn Guo 
> ---
>  .../devicetree/bindings/display/zte,vou.txt | 21 
> +
>  1 file changed, 21 insertions(+)

Acked-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: drm-next-misc merge breaks vmwgfx

2017-04-06 Thread Thomas Hellstrom
On 04/06/2017 05:01 PM, Daniel Vetter wrote:
> On Thu, Apr 6, 2017 at 4:56 PM, Thomas Hellstrom  
> wrote:
>> On 04/06/2017 04:47 PM, Daniel Vetter wrote:
>>> On Thu, Apr 6, 2017 at 4:10 PM, Thomas Hellstrom  
>>> wrote:
 Also, when testing the tip of drm-misc-next (with the non-atomic vmwgfx)
 there appeared to be warnings about a non-NULL
 dev->mode_config.acquire_ctx. I'll see if I can reproduce those, but
 perhaps removing the line

 dev->mode_config.acquire_ctx = 

 in drm_mode_setcrtc()

 is part of the problem.
>>> Hm, where do you hit that? And by tip of drm-misc-next, do you mean
>>> the very latest state, which includes atomic vmwgfx, or is this with
>>> the non-atomic vmwgfx? Please paste the backtraces (and for which tree
>>> they are).
>>> -Daniel
>> Actually this must have been from a confused rebase-bisect state
>> somewhere. I can't reproduce this.
> Have you changed CONFIG_DEBUG_WW_MUTEX_SLOWPATH perhaps? Without this
> you shouldn't be able to hit any retry path (so minus warnings the
> patch you bisected won't have an affected), with you will hit the
> deadlock retry paths pseudo-randomly. It might take a few trials to
> hit it again, depending upon timing.
> -Daniel

No, it's not that. I've set it to off for all these tests, but lockdep
and hang-checks on.

/Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 4/4] drm: zte: add VGA driver support

2017-04-06 Thread Shawn Guo
From: Shawn Guo 

It adds VGA driver support, which needs to configure corresponding VOU
interface in RGB_888 format, and thus the following changes are needed
on zx_vou.

- Rename the CSC block of Graphic Layer a bit to make it more specific,
  and add CSC of Channel to support RGB output.
- Bypass Dither block for RGB output.

Signed-off-by: Shawn Guo 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/zte/Makefile  |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.c  |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.h  |   1 +
 drivers/gpu/drm/zte/zx_vga.c  | 530 ++
 drivers/gpu/drm/zte/zx_vga_regs.h |  36 +++
 drivers/gpu/drm/zte/zx_vou.c  |  33 ++-
 drivers/gpu/drm/zte/zx_vou_regs.h |  12 +-
 7 files changed, 610 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/zte/zx_vga.c
 create mode 100644 drivers/gpu/drm/zte/zx_vga_regs.h

diff --git a/drivers/gpu/drm/zte/Makefile b/drivers/gpu/drm/zte/Makefile
index 01352b56c418..9df7766a7f9d 100644
--- a/drivers/gpu/drm/zte/Makefile
+++ b/drivers/gpu/drm/zte/Makefile
@@ -3,6 +3,7 @@ zxdrm-y := \
zx_hdmi.o \
zx_plane.o \
zx_tvenc.o \
+   zx_vga.o \
zx_vou.o
 
 obj-$(CONFIG_DRM_ZTE) += zxdrm.o
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c
index 5c6944a1e72c..8a6892eeb44f 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.c
+++ b/drivers/gpu/drm/zte/zx_drm_drv.c
@@ -248,6 +248,7 @@ static int zx_drm_remove(struct platform_device *pdev)
_crtc_driver,
_hdmi_driver,
_tvenc_driver,
+   _vga_driver,
_drm_platform_driver,
 };
 
diff --git a/drivers/gpu/drm/zte/zx_drm_drv.h b/drivers/gpu/drm/zte/zx_drm_drv.h
index 5ca035b079c7..2a8cdc5f8be4 100644
--- a/drivers/gpu/drm/zte/zx_drm_drv.h
+++ b/drivers/gpu/drm/zte/zx_drm_drv.h
@@ -14,6 +14,7 @@
 extern struct platform_driver zx_crtc_driver;
 extern struct platform_driver zx_hdmi_driver;
 extern struct platform_driver zx_tvenc_driver;
+extern struct platform_driver zx_vga_driver;
 
 static inline u32 zx_readl(void __iomem *reg)
 {
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
new file mode 100644
index ..0d850d9ea700
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -0,0 +1,530 @@
+/*
+ * Copyright (C) 2017 Sanechips Technology Co., Ltd.
+ * Copyright 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "zx_drm_drv.h"
+#include "zx_vga_regs.h"
+#include "zx_vou.h"
+
+struct zx_vga_pwrctrl {
+   struct regmap *regmap;
+   u32 reg;
+   u32 mask;
+};
+
+struct zx_vga_i2c {
+   struct i2c_adapter adap;
+   struct mutex lock;
+};
+
+struct zx_vga {
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+   struct zx_vga_i2c *ddc;
+   struct device *dev;
+   void __iomem *mmio;
+   struct clk *i2c_wclk;
+   struct zx_vga_pwrctrl pwrctrl;
+   spinlock_t lock;
+   struct completion complete;
+   bool connected;
+};
+
+#define to_zx_vga(x) container_of(x, struct zx_vga, x)
+
+static void zx_vga_encoder_enable(struct drm_encoder *encoder)
+{
+   struct zx_vga *vga = to_zx_vga(encoder);
+   struct zx_vga_pwrctrl *pwrctrl = >pwrctrl;
+
+   /* Set bit to power up VGA DACs */
+   regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask,
+  pwrctrl->mask);
+
+   vou_inf_enable(VOU_VGA, encoder->crtc);
+}
+
+static void zx_vga_encoder_disable(struct drm_encoder *encoder)
+{
+   struct zx_vga *vga = to_zx_vga(encoder);
+   struct zx_vga_pwrctrl *pwrctrl = >pwrctrl;
+
+   vou_inf_disable(VOU_VGA, encoder->crtc);
+
+   /* Clear bit to power down VGA DACs */
+   regmap_update_bits(pwrctrl->regmap, pwrctrl->reg, pwrctrl->mask, 0);
+}
+
+static const struct drm_encoder_helper_funcs zx_vga_encoder_helper_funcs = {
+   .enable = zx_vga_encoder_enable,
+   .disable = zx_vga_encoder_disable,
+};
+
+static const struct drm_encoder_funcs zx_vga_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static int zx_vga_connector_get_modes(struct drm_connector *connector)
+{
+   struct zx_vga *vga = to_zx_vga(connector);
+   unsigned long flags;
+   struct edid *edid;
+   int ret;
+
+   /*
+* Clear both detection bits to switch I2C bus from device
+* detecting to EDID reading.
+*/
+   spin_lock_irqsave(>lock, flags);
+   zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
+   spin_unlock_irqrestore(>lock, flags);
+
+   edid = drm_get_edid(connector, >ddc->adap);
+   if (!edid)
+   return 0;
+
+   /*
+* As edid reading 

[PATCH v2 1/4] drm: zte: do not enable clock auto-gating by default

2017-04-06 Thread Shawn Guo
From: Shawn Guo 

Some VOU modules do not work well with clock auto-gating.  For example,
VGA I2C bus will fail to read EDID data from monitor.  Let's not enable
this feature by default, and leave it to the possible future low-power
optimization.

Signed-off-by: Shawn Guo 
Reviewed-by: Sean Paul 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/zte/zx_vou.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index cf92d675feaa..2a2d90bd9425 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -720,9 +720,6 @@ static void vou_hw_init(struct zx_vou_hw *vou)
/* Release reset for all VOU modules */
zx_writel(vou->vouctl + VOU_SOFT_RST, ~0);
 
-   /* Enable clock auto-gating for all VOU modules */
-   zx_writel(vou->vouctl + VOU_CLK_REQEN, ~0);
-
/* Enable all VOU module clocks */
zx_writel(vou->vouctl + VOU_CLK_EN, ~0);
 
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/4] drm: zte: move CSC register definitions into a common header

2017-04-06 Thread Shawn Guo
From: Shawn Guo 

The CSC (Color Space Conversion) block in VOU is used by not only
Graphic Layer (plane) but also channel (CRTC) module.  Let's move
its register definitions into a common header, so that CRTC driver can
include it when needed.

Signed-off-by: Shawn Guo 
Reviewed-by: Sean Paul 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/zte/zx_common_regs.h | 31 +++
 drivers/gpu/drm/zte/zx_plane.c   |  1 +
 drivers/gpu/drm/zte/zx_plane_regs.h  | 18 --
 3 files changed, 32 insertions(+), 18 deletions(-)
 create mode 100644 drivers/gpu/drm/zte/zx_common_regs.h

diff --git a/drivers/gpu/drm/zte/zx_common_regs.h 
b/drivers/gpu/drm/zte/zx_common_regs.h
new file mode 100644
index ..2afd80664c51
--- /dev/null
+++ b/drivers/gpu/drm/zte/zx_common_regs.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2017 Sanechips Technology Co., Ltd.
+ * Copyright 2017 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ZX_COMMON_REGS_H__
+#define __ZX_COMMON_REGS_H__
+
+/* CSC registers */
+#define CSC_CTRL0  0x30
+#define CSC_COV_MODE_SHIFT 16
+#define CSC_COV_MODE_MASK  (0x << CSC_COV_MODE_SHIFT)
+#define CSC_BT601_IMAGE_RGB2YCBCR  0
+#define CSC_BT601_IMAGE_YCBCR2RGB  1
+#define CSC_BT601_VIDEO_RGB2YCBCR  2
+#define CSC_BT601_VIDEO_YCBCR2RGB  3
+#define CSC_BT709_IMAGE_RGB2YCBCR  4
+#define CSC_BT709_IMAGE_YCBCR2RGB  5
+#define CSC_BT709_VIDEO_RGB2YCBCR  6
+#define CSC_BT709_VIDEO_YCBCR2RGB  7
+#define CSC_BT2020_IMAGE_RGB2YCBCR 8
+#define CSC_BT2020_IMAGE_YCBCR2RGB 9
+#define CSC_BT2020_VIDEO_RGB2YCBCR 10
+#define CSC_BT2020_VIDEO_YCBCR2RGB 11
+#define CSC_WORK_ENABLEBIT(0)
+
+#endif /* __ZX_COMMON_REGS_H__ */
diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
index d646ac931663..4a6252720c10 100644
--- a/drivers/gpu/drm/zte/zx_plane.c
+++ b/drivers/gpu/drm/zte/zx_plane.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 
+#include "zx_common_regs.h"
 #include "zx_drm_drv.h"
 #include "zx_plane.h"
 #include "zx_plane_regs.h"
diff --git a/drivers/gpu/drm/zte/zx_plane_regs.h 
b/drivers/gpu/drm/zte/zx_plane_regs.h
index 65f271aeabed..9c655f59f9f7 100644
--- a/drivers/gpu/drm/zte/zx_plane_regs.h
+++ b/drivers/gpu/drm/zte/zx_plane_regs.h
@@ -77,24 +77,6 @@
 #define LUMA_STRIDE(x)  (((x) << LUMA_STRIDE_SHIFT) & LUMA_STRIDE_MASK)
 #define CHROMA_STRIDE(x) (((x) << CHROMA_STRIDE_SHIFT) & CHROMA_STRIDE_MASK)
 
-/* CSC registers */
-#define CSC_CTRL0  0x30
-#define CSC_COV_MODE_SHIFT 16
-#define CSC_COV_MODE_MASK  (0x << CSC_COV_MODE_SHIFT)
-#define CSC_BT601_IMAGE_RGB2YCBCR  0
-#define CSC_BT601_IMAGE_YCBCR2RGB  1
-#define CSC_BT601_VIDEO_RGB2YCBCR  2
-#define CSC_BT601_VIDEO_YCBCR2RGB  3
-#define CSC_BT709_IMAGE_RGB2YCBCR  4
-#define CSC_BT709_IMAGE_YCBCR2RGB  5
-#define CSC_BT709_VIDEO_RGB2YCBCR  6
-#define CSC_BT709_VIDEO_YCBCR2RGB  7
-#define CSC_BT2020_IMAGE_RGB2YCBCR 8
-#define CSC_BT2020_IMAGE_YCBCR2RGB 9
-#define CSC_BT2020_VIDEO_RGB2YCBCR 10
-#define CSC_BT2020_VIDEO_YCBCR2RGB 11
-#define CSC_WORK_ENABLEBIT(0)
-
 /* RSZ registers */
 #define RSZ_SRC_CFG0x00
 #define RSZ_DEST_CFG   0x04
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/4] dt-bindings: display: add support for ZTE VGA device

2017-04-06 Thread Shawn Guo
From: Shawn Guo 

It adds bindings doc for ZTE VOU VGA output device.

Signed-off-by: Shawn Guo 
---
 .../devicetree/bindings/display/zte,vou.txt | 21 +
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt 
b/Documentation/devicetree/bindings/display/zte,vou.txt
index 9c356284232b..38476475fd60 100644
--- a/Documentation/devicetree/bindings/display/zte,vou.txt
+++ b/Documentation/devicetree/bindings/display/zte,vou.txt
@@ -58,6 +58,18 @@ Required properties:
integer cells.  The first cell is the offset of SYSCTRL register used
to control TV Encoder DAC power, and the second cell is the bit mask.
 
+* VGA output device
+
+Required properties:
+ - compatible: should be "zte,zx296718-vga"
+ - reg: Physical base address and length of the VGA device IO region
+ - interrupts : VGA interrupt number to CPU
+ - clocks: Phandle with clock-specifier pointing to VGA I2C clock.
+ - clock-names: Must be "i2c_wclk".
+ - zte,vga-power-control: the phandle to SYSCTRL block followed by two
+   integer cells.  The first cell is the offset of SYSCTRL register used
+   to control VGA DAC power, and the second cell is the bit mask.
+
 Example:
 
 vou: vou@144 {
@@ -81,6 +93,15 @@ vou: vou@144 {
  "main_wclk", "aux_wclk";
};
 
+   vga: vga@8000 {
+   compatible = "zte,zx296718-vga";
+   reg = <0x8000 0x1000>;
+   interrupts = ;
+   clocks = < VGA_I2C_WCLK>;
+   clock-names = "i2c_wclk";
+   zte,vga-power-control = < 0x170 0xe0>;
+   };
+
hdmi: hdmi@c000 {
compatible = "zte,zx296718-hdmi";
reg = <0xc000 0x4000>;
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/4] Add ZTE VGA driver support

2017-04-06 Thread Shawn Guo
From: Shawn Guo 

The series adds the driver for ZTE VGA device, which becomes the third
VOU output device we support, besides the existing HDMI and TV Encoder.

Changes for v2:
 - Add return check for encoder and connector init function calls.
 - Improve comments in function zx_vga_irq_handler() to avoid confusion.
 - Add lock for VGA_AUTO_DETECT_SEL register access to avoid race
   condition between irq handler and .get_modes hook.
 - Copy device tree maintainer and list for bindings doc.

Shawn Guo (4):
  drm: zte: do not enable clock auto-gating by default
  drm: zte: move CSC register definitions into a common header
  dt-bindings: display: add support for ZTE VGA device
  drm: zte: add VGA driver support

 .../devicetree/bindings/display/zte,vou.txt|  21 +
 drivers/gpu/drm/zte/Makefile   |   1 +
 drivers/gpu/drm/zte/zx_common_regs.h   |  31 ++
 drivers/gpu/drm/zte/zx_drm_drv.c   |   1 +
 drivers/gpu/drm/zte/zx_drm_drv.h   |   1 +
 drivers/gpu/drm/zte/zx_plane.c |   1 +
 drivers/gpu/drm/zte/zx_plane_regs.h|  18 -
 drivers/gpu/drm/zte/zx_vga.c   | 530 +
 drivers/gpu/drm/zte/zx_vga_regs.h  |  36 ++
 drivers/gpu/drm/zte/zx_vou.c   |  36 +-
 drivers/gpu/drm/zte/zx_vou_regs.h  |  12 +-
 11 files changed, 663 insertions(+), 25 deletions(-)
 create mode 100644 drivers/gpu/drm/zte/zx_common_regs.h
 create mode 100644 drivers/gpu/drm/zte/zx_vga.c
 create mode 100644 drivers/gpu/drm/zte/zx_vga_regs.h

-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: drm-next-misc merge breaks vmwgfx

2017-04-06 Thread Daniel Vetter
On Thu, Apr 6, 2017 at 4:56 PM, Thomas Hellstrom  wrote:
> On 04/06/2017 04:47 PM, Daniel Vetter wrote:
>> On Thu, Apr 6, 2017 at 4:10 PM, Thomas Hellstrom  
>> wrote:
>>> Also, when testing the tip of drm-misc-next (with the non-atomic vmwgfx)
>>> there appeared to be warnings about a non-NULL
>>> dev->mode_config.acquire_ctx. I'll see if I can reproduce those, but
>>> perhaps removing the line
>>>
>>> dev->mode_config.acquire_ctx = 
>>>
>>> in drm_mode_setcrtc()
>>>
>>> is part of the problem.
>> Hm, where do you hit that? And by tip of drm-misc-next, do you mean
>> the very latest state, which includes atomic vmwgfx, or is this with
>> the non-atomic vmwgfx? Please paste the backtraces (and for which tree
>> they are).
>> -Daniel
>
> Actually this must have been from a confused rebase-bisect state
> somewhere. I can't reproduce this.

Have you changed CONFIG_DEBUG_WW_MUTEX_SLOWPATH perhaps? Without this
you shouldn't be able to hit any retry path (so minus warnings the
patch you bisected won't have an affected), with you will hit the
deadlock retry paths pseudo-randomly. It might take a few trials to
hit it again, depending upon timing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   >