Re: [PATCH 1/4] drm: Plumb modifiers through plane init

2017-07-24 Thread kbuild test robot
Hi Ben,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-sunxi_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/sun4i/sun8i_layer.c: In function 'sun8i_layer_init_one':
>> drivers/gpu/drm/sun4i/sun8i_layer.c:93:12: error: incompatible type for 
>> argument 7 of 'drm_universal_plane_init'
   plane->type, NULL);
   ^
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
   include/drm/drm_plane.h:550:5: note: expected 'const uint64_t * {aka const 
long long unsigned int *}' but argument is of type 'const enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
>> include/linux/stddef.h:7:14: error: incompatible type for argument 8 of 
>> 'drm_universal_plane_init'
#define NULL ((void *)0)
 ^
>> drivers/gpu/drm/sun4i/sun8i_layer.c:93:25: note: in expansion of macro 'NULL'
   plane->type, NULL);
^~~~
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
   include/drm/drm_plane.h:550:5: note: expected 'enum drm_plane_type' but 
argument is of type 'void *'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
>> drivers/gpu/drm/sun4i/sun8i_layer.c:90:8: error: too few arguments to 
>> function 'drm_universal_plane_init'
 ret = drm_universal_plane_init(drm, >plane, 0,
   ^~~~
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/sun4i/sun8i_layer.c:16:
   include/drm/drm_plane.h:550:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
--
   drivers/gpu//drm/sun4i/sun8i_layer.c: In function 'sun8i_layer_init_one':
   drivers/gpu//drm/sun4i/sun8i_layer.c:93:12: error: incompatible type for 
argument 7 of 'drm_universal_plane_init'
   plane->type, NULL);
   ^
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
   include/drm/drm_plane.h:550:5: note: expected 'const uint64_t * {aka const 
long long unsigned int *}' but argument is of type 'const enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/mod_devicetable.h:11,
from include/linux/i2c.h:29,
from include/drm/drm_crtc.h:28,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
>> include/linux/stddef.h:7:14: error: incompatible type for argument 8 of 
>> 'drm_universal_plane_init'
#define NULL ((void *)0)
 ^
   drivers/gpu//drm/sun4i/sun8i_layer.c:93:25: note: in expansion of macro 
'NULL'
   plane->type, NULL);
^~~~
   In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu//drm/sun4i/sun8i_layer.c:16:
   include/drm/drm_plane.h:550:5: note: expected 'enum drm_plane_type' but 
argument is of type 'void *'
int drm_universal_plane_init(struct drm_device *dev,
^

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

2017-07-24 Thread Mario Kleiner

On 07/24/2017 03:45 PM, Florian Echtler wrote:

Hello Lukas,

On 17.07.2017 11:02, Lukas Wunner wrote:

On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:

Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
landed in Linus' tree last week and is included in 4.13-rc1.  It is
supposed to fix black screen issues with the iMac10,1 that you're also
using, though in Mario's case they seem to occur upon boot, rather than
on suspend, still might be worth a try:


Hi,



thanks for the hint. I've applied this patch to the v4.12 tree I'm currently
running, and it didn't seem to make any difference (i.e. display stays black
after suspend).



That's the same here with my patch applied. After a suspend -> resume, 
the internal panel stays black, the patch doesn't help for that. 
Somethig i didn't notice btw., apparently i never suspend->resumed it.



Without the patch, when I plug in an external display (via MiniDP-to-DVI), then
the internal panel stays black when booting, only the external display works.


That's different for me:

The internal panel always works during boot, until the radeon kms driver 
loads and modesetting gets initialized, then the panel goes dark.


With my patch, the panel then lights up properly immediately, and 
external output to dvi/hdmi works as well if i connect anything. 
External Displayport panel doesn't work though - stays dark, although it 
is reported connected+active in xrandr.


However this is something i got when connecting the external Displayport 
panel:


Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344792] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:16:09 kleinerm-MaxtorLinux kernel: [ 1441.344819] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Jul  7 04:18:07 kleinerm-MaxtorLinux kernel: [ 1559.770783] 
drm_dp_i2c_do_msg: 20 callbacks suppressed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143406] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.143439] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356173] 
[drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
Jul  7 04:30:19 kleinerm-MaxtorLinux kernel: [ 2291.356205] 
[drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed


So link training failed, because drm_dp_dpcd_read_link_status() already 
failed to read from the dp aux channel.


Without my patch the internal panel stays dark, but plugging in an 
external hdmi/dvi display gets both internal+external to light up.


Another way i was able to force the internal panel to stay on without my 
patch and without an external display connected is to use the kernel 
cmdline option "video=DP-1:2560x1440D" to force the external output on, 
although nothing is connected.


The patch is just the result of trial and error, following hunches, 
based on reading through the radeon modesetting code. Unfortunately no 
real insight into why stuff goes wrong. I also remember disassembling 
bits of the dumped atombios a year ago and not finding anything that 
looked suspicious to me, but then i'm not experienced at that.




Actually, the patch then makes things slightly worse in my case: with the patch
applied, not even the external sink works anymore. When I log in remotely and
run "DISPLAY=:0.0 xrandr", both DP connections are shown as active, but neither
does actually show an image.



So the same machine model behaves differently with the same patch, and 
worse in your case than without it? Maybe different hardware or firmware?


Apples website lists two models of late 2009 iMac10,1 and Radeon HD 
4670, to which the patch should apply. One 21.5 inch model without TDM 
and a 27 inch model with TDM. Mine is the 27 inch one. I assume yours as 
well due to TDM? Attached is the output of dmidecode on mine, not sure 
what to look for for differences?


Also attached a dmesg snippet for comparison wrt. SMBIOS version etc.


I'd be grateful about a bit of background information here, I'd really like to
help fix this.


Lukas idea that some hardware mux gets switched into the wrong position 
on models with TDM sounds pretty appealing to me, but how to test?


-mario



Best, Florian

# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.4 present.
49 structures occupying 2670 bytes.
Table at 0xBFEC3000.

Handle 0x, DMI type 4, 35 bytes
Processor Information
Socket Designation: U2E1
Type: Central Processor
Family: Other
Manufacturer: Intel(R) Corporation
ID: 7A 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 23, Stepping 10
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time 

Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob

2017-07-24 Thread kbuild test robot
Hi Ben,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'fops'
>> include/drm/drm_mode_config.h:771: warning: No description found for 
>> parameter 'modifiers_property'
>> include/drm/drm_mode_config.h:771: warning: Excess struct/union/enum/typedef 
>> 

Re: [PATCH 1/4] drm: Plumb modifiers through plane init

2017-07-24 Thread kbuild test robot
Hi Ben,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   arch/x86/include/asm/uaccess_32.h:1: warning: no structured comments found
   include/linux/init.h:1: warning: no structured comments found
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_major' description in 'fsl_mc_device_id'
   include/linux/mod_devicetable.h:687: warning: Excess 
struct/union/enum/typedef member 'ver_minor' description in 'fsl_mc_device_id'
   kernel/sched/core.c:2088: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2088: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:230: warning: No description found for parameter 
'enabled'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:408: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:537: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:537: warning: No description found for parameter 'fops'
>> include/drm/drm_plane.h:546: warning: No description found for parameter 
>> 'modifiers'
>> include/drm/drm_plane.h:546: warning: No description found for parameter 
>> 'modifier_count'
   

Re: [PATCH v5 6/7] dt-bindings: display: rockchip: fill Documents for vop series

2017-07-24 Thread Mark yao

On 2017年07月25日 03:53, Rob Herring wrote:

On Thu, Jul 20, 2017 at 10:43:53AM +0800, Mark Yao wrote:

Signed-off-by: Mark Yao 
---
Changes in v5:
- clean document commit title
- move changes description out of docummit commit msg

Changes in v2:
- rename rk322x to rk3228
- correct some vop registers define

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

Acked-by: Rob Herring 




Thanks for the Ack. :-)

--
Mark Yao


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


[PATCHv1 02/14] drm/omap: drop incorrect comment

2017-07-24 Thread Sebastian Reichel
The wrappers have been removed in commit 5a35876e2830
(drm: omapdrm: Remove manual update display support)
and will not be reintroduced, since the normal sys
functions properly call the dirty callback.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index daf81a0a2899..929a3ef0fba0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -84,9 +84,6 @@ static struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
 
-   /* Note: to properly handle manual update displays, we wrap the
-* basic fbdev ops which write to the framebuffer
-*/
.fb_read = drm_fb_helper_sys_read,
.fb_write = drm_fb_helper_sys_write,
.fb_fillrect = drm_fb_helper_sys_fillrect,
-- 
2.13.2

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


[PATCHv1 11/14] drm/omap: panel-dsi-cm: add external backlight support

2017-07-24 Thread Sebastian Reichel
Droid 4 has a command mode DSI panel, which does not have/use
DSI based backlight support. This adds proper support for this
using a backlight phandle property, which follows the common
panel binding.

If no backlight phandle is found, it is assumed, that the
native backlight should be used instead. This is used by
the Nokia N950.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 91 -
 1 file changed, 60 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index b50b1e81b2f5..1eeb8b0d10c2 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -51,6 +51,7 @@ struct panel_drv_data {
struct mutex lock;
 
struct backlight_device *bldev;
+   struct backlight_device *extbldev;
 
unsigned long   hw_guard_end;   /* next value of jiffies when we can
 * issue the next sleep in/out command
@@ -100,6 +101,30 @@ static int dsicm_panel_reset(struct panel_drv_data *ddata);
 
 static void dsicm_ulps_work(struct work_struct *work);
 
+static void dsicm_bl_power(struct panel_drv_data *ddata, bool enable)
+{
+   struct backlight_device *backlight;
+
+   if (ddata->bldev)
+   backlight = ddata->bldev;
+   else if (ddata->extbldev)
+   backlight = ddata->extbldev;
+   else
+   return;
+
+   if (enable) {
+   backlight->props.fb_blank = FB_BLANK_UNBLANK;
+   backlight->props.state = ~(BL_CORE_FBBLANK | BL_CORE_SUSPENDED);
+   backlight->props.power = FB_BLANK_UNBLANK;
+   } else {
+   backlight->props.fb_blank = FB_BLANK_NORMAL;
+   backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight->props.state |= BL_CORE_FBBLANK | BL_CORE_SUSPENDED;
+   }
+
+   backlight_update_status(backlight);
+}
+
 static void hw_guard_start(struct panel_drv_data *ddata, int guard_msec)
 {
ddata->hw_guard_wait = msecs_to_jiffies(guard_msec);
@@ -343,7 +368,7 @@ static int dsicm_bl_update_status(struct backlight_device 
*dev)
 {
struct panel_drv_data *ddata = dev_get_drvdata(>dev);
struct omap_dss_device *in = ddata->in;
-   int r;
+   int r = 0;
int level;
 
if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
@@ -364,8 +389,6 @@ static int dsicm_bl_update_status(struct backlight_device 
*dev)
r = dsicm_dcs_write_1(ddata, DCS_BRIGHTNESS, level);
 
in->ops.dsi->bus_unlock(in);
-   } else {
-   r = 0;
}
 
mutex_unlock(>lock);
@@ -819,6 +842,8 @@ static int dsicm_enable(struct omap_dss_device *dssdev)
 
mutex_unlock(>lock);
 
+   dsicm_bl_power(ddata, true);
+
return 0;
 err:
dev_dbg(>pdev->dev, "enable failed\n");
@@ -834,6 +859,8 @@ static void dsicm_disable(struct omap_dss_device *dssdev)
 
dev_dbg(>pdev->dev, "disable\n");
 
+   dsicm_bl_power(ddata, false);
+
mutex_lock(>lock);
 
dsicm_cancel_ulps_work(ddata);
@@ -1198,6 +1225,7 @@ static struct omap_dss_driver dsicm_ops = {
 static int dsicm_probe_of(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
+   struct device_node *backlight;
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *in;
struct display_timing timing;
@@ -1259,14 +1287,25 @@ static int dsicm_probe_of(struct platform_device *pdev)
 
ddata->in = in;
 
-   /* TODO: ulps, backlight */
+   backlight = of_parse_phandle(node, "backlight", 0);
+   if (backlight) {
+   ddata->extbldev = of_find_backlight_by_node(backlight);
+   of_node_put(backlight);
+
+   if (!ddata->extbldev)
+   return -EPROBE_DEFER;
+   } else {
+   /* assume native backlight support */
+   ddata->use_dsi_backlight = true;
+   }
+
+   /* TODO: ulps */
 
return 0;
 }
 
 static int dsicm_probe(struct platform_device *pdev)
 {
-   struct backlight_properties props;
struct panel_drv_data *ddata;
struct backlight_device *bldev = NULL;
struct device *dev = >dev;
@@ -1319,7 +1358,7 @@ static int dsicm_probe(struct platform_device *pdev)
GPIOF_OUT_INIT_LOW, "taal rst");
if (r) {
dev_err(dev, "failed to request reset gpio\n");
-   return r;
+   goto err_reg;
}
}
 
@@ -1328,7 +1367,7 @@ static int dsicm_probe(struct platform_device *pdev)
GPIOF_IN, "taal irq");
if (r) {
dev_err(dev, "GPIO request failed\n");
-   

Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

2017-07-24 Thread Russell King - ARM Linux
On Mon, Jul 24, 2017 at 02:07:17PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
> > Just to make sure you aren't waiting for me to do anything: as far as I can 
> > tell
> > the Kconfig above will ensure the right dependencies. If you have an example
> > where this fails, then let me know. I am not planning on making any changes.
> > Frankly, I wouldn't know what to change since AFAICT it is all working with
> > the above Kconfig.
> 
> No, I just haven't got around to it yet - I've been busy all last week
> trying to work out what's been causing a USB host driver to fail for a 
> client, and as such haven't had any chance to look at much else post
> merge window yet.

It's going to be a while yet - today I've attempted to bring my tree
forward to v4.13-rc2, but it's proven a long and difficult task to get
anywhere close to finishing that... and I've just ended up rewinding
back to this morning's state (because I ended up having to drop some
branches that other stuff depended upon.)

I'll have another go later in the week.

Until I can do this, I can't do anything else with mainline work.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 03/41] drm/arc: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Alexey Brodkin
Hi Noralf,

> -Original Message-
> From: Noralf Trønnes [mailto:nor...@tronnes.org]
> Sent: Sunday, July 23, 2017 10:16 PM
> To: dri-devel@lists.freedesktop.org
> Cc: alexander.deuc...@amd.com; alexey.brod...@synopsys.com; 
> alison.w...@freescale.com; benjamin.gaign...@linaro.org;
> bske...@redhat.com; boris.brezil...@free-electrons.com; 
> brian.star...@arm.com; puck.c...@hisilicon.com;
> christian.koe...@amd.com; ck...@mediatek.com; daniel.vet...@intel.com; 
> airl...@redhat.com; e...@anholt.net;
> kra...@redhat.com; jani.nik...@linux.intel.com; jy0922.s...@samsung.com; 
> jsa...@ti.com; kyungmin.p...@samsung.com;
> laurent.pinch...@ideasonboard.com; liviu.du...@arm.com; ma...@denx.de; 
> mark@rock-chips.com; maxime.ripard@free-
> electrons.com; narmstr...@baylibre.com; patrik.r.jakobs...@gmail.com; 
> philippe.co...@st.com; p.za...@pengutronix.de;
> robdcl...@gmail.com; zourongr...@gmail.com; li...@armlinux.org.uk; 
> sw0312@samsung.com; shawn...@kernel.org;
> ste...@agner.ch; thierry.red...@gmail.com; tomi.valkei...@ti.com; 
> vincent.abr...@st.com; z.liuxinli...@hisilicon.com;
> kong.kongxin...@hisilicon.com; yannick.fer...@st.com; Noralf Trønnes 
> 
> Subject: [PATCH 03/41] drm/arc: Use .dumb_map_offset and .dumb_destroy 
> defaults
> 
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Alexey Brodkin 
> Signed-off-by: Noralf Trønnes 
> ---

Acked-by: Alexey Brodkin 

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


[PATCHv1 07/14] drm/omap: add support for physical size hints from display drivers

2017-07-24 Thread Sebastian Reichel
While physical size information is automatically parsed for EDID
based displays, we need to provide it manually for displays providing
one fixed mode.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h| 2 ++
 drivers/gpu/drm/omapdrm/omap_connector.c | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 4e619ff360ae..530365e9c48d 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -560,6 +560,8 @@ struct omap_dss_driver {
struct videomode *vm);
void (*get_timings)(struct omap_dss_device *dssdev,
struct videomode *vm);
+   void (*get_size)(struct omap_dss_device *dssdev,
+unsigned int *width, unsigned int *height);
 
int (*set_wss)(struct omap_dss_device *dssdev, u32 wss);
u32 (*get_wss)(struct omap_dss_device *dssdev);
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 5e941305ab1b..b2678105aaf2 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -136,6 +136,12 @@ static int omap_connector_get_modes(struct drm_connector 
*connector)
drm_mode_set_name(mode);
drm_mode_probed_add(connector, mode);
 
+   if (dssdrv->get_size) {
+   dssdrv->get_size(dssdev,
+>display_info.width_mm,
+>display_info.height_mm);
+   }
+
n = 1;
}
 
-- 
2.13.2

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


Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-24 Thread Mauro Rossi
Hi,

after git-send I noticed that libdrm patches in drii-devel are
prefixed by [ PATCH libdrm ]

Please consider that this is a libdrm patch.
Mauro


2017-07-22 11:01 GMT+02:00 Mauro Rossi :
> Changes in Android.mk makefile to avoid building errors in mesa
> due to missing LOCAL_CFLAGS variable definition for
> AMDGPU_ASIC_ID_TABLE and ASIC_ID_TABLE_NUM_ENTRIES
>
> Fixes: 7e6bf88cac ("amdgpu: move asic id table to a separate file")
> ---
>  amdgpu/Android.mk | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611ba..270680bb 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -10,5 +10,13 @@ LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> +   $(LIBDRM_TOP)/data/amdgpu.ids)
> +
> +LOCAL_CFLAGS += -DAMDGPU_ASIC_ID_TABLE=\"$(LIBDRM_TOP)/data/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
> +
> +$(intermediates)/amdgpu_asic_id.o: $(LIBDRM_TOP)/data/amdgpu.ids
> +
>  include $(LIBDRM_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv1 12/14] drm/omap: panel-dsi-cm: switch to gpiod

2017-07-24 Thread Sebastian Reichel
Use the new descriptor based GPIO API instead of
the legacy one, which results in cleaner code
with less lines of code.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 74 +
 1 file changed, 27 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 1eeb8b0d10c2..8f7463392047 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -59,8 +58,8 @@ struct panel_drv_data {
unsigned long   hw_guard_wait;  /* max guard time in jiffies */
 
/* panel HW configuration from DT or platform data */
-   int reset_gpio;
-   int ext_te_gpio;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *ext_te_gpio;
 
struct regulator *vpnl;
struct regulator *vddi;
@@ -288,8 +287,8 @@ static int dsicm_enter_ulps(struct panel_drv_data *ddata)
if (r)
goto err;
 
-   if (gpio_is_valid(ddata->ext_te_gpio))
-   disable_irq(gpio_to_irq(ddata->ext_te_gpio));
+   if (ddata->ext_te_gpio)
+   disable_irq(gpiod_to_irq(ddata->ext_te_gpio));
 
in->ops.dsi->disable(in, false, true);
 
@@ -330,8 +329,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
goto err2;
}
 
-   if (gpio_is_valid(ddata->ext_te_gpio))
-   enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+   if (ddata->ext_te_gpio)
+   enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
 
dsicm_queue_ulps_work(ddata);
 
@@ -344,8 +343,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
 
r = dsicm_panel_reset(ddata);
if (!r) {
-   if (gpio_is_valid(ddata->ext_te_gpio))
-   enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+   if (ddata->ext_te_gpio)
+   enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
ddata->ulps_enabled = false;
}
 err1:
@@ -591,16 +590,13 @@ static struct attribute_group dsicm_attr_group = {
 
 static void dsicm_hw_reset(struct panel_drv_data *ddata)
 {
-   if (!gpio_is_valid(ddata->reset_gpio))
-   return;
-
-   gpio_set_value(ddata->reset_gpio, 1);
+   gpiod_set_value(ddata->reset_gpio, 1);
udelay(10);
/* reset the panel */
-   gpio_set_value(ddata->reset_gpio, 0);
+   gpiod_set_value(ddata->reset_gpio, 0);
/* assert reset */
udelay(10);
-   gpio_set_value(ddata->reset_gpio, 1);
+   gpiod_set_value(ddata->reset_gpio, 1);
/* wait after releasing reset */
usleep_range(5000, 1);
 }
@@ -954,7 +950,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
if (r)
goto err;
 
-   if (ddata->te_enabled && gpio_is_valid(ddata->ext_te_gpio)) {
+   if (ddata->te_enabled && ddata->ext_te_gpio) {
schedule_delayed_work(>te_timeout_work,
msecs_to_jiffies(250));
atomic_set(>do_update, 1);
@@ -1001,7 +997,7 @@ static int _dsicm_enable_te(struct panel_drv_data *ddata, 
bool enable)
else
r = dsicm_dcs_write_0(ddata, MIPI_DCS_SET_TEAR_OFF);
 
-   if (!gpio_is_valid(ddata->ext_te_gpio))
+   if (!ddata->ext_te_gpio)
in->ops.dsi->enable_te(in, enable);
 
/* possible panel bug */
@@ -1229,21 +1225,21 @@ static int dsicm_probe_of(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *in;
struct display_timing timing;
-   int gpio, err;
+   int err;
 
-   gpio = of_get_named_gpio(node, "reset-gpios", 0);
-   if (!gpio_is_valid(gpio)) {
-   dev_err(>dev, "failed to parse reset gpio\n");
-   return gpio;
+   ddata->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(ddata->reset_gpio)) {
+   err = PTR_ERR(ddata->reset_gpio);
+   dev_err(>dev, "reset gpio request failed: %d", err);
+   return err;
}
-   ddata->reset_gpio = gpio;
 
-   gpio = of_get_named_gpio(node, "te-gpios", 0);
-   if (gpio_is_valid(gpio) || gpio == -ENOENT) {
-   ddata->ext_te_gpio = gpio;
-   } else {
-   dev_err(>dev, "failed to parse TE gpio\n");
-   return gpio;
+   ddata->ext_te_gpio = devm_gpiod_get_optional(>dev, "te",
+GPIOD_IN);
+   if (IS_ERR(ddata->ext_te_gpio)) {
+   err = PTR_ERR(ddata->ext_te_gpio);
+   dev_err(>dev, "TE gpio request failed: %d", err);
+   return err;
}
 
err = 

[PATCH 1/3][resend] drm: rcar-du: use of_graph_get_remote_endpoint()

2017-07-24 Thread Kuninori Morimoto

From: Kuninori Morimoto 

Now, we can use of_graph_get_remote_endpoint(). Let's use it.

Signed-off-by: Kuninori Morimoto 
Reviewed-by: Laurent Pinchart 
---
based on 4c9c3d595f1bad021cc126d20879df4016801736
("of_graph: add of_graph_get_remote_endpoint()")

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

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 82b978a..66d8cc3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -309,7 +309,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
return -ENODEV;
}
 
-   entity_ep_node = of_parse_phandle(ep->local_node, "remote-endpoint", 0);
+   entity_ep_node = of_graph_get_remote_endpoint(ep->local_node);
 
for_each_endpoint_of_node(entity, ep_node) {
if (ep_node == entity_ep_node)
-- 
1.9.1

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


[PATCH][resend] drm: dw-hdmi-i2s: add missing company name on Copyright

2017-07-24 Thread Kuninori Morimoto

From: Kuninori Morimoto 

This driver's Copyright is under Renesas Solutions Corp

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index b2cf59f..d487b6b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -1,7 +1,8 @@
 /*
  * dw-hdmi-i2s-audio.c
  *
- * Copyright (c) 2016 Kuninori Morimoto 
+ * Copyright (c) 2016 Renesas Solutions Corp.
+ * Kuninori Morimoto 
  *
  * 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
-- 
1.9.1

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


[PATCHv1 01/14] drm/omap: remove unused function defines

2017-07-24 Thread Sebastian Reichel
Remove driver (un)register API defines. They do not even exist
anymore.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 85953a0bc7c2..4e619ff360ae 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -575,9 +575,6 @@ struct omap_dss_driver {
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
-int omap_dss_register_driver(struct omap_dss_driver *);
-void omap_dss_unregister_driver(struct omap_dss_driver *);
-
 int omapdss_register_display(struct omap_dss_device *dssdev);
 void omapdss_unregister_display(struct omap_dss_device *dssdev);
 
-- 
2.13.2

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


[PATCHv1 13/14] ARM: dts: omap4-droid4: improve LCD description

2017-07-24 Thread Sebastian Reichel
This improves LCD support for the Droid 4.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/omap4-droid4-xt894.dts | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts 
b/arch/arm/boot/dts/omap4-droid4-xt894.dts
index 3af4905a6b61..942bb6ec99e5 100644
--- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
+++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
@@ -192,6 +192,10 @@
vddi-supply = <_regulator>;
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;  /* gpio101 */
 
+   width-mm = <50>;
+   height-mm = <89>;
+   backlight = <_backlight>;
+
panel-timing {
clock-frequency = <0>;  /* Calculated by dsi */
 
@@ -361,7 +365,7 @@
 
enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
 
-   backlight {
+   lcd_backlight: backlight {
compatible = "ti,lm3532-backlight";
 
lcd {
-- 
2.13.2

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


Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

2017-07-24 Thread Florian Echtler
Hello Lukas,

On 17.07.2017 11:02, Lukas Wunner wrote:
> On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
> 
> Sorry for the delay Florian.  Commit 564d8a2cf3ab by Mario Kleiner (+cc)
> landed in Linus' tree last week and is included in 4.13-rc1.  It is
> supposed to fix black screen issues with the iMac10,1 that you're also
> using, though in Mario's case they seem to occur upon boot, rather than
> on suspend, still might be worth a try:

thanks for the hint. I've applied this patch to the v4.12 tree I'm currently
running, and it didn't seem to make any difference (i.e. display stays black
after suspend).

Without the patch, when I plug in an external display (via MiniDP-to-DVI), then
the internal panel stays black when booting, only the external display works.

Actually, the patch then makes things slightly worse in my case: with the patch
applied, not even the external sink works anymore. When I log in remotely and
run "DISPLAY=:0.0 xrandr", both DP connections are shown as active, but neither
does actually show an image.

I'd be grateful about a bit of background information here, I'd really like to
help fix this.

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



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


Re: [PATCH 2/4] drm/bridge: dw-hdmi: add cec notifier support

2017-07-24 Thread Russell King - ARM Linux
On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
> Hi Russell,
> 
> On 07/17/2017 02:23 PM, Hans Verkuil wrote:
> >On 17/07/17 14:05, Russell King - ARM Linux wrote:
> >>On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
> >>>On 17/07/17 11:05, Russell King - ARM Linux wrote:
> On Mon, Jul 17, 2017 at 10:56:47AM +0200, Hans Verkuil wrote:
> >Hi Russell,
> >
> >On 09/06/17 16:10, Russell King - ARM Linux wrote:
> >>On Fri, Jun 09, 2017 at 03:56:39PM +0200, Neil Armstrong wrote:
> >>>Yes, but on the Amlogic Meson plarform, the DW-HDMI CEC controller is
> >>>not used, but a custom one, so this notifier is actually useful for
> >>>this platform and maybe others.
> >>
> >>Is the CEC controller configured into dw-hdmi (is the config bit set?)
> >>I'm just wondering if we're going to end up with two CEC drivers trying
> >>to bind to the same notifier.
> >>
> >>>Should we really wait until I push the Amlogic AO CEC driver ? Having a
> >>>notifier in the DW-HDMI driver won't harm anybody since it *will be 
> >>>used*.
> >>
> >>It sounds like this adds additional information that has been missing
> >>from the review of my patches - and I suspect changes Hans' comments.
> >>So, I'll wait, it seems pointless to try and update the patches when
> >>it's not clear how to proceed due to other dependencies, especially
> >>when it means that their existing state is what's required (I'm pleased
> >>that I've held off modifying the patches so far.)
> >>
> >>If that means having to wait another kernel revision, then I guess 
> >>that's
> >>what will have to happen.
> >
> >Can you respin your patch series, keeping the notifier support? The CEC
> >kernel config handling has been cleaned up (just select CEC_CORE and
> >CEC_NOTIFIER) so you should be good to go.
> 
> Not yet - the change to the way you're dealing with Kconfig in CEC is
> fundamentally broken, and needs fixing before we can merge dw-hdmi-cec
> support.
> 
> As a result of these Kconfig changes, dw-hdmi-cec now fails if:
> 
> 1. You build the CEC part as a module
> 2. You build the HDMI part into the kernel
> 
> This results in CEC_NOTIFIER=y and CEC_CORE=m, which, when the HDMI part
> gets built, results in the stubs in the notifier code being used, rather
> than the real functions.  This in turn causes the CEC part to never
> receive a physical address, which is therefore non-functional.
> 
> I did have a patch to fix this, but it was never committed, and I got
> busy with other stuff (so it ended up being git reset --hard away.)
> 
> >>>
> >>>This is more a DRM_DW_HDMI issue than a CEC issue IMHO.
> >>>
> >>>This will fix this:
> >>>
> >>>config DRM_DW_HDMI
> >>> tristate
> >>> select DRM_KMS_HELPER
> >>> select REGMAP_MMIO
> >>> select CEC_CORE if CEC_NOTIFIER   <<
> >>>
> >>>config DRM_DW_HDMI_CEC
> >>> tristate "Synopsis Designware CEC interface"
> >>> depends on DRM_DW_HDMI
> >>> select CEC_CORE
> >>> select CEC_NOTIFIER
> >>> help
> >>>   Support the CE interface which is part of the Synopsis
> >>>   Designware HDMI block.
> >>>
> >>>This makes sense: if DRM_DW_HDMI_CEC is disabled but another CEC module is
> >>>used instead (as is apparently the case for amlogic), then the
> >>>
> >>>   select CEC_CORE if CEC_NOTIFIER
> >>>
> >>>line ensures that CONFIG_CEC_CORE has the right m/y value.
> >>
> >>I disagree with this approach.
> >>
> >>If DRM_DW_HDMI=y and DRM_DW_HDMI_CEC=n, but some other driver is enabled
> >>that selects CEC_NOTIFIER, then we end up with CEC_CORE forced enabled
> >>through dw-hdmi, even though we haven't asked for the CEC part to be
> >>enabled.
> >
> >If CEC_NOTIFIER is enabled by a CEC driver, then CEC_CORE will also be
> >enabled (without CEC_CORE that driver wouldn't compile, obviously).
> >
> >So I don't see the problem. All the select...if does is make sure that
> >the CEC_CORE can be reached from the HDMI driver if someone enabled the
> >CEC notifier (and thus CEC_CORE).
> >
> >>You might as well have CEC_NOTIFIER itself select CEC_CORE, and be done
> >>with it, because that's basically what this boils down to.
> >
> >That makes no sense.
> >
> >If CEC_NOTIFIER is set, then both the CEC driver and the HDMI driver have to
> >select CEC_CORE to ensure the right dependency. If CEC_NOTIFIER is not set,
> >then only the CEC driver has to select CEC_CORE. In that case the CEC code
> >is typically either integrated into the HDMI driver or it is a standalone
> >device like the USB pulse8-cec driver.
> 
> Just to make sure you aren't waiting for me to do anything: as far as I can 
> tell
> the Kconfig above will ensure the right dependencies. If you have an example
> where this fails, then let me know. I am not 

Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()

2017-07-24 Thread Ross Zwisler
On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, 
> > unsigned long addr,
> > if (!pte)
> > goto out;
> > retval = -EBUSY;
> > -   if (!pte_none(*pte))
> > -   goto out_unlock;
> > +   if (!pte_none(*pte)) {
> > +   if (mkwrite) {
> > +   if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> 
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...

Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().

I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:

if (!pte_none(*pte)) {
if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
goto out_unlock;
if (mkwrite) {
entry = *pte;
goto out_mkwrite;
} else
goto out_unlock;
}

This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.

The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.

This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe.  It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.

Does that make sense to you, or would you recommend leaving it out?  (If so,
why?)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv1 05/14] drm/omap: add manual update detection helper

2017-07-24 Thread Sebastian Reichel
In preparation for manually updated display support, such as DSI
command mode panels, this adds a simple helper to see if a connector
is manually updated.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 8 
 drivers/gpu/drm/omapdrm/omap_drv.h   | 1 +
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c24b6b783e9a..5e941305ab1b 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -42,6 +42,14 @@ bool omap_connector_get_hdmi_mode(struct drm_connector 
*connector)
return omap_connector->hdmi_mode;
 }
 
+bool omap_connector_get_manually_updated(struct drm_connector *connector)
+{
+   struct omap_connector *omap_connector = to_omap_connector(connector);
+
+   return !!(omap_connector->dssdev->caps &
+ OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE);
+}
+
 static enum drm_connector_status omap_connector_detect(
struct drm_connector *connector, bool force)
 {
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 22f3d94994d2..f6c48f254c9b 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -142,6 +142,7 @@ struct drm_connector *omap_connector_init(struct drm_device 
*dev,
 struct drm_encoder *omap_connector_attached_encoder(
struct drm_connector *connector);
 bool omap_connector_get_hdmi_mode(struct drm_connector *connector);
+bool omap_connector_get_manually_updated(struct drm_connector *connector);
 
 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
struct drm_file *file, const struct drm_mode_fb_cmd2 *mode_cmd);
-- 
2.13.2

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


[PATCHv1 14/14] ARM: dts: n950: add display support

2017-07-24 Thread Sebastian Reichel
Add basic panel support for the Nokia N950. It must be tweaked a
little bit later, since the panel was built into the device
upside-down. Also the first 5 and the last 5 pixels are covered
by plastic.

Signed-off-By: Sebastian Reichel 
---
 arch/arm/boot/dts/omap3-n950.dts | 88 
 1 file changed, 88 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index 646601a3ebd8..ef70aae99d1b 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -51,6 +51,26 @@
};
 };
 
+_pmx_core {
+   dsi_pins: pinmux_dsi_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20dc, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx0 - data0+ */
+   OMAP3_CORE1_IOPAD(0x20de, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy0 - data0- */
+   OMAP3_CORE1_IOPAD(0x20e0, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx1 - clk+   */
+   OMAP3_CORE1_IOPAD(0x20e2, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy1 - clk-   */
+   OMAP3_CORE1_IOPAD(0x20e4, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dx2 - data1+ */
+   OMAP3_CORE1_IOPAD(0x20e6, PIN_OUTPUT | MUX_MODE1) /* 
dsi_dy2 - data1- */
+   >;
+   };
+
+   display_pins: pinmux_display_pins {
+   pinctrl-single,pins = <
+   OMAP3_CORE1_IOPAD(0x20ca, PIN_INPUT | MUX_MODE4) /* 
gpio 62 - display te */
+   OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE4) /* 
gpio 87 - display reset */
+   >;
+   };
+};
+
  {
smia_1: camera@10 {
compatible = "nokia,smia";
@@ -185,3 +205,71 @@
st,max-limit-y = <32>;
st,max-limit-z = <32>;
 };
+
+ {
+   status = "ok";
+
+   vdda_video-supply = <>;
+};
+
+ {
+   status = "ok";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   vdd-supply = <>;
+
+   port {
+   dsi_out_ep: endpoint {
+   remote-endpoint = <_in>;
+   lanes = <2 3 0 1 4 5>;
+   };
+   };
+
+   lcd0: display {
+   compatible = "nokia,himalaya", "panel-dsi-cm";
+   label = "lcd0";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
+   vpnl-supply = <>;
+   vddi-supply = <>;
+
+   reset-gpios = < 23 GPIO_ACTIVE_HIGH>; /* 87 */
+   te-gpios = < 30 GPIO_ACTIVE_HIGH>;/* 62 */
+
+   width-mm = <49>; /* 48.960 mm */
+   height-mm = <88>; /* 88.128 mm */
+
+   /* TODO:
+* - panel is upside-down
+* - top + bottom 5px are not visible
+*/
+   panel-timing {
+   clock-frequency = <0>;  /* Calculated by dsi */
+
+   hback-porch = <2>;
+   hactive = <480>;
+   hfront-porch = <0>;
+   hsync-len = <2>;
+
+   vback-porch = <1>;
+   vactive = <864>;
+   vfront-porch = <0>;
+   vsync-len = <1>;
+
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <1>;
+   pixelclk-active = <1>;
+   };
+
+   port {
+   lcd0_in: endpoint {
+   remote-endpoint = <_out_ep>;
+   };
+   };
+   };
+};
-- 
2.13.2

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


[PATCHv1 04/14] drm/omap: add framedone interrupt support

2017-07-24 Thread Sebastian Reichel
This prepares framedone interrupt handling for
manual display update support.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 48 +
 drivers/gpu/drm/omapdrm/omap_drv.h  |  2 ++
 drivers/gpu/drm/omapdrm/omap_irq.c  | 24 +++
 3 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index dd0ef40ca469..404652ad8a6d 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -42,6 +42,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+   void (*framedone_handler)(void *);
+   void *framedone_handler_data;
 };
 
 /* 
-
@@ -238,6 +241,17 @@ static int omap_crtc_dss_register_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   if (omap_crtc->framedone_handler)
+   return -EBUSY;
+
+   dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+   omap_crtc->framedone_handler = handler;
+   omap_crtc->framedone_handler_data = data;
+
return 0;
 }
 
@@ -245,6 +259,16 @@ static void omap_crtc_dss_unregister_framedone(
enum omap_channel channel,
void (*handler)(void *), void *data)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+
+   dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+   WARN_ON(omap_crtc->framedone_handler != handler);
+   WARN_ON(omap_crtc->framedone_handler_data != data);
+
+   omap_crtc->framedone_handler = NULL;
+   omap_crtc->framedone_handler_data = NULL;
 }
 
 static const struct dss_mgr_ops mgr_ops = {
@@ -312,6 +336,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc->framedone_handler) {
+   dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+   return;
+   }
+
+   omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+   spin_lock(>dev->event_lock);
+   /* Send the vblank event if one has been requested. */
+   if (omap_crtc->event) {
+   drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+   omap_crtc->event = NULL;
+   }
+   omap_crtc->pending = false;
+   spin_unlock(>dev->event_lock);
+
+   /* Wake up omap_atomic_complete. */
+   wake_up(_crtc->pending_wait);
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h 
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 4bd1e9070b31..22f3d94994d2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -97,6 +97,7 @@ void omap_gem_describe_objects(struct list_head *list, struct 
seq_file *m);
 int omap_gem_resume(struct device *dev);
 #endif
 
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable);
 int omap_irq_enable_vblank(struct drm_crtc *crtc);
 void omap_irq_disable_vblank(struct drm_crtc *crtc);
 void omap_drm_irq_uninstall(struct drm_device *dev);
@@ -124,6 +125,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
 int omap_crtc_wait_pending(struct drm_crtc *crtc);
 void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
 
 struct drm_plane *omap_plane_init(struct drm_device *dev,
int idx, enum drm_plane_type type,
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 013b0bba712f..301c0e7a70b7 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -87,6 +87,27 @@ int omap_irq_wait(struct drm_device *dev, struct 
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
 }
 
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+   struct drm_device *dev = crtc->dev;
+   struct omap_drm_private *priv = dev->dev_private;
+   unsigned long flags;
+   enum omap_channel channel = omap_crtc_channel(crtc);
+   int framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
+
+   DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+   spin_lock_irqsave(>wait_lock, flags);
+   if (enable)
+   priv->irq_mask |= framedone_irq;
+  

[PATCHv1 03/14] drm/omap: plane: update fifo size on ovl setup

2017-07-24 Thread Sebastian Reichel
This is a workaround for a hardware bug occuring on OMAP3
with manually updated panels. Details about the HW bug are
unknown to me, but without this fix the panel refresh does
not work at all on Nokia N950.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index fd7504b37e3b..b6dca5ee34d4 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -1398,6 +1398,18 @@ void dispc_ovl_compute_fifo_thresholds(enum 
omap_plane_id plane,
}
 }
 
+void dispc_ovl_set_manual_fifo_threshold(enum omap_plane_id plane)
+{
+   u32 fifo_low, fifo_high;
+   bool use_fifo_merge = false;
+   bool use_manual_update = true;
+
+   dispc_ovl_compute_fifo_thresholds(plane, _low, _high,
+ use_fifo_merge, use_manual_update);
+
+   dispc_ovl_set_fifo_threshold(plane, fifo_low, fifo_high);
+}
+
 static void dispc_ovl_set_mflag(enum omap_plane_id plane, bool enable)
 {
int bit;
@@ -2566,6 +2578,10 @@ static int dispc_ovl_setup(enum omap_plane_id plane,
oi->zorder, oi->pre_mult_alpha, oi->global_alpha,
oi->rotation_type, replication, vm, mem_to_mem);
 
+   /* manual mode needs other fifo thresholds */
+   if (mgr_fld_read(channel, DISPC_MGR_FLD_STALLMODE))
+   dispc_ovl_set_manual_fifo_threshold(plane);
+
return r;
 }
 
-- 
2.13.2

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


Re: [PATCH] powerpc/asm/cacheflush: Cleanup cacheflush function params

2017-07-24 Thread Matt Brown
I've realised that changing the arguments for the cacheflush functions
is much more work than its worth, due to other archs using these
functions.
The next patch will just translate the asm cacheflush functions to c,
keeping the existing parameters.
So this won't have any effect on the drivers.

Thanks,
Matt Brown

On Thu, Jul 20, 2017 at 11:01 PM, Michael Ellerman  wrote:
> Geert Uytterhoeven  writes:
>
>> On Thu, Jul 20, 2017 at 1:43 PM, Michael Ellerman  
>> wrote:
>>> Matt Brown  writes:
 The cacheflush prototypes currently use start and stop values and each
 call requires typecasting the address to an unsigned long.
 This patch changes the cacheflush prototypes to follow the x86 style of
 using a base and size values, with base being a void pointer.

 All callers of the cacheflush functions, including drivers, have been
 modified to conform to the new prototypes.

 The 64 bit cacheflush functions which were implemented in assembly code
 (flush_dcache_range, flush_inval_dcache_range) have been translated into
 C for readability and coherence.
>>
 --- a/arch/powerpc/include/asm/cacheflush.h
 +++ b/arch/powerpc/include/asm/cacheflush.h
 @@ -51,13 +51,13 @@ static inline void __flush_dcache_icache_phys(unsigned 
 long physaddr)
   * Write any modified data cache blocks out to memory and invalidate them.
   * Does not invalidate the corresponding instruction cache blocks.
   */
 -static inline void flush_dcache_range(unsigned long start, unsigned long 
 stop)
 +static inline void flush_dcache_range(void *start, unsigned long size)
  {
 - void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1));
 - unsigned long size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 
 1);
 + void *addr = (void *)((u32)start & ~(L1_CACHE_BYTES - 1));
>>>
>>> unsigned long would be nicer than u32.
>>
>> Indeed. That would make this work on ppc64, too.
>> After which ppc64 has an identical copy (u64 = unsigned long on ppc64) below?
>
> That was Matt's homework to notice that ;)
>
> cheers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv1 06/14] drm/omap: add support for manually updated displays

2017-07-24 Thread Sebastian Reichel
This adds the required infrastructure for manually
updated displays, such as DSI command mode panels.

While those panels often support partial updates
we currently always do a full refresh. Display
will be refreshed when something calls the dirty
callback, such as libdrm's drmModeDirtyFB().

This is currently being implemented for the kernel
console and for Xorg. Weston currently does not
implement this and is known not to work on manually
updated displays.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 110 +---
 drivers/gpu/drm/omapdrm/omap_drv.h  |   1 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  20 +++
 3 files changed, 123 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 404652ad8a6d..35a40271d1cb 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -42,6 +42,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+   struct delayed_work update_work;
 
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -133,6 +134,28 @@ static void omap_crtc_dss_disconnect(enum omap_channel 
channel,
 
 static void omap_crtc_dss_start_update(enum omap_channel channel)
 {
+   struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct omap_drm_private *priv = omap_crtc->base.dev->dev_private;
+
+   priv->dispc_ops->mgr_enable(channel, true);
+}
+
+static bool omap_crtc_is_manually_updated(struct drm_crtc *crtc)
+{
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   bool result = false;
+
+   drm_connector_list_iter_begin(crtc->dev, _iter);
+   drm_for_each_connector_iter(connector, _iter) {
+   if (connector->state->crtc != crtc)
+   continue;
+   result = omap_connector_get_manually_updated(connector);
+   break;
+   }
+   drm_connector_list_iter_end(_iter);
+
+   return result;
 }
 
 /* Called only from the encoder enable/disable and suspend/resume handlers. */
@@ -144,12 +167,17 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
enum omap_channel channel = omap_crtc->channel;
struct omap_irq_wait *wait;
u32 framedone_irq, vsync_irq;
+   bool is_manual = omap_crtc_is_manually_updated(crtc);
+   enum omap_display_type type = omap_crtc_output[channel]->output_type;
int ret;
 
if (WARN_ON(omap_crtc->enabled == enable))
return;
 
-   if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
+   if (is_manual)
+   omap_irq_enable_framedone(crtc, enable);
+
+   if (is_manual || type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(channel, enable);
omap_crtc->enabled = enable;
return;
@@ -200,7 +228,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
}
 }
 
-
 static int omap_crtc_dss_enable(enum omap_channel channel)
 {
struct omap_crtc *omap_crtc = omap_crtcs[channel];
@@ -360,6 +387,53 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc, 
uint32_t irqstatus)
wake_up(_crtc->pending_wait);
 }
 
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+   if (!omap_crtc_is_manually_updated(crtc))
+   return;
+
+   if (!delayed_work_pending(_crtc->update_work))
+   schedule_delayed_work(_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+   struct omap_crtc *omap_crtc =
+   container_of(data, struct omap_crtc, update_work.work);
+   struct omap_dss_device *dssdev = omap_crtc_output[omap_crtc->channel];
+   struct drm_device *dev = omap_crtc->base.dev;
+   struct omap_dss_driver *dssdrv;
+   int ret, width, height;
+
+   if (!dssdev || !dssdev->dst) {
+   dev_err_once(dev->dev, "missing dssdev!");
+   return;
+   }
+
+   dssdev = dssdev->dst;
+   dssdrv = dssdev->driver;
+
+   if (!dssdrv || !dssdrv->update) {
+   dev_err_once(dev->dev, "incorrect dssdrv!");
+   return;
+   }
+
+   if (dssdrv->sync)
+   dssdrv->sync(dssdev);
+
+   width = dssdev->panel.vm.hactive;
+   height = dssdev->panel.vm.vactive;
+   ret = dssdrv->update(dssdev, 0, 0, width, height);
+   if (ret < 0) {
+   spin_lock_irq(>event_lock);
+   omap_crtc->pending = false;
+   spin_unlock_irq(>event_lock);
+   wake_up(_crtc->pending_wait);
+   }
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct 

[PATCHv1 10/14] drm/omap: panel-dsi-cm: add physical size support

2017-07-24 Thread Sebastian Reichel
Add support to load physical size information from DT using
the properties defined by the common panel binding.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 95c28f518239..b50b1e81b2f5 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -66,6 +66,9 @@ struct panel_drv_data {
 
bool use_dsi_backlight;
 
+   int width_mm;
+   int height_mm;
+
struct omap_dsi_pin_config pin_config;
 
/* runtime variables */
@@ -1163,6 +1166,15 @@ static int dsicm_check_timings(struct omap_dss_device 
*dssdev,
return ret;
 }
 
+static void dsicm_get_size(struct omap_dss_device *dssdev,
+ unsigned int *width, unsigned int *height)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   *width = ddata->width_mm;
+   *height = ddata->height_mm;
+}
+
 static struct omap_dss_driver dsicm_ops = {
.connect= dsicm_connect,
.disconnect = dsicm_disconnect,
@@ -1175,6 +1187,7 @@ static struct omap_dss_driver dsicm_ops = {
 
.get_timings= dsicm_get_timings,
.check_timings  = dsicm_check_timings,
+   .get_size   = dsicm_get_size,
 
.enable_te  = dsicm_enable_te,
.get_te = dsicm_get_te,
@@ -1216,6 +1229,12 @@ static int dsicm_probe_of(struct platform_device *pdev)
 "failed to get video timing, using defaults\n");
}
 
+   ddata->width_mm = 0;
+   of_property_read_u32(node, "width-mm", >width_mm);
+
+   ddata->height_mm = 0;
+   of_property_read_u32(node, "height-mm", >height_mm);
+
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(>dev, "failed to find video source\n");
-- 
2.13.2

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


[PATCHv1 08/14] drm/omap: panel-dsi-cm: fix driver

2017-07-24 Thread Sebastian Reichel
From: Tony Lindgren 

This adds support for get_timings() and check_timings()
to get the driver working and properly initializes the
timing information from DT.

Signed-off-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 56 ++---
 1 file changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 76787a75a4dc..3845a50537a6 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -25,6 +25,7 @@
 #include 
 
 #include 
+#include 
 
 #include "../dss/omapdss.h"
 
@@ -1099,6 +1100,36 @@ static void dsicm_ulps_work(struct work_struct *work)
mutex_unlock(>lock);
 }
 
+static void dsicm_get_timings(struct omap_dss_device *dssdev,
+ struct videomode *vm)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+
+   *vm = ddata->vm;
+}
+
+static int dsicm_check_timings(struct omap_dss_device *dssdev,
+  struct videomode *vm)
+{
+   struct panel_drv_data *ddata = to_panel_data(dssdev);
+   int ret = 0;
+
+   if (vm->hactive != ddata->vm.hactive)
+   ret = -EINVAL;
+
+   if (vm->vactive != ddata->vm.vactive)
+   ret = -EINVAL;
+
+   if (ret) {
+   dev_warn(dssdev->dev, "wrong resolution: %d x %d",
+vm->hactive, vm->vactive);
+   dev_warn(dssdev->dev, "panel resolution: %d x %d",
+ddata->vm.hactive, ddata->vm.vactive);
+   }
+
+   return ret;
+}
+
 static struct omap_dss_driver dsicm_ops = {
.connect= dsicm_connect,
.disconnect = dsicm_disconnect,
@@ -1109,6 +1140,9 @@ static struct omap_dss_driver dsicm_ops = {
.update = dsicm_update,
.sync   = dsicm_sync,
 
+   .get_timings= dsicm_get_timings,
+   .check_timings  = dsicm_check_timings,
+
.enable_te  = dsicm_enable_te,
.get_te = dsicm_get_te,
 
@@ -1120,7 +1154,8 @@ static int dsicm_probe_of(struct platform_device *pdev)
struct device_node *node = pdev->dev.of_node;
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct omap_dss_device *in;
-   int gpio;
+   struct display_timing timing;
+   int gpio, err;
 
gpio = of_get_named_gpio(node, "reset-gpios", 0);
if (!gpio_is_valid(gpio)) {
@@ -1137,6 +1172,17 @@ static int dsicm_probe_of(struct platform_device *pdev)
return gpio;
}
 
+   err = of_get_display_timing(node, "panel-timing", );
+   if (!err) {
+   videomode_from_timing(, >vm);
+   if (!ddata->vm.pixelclock)
+   ddata->vm.pixelclock =
+   ddata->vm.hactive * ddata->vm.vactive * 60;
+   } else {
+   dev_warn(>dev,
+"failed to get video timing, using defaults\n");
+   }
+
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(>dev, "failed to find video source\n");
@@ -1171,14 +1217,14 @@ static int dsicm_probe(struct platform_device *pdev)
if (!pdev->dev.of_node)
return -ENODEV;
 
-   r = dsicm_probe_of(pdev);
-   if (r)
-   return r;
-
ddata->vm.hactive = 864;
ddata->vm.vactive = 480;
ddata->vm.pixelclock = 864 * 480 * 60;
 
+   r = dsicm_probe_of(pdev);
+   if (r)
+   return r;
+
dssdev = >dssdev;
dssdev->dev = dev;
dssdev->driver = _ops;
-- 
2.13.2

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


[PATCHv1 09/14] drm/omap: panel-dsi-cm: add regulator support

2017-07-24 Thread Sebastian Reichel
Add support for regulators used by panels found inside
of the Nokia N950, N9 and Motorola Droid 4.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 57 +++--
 1 file changed, 53 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 3845a50537a6..95c28f518239 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -60,6 +61,9 @@ struct panel_drv_data {
int reset_gpio;
int ext_te_gpio;
 
+   struct regulator *vpnl;
+   struct regulator *vddi;
+
bool use_dsi_backlight;
 
struct omap_dsi_pin_config pin_config;
@@ -590,25 +594,43 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
.lp_clk_max = 1000,
};
 
+   if (ddata->vpnl) {
+   r = regulator_enable(ddata->vpnl);
+   if (r) {
+   dev_err(>pdev->dev,
+   "failed to enable VPNL: %d\n", r);
+   return r;
+   }
+   }
+
+   if (ddata->vddi) {
+   r = regulator_enable(ddata->vddi);
+   if (r) {
+   dev_err(>pdev->dev,
+   "failed to enable VDDI: %d\n", r);
+   goto err_vpnl;
+   }
+   }
+
if (ddata->pin_config.num_pins > 0) {
r = in->ops.dsi->configure_pins(in, >pin_config);
if (r) {
dev_err(>pdev->dev,
"failed to configure DSI pins\n");
-   goto err0;
+   goto err_vddi;
}
}
 
r = in->ops.dsi->set_config(in, _config);
if (r) {
dev_err(>pdev->dev, "failed to configure DSI\n");
-   goto err0;
+   goto err_vddi;
}
 
r = in->ops.dsi->enable(in);
if (r) {
dev_err(>pdev->dev, "failed to enable DSI\n");
-   goto err0;
+   goto err_vddi;
}
 
dsicm_hw_reset(ddata);
@@ -666,7 +688,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
dsicm_hw_reset(ddata);
 
in->ops.dsi->disable(in, true, false);
-err0:
+err_vddi:
+   if (ddata->vddi)
+   regulator_disable(ddata->vddi);
+err_vpnl:
+   if (ddata->vpnl)
+   regulator_disable(ddata->vpnl);
+
return r;
 }
 
@@ -689,6 +717,11 @@ static void dsicm_power_off(struct panel_drv_data *ddata)
 
in->ops.dsi->disable(in, true, false);
 
+   if (ddata->vddi)
+   regulator_disable(ddata->vddi);
+   if (ddata->vpnl)
+   regulator_disable(ddata->vpnl);
+
ddata->enabled = 0;
 }
 
@@ -1189,6 +1222,22 @@ static int dsicm_probe_of(struct platform_device *pdev)
return PTR_ERR(in);
}
 
+   ddata->vpnl = devm_regulator_get_optional(>dev, "vpnl");
+   if (IS_ERR(ddata->vpnl)) {
+   err = PTR_ERR(ddata->vpnl);
+   if (err == -EPROBE_DEFER)
+   return err;
+   ddata->vpnl = NULL;
+   }
+
+   ddata->vddi = devm_regulator_get_optional(>dev, "vddi");
+   if (IS_ERR(ddata->vddi)) {
+   err = PTR_ERR(ddata->vddi);
+   if (err == -EPROBE_DEFER)
+   return err;
+   ddata->vddi = NULL;
+   }
+
ddata->in = in;
 
/* TODO: ulps, backlight */
-- 
2.13.2

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


Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()

2017-07-24 Thread Ross Zwisler
On Mon, Jul 24, 2017 at 01:15:31PM +0200, Jan Kara wrote:
> On Sat 22-07-17 09:21:31, Dan Williams wrote:
> > On Fri, Jul 21, 2017 at 3:39 PM, Ross Zwisler
> >  wrote:
> > > To be able to use the common 4k zero page in DAX we need to have our PTE
> > > fault path look more like our PMD fault path where a PTE entry can be
> > > marked as dirty and writeable as it is first inserted, rather than waiting
> > > for a follow-up dax_pfn_mkwrite() => finish_mkwrite_fault() call.
> > >
> > > Right now we can rely on having a dax_pfn_mkwrite() call because we can
> > > distinguish between these two cases in do_wp_page():
> > >
> > > case 1: 4k zero page => writable DAX storage
> > > case 2: read-only DAX storage => writeable DAX storage
> > >
> > > This distinction is made by via vm_normal_page().  vm_normal_page() 
> > > returns
> > > false for the common 4k zero page, though, just as it does for DAX ptes.
> > > Instead of special casing the DAX + 4k zero page case, we will simplify 
> > > our
> > > DAX PTE page fault sequence so that it matches our DAX PMD sequence, and
> > > get rid of the dax_pfn_mkwrite() helper.  We will instead use
> > > dax_iomap_fault() to handle write-protection faults.
> > >
> > > This means that insert_pfn() needs to follow the lead of insert_pfn_pmd()
> > > and allow us to pass in a 'mkwrite' flag.  If 'mkwrite' is set 
> > > insert_pfn()
> > > will do the work that was previously done by wp_page_reuse() as part of 
> > > the
> > > dax_pfn_mkwrite() call path.
> > >
> > > Signed-off-by: Ross Zwisler 
> > > ---
> > >  drivers/dax/device.c|  2 +-
> > >  drivers/gpu/drm/exynos/exynos_drm_gem.c |  3 ++-
> > >  drivers/gpu/drm/gma500/framebuffer.c|  2 +-
> > >  drivers/gpu/drm/msm/msm_gem.c   |  3 ++-
> > >  drivers/gpu/drm/omapdrm/omap_gem.c  |  6 --
> > >  drivers/gpu/drm/ttm/ttm_bo_vm.c |  2 +-
> > >  fs/dax.c|  2 +-
> > >  include/linux/mm.h  |  2 +-
> > >  mm/memory.c | 27 +--
> > >  9 files changed, 34 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/dax/device.c b/drivers/dax/device.c
> > > index e9f3b3e..3973521 100644
> > > --- a/drivers/dax/device.c
> > > +++ b/drivers/dax/device.c
> > > @@ -273,7 +273,7 @@ static int __dev_dax_pte_fault(struct dev_dax 
> > > *dev_dax, struct vm_fault *vmf)
> > >
> > > pfn = phys_to_pfn_t(phys, dax_region->pfn_flags);
> > >
> > > -   rc = vm_insert_mixed(vmf->vma, vmf->address, pfn);
> > > +   rc = vm_insert_mixed(vmf->vma, vmf->address, pfn, false);
> > 
> > Ugh, I generally find bool flags unreadable. They place a tax on
> > jumping to function definition to recall what true and false mean. If
> > we want to go this 'add an argument' route can we at least add an enum
> > like:
> > 
> > enum {
> > PTE_MKDIRTY,
> > PTE_MKCLEAN,
> > };
> > 
> > ...to differentiate the two cases?
> 
> So how I usually deal with this is that I create e.g.:
> 
> __vm_insert_mixed() that takes the bool argument, make vm_insert_mixed()
> pass false, and vm_insert_mixed_mkwrite() pass true. That way there's no
> code duplication, old call sites can stay unchanged, the naming clearly
> says what's going on...

Ah, that does seem cleaner.  I'll try that for v5.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCHv1 00/14] omapdrm: DSI command mode panel support

2017-07-24 Thread Sebastian Reichel
Hi,

This adds support for command mode DSI panels to
omapdrm. I tested the patches on Nokia N950 (omap3)
and Motorola Droid 4 (omap4). This is basically
PATCHv3 of my series adding N950 display support,
but I started from scratch without reverting the
removal of manual display update support.

Tested:
 * Framebuffer Console
 * Display blanking
 * kmstest
 * Xorg with omap and modesetting driver
 * No updates send when nothing needs to be sent

Known issues:
 * Proper display rotation support
 * N950 (and N9) has first and last few lines
   covered by plastic, so we should expose a
   smaller screen

I plan to look into these issues once basic support
has been merged.

-- Sebastian

Sebastian Reichel (13):
  drm/omap: remove unused function defines
  drm/omap: drop incorrect comment
  drm/omap: plane: update fifo size on ovl setup
  drm/omap: add framedone interrupt support
  drm/omap: add manual update detection helper
  drm/omap: add support for manually updated displays
  drm/omap: add support for physical size hints from display drivers
  drm/omap: panel-dsi-cm: add regulator support
  drm/omap: panel-dsi-cm: add physical size support
  drm/omap: panel-dsi-cm: add external backlight support
  drm/omap: panel-dsi-cm: switch to gpiod
  ARM: dts: omap4-droid4: improve LCD description
  ARM: dts: n950: add display support

Tony Lindgren (1):
  drm/omap: panel-dsi-cm: fix driver

 arch/arm/boot/dts/omap3-n950.dts|  88 
 arch/arm/boot/dts/omap4-droid4-xt894.dts|   6 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 289 +---
 drivers/gpu/drm/omapdrm/dss/dispc.c |  16 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h   |   5 +-
 drivers/gpu/drm/omapdrm/omap_connector.c|  14 ++
 drivers/gpu/drm/omapdrm/omap_crtc.c | 158 -
 drivers/gpu/drm/omapdrm/omap_drv.h  |   4 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  20 ++
 drivers/gpu/drm/omapdrm/omap_fbdev.c|   3 -
 drivers/gpu/drm/omapdrm/omap_irq.c  |  24 ++
 11 files changed, 529 insertions(+), 98 deletions(-)

-- 
2.13.2

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


Re: [PATCH 000/102] Convert drivers to explicit reset API

2017-07-24 Thread Philipp Zabel
On Sun, 2017-07-23 at 20:41 +0200, Linus Walleij wrote:
> On Thu, Jul 20, 2017 at 10:46 PM, Dmitry Torokhov
>  wrote:
> > On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel  
> > wrote:
> 
> >>> What about reset_control_get(struct device *, const char *, int flags)
> >>> to replace all those variants ?
> >>
> >> While I like how this looks, unfortunately (devm_)reset_control_get
> >> already exists without the flags, so we can't change to that with a
> >> gentle transition.
> >
> > This was done for gpiod_get() and its flags argument with horrifying
> > #define-ry, which thankfully was completely hidden from users.
> 
> For your reference:
> 
> commit bae48da237fcedd7ad09569025483b988635efb7
> "gpiolib: add gpiod_get() and gpiod_put() functions"
> 
> commit 39b2bbe3d715cf5013b5c48695ccdd25bd3bf120
> "gpio: add flags argument to gpiod_get*() functions"
> 
> commit 0dbc8b7afef6e4fddcfebcbacbeb269a0a3b06d5
> "gpio: move varargs hack outside #ifdef GPIOLIB"
> 
> commit b17d1bf16cc72a374a48d748940f79d40ff4
> "gpio: make flags mandatory for gpiod_get functions"
> 
> Retrospectively ... was that really a good idea... it was a LOT
> of trouble to add a flag, maybe it had been better to try and
> just slam all users in a single go.
> 
> But it worked.

Thanks for the hint and the references. It seems this turned out okay,
but I wouldn't dare to introduce such macro horror^Wmagic.
I'd rather have all users converted to the _exclusive/_shared function
calls and maybe then replace the internal __reset_control_get with
Thomas' suggestion.

regards
Philipp

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


Re: [PATCH 4/4] drm/i915: Add support for CCS modifiers

2017-07-24 Thread kbuild test robot
Hi Ben,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane-init/20170725-062539
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/intel_display.c:105:2: error: 
>> 'I915_FORMAT_MOD_Yf_TILED_CCS' undeclared here (not in a function)
 I915_FORMAT_MOD_Yf_TILED_CCS,
 ^~~~
>> drivers/gpu/drm/i915/intel_display.c:106:2: error: 
>> 'I915_FORMAT_MOD_Y_TILED_CCS' undeclared here (not in a function)
 I915_FORMAT_MOD_Y_TILED_CCS,
 ^~~
   drivers/gpu/drm/i915/intel_display.c: In function 'skl_mod_supported':
>> drivers/gpu/drm/i915/intel_display.c:13642:16: warning: comparison between 
>> pointer and integer
  if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
   ^~
   drivers/gpu/drm/i915/intel_display.c:13643:16: warning: comparison between 
pointer and integer
  modifier == I915_FORMAT_MOD_Y_TILED_CCS)
   ^~
--
>> drivers/gpu/drm/i915/intel_sprite.c:1092:2: error: 
>> 'I915_FORMAT_MOD_Yf_TILED_CCS' undeclared here (not in a function)
 I915_FORMAT_MOD_Yf_TILED_CCS,
 ^~~~
>> drivers/gpu/drm/i915/intel_sprite.c:1093:2: error: 
>> 'I915_FORMAT_MOD_Y_TILED_CCS' undeclared here (not in a function)
 I915_FORMAT_MOD_Y_TILED_CCS,
 ^~~

vim +/I915_FORMAT_MOD_Yf_TILED_CCS +105 drivers/gpu/drm/i915/intel_display.c

   103  
   104  static const uint64_t skl_format_modifiers_ccs[] = {
 > 105  I915_FORMAT_MOD_Yf_TILED_CCS,
 > 106  I915_FORMAT_MOD_Y_TILED_CCS,
   107  I915_FORMAT_MOD_Yf_TILED,
   108  I915_FORMAT_MOD_Y_TILED,
   109  I915_FORMAT_MOD_X_TILED,
   110  DRM_FORMAT_MOD_LINEAR,
   111  DRM_FORMAT_MOD_INVALID
   112  };
   113  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 22226] [945] DRI memory manager reports 18014398509481940 kB

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=6

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 20235] [i915] [Regression] VT switch and suspend to disk broken

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=20235

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 17768] 2.6.27-rc5 kernel Oops with i915

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=17768

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 16334] [DRM 945GM] i915 Oops (i915_driver_lastclose) when shutdown X

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=16334

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 26326] [855] Xserver freezing on Toshiba Satellite A10

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=26326

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 12882] [855GM missing DVO driver] s-video not detected

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=12882

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 9751] i915_wait_irq crash on G965, 2.6.19.2

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=9751

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 16245] [kernel modesetting] display mashed after change mode

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=16245

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 19415] [945GM] X fail to start on kernel 2.6.28

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=19415

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 17902] [830M missing dvo driver] need support for DVO-LVDS via na2501

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=17902

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 28430] [865G] OOPS when stolen memory set to zero

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28430

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 27563] [810] Xorg freezes sometimes when playing Crack-Attack (races in drivers/char/drm/drm.ko?)

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27563

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 27541] [830M] [KMS] internal display goes nuts during boot

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27541

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 28509] [852] gpu hang

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=28509

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 30654] [855] flickers when vblank_mode is enabled

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=30654

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 30845] [855 missing dvo driver] DVI output unsupported

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=30845

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[Bug 40181] [845G] GPU Hang on First Login with Display Manager

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=40181

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


Re: [PATCH 30/41] drm/omapdrm: Use the drm_driver.dumb_destroy default

2017-07-24 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patch.

On Sunday 23 Jul 2017 21:16:46 Noralf Trønnes wrote:
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
> 
> Cc: Tomi Valkeinen 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 022029e..ce3341d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -517,7 +517,6 @@ static struct drm_driver omap_drm_driver = {
>   .gem_vm_ops = _gem_vm_ops,
>   .dumb_create = omap_gem_dumb_create,
>   .dumb_map_offset = omap_gem_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
>   .ioctls = ioctls,
>   .num_ioctls = DRM_OMAP_NUM_IOCTLS,
>   .fops = _fops,

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH 14/41] drm/shmobile: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patch.

On Sunday 23 Jul 2017 21:16:30 Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index c2ca073..5925725 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -145,8 +145,6 @@ static struct drm_driver shmob_drm_driver = {
>   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
>   .dumb_create= drm_gem_cma_dumb_create,
> - .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> - .dumb_destroy   = drm_gem_dumb_destroy,
>   .fops   = _drm_fops,
>   .name   = "shmob-drm",
>   .desc   = "Renesas SH Mobile DRM",

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH 01/41] drm/gem: Add drm_gem_dumb_map_offset()

2017-07-24 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patch.

On Sunday 23 Jul 2017 21:16:17 Noralf Trønnes wrote:
> Add a common drm_driver.dumb_map_offset function for GEM backed drivers.
> 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_gem.c | 35 +++
>  include/drm/drm_gem.h |  2 ++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 5df028a..a8d396b 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -311,6 +311,41 @@ drm_gem_handle_delete(struct drm_file *filp, u32
> handle) EXPORT_SYMBOL(drm_gem_handle_delete);
> 
>  /**
> + * drm_gem_dumb_map_offset - return the fake mmap offset for a gem object
> + * @file: drm file-private structure containing the gem object
> + * @dev: corresponding drm_device
> + * @handle: gem object handle
> + * @offset: return location for the fake mmap offset
> + *
> + * This implements the _driver.dumb_map_offset kms driver callback for
> + * drivers which use gem to manage their backing storage.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
> + u32 handle, u64 *offset)
> +{
> + struct drm_gem_object *obj;
> + int ret;
> +
> + obj = drm_gem_object_lookup(file, handle);
> + if (!obj)
> + return -ENOENT;
> +
> + ret = drm_gem_create_mmap_offset(obj);
> + if (ret)
> + goto out;
> +
> + *offset = drm_vma_node_offset_addr(>vma_node);
> +out:
> + drm_gem_object_put_unlocked(obj);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_dumb_map_offset);
> +
> +/**
>   * drm_gem_dumb_destroy - dumb fb callback helper for gem based drivers
>   * @file: drm file-private structure to remove the dumb handle from
>   * @dev: corresponding drm_device
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 4a9d231..9c55c2a 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -302,6 +302,8 @@ void drm_gem_put_pages(struct drm_gem_object *obj,
> struct page **pages, bool dirty, bool accessed);
> 
>  struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
> handle); +int drm_gem_dumb_map_offset(struct drm_file *file, struct
> drm_device *dev, +u32 handle, u64 *offset);
>  int drm_gem_dumb_destroy(struct drm_file *file,
>struct drm_device *dev,
>uint32_t handle);

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH 13/41] drm/rcar-du: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Laurent Pinchart
Hi Noralf,

Thank you for the patch.

On Sunday 23 Jul 2017 21:16:29 Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index d6a0255..c09cf84 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -238,8 +238,6 @@ static struct drm_driver rcar_du_driver = {
>   .gem_prime_vunmap   = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
>   .dumb_create= rcar_du_dumb_create,
> - .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> - .dumb_destroy   = drm_gem_dumb_destroy,
>   .fops   = _du_fops,
>   .name   = "rcar-du",
>   .desc   = "Renesas R-Car Display Unit",

-- 
Regards,

Laurent Pinchart

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


[Bug 92240] [SKL] igt/kms_fbcon_fbt/fbc fail

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=92240

Elizabeth  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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


[PATCH] drm/amdgpu: fix spelling mistake: "suuport"-> "support"

2017-07-24 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in WARN_ONCE message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 5795f81369f0..06f11e2a32af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1301,7 +1301,7 @@ static int amdgpu_vm_update_ptes(struct 
amdgpu_pte_update_params *params,
 
if (params->shadow) {
if (WARN_ONCE(use_cpu_update,
-   "CPU VM update doesn't suuport shadow pages"))
+   "CPU VM update doesn't support shadow pages"))
return 0;
 
if (!pt->shadow)
-- 
2.11.0

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


Re: [PATCH] drm/radeon: Set depth on low mem to 16 bpp instead of 8 bpp

2017-07-24 Thread Alex Deucher
On Wed, Jul 19, 2017 at 4:45 AM, Takashi Iwai  wrote:
> On Tue, 18 Jul 2017 22:53:48 +0200,
> Michel D4nzer wrote:
>>
>> On 18/07/17 11:20 AM, Takashi Iwai wrote:
>> > From: Egbert Eich 
>> >
>> > The radeon driver reduces the framebuffer resolution to 8bpp if a
>> > device with less than 32MB VRAM is found.  This causes the framebuffer
>> > to run in 8 bit paletted mode.  For a text console this is not an
>> > issue as 256 different colors is more than one gets on a VGA text
>> > console.  However this leads to a poor 8bit pseudo-color visual when
>> > running X on fbdev, too, which is quite ugly.
>> >
>> > In this patch, we try to give some moderate compromise: limit the
>> > framebuffer bpp to 8 only when VRAM is 8MB or less, and use 16 bpp
>> > otherwise for 32MB or less VRAM.
>> >
>> > Signed-off-by: Egbert Eich 
>> > Signed-off-by: Takashi Iwai 
>> > ---
>> >
>> > This has been included in SUSE kernel for quite some time, and I'm
>> > trying to upstream this.  The 16bpp looks more reasonable nowadays,
>> > but I know this is a matter of taste, too.  It'd be great if you guys
>> > can comment on this, at least, whether it's uttly non-sense or not.
>>
>> [...]
>>
>> > diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
>> > b/drivers/gpu/drm/radeon/radeon_fb.c
>> > index 356ad90a5238..b5f2642f124b 100644
>> > --- a/drivers/gpu/drm/radeon/radeon_fb.c
>> > +++ b/drivers/gpu/drm/radeon/radeon_fb.c
>> > @@ -347,9 +347,12 @@ int radeon_fbdev_init(struct radeon_device *rdev)
>> > if (list_empty(>ddev->mode_config.connector_list))
>> > return 0;
>> >   - /* select 8 bpp console on RN50 or 16MB cards */
>> > -   if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
>> > +   /* select 8 bpp console on 8MB cards, or 16 bpp on RN50 or 32MB */
>> > +   if (rdev->mc.real_vram_size <= (8*1024*1024))
>> > bpp_sel = 8;
>> > +   else if (ASIC_IS_RN50(rdev) ||
>> > +rdev->mc.real_vram_size <= (32*1024*1024))
>> > +   bpp_sel = 16;
>> > rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL);
>> > if (!rfbdev)
>> >
>>
>> Looks reasonable to me — if nothing else, at least the comment and
>> code will match again! :)
>>
>> My only potential doubt is whether there could be another reason than
>> VRAM size why RN50 should use 8 bpp. Assuming not,
>
> We also hope there no such popular board :)
> FWIW, at least we didn't get a relevant bug report, so far.
>
>> Reviewed-by: Michel Dänzer 
>
> Thanks!

Applied.  thanks!

Alex


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


Re: [PATCH v5 6/7] dt-bindings: display: rockchip: fill Documents for vop series

2017-07-24 Thread Rob Herring
On Thu, Jul 20, 2017 at 10:43:53AM +0800, Mark Yao wrote:
> Signed-off-by: Mark Yao 
> ---
> Changes in v5:
> - clean document commit title
> - move changes description out of docummit commit msg
> 
> Changes in v2:
> - rename rk322x to rk3228
> - correct some vop registers define
> 
>  Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4 
>  1 file changed, 4 insertions(+)

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


Re: [RFC 1/7] drm/gem: Add drm_gem_dumb_map_offset()

2017-07-24 Thread Noralf Trønnes


Den 24.07.2017 10.28, skrev Daniel Vetter:

On Fri, Jul 21, 2017 at 08:41:50PM +0200, Noralf Trønnes wrote:

Den 20.07.2017 10.00, skrev Daniel Vetter:

On Thu, Jul 20, 2017 at 12:13:07AM +0200, Noralf Trønnes wrote:

Den 19.07.2017 23.01, skrev Eric Anholt:

Noralf Trønnes  writes:


Add a common drm_driver.dumb_map_offset function for GEM backed drivers.

Signed-off-by: Noralf Trønnes 

Instead of just introducing the new code, could we replace CMA's code
with calls to this at the same time?

I have gone through all the drm_driver->dumb_map_offset
implementations and found 23 drivers that could use it:
- 18 drivers use drm_gem_cma_dumb_map_offset()
- exynos_drm_gem_dumb_map_offset()
- mtk_drm_gem_dumb_map_offset()
- psb_gem_dumb_map_gtt()
- rockchip_gem_dumb_map_offset()
- tegra_bo_dumb_map_offset()

vgem_gem_dumb_map() can't use it because of this check:
  if (!obj->filp) {
  ret = -EINVAL;
  goto unref;
  }

armada_gem_dumb_map_offset() can't use it because of this check:
  /* Don't allow imported objects to be mapped */
  if (obj->obj.import_attach) {
  ret = -EINVAL;
  goto err_unref;
  }

I see that drivers must implement all 3 .dumb_* callbacks:

   * To support dumb objects drivers must implement the
_driver.dumb_create,
   * _driver.dumb_destroy and _driver.dumb_map_offset operations. See
   * there for further details.

I'm a fan of defaults, is there any reason we can't do this:

So in general we try not to set defaults for the main driver entry hooks,
to avoid the helper functions leaking into core and becoming mandatory.
So e.g. ->atomic_commit should never have a default of
drm_atomic_helper_commit.

Same thought applied here for the dumb buffers - the idea is that drivers
using any kind of buffer manager scheme could have dumb buffers, including
maybe not having a buffer manager at all (and you get some cookie to
direct vram allocations or whatever). But everyone ended up with gem, just
with different kinds of backing storage implementations (cma, shmem or
ttm).

I think it makes sense to make these the defaults and rip out the default
assignment from all drivers.

   int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
   {
   struct drm_mode_map_dumb *args = data;

   /* call driver ioctl to get mmap offset */
- if (!dev->driver->dumb_map_offset)
+if (!dev->driver->dumb_create)
  return -ENOSYS;

- return dev->driver->dumb_map_offset(file_priv, dev, args->handle,
>offset);
+ if (dev->driver->dumb_map_offset)
+return dev->driver->dumb_map_offset(file_priv, dev, args->handle,
>offset);
+else
+return drm_gem_dumb_map_offset(file_priv, dev, args->handle,
>offset);
   }

   int drm_mode_destroy_dumb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
   {
   struct drm_mode_destroy_dumb *args = data;

- if (!dev->driver->dumb_destroy)
+if (!dev->driver->dumb_create)
   return -ENOSYS;

-return dev->driver->dumb_destroy(file_priv, dev, args->handle);
+ if (dev->driver->dumb_destroy)
+return dev->driver->dumb_destroy(file_priv, dev, args->handle);
+else
+return drm_gem_dumb_destroy(file_priv, dev, args->handle);
   }

There are 36 drivers that use drm_gem_dumb_destroy() directly.
vgem violates the docs and doesn't set .dumb_destroy.

Interesting, suprising it doesn't leak like mad.

I suspect that if we had CMA subclass from drm_fb_gem (or we move the
gem objects to the base class), we could remove a lot of its code that
you're copying in patch 2, as well.

Yes, that was the intention.

I guess we'd need to see more of the grand plan ...

Currently it looks like 4 patchsets:

1. Add drm_gem_dumb_map_offset() and implement defaults as discussed above.

2. Add drm_gem_object pointers to drm_framebuffer and create matching
helpers for:
  drm_framebuffer_funcs->create_handle
  drm_framebuffer_funcs->destroy
  drm_mode_config_funcs->fb_create
  Should I put the functions in drm_framebuffer_helper.[h,c] ?

I'd call them drm_gem_framebuffer_helper.[hc], just to highlight the
gem<->kms connection a bit more.


Use these helpers in the cma library

3. Add drm_fb_helper_simple_init() and drm_fb_helper_simple_fini()
Use them in drivers where applicable.

4. Add shmem library
Convert tinydrm to shmem.

Sounds like a good plan. I'll try to scrape away some review bandwidth to
look at your patches.


Thanks, this fanned out a bit more than first expected.

Noralf.

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


Re: [PATCH 00/41] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy

2017-07-24 Thread Noralf Trønnes


Den 23.07.2017 21.16, skrev Noralf Trønnes:

This adds defaults for the drm_driver.dumb_destroy and
drm_driver.dumb_map_offset callbacks as discussed with Daniel.

vmwgfx is the only driver that doesn't use drm_gem_dumb_destroy().

vgem

vgem changes behaviour after this, because it didn't have .dumb_destroy
set, something the docs mandates.

This patchset is part of a process to add a shmem gem library like the
cma library. The common parts between the two goes into core or helpers.

Noralf.



Philipp made me aware that I forgot to remove drm_gem_cma_dumb_map_offset().
I'll make a follow up patch when this is merged.

Noralf.


Noralf Trønnes (41):
   drm/gem: Add drm_gem_dumb_map_offset()
   drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy
   drm/arc: Use .dumb_map_offset and .dumb_destroy defaults
   drm/arm: hdlcd: Use .dumb_map_offset and .dumb_destroy defaults
   drm/arm: mali-dp: Use .dumb_map_offset and .dumb_destroy defaults
   drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults
   drm/fsl-dcu: Use .dumb_map_offset and .dumb_destroy defaults
   drm/kirin: Use .dumb_map_offset and .dumb_destroy defaults
   drm/imx: Use .dumb_map_offset and .dumb_destroy defaults
   drm/meson: Use .dumb_map_offset and .dumb_destroy defaults
   drm/mxsfb: Use .dumb_map_offset and .dumb_destroy defaults
   drm/pl111: Use .dumb_map_offset and .dumb_destroy defaults
   drm/rcar-du: Use .dumb_map_offset and .dumb_destroy defaults
   drm/shmobile: Use .dumb_map_offset and .dumb_destroy defaults
   drm/sti: Use .dumb_map_offset and .dumb_destroy defaults
   drm/stm: Use .dumb_map_offset and .dumb_destroy defaults
   drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults
   drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults
   drm/vc4: Use .dumb_map_offset and .dumb_destroy defaults
   drm/zte: Use .dumb_map_offset and .dumb_destroy defaults
   drm/tinydrm: Use .dumb_map_offset and .dumb_destroy defaults
   drm/mediatek: Use .dumb_map_offset and .dumb_destroy defaults
   drm/gma500: Use .dumb_map_offset and .dumb_destroy defaults
   drm/rockchip: Use .dumb_map_offset and .dumb_destroy defaults
   drm/tegra: Use .dumb_map_offset and .dumb_destroy defaults
   drm/cirrus: Use the drm_driver.dumb_destroy default
   drm/udl: Use the drm_driver.dumb_destroy default
   drm/qxl: Use the drm_driver.dumb_destroy default
   drm/amdgpu: Use the drm_driver.dumb_destroy default
   drm/omapdrm: Use the drm_driver.dumb_destroy default
   drm/ast: Use the drm_driver.dumb_destroy default
   drm/nouveau: Use the drm_driver.dumb_destroy default
   drm/i915: Use the drm_driver.dumb_destroy default
   drm/msm: Use the drm_driver.dumb_destroy default
   drm/exynos: Use the drm_driver.dumb_destroy default
   drm/hisilicon: hibmc: Use the drm_driver.dumb_destroy default
   drm/mgag200: Use the drm_driver.dumb_destroy default
   drm/radeon: Use the drm_driver.dumb_destroy default
   drm/bochs: Use the drm_driver.dumb_destroy default
   drm/armada: Use the drm_driver.dumb_destroy default
   drm/virtio: Use the drm_driver.dumb_destroy default

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  1 -
  drivers/gpu/drm/arc/arcpgu_drv.c|  2 --
  drivers/gpu/drm/arm/hdlcd_drv.c |  2 --
  drivers/gpu/drm/arm/malidp_drv.c|  2 --
  drivers/gpu/drm/armada/armada_drv.c |  1 -
  drivers/gpu/drm/armada/armada_gem.c |  6 -
  drivers/gpu/drm/armada/armada_gem.h |  2 --
  drivers/gpu/drm/ast/ast_drv.c   |  1 -
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  2 --
  drivers/gpu/drm/bochs/bochs_drv.c   |  1 -
  drivers/gpu/drm/cirrus/cirrus_drv.c |  1 -
  drivers/gpu/drm/drm_dumb_buffers.c  | 26 --
  drivers/gpu/drm/drm_gem.c   | 35 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |  1 -
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  2 --
  drivers/gpu/drm/gma500/gem.c| 30 -
  drivers/gpu/drm/gma500/psb_drv.c|  2 --
  drivers/gpu/drm/gma500/psb_drv.h|  2 --
  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c |  1 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  2 --
  drivers/gpu/drm/i915/i915_drv.c |  1 -
  drivers/gpu/drm/imx/imx-drm-core.c  |  2 --
  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  2 --
  drivers/gpu/drm/mediatek/mtk_drm_gem.c  | 25 --
  drivers/gpu/drm/mediatek/mtk_drm_gem.h  |  3 ---
  drivers/gpu/drm/meson/meson_drv.c   |  2 --
  drivers/gpu/drm/mgag200/mgag200_drv.c   |  1 -
  drivers/gpu/drm/msm/msm_drv.c   |  1 -
  drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 --
  drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
  drivers/gpu/drm/omapdrm/omap_drv.c  |  1 -
  

Re: [PATCH 09/41] drm/imx: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Noralf Trønnes


Den 24.07.2017 09.46, skrev Philipp Zabel:

On Sun, 2017-07-23 at 21:16 +0200, Noralf Trønnes wrote:

This driver can use the drm_driver.dumb_destroy and
drm_driver.dumb_map_offset defaults, so no need to set them.

Cc: Philipp Zabel 
Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/imx/imx-drm-core.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f5c6212..f91cb72 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -182,8 +182,6 @@ static struct drm_driver imx_drm_driver = {
.gem_free_object_unlocked = drm_gem_cma_free_object,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create= drm_gem_cma_dumb_create,
-   .dumb_map_offset= drm_gem_cma_dumb_map_offset,

Are there any users of drm_gem_cma_dumb_map_offset left after patch 21?


You're quite right, there isn't, I forgot to remove it :-)
Thanks.

Noralf.


-   .dumb_destroy   = drm_gem_dumb_destroy,
  
  	.prime_handle_to_fd	= drm_gem_prime_handle_to_fd,

.prime_fd_to_handle = drm_gem_prime_fd_to_handle,

Acked-by: Philipp Zabel 

regards
Philipp



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


[Bug 94410] [radeonsi] Unreal engine 4 Segmentation fault

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=94410

--- Comment #2 from Felix Hellmann  ---
This still happens in current git (dd072cf4b1) with unreal editor 4.16.

Kernel 4.12.3-ARCH
Rx 480
libdrm-2.4.82

Full log output from two runs. One with default binned2 malloc and one with
ansimalloc:

https://pastebin.com/tmCAaEkX

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


[Bug 99316] Radeon crash when laptop on AC power

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=99316

--- Comment #10 from mat...@yahoo.de ---
I have also a Dell notebook with the same dGPU, but cannot reproduce your error
with Ubuntu 16.04 kernel 4.10.0.

Instead I have the problem, that the dGPU only gets powered at a low frequency,
and becomes slower than the Intel GPU by doing so. 

When I run glmark2, I look at "/sys/kernel/debug/dri/0/radeon_pm_info" and
always see the following output:

default engine clock: 925000 kHz
current engine clock: 20 kHz
default memory clock: 100 kHz
current memory clock: 148990 kHz
voltage: 1225 mV
PCIE lanes: 16

Btw.: This dGPU cannot be connected to a CRT directly, as there seems to be no
connection available at all.

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


Re: linux-next: build failure after merge of the drm-misc tree

2017-07-24 Thread Greg KH
On Mon, Jul 24, 2017 at 10:24:41AM +0200, Daniel Vetter wrote:
> On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell  
> wrote:
> > Hi Daniel,
> >
> > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter  
> > wrote:
> >>
> >> How are we going to handle this now? The refactor is deeply burried in
> >> drm-misc, I guess you could cherry-pick the relevant patches over. But
> >> that'll probably lead to more conflicts because git will get confused.
> >
> > I'll just keep applying the merge resolution patch and will remind Dave
> > and Greg about it during the week before the merge window opens so that
> > they can let Linus know that the fix up is needed.
> 
> Well, Greg squeezed the vbox driver into -rc2, so now we already get
> to resolve this in a backmerge. And hopefully the bikeshed patches in
> -staging won't interfere too badly with whatever refactoring we'll do
> in drm-next.
> 
> Greg, fyi this is the last time I'll ack a drm driver for staging.
> This just doesn't work. We're spending more time here working the
> -staging vs. drm-next conflicts than the actual vbox driver review has
> taken me. And probly less than the cleanup for merging directly to
> drm-next will end up taking.

Hey, I was amazed that you all acked it, and it's why I required that
you do so before I took it :)

Good luck with the merges!

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


[RFC v3] drm/hdcp: drm enum property for CP State

2017-07-24 Thread Ramalingam C
DRM connector property is created to represent the content protection
state of the connector and to configure the same.

Content protection states defined:
DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
DRM_MODE_CONTENT_PROTECTION_ENABLE  - Enabled

v2: Redesigned the property to match with CP needs of CrOS [Sean].

v3: Renamed the state names. Header is removed [sean].

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/drm_connector.c | 14 ++
 include/drm/drm_mode_config.h   |  5 +
 include/uapi/drm/drm_mode.h |  5 +
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5cd61af..d6aaa08 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -617,6 +617,13 @@ static const struct drm_prop_enum_list 
drm_link_status_enum_list[] = {
 };
 DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 
+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+   { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED,  "Unsupported" },
+   { DRM_MODE_CONTENT_PROTECTION_DISABLE,  "Disabled" },
+   { DRM_MODE_CONTENT_PROTECTION_ENABLE,   "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -789,6 +796,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "Content Protection",
+   drm_cp_enum_list,
+   ARRAY_SIZE(drm_cp_enum_list));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.cp_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 4298171..7acb8b2 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -538,6 +538,11 @@ struct drm_mode_config {
 */
struct drm_property *link_status_property;
/**
+* @cp_property: Default connector property for CP
+* of a connector
+*/
+   struct drm_property *cp_property;
+   /**
 * @plane_type_property: Default plane property to differentiate
 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f..554a770 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -127,6 +127,11 @@ extern "C" {
 #define DRM_MODE_LINK_STATUS_GOOD  0
 #define DRM_MODE_LINK_STATUS_BAD   1
 
+/* Content Protection options */
+#define DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED0
+#define DRM_MODE_CONTENT_PROTECTION_DISABLE1
+#define DRM_MODE_CONTENT_PROTECTION_ENABLE 2
+
 /*
  * DRM_MODE_ROTATE_
  *
-- 
2.7.4

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


Re: [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

2017-07-24 Thread Harry Wentland
On 2017-07-24 10:54 AM, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
> 
> When that happens (a monitor is replaced by another one during suspend),
> no hotplug event will be triggered so the change will not be caught at
> resume time. Detecting that the EDID changed allows detecting it.
> 

This makes sense and could be used by other drivers.

Acked-by: Harry Wentland 

Harry

> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/drm_edid.c | 45 +
>  include/drm/drm_edid.h |  3 +++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 6bb6337be920..f6ce8bc2907a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector 
> *connector,
>   }
>   return;
>  }
> +
> +/**
> + * drm_check_edid_changed - Check whether the EDID changed since the last 
> update
> + * @connector: connector we're probing
> + * @adapter: I2C adapter to use for DDC
> + *
> + * Check whether the EDID changed since the last time it was updated in the
> + * drm blob cache.
> + *
> + * Return: A boolean indicating whether a change happened or not.
> + */
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter)
> +{
> + struct drm_property_blob *edid_blob;
> + struct edid *edid_stored;
> + struct edid *edid_read;
> + int ret = 0;
> +
> + if (!connector->edid_blob_ptr)
> + return false;
> +
> + edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
> + if (!edid_blob)
> + return false;
> +
> + if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
> + goto out;
> +
> + edid_stored = (struct edid *) edid_blob->data;
> +
> + edid_read = drm_get_edid(connector, adapter);
> + if (!edid_read)
> + goto out;
> +
> + ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
> +
> + kfree(edid_read);
> +
> +out:
> + drm_property_blob_put(edid_blob);
> +
> + return ret != 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_check_edid_changed);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 1e1908a6b1d6..593a97b269c3 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
> *name,
>  struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
>  int hsize, int vsize, int fresh,
>  bool rb);
> +bool drm_check_edid_changed(struct drm_connector *connector,
> + struct i2c_adapter *adapter);
> +
>  #endif /* __DRM_EDID_H__ */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/5] dt-bindings: gpu: add a power_model optional properties for MALI

2017-07-24 Thread Rob Herring
On Tue, Jul 18, 2017 at 08:58:50AM +0800, Caesar Wang wrote:
> Rob,
> 
> 在 2017年07月18日 04:07, Rob Herring 写道:
> > On Mon, Jul 17, 2017 at 04:14:28PM +0800, Caesar Wang wrote:
> > > This patch adds the MALI's power-model to set the IPA model to be used
> > > for power management.
> > What's IPA? India Pale Ale or Intermediate Physical Address?
> 
> IPA is intelligent Power Allocator.  (As the ARM introduced on
> https://developer.arm.com/open-source/intelligent-power-allocation)
> 
> > 
> > > Signed-off-by: Caesar Wang 
> > > ---
> > > 
> > > Changes in v2: None
> > > 
> > >   Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 12 
> > > 
> > >   1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt 
> > > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> > > index a461e47..b616e6b 100644
> > > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> > > @@ -37,6 +37,18 @@ Optional properties:
> > >   - operating-points-v2 : Refer to 
> > > Documentation/devicetree/bindings/power/opp.txt
> > > for details.
> > > +- power_model : Sets power model parameters. Note that this model was 
> > > designed for the Juno
> > > + platform, and may not be suitable for other platforms. A 
> > > structure containing :
> > > + - compatible: Should be arm,mali-simple-power-model
> > > + - dynamic-coefficient: Coefficient, in pW/(Hz V^2), which is multiplied
> > > +   by v^2*f to calculate the dynamic power consumption.
> > > + - static-coefficient: Coefficient, in uW/V^3, which is multiplied by
> > > +   v^3 to calculate the static power consumption.
> > > + - ts: An array containing coefficients for the temperature scaling
> > > +   factor. This is used to scale the static power by a factor of
> > > +   tsf/100, where tsf = ts[3]*T^3 + ts[2]*T^2 + ts[1]*T + ts[0],
> > > +   and T = temperature in degrees.
> > > + - thermal-zone: A string identifying the thermal zone used for the GPU
> > This can all easily be implied by the compatible string. I'm not
> > inclined to accept something Mali specific here.
> 
> Isn't  arm,mali-midgard.txt document suit for Mali specific? :-)

It is, but I'm saying we shouldn't have something Mali specific here. It 
should be something that works across different GPUs at least. IOW, get 
some agreement with say adreno folks that these properties are useful and 
I'll be more receptive. 

> > 
> > This looks *very* precise, but I'd be surprised if these values are any
> > more than magic values (at least the dynamic coef) adjusted until the
> > desired power/performance requirements are achieved. To put it another
> > way, why don't we have similar values for CPUs?
> 
> These value was calculated by running full GPU process.
> 
> CPU had the similar value for dtsi.
> 
> Say: arch/arm64/boot/dts/rockchip/rk3399.dtsi
> cpu_b0: cpu@100 {
> ...
> dynamic-power-coefficient = <436>;
> ...
> };

Indeed. While it is documented for ARM CPUs, I don't see that it 
is widely used as only the hi6220 dts defines it. So either support for 
platforms is just missing, or upstream is not really using this property.

And if we are going to use this, then it needs to be documented in a 
common location and moved out of arm/cpus.txt.

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


Re: [PATCH 12/41] drm/pl111: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Eric Anholt
Noralf Trønnes  writes:

> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.

Reviewed-by: Eric Anholt 


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


Re: [PATCH 19/41] drm/vc4: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-24 Thread Eric Anholt
Noralf Trønnes  writes:

> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.

Reviewed-by: Eric Anholt 


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


Re: [PATCH 02/41] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy

2017-07-24 Thread Eric Anholt
Noralf Trønnes  writes:

> Almost everyone did end up using GEM as bo, so this adds defaults
> for the drm_driver.dumb_destroy and drm_driver.dumb_map_offset
> callbacks.
>
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_dumb_buffers.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index 10307cc..cd68ab4 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -24,6 +24,7 @@
>   */
>  
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> @@ -42,9 +43,10 @@
>   * create dumb buffers suitable for scanout, which can then be used to create
>   * KMS frame buffers.
>   *
> - * To support dumb objects drivers must implement the 
> _driver.dumb_create,
> - * _driver.dumb_destroy and _driver.dumb_map_offset operations. See
> - * there for further details.
> + * To support dumb objects drivers must implement the _driver.dumb_create
> + * operation. _driver.dumb_destroy defaults to drm_gem_dumb_destroy() if
> + * not set and _driver.dumb_map_offset operations to

s/operations/default/ I think

Other than that, patch 1-2 are:

Reviewed-by: Eric Anholt 

Thanks for working on these cleanups!


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


Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()

2017-07-24 Thread Jan Kara
On Mon 24-07-17 09:23:57, Ross Zwisler wrote:
> On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, 
> > > unsigned long addr,
> > >   if (!pte)
> > >   goto out;
> > >   retval = -EBUSY;
> > > - if (!pte_none(*pte))
> > > - goto out_unlock;
> > > + if (!pte_none(*pte)) {
> > > + if (mkwrite) {
> > > + if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
> > 
> > Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> > mappings has triggered this situation if I'm right...
> 
> Yep, I think this WARN_ON_ONCE() is correct.  The test with private mappings
> had collisions between read-only DAX mappings which were being faulted in via
> insert_pfn(), and read/write COW page cache mappings which were being faulted
> in by wp_page_copy().
> 
> I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
> insert_pfn() outside of the mkwrite case, i.e.:
> 
>   if (!pte_none(*pte)) {
>   if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
>   goto out_unlock;
>   if (mkwrite) {
>   entry = *pte;
>   goto out_mkwrite;
>   } else
>   goto out_unlock;
>   }
> 
> This was triggering when one thread was faulting in a read-only DAX mapping
> when another thread had already faulted in a read-write COW page cache page.
> 
> The patches I sent out have the warning in the mkwrite case, which would mean
> that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
> didn't match what was already in the PTE.
> 
> This can't ever happen in the private mapping case because we will never
> install a read/write PTE for normal storage, only for COW page cache pages.
> Essentially I don't think we should ever be able to hit this warning, and if
> we do I'd like to get the bug report so that I can track down how it was
> happening and make sure that it's safe.  It is in the mkwrite path of
> insert_pfn() which is currently only used by the DAX code.
> 
> Does that make sense to you, or would you recommend leaving it out?  (If so,
> why?)

Ah, OK, makes sense. So feel free to add:

Reviewed-by: Jan Kara 

Honza
-- 
Jan Kara 
SUSE Labs, CR
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101832

--- Comment #7 from Laurent carlier  ---
With debug symbols, backtrace is a bit different:

[442527.173] (EE) Backtrace:
[442527.174] (EE) 0: /usr/lib/xorg-server/Xorg (OsSigHandler+0x2a)
[0x5645b1d61fba]
[442527.174] (EE) 1: /usr/lib/libpthread.so.0 (funlockfile+0x50)
[0x7fe7639f982f]
[442527.174] (EE) 2: /usr/lib/libc.so.6 (strlen+0x26) [0x7fe7636c48c6]
[442527.175] (EE) 3: /usr/lib/xorg/modules/dri/radeonsi_dri.so
(_ZN8KnobBase30autoExpandEnvironmentVariablesERNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x120)
[0x7fe75eb34630]
[442527.175] (EE) 4: /usr/lib/xorg/modules/dri/radeonsi_dri.so
(_ZN11GlobalKnobsC1Ev+0x13b) [0x7fe75eb34fbb]
[442527.175] (EE) 5: /usr/lib/xorg/modules/dri/radeonsi_dri.so
(_GLOBAL__sub_I_gen_knobs.cpp+0x10) [0x7fe75e3f25f0]
[442527.176] (EE) 6: /lib64/ld-linux-x86-64.so.2 (call_init.part.0+0x9a)
[0x7fe765c5237a]
[442527.176] (EE) 7: /lib64/ld-linux-x86-64.so.2 (_dl_init+0x76)
[0x7fe765c52486]
[442527.176] (EE) 8: /lib64/ld-linux-x86-64.so.2 (dl_open_worker+0x38e)
[0x7fe765c5693e]
[442527.177] (EE) 9: /usr/lib/libc.so.6 (_dl_catch_error+0x84) [0x7fe763769e44]
[442527.177] (EE) 10: /lib64/ld-linux-x86-64.so.2 (_dl_open+0xca)
[0x7fe765c5615a]
[442527.177] (EE) unw_get_proc_name failed: no unwind info found [-10]
[442527.177] (EE) 11: /usr/lib/libdl.so.2 (?+0xca) [0x7fe7652c3f1a]
[442527.177] (EE) 12: /usr/lib/libc.so.6 (_dl_catch_error+0x84)
[0x7fe763769e44]
[442527.178] (EE) 13: /usr/lib/libdl.so.2 (dlerror+0x2e7) [0x7fe7652c4827]
[442527.178] (EE) 14: /usr/lib/libdl.so.2 (dlopen+0x42) [0x7fe7652c3f42]
[442527.178] (EE) 15: /usr/lib/libgbm.so.1 (dri_open_driver.isra.5+0x1b4)
[0x7fe75fef8984]
[442527.178] (EE) 16: /usr/lib/libgbm.so.1 (dri_screen_create_dri2+0x2c)
[0x7fe75fef8aac]
[442527.178] (EE) 17: /usr/lib/libgbm.so.1 (dri_device_create+0x168)
[0x7fe75fef8f28]
[442527.178] (EE) 18: /usr/lib/libgbm.so.1 (gbm_create_device+0x57)
[0x7fe75fef6e07]
[442527.178] (EE) 19: /usr/lib/xorg/modules/drivers/amdgpu_drv.so
(_init+0x7ffd) [0x7fe7603218dd]
[442527.179] (EE) 20: /usr/lib/xorg-server/Xorg (InitOutput+0xb10)
[0x5645b1c3edc0]
[442527.179] (EE) 21: /usr/lib/xorg-server/Xorg (dix_main+0x1e2)
[0x5645b1bfbb92]
[442527.179] (EE) 22: /usr/lib/libc.so.6 (__libc_start_main+0xea)
[0x7fe7636624ca]
[442527.179] (EE) 23: /usr/lib/xorg-server/Xorg (_start+0x2a) [0x5645b1be553a]
[442527.179] (EE)
[442527.179] (EE) Segmentation fault at address 0x0
[442527.179] (EE)
Fatal server error:
[442527.179] (EE) Caught signal 11 (Segmentation fault). Server aborting
[442527.179] (EE)
[442527.179] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.

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


Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Harry Wentland
On 2017-07-24 10:06 AM, Ricardo Ribalda Delgado wrote:
> Hi Harry
> On Mon, Jul 24, 2017 at 4:01 PM, Harry Wentland  
> wrote:
> 
>>
>> This is used and needed by the DC display driver. See
>> display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:
>>
>> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11
>>
> 
> I could not find any reference to the function in linux-next (>4.12)
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/amd
> 
> Is there any plan to merge Alex's amd-stagin tree?

The plan is to merge/upstream the amd/display portion of Alex's
amd-staging tree. We're currently working on the community feedback we
received to get it into shape.

Harry

> 
> Sorry, I am not very familiar with this subsystem.
> 
> Regards!
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH 1/4] drm/modes: Fix drm_mode_is_420_only() comment

2017-07-24 Thread Sharma, Shashank
Reviewed-by: Shashank Sharma 

Regards
Shashank

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Sean Paul
Sent: Thursday, July 20, 2017 11:18 PM
To: dri-devel@lists.freedesktop.org
Cc: Vetter, Daniel 
Subject: [PATCH 1/4] drm/modes: Fix drm_mode_is_420_only() comment

Fixes the following warnings when building docs:
../drivers/gpu/drm/drm_modes.c:1623: warning: No description found for 
parameter 'display'
../drivers/gpu/drm/drm_modes.c:1623: warning: Excess function parameter 
'connector' description in 'drm_mode_is_420_only'

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_modes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 
d52f0a17a66b..4a3f68a33844 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1610,7 +1610,7 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
  * drm_mode_is_420_only - if a given videomode can be only supported in 
YCBCR420
  * output format
  *
- * @connector: drm connector under action.
+ * @display: display under action
  * @mode: video mode to be tested.
  *
  * Returns:
--
2.14.0.rc0.284.gd933b75aa4-goog

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


[Bug 101900] No HDMI audio on Polaris

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101900

--- Comment #1 from Direx  ---
Created attachment 132869
  --> https://bugs.freedesktop.org/attachment.cgi?id=132869=edit
Alsa codec info for HDMI device

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


[Bug 101900] No HDMI audio on Polaris

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101900

Bug ID: 101900
   Summary: No HDMI audio on Polaris
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: di...@betriebsdirektor.de

Created attachment 132868
  --> https://bugs.freedesktop.org/attachment.cgi?id=132868=edit
dmesg

I am using the current amd-staging-4.11 tree with DC/DAL and HDMI audio is
still not working on my RX480. I have already experimented with the
amdgpu.audio parameter, but it does not change anything.

alsamixer shows 6 different SPDIF devices for "HDA ATI HDMI" and they are all
unmuted. Still HDMI audio is not working at all.

The dmesg actually looks promising, as dc_link_detect detects my AVR and quite
a few sound modes with different channel numbers.

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


Re: FW: [PATCH v2 2/4] drm: Fix warning when building docs for scdc_helper

2017-07-24 Thread Sharma, Shashank
Thanks for adding this fix , Sean, and sorry about missing this 
alignment in doc.


Regards
Shashank
On 7/24/2017 9:01 PM, Sharma, Shashank wrote:


-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Sean Paul
Sent: Friday, July 21, 2017 1:39 AM
To: dri-devel@lists.freedesktop.org; dan...@ffwll.ch
Cc: Vetter, Daniel 
Subject: [PATCH v2 2/4] drm: Fix warning when building docs for scdc_helper

Fixes:
../drivers/gpu/drm/drm_scdc_helper.c:203: ERROR: Unexpected indentation.
../drivers/gpu/drm/drm_scdc_helper.c:204: WARNING: Block quote ends without a 
blank line; unexpected unindent.

Changes in v2:
  - Property blockquote TMDS calculations so they look pretty (Daniel)
  - Remove duplicate documentation from the header file

Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/drm_scdc_helper.c | 33 -
  include/drm/drm_scdc_helper.h | 25 -
  2 files changed, 20 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/drm_scdc_helper.c 
b/drivers/gpu/drm/drm_scdc_helper.c
index 3cd96a95736d..7d1b0f011d33 100644
--- a/drivers/gpu/drm/drm_scdc_helper.c
+++ b/drivers/gpu/drm/drm_scdc_helper.c
@@ -194,19 +194,26 @@ EXPORT_SYMBOL(drm_scdc_set_scrambling);
   * @adapter: I2C adapter for DDC channel
   * @set: ret or reset the high clock ratio
   *
- * TMDS clock ratio calculations go like this:
- * TMDS character = 10 bit TMDS encoded value
- * TMDS character rate = The rate at which TMDS characters are 
transmitted(Mcsc)
- * TMDS bit rate = 10x TMDS character rate
- * As per the spec:
- * TMDS clock rate for pixel clock < 340 MHz = 1x the character rate
- * = 1/10 pixel clock rate
- * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character rate
- * = 1/40 pixel clock rate
- *
- * Writes to the TMDS config register over SCDC channel, and:
- * sets TMDS clock ratio to 1/40 when set = 1
- * sets TMDS clock ratio to 1/10 when set = 0
+ *
+ * TMDS clock ratio calculations go like this:
+ * TMDS character = 10 bit TMDS encoded value
+ *
+ * TMDS character rate = The rate at which TMDS characters are
+ * transmitted (Mcsc)
+ *
+ * TMDS bit rate = 10x TMDS character rate
+ *
+ * As per the spec:
+ * TMDS clock rate for pixel clock < 340 MHz = 1x the character
+ * rate = 1/10 pixel clock rate
+ *
+ * TMDS clock rate for pixel clock > 340 MHz = 0.25x the character
+ * rate = 1/40 pixel clock rate
+ *
+ * Writes to the TMDS config register over SCDC channel, and:
+ * sets TMDS clock ratio to 1/40 when set = 1
+ *
+ * sets TMDS clock ratio to 1/10 when set = 0
   *
   * Returns:
   * True if write is successful, false otherwise.
diff --git a/include/drm/drm_scdc_helper.h b/include/drm/drm_scdc_helper.h 
index c25122bb490a..f92eb2094d6b 100644
--- a/include/drm/drm_scdc_helper.h
+++ b/include/drm/drm_scdc_helper.h
@@ -131,31 +131,6 @@ static inline int drm_scdc_writeb(struct i2c_adapter 
*adapter, u8 offset,
  
  bool drm_scdc_get_scrambling_status(struct i2c_adapter *adapter);
  
-/**

- * drm_scdc_set_scrambling - enable scrambling
- * @adapter: I2C adapter for DDC channel
- * @enable: bool to indicate if scrambling is to be enabled/disabled
- *
- * Writes the TMDS config register over SCDC channel, and:
- * enables scrambling when enable = 1
- * disables scrambling when enable = 0
- *
- * Returns:
- * True if scrambling is set/reset successfully, false otherwise.
- */
  bool drm_scdc_set_scrambling(struct i2c_adapter *adapter, bool enable);
-
-/**
- * drm_scdc_set_high_tmds_clock_ratio - set TMDS clock ratio
- * @adapter: I2C adapter for DDC channel
- * @set: ret or reset the high clock ratio
- *
- * Writes to the TMDS config register over SCDC channel, and:
- * sets TMDS clock ratio to 1/40 when set = 1
- * sets TMDS clock ratio to 1/10 when set = 0
- *
- * Returns:
- * True if write is successful, false otherwise.
- */
  bool drm_scdc_set_high_tmds_clock_ratio(struct i2c_adapter *adapter, bool 
set);  #endif
--
2.14.0.rc0.284.gd933b75aa4-goog


Reviewed-by: Shashank Sharma 


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


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


[Bug 101832] [regression][bisect] sddm fails to start after f50aa21456d82c8cb6fbaa565835f1acc1720a5d

2017-07-24 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=101832

--- Comment #6 from Laurent carlier  ---
The patchset fixes the unresolved symbols, but segfault is still here. I will
try to grab a better backtrace.

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


RE: [PATCH 29/41] drm/amdgpu: Use the drm_driver.dumb_destroy default

2017-07-24 Thread Deucher, Alexander
> -Original Message-
> From: Noralf Trønnes [mailto:nor...@tronnes.org]
> Sent: Sunday, July 23, 2017 3:17 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Deucher, Alexander; abrod...@synopsys.com;
> alison.w...@freescale.com; benjamin.gaign...@linaro.org;
> bske...@redhat.com; boris.brezil...@free-electrons.com;
> brian.star...@arm.com; puck.c...@hisilicon.com; Koenig, Christian;
> ck...@mediatek.com; daniel.vet...@intel.com; airl...@redhat.com;
> e...@anholt.net; kra...@redhat.com; jani.nik...@linux.intel.com;
> jy0922.s...@samsung.com; jsa...@ti.com; kyungmin.p...@samsung.com;
> laurent.pinch...@ideasonboard.com; liviu.du...@arm.com;
> ma...@denx.de; mark@rock-chips.com; maxime.ripard@free-
> electrons.com; narmstr...@baylibre.com; patrik.r.jakobs...@gmail.com;
> philippe.co...@st.com; p.za...@pengutronix.de; robdcl...@gmail.com;
> zourongr...@gmail.com; li...@armlinux.org.uk;
> sw0312@samsung.com; shawn...@kernel.org; ste...@agner.ch;
> thierry.red...@gmail.com; tomi.valkei...@ti.com; vincent.abr...@st.com;
> z.liuxinli...@hisilicon.com; kong.kongxin...@hisilicon.com;
> yannick.fer...@st.com; Noralf Trønnes
> Subject: [PATCH 29/41] drm/amdgpu: Use the drm_driver.dumb_destroy
> default
> 
> drm_gem_dumb_destroy() is the drm_driver.dumb_destroy default,
> so no need to set it.
> 
> Cc: Alex Deucher 
> Cc: Christian König 
> Signed-off-by: Noralf Trønnes 

This and the radeon patch are:
Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 4699924..3c57102 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -822,7 +822,6 @@ static struct drm_driver kms_driver = {
>   .gem_close_object = amdgpu_gem_object_close,
>   .dumb_create = amdgpu_mode_dumb_create,
>   .dumb_map_offset = amdgpu_mode_dumb_mmap,
> - .dumb_destroy = drm_gem_dumb_destroy,
>   .fops = _driver_kms_fops,
> 
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> --
> 2.7.4

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


[PATCH 2/2] drm/i915: Detect monitor change from EDID change after resume

2017-07-24 Thread Paul Kocialkowski
This introduces a dedicated work and related helpers to detect whether
a monitor was replaced by another one during suspend. This detection is
based on EDID change detection, using the associated generic drm helper.

This requires storing more information to the intel_connector structure,
such as the i2c adapter required to get the EDID.

Support for this is introduced for DP, HDMI and VGA.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/i915/i915_drv.c  |  2 ++
 drivers/gpu/drm/i915/i915_drv.h  |  5 
 drivers/gpu/drm/i915/intel_crt.c |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 50 
 drivers/gpu/drm/i915/intel_dp.c  |  3 +++
 drivers/gpu/drm/i915/intel_drv.h |  6 +
 drivers/gpu/drm/i915/intel_hdmi.c|  3 +++
 7 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3ac8215c0e36..b3cf4112fc65 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1702,6 +1702,8 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_display_resume(dev);
 
+   intel_edid_changes_detect(dev);
+
drm_kms_helper_poll_enable(dev);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b051122c960b..2c189a5b714e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3904,6 +3904,11 @@ intel_display_capture_error_state(struct 
drm_i915_private *dev_priv);
 extern void intel_display_print_error_state(struct drm_i915_error_state_buf *e,
struct intel_display_error_state 
*error);
 
+/* edid change */
+void intel_edid_change_init(struct intel_connector *connector,
+   struct i2c_adapter *adapter);
+void intel_edid_changes_detect(struct drm_device *dev);
+
 int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32 
*val);
 int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32 
val);
 int skl_pcode_request(struct drm_i915_private *dev_priv, u32 mbox, u32 request,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 84a1f5e85153..63e2184a6ea4 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -925,6 +925,9 @@ void intel_crt_init(struct drm_i915_private *dev_priv)
 */
crt->force_hotplug_required = 0;
 
+   intel_edid_change_init(intel_connector,
+  intel_gmbus_get_adapter(dev_priv, 
dev_priv->vbt.crt_ddc_pin));
+
/*
 * TODO: find a proper way to discover whether we need to set the the
 * polarity and link reversal bits or not, instead of relying on the
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6c823cc02db3..69e306759a02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15016,3 +15016,53 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,
 }
 
 #endif
+
+static void intel_edid_change_work_func(struct work_struct *work)
+{
+   struct intel_connector *connector =
+   container_of(work, struct intel_connector, edid_change_work);
+   bool changed;
+
+   changed = drm_check_edid_changed(>base, connector->adapter);
+   if (changed) {
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] EDID change detected\n",
+ connector->base.base.id, connector->base.name);
+
+   drm_kms_helper_hotplug_event(connector->base.dev);
+   }
+}
+
+/**
+ * intel_edid_change_init - init the EDID change data
+ * @connector: DRM connector device to use
+ * @adapter: i2c adapter
+ *
+ * Store the i2c adapter and initialize the EDID change detection work.
+ */
+void intel_edid_change_init(struct intel_connector *connector,
+   struct i2c_adapter *adapter)
+{
+   connector->adapter = adapter;
+
+   INIT_WORK(>edid_change_work, intel_edid_change_work_func);
+}
+
+/**
+ * intel_edid_changes_detect - detect EDID changes to connectors
+ * @dev: DRM device to get connectors from
+ *
+ * Schedule the EDID detection change work for all registered connectors.
+ */
+void intel_edid_changes_detect(struct drm_device *dev)
+{
+   struct intel_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+
+   drm_connector_list_iter_begin(dev, _iter);
+   for_each_intel_connector_iter(connector, _iter) {
+   if (!connector->adapter)
+   continue;
+
+   schedule_work(>edid_change_work);
+   }
+}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2d42d09428c9..bc4dbb076096 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6063,6 +6063,9 @@ intel_dp_init_connector(struct 

[PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

2017-07-24 Thread Paul Kocialkowski
This adds a common drm helper to detect whether the EDID changed from
the last known cached one. This is useful help detect that a monitor was
changed during a suspend/resume cycle.

When that happens (a monitor is replaced by another one during suspend),
no hotplug event will be triggered so the change will not be caught at
resume time. Detecting that the EDID changed allows detecting it.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/drm_edid.c | 45 +
 include/drm/drm_edid.h |  3 +++
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6bb6337be920..f6ce8bc2907a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5036,3 +5036,48 @@ static void drm_get_displayid(struct drm_connector 
*connector,
}
return;
 }
+
+/**
+ * drm_check_edid_changed - Check whether the EDID changed since the last 
update
+ * @connector: connector we're probing
+ * @adapter: I2C adapter to use for DDC
+ *
+ * Check whether the EDID changed since the last time it was updated in the
+ * drm blob cache.
+ *
+ * Return: A boolean indicating whether a change happened or not.
+ */
+bool drm_check_edid_changed(struct drm_connector *connector,
+   struct i2c_adapter *adapter)
+{
+   struct drm_property_blob *edid_blob;
+   struct edid *edid_stored;
+   struct edid *edid_read;
+   int ret = 0;
+
+   if (!connector->edid_blob_ptr)
+   return false;
+
+   edid_blob = drm_property_blob_get(connector->edid_blob_ptr);
+   if (!edid_blob)
+   return false;
+
+   if (!edid_blob->data || edid_blob->length != sizeof(struct edid))
+   goto out;
+
+   edid_stored = (struct edid *) edid_blob->data;
+
+   edid_read = drm_get_edid(connector, adapter);
+   if (!edid_read)
+   goto out;
+
+   ret = memcmp(edid_stored, edid_read, sizeof(struct edid));
+
+   kfree(edid_read);
+
+out:
+   drm_property_blob_put(edid_blob);
+
+   return ret != 0;
+}
+EXPORT_SYMBOL_GPL(drm_check_edid_changed);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 1e1908a6b1d6..593a97b269c3 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -485,4 +485,7 @@ void drm_edid_get_monitor_name(struct edid *edid, char 
*name,
 struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
   int hsize, int vsize, int fresh,
   bool rb);
+bool drm_check_edid_changed(struct drm_connector *connector,
+   struct i2c_adapter *adapter);
+
 #endif /* __DRM_EDID_H__ */
-- 
2.13.2

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


Re: 10bit output via KMS

2017-07-24 Thread Alex Deucher
On Mon, Jul 24, 2017 at 8:34 AM, Volker Vogelhuber
 wrote:
> I have implemented a display manager application that takes DMB-BUF FDs
> from another process and presents them to a connected output display
> using the KMS infrastructure (drmModeAddFB, etc.). So far this works
> without problems for XRGB. Now I wanted to have 10bit color depth
> per channel. I created a FBO with 10bit (by patching the mesa and ex-
> ported it's texture as a file descriptor via eglExportDMABUFImageMESA,
> see attached patch).
> When I try to import that file descriptor via gbm_bo_import it fails
> because in gbm_bo_import, createImageFromFds is called which compares
> the format passed to gbm_bo_import with intel_image_formats. But this
> array does not seem to support 10bit formats. Now I wonder how one
> could output 10bit per color channel to an output connector?
>

Adding Nicolai.  I think he sent out similar patches for mesa and
glamor earlier this year to enable this as well.

Alex


>
> ---
>  include/EGL/eglext.h |  4 
>  src/egl/drivers/dri2/egl_dri2.c  | 26 +-
>  src/gbm/backends/dri/gbm_dri.c   |  3 +++
>  src/mesa/drivers/dri/i965/intel_screen.c |  2 ++
>  4 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h
> index bc8f0ba..c0d55e9 100644
> --- a/include/EGL/eglext.h
> +++ b/include/EGL/eglext.h
> @@ -862,10 +862,14 @@ EGLAPI EGLSurface EGLAPIENTRY eglCreatePixmapSurfaceHI
> (EGLDisplay dpy, EGLConfi
>  #define EGL_DRM_BUFFER_FORMAT_MESA0x31D0
>  #define EGL_DRM_BUFFER_USE_MESA   0x31D1
>  #define EGL_DRM_BUFFER_FORMAT_ARGB32_MESA 0x31D2
> +#define EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA 0x31D9
> +#define EGL_DRM_BUFFER_FORMAT_R8_MESA 0x31E0
> +#define EGL_DRM_BUFFER_FORMAT_GR88_MESA   0x31E1
>  #define EGL_DRM_BUFFER_MESA   0x31D3
>  #define EGL_DRM_BUFFER_STRIDE_MESA0x31D4
>  #define EGL_DRM_BUFFER_USE_SCANOUT_MESA   0x0001
>  #define EGL_DRM_BUFFER_USE_SHARE_MESA 0x0002
> +#define EGL_DRM_BUFFER_USE_LINEAR 0x0008
>  typedef EGLImageKHR (EGLAPIENTRYP PFNEGLCREATEDRMIMAGEMESAPROC) (EGLDisplay
> dpy, const EGLint *attrib_list);
>  typedef EGLBoolean (EGLAPIENTRYP PFNEGLEXPORTDRMIMAGEMESAPROC) (EGLDisplay
> dpy, EGLImageKHR image, EGLint *name, EGLint *handle, EGLint *stride);
>  #ifdef EGL_EGLEXT_PROTOTYPES
> diff --git a/src/egl/drivers/dri2/egl_dri2.c
> b/src/egl/drivers/dri2/egl_dri2.c
> index 2cab7d0..39394b0 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1921,6 +1921,18 @@ dri2_create_image_mesa_drm_buffer(_EGLDisplay *disp,
> _EGLContext *ctx,
>format = __DRI_IMAGE_FORMAT_ARGB;
>pitch = attrs.DRMBufferStrideMESA;
>break;
> +   case EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA:
> +  format = __DRI_IMAGE_FORMAT_ARGB2101010;
> +  pitch = attrs.DRMBufferStrideMESA;
> +  break;
> +   case EGL_DRM_BUFFER_FORMAT_R8_MESA:
> +  format = __DRI_IMAGE_FORMAT_R8;
> +  pitch = attrs.DRMBufferStrideMESA;
> +  break;
> +case EGL_DRM_BUFFER_FORMAT_GR88_MESA:
> +  format = __DRI_IMAGE_FORMAT_GR88;
> +  pitch = attrs.DRMBufferStrideMESA;
> +  break;
> default:
>_eglError(EGL_BAD_PARAMETER,
>  "dri2_create_image_khr: unsupported pixmap depth");
> @@ -2216,6 +2228,15 @@ dri2_create_drm_image_mesa(_EGLDriver *drv,
> _EGLDisplay *disp,
> case EGL_DRM_BUFFER_FORMAT_ARGB32_MESA:
>format = __DRI_IMAGE_FORMAT_ARGB;
>break;
> +   case EGL_DRM_BUFFER_FORMAT_RGB10A2_MESA:
> +  format = __DRI_IMAGE_FORMAT_ARGB2101010;
> +  break;
> +   case EGL_DRM_BUFFER_FORMAT_R8_MESA:
> +  format = __DRI_IMAGE_FORMAT_R8;
> +  break;
> +   case EGL_DRM_BUFFER_FORMAT_GR88_MESA:
> +  format = __DRI_IMAGE_FORMAT_GR88;
> +  break;
> default:
>_eglLog(_EGL_WARNING, "bad image format value 0x%04x",
>  attrs.DRMBufferFormatMESA);
> @@ -2225,7 +2246,8 @@ dri2_create_drm_image_mesa(_EGLDriver *drv,
> _EGLDisplay *disp,
> valid_mask =
>EGL_DRM_BUFFER_USE_SCANOUT_MESA |
>EGL_DRM_BUFFER_USE_SHARE_MESA |
> -  EGL_DRM_BUFFER_USE_CURSOR_MESA;
> +  EGL_DRM_BUFFER_USE_CURSOR_MESA |
> +  EGL_DRM_BUFFER_USE_LINEAR;
> if (attrs.DRMBufferUseMESA & ~valid_mask) {
>_eglLog(_EGL_WARNING, "bad image use bit 0x%04x",
>  attrs.DRMBufferUseMESA & ~valid_mask);
> @@ -2239,6 +2261,8 @@ dri2_create_drm_image_mesa(_EGLDriver *drv,
> _EGLDisplay *disp,
>dri_use |= __DRI_IMAGE_USE_SCANOUT;
> if (attrs.DRMBufferUseMESA & EGL_DRM_BUFFER_USE_CURSOR_MESA)
>dri_use |= __DRI_IMAGE_USE_CURSOR;
> +   if (attrs.DRMBufferUseMESA & EGL_DRM_BUFFER_USE_LINEAR)
> +  dri_use |= __DRI_IMAGE_USE_LINEAR;
>
> dri2_img->dri_image =
>dri2_dpy->image->createImage(dri2_dpy->dri_screen,
> diff --git 

Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Harry Wentland
On 2017-07-24 09:35 AM, Ricardo Ribalda Delgado wrote:
> amd_powerplay_display_configuration_change is never called.
> 
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 21 -
>  drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h |  3 ---
>  2 files changed, 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
> b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> index f73e80c4bf33..1ee7aa5546bf 100644
> --- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> +++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
> @@ -1237,27 +1237,6 @@ int amd_powerplay_reset(void *handle)
>   return pem_handle_event(eventmgr, AMD_PP_EVENT_COMPLETE_INIT, 
> _data);
>  }
>  
> -/* export this function to DAL */
> -
> -int amd_powerplay_display_configuration_change(void *handle,
> - const struct amd_pp_display_configuration *display_config)

This is used and needed by the DC display driver. See
display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:

https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11

Harry

> -{
> - struct pp_hwmgr  *hwmgr;
> - struct pp_instance *pp_handle = (struct pp_instance *)handle;
> - int ret = 0;
> -
> - ret = pp_check(pp_handle);
> -
> - if (ret != 0)
> - return ret;
> -
> - hwmgr = pp_handle->hwmgr;
> - mutex_lock(_handle->pp_lock);
> - phm_store_dal_configuration_data(hwmgr, display_config);
> - mutex_unlock(_handle->pp_lock);
> - return 0;
> -}
> -
>  int amd_powerplay_get_display_power_level(void *handle,
>   struct amd_pp_simple_clock_info *output)
>  {
> diff --git a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h 
> b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> index 07e9c0b5915d..ae49af5cc5d1 100644
> --- a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> +++ b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
> @@ -407,9 +407,6 @@ int amd_powerplay_destroy(void *handle);
>  
>  int amd_powerplay_reset(void *handle);
>  
> -int amd_powerplay_display_configuration_change(void *handle,
> - const struct amd_pp_display_configuration *input);
> -
>  int amd_powerplay_get_display_power_level(void *handle,
>   struct amd_pp_simple_clock_info *output);
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Ricardo Ribalda Delgado
Hi Harry
On Mon, Jul 24, 2017 at 4:01 PM, Harry Wentland  wrote:

>
> This is used and needed by the DC display driver. See
> display/amdgpu_dm/amdgpu_dm_services.c:193 in Alex's amd-staging-4.11 tree:
>
> https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_services.c?h=amd-staging-4.11
>

I could not find any reference to the function in linux-next (>4.12)

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/amd

Is there any plan to merge Alex's amd-stagin tree?

Sorry, I am not very familiar with this subsystem.

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


[PATCH 14/14] amdgpu: powerplay: Remove unused structure

2017-07-24 Thread Ricardo Ribalda Delgado
Remove unused structure definition amd_pp_display_configuration.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h | 40 ---
 1 file changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h 
b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
index ae49af5cc5d1..6b6f2f7c8527 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
@@ -191,46 +191,6 @@ struct single_display_configuration
 
 #define MAX_NUM_DISPLAY 32
 
-struct amd_pp_display_configuration {
-   bool nb_pstate_switch_disable;/* controls NB PState switch */
-   bool cpu_cc6_disable; /* controls CPU CState switch ( on or off) */
-   bool cpu_pstate_disable;
-   uint32_t cpu_pstate_separation_time;
-
-   uint32_t num_display;  /* total number of display*/
-   uint32_t num_path_including_non_display;
-   uint32_t crossfire_display_index;
-   uint32_t min_mem_set_clock;
-   uint32_t min_core_set_clock;
-   /* unit 10KHz x bit*/
-   uint32_t min_bus_bandwidth;
-   /* minimum required stutter sclk, in 10khz uint32_t ulMinCoreSetClk;*/
-   uint32_t min_core_set_clock_in_sr;
-
-   struct single_display_configuration displays[MAX_NUM_DISPLAY];
-
-   uint32_t vrefresh; /* for active display*/
-
-   uint32_t min_vblank_time; /* for active display*/
-   bool multi_monitor_in_sync;
-   /* Controller Index of primary display - used in MCLK SMC switching hang
-* SW Workaround*/
-   uint32_t crtc_index;
-   /* htotal*1000/pixelclk - used in MCLK SMC switching hang SW 
Workaround*/
-   uint32_t line_time_in_us;
-   bool invalid_vblank_time;
-
-   uint32_t display_clk;
-   /*
-* for given display configuration if multimonitormnsync == false then
-* Memory clock DPMS with this latency or below is allowed, DPMS with
-* higher latency not allowed.
-*/
-   uint32_t dce_tolerable_mclk_in_active_latency;
-   uint32_t min_dcef_set_clk;
-   uint32_t min_dcef_deep_sleep_set_clk;
-};
-
 struct amd_pp_simple_clock_info {
uint32_tengine_max_clock;
uint32_tmemory_max_clock;
-- 
2.13.2

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


[PATCH 13/14] amdgpu: amdgpu_dpm: Remove unused field

2017-07-24 Thread Ricardo Ribalda Delgado
Remove unused field pm_display_cfg

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
index 8c96a4caa715..5c740814dba4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h
@@ -488,7 +488,6 @@ struct amdgpu_pm {
const struct amdgpu_dpm_funcs *funcs;
uint32_tpcie_gen_mask;
uint32_tpcie_mlw_mask;
-   struct amd_pp_display_configuration pm_display_cfg;/* set by DAL */
 };
 
 #define R600_SSTU_DFLT   0
-- 
2.13.2

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


[PATCH 12/14] amdgpu: powerplay: hwmgr: Remove unused field

2017-07-24 Thread Ricardo Ribalda Delgado
Remove unused field display_config

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
index 47e57bd2c36f..220bb8cde530 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
@@ -779,7 +779,6 @@ struct pp_hwmgr {
struct pp_power_state*request_ps;
struct pp_power_state*boot_ps;
struct pp_power_state*uvd_ps;
-   struct amd_pp_display_configuration display_config;
uint32_t feature_mask;
 
/* power profile */
-- 
2.13.2

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


[PATCH 11/14] amdgpu: ci_dpm: Assume pm_display_cfg is zero

2017-07-24 Thread Ricardo Ribalda Delgado
pm_display_cfg is never set, so we can assume that it is zero

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c 
b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
index cb508a211b2f..8319bca3dc52 100644
--- a/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/ci_dpm.c
@@ -972,12 +972,6 @@ static void ci_apply_state_adjust_rules(struct 
amdgpu_device *adev,
sclk = ps->performance_levels[0].sclk;
}
 
-   if (adev->pm.pm_display_cfg.min_core_set_clock > sclk)
-   sclk = adev->pm.pm_display_cfg.min_core_set_clock;
-
-   if (adev->pm.pm_display_cfg.min_mem_set_clock > mclk)
-   mclk = adev->pm.pm_display_cfg.min_mem_set_clock;
-
if (rps->vce_active) {
if (sclk < adev->pm.dpm.vce_states[adev->pm.dpm.vce_level].sclk)
sclk = 
adev->pm.dpm.vce_states[adev->pm.dpm.vce_level].sclk;
-- 
2.13.2

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


[PATCH 10/14] amdgpu: powerplay: vega10_hwmgr: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, so we can assume that it is zero

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index d6f097f44b6c..dd73ab7e5cfe 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3044,8 +3044,6 @@ static int vega10_apply_state_adjust_rules(struct 
pp_hwmgr *hwmgr,
cgs_get_active_displays_info(hwmgr->device, );
 
/* result = PHM_CheckVBlankTime(hwmgr, );*/
-   minimum_clocks.engineClock = hwmgr->display_config.min_core_set_clock;
-   minimum_clocks.memoryClock = hwmgr->display_config.min_mem_set_clock;
 
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_StablePState)) {
@@ -4000,10 +3998,6 @@ static int 
vega10_notify_smc_display_config_after_ps_adjustment(
else
vega10_notify_smc_display_change(hwmgr, true);
 
-   min_clocks.dcefClock = hwmgr->display_config.min_dcef_set_clk;
-   min_clocks.dcefClockInSR = 
hwmgr->display_config.min_dcef_deep_sleep_set_clk;
-   min_clocks.memoryClock = hwmgr->display_config.min_mem_set_clock;
-
for (i = 0; i < dpm_table->count; i++) {
if (dpm_table->dpm_levels[i].value == min_clocks.dcefClock)
break;
@@ -4634,20 +4628,19 @@ static bool
 vega10_check_smc_update_required_for_display_configuration(struct pp_hwmgr 
*hwmgr)
 {
struct vega10_hwmgr *data = (struct vega10_hwmgr *)(hwmgr->backend);
-   bool is_update_required = false;
struct cgs_display_info info = {0, 0, NULL};
 
cgs_get_active_displays_info(hwmgr->device, );
 
if (data->display_timing.num_existing_displays != info.display_count)
-   is_update_required = true;
+   return true;
 
-   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_SclkDeepSleep)) {
-   if (data->display_timing.min_clock_in_sr != 
hwmgr->display_config.min_core_set_clock_in_sr)
-   is_update_required = true;
-   }
+   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_SclkDeepSleep) &&
+   data->display_timing.min_clock_in_sr)
+   return true;
 
-   return is_update_required;
+   return false;
 }
 
 static int vega10_disable_dpm_tasks(struct pp_hwmgr *hwmgr)
-- 
2.13.2

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


[PATCH 08/14] amdgpu: powerplay: tonga_smc: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, we can assume it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
index 65d3a4893958..341c31c63e5e 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c
@@ -562,8 +562,7 @@ static int tonga_populate_single_graphic_level(struct 
pp_hwmgr *hwmgr,
graphic_level->VoltageDownHyst = 0;
graphic_level->PowerThrottle = 0;
 
-   data->display_timing.min_clock_in_sr =
-   hwmgr->display_config.min_core_set_clock_in_sr;
+   data->display_timing.min_clock_in_sr = 0;
 
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_SclkDeepSleep))
-- 
2.13.2

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


[PATCH 09/14] amdgpu: powerplay: rv_hwmgr: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, so we can assume that it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
index 4c7f430b36eb..64a3cb66a3a0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
@@ -241,8 +241,6 @@ static int rv_tf_set_clock_limit(struct pp_hwmgr *hwmgr, 
void *input,
struct PP_Clocks clocks = {0};
struct pp_display_clock_request clock_req;
 
-   clocks.dcefClock = hwmgr->display_config.min_dcef_set_clk;
-   clocks.dcefClockInSR = 
hwmgr->display_config.min_dcef_deep_sleep_set_clk;
clock_req.clock_type = amd_pp_dcf_clock;
clock_req.clock_freq_in_khz = clocks.dcefClock * 10;
 
-- 
2.13.2

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


[PATCH 05/14] amdgpu: powerplay: fiji_smc: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, so we can assume it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
index 6a320b27aefd..befd5c304636 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -742,11 +742,12 @@ static int fiji_populate_single_graphic_level(struct 
pp_hwmgr *hwmgr,
 
threshold = clock * data->fast_watermark_threshold / 100;
 
-   data->display_timing.min_clock_in_sr = 
hwmgr->display_config.min_core_set_clock_in_sr;
+   data->display_timing.min_clock_in_sr = 0;
 
-   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_SclkDeepSleep))
-   level->DeepSleepDivId = 
smu7_get_sleep_divider_id_from_clock(clock,
-   
hwmgr->display_config.min_core_set_clock_in_sr);
+   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_SclkDeepSleep))
+   level->DeepSleepDivId =
+   smu7_get_sleep_divider_id_from_clock(clock, 0);
 
 
/* Default to slow, highest DPM level will be
-- 
2.13.2

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


[PATCH 06/14] amdgpu: powerplay: iceland_smc: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, we can assume it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
index 51adf04ab4b3..dce87fc13e0c 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -780,8 +780,7 @@ static int iceland_populate_single_graphic_level(struct 
pp_hwmgr *hwmgr,
graphic_level->VoltageDownHyst = 0;
graphic_level->PowerThrottle = 0;
 
-   data->display_timing.min_clock_in_sr =
-   hwmgr->display_config.min_core_set_clock_in_sr;
+   data->display_timing.min_clock_in_sr = 0;
 
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_SclkDeepSleep))
-- 
2.13.2

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


[PATCH 07/14] amdgpu: powerplay: polaris10_smc: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, we can assume it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
index f68e759e8be2..c889fc930cfc 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c
@@ -711,11 +711,12 @@ static int polaris10_populate_single_graphic_level(struct 
pp_hwmgr *hwmgr,
level->DownHyst = 0;
level->VoltageDownHyst = 0;
level->PowerThrottle = 0;
-   data->display_timing.min_clock_in_sr = 
hwmgr->display_config.min_core_set_clock_in_sr;
+   data->display_timing.min_clock_in_sr = 0;
 
-   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_SclkDeepSleep))
-   level->DeepSleepDivId = 
smu7_get_sleep_divider_id_from_clock(clock,
-   
hwmgr->display_config.min_core_set_clock_in_sr);
+   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_SclkDeepSleep))
+   level->DeepSleepDivId =
+   smu7_get_sleep_divider_id_from_clock(clock, 0);
 
/* Default to slow, highest DPM level will be
 * set to PPSMC_DISPLAY_WATERMARK_LOW later.
-- 
2.13.2

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


[PATCH 03/14] amdgpu: powerplay: cz_hwmgr: Fix invalid error message.

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, therefore we can assume it is zero.

Without this fix, the user will get the following invalid warning on its
dmesg:

amdgpu: [powerplay] min_core_set_clock not set.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
index 0b74da3dca8b..418f6bf33bb5 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c
@@ -720,12 +720,8 @@ static int cz_tf_update_sclk_limit(struct pp_hwmgr *hwmgr,
else
cz_hwmgr->sclk_dpm.soft_max_clk  = table->entries[table->count 
- 1].clk;
 
-   clock = hwmgr->display_config.min_core_set_clock;
-   if (clock == 0)
-   pr_info("min_core_set_clock not set\n");
-
-   if (cz_hwmgr->sclk_dpm.hard_min_clk != clock) {
-   cz_hwmgr->sclk_dpm.hard_min_clk = clock;
+   if (cz_hwmgr->sclk_dpm.hard_min_clk) {
+   cz_hwmgr->sclk_dpm.hard_min_clk = 0;
 
smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
PPSMC_MSG_SetSclkHardMin,
@@ -780,15 +776,13 @@ static int cz_tf_set_deep_sleep_sclk_threshold(struct 
pp_hwmgr *hwmgr,
 {
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_SclkDeepSleep)) {
-   uint32_t clks = hwmgr->display_config.min_core_set_clock_in_sr;
-   if (clks == 0)
-   clks = CZ_MIN_DEEP_SLEEP_SCLK;
 
-   PP_DBG_LOG("Setting Deep Sleep Clock: %d\n", clks);
+   PP_DBG_LOG("Setting Deep Sleep Clock: %d\n",
+  CZ_MIN_DEEP_SLEEP_SCLK);
 
smum_send_msg_to_smc_with_parameter(hwmgr->smumgr,
PPSMC_MSG_SetMinDeepSleepSclk,
-   clks);
+   CZ_MIN_DEEP_SLEEP_SCLK);
}
 
return 0;
@@ -1120,9 +1114,7 @@ static int cz_apply_state_adjust_rules(struct pp_hwmgr 
*hwmgr,
 
cz_hwmgr->battery_state = (PP_StateUILabel_Battery == 
prequest_ps->classification.ui_label);
 
-   clocks.memoryClock = hwmgr->display_config.min_mem_set_clock != 0 ?
-   hwmgr->display_config.min_mem_set_clock :
-   cz_hwmgr->sys_info.nbp_memory_clock[1];
+   clocks.memoryClock = cz_hwmgr->sys_info.nbp_memory_clock[1];
 
cgs_get_active_displays_info(hwmgr->device, );
num_of_active_displays = info.display_count;
-- 
2.13.2

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


[PATCH 01/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Ricardo Ribalda Delgado
amd_powerplay_display_configuration_change is never called.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 21 -
 drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h |  3 ---
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c 
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index f73e80c4bf33..1ee7aa5546bf 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -1237,27 +1237,6 @@ int amd_powerplay_reset(void *handle)
return pem_handle_event(eventmgr, AMD_PP_EVENT_COMPLETE_INIT, 
_data);
 }
 
-/* export this function to DAL */
-
-int amd_powerplay_display_configuration_change(void *handle,
-   const struct amd_pp_display_configuration *display_config)
-{
-   struct pp_hwmgr  *hwmgr;
-   struct pp_instance *pp_handle = (struct pp_instance *)handle;
-   int ret = 0;
-
-   ret = pp_check(pp_handle);
-
-   if (ret != 0)
-   return ret;
-
-   hwmgr = pp_handle->hwmgr;
-   mutex_lock(_handle->pp_lock);
-   phm_store_dal_configuration_data(hwmgr, display_config);
-   mutex_unlock(_handle->pp_lock);
-   return 0;
-}
-
 int amd_powerplay_get_display_power_level(void *handle,
struct amd_pp_simple_clock_info *output)
 {
diff --git a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h 
b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
index 07e9c0b5915d..ae49af5cc5d1 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h
@@ -407,9 +407,6 @@ int amd_powerplay_destroy(void *handle);
 
 int amd_powerplay_reset(void *handle);
 
-int amd_powerplay_display_configuration_change(void *handle,
-   const struct amd_pp_display_configuration *input);
-
 int amd_powerplay_get_display_power_level(void *handle,
struct amd_pp_simple_clock_info *output);
 
-- 
2.13.2

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


[PATCH 02/14] amdgpu: powerplay: Remove unused function

2017-07-24 Thread Ricardo Ribalda Delgado
phm_store_dal_configuration_data is not used anymore.

Remove also reference on comments to the function

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../gpu/drm/amd/powerplay/eventmgr/eventtasks.c|  1 -
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  | 25 --
 .../gpu/drm/amd/powerplay/inc/hardwaremanager.h|  3 ---
 3 files changed, 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c 
b/drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c
index 8c4ebaae1e0c..eeb155036c40 100644
--- a/drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c
+++ b/drivers/gpu/drm/amd/powerplay/eventmgr/eventtasks.c
@@ -193,7 +193,6 @@ int pem_task_store_dal_configuration(struct pp_eventmgr 
*eventmgr, const struct
 {
/* TODO */
return 0;
-   /*phm_store_dal_configuration_data(eventmgr->hwmgr, display_config) */
 }
 
 int pem_task_notify_hw_mgr_display_configuration_change(struct pp_eventmgr 
*eventmgr, struct pem_event_data *event_data)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
index fcc722ea7649..c747fbd34073 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
@@ -320,31 +320,6 @@ int phm_check_states_equal(struct pp_hwmgr *hwmgr,
return hwmgr->hwmgr_func->check_states_equal(hwmgr, pstate1, pstate2, 
equal);
 }
 
-int phm_store_dal_configuration_data(struct pp_hwmgr *hwmgr,
-   const struct amd_pp_display_configuration *display_config)
-{
-   PHM_FUNC_CHECK(hwmgr);
-
-   if (display_config == NULL)
-   return -EINVAL;
-
-   hwmgr->display_config = *display_config;
-
-   if (hwmgr->hwmgr_func->store_cc6_data == NULL)
-   return -EINVAL;
-
-   /* TODO: pass other display configuration in the future */
-
-   if (hwmgr->hwmgr_func->store_cc6_data)
-   hwmgr->hwmgr_func->store_cc6_data(hwmgr,
-   display_config->cpu_pstate_separation_time,
-   display_config->cpu_cc6_disable,
-   display_config->cpu_pstate_disable,
-   display_config->nb_pstate_switch_disable);
-
-   return 0;
-}
-
 int phm_get_dal_power_level(struct pp_hwmgr *hwmgr,
struct amd_pp_simple_clock_info *info)
 {
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h 
b/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
index a1ebe1014492..ebddcdce323c 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/hardwaremanager.h
@@ -397,9 +397,6 @@ extern int phm_check_states_equal(struct pp_hwmgr *hwmgr,
 const struct pp_hw_power_state *pstate2,
 bool *equal);
 
-extern int phm_store_dal_configuration_data(struct pp_hwmgr *hwmgr,
-   const struct amd_pp_display_configuration *display_config);
-
 extern int phm_get_dal_power_level(struct pp_hwmgr *hwmgr,
struct amd_pp_simple_clock_info *info);
 
-- 
2.13.2

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


[PATCH 04/14] amdgpu: powerplay: smu7_hwmgr: Assume display_config is zero

2017-07-24 Thread Ricardo Ribalda Delgado
display_config is never set, so we can assume it is zero.

Signed-off-by: Ricardo Ribalda Delgado 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 1f01020ce3a9..893e6e846284 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -2727,9 +2727,6 @@ static int smu7_apply_state_adjust_rules(struct pp_hwmgr 
*hwmgr,
 
cgs_get_active_displays_info(hwmgr->device, );
 
-   minimum_clocks.engineClock = hwmgr->display_config.min_core_set_clock;
-   minimum_clocks.memoryClock = hwmgr->display_config.min_mem_set_clock;
-
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_StablePState)) {
max_limits = &(hwmgr->dyn_state.max_clock_voltage_on_ac);
@@ -3928,7 +3925,7 @@ smu7_notify_smc_display_config_after_ps_adjustment(struct 
pp_hwmgr *hwmgr)
 
num_active_displays = info.display_count;
 
-   if (num_active_displays > 1 && 
hwmgr->display_config.multi_monitor_in_sync != true)
+   if (num_active_displays > 1)
smu7_notify_smc_display_change(hwmgr, false);
 
return 0;
@@ -4032,12 +4029,12 @@ 
smu7_check_smc_update_required_for_display_configuration(struct pp_hwmgr *hwmgr)
if (data->display_timing.num_existing_displays != info.display_count)
is_update_required = true;
 
-   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps, 
PHM_PlatformCaps_SclkDeepSleep)) {
-   if (data->display_timing.min_clock_in_sr != 
hwmgr->display_config.min_core_set_clock_in_sr &&
-   (data->display_timing.min_clock_in_sr >= 
SMU7_MINIMUM_ENGINE_CLOCK ||
-   hwmgr->display_config.min_core_set_clock_in_sr >= 
SMU7_MINIMUM_ENGINE_CLOCK))
-   is_update_required = true;
-   }
+   if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
+   PHM_PlatformCaps_SclkDeepSleep) &&
+   data->display_timing.min_clock_in_sr &&
+   data->display_timing.min_clock_in_sr >= SMU7_MINIMUM_ENGINE_CLOCK)
+   is_update_required = true;
+
return is_update_required;
 }
 
-- 
2.13.2

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


[PATCH 00/14] Remove unused structure amd_pp_display_configuration

2017-07-24 Thread Ricardo Ribalda Delgado
While trying to fix the error message

amdgpu: [powerplay] min_core_set_clock not set

on my carizzo board. I Realized that the structure display_config was never
set and therefore a lot of code could be simplified.

Also due to display_config never set, the error message was invalid.

Other people referencing it:

http://www.mikejonesey.co.uk/linux/optimisation/amd-carrizo-powerplay-this-function-not-implement

Ricardo Ribalda Delgado (14):
  amdgpu: powerplay: Remove unused function
  amdgpu: powerplay: Remove unused function
  amdgpu: powerplay: cz_hwmgr: Fix invalid error message.
  amdgpu: powerplay: smu7_hwmgr: Assume display_config is zero
  amdgpu: powerplay: fiji_smc: Assume display_config is zero
  amdgpu: powerplay: iceland_smc: Assume display_config is zero
  amdgpu: powerplay: polaris10_smc: Assume display_config is zero
  amdgpu: powerplay: tonga_smc: Assume display_config is zero
  amdgpu: powerplay: rv_hwmgr: Assume display_config is zero
  amdgpu: powerplay: vega10_hwmgr: Assume display_config is zero
  amdgpu: ci_dpm: Assume pm_display_cfg is zero
  amdgpu: powerplay: hwmgr: Remove unused field
  amdgpu: amdgpu_dpm: Remove unused field
  amdgpu: powerplay: Remove unused structure

 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h|  1 -
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  6 ---
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c  | 21 ---
 .../gpu/drm/amd/powerplay/eventmgr/eventtasks.c|  1 -
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 20 +++---
 .../gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c  | 25 -
 drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c |  2 -
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   | 10 ++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 18 +++--
 drivers/gpu/drm/amd/powerplay/inc/amd_powerplay.h  | 43 --
 .../gpu/drm/amd/powerplay/inc/hardwaremanager.h|  3 --
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h  |  1 -
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  5 +--
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c |  3 +-
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  5 +--
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  3 +-
 16 files changed, 20 insertions(+), 147 deletions(-)

-- 
2.13.2

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


Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

2017-07-24 Thread Ramalingam C



On Monday 24 July 2017 06:53 PM, Sean Paul wrote:

On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C  wrote:

Sorry for late response.


On Friday 14 July 2017 07:25 PM, Sean Paul wrote:

On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:

DRM connector property is created to represent the content protection
state of the connector and to configure the same.

CP States defined:
DRM_CP_UNSUPPORTED - CP is not supported
DRM_CP_DISABLE - CP is disabled
DRM_CP_ENABLE - CP is enabled

Why are we changing the names from the original version (that's used in
CrOS)? It's not
obvious what "CP" stands for when looking at the name.

Sean,

Considering that we want to test this interface for CrOS stack as a
consumer, I will try to align the property names.
Meanwhile got few questions with respect to designing this CP interface
aligned with existing CrOS stack.

I want to understand what all are the bare minimal content protection
interface required for existing CrOS Userspace stack.
Whether this drm enum property will be sufficient for CrOS Content
protection needs of HDCP1.4.?

Yep, just the property. Userspace sets it to desired and polls it
until it's enabled. Here are the code pointers, I sent this to Marc
Herbert, so perhaps it's already gotten to you.

Threads to set/query hdcp state:
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
Code which actually tweaks the drm props:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc



Could you please help me on that direction?

When i refer your RFC at
https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
there is a drm range property called  "Content Protection KSV", claimed to
stand for content protection state.
Is this used by current CrOS userspace stack?


No, it's not.


As per the design I am proposing, SRM is passed to KMD and revocation check
is done in kernel space.

I'm not completely against this, however I'm more partial to having
userspace handle SRM/revocation since it's not really a hardware
feature.


How is this done in CrOS? CrOS uses the above mentioned ksv property for
that purpose, to pass the ksv to UMD for revocation check?

We don't have SRM or revocation lists, but that was the idea should we
have needed it.

Sean

Thank you sean. This clears my doubts. I will share the reworked patch soon.

--Ram





V2: Redesigned the property to match with CP needs of CrOS.

Signed-off-by: Ramalingam C 
---
  drivers/gpu/drm/drm_connector.c | 14 +
  include/drm/drm_hdcp.h  | 44
+
  include/drm/drm_mode_config.h   |  5 +
  3 files changed, 63 insertions(+)
  create mode 100644 include/drm/drm_hdcp.h

diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c
index 5cd61af..64895fb 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "drm_crtc_internal.h"
  #include "drm_internal.h"
@@ -617,6 +618,13 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
  };
  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)

+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_CP_UNSUPPORTED, "CP Not Supported" },
+ { DRM_CP_DISABLE, "Disable CP" },
+ { DRM_CP_ENABLE, "Enable CP for Type0 content" },

Type0 has no meaning in this case. The whole point of using "Content
Protection"
is to abstract the means of protection from userspace. The names are also
much
more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
fine.

Looks like i was still trying to reflect that "Type1 is coming" ;). I will
rename these in next revision. Thanks


+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
  /**
   * drm_display_info_set_bus_formats - set the supported bus formats
   * @info: display info to store bus formats in
@@ -789,6 +797,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
   return -ENOMEM;
   dev->mode_config.link_status_property = prop;

+ prop = drm_property_create_enum(dev, 0, "cp", drm_cp_enum_list,
+   ARRAY_SIZE(drm_cp_enum_list));

Your property name here, on the other hand, is not descriptive enough.
Please
expand to something meaningful.

Will change it to "content protection"

+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cp_property = prop;
+
   return 0;
  }

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h

Why create a new header for this? That seems a little excessive.

But I am planning to use this header for all hdcp protocol specific
definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
etc.
With that I felt it justifies a header on it own.
And this will grow further when 

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

2017-07-24 Thread Sean Paul
On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C  wrote:
> Sorry for late response.
>
>
> On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
>
> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - CP is disabled
> DRM_CP_ENABLE - CP is enabled
>
> Why are we changing the names from the original version (that's used in
> CrOS)? It's not
> obvious what "CP" stands for when looking at the name.
>
> Sean,
>
> Considering that we want to test this interface for CrOS stack as a
> consumer, I will try to align the property names.
> Meanwhile got few questions with respect to designing this CP interface
> aligned with existing CrOS stack.
>
> I want to understand what all are the bare minimal content protection
> interface required for existing CrOS Userspace stack.
> Whether this drm enum property will be sufficient for CrOS Content
> protection needs of HDCP1.4.?

Yep, just the property. Userspace sets it to desired and polls it
until it's enabled. Here are the code pointers, I sent this to Marc
Herbert, so perhaps it's already gotten to you.

Threads to set/query hdcp state:
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/apply_content_protection_task.cc
https://cs.chromium.org/chromium/src/ui/display/manager/chromeos/query_content_protection_task.cc
Code which actually tweaks the drm props:
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_display.cc


> Could you please help me on that direction?
>
> When i refer your RFC at
> https://lists.freedesktop.org/archives/dri-devel/2014-December/073418.html
> there is a drm range property called  "Content Protection KSV", claimed to
> stand for content protection state.
> Is this used by current CrOS userspace stack?
>

No, it's not.

> As per the design I am proposing, SRM is passed to KMD and revocation check
> is done in kernel space.

I'm not completely against this, however I'm more partial to having
userspace handle SRM/revocation since it's not really a hardware
feature.

> How is this done in CrOS? CrOS uses the above mentioned ksv property for
> that purpose, to pass the ksv to UMD for revocation check?

We don't have SRM or revocation lists, but that was the idea should we
have needed it.

Sean

>
>
>
> V2: Redesigned the property to match with CP needs of CrOS.
>
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/drm_connector.c | 14 +
>  include/drm/drm_hdcp.h  | 44
> +
>  include/drm/drm_mode_config.h   |  5 +
>  3 files changed, 63 insertions(+)
>  create mode 100644 include/drm/drm_hdcp.h
>
> diff --git a/drivers/gpu/drm/drm_connector.c
> b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..64895fb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -617,6 +618,13 @@ static const struct drm_prop_enum_list
> drm_link_status_enum_list[] = {
>  };
>  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>
> +static const struct drm_prop_enum_list drm_cp_enum_list[] = {
> + { DRM_CP_UNSUPPORTED, "CP Not Supported" },
> + { DRM_CP_DISABLE, "Disable CP" },
> + { DRM_CP_ENABLE, "Enable CP for Type0 content" },
>
> Type0 has no meaning in this case. The whole point of using "Content
> Protection"
> is to abstract the means of protection from userspace. The names are also
> much
> more verbose than they need be. "Unsupported", "Disabled", "Enabled" are
> fine.
>
> Looks like i was still trying to reflect that "Type1 is coming" ;). I will
> rename these in next revision. Thanks
>
>
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
>  /**
>   * drm_display_info_set_bus_formats - set the supported bus formats
>   * @info: display info to store bus formats in
> @@ -789,6 +797,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_enum(dev, 0, "cp", drm_cp_enum_list,
> +   ARRAY_SIZE(drm_cp_enum_list));
>
> Your property name here, on the other hand, is not descriptive enough.
> Please
> expand to something meaningful.
>
> Will change it to "content protection"
>
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cp_property = prop;
> +
>   return 0;
>  }
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
>
> Why create a new header for this? That seems a little excessive.
>
> But I am planning to use this header for all hdcp protocol specific
> definitions like HDCP2.2 messages and Panel's HDCP2.2 register definitions
> etc.
> With that I felt it 

  1   2   >