[Bug 89072] Radeon Hawaii no acceleration on 32-bit kernel

2015-03-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89072

--- Comment #6 from Woody Suwalski  ---
Also did a sanity test on Nvidia 50 and Radon 635, no new problems noticed.
Alex, if you think that glxgears test is a sufficient proof, we can close this
bug.

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


[PATCH] drm/exynos: fix typo config name correctly.

2015-03-06 Thread Inki Dae
This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index a5e7461..0a67803 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI

 config DRM_EXYNOS_DP
bool "EXYNOS DRM DP driver support"
-   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7DECON) && ARCH_EXYNOS && 
(DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
+   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON) && ARCH_EXYNOS && 
(DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
default DRM_EXYNOS
select DRM_PANEL
help
-- 
1.7.9.5



[PATCH] drm/exynos: Check for NULL dereference of crtc

2015-03-06 Thread Inki Dae
On 2015년 02월 18일 02:14, Charles Keepax wrote:
> The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
> use of the enabled flag, which means that the code may attempt to call
> win_enable on a NULL crtc. This results in the following oops on

Hmm... it's strange. plane->funcs->destroy() is called prior to
crtc->funcs->destroy() so it should be exynos_crtc is not NULL. However,
it seems there is any corner case we didn't catch up.

Applied.

Thanks,
Inki Dae

> Arndale:
> 
> [1.673479] Unable to handle kernel NULL pointer dereference at virtual 
> address 0368
> [1.681500] pgd = c0004000
> [1.684154] [0368] *pgd=
> [1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [1.693012] Modules linked in:
> [1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
> 3.19.0-07545-g57485fa #1907
> [1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> ()
> [2.014803] [] (exynos_plane_destroy) from [] 
> (drm_mode_config_cleanup+0x168/0x20c)
> [2.024178] [] (drm_mode_config_cleanup) from [] 
> (exynos_drm_load+0xac/0x12c)
> 
> This patch adds in a check to ensure exynos_crtc is not NULL before it
> is dereferenced.
> 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index 2dfb847..78fc0a1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -176,7 +176,7 @@ static int exynos_disable_plane(struct drm_plane *plane)
>   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc);
>  
> - if (exynos_crtc->ops->win_disable)
> + if (exynos_crtc && exynos_crtc->ops->win_disable)
>   exynos_crtc->ops->win_disable(exynos_crtc,
> exynos_plane->zpos);
>  
> 



[PATCH] drm: fix sysfs symlinks between driver and module

2015-03-06 Thread Akinobu Mita
When registering drivers, the symlinks for mapping between driver
and module are created in sysfs.  But the drm drivers registered
by drm_pci_init() create wrong symlinks, because correct owner
module of pci driver is not passed to pci_register_driver().

For example, the i915 driver creates the following wrong symlinks:

/sys/bus/pci/drivers/i915/module -> ../../../../module/drm
/sys/module/drm/drivers/pci:i915 -> ../../../bus/pci/drivers/i915

With this change, these symlinks are fixed:

/sys/bus/pci/drivers/i915/module -> ../../../../module/i915
/sys/module/i915/drivers/pci:i915 -> ../../../bus/pci/drivers/i915

Signed-off-by: Akinobu Mita 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_pci.c | 14 +-
 include/drm/drmP.h|  5 -
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index fd29f03..e093a11 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -318,16 +318,19 @@ err_free:
 EXPORT_SYMBOL(drm_get_pci_dev);

 /**
- * drm_pci_init - Register matching PCI devices with the DRM subsystem
+ * __drm_pci_init - Register matching PCI devices with the DRM subsystem
  * @driver: DRM device driver
  * @pdriver: PCI device driver
+ * @owner: owner module of pdriver
+ * @mod_name: module name string
  *
  * Initializes a drm_device structures, registering the stubs and initializing
  * the AGP device.
  *
  * Return: 0 on success or a negative error code on failure.
  */
-int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver)
+int __drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver,
+  struct module *owner, const char *mod_name)
 {
struct pci_dev *pdev = NULL;
const struct pci_device_id *pid;
@@ -336,7 +339,7 @@ int drm_pci_init(struct drm_driver *driver, struct 
pci_driver *pdriver)
DRM_DEBUG("\n");

if (driver->driver_features & DRIVER_MODESET)
-   return pci_register_driver(pdriver);
+   return __pci_register_driver(pdriver, owner, mod_name);

/* If not using KMS, fall back to stealth mode manual scanning. */
INIT_LIST_HEAD(&driver->legacy_dev_list);
@@ -404,7 +407,8 @@ EXPORT_SYMBOL(drm_pcie_get_speed_cap_mask);

 #else

-int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver)
+int __drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver,
+  struct module *owner, const char *mod_name)
 {
return -1;
 }
@@ -425,7 +429,7 @@ int drm_pci_set_unique(struct drm_device *dev,
 }
 #endif

-EXPORT_SYMBOL(drm_pci_init);
+EXPORT_SYMBOL(__drm_pci_init);

 /**
  * drm_pci_exit - Unregister matching PCI devices from the DRM subsystem
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e928625..8a06d9d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1034,7 +1034,10 @@ static __inline__ int drm_pci_device_is_agp(struct 
drm_device *dev)
 }
 void drm_pci_agp_destroy(struct drm_device *dev);

-extern int drm_pci_init(struct drm_driver *driver, struct pci_driver *pdriver);
+extern int __drm_pci_init(struct drm_driver *driver, struct pci_driver 
*pdriver,
+ struct module *owner, const char *mod_name);
+#define drm_pci_init(driver, pdriver) \
+   __drm_pci_init(driver, pdriver, THIS_MODULE, KBUILD_MODNAME)
 extern void drm_pci_exit(struct drm_driver *driver, struct pci_driver 
*pdriver);
 #ifdef CONFIG_PCI
 extern int drm_get_pci_dev(struct pci_dev *pdev,
-- 
1.9.1



[git pull] drm fixes

2015-03-06 Thread Dave Airlie

Hi Linus,

radeon, imx, msm, i915 fixes,

the msm, imx and i915 ones are fairly run of the mill,

radeon had some DP audio and posting reads for irq fixes,
along with a fix for 32-bit kernels with new cards, we were
using unsigned long to represent GPU side memory space, but
since that changed size on 32 vs 64 cards with lots of VRAM failed,
so the change has no effect on x86-64, just moves to using uint64_t
instead.

Dave.

The following changes since commit 13a7a6ac0a11197edcd0f756a035f472b42cdf8b:

  Linux 4.0-rc2 (2015-03-03 09:04:59 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to f6bec6ea6816ece9d229c4d37c44e3222de14044:

  Merge tag 'drm-intel-fixes-2015-03-05' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-03-07 07:40:17 
+1000)



Alex Deucher (15):
  drm/radeon: fix the audio dpms callbacks
  drm/radeon: assign pin in detect
  drm/radeon/audio: set mute around state setup
  drm/radeon: don't toggle audio state in modeset
  drm/radeon/audio: update EDID derived fields in modeset
  drm/radeon: properly set dto for dp on DCE4/5
  drm/radeon: adjust audio callback order
  drm/radeon: do a posting read in r100_set_irq
  drm/radeon: do a posting read in rs600_set_irq
  drm/radeon: do a posting read in r600_set_irq
  drm/radeon: do a posting read in evergreen_set_irq
  drm/radeon: do a posting read in si_set_irq
  drm/radeon: do a posting read in cik_set_irq
  drm/radeon: fix interlaced modes on DCE8
  drm/ttm: device address space != CPU address space

Chris Wilson (1):
  drm/i915: Check for driver readyness before handling an underrun interrupt

Daniel Vetter (1):
  drm/rockchip: Flip select/depends in Kconfig

Dave Airlie (6):
  Merge tag 'imx-drm-fixes-2015-02-24' of 
git://git.pengutronix.de/git/pza/linux into drm-fixes
  Revert "drm/rockchip: Flip select/depends in Kconfig"
  Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Merge branch 'msm-fixes-4.0' of 
git://people.freedesktop.org/~robclark/linux into drm-fixes
  Merge tag 'v4.0-rc2' into drm-fixes
  Merge tag 'drm-intel-fixes-2015-03-05' of 
git://anongit.freedesktop.org/drm-intel into drm-fixes

Imre Deak (1):
  drm/i915: gen4: work around hang during hibernation

Laurent Pinchart (1):
  drm/msm/atomic: Don't leak atomic commit object when commit fails

Liu Ying (1):
  DRM: i.MX: parallel display: Support probe deferral for finding DRM panel

Philipp Zabel (4):
  gpu: ipu-v3: do not divide by zero if the pixel clock is too large
  drm/imx: dw_hdmi-imx: add mode_valid callback prune unsupported modes
  drm/imx: dw_hdmi-imx: add end of array element to current control array
  drm/imx: imx-ldb: enable DI clock in encoder_mode_set

Rob Clark (3):
  drm/msm/mdp5: fix cursor ROI
  drm/msm/mdp5: fix cursor blending
  drm/msm: kexec fixes

Slava Grigorev (2):
  radeon/audio: fix whitespace
  radeon/audio: fix DP audio on DCE6

Stephane Viau (3):
  drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
  drm/msm: update generated headers (add 6th lm.base entry)
  drm/msm/mdp5: Avoid flushing registers when CRTC is disabled

Thierry Reding (1):
  drm/mm: Support 4 GiB and larger ranges

Tommi Rantala (1):
  drm/radeon: fix DRM_IOCTL_RADEON_CS oops

 drivers/gpu/drm/drm_mm.c| 152 +++-
 drivers/gpu/drm/i915/i915_debugfs.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c |  30 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |   6 +-
 drivers/gpu/drm/i915/intel_fifo_underrun.c  |  18 ++--
 drivers/gpu/drm/imx/dw_hdmi-imx.c   |  36 ++-
 drivers/gpu/drm/imx/imx-ldb.c   |  28 +++--
 drivers/gpu/drm/imx/parallel-display.c  |   5 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c |   5 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h |  15 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  99 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |   6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c |   5 +
 drivers/gpu/drm/msm/msm_atomic.c|   4 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   2 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |   3 +
 drivers/gpu/drm/radeon/atombios_encoders.c  |  30 +++---
 drivers/gpu/drm/radeon/cik.c|   3 +
 drivers/gpu/drm/radeon/dce6_afmt.c  |  68 ++---
 drivers/gpu/drm/radeon/evergreen.c  |   3 +
 drivers/gpu/drm/radeon/evergreen_hdmi.c |  59 ---
 drivers/gpu/drm/radeon/r100.c   |   4 +
 drivers/gpu/drm/radeon/r600.c   |   3 +
 drivers/gpu/drm/radeon/r600_hdmi.c  |  11 --
 drivers/gpu/drm/radeon/radeon_audio.c   |  50 +
 drivers/gpu/drm/radeo

[patch] drm/exynos: IS_ERR() vs NULL bug

2015-03-06 Thread Inki Dae
On 2015년 02월 20일 19:54, Dan Carpenter wrote:
> of_iomap() doesn't return error pointers, it returns NULL on error.

Applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 63f02e2..9700461 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -888,8 +888,8 @@ static int decon_probe(struct platform_device *pdev)
>   of_node_put(i80_if_timings);
>  
>   ctx->regs = of_iomap(dev->of_node, 0);
> - if (IS_ERR(ctx->regs)) {
> - ret = PTR_ERR(ctx->regs);
> + if (!ctx->regs) {
> + ret = -ENOMEM;
>   goto err_del_component;
>   }
>  
> 



[PATCH] drm/exynos: remove unused files

2015-03-06 Thread Inki Dae
On 2015년 02월 18일 20:17, Andrzej Hajda wrote:
> These files are not used anymore.

Applied.

Thanks,
Inki Dae

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_connector.c | 245 
> --
>  drivers/gpu/drm/exynos/exynos_drm_connector.h |  20 ---
>  2 files changed, 265 deletions(-)
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.c
>  delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_connector.h
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> deleted file mode 100644
> index ba9b3d5..000
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ /dev/null
> @@ -1,245 +0,0 @@
> -/*
> - * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> - * Authors:
> - *   Inki Dae 
> - *   Joonyoung Shim 
> - *   Seung-Woo Kim 
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
> - */
> -
> -#include 
> -#include 
> -
> -#include 
> -#include "exynos_drm_drv.h"
> -#include "exynos_drm_encoder.h"
> -#include "exynos_drm_connector.h"
> -
> -#define to_exynos_connector(x)   container_of(x, struct 
> exynos_drm_connector,\
> - drm_connector)
> -
> -struct exynos_drm_connector {
> - struct drm_connectordrm_connector;
> - uint32_tencoder_id;
> - struct exynos_drm_display   *display;
> -};
> -
> -static int exynos_drm_connector_get_modes(struct drm_connector *connector)
> -{
> - struct exynos_drm_connector *exynos_connector =
> - to_exynos_connector(connector);
> - struct exynos_drm_display *display = exynos_connector->display;
> - struct edid *edid = NULL;
> - unsigned int count = 0;
> - int ret;
> -
> - /*
> -  * if get_edid() exists then get_edid() callback of hdmi side
> -  * is called to get edid data through i2c interface else
> -  * get timing from the FIMD driver(display controller).
> -  *
> -  * P.S. in case of lcd panel, count is always 1 if success
> -  * because lcd panel has only one mode.
> -  */
> - if (display->ops->get_edid) {
> - edid = display->ops->get_edid(display, connector);
> - if (IS_ERR_OR_NULL(edid)) {
> - ret = PTR_ERR(edid);
> - edid = NULL;
> - DRM_ERROR("Panel operation get_edid failed %d\n", ret);
> - goto out;
> - }
> -
> - count = drm_add_edid_modes(connector, edid);
> - if (!count) {
> - DRM_ERROR("Add edid modes failed %d\n", count);
> - goto out;
> - }
> -
> - drm_mode_connector_update_edid_property(connector, edid);
> - } else {
> - struct exynos_drm_panel_info *panel;
> - struct drm_display_mode *mode = drm_mode_create(connector->dev);
> - if (!mode) {
> - DRM_ERROR("failed to create a new display mode.\n");
> - return 0;
> - }
> -
> - if (display->ops->get_panel)
> - panel = display->ops->get_panel(display);
> - else {
> - drm_mode_destroy(connector->dev, mode);
> - return 0;
> - }
> -
> - drm_display_mode_from_videomode(&panel->vm, mode);
> - mode->width_mm = panel->width_mm;
> - mode->height_mm = panel->height_mm;
> - connector->display_info.width_mm = mode->width_mm;
> - connector->display_info.height_mm = mode->height_mm;
> -
> - mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> - drm_mode_set_name(mode);
> - drm_mode_probed_add(connector, mode);
> -
> - count = 1;
> - }
> -
> -out:
> - kfree(edid);
> - return count;
> -}
> -
> -static int exynos_drm_connector_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - struct exynos_drm_connector *exynos_connector =
> - to_exynos_connector(connector);
> - struct exynos_drm_display *display = exynos_connector->display;
> - int ret = MODE_BAD;
> -
> - DRM_DEBUG_KMS("%s\n", __FILE__);
> -
> - if (display->ops->check_mode)
> - if (!display->ops->check_mode(display, mode))
> - ret = MODE_OK;
> -
> - return ret;
> -}
> -
> -static struct drm_encoder *exynos_drm_best_encoder(
> - struct drm_connector *connector)
> -{
> - struct drm_device *dev = connector->dev;
> - struct exynos_drm_connector *exynos_connector

[PATCH] drm/radeon: typo in parameter description

2015-03-06 Thread Vincent Batts
"defaul" -> "default"

Signed-off-by: Vincent Batts 
---
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 5d684be..3b00690 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -239,7 +239,7 @@ module_param_named(pcie_gen2, radeon_pcie_gen2, int, 0444);
 MODULE_PARM_DESC(msi, "MSI support (1 = enable, 0 = disable, -1 = auto)");
 module_param_named(msi, radeon_msi, int, 0444);

-MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (defaul 1 = 10 
seconds, 0 = disable)");
+MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default 1 = 10 
seconds, 0 = disable)");
 module_param_named(lockup_timeout, radeon_lockup_timeout, int, 0444);

 MODULE_PARM_DESC(fastfb, "Direct FB access for IGP chips (0 = disable, 1 = 
enable)");
-- 
1.8.4


[PATCH 4/4] drm/msm: Fix default fb var width and height

2015-03-06 Thread h...@codeaurora.org
Hi Rob,

> On Fri, Mar 6, 2015 at 1:12 PM, Rob Clark  wrote:
>> On Thu, Mar 5, 2015 at 3:20 PM, Hai Li  wrote:
>>> The framebuffer var width and height should reflect the size of
>>> framebuffer memory allocated, which is the entire surface size.
>>>
>>> In case of dual DSI connectors with TILE properties, this change
>>> makes the whole image show on the dual DSI panel, instead of
>>> duplicated images on both sides.
>>>
>>> Signed-off-by: Hai Li 
>>> ---
>>>  drivers/gpu/drm/msm/msm_fbdev.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c
>>> b/drivers/gpu/drm/msm/msm_fbdev.c
>>> index df60f65..d3e8b14 100644
>>> --- a/drivers/gpu/drm/msm/msm_fbdev.c
>>> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
>>> @@ -169,7 +169,8 @@ static int msm_fbdev_create(struct drm_fb_helper
>>> *helper,
>>> }
>>>
>>> drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
>>> -   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width,
>>> sizes->fb_height);
>>> +   drm_fb_helper_fill_var(fbi, helper,
>>> +   sizes->surface_width, sizes->surface_height);
>>>
>>
>> so, I believe the intention for separation if surface_width/height and
>> fb_width/height, it to allocate a buffer that is big enough (width and
>> height) for all connected displays (so as to not leave some display
>> scanning out too small of a buffer), but size the fbdev buffer small
>> enough that text would be visible on all screens.  Using
>> surface_width/height here instead of fb_width/height would break that.
>>
>> But I think I have a different idea.. we could implement fb helper
>> func initial_config() to just call drm_pick_crtcs() (which we'd have
>> to export), and then for each of the crtcs[n] connected to a connector
>> with TILE property, populate the offsets[n].x/y.  Or possibly we
>> should just make drm_setup_crtcs() clever enough to do that
>> automatically.. that would result in larger fb_size and the two crtc's
>> scanning out their own parts of the buffer.
>
> Oh, I spoke too soon.. looks like Dave already added it in
> drm_get_tile_offsets()..
>

As discussed in IRC, the TILE information has been set and the framebuffer
is allocated with the full size, not the half.

The problem is, we create the full size framebuffer but only tell the user
(fbcon here, but may be real user space application who will use the
default framebuffer.) the half resolution. I think this mismatch will
cause trouble not only in the case of TILE connectors.

For our specific case of TILE connectors, since the right crtc offset.x
has been set to the half width, while the framebuffer width set to plane
is 0~half_width-1 (got from fb var info), the PIPE takes it wrong settings
and will not fetch the image data from framebuffer.
> BR,
> -R
>




[PATCH] Revert "intel: Fix documentation for drm_intel_gem_bo_wait()"

2015-03-06 Thread Daniel Vetter
This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.

Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).

So lets undo the documentation change for consistency, since working
around kernel regressions isn't good. Practical impact is nil anyway.

v2: Add a note to docs that some kernels have been broken.

v3: Remove the random garbage included by accident.

Cc: Kristian Høgsberg 
Cc: Chris Wilson 
Reviewed-by: Kristian Høgsberg 
Signed-off-by: Daniel Vetter 
---
 intel/intel_bufmgr_gem.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc46242..acbfd4ada209 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1655,14 +1655,12 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  *
  * @bo: buffer object to wait for
  * @timeout_ns: amount of time to wait in nanoseconds.
- *   If value is less than or equal to 0, return immediately.
+ *   If value is less than 0, an infinite wait will occur.
  *
- * Returns 0 if the wait was successful ie. the last batch referencing
- * the object has completed within the allotted time. Otherwise some
- * negative return value describes the error. Of particular interest
- * is -ETIME when the wait has failed to yield the desired result.
- * Use a timeout of INT64_MAX to wait indefinitely (well, at least 292
- * years).
+ * Returns 0 if the wait was successful ie. the last batch referencing the
+ * object has completed within the allotted time. Otherwise some negative 
return
+ * value describes the error. Of particular interest is -ETIME when the wait 
has
+ * failed to yield the desired result.
  *
  * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows
  * the operation to give up after a certain amount of time. Another subtle
@@ -1675,6 +1673,9 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  * not guarantee that the buffer is re-issued via another thread, or an flinked
  * handle. Userspace must make sure this race does not occur if such precision
  * is important.
+ *
+ * Note that some kernels have broken the inifite wait for negative values
+ * promise, upgrade to latest stable kernels if this is the case.
  */
 drm_public int
 drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
-- 
2.1.4



[PATCH] Revert "intel: Fix documentation for drm_intel_gem_bo_wait()"

2015-03-06 Thread Daniel Vetter
This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.

Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).

So lets undo the documentation change for consistency, since working
around kernel regressions isn't good. Practical impact is nil anyway.

v2: Add a note to docs that some kernels have been broken.

Cc: Kristian Høgsberg 
Cc: Chris Wilson 
Reviewed-by: Kristian Høgsberg 
Signed-off-by: Daniel Vetter 
---
 intel/intel_bufmgr_gem.c | 15 ---
 xf86drmMode.c| 13 -
 2 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc46242..acbfd4ada209 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1655,14 +1655,12 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  *
  * @bo: buffer object to wait for
  * @timeout_ns: amount of time to wait in nanoseconds.
- *   If value is less than or equal to 0, return immediately.
+ *   If value is less than 0, an infinite wait will occur.
  *
- * Returns 0 if the wait was successful ie. the last batch referencing
- * the object has completed within the allotted time. Otherwise some
- * negative return value describes the error. Of particular interest
- * is -ETIME when the wait has failed to yield the desired result.
- * Use a timeout of INT64_MAX to wait indefinitely (well, at least 292
- * years).
+ * Returns 0 if the wait was successful ie. the last batch referencing the
+ * object has completed within the allotted time. Otherwise some negative 
return
+ * value describes the error. Of particular interest is -ETIME when the wait 
has
+ * failed to yield the desired result.
  *
  * Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows
  * the operation to give up after a certain amount of time. Another subtle
@@ -1675,6 +1673,9 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
  * not guarantee that the buffer is re-issued via another thread, or an flinked
  * handle. Userspace must make sure this race does not occur if such precision
  * is important.
+ *
+ * Note that some kernels have broken the inifite wait for negative values
+ * promise, upgrade to latest stable kernels if this is the case.
  */
 drm_public int
 drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe721842..3a9bb0b6560a 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -477,7 +477,7 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t 
encoder_id)
  * Connector manipulation
  */

-drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+drmModeConnectorPtr __drmModeGetConnector(int fd, uint32_t connector_id, bool 
current)
 {
struct drm_mode_get_connector conn, counts;
drmModeConnectorPtr r = NULL;
@@ -485,6 +485,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t 
connector_id)
 retry:
memclear(conn);
conn.connector_id = connector_id;
+   conn.count_modes = current;

if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, &conn))
return 0;
@@ -572,6 +573,16 @@ err_allocs:
return r;
 }

+drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+{
+   __drmModeGetConnector(fd, connector_id, false);
+}
+
+drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+{
+   __drmModeGetConnector(fd, connector_id, true);
+}
+
 int drmModeAttachMode(int fd, uint32_t connector_id, drmModeModeInfoPtr 
mode_info)
 {
struct drm_mode_mode_cmd res;
-- 
2.1.4



[PULL] drm-intel-next

2015-03-06 Thread Daniel Vetter
Hi Dave,

drm-intel-next-2015-02-27:
- Y tiling support for scanout from Tvrtko&Damien
- Remove more UMS support
- some small prep patches for OLR removal from John Harrison
- first few patches for dynamic pagetable allocation from Ben Widawsky, rebased
  by tons of other people
- DRRS support patches (Sonika&Vandana)
- fbc patches from Paulo
- make sure our vblank callbacks aren't called when the pipes are off
- various patches all over

Also can you perhaps pull -rc3 in while at it? I'd like to rebase and get
all the current fixes into my next queue.

Cheers, Daniel


The following changes since commit d4495cbaa5869d2ce8f4b1c9331d3a19b24eb98b:

  drm/i915: Update DRIVER_DATE to 20150214 (2015-02-14 00:41:35 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-02-27

for you to fetch changes up to f89fe1ffe698a6bb7671ebf99f5bb918fda4cf35:

  drm/i915: Update DRIVER_DATE to 20150227 (2015-02-27 19:12:46 +0100)


- Y tiling support for scanout from Tvrtko&Damien
- Remove more UMS support
- some small prep patches for OLR removal from John Harrison
- first few patches for dynamic pagetable allocation from Ben Widawsky, rebased
  by tons of other people
- DRRS support patches (Sonika&Vandana)
- fbc patches from Paulo
- make sure our vblank callbacks aren't called when the pipes are off
- various patches all over


Akash Goel (1):
  drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions

Ander Conselvan de Oliveira (1):
  drm/i915: Look at staged config when fixing pipe_src_w for LVDS

Ben Widawsky (3):
  drm/i915: page table abstractions
  drm/i915: Complete page table structures
  drm/i915: Create page table allocators

Chris Wilson (2):
  drm/i915: Trim the command parser allocations
  drm/i915: Clarify obj->map_and_fenceable

Damien Lespiau (7):
  drm/i915/skl: Implement WaDisablePowerCompilerClockGating
  drm/i915/skl: Tune IZ hashing when subslices are unbalanced
  drm/i915/skl: Make sure to allocate mininum sizes in the DDB
  drm/i915/skl: Allow scanning out Y and Yf fbs
  drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling
  drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints
  drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling

Dan Carpenter (2):
  drm/i915: cleanup some indenting
  drm/i915: fix a printk format

Daniel Vetter (13):
  drm/irq: Add drm_crtc_vblank_reset
  drm/i915: Drop pipe_enable checks in vblank funcs
  drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c
  drm/i915: Switch to drm_crtc variants of vblank functions
  drm/irq: Don't call ->get_vblank_counter directly from 
irq_uninstall/cleanup
  drm: WARN if drm_handle_vblank is called errornously
  drm/i915: Remove DRIVER_MODESET checks in load/unload/close code
  drm/i915: Remove DRIVER_MODESET checks from suspend/resume code
  drm/i915: Remove DRIVER_MODESET checks in the gpu reset code
  drm/i915: Remove DRIVER_MODESET checks from gem code
  drm/i915: Remove regfile code&data for UMS suspend/resume
  drm/i915: Remove DRIVER_MODESET checks from modeset code
  drm/i915: Update DRIVER_DATE to 20150227

Dave Gordon (1):
  drm/i915: FIFO space query code refactor

Durgadoss R (1):
  drm/i915: Enable eDP DRRS for CHV

Jeff McGee (3):
  drm/i915/skl: Determine SKL slice/subslice/EU info
  drm/i915/skl: Add SKL HW status to SSEU status
  drm/i915: Request full SSEU enablement on Gen9

John Harrison (3):
  drm/i915: Rename 'flags' to 'dispatch_flags' for better code reading
  drm/i915: Add missing trace point to LRC execbuff code path
  drm/i915: Cache ringbuf pointer in request structure

Matt Roper (2):
  drm/i915: Use enabled value from crtc_state rather than crtc (v2)
  drm/i915: Ensure crtc_state backpointer is always initialized

Michel Thierry (2):
  drm/i915: Plumb drm_device through page tables operations
  drm/i915: Add missing description to parameter in alloc_pt_range

Paulo Zanoni (4):
  drm/i915: extract intel_fbc_find_crtc()
  drm/i915: HSW+ FBC is tied to pipe A
  drm/i915: gen5+ can have FBC with multiple pipes
  drm/i915: don't reallocate the compressed FB at every frame

Ramalingam C (2):
  drm/i915: Add support for DRRS in intel_dp_set_m_n
  drm/i915: Enhancing eDP DRRS debug message

Sonika Jindal (2):
  drm/i915/skl: Support for edp low_vswing param in vbt
  drm/i915/skl: Add support for edp1.4 low vswing

Thomas Daniel (2):
  drm/i915: Reset logical ring contexts' head and tail during GPU reset
  drm/i915: Shift driver's HWSP usage out of reserved range

Tvrtko Ursulin (4):
  drm/i915/skl: Add new displayable tiling formats
  drm/i915/skl: Updated watermark progr

[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

2015-03-06 Thread Jyri Sarha
On 03/06/15 17:36, Tony Lindgren wrote:
> * Jyri Sarha  [150306 07:37]:
>> Use new binding for the external tda19988 HDMI encoder.
>
> Can this be merged separately after the driver code is
> merged with things still working?
>

Yes absolutely. That is why DRM_TILCDC_SLAVE_COMPAT is there for.

Cheers,
Jyri


[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

2015-03-06 Thread Jyri Sarha
Use new binding for the external tda19988 HDMI encoder.

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

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@

 &lcdc {
status = "okay";
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
 };

-/ {
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
+&i2c0 {
+   tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
-   status = "okay";
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
 };

-- 
1.9.1



[PATCH v2 6/7] drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT

2015-03-06 Thread Jyri Sarha
If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_SLAVE_COMPAT are not linked, if DRM_TILCDC is
built as module.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..ad7f10f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
-- 
1.9.1



[PATCH v2 5/7] drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti, tilcdc, slave binding support

2015-03-06 Thread Jyri Sarha
Adds a CONFIG_DRM_TILCDC_SLAVE_COMPAT module for "ti,tilcdc,slave"
node conversion. The implementation is in tilcdc_slave_compat.c and it
uses tilcdc_slave_compat.dts as a basis for creating a DTS
overlay. The DTS overlay adds an external tda998x encoder to tilcdc
that corresponds to the old tda998x based slave encoder.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig |  13 ++
 drivers/gpu/drm/tilcdc/Makefile|   3 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 +
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 +++
 4 files changed, 358 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..7e1e72b 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,15 @@
+config DRM_TILCDC_SLAVE_COMPAT
+   bool "Support device tree blobs using TI LCDC Slave binding"
+   depends on DRM_TILCDC
+   default y
+   select OF_RESOLVE
+   select OF_OVERLAY
+   help
+ Choose this option if you need a kernel that is compatible
+ with device tree blobs using the obsolete "ti,tilcdc,slave"
+ binding. If you find "ti,tilcdc,slave"-string from your DTB,
+ you probably need this. Otherwise you do not.
+
 config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM && HAVE_DMA_ATTRS
@@ -8,6 +20,7 @@ config DRM_TILCDC
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
+   select DRM_TILCDC_INIT
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..deeca48 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,9 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
 endif

+obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \
+tilcdc_slave_compat.dtb.o
+
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
new file mode 100644
index 000..cc9572d
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+/*
+ * To support the old "ti,tilcdc,slave" binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct kfree_table {
+   int total;
+   int num;
+   void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+   kft->total = 32;
+   kft->num = 0;
+   kft->table = kmalloc(kft->total * sizeof(*kft->table),
+GFP_KERNEL);
+   if (!kft->table)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+   if (kft->num == kft->total) {
+   void **old = kft->table;
+
+   kft->total *= 2;
+   kft->table = krealloc(old, kft->total * sizeof(*kft->table),
+ GFP_KERNEL);
+   if (!kft->table) {
+   kft->table = old;
+   kfree(p);
+   return -ENOMEM;
+   }
+   }
+   kft->table[kft->num++] = p;
+   return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+   int i;
+
+   for (i = 0; i < kft->num; i++)
+   kfree(kft->table[i]);
+
+   kfree(kft->table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+   struct property *nprop;
+
+   nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+   if (!nprop || kfree_table_add(kft, nprop))
+   return NULL;
+
+   nprop->name = kstrdup(prop->name, GFP_KERNEL);
+   if (!nprop->name || kfree_table_add(kft, nprop->name))
+   return NULL;
+
+   nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
+   if (!nprop->value || kfree_table_add(kft, nprop->value))
+   return NULL;
+
+   nprop->length = prop->length;
+
+   return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,

[PATCH v2 4/7] drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint

2015-03-06 Thread Jyri Sarha
This patch should be dropped/reverterd if/after "of: Decrement refcount
of previous endpoint in of_graph_get_next_endpoint" patch has been
merged.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 61f8aee..1dd6c20 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -83,6 +83,7 @@ int tilcdc_get_external_components(struct device *dev,
struct device_node *node;

node = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
if (!node && !of_device_is_available(node)) {
of_node_put(node);
continue;
-- 
1.9.1



[PATCH v2 3/7] drm/tilcdc: Add support for external tda998x encoder

2015-03-06 Thread Jyri Sarha
Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The current
implementation supports only tda998x encoder.

I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  33 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  76 ---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   4 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 104 +
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 +
 7 files changed, 256 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.

+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+   binding follows Documentation/devicetree/bindings/graph.txt and
+   suppors a single port with a single endpoint.
+
 Example:

fb: fb at 4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+   port {
+   lcdc_0: endpoint at 0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
+   };
+
+   tda19988: tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+
+   pinctrl-names = "default", "off";
+   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+   pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+   port {
+   hdmi_0: endpoint at 0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+   tilcdc_external.o \
tilcdc_drv.o

 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {

/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+   /* Only set if an external encoder is connected */
+   bool simulate_vesa_sync;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   if (!tilcdc_crtc->simulate_vesa_sync)
+   return true;
+
+   /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+   adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+   adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+   adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+   } else {
+   adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+   }
+
return true;
 }

@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
 }

+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+   bool simulate_vesa_sync)
+{
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
 void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
diff --git a/driver

[PATCH v2 2/7] drm/tilcdc: Remove tilcdc slave support for tda998x driver

2015-03-06 Thread Jyri Sarha
Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 drivers/gpu/drm/tilcdc/Makefile|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 6 files changed, 470 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
-   };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
-   tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"

 #include "drm_fb_helper.h"

 static LIST_HEAD(module_list);
-static bool slave_probing;

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
 }

-void tilcdc_slave_probedefer(bool defered)
-{
-   slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];

 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}

-   /* defer probing if slave is in deferred probing */
-   if (slave_probing == true)
-   return -EPROBE_DEFER;
-
return drm_platform_init(&tilcdc_driver, pdev);
 }

@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
-   tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
 }
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
platform_driver_unregister(&tilcdc_platform_driver);
tilcdc_panel_fini();
-   tilcdc_slave_fini();
tilcdc_tfp410_fini();
 }

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);

 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have r

[PATCH v2 1/7] drm/tilcdc: Fix module unloading

2015-03-06 Thread Jyri Sarha
Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
 }

+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);

-   WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);

drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
-- 
1.9.1



[PATCH v2 0/7] Use DRM component API in tilcdc to connect to tda998x

2015-03-06 Thread Jyri Sarha
Changes since first version of the patch-set:
- Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
- Add separate: 
  drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
- Reduce info-level spam
- Use component_master_add_with_match()
- Be more explicit about tda998x being the only supported external encoder

Remove tilcdc slave support and connect to tda998x trough its
component DRM API. For dtb backward compatibility the code creates at
boot time a DT overlay based on the earlier binding. The overlay
conforms to the new graph based binding.

The first patch is just a bugfix and can be applied or dropped
independently.

Jyri Sarha (7):
  drm/tilcdc: Fix module unloading
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Add support for external tda998x encoder
  drm/tilcdc: Decrement refcount of ep-node from
of_graph_get_next_endpoint
  drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
support
  drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT
  ARM: dts: am335x-boneblack: Use new binding for HDMI

 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  20 +-
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tilcdc/Kconfig |  13 +
 drivers/gpu/drm/tilcdc/Makefile|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  36 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  89 +++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   5 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 105 ++
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c   | 270 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts |  72 
 15 files changed, 633 insertions(+), 489 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts

-- 
1.9.1



[RFC v2 3/7] cec: add new framework for cec support.

2015-03-06 Thread Kamil Debski
Hi Sean, Hans,

I am sorry to reply so late, I was busy with other work. I am preparing the
next version
of the CEC framework and I would like to discuss your comment.

From: Sean Young [mailto:s...@mess.org]
Sent: Friday, January 23, 2015 12:08 PM
> 
> On Thu, Jan 22, 2015 at 05:04:35PM +0100, Kamil Debski wrote:
> > Add the CEC framework.
> -snip-
> > +Remote control handling
> > +---
> > +
> > +The CEC framework provides two ways of handling the key messages of
> > +remote control. In the first case, the CEC framework will handle
> > +these messages and provide the keypressed via the RC framework. In
> > +the second case the messages related to the key down/up events are
> > +not parsed by the framework and are passed to the userspace as raw
> messages.
> > +
> > +Switching between these modes is done with a special ioctl.
> > +
> > +#define CEC_G_KEY_PASSTHROUGH  _IOR('a', 10, __u8)
> > +#define CEC_S_KEY_PASSTHROUGH  _IOW('a', 11, __u8)
> > +#define CEC_KEY_PASSTHROUGH_DISABLE0
> > +#define CEC_KEY_PASSTHROUGH_ENABLE 1
> 
> This is ugly. This ioctl stops keypresses from going to rc-core. The
> cec device is still registered with rc-core but no keys will be passed
> to it.
> This could also be handled by loading an empty keymap; this way the
> input layer will still receive scancodes but no keypresses.

I see here a few options that can be done:

1) Remove the past through option altogether
I think I would opt for leaving it. There should be some mode that would
enable
raw access to the CEC bus. Maybe it should be something more like a
promiscuous mode
in Wi-Fi networks. What do you think? Sean, Hans?

2) Leave the pass through mode, but without disabling passing the keyup/down
events to
the RC framework. This way an application could capture all messages, but
the input device
would not be crippled in any way. The problem with this solution is that key
presses could
be accounted twice.

3) As you suggested - load an empty keymap whenever the pass through mode is
enabled.
I am not that familiar with the RC core. Is there a simple way to switch to
an empty map
from the kernel? There is the ir_setkeytable function, but it is static in
rc-main.c, so it
cannot be used in other kernel modules. Any hints, Sean?

4) Remove the input device whenever a pass through mode is enabled. This is
an alternative to
the solution number 3. I think it would not be great, because a
/dev/input/event* that appears
and disappears could be confusing.

> 
> > +static ssize_t cec_read(struct file *filp, char __user *buf,
> > +   size_t sz, loff_t *off)
> > +{
> > +   struct cec_devnode *cecdev = cec_devnode_data(filp);
> > +
> > +   if (!cec_devnode_is_registered(cecdev))
> > +   return -EIO;
> > +   return 0;
> > +}
> > +
> > +static ssize_t cec_write(struct file *filp, const char __user *buf,
> > +   size_t sz, loff_t *off)
> > +{
> > +   struct cec_devnode *cecdev = cec_devnode_data(filp);
> > +
> > +   if (!cec_devnode_is_registered(cecdev))
> > +   return -EIO;
> > +   return 0;
> > +}
> 
> Both read and write do nothing; they should either -ENOSYS or the
> fuctions should be removed.
> 

I agree, I removed this for the next version.

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland




[PATCH 0/2] PCI: pci_unignore_hotplug()

2015-03-06 Thread Alex Deucher
On Fri, Mar 6, 2015 at 1:49 PM, Bjorn Helgaas  wrote:
> On Tue, Feb 24, 2015 at 03:23:27PM -0500, Alex Deucher wrote:
>> On Tue, Feb 24, 2015 at 3:12 PM, Alex Williamson
>>  wrote:
>> > I'd kinda like to use pci_ignore_hotplug() for devices in use by a
>> > user via vfio-pci, but the interface seems only partially implemented
>> > since we can only set ignore_hotplug and not clear it.  This adds the
>> > capability to clear the flag and applies it as seems to be appropriate
>> > to the existing users.  I don't have a system with power control for
>> > a radeon or nouveau device, so I'd certainly appreciate testing.  It
>> > seems though that once the device is in D0, we've passed the critical
>> > point where the device could be accidentally unplugged.  Thanks,
>>
>> Something re-broke this recently.  See:
>> https://bugzilla.kernel.org/show_bug.cgi?id=61891
>> https://bugzilla.kernel.org/show_bug.cgi?id=89731
>
> I'm not opposed to adding pci_unignore_hotplug() when we have users for it.
> I don't really want to throw in the nouveau and radeon changes while there
> are open issues in the same area, though.
>
> I haven't looked at the bugzillas above.  Let me know if I should.

Please do.  My comments were not targeted at this patch set, but
rather at the fact that pci hotplug (acpiphp in this case) is again
trying to remove the driver even though it's flagged to ignore hotplug
in the hybrid laptop case.

Alex


[PATCH libdrm] proptest: install it with --enable-install-test-programs

2015-03-06 Thread Daniel Kurtz
--enable-install-test-programs allows tests to be installed in $bindir.
This is disabled by default, but very useful when cross compiling.

Signed-off-by: Daniel Kurtz 
---
 tests/proptest/Makefile.am | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
index 48a84c1..0594e02 100644
--- a/tests/proptest/Makefile.am
+++ b/tests/proptest/Makefile.am
@@ -3,8 +3,13 @@ AM_CFLAGS = \
-I$(top_srcdir)/include/drm \
-I$(top_srcdir)

+if HAVE_INSTALL_TESTS
+bin_PROGRAMS = \
+   proptest
+else
 noinst_PROGRAMS = \
proptest
+endif

 proptest_SOURCES = \
proptest.c
-- 
2.2.0.rc0.207.ga3a616c



[PATCH libdrm] tests: add rockchip to modetest, kmstest, vbltest and proptest

2015-03-06 Thread Daniel Kurtz
There is a rockchip drm kms driver.
Add "rockchip" to the static lists of driver names in the the standard
set of tests.

Signed-off-by: Daniel Kurtz 
---
 tests/kmstest/main.c  | 1 +
 tests/modetest/modetest.c | 2 +-
 tests/proptest/proptest.c | 2 +-
 tests/vbltest/vbltest.c   | 2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 2c87b1c..fb22354 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -63,6 +63,7 @@ char *drivers[] = {
"vmwgfx",
"exynos",
"imx-drm",
+   "rockchip",
NULL
 };

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 425e528..5f46efd 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1453,7 +1453,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
int test_cursor = 0;
-   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm" };
+   const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", 
"omapdrm", "exynos", "tilcdc", "msm", "sti", "tegra", "imx-drm", "rockchip" };
char *device = NULL;
char *module = NULL;
unsigned int i;
diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
index 7618f63..a6011bf 100644
--- a/tests/proptest/proptest.c
+++ b/tests/proptest/proptest.c
@@ -303,7 +303,7 @@ static void printUsage(void)

 int main(int argc, char *argv[])
 {
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
"msm" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "omapdrm", 
"msm", "rockchip" };
unsigned int i, ret = 0;

for (i = 0; i < ARRAY_SIZE(modules); i++){
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 916d494..136d8f4 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -106,7 +106,7 @@ int main(int argc, char **argv)
 {
unsigned i;
int c, fd, ret;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
"omapdrm", "tilcdc", "msm", "tegra", "imx-drm" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx", "exynos", 
"omapdrm", "tilcdc", "msm", "tegra", "imx-drm", "rockchip" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
2.2.0.rc0.207.ga3a616c



[PATCH 5/5] drm/fb: handle tiled connectors better

2015-03-06 Thread Rob Clark
We don't want tile 0,0 to artificially constrain the size of the legacy
fbdev device.  Instead when reducing fb_size to be the minimum of all
displays, only consider the rightmost and bottommost tiles.

Signed-off-by: Rob Clark 
Tested-by: Hai Li 
---
 drivers/gpu/drm/drm_fb_helper.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5ec3849..182f04a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1034,9 +1034,16 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
crtc_count = 0;
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
-   int x, y;
+   struct drm_mode_set *mode_set;
+   int x, y, j;
+   /* in case of tile group, are we the last tile vert or horiz?
+* If no tile group you are always the last one both vertically
+* and horizontally
+*/
+   bool lastv = true, lasth = true;

desired_mode = fb_helper->crtc_info[i].desired_mode;
+   mode_set = &fb_helper->crtc_info[i].mode_set;

if (!desired_mode)
continue;
@@ -1051,8 +1058,21 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,

sizes.surface_width  = max_t(u32, desired_mode->hdisplay + x, 
sizes.surface_width);
sizes.surface_height = max_t(u32, desired_mode->vdisplay + y, 
sizes.surface_width);
-   sizes.fb_width  = min_t(u32, desired_mode->hdisplay + x, 
sizes.fb_width);
-   sizes.fb_height = min_t(u32, desired_mode->vdisplay + y, 
sizes.fb_height);
+
+   for (j = 0; j < mode_set->num_connectors; j++) {
+   struct drm_connector *connector = 
mode_set->connectors[j];
+   if (connector->has_tile) {
+   lasth = (connector->tile_h_loc == 
(connector->num_h_tile - 1));
+   lastv = (connector->tile_v_loc == 
(connector->num_v_tile - 1));
+   /* cloning to multiple tiles is just 
crazy-talk, so: */
+   break;
+   }
+   }
+
+   if (lasth)
+   sizes.fb_width  = min_t(u32, desired_mode->hdisplay + 
x, sizes.fb_width);
+   if (lastv)
+   sizes.fb_height = min_t(u32, desired_mode->vdisplay + 
y, sizes.fb_height);
}

if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
-- 
2.1.0



[PATCH 4/5] drm/fb: small cleanup

2015-03-06 Thread Rob Clark
Flip conditional to reduce indentation level of rest of fxn, and use
min/max to make the code clearer.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_fb_helper.c | 28 +++-
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1e6a0c7..5ec3849 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1035,22 +1035,24 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_display_mode *desired_mode;
int x, y;
+
desired_mode = fb_helper->crtc_info[i].desired_mode;
+
+   if (!desired_mode)
+   continue;
+
+   crtc_count++;
+
x = fb_helper->crtc_info[i].x;
y = fb_helper->crtc_info[i].y;
-   if (desired_mode) {
-   if (gamma_size == 0)
-   gamma_size = 
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
-   if (desired_mode->hdisplay + x < sizes.fb_width)
-   sizes.fb_width = desired_mode->hdisplay + x;
-   if (desired_mode->vdisplay + y < sizes.fb_height)
-   sizes.fb_height = desired_mode->vdisplay + y;
-   if (desired_mode->hdisplay + x > sizes.surface_width)
-   sizes.surface_width = desired_mode->hdisplay + 
x;
-   if (desired_mode->vdisplay + y > sizes.surface_height)
-   sizes.surface_height = desired_mode->vdisplay + 
y;
-   crtc_count++;
-   }
+
+   if (gamma_size == 0)
+   gamma_size = 
fb_helper->crtc_info[i].mode_set.crtc->gamma_size;
+
+   sizes.surface_width  = max_t(u32, desired_mode->hdisplay + x, 
sizes.surface_width);
+   sizes.surface_height = max_t(u32, desired_mode->vdisplay + y, 
sizes.surface_width);
+   sizes.fb_width  = min_t(u32, desired_mode->hdisplay + x, 
sizes.fb_width);
+   sizes.fb_height = min_t(u32, desired_mode->vdisplay + y, 
sizes.fb_height);
}

if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
-- 
2.1.0



[PATCH 3/5] drm/rockchip: use correct fb width/height

2015-03-06 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index a5d889a8..ff04877 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -106,7 +106,7 @@ static int rockchip_drm_fbdev_create(struct drm_fb_helper 
*helper,

fb = helper->fb;
drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
-   drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height);
+   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);

offset = fbi->var.xoffset * bytes_per_pixel;
offset += fbi->var.yoffset * fb->pitches[0];
-- 
2.1.0



[PATCH 2/5] drm/exynos: use correct fb width/height

2015-03-06 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 84f8dfe..e71e331 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -76,6 +76,7 @@ static struct fb_ops exynos_drm_fb_ops = {
 };

 static int exynos_drm_fbdev_update(struct drm_fb_helper *helper,
+struct drm_fb_helper_surface_size *sizes,
 struct drm_framebuffer *fb)
 {
struct fb_info *fbi = helper->fbdev;
@@ -85,7 +86,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
unsigned long offset;

drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
-   drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height);
+   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);

/* RGB formats use only one buffer */
buffer = exynos_drm_fb_buffer(fb, 0);
@@ -189,7 +190,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
*helper,
goto err_destroy_framebuffer;
}

-   ret = exynos_drm_fbdev_update(helper, helper->fb);
+   ret = exynos_drm_fbdev_update(helper, sizes, helper->fb);
if (ret < 0)
goto err_dealloc_cmap;

-- 
2.1.0



[PATCH 1/5] drm/cma: use correct fb width/height

2015-03-06 Thread Rob Clark
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index cc0ae04..5c1aca4 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -304,7 +304,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper 
*helper,
}

drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
-   drm_fb_helper_fill_var(fbi, helper, fb->width, fb->height);
+   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);

offset = fbi->var.xoffset * bytes_per_pixel;
offset += fbi->var.yoffset * fb->pitches[0];
-- 
2.1.0



[PATCH 0/5] drm/fb: handle tile connectors

2015-03-06 Thread Rob Clark
Fix fb_width/height to properly take account tiles (for ex, DP MST).
Also fixes for fb_width/height vs surface_width/height confusion that
I noticed in a handful of drivers.

Rob Clark (5):
  drm/cma: use correct fb width/height
  drm/exynos: use correct fb width/height
  drm/rockchip: use correct fb width/height
  drm/fb: small cleanup
  drm/fb: handle tiled connectors better

 drivers/gpu/drm/drm_fb_cma_helper.c   |  2 +-
 drivers/gpu/drm/drm_fb_helper.c   | 48 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  5 +--
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  2 +-
 4 files changed, 40 insertions(+), 17 deletions(-)

-- 
2.1.0



[PATCH] drm: Lighten sysfs connector 'status'

2015-03-06 Thread Daniel Vetter
On Fri, Mar 06, 2015 at 08:58:40AM -0500, Alex Deucher wrote:
> On Fri, Mar 6, 2015 at 7:36 AM, Chris Wilson  
> wrote:
> > Since the beginning, sysfs/connector/status has done a heavyweight
> > detection of the current connector status. But no user, such as upowerd
> > or logind, has ever desired to initiate a probe. Move the probing into a
> > new attribute so that existing readers get the behaviour they desire.
> >
> > v2: David Herrmann suggested using "echo detect > /sys/.../status" to
> > trigger the probing, which is a fine idea. This extends that to also
> > allow the user to apply the force detection overrides at runtime.
> >
> > v3: Now with airlied's email address fixed! Requires sysfs_streq()
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> > Cc: David Herrmann 
> > Cc: Dave Airlie 
> > Cc: Alex Deucher 
> 
> Reviewed-by: Alex Deucher 

Merged to drm-misc, thanks.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_sysfs.c | 61 
> > +++--
> >  1 file changed, 53 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 5c99d3773212..ffc305fc2076 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -166,23 +166,68 @@ void drm_sysfs_destroy(void)
> >  /*
> >   * Connector properties
> >   */
> > -static ssize_t status_show(struct device *device,
> > +static ssize_t status_store(struct device *device,
> >struct device_attribute *attr,
> > -  char *buf)
> > +  const char *buf, size_t count)
> >  {
> > struct drm_connector *connector = to_drm_connector(device);
> > -   enum drm_connector_status status;
> > +   struct drm_device *dev = connector->dev;
> > +   enum drm_connector_status old_status;
> > int ret;
> >
> > -   ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
> > +   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
> > if (ret)
> > return ret;
> >
> > -   status = connector->funcs->detect(connector, true);
> > -   mutex_unlock(&connector->dev->mode_config.mutex);
> > +   old_status = connector->status;
> > +
> > +   if (sysfs_streq(buf, "detect")) {
> > +   connector->force = 0;
> > +   connector->status = connector->funcs->detect(connector, 
> > true);
> > +   } else if (sysfs_streq(buf, "on")) {
> > +   connector->force = DRM_FORCE_ON;
> > +   } else if (sysfs_streq(buf, "on-digital")) {
> > +   connector->force = DRM_FORCE_ON_DIGITAL;
> > +   } else if (sysfs_streq(buf, "off")) {
> > +   connector->force = DRM_FORCE_OFF;
> > +   } else
> > +   ret = -EINVAL;
> > +
> > +   if (ret == 0 && connector->force) {
> > +   if (connector->force == DRM_FORCE_ON ||
> > +   connector->force == DRM_FORCE_ON_DIGITAL)
> > +   connector->status = connector_status_connected;
> > +   else
> > +   connector->status = connector_status_disconnected;
> > +   if (connector->funcs->force)
> > +   connector->funcs->force(connector);
> > +   }
> > +
> > +   if (old_status != connector->status) {
> > +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> > %d\n",
> > + connector->base.id,
> > + connector->name,
> > + old_status, connector->status);
> > +
> > +   dev->mode_config.delayed_event = true;
> > +   if (dev->mode_config.poll_enabled)
> > +   
> > schedule_delayed_work(&dev->mode_config.output_poll_work,
> > + 0);
> > +   }
> > +
> > +   mutex_unlock(&dev->mode_config.mutex);
> > +
> > +   return ret;
> > +}
> > +
> > +static ssize_t status_show(struct device *device,
> > +  struct device_attribute *attr,
> > +  char *buf)
> > +{
> > +   struct drm_connector *connector = to_drm_connector(device);
> >
> > return snprintf(buf, PAGE_SIZE, "%s\n",
> > -   drm_get_connector_status_name(status));
> > +   drm_get_connector_status_name(connector->status));
> >  }
> >
> >  static ssize_t dpms_show(struct device *device,
> > @@ -339,7 +384,7 @@ static ssize_t select_subconnector_show(struct device 
> > *device,
> > drm_get_dvi_i_select_name((int)subconnector));
> >  }
> >
> > -static DEVICE_ATTR_RO(status);
> > +static DEVICE_ATTR_RW(status);
> >  static DEVICE_ATTR_RO(enabled);
> >  static DEVICE_ATTR_RO(dpms);
> >  static DEVICE_ATTR_RO(modes);
> > --
> > 2.1.4
> >

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


[PATCH libdrm 00/12] Introduce drm_intel_device and use i915_pciid.h

2015-03-06 Thread Damien Lespiau
On Fri, Mar 06, 2015 at 02:10:44PM +, Emil Velikov wrote:
> On 05/03/15 16:20, Damien Lespiau wrote:
> > A couple of things I wanted to do for the longest time:
> >   
> >   - Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy 
> > the
> > file when updating
> >   - Start a new object, struct drm_intel_device where we could put common 
> > code
> > across several userspace projects. For instance it could be where we put
> > the "number of threads" logic we need to use in several 3d/gpgpu
> > states/instructions (that's a bit fiddly starting with CHV: we can't use
> > static tables anymore and need a runtime query to the kernel)
> > 
> Hi Damien,
> 
> So this paves the way to de-duplicate the device information stored in
> beignet, libva-intel-driver, mesa, xf86-video-intel, other ?

I don't expect xf86-video-intel to use this, but otherwise that's the
long term plan (will need a lot more work though).

-- 
Damien


[PATCH libdrm 00/12] Introduce drm_intel_device and use i915_pciid.h

2015-03-06 Thread Emil Velikov
On 05/03/15 16:20, Damien Lespiau wrote:
> A couple of things I wanted to do for the longest time:
>   
>   - Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy the
> file when updating
>   - Start a new object, struct drm_intel_device where we could put common code
> across several userspace projects. For instance it could be where we put
> the "number of threads" logic we need to use in several 3d/gpgpu
> states/instructions (that's a bit fiddly starting with CHV: we can't use
> static tables anymore and need a runtime query to the kernel)
> 
Hi Damien,

So this paves the way to de-duplicate the device information stored in
beignet, libva-intel-driver, mesa, xf86-video-intel, other ?

That's great, thank you :-)
Emil


[PATCH] drm/exynos: Check for NULL dereference of crtc

2015-03-06 Thread Charles Keepax
On Fri, Mar 06, 2015 at 10:13:42PM +0900, Inki Dae wrote:
> On 2015년 02월 18일 02:14, Charles Keepax wrote:
> > The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
> > use of the enabled flag, which means that the code may attempt to call
> > win_enable on a NULL crtc. This results in the following oops on
> 
> Hmm... it's strange. plane->funcs->destroy() is called prior to
> crtc->funcs->destroy() so it should be exynos_crtc is not NULL. However,
> it seems there is any corner case we didn't catch up.
> 
> Applied.

Thanks, it seems the offending path in an error path, looks like
Arndale is missing some required DT setting which causes
exynos_drm_load to fail:

[1.638109] of_graph_get_next_endpoint(): no port node found in 
/dp-controller at 145B
[1.646424] exynos-drm exynos-drm: bound 1440.fimd (ops 
fimd_component_ops)
[1.652704] /dp-controller at 145B: could not find display-timings node
[1.659323] /dp-controller at 145B: no timings specified
[1.664709] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22
[1.671485] exynos-drm exynos-drm: failed to bind 145b.dp-controller 
(ops exynos_dp_ops): -22

Which ends up calling exynos_plane_destroy as part of the clean up:

[1.698655] [] (unwind_backtrace) from [] 
(show_stack+0x20/0x24)
[1.706385] [] (show_stack) from [] 
(dump_stack+0x78/0xc4)
[1.713588] [] (dump_stack) from [] 
(exynos_disable_plane+0x2c/0x60)
[1.721660] [] (exynos_disable_plane) from [] 
(exynos_plane_destroy+0x1c/0x30)
[1.730605] [] (exynos_plane_destroy) from [] 
(drm_mode_config_cleanup+0x168/0x20c)
[1.739982] [] (drm_mode_config_cleanup) from [] 
(exynos_drm_load+0xac/0x12c)
[1.748832] [] (exynos_drm_load) from [] 
(drm_dev_register+0xb0/0x110)
[1.757075] [] (drm_dev_register) from [] 
(drm_platform_init+0x50/0xe0)
[1.765405] [] (drm_platform_init) from [] 
(exynos_drm_bind+0x20/0x28)
[1.773655] [] (exynos_drm_bind) from [] 
(try_to_bring_up_master.part.1+0xd8/0x114)
[1.783027] [] (try_to_bring_up_master.part.1) from [] 
(component_master_add_with_match+0xb4/0x134)
[1.793792] [] (component_master_add_with_match) from [] 
(exynos_drm_platform_probe+0xfc/0x124)
[1.804207] [] (exynos_drm_platform_probe) from [] 
(platform_drv_probe+0x58/0xb4)
[1.813411] [] (platform_drv_probe) from [] 
(driver_probe_device+0x11c/0x23c)
[1.822261] [] (driver_probe_device) from [] 
(__driver_attach+0x9c/0xa0)
[1.830679] [] (__driver_attach) from [] 
(bus_for_each_dev+0x64/0x98)
[1.838838] [] (bus_for_each_dev) from [] 
(driver_attach+0x2c/0x30)
[1.846824] [] (driver_attach) from [] 
(bus_add_driver+0xe8/0x1e4)
[1.854722] [] (bus_add_driver) from [] 
(driver_register+0x88/0x104)
[1.862794] [] (driver_register) from [] 
(__platform_driver_register+0x58/0x6c)
[1.871827] [] (__platform_driver_register) from [] 
(exynos_drm_init+0xc8/0x124)
[1.880936] [] (exynos_drm_init) from [] 
(do_one_initcall+0x90/0x1e0)
[1.889096] [] (do_one_initcall) from [] 
(kernel_init_freeable+0x114/0x1e0)
[1.897779] [] (kernel_init_freeable) from [] 
(kernel_init+0x18/0xfc)
[1.905934] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x34)

Hope that helps some, afraid I am not really familiar enough with
the graphics stack to chase that down much more though.

Thanks,
Charles


[PATCH] drm: Lighten sysfs connector 'status'

2015-03-06 Thread David Herrmann
Hi

On Fri, Mar 6, 2015 at 1:36 PM, Chris Wilson  
wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so that existing readers get the behaviour they desire.
>
> v2: David Herrmann suggested using "echo detect > /sys/.../status" to
> trigger the probing, which is a fine idea. This extends that to also
> allow the user to apply the force detection overrides at runtime.
>
> v3: Now with airlied's email address fixed! Requires sysfs_streq()
>
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: David Herrmann 
> Cc: Dave Airlie 
> Cc: Alex Deucher 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 61 
> +++--
>  1 file changed, 53 insertions(+), 8 deletions(-)

Looks good to me:
Reviewed-by: David Herrmann 

Thanks
David

> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 5c99d3773212..ffc305fc2076 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -166,23 +166,68 @@ void drm_sysfs_destroy(void)
>  /*
>   * Connector properties
>   */
> -static ssize_t status_show(struct device *device,
> +static ssize_t status_store(struct device *device,
>struct device_attribute *attr,
> -  char *buf)
> +  const char *buf, size_t count)
>  {
> struct drm_connector *connector = to_drm_connector(device);
> -   enum drm_connector_status status;
> +   struct drm_device *dev = connector->dev;
> +   enum drm_connector_status old_status;
> int ret;
>
> -   ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
> +   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
> if (ret)
> return ret;
>
> -   status = connector->funcs->detect(connector, true);
> -   mutex_unlock(&connector->dev->mode_config.mutex);
> +   old_status = connector->status;
> +
> +   if (sysfs_streq(buf, "detect")) {
> +   connector->force = 0;
> +   connector->status = connector->funcs->detect(connector, true);
> +   } else if (sysfs_streq(buf, "on")) {
> +   connector->force = DRM_FORCE_ON;
> +   } else if (sysfs_streq(buf, "on-digital")) {
> +   connector->force = DRM_FORCE_ON_DIGITAL;
> +   } else if (sysfs_streq(buf, "off")) {
> +   connector->force = DRM_FORCE_OFF;
> +   } else
> +   ret = -EINVAL;
> +
> +   if (ret == 0 && connector->force) {
> +   if (connector->force == DRM_FORCE_ON ||
> +   connector->force == DRM_FORCE_ON_DIGITAL)
> +   connector->status = connector_status_connected;
> +   else
> +   connector->status = connector_status_disconnected;
> +   if (connector->funcs->force)
> +   connector->funcs->force(connector);
> +   }
> +
> +   if (old_status != connector->status) {
> +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + connector->base.id,
> + connector->name,
> + old_status, connector->status);
> +
> +   dev->mode_config.delayed_event = true;
> +   if (dev->mode_config.poll_enabled)
> +   
> schedule_delayed_work(&dev->mode_config.output_poll_work,
> + 0);
> +   }
> +
> +   mutex_unlock(&dev->mode_config.mutex);
> +
> +   return ret;
> +}
> +
> +static ssize_t status_show(struct device *device,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> +   struct drm_connector *connector = to_drm_connector(device);
>
> return snprintf(buf, PAGE_SIZE, "%s\n",
> -   drm_get_connector_status_name(status));
> +   drm_get_connector_status_name(connector->status));
>  }
>
>  static ssize_t dpms_show(struct device *device,
> @@ -339,7 +384,7 @@ static ssize_t select_subconnector_show(struct device 
> *device,
> drm_get_dvi_i_select_name((int)subconnector));
>  }
>
> -static DEVICE_ATTR_RO(status);
> +static DEVICE_ATTR_RW(status);
>  static DEVICE_ATTR_RO(enabled);
>  static DEVICE_ATTR_RO(dpms);
>  static DEVICE_ATTR_RO(modes);
> --
> 2.1.4
>


[PATCH 4/4] drm/msm: Fix default fb var width and height

2015-03-06 Thread Rob Clark
On Fri, Mar 6, 2015 at 1:12 PM, Rob Clark  wrote:
> On Thu, Mar 5, 2015 at 3:20 PM, Hai Li  wrote:
>> The framebuffer var width and height should reflect the size of
>> framebuffer memory allocated, which is the entire surface size.
>>
>> In case of dual DSI connectors with TILE properties, this change
>> makes the whole image show on the dual DSI panel, instead of
>> duplicated images on both sides.
>>
>> Signed-off-by: Hai Li 
>> ---
>>  drivers/gpu/drm/msm/msm_fbdev.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c 
>> b/drivers/gpu/drm/msm/msm_fbdev.c
>> index df60f65..d3e8b14 100644
>> --- a/drivers/gpu/drm/msm/msm_fbdev.c
>> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
>> @@ -169,7 +169,8 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
>> }
>>
>> drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
>> -   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, 
>> sizes->fb_height);
>> +   drm_fb_helper_fill_var(fbi, helper,
>> +   sizes->surface_width, sizes->surface_height);
>>
>
> so, I believe the intention for separation if surface_width/height and
> fb_width/height, it to allocate a buffer that is big enough (width and
> height) for all connected displays (so as to not leave some display
> scanning out too small of a buffer), but size the fbdev buffer small
> enough that text would be visible on all screens.  Using
> surface_width/height here instead of fb_width/height would break that.
>
> But I think I have a different idea.. we could implement fb helper
> func initial_config() to just call drm_pick_crtcs() (which we'd have
> to export), and then for each of the crtcs[n] connected to a connector
> with TILE property, populate the offsets[n].x/y.  Or possibly we
> should just make drm_setup_crtcs() clever enough to do that
> automatically.. that would result in larger fb_size and the two crtc's
> scanning out their own parts of the buffer.

Oh, I spoke too soon.. looks like Dave already added it in
drm_get_tile_offsets()..

BR,
-R


[PATCH 4/4] drm/msm: Fix default fb var width and height

2015-03-06 Thread Rob Clark
On Thu, Mar 5, 2015 at 3:20 PM, Hai Li  wrote:
> The framebuffer var width and height should reflect the size of
> framebuffer memory allocated, which is the entire surface size.
>
> In case of dual DSI connectors with TILE properties, this change
> makes the whole image show on the dual DSI panel, instead of
> duplicated images on both sides.
>
> Signed-off-by: Hai Li 
> ---
>  drivers/gpu/drm/msm/msm_fbdev.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
> index df60f65..d3e8b14 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -169,7 +169,8 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
> }
>
> drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
> -   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, 
> sizes->fb_height);
> +   drm_fb_helper_fill_var(fbi, helper,
> +   sizes->surface_width, sizes->surface_height);
>

so, I believe the intention for separation if surface_width/height and
fb_width/height, it to allocate a buffer that is big enough (width and
height) for all connected displays (so as to not leave some display
scanning out too small of a buffer), but size the fbdev buffer small
enough that text would be visible on all screens.  Using
surface_width/height here instead of fb_width/height would break that.

But I think I have a different idea.. we could implement fb helper
func initial_config() to just call drm_pick_crtcs() (which we'd have
to export), and then for each of the crtcs[n] connected to a connector
with TILE property, populate the offsets[n].x/y.  Or possibly we
should just make drm_setup_crtcs() clever enough to do that
automatically.. that would result in larger fb_size and the two crtc's
scanning out their own parts of the buffer.

BR,
-R

> dev->mode_config.fb_base = paddr;
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>


[PATCH 0/2] PCI: pci_unignore_hotplug()

2015-03-06 Thread Bjorn Helgaas
On Tue, Feb 24, 2015 at 03:23:27PM -0500, Alex Deucher wrote:
> On Tue, Feb 24, 2015 at 3:12 PM, Alex Williamson
>  wrote:
> > I'd kinda like to use pci_ignore_hotplug() for devices in use by a
> > user via vfio-pci, but the interface seems only partially implemented
> > since we can only set ignore_hotplug and not clear it.  This adds the
> > capability to clear the flag and applies it as seems to be appropriate
> > to the existing users.  I don't have a system with power control for
> > a radeon or nouveau device, so I'd certainly appreciate testing.  It
> > seems though that once the device is in D0, we've passed the critical
> > point where the device could be accidentally unplugged.  Thanks,
> 
> Something re-broke this recently.  See:
> https://bugzilla.kernel.org/show_bug.cgi?id=61891
> https://bugzilla.kernel.org/show_bug.cgi?id=89731

I'm not opposed to adding pci_unignore_hotplug() when we have users for it.
I don't really want to throw in the nouveau and radeon changes while there
are open issues in the same area, though.

I haven't looked at the bugzillas above.  Let me know if I should.

Bjorn


[PATCH] drm: Lighten sysfs connector 'status'

2015-03-06 Thread Chris Wilson
Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing readers get the behaviour they desire.

v2: David Herrmann suggested using "echo detect > /sys/.../status" to
trigger the probing, which is a fine idea. This extends that to also
allow the user to apply the force detection overrides at runtime.

v3: Now with airlied's email address fixed! Requires sysfs_streq()

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: David Herrmann 
Cc: Dave Airlie 
Cc: Alex Deucher 
---
 drivers/gpu/drm/drm_sysfs.c | 61 +++--
 1 file changed, 53 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 5c99d3773212..ffc305fc2076 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -166,23 +166,68 @@ void drm_sysfs_destroy(void)
 /*
  * Connector properties
  */
-static ssize_t status_show(struct device *device,
+static ssize_t status_store(struct device *device,
   struct device_attribute *attr,
-  char *buf)
+  const char *buf, size_t count)
 {
struct drm_connector *connector = to_drm_connector(device);
-   enum drm_connector_status status;
+   struct drm_device *dev = connector->dev;
+   enum drm_connector_status old_status;
int ret;

-   ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
+   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
if (ret)
return ret;

-   status = connector->funcs->detect(connector, true);
-   mutex_unlock(&connector->dev->mode_config.mutex);
+   old_status = connector->status;
+
+   if (sysfs_streq(buf, "detect")) {
+   connector->force = 0;
+   connector->status = connector->funcs->detect(connector, true);
+   } else if (sysfs_streq(buf, "on")) {
+   connector->force = DRM_FORCE_ON;
+   } else if (sysfs_streq(buf, "on-digital")) {
+   connector->force = DRM_FORCE_ON_DIGITAL;
+   } else if (sysfs_streq(buf, "off")) {
+   connector->force = DRM_FORCE_OFF;
+   } else
+   ret = -EINVAL;
+
+   if (ret == 0 && connector->force) {
+   if (connector->force == DRM_FORCE_ON ||
+   connector->force == DRM_FORCE_ON_DIGITAL)
+   connector->status = connector_status_connected;
+   else
+   connector->status = connector_status_disconnected;
+   if (connector->funcs->force)
+   connector->funcs->force(connector);
+   }
+
+   if (old_status != connector->status) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+ connector->base.id,
+ connector->name,
+ old_status, connector->status);
+
+   dev->mode_config.delayed_event = true;
+   if (dev->mode_config.poll_enabled)
+   
schedule_delayed_work(&dev->mode_config.output_poll_work,
+ 0);
+   }
+
+   mutex_unlock(&dev->mode_config.mutex);
+
+   return ret;
+}
+
+static ssize_t status_show(struct device *device,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct drm_connector *connector = to_drm_connector(device);

return snprintf(buf, PAGE_SIZE, "%s\n",
-   drm_get_connector_status_name(status));
+   drm_get_connector_status_name(connector->status));
 }

 static ssize_t dpms_show(struct device *device,
@@ -339,7 +384,7 @@ static ssize_t select_subconnector_show(struct device 
*device,
drm_get_dvi_i_select_name((int)subconnector));
 }

-static DEVICE_ATTR_RO(status);
+static DEVICE_ATTR_RW(status);
 static DEVICE_ATTR_RO(enabled);
 static DEVICE_ATTR_RO(dpms);
 static DEVICE_ATTR_RO(modes);
-- 
2.1.4



[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

2015-03-06 Thread Jyri Sarha
On 03/06/15 11:58, Russell King - ARM Linux wrote:
> On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
>> Would it be Ok to add a check that master->ops->add_components is defined,
>> before calling it in find_componets() (drivers/base/component.c:120) and
>> return 0 if it is not?
>
> No:
>
> http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h=8c4e8764a7e3
>
> also:
>
> http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=11eda5aaf41e
>
> is what's planned to be merged when I can get a round tuit, and people
> stop using the old methods.
>

Ok, but could it still be allowed to add a master without any components 
(match == NULL)?

Or do I have to handle the configurations without any components separately?

Best regards,
Jyri


[Beignet] [PATCH] drm/i915: Export total subslice and EU counts

2015-03-06 Thread Jeff McGee
On Thu, Mar 05, 2015 at 12:35:55PM +0800, Zhigang Gong wrote:
> There is one minor conflict when apply the KMD patch to latest
> drm-intel-nightly branch. It should be easy to fix.
> 
> Another issue is that IMO, we should bump libdrm's version number
> when increase these new APIs. Then in Beignet, we can check the
> libdrm version at build time and determine whether we will use
> these new interfaces. Thus, we can avoid breaking beignet on
> those systems which have previous libdrm/kernel installed.
> 
> The other parts of the whole patchset,
> including patches for KMD/libdrm/Intel gpu tools and Beignet,
> all look good to me.
> 
> And I just tested it on BDW and SKL platforms, it works fine.
> 

Can you add your Reviewed-by tag to at least the Beignet patches?
I think Daniel wants to see that before moving forward with the
rest. Thanks

Jeff

> Thanks,
> Zhigang Gong.
> 
> On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> > From: Jeff McGee 
> > 
> > Setup new I915_GETPARAM ioctl entries for subslice total and
> > EU total. Userspace drivers need these values when constructing
> > GPGPU commands. This kernel query method is intended to replace
> > the PCI ID-based tables that userspace drivers currently maintain.
> > The kernel driver can employ fuse register reads as needed to
> > ensure the most accurate determination of GT config attributes.
> > This first became important with Cherryview in which the config
> > could differ between devices with the same PCI ID.
> > 
> > The kernel detection of these values is device-specific and not
> > included in this patch. Because zero is not a valid value for any of
> > these parameters, a value of zero is interpreted as unknown for the
> > device. Userspace drivers should continue to maintain ID-based tables
> > for older devices not supported by the new query method.
> > 
> > For: VIZ-4636
> > Signed-off-by: Jeff McGee 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c | 10 ++
> >  include/uapi/drm/i915_drm.h |  2 ++
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 053e178..9350ea2 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -150,6 +150,16 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> > case I915_PARAM_MMAP_VERSION:
> > value = 1;
> > break;
> > +   case I915_PARAM_SUBSLICE_TOTAL:
> > +   value = INTEL_INFO(dev)->subslice_total;
> > +   if (!value)
> > +   return -ENODEV;
> > +   break;
> > +   case I915_PARAM_EU_TOTAL:
> > +   value = INTEL_INFO(dev)->eu_total;
> > +   if (!value)
> > +   return -ENODEV;
> > +   break;
> > default:
> > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > return -EINVAL;
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 6eed16b..8672efc 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -347,6 +347,8 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
> >  #define I915_PARAM_MMAP_VERSION  30
> >  #define I915_PARAM_HAS_BSD2 31
> > +#define I915_PARAM_SUBSLICE_TOTAL   32
> > +#define I915_PARAM_EU_TOTAL 33
> >  
> >  typedef struct drm_i915_getparam {
> > int param;
> > -- 
> > 2.3.0
> > 
> > ___
> > Beignet mailing list
> > Beignet at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/beignet
> ___
> Beignet mailing list
> Beignet at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/beignet


[Beignet] [PATCH] drm/i915: Export total subslice and EU counts

2015-03-06 Thread Jeff McGee
On Thu, Mar 05, 2015 at 12:35:55PM +0800, Zhigang Gong wrote:
> There is one minor conflict when apply the KMD patch to latest
> drm-intel-nightly branch. It should be easy to fix.
> 
> Another issue is that IMO, we should bump libdrm's version number
> when increase these new APIs. Then in Beignet, we can check the
> libdrm version at build time and determine whether we will use
> these new interfaces. Thus, we can avoid breaking beignet on
> those systems which have previous libdrm/kernel installed.
> 
Right. I can append a libdrm patch to bump the version. And then I
suppose I will follow the process to make a new release. Not sure
right now how that works. First time going through it.

Also, how should we test for the libdrm version and conditionally
use the API? Is there a previous example of this in Beignet that I
could follow?

Jeff

> The other parts of the whole patchset,
> including patches for KMD/libdrm/Intel gpu tools and Beignet,
> all look good to me.
> 
> And I just tested it on BDW and SKL platforms, it works fine.
> 
> Thanks,
> Zhigang Gong.
> 
> On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> > From: Jeff McGee 
> > 
> > Setup new I915_GETPARAM ioctl entries for subslice total and
> > EU total. Userspace drivers need these values when constructing
> > GPGPU commands. This kernel query method is intended to replace
> > the PCI ID-based tables that userspace drivers currently maintain.
> > The kernel driver can employ fuse register reads as needed to
> > ensure the most accurate determination of GT config attributes.
> > This first became important with Cherryview in which the config
> > could differ between devices with the same PCI ID.
> > 
> > The kernel detection of these values is device-specific and not
> > included in this patch. Because zero is not a valid value for any of
> > these parameters, a value of zero is interpreted as unknown for the
> > device. Userspace drivers should continue to maintain ID-based tables
> > for older devices not supported by the new query method.
> > 
> > For: VIZ-4636
> > Signed-off-by: Jeff McGee 
> > ---
> >  drivers/gpu/drm/i915/i915_dma.c | 10 ++
> >  include/uapi/drm/i915_drm.h |  2 ++
> >  2 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 053e178..9350ea2 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -150,6 +150,16 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> > case I915_PARAM_MMAP_VERSION:
> > value = 1;
> > break;
> > +   case I915_PARAM_SUBSLICE_TOTAL:
> > +   value = INTEL_INFO(dev)->subslice_total;
> > +   if (!value)
> > +   return -ENODEV;
> > +   break;
> > +   case I915_PARAM_EU_TOTAL:
> > +   value = INTEL_INFO(dev)->eu_total;
> > +   if (!value)
> > +   return -ENODEV;
> > +   break;
> > default:
> > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > return -EINVAL;
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 6eed16b..8672efc 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -347,6 +347,8 @@ typedef struct drm_i915_irq_wait {
> >  #define I915_PARAM_HAS_COHERENT_PHYS_GTT 29
> >  #define I915_PARAM_MMAP_VERSION  30
> >  #define I915_PARAM_HAS_BSD2 31
> > +#define I915_PARAM_SUBSLICE_TOTAL   32
> > +#define I915_PARAM_EU_TOTAL 33
> >  
> >  typedef struct drm_i915_getparam {
> > int param;
> > -- 
> > 2.3.0
> > 
> > ___
> > Beignet mailing list
> > Beignet at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/beignet
> ___
> Beignet mailing list
> Beignet at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/beignet


[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

2015-03-06 Thread Russell King - ARM Linux
On Fri, Mar 06, 2015 at 12:21:42PM +0200, Jyri Sarha wrote:
> On 03/06/15 11:58, Russell King - ARM Linux wrote:
> >On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> >>Would it be Ok to add a check that master->ops->add_components is defined,
> >>before calling it in find_componets() (drivers/base/component.c:120) and
> >>return 0 if it is not?
> >
> >No:
> >
> >http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h=8c4e8764a7e3
> >
> >also:
> >
> >http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=11eda5aaf41e
> >
> >is what's planned to be merged when I can get a round tuit, and people
> >stop using the old methods.
> >
> 
> Ok, but could it still be allowed to add a master without any components
> (match == NULL)?
> 
> Or do I have to handle the configurations without any components separately?

That's not a decision I want to make in my current state.  Give me a
couple of week or two and re-ping me.

http://archive.arm.linux.org.uk/lurker/message/20150306.102749.fcabd2bf.en.html

(and the reason becomes self-evident when you realise that message did
not go to the right list on Tuesday evening when it was meant to.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.


[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

2015-03-06 Thread Jyri Sarha
On 03/02/15 18:01, Russell King - ARM Linux wrote:
> On Thu, Feb 26, 2015 at 04:55:32PM +0200, Jyri Sarha wrote:
>> +ret = component_bind_all(dev->dev, dev);
>> +if (ret < 0) {
>> +dev_err(dev->dev, "Binding subcomponents failed: %d\n", ret);
>
> Do you need to print this?  The component helper is already fairly
> verbose about what succeeds and fails.
>

Will remove.

>> +static const struct component_master_ops tilcdc_comp_ops = {
>> +.add_components = tilcdc_add_external_components,
>
> I'd much rather you used the new matching support rather than using the
> old .add_components.  The new matching support is more efficient as you
> only have to scan DT once, rather than each time we try to probe.  That
> will mean...
>

That is otherwise fine, but with the match code it not possible to 
implement a master that may not have any components.

Would it be Ok to add a check that master->ops->add_components is 
defined, before calling it in find_componets() 
(drivers/base/component.c:120) and return 0 if it is not?

Best regards,
Jyri

>> @@ -613,12 +643,12 @@ static int tilcdc_pdev_probe(struct platform_device 
>> *pdev)
>>  return -ENXIO;
>>  }
>
> You need to build a struct component_match array here using
> component_match_add()...
>
>>
>> -return drm_platform_init(&tilcdc_driver, pdev);
>> +return component_master_add(&pdev->dev, &tilcdc_comp_ops);
>
> and then finally register the ops with component_master_add_with_match().
>
> Thanks.
>



[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

2015-03-06 Thread jianwei.w...@freescale.com


> -Original Message-
> From: Stefan Agner [mailto:stefan at agner.ch]
> Sent: Wednesday, March 04, 2015 11:04 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> Scott-B07421; Xiubo Li; Wang Huan-B18965; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver
> 
> On 2015-02-13 12:03, Jianwei Wang wrote:
> > This patch add support for Two Dimensional Animation and Compositing
> > Engine (2D-ACE) on the Freescale LS102x SoCs.
> >
> > 2D-ACE is a Freescale display controller. It supports at most four
> > plane and provide an hardware cursor.
> >
> > This is a simplified version, only a primary plane, a fb created for
> > fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> > encoder is not in use. Now this drver support fbdev only.
> 
> Hi,
> 
> Do you know if that driver also works on Vybrid devices? Vybrid has also
> DCU4 module with 2D-ACE functionality, also the registers look pretty
> similar. I was thinking about creating a driver for Vybrid anyway...
> 
> Some remarks below...
> 

Hi,

As you say the display IP module on ls1021a and Vybrid device are all 2D-ACE, 
so I think this driver also works on Vybrid devices. I'd like to do something
for the compatibility.

> "FB Driver" probably refers more to a fbdev driver in the Linux kernel
> sense, but since this is a DRM driver this is somewhat confusing. The
> binding should describe the hardware, in the Vybrid RM mentions the IP as
> "Display Control Unit (DCU4)", so maybe
> 
> Freescale Display Controller Unit (DCU4) module
> 
> Also, instead of using dcfb, I would use somewhat more hardware
> describing, e.g. dcu4?
> 
> > +
> > +Required properties:
> > +- compatible:  Should be one of "fsl,ls1021a-dcfb".
> 
> If the driver also works for Vybrid, be favorable to have a generic
> compatible string, e.g. fsl,dcu4?

Thank you for your comments, I'll modify it.

> > +   regmap_write(fsl_dev->scfg_regmap, 0x28, 0x8000);
> 
> What does this actually do? I don't think this exists in Vybrid, but I
> guess we could easily make the property optional which would then not
> call this function...
> 
> --
> Stefan

This is a platform related register. I would move it to platform related
file (arch/arm/mach-imx/mach-ls1021a.c).

Regards,
Jianwei

> 
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Xiubo Li 
> > Signed-off-by: Jianwei Wang 
> > ---
> >  .../devicetree/bindings/video/fsl,dcfb.txt |  50 +++
> >  drivers/gpu/drm/Kconfig|   2 +
> >  drivers/gpu/drm/Makefile   |   1 +
> >  drivers/gpu/drm/fsl/Kconfig|  17 +
> >  drivers/gpu/drm/fsl/Makefile   |   7 +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 412
> +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  40 ++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 323
> 
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 167 +
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  43 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  45 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  22 ++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 124 +++
> >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  28 ++
> >  14 files changed, 1281 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/video/fsl,dcfb.txt
> >  create mode 100644 drivers/gpu/drm/fsl/Kconfig  create mode 100644
> > drivers/gpu/drm/fsl/Makefile  create mode 100644
> > drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
> >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> >
> > diff --git a/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > new file mode 100644
> > index 000..de7da97
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > @@ -0,0 +1,50 @@
> > +* Freescale Simple Display Controller FB Driver
> 
> "FB Driver" probably refers more to a fbdev driver in the Linux kernel
> sense, but since this is a DRM driver this is somewhat confusing. The
> binding should describe the hardware, in the Vybrid RM mentions the IP as
> "Display Control Unit (DCU4)", so maybe
> 
> Freescale Display Controller Unit (DCU4) module
> 
> Also, instead of using dcfb, I would use somewhat more hardware
> d

[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

2015-03-06 Thread Russell King - ARM Linux
On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> Would it be Ok to add a check that master->ops->add_components is defined,
> before calling it in find_componets() (drivers/base/component.c:120) and
> return 0 if it is not?

No:

http://ftp.arm.linux.org.uk/cgit/linux-arm.git/commit/?h=8c4e8764a7e3

also:

http://ftp.arm.linux.org.uk/cgit/linux-arm.git/log/?h=11eda5aaf41e

is what's planned to be merged when I can get a round tuit, and people
stop using the old methods.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.


[PATCH] drm/radeon: fix wait to actually occur after the signaling callback

2015-03-06 Thread Alex Deucher
On Tue, Mar 3, 2015 at 3:56 AM, Maarten Lankhorst
 wrote:
> A normal wait adds to the front of the tail. By doing something
> similar to fence_default_wait the fence code can run without racing.
>
> This is a complete fix for "panic on suspend from KDE with radeon",
> and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
> si_irq_set needs to be fixed too, to completely flush the writes
> before radeon_fence_activity is called in radeon_fence_enable_signaling.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861
> Signed-off-by: Maarten Lankhorst 
> Reported-by: Jon Arne Jørgensen 
> Reported-and-tested-by: Gustaw Smolarczyk 
> Cc: stable at vger.kernel.org (v3.18+)

Added to my -fixes queue.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_fence.c | 68 
> +++
>  1 file changed, 45 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index d13d1b5a859f..df09ca7c4889 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -1030,37 +1030,59 @@ static inline bool radeon_test_signaled(struct 
> radeon_fence *fence)
> return test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->base.flags);
>  }
>
> +struct radeon_wait_cb {
> +   struct fence_cb base;
> +   struct task_struct *task;
> +};
> +
> +static void
> +radeon_fence_wait_cb(struct fence *fence, struct fence_cb *cb)
> +{
> +   struct radeon_wait_cb *wait =
> +   container_of(cb, struct radeon_wait_cb, base);
> +
> +   wake_up_process(wait->task);
> +}
> +
>  static signed long radeon_fence_default_wait(struct fence *f, bool intr,
>  signed long t)
>  {
> struct radeon_fence *fence = to_radeon_fence(f);
> struct radeon_device *rdev = fence->rdev;
> -   bool signaled;
> +   struct radeon_wait_cb cb;
>
> -   fence_enable_sw_signaling(&fence->base);
> +   cb.task = current;
>
> -   /*
> -* This function has to return -EDEADLK, but cannot hold
> -* exclusive_lock during the wait because some callers
> -* may already hold it. This means checking needs_reset without
> -* lock, and not fiddling with any gpu internals.
> -*
> -* The callback installed with fence_enable_sw_signaling will
> -* run before our wait_event_*timeout call, so we will see
> -* both the signaled fence and the changes to needs_reset.
> -*/
> +   if (fence_add_callback(f, &cb.base, radeon_fence_wait_cb))
> +   return t;
> +
> +   while (t > 0) {
> +   if (intr)
> +   set_current_state(TASK_INTERRUPTIBLE);
> +   else
> +   set_current_state(TASK_UNINTERRUPTIBLE);
> +
> +   /*
> +* radeon_test_signaled must be called after
> +* set_current_state to prevent a race with wake_up_process
> +*/
> +   if (radeon_test_signaled(fence))
> +   break;
> +
> +   if (rdev->needs_reset) {
> +   t = -EDEADLK;
> +   break;
> +   }
> +
> +   t = schedule_timeout(t);
> +
> +   if (t > 0 && intr && signal_pending(current))
> +   t = -ERESTARTSYS;
> +   }
> +
> +   __set_current_state(TASK_RUNNING);
> +   fence_remove_callback(f, &cb.base);
>
> -   if (intr)
> -   t = wait_event_interruptible_timeout(rdev->fence_queue,
> -   ((signaled = radeon_test_signaled(fence)) ||
> -rdev->needs_reset), t);
> -   else
> -   t = wait_event_timeout(rdev->fence_queue,
> -   ((signaled = radeon_test_signaled(fence)) ||
> -rdev->needs_reset), t);
> -
> -   if (t > 0 && !signaled)
> -   return -EDEADLK;
> return t;
>  }
>
> --
> 2.3.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/amdkfd: add debug prints for process teardown

2015-03-06 Thread Alex Deucher
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay  wrote:
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index a369c14..945d622 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -162,10 +162,16 @@ static void kfd_process_wq_release(struct work_struct 
> *work)
>
> p = my_work->p;
>
> +   pr_debug("Releasing process (pasid %d) in workqueue\n",
> +   p->pasid);
> +
> mutex_lock(&p->mutex);
>
> list_for_each_entry_safe(pdd, temp, &p->per_device_data,
> per_device_list) {
> +   pr_debug("Releasing pdd (topology id %d) for process (pasid 
> %d) in workqueue\n",
> +   pdd->dev->id, p->pasid);
> +
> amd_iommu_unbind_pasid(pdd->dev->pdev, p->pasid);
> list_del(&pdd->per_device_list);
>
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/amdkfd: Remove unused field from struct qcm_process_device

2015-03-06 Thread Alex Deucher
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay  wrote:
> Signed-off-by: Oded Gabbay 
> Reviewed-by: Ben Goz 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index 5a44f2f..b7bd7af 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -378,8 +378,6 @@ struct qcm_process_device {
> /* The Device Queue Manager that owns this data */
> struct device_queue_manager *dqm;
> struct process_queue_manager *pqm;
> -   /* Device Queue Manager lock */
> -   struct mutex *lock;
> /* Queues list */
> struct list_head queues_list;
> struct list_head priv_queue_list;
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] drm/amdkfd: rename fence_wait_timeout

2015-03-06 Thread Alex Deucher
On Thu, Mar 5, 2015 at 5:14 AM, Oded Gabbay  wrote:
> fence_wait_timeout() is an exported kernel symbol, so we should rename our
> local function to something different.
>
> Signed-off-by: Oded Gabbay 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index b3589d0..b508bae 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -891,7 +891,7 @@ out:
> return retval;
>  }
>
> -static int fence_wait_timeout(unsigned int *fence_addr,
> +static int amdkfd_fence_wait_timeout(unsigned int *fence_addr,
> unsigned int fence_value,
> unsigned long timeout)
>  {
> @@ -947,7 +947,7 @@ static int destroy_queues_cpsch(struct 
> device_queue_manager *dqm, bool lock)
> pm_send_query_status(&dqm->packets, dqm->fence_gpu_addr,
> KFD_FENCE_COMPLETED);
> /* should be timed out */
> -   fence_wait_timeout(dqm->fence_addr, KFD_FENCE_COMPLETED,
> +   amdkfd_fence_wait_timeout(dqm->fence_addr, KFD_FENCE_COMPLETED,
> QUEUE_PREEMPT_DEFAULT_TIMEOUT_MS);
> pm_release_ib(&dqm->packets);
> dqm->active_runlist = false;
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: Lighten sysfs connector 'status'

2015-03-06 Thread Alex Deucher
On Fri, Mar 6, 2015 at 7:36 AM, Chris Wilson  
wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so that existing readers get the behaviour they desire.
>
> v2: David Herrmann suggested using "echo detect > /sys/.../status" to
> trigger the probing, which is a fine idea. This extends that to also
> allow the user to apply the force detection overrides at runtime.
>
> v3: Now with airlied's email address fixed! Requires sysfs_streq()
>
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: David Herrmann 
> Cc: Dave Airlie 
> Cc: Alex Deucher 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_sysfs.c | 61 
> +++--
>  1 file changed, 53 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 5c99d3773212..ffc305fc2076 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -166,23 +166,68 @@ void drm_sysfs_destroy(void)
>  /*
>   * Connector properties
>   */
> -static ssize_t status_show(struct device *device,
> +static ssize_t status_store(struct device *device,
>struct device_attribute *attr,
> -  char *buf)
> +  const char *buf, size_t count)
>  {
> struct drm_connector *connector = to_drm_connector(device);
> -   enum drm_connector_status status;
> +   struct drm_device *dev = connector->dev;
> +   enum drm_connector_status old_status;
> int ret;
>
> -   ret = mutex_lock_interruptible(&connector->dev->mode_config.mutex);
> +   ret = mutex_lock_interruptible(&dev->mode_config.mutex);
> if (ret)
> return ret;
>
> -   status = connector->funcs->detect(connector, true);
> -   mutex_unlock(&connector->dev->mode_config.mutex);
> +   old_status = connector->status;
> +
> +   if (sysfs_streq(buf, "detect")) {
> +   connector->force = 0;
> +   connector->status = connector->funcs->detect(connector, true);
> +   } else if (sysfs_streq(buf, "on")) {
> +   connector->force = DRM_FORCE_ON;
> +   } else if (sysfs_streq(buf, "on-digital")) {
> +   connector->force = DRM_FORCE_ON_DIGITAL;
> +   } else if (sysfs_streq(buf, "off")) {
> +   connector->force = DRM_FORCE_OFF;
> +   } else
> +   ret = -EINVAL;
> +
> +   if (ret == 0 && connector->force) {
> +   if (connector->force == DRM_FORCE_ON ||
> +   connector->force == DRM_FORCE_ON_DIGITAL)
> +   connector->status = connector_status_connected;
> +   else
> +   connector->status = connector_status_disconnected;
> +   if (connector->funcs->force)
> +   connector->funcs->force(connector);
> +   }
> +
> +   if (old_status != connector->status) {
> +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
> %d\n",
> + connector->base.id,
> + connector->name,
> + old_status, connector->status);
> +
> +   dev->mode_config.delayed_event = true;
> +   if (dev->mode_config.poll_enabled)
> +   
> schedule_delayed_work(&dev->mode_config.output_poll_work,
> + 0);
> +   }
> +
> +   mutex_unlock(&dev->mode_config.mutex);
> +
> +   return ret;
> +}
> +
> +static ssize_t status_show(struct device *device,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> +   struct drm_connector *connector = to_drm_connector(device);
>
> return snprintf(buf, PAGE_SIZE, "%s\n",
> -   drm_get_connector_status_name(status));
> +   drm_get_connector_status_name(connector->status));
>  }
>
>  static ssize_t dpms_show(struct device *device,
> @@ -339,7 +384,7 @@ static ssize_t select_subconnector_show(struct device 
> *device,
> drm_get_dvi_i_select_name((int)subconnector));
>  }
>
> -static DEVICE_ATTR_RO(status);
> +static DEVICE_ATTR_RW(status);
>  static DEVICE_ATTR_RO(enabled);
>  static DEVICE_ATTR_RO(dpms);
>  static DEVICE_ATTR_RO(modes);
> --
> 2.1.4
>


[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

2015-03-06 Thread Tony Lindgren
* Jyri Sarha  [150306 07:57]:
> On 03/06/15 17:36, Tony Lindgren wrote:
> >* Jyri Sarha  [150306 07:37]:
> >>Use new binding for the external tda19988 HDMI encoder.
> >
> >Can this be merged separately after the driver code is
> >merged with things still working?
> >
> 
> Yes absolutely. That is why DRM_TILCDC_SLAVE_COMPAT is there for.

Great, thanks for sorting it out properly. Please ping me to
apply this patch when the driver changes are in Linux next.

Regards,

Tony


[PATCH 1/2] drm/udl: make page flips asynchronous.

2015-03-06 Thread Chris Wilson
On Thu, Mar 05, 2015 at 05:52:50PM -0800, Haixia Shi wrote:
> On Thu, Mar 5, 2015 at 2:33 AM, Chris Wilson  
> wrote:
> > On Wed, Mar 04, 2015 at 06:26:23PM -0800, Haixia Shi wrote:
> >> This also limits the maximum frequency of page flips by the vrefresh rate.
> >>
> >> Signed-off-by: Haixia Shi 
> >> Reviewed-by: Stéphane Marchesin 
> >> Tested-by: Haixia Shi 
> >
> > I think the better approach would have been to push the task down to
> > udl_handle_damage(). Almost all of the callers would prefer deferred
> > updates (with the notable exception of modesetting).
> > -Chris
> 
> I'm not sure this is correct. While there's reasonable expectation for
> page flips to be asynchronous (when flip completes it would send the
> vblank event), my understanding is that fb_fillrect, fb_copyarea and
> fb_imageblit are synchronous.

No, they are not synchronous with monitor refresh. Conceptually running
the usb xfer from a timer is the equivalent of the monitor reading from
the scanout at a distinct point in time from when we write into the
framebuffer.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


[Bug 78238] GPU lockup on opening new tab in Chromium

2015-03-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=78238

russianneuromancer at ya.ru changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from russianneuromancer at ya.ru ---
Not reproducible anymore with current kernel, Mesa, etc.

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


[PATCH v2 7/7] ARM: dts: am335x-boneblack: Use new binding for HDMI

2015-03-06 Thread Tony Lindgren
* Jyri Sarha  [150306 07:37]:
> Use new binding for the external tda19988 HDMI encoder.

Can this be merged separately after the driver code is
merged with things still working?

Otherwise we can have glitches with the output working and
have dependencies between kernel branches.

Regards,

Tony

> Signed-off-by: Jyri Sarha 
> ---
>  arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index 5c42d25..eadbba3 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -68,16 +68,26 @@
>  
>  &lcdc {
>   status = "okay";
> + port {
> + lcdc_0: endpoint at 0 {
> + remote-endpoint = <&hdmi_0>;
> + };
> + };
>  };
>  
> -/ {
> - hdmi {
> - compatible = "ti,tilcdc,slave";
> - i2c = <&i2c0>;
> +&i2c0 {
> + tda19988 {
> + compatible = "nxp,tda998x";
> + reg = <0x70>;
>   pinctrl-names = "default", "off";
>   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
>   pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> - status = "okay";
> +
> + port {
> + hdmi_0: endpoint at 0 {
> + remote-endpoint = <&lcdc_0>;
> + };
> + };
>   };
>  };
>  
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Bug 89072] Radeon Hawaii no acceleration on 32-bit kernel

2015-03-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89072

--- Comment #5 from Woody Suwalski  ---
Your idea seems to be correct:

[0.922337] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[0.922383] [drm] Driver supports precise vblank timestamp query.
[0.922444] radeon :01:00.0: radeon: using MSI.
[0.922505] [drm] radeon: irq initialized.
[0.924622] [drm] ring test on 0 succeeded in 4 usecs
[0.924743] [drm] ring test on 1 succeeded in 3 usecs
[0.924799] [drm] ring test on 2 succeeded in 3 usecs
[0.924945] [drm] ring test on 3 succeeded in 5 usecs
[0.924997] [drm] ring test on 4 succeeded in 5 usecs
[0.970689] [drm] ring test on 5 succeeded in 2 usecs
[0.990579] [drm] UVD initialized successfully.
[1.099778] [drm] ring test on 6 succeeded in 24 usecs
[1.099831] [drm] ring test on 7 succeeded in 3 usecs
[1.099876] [drm] VCE initialized successfully.
[1.16] [drm] ib test on ring 0 succeeded in 0 usecs
[1.599633] [drm] ib test on ring 1 succeeded in 0 usecs
[1.851505] tsc: Refined TSC clocksource calibration: 3092.973 MHz
[2.099525] [drm] ib test on ring 2 succeeded in 0 usecs
[2.099660] [drm] ib test on ring 3 succeeded in 0 usecs
[2.099758] [drm] ib test on ring 4 succeeded in 0 usecs
[2.619405] [drm] ib test on ring 5 succeeded
[2.640200] [drm] ib test on ring 6 succeeded
[2.640982] [drm] ib test on ring 7 succeeded

glxgears shows much better numbers now.

The side effect is a compilation warning for nouveau driver - patch attached.

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


[Bug 89072] Radeon Hawaii no acceleration on 32-bit kernel

2015-03-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89072

--- Comment #4 from Woody Suwalski  ---
Created attachment 114065
  --> https://bugs.freedesktop.org/attachment.cgi?id=114065&action=edit
fix for nouveau_fbcon.c printk compilation warning

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


[Bug 94331] Random panic with radeon

2015-03-06 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=94331

--- Comment #1 from Michel Dänzer  ---
(In reply to sulamiification from comment #0)
> Because of the panic messsage I am assuming it is at least related to radeon.

Why is that? If you mean because of 'drm_kms_helper', that message appears
regardless of what causes the panic.

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


[Bug 89431] Monitor is deactivated after DPMS activates

2015-03-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=89431

--- Comment #8 from rob at emanuele.us ---
building a new linux-image for ubuntu is tricky... might take me a little
longer

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