[PATCH v12 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

2016-03-16 Thread kbuild test robot
Hi Jitao,

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

url:
https://github.com/0day-ci/linux/commits/Jitao-Shi/Documentation-bridge-Add-documentation-for-ps8640-DT-properties/20160316-213031
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/gpu/drm/bridge/parade-ps8640.c:114:30: sparse: invalid initializer
   drivers/gpu/drm/bridge/parade-ps8640.c:430:24: sparse: undefined identifier 
'of_find_mipi_dsi_host_by_node'
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
  ^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_bridge_attach':
   drivers/gpu/drm/bridge/parade-ps8640.c:430:10: error: implicit declaration 
of function 'of_find_mipi_dsi_host_by_node' 
[-Werror=implicit-function-declaration]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
 ^
   drivers/gpu/drm/bridge/parade-ps8640.c:430:8: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
   ^
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_check_chip_id':
>> drivers/gpu/drm/bridge/parade-ps8640.c:717:21: warning: passing argument 2 
>> of 'memcmp' makes pointer from integer without a cast [-Wint-conversion]
 return memcmp(buf, hw_chip_id, sizeof(buf));
^
   In file included from include/linux/bitmap.h:8:0,
from include/linux/cpumask.h:11,
from arch/x86/include/asm/cpumask.h:4,
from arch/x86/include/asm/msr.h:10,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:54,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/firmware.h:6,
from drivers/gpu/drm/bridge/parade-ps8640.c:16:
   include/linux/string.h:112:12: note: expected 'const void *' but argument is 
of type 'u8 {aka const unsigned char}'
extern int memcmp(const void *,const void *,__kernel_size_t);
   ^
   cc1: some warnings being treated as errors

sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:228:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/gpu/drm/bridge/parade-ps8640.c:114:30: sparse: invalid initializer
   drivers/gpu/drm/bridge/parade-ps8640.c:430:24: sparse: undefined identifier 
'of_find_mipi_dsi_host_by_node'
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
  ^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.

[PATCH v12 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

2016-03-16 Thread kbuild test robot
Hi Jitao,

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

url:
https://github.com/0day-ci/linux/commits/Jitao-Shi/Documentation-bridge-Add-documentation-for-ps8640-DT-properties/20160316-213031
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/bridge/parade-ps8640.c:114:37: warning: excess elements in 
>> scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:37: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
  ^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:43: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: warning: excess elements in 
scalar initializer
static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
^
   drivers/gpu/drm/bridge/parade-ps8640.c:114:49: note: (near initialization 
for 'hw_chip_id')
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_bridge_attach':
   drivers/gpu/drm/bridge/parade-ps8640.c:430:10: error: implicit declaration 
of function 'of_find_mipi_dsi_host_by_node' 
[-Werror=implicit-function-declaration]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
 ^
   drivers/gpu/drm/bridge/parade-ps8640.c:430:8: warning: assignment makes 
pointer from integer without a cast [-Wint-conversion]
  host = of_find_mipi_dsi_host_by_node(dsi_node);
   ^
   drivers/gpu/drm/bridge/parade-ps8640.c: In function 'ps8640_check_chip_id':
>> drivers/gpu/drm/bridge/parade-ps8640.c:717:21: warning: passing argument 2 
>> of '__builtin_memcmp' makes pointer from integer without a cast 
>> [-Wint-conversion]
 return memcmp(buf, hw_chip_id, sizeof(buf));
^
   In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/thread_info.h:11,
from include/linux/thread_info.h:54,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/firmware.h:6,
from drivers/gpu/drm/bridge/parade-ps8640.c:16:
   arch/x86/include/asm/string_32.h:202:16: note: expected 'const void *' but 
argument is of type 'u8 {aka const unsigned char}'
#define memcmp __builtin_memcmp
   ^
>> include/linux/string.h:112:12: note: in expansion of macro 'memcmp'
extern int memcmp(const void *,const void *,__kernel_size_t);
   ^
   cc1: some warnings being treated as errors

vim +114 drivers/gpu/drm/bridge/parade-ps8640.c

98  struct mipi_dsi_device dsi;
99  struct i2c_client *page[8];
   100  struct i2c_client *ddc_i2c;
   101  struct regulator_bulk_data supplies[2];
   102  struct drm_panel *panel;
   103  struct gpio_desc *gpio_rst_n;
   104  struct gpio_desc *gpio_slp_n;
   105  struct gpio_desc *gpio_mode_sel_n;
   106  bool enabled;
   107  
   108  /* firmware file info */
   109  bool in_fw_update;
   110  struct ps8640_info info;
   111  };
   112  
   113  static const u8 enc_ctrl_code[6] = {0xaa, 0x55, 0x50, 0x41, 0x52, 0x44};
 > 114  static const u8 hw_chip_id = {0x00, 0x0a, 0x00, 0x30};
   115  
   116  static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
   117 u16 data_len)
   118  {
   119  int ret;
   120  struct i2c_msg msgs[] = {
   121  {
   122   .addr = client->addr,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 53508 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160316/68b62f5a/attachment-0001.obj>


[PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-03-16 Thread Ville Syrjälä
On Wed, Mar 16, 2016 at 03:44:37PM -0400, Lyude Paul wrote:
> On Wed, 2016-03-16 at 21:39 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> > > 
> > > After unplugging a DP MST display from the system, we have to go through
> > > and destroy all of the DRM connectors associated with it since none of
> > > them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> > > doesn't do a good enough job of ensuring that throughout the destruction
> > > process that no modesettings can be done with the connectors. As it is
> > > right now, intel_dp_destroy_mst_connector() works like this:
> > > 
> > > * Take all modeset locks
> > > * Clear the configuration of the crtc on the connector, if there is one
> > > * Drop all modeset locks, this is required because of circular
> > >   dependency issues that arise with trying to remove the connector from
> > >   sysfs with modeset locks held
> > > * Unregister the connector
> > > * Take all modeset locks, again
> > > * Do the rest of the required cleaning for destroying the connector
> > > * Finally drop all modeset locks for good
> > So pretty much what I suspected
> > https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html
> > 
> > > 
> > > 
> > > This only works sometimes. During the destruction process, it's very
> > > possible that a userspace application will attempt to do a modesetting
> > > using the connector. When we drop the modeset locks, an ioctl handler
> > > such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> > > locks from us. When this happens, one thing leads to another and
> > > eventually we end up committing a mode with the non-existent connector:
> > > 
> > >   [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to
> > > enable link training
> > >   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > >   [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel
> > > equalization
> > >   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > >   [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> > > 
> > > And in some cases, such as with the T460s using an MST dock, this
> > > results in breaking modesetting and/or panicking the system.
> > Are these just kernel oopses etc.? If the hardware gets upset from
> > modesetting when the sink is gone, well, then we still have a problem
> > because the user can of course yank the cable while the modeset is already
> > underway.
> It is more then that. Unfortunately though, fixing that part is not as easy. 
> We
> never expect an atomic modesetting commit to fail, but unfortunately any code
> having to do with turning on DP MST has the chance of failing and we turn on 
> DP
> MST during commits. So fixing that would take moving quite a bit of code 
> around.

SST has the same problems really. The sink may be gone so link training
etc. just won't succeed. But we should still finish the modeset without
killing the system or something.

> 
> > 
> > > 
> > > 
> > > To work around this, we now unregister the connector at the very
> > > beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> > > locks, and then hold them until we finish the rest of the function.
> > > 
> > > CC: stable at vger.kernel.org
> > > Signed-off-by: Lyude 
> > > Signed-off-by: Rob Clark 
> > These sobs don't make much sense to me.
> I should have mentioned that Rob Clark was the one who came up with the idea 
> of
> just moving the connector->unregister() call to the top of the function.
> 
> > 
> > Patch itself does make sense to me, so 
> > Reviewed-by: Ville Syrjälä 
> > 
> > > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
> > >  1 file changed, 2 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index fa0dabf..b21ac88 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >  struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > >  struct drm_device *dev = connector->dev;
> > >  
> > > + intel_connector->unregister(intel_connector);
> > > +
> > >  /* need to nuke the connector */
> > >  drm_modeset_lock_all(dev);
> > >  if (connector->state->crtc) {
> > > @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >  
> > >  WARN(ret, "Disabling mst crtc failed with %i\n", ret);
> > >  }
> > > - drm_modeset_unlock_all(dev);
> > >  
> > > - intel_connector->unregister(intel_connector);
> > > -
> > > - drm_modeset_lock_all(dev);
> > >  intel_connector_remove_from_fbdev(intel_connector);
> > >  drm_connector_cleanup(con

[PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-03-16 Thread Ville Syrjälä
On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> After unplugging a DP MST display from the system, we have to go through
> and destroy all of the DRM connectors associated with it since none of
> them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> doesn't do a good enough job of ensuring that throughout the destruction
> process that no modesettings can be done with the connectors. As it is
> right now, intel_dp_destroy_mst_connector() works like this:
> 
> * Take all modeset locks
> * Clear the configuration of the crtc on the connector, if there is one
> * Drop all modeset locks, this is required because of circular
>   dependency issues that arise with trying to remove the connector from
>   sysfs with modeset locks held
> * Unregister the connector
> * Take all modeset locks, again
> * Do the rest of the required cleaning for destroying the connector
> * Finally drop all modeset locks for good

So pretty much what I suspected
https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html

> 
> This only works sometimes. During the destruction process, it's very
> possible that a userspace application will attempt to do a modesetting
> using the connector. When we drop the modeset locks, an ioctl handler
> such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> locks from us. When this happens, one thing leads to another and
> eventually we end up committing a mode with the non-existent connector:
> 
>   [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
> enable link training
>   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>   [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
> equalization
>   [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
>   [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> 
> And in some cases, such as with the T460s using an MST dock, this
> results in breaking modesetting and/or panicking the system.

Are these just kernel oopses etc.? If the hardware gets upset from
modesetting when the sink is gone, well, then we still have a problem
because the user can of course yank the cable while the modeset is already
underway.

> 
> To work around this, we now unregister the connector at the very
> beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> locks, and then hold them until we finish the rest of the function.
> 
> CC: stable at vger.kernel.org
> Signed-off-by: Lyude 
> Signed-off-by: Rob Clark 

These sobs don't make much sense to me.

Patch itself does make sense to me, so 
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index fa0dabf..b21ac88 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>   struct intel_connector *intel_connector = to_intel_connector(connector);
>   struct drm_device *dev = connector->dev;
>  
> + intel_connector->unregister(intel_connector);
> +
>   /* need to nuke the connector */
>   drm_modeset_lock_all(dev);
>   if (connector->state->crtc) {
> @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct 
> drm_dp_mst_topology_mgr *mgr,
>  
>   WARN(ret, "Disabling mst crtc failed with %i\n", ret);
>   }
> - drm_modeset_unlock_all(dev);
>  
> - intel_connector->unregister(intel_connector);
> -
> - drm_modeset_lock_all(dev);
>   intel_connector_remove_from_fbdev(intel_connector);
>   drm_connector_cleanup(connector);
>   drm_modeset_unlock_all(dev);
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC


[PATCH v12 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

2016-03-16 Thread Jitao Shi
This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
---
Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove

The following patches are needed to support dsi host through none dsi bus:
https://patchwork.kernel.org/patch/8289181/ ("drm/dsi: check for CONFIG_OF when 
defining")
https://patchwork.kernel.org/patch/8289051/ ("drm/dsi: Use 
mipi_dsi_device_register_full for DSI device")
https://patchwork.kernel.org/patch/8289081/ ("drm/dsi: Try to match non-DT DSI 
devices")
https://patchwork.kernel.org/patch/8289121/ ("drm/dsi: Add routine to 
unregister a DSI device")
https://patchwork.kernel.org/patch/8289091/ ("drm/dsi: Get DSI host by DT 
device node")
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1073 
 3 files changed, 1086 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..be6084e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,16 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..fbe38dc 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..d7700e2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1073 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_IROM_CTRL0xb0
+#define IROM_ENABLE0xc0
+#define IROM_DISABLE   0x80
+#define PAGE2_SW_REST  0xbc
+#define SPI_SW_RESET   BIT(7)
+#define MPU_SW_RESET   BIT(6)
+#define PAGE2_ENCTLSPI_WR  0xda
+#define PAGE2_I2C_BYPASS   0xea
+#define I2C_BYPASS_EN  0xd0
+#define PAGE3_SET_ADD  0xfe
+#define PAGE3_SET_VAL  0xff
+#define VDO_CTL_ADD0x13
+#define VDO_DIS0x18
+#define VDO_EN 0x1c
+#define PAGE4_REV_L0xf0
+#define PAGE4_REV_H0xf1
+#define PAGE4_CHIP_L   0xf2
+#define PAGE4_CHIP_H   0xf3
+
+/* Firmware */
+#define SPI_MAX_RETRY_CNT  8
+#define PS_FW_NAME "ps864x_fw.bin"
+
+#define FW_CHIP_ID_OFFSET  0
+#define FW_VERSION_OFFSET  2
+#define EDID_I2C_ADDR  0x50
+
+#define WRITE_STATUS_REG_CMD   0x01
+#define READ_STATUS_REG_CMD0x05
+#define BUSY   BIT(0)
+#

[PATCH v12 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

2016-03-16 Thread Jitao Shi
Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v11:
 - No change
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..022b33f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,43 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = <&pio 116 GPIO_ACTIVE_LOW>;
+   reset-gpios = <&pio 115 GPIO_ACTIVE_LOW>;
+   mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <&ps8640_fixed_1v2>;
+   vdd33-supply = <&mt6397_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <&dsi0_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <&panel_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5



[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Deucher, Alexander
> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Wednesday, March 16, 2016 4:41 PM
> To: Koenig, Christian
> Cc: Jerome Glisse; Deucher, Alexander; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 3/4] drm/radeon: consolidate uvd/vce initialization,
> resume and suspend.
> 
> Just an aside,
> 
> So is there no way to do hibernate with these blocks?
> 
> Like can you not cleanly shut them down without doing a power cycle.

Christian is the expert, but my understanding is that once they are running, 
you can't re-initialize them without cutting the power to them (either via 
S3/S4 or powergating the block on chips that support it).  On windows hibernate 
is more like suspend.  There is no additional freeze and thaw in between. 
Probably the proper fix is only init the blocks once on resume from hibernate 
instead of doing it twice.  Kexec will probably have similar problems.

Alex



[PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

2016-03-16 Thread Samuel Pitoiset
Reviewed-by: Samuel Pitoiset 

On 03/14/2016 03:24 PM, Arnd Bergmann wrote:
> gcc-6 warns about code in the nouveau driver that is obviously silly:
>
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 
> 'nv40_perfctr_next':
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison 
> always evaluats to false [-Wtautological-compare]
>if (pm->sequence != pm->sequence) {
>
> The behavior was accidentally introduced in a patch described as "This is
> purely preparation for upcoming commits, there should be no code changes 
> here.".
> As far as I can tell, that was true for the rest of that patch except for
> this one function, which has been changed to a NOP.
>
> This patch restores the original behavior.
>
> Signed-off-by: Arnd Bergmann 
> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")
> ---
>   drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 6 --
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> index 4bef72a9d106..3fda594700e0 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> @@ -59,9 +59,11 @@ static void
>   nv40_perfctr_next(struct nvkm_pm *pm, struct nvkm_perfdom *dom)
>   {
>   struct nvkm_device *device = pm->engine.subdev.device;
> - if (pm->sequence != pm->sequence) {
> + struct nv40_pm *nv40pm = container_of(pm, struct nv40_pm, base);
> +
> + if (nv40pm->sequence != pm->sequence) {
>   nvkm_wr32(device, 0x400084, 0x0020);
> - pm->sequence = pm->sequence;
> + nv40pm->sequence = pm->sequence;
>   }
>   }
>
>


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Christian König
Am 16.03.2016 um 18:43 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 06:06:36PM +0100, Christian König wrote:
>> [SNIP]
>> And as I said that is exactly what you should NOT be doing here. Once the
>> firmware is loaded the block should be kept in that state.
>>
>> Freeing the memory allocated for the firmware is also not a good idea at all
>> because we don't know who exactly is accessing it.
> And what i am saying is that block is not responding so it does not matter
> what memory endup there as it only try to read from the firmware afaict.
> So nothing bad will come from that, block is already in non functional
> state what worse can happen ?

That the block is not responding to CPU register accesses just means 
that the SRBM read side interface doesn't work for some reason.

Depending on what the cause is the micro engine usually still happily 
read and write memory when that happens.

When the whole engine is hung you usually don't get working power 
management as well.

>>> [SNIP]
>>>
>>> Again lot simpler to follow control flow than to jump through various level
>>> of if/else. Again uvd and vce tied together (and again i can untie them if
>>> you think it is better to untie them).
>>>
>>> But this time the extra thing is that i properly disable ring if any error
>>> happens while existing code does not.
>> And again that is exactly what we should NOT do.
>>
>> When initialization fails we don't know in which state the ring buffer and
>> micro engines are, so freeing them and giving the space back to be reused in
>> clearly not a good idea.
>>
>> All we should do is clearing the ready flag when something fails to prevent
>> userspace from making command submissions to the failed engine.
> This block only read from that memory ! Never write (unless it modify the fw
> in place which would surprise me). So when block is in bad states it does not
> matter what endup there, block is not processing anything.

No, the memory is quite heavily written as well. Only BAR0 is code, BAR1 
is the heap and BAR2 the stack of the micro engine.

Those are usually heavily accessed by the interrupt handlers even when 
the engine is completely stuck otherwise.

The only way I know to prevent that is to stall the both the register as 
well as the memory bus, wait for a moment and then put the micro engine 
into soft reset. See uvd_v1_0_stop() how that is done.

But as I said after that you can usually forget power management as well.

>>> I am not pasting the init path but it the same logic, tying uvd and vce
>>> together and simplifying error code path.
>>>
>>>
>>>
 Please also note that VCE/UVD has dependencies on power management, so that
 when they are once initialized they should NOT be turned off again.

 I only briefly skimmed over your patch, but it actually looks like to me
 that you broken that by trying to cleanup the initialization routine.
>>> I have seen that but assuming Heisenbergs does not get involve, then given
>>> that the block is not responding to register write it is unlikely that thing
>>> will we worse if we try to disable the block. And from my testing it does
>>> not impact power management. My guess is that the block keep reporting it is
>>> busy and that power gating and clock gating are inhibited by that.
>> It's more complicated than that just a simple busy signal. The engines
>> actively communicate with the power management controller to tell them their
>> needs and limits for the clocks based on the workload they have.
>>
>> Once initialized the power management controller expects the UVD and VCE
>> micro-controllers to answer such requests.
>>
>> Failing to do so can get you stuck at a specific power level.
> Yes and what i am saying is that block is in bad states so either it is
> answering always busy and thus stop power level change or it is not answering
> and power level can change. So trying to disable the block leads to the
> exact same situation, either the block shutdown and power level can change
> or it does not and thing are exactly as if we did nothing !

I've tested that multiple times and as long as you don't turn of the 
VCPU completely it's usually still answering the interrupt handler even 
when it is stuck in an endless loop otherwise and not doing anything else.

That's also the reason why it is so dangerous to just put the block into 
reset in this state or touch it otherwise.

You can't stall it because the SRBM interface is borked and you don't 
have access to the registers any more and you can't properly reset it 
either because when you do that in the middle of a memory transaction 
the whole system goes down.

[SNIP]
>> As far as I can see you're actually messing the error handling up quite a
>> bit here instead of improving it.
> I am not ! I AM MAKING IT CLEAR WHAT HAPPENS. YES ON ERROR I TRY TO DISABLE
> THING BUT IF BLOCK IS NOT ANSWERING THIS CAN NOT MAKE THING WORSE.

Calm down, I'm just trying to explain here how the hardware works

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

2016-03-16 Thread Russell King - ARM Linux
On Wed, Mar 16, 2016 at 04:28:25PM +0100, Daniel Vetter wrote:
> On Wed, Mar 16, 2016 at 02:57:49PM +, Robin Murphy wrote:
> > In the absence of an fb_mmap callback, the fbdev code falls back to a
> > naive implementation which relies upon the DMA address being the same
> > as the physical address, and the buffer being physically contiguous
> > from there. Whilst this often holds for standard CMA allocations via
> > the platform's regular DMA ops, if the allocation is provided by an
> > IOMMU then such assumptions can fall apart spectacularly.
> > 
> > To resolve this, reroute the fb_mmap call to the appropriate DMA API
> > implementation, as per the other cma_helper calls.
> > 
> > Signed-off-by: Robin Murphy 
> > ---
> > 
> > Hi dri-devel,
> > 
> > This is an empirical fix for something I tickled via the newly-added
> > ARM HDLCD driver on a Juno platform - I have no idea whatsoever about
> > how "proper" it is in terms of the DRM infrastructure, so feel free to
> > treat this as a bug report rather than an actual patch if appropriate ;)
> 
> I think the best case would be if we could have a generic fbdev helper
> that remaps to dumb mmap support. But that's a bit tricky to pull of:
> 1. from fb_info we can get at the fbdev drm_framebuffer.
> 2. from a drm_framebuffer we can get at the underlying backing storage
> object using fb->funcs->get_handle.
> 3. With that handle we could go into the dumb mmap support (using als the
> vma) and create the mmap.
> 
> Except that ->get_handle needs a file_priv, and that just exist for the
> fbdev emulation kms client. I guess we could fix that by creating a
> minimal fake drm file_priv for the fbdev emulation (and treat it more like
> any other kms client), but I think that's way too much work when this
> simple patch here gets the job done.

I think first, a different question needs to be answered:

include/uapi/linux/fb.h:

struct fb_fix_screeninfo {
char id[16];/* identification string eg "TT 
Builtin" */
unsigned long smem_start;   /* Start of frame buffer mem */
/* (physical address) */

Should a DMA address be exposed through smem_start, rather than a
physical address as the long-standing documentation quoted above
has stated?

Is it, in fact, a driver bug to store something that isn't a physical
address there?

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


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Jerome Glisse
On Wed, Mar 16, 2016 at 06:06:36PM +0100, Christian König wrote:
> Am 16.03.2016 um 16:56 schrieb Jerome Glisse:
> >On Wed, Mar 16, 2016 at 04:19:16PM +0100, Christian König wrote:
> >>Am 16.03.2016 um 15:59 schrieb Jerome Glisse:
> >>>On Wed, Mar 16, 2016 at 2:03 PM, Christian König
> >>> wrote:
> Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
> >From: Jérome Glisse 
> >
> >This consolidate uvd/vce into a common shape for all generation. It
> >also leverage the rdev->has_uvd flags to know what it is useless to
> >try to resume/suspend uvd/vce block.
> >
> >There is no functional changes when there is no error. On error the
> >device driver will behave differently than before after this patch.
> >It should now safely ignore uvd/vce errors and keeps normal operation
> >of others engine. This is an improvement over current situation where
> >we have different behavior depending on GPU generation and on what
> >fails.
> >
> >Finaly this is a preparatory step for a patch which allow to disable
> >uvd/vce as a driver option.
> >
> >This have only been tested on southern island so please test it on
> >other generations (i do not have hardware handy for now).
> >
> >Signed-off-by: Jérôme Glisse 
> >Cc: Alex Deucher 
> >Cc: Christian König 
> NAK, skipping UVD and VCE suspend/resume when initialization fails should
> already be implemented.
> 
> There might be some (quite some) bugs in there, but that doesn't justify
> reworking the initialization over all different generations. Especially
> since you don't have hardware to test all of them.
> 
> Just make sure that radeon_uvd/vce_fini() is called when something goes
> wrong and/or that the UVD/VCE BO is properly released.
> 
> Regards,
> Christian.
> >>>Current code is a mess when it comes to handling error related to
> >>>uvd/vce. This patch consolidate control flow in something easy to
> >>>follow. You can check that there is absolulety no control flow change
> >>>for the case where uvd/vce works and thus it does not break anything
> >>>that works. It will only gracefully fails and cleanup if things go
> >>>wrong. So while i have not tested on other hw i am confident that this
> >>>does not introduce regression.
> >>>
> >>>I tried to do it without consolidation but it ended up in adding even
> >>>more if() levels that line did begins after 80colums. So please
> >>>reconsider because this is an improvement over existing code.
> >>Well then please point out at the example of the SI or CIK code what exactly
> >>is missing here.
> >Going from :
> > if (rdev->has_uvd) {
> > r = uvd_v2_2_resume(rdev);
> > if (!r) {
> > r = radeon_fence_driver_start_ring(rdev,
> >
> > R600_RING_TYPE_UVD_INDEX);
> > if (r)
> > dev_err(rdev->dev, "UVD fences init error 
> > (%d).\n", r);
> > }
> > if (r)
> > rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
> > }
> > r = radeon_vce_resume(rdev);
> > if (!r) {
> > r = vce_v1_0_resume(rdev);
> > if (!r)
> > r = radeon_fence_driver_start_ring(rdev,
> >
> > TN_RING_TYPE_VCE1_INDEX);
> > if (!r)
> > r = radeon_fence_driver_start_ring(rdev,
> >
> > TN_RING_TYPE_VCE2_INDEX);
> > }
> > if (r) {
> > dev_err(rdev->dev, "VCE init error (%d).\n", r);
> > rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
> > rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
> > }
> >
> >
> >To:
> > r = uvd_v2_2_resume(rdev);
> > if (r)
> > goto error;
> > r = radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
> > if (r)
> > goto error_uvd;
> > r = radeon_vce_resume(rdev);
> > if (r)
> > goto error_uvd;
> > r = vce_v1_0_resume(rdev);
> > if (r)
> > goto error_vce;
> > r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE1_INDEX);
> > if (r)
> > goto error_vce;
> > r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE2_INDEX);
> > if (r)
> > goto error_vce;
> > return;
> >error_vce:
> > radeon_vce_suspend(rdev);
> >error_uvd:
> > radeon_uvd_suspend(rdev);
> >error:
> > dev_err(rdev->dev, "UVD/VCE startup error (%d).\n", r);
> > /* On error just disable everything. */
> > radeon_vce_fini(rdev);
> > radeon_uvd_fini(rdev);
> > rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
> > rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
> > rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
> 
> And as I said that

[PATCH 1/3] drm/radeon: fix indentation.

2016-03-16 Thread Alex Deucher
Applied.  thanks!

Alex


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Christian König
Am 16.03.2016 um 16:56 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 04:19:16PM +0100, Christian König wrote:
>> Am 16.03.2016 um 15:59 schrieb Jerome Glisse:
>>> On Wed, Mar 16, 2016 at 2:03 PM, Christian König
>>>  wrote:
 Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
> From: Jérome Glisse 
>
> This consolidate uvd/vce into a common shape for all generation. It
> also leverage the rdev->has_uvd flags to know what it is useless to
> try to resume/suspend uvd/vce block.
>
> There is no functional changes when there is no error. On error the
> device driver will behave differently than before after this patch.
> It should now safely ignore uvd/vce errors and keeps normal operation
> of others engine. This is an improvement over current situation where
> we have different behavior depending on GPU generation and on what
> fails.
>
> Finaly this is a preparatory step for a patch which allow to disable
> uvd/vce as a driver option.
>
> This have only been tested on southern island so please test it on
> other generations (i do not have hardware handy for now).
>
> Signed-off-by: Jérôme Glisse 
> Cc: Alex Deucher 
> Cc: Christian König 
 NAK, skipping UVD and VCE suspend/resume when initialization fails should
 already be implemented.

 There might be some (quite some) bugs in there, but that doesn't justify
 reworking the initialization over all different generations. Especially
 since you don't have hardware to test all of them.

 Just make sure that radeon_uvd/vce_fini() is called when something goes
 wrong and/or that the UVD/VCE BO is properly released.

 Regards,
 Christian.
>>> Current code is a mess when it comes to handling error related to
>>> uvd/vce. This patch consolidate control flow in something easy to
>>> follow. You can check that there is absolulety no control flow change
>>> for the case where uvd/vce works and thus it does not break anything
>>> that works. It will only gracefully fails and cleanup if things go
>>> wrong. So while i have not tested on other hw i am confident that this
>>> does not introduce regression.
>>>
>>> I tried to do it without consolidation but it ended up in adding even
>>> more if() levels that line did begins after 80colums. So please
>>> reconsider because this is an improvement over existing code.
>> Well then please point out at the example of the SI or CIK code what exactly
>> is missing here.
> Going from :
>   if (rdev->has_uvd) {
>   r = uvd_v2_2_resume(rdev);
>   if (!r) {
>   r = radeon_fence_driver_start_ring(rdev,
>  
> R600_RING_TYPE_UVD_INDEX);
>   if (r)
>   dev_err(rdev->dev, "UVD fences init error 
> (%d).\n", r);
>   }
>   if (r)
>   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
>   }
>   r = radeon_vce_resume(rdev);
>   if (!r) {
>   r = vce_v1_0_resume(rdev);
>   if (!r)
>   r = radeon_fence_driver_start_ring(rdev,
>  
> TN_RING_TYPE_VCE1_INDEX);
>   if (!r)
>   r = radeon_fence_driver_start_ring(rdev,
>  
> TN_RING_TYPE_VCE2_INDEX);
>   }
>   if (r) {
>   dev_err(rdev->dev, "VCE init error (%d).\n", r);
>   rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
>   rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
>   }
>
>
> To:
>   r = uvd_v2_2_resume(rdev);
>   if (r)
>   goto error;
>   r = radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
>   if (r)
>   goto error_uvd;
>   r = radeon_vce_resume(rdev);
>   if (r)
>   goto error_uvd;
>   r = vce_v1_0_resume(rdev);
>   if (r)
>   goto error_vce;
>   r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE1_INDEX);
>   if (r)
>   goto error_vce;
>   r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE2_INDEX);
>   if (r)
>   goto error_vce;
>   return;
> error_vce:
>   radeon_vce_suspend(rdev);
> error_uvd:
>   radeon_uvd_suspend(rdev);
> error:
>   dev_err(rdev->dev, "UVD/VCE startup error (%d).\n", r);
>   /* On error just disable everything. */
>   radeon_vce_fini(rdev);
>   radeon_uvd_fini(rdev);
>   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
>   rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
>   rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;

And as I said that is exactly what you should NOT be doing here. Once 
the firmware is loaded the block should be kept in that state.

Freeing the memory allocated for 

[Intel-gfx] [PATCH 1/2] drm/i915: Call intel_dp_mst_resume() before resuming displays

2016-03-16 Thread Lyude Paul
On Sun, 2016-03-13 at 19:45 +0100, Daniel Vetter wrote:
> On Fri, Mar 11, 2016 at 10:57:01AM -0500, Lyude wrote:
> > 
> > Since we need MST devices ready before we try to resume displays,
> > calling this after intel_display_resume() can result in some issues with
> > various laptop docks where the monitor won't turn back on after
> > suspending the system.
> > 
> > This order was originally changed in
> > 
> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
> > 
> > In order to fix some unclaimed register errors, however the actual cause
> > of those has since been fixed.
> > 
> > CC: stable at vger.kernel.org
> > Signed-off-by: Lyude 
> Don't we need to first apply patch 2/2 to avoid breaking systems
> in-between?
> -Daniel
AFAICT the warns don't appear even with this patch, so no.
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index f357058..08854ae 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -761,12 +761,12 @@ static int i915_drm_resume(struct drm_device *dev)
> >    dev_priv->display.hpd_irq_setup(dev);
> >    spin_unlock_irq(&dev_priv->irq_lock);
> >  
> > +   intel_dp_mst_resume(dev);
> > +
> >    drm_modeset_lock_all(dev);
> >    intel_display_resume(dev);
> >    drm_modeset_unlock_all(dev);
> >  
> > -   intel_dp_mst_resume(dev);
> > -
> >    /*
> >     * ... but also need to make sure that hotplug processing
> >     * doesn't cause havoc. Like in the driver load code we don't
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Jerome Glisse
On Wed, Mar 16, 2016 at 04:19:16PM +0100, Christian König wrote:
> Am 16.03.2016 um 15:59 schrieb Jerome Glisse:
> >On Wed, Mar 16, 2016 at 2:03 PM, Christian König
> > wrote:
> >>Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
> >>>From: Jérome Glisse 
> >>>
> >>>This consolidate uvd/vce into a common shape for all generation. It
> >>>also leverage the rdev->has_uvd flags to know what it is useless to
> >>>try to resume/suspend uvd/vce block.
> >>>
> >>>There is no functional changes when there is no error. On error the
> >>>device driver will behave differently than before after this patch.
> >>>It should now safely ignore uvd/vce errors and keeps normal operation
> >>>of others engine. This is an improvement over current situation where
> >>>we have different behavior depending on GPU generation and on what
> >>>fails.
> >>>
> >>>Finaly this is a preparatory step for a patch which allow to disable
> >>>uvd/vce as a driver option.
> >>>
> >>>This have only been tested on southern island so please test it on
> >>>other generations (i do not have hardware handy for now).
> >>>
> >>>Signed-off-by: Jérôme Glisse 
> >>>Cc: Alex Deucher 
> >>>Cc: Christian König 
> >>
> >>NAK, skipping UVD and VCE suspend/resume when initialization fails should
> >>already be implemented.
> >>
> >>There might be some (quite some) bugs in there, but that doesn't justify
> >>reworking the initialization over all different generations. Especially
> >>since you don't have hardware to test all of them.
> >>
> >>Just make sure that radeon_uvd/vce_fini() is called when something goes
> >>wrong and/or that the UVD/VCE BO is properly released.
> >>
> >>Regards,
> >>Christian.
> >Current code is a mess when it comes to handling error related to
> >uvd/vce. This patch consolidate control flow in something easy to
> >follow. You can check that there is absolulety no control flow change
> >for the case where uvd/vce works and thus it does not break anything
> >that works. It will only gracefully fails and cleanup if things go
> >wrong. So while i have not tested on other hw i am confident that this
> >does not introduce regression.
> >
> >I tried to do it without consolidation but it ended up in adding even
> >more if() levels that line did begins after 80colums. So please
> >reconsider because this is an improvement over existing code.
> 
> Well then please point out at the example of the SI or CIK code what exactly
> is missing here.

Going from :
if (rdev->has_uvd) {
r = uvd_v2_2_resume(rdev);
if (!r) {
r = radeon_fence_driver_start_ring(rdev,
   
R600_RING_TYPE_UVD_INDEX);
if (r)
dev_err(rdev->dev, "UVD fences init error 
(%d).\n", r);
}
if (r)
rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
}
r = radeon_vce_resume(rdev);
if (!r) {
r = vce_v1_0_resume(rdev);
if (!r)
r = radeon_fence_driver_start_ring(rdev,
   
TN_RING_TYPE_VCE1_INDEX);
if (!r)
r = radeon_fence_driver_start_ring(rdev,
   
TN_RING_TYPE_VCE2_INDEX);
}
if (r) {
dev_err(rdev->dev, "VCE init error (%d).\n", r);
rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
}


To:
r = uvd_v2_2_resume(rdev);
if (r)
goto error;
r = radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
if (r)
goto error_uvd;
r = radeon_vce_resume(rdev);
if (r)
goto error_uvd;
r = vce_v1_0_resume(rdev);
if (r)
goto error_vce;
r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE1_INDEX);
if (r)
goto error_vce;
r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE2_INDEX);
if (r)
goto error_vce;
return;
error_vce:
radeon_vce_suspend(rdev);
error_uvd:
radeon_uvd_suspend(rdev);
error:
dev_err(rdev->dev, "UVD/VCE startup error (%d).\n", r);
/* On error just disable everything. */
radeon_vce_fini(rdev);
radeon_uvd_fini(rdev);
rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;


Is lot more clear to me than bunch of intertwine if/else. A clear error path
for which you do not have to jump through if level to see what get executed
or not on error. The only difference is that it does tie uvd and vce together.
I did that on purpose because on the

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

2016-03-16 Thread Daniel Vetter
On Wed, Mar 16, 2016 at 02:57:49PM +, Robin Murphy wrote:
> In the absence of an fb_mmap callback, the fbdev code falls back to a
> naive implementation which relies upon the DMA address being the same
> as the physical address, and the buffer being physically contiguous
> from there. Whilst this often holds for standard CMA allocations via
> the platform's regular DMA ops, if the allocation is provided by an
> IOMMU then such assumptions can fall apart spectacularly.
> 
> To resolve this, reroute the fb_mmap call to the appropriate DMA API
> implementation, as per the other cma_helper calls.
> 
> Signed-off-by: Robin Murphy 
> ---
> 
> Hi dri-devel,
> 
> This is an empirical fix for something I tickled via the newly-added
> ARM HDLCD driver on a Juno platform - I have no idea whatsoever about
> how "proper" it is in terms of the DRM infrastructure, so feel free to
> treat this as a bug report rather than an actual patch if appropriate ;)

I think the best case would be if we could have a generic fbdev helper
that remaps to dumb mmap support. But that's a bit tricky to pull of:
1. from fb_info we can get at the fbdev drm_framebuffer.
2. from a drm_framebuffer we can get at the underlying backing storage
object using fb->funcs->get_handle.
3. With that handle we could go into the dumb mmap support (using als the
vma) and create the mmap.

Except that ->get_handle needs a file_priv, and that just exist for the
fbdev emulation kms client. I guess we could fix that by creating a
minimal fake drm file_priv for the fbdev emulation (and treat it more like
any other kms client), but I think that's way too much work when this
simple patch here gets the job done.

Long story short, assuming this doesn't break other cma-helper using
drivers:

Acked-by: Daniel Vetter 

> 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index bb88e3d..117d7ea 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  struct drm_fb_cma {
> @@ -221,6 +222,12 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void 
> *arg)
>  EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
>  #endif
>  
> +static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> + return dma_mmap_writecombine(info->device, vma, info->screen_base,
> +  info->fix.smem_start, info->fix.smem_len);
> +}
> +
>  static struct fb_ops drm_fbdev_cma_ops = {
>   .owner  = THIS_MODULE,
>   .fb_fillrect= drm_fb_helper_sys_fillrect,
> @@ -231,6 +238,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
>   .fb_blank   = drm_fb_helper_blank,
>   .fb_pan_display = drm_fb_helper_pan_display,
>   .fb_setcmap = drm_fb_helper_setcmap,
> + .fb_mmap= drm_fb_cma_mmap,
>  };
>  
>  static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
> -- 
> 2.7.3.dirty
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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


[PATCH v15 1/3] drm: rockchip: Add basic drm driver

2016-03-16 Thread Tomeu Vizoso
On 15 March 2016 at 02:30, Mark yao  wrote:
> On 2016年03月14日 21:35, Tomeu Vizoso wrote:
>>
>> On 2 December 2014 at 10:15, Mark Yao  wrote:
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> new file mode 100644
>>> index 000..e7ca25b
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -0,0 +1,1455 @@
>>
>> ...
>>>
>>> +static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>>> +   const struct drm_display_mode *mode,
>>> +   struct drm_display_mode *adjusted_mode)
>>> +{
>>> +   if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
>>> +   return false;
>>
>> Hi Mark,
>>
>> what's the rationale for this?
>>
>> Disabling a CRTC as in [0] will cause mode_fixup() to be called with
>> an empty mode, failing that test.
>>
>> Removing the check seems to get things working fine for a short while,
>> but a later modeset invariably gets the VOP to hang (as reported by
>> [1]).
>>
>> Do you know why that check was put in place and what exactly could be
>> causing the hw to hang?
>>
>> [0]
>> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
>>
>> Thanks,
>>
>> Tomeu
>>
> Hi Tomeu
>
> Just thinking that "adjusted_mode->htotal == 0 || adjusted_mode->vtotal ==
> 0" is not a good mode for vop.

Ah, ok. Guess it should be removed then so we don't break userspace?

> And you said VOP hang, only WARN_ON error message? or system hang, die?

Sorry, the symptom was only the warning, I just went a bit too far and
assumed the VOP had stopped working at all.

> I think maybe crtc disable too fast, vblank is off, then no one can feed the
> wait_update_complete.
> Can you test it again with following patch?

Actually, in today's testing I don't see that happening any more,
sorry about that :/

What I have been looking at today is a related issue when running the
kms_flip_event_leak test from intel-gpu-tools. If I remove the check
mentioned above so CRTCs can be disabled with the SetCRTC IOCTL, I see
this page fault the second and subsequent times I run the test.

[   75.809031] rk_iommu ff930300.iommu: Page fault at 0x0100 of type read
[   75.809035] rk_iommu ff930300.iommu: iova = 0x0100: dte_index:
0x4 pte_index: 0x0 page_offset: 0x0
[   75.809040] rk_iommu ff930300.iommu: mmu_dte_addr: 0x2c258000
dte at 0x2c258010: 0x2c561001 valid: 1 pte at 0x2c561000: 0x2a06 valid:
0 page at 0x flags: 0x0
[   76.951288] rk_iommu ff930300.iommu: Enable stall request timed
out, status: 0x4b

I have written a smaller standalone test that is attached in case you
want to check it out, but I haven't been able to find out why it only
happens when the test is rerun.

Apparently the VOP is still trying to read a BO (0x0100) right
when the kernel frees it, but from what I can see, it should be
scanning another BO at that point.

Do you have any ideas on what could be happening?

Thanks,

Tomeu

> drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -503,6 +503,8 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
> if (!vop->is_enabled)
> return;
>  +   vop_crtc_wait_for_update(crtc);
> +
> drm_crtc_vblank_off(crtc);
>
> Thanks.
>
> --
> ï¼­ark Yao
>
>
-- next part --
A non-text attachment was scrubbed...
Name: page_fault.c
Type: text/x-csrc
Size: 3368 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160316/739ab6f1/attachment-0001.c>


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Christian König
Am 16.03.2016 um 15:59 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 2:03 PM, Christian König
>  wrote:
>> Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
>>> From: Jérome Glisse 
>>>
>>> This consolidate uvd/vce into a common shape for all generation. It
>>> also leverage the rdev->has_uvd flags to know what it is useless to
>>> try to resume/suspend uvd/vce block.
>>>
>>> There is no functional changes when there is no error. On error the
>>> device driver will behave differently than before after this patch.
>>> It should now safely ignore uvd/vce errors and keeps normal operation
>>> of others engine. This is an improvement over current situation where
>>> we have different behavior depending on GPU generation and on what
>>> fails.
>>>
>>> Finaly this is a preparatory step for a patch which allow to disable
>>> uvd/vce as a driver option.
>>>
>>> This have only been tested on southern island so please test it on
>>> other generations (i do not have hardware handy for now).
>>>
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Alex Deucher 
>>> Cc: Christian König 
>>
>> NAK, skipping UVD and VCE suspend/resume when initialization fails should
>> already be implemented.
>>
>> There might be some (quite some) bugs in there, but that doesn't justify
>> reworking the initialization over all different generations. Especially
>> since you don't have hardware to test all of them.
>>
>> Just make sure that radeon_uvd/vce_fini() is called when something goes
>> wrong and/or that the UVD/VCE BO is properly released.
>>
>> Regards,
>> Christian.
> Current code is a mess when it comes to handling error related to
> uvd/vce. This patch consolidate control flow in something easy to
> follow. You can check that there is absolulety no control flow change
> for the case where uvd/vce works and thus it does not break anything
> that works. It will only gracefully fails and cleanup if things go
> wrong. So while i have not tested on other hw i am confident that this
> does not introduce regression.
>
> I tried to do it without consolidation but it ended up in adding even
> more if() levels that line did begins after 80colums. So please
> reconsider because this is an improvement over existing code.

Well then please point out at the example of the SI or CIK code what 
exactly is missing here.

Please also note that VCE/UVD has dependencies on power management, so 
that when they are once initialized they should NOT be turned off again.

I only briefly skimmed over your patch, but it actually looks like to me 
that you broken that by trying to cleanup the initialization routine.

Regards,
Christian.

>
> Jérôme



[PATCH v2 1/9] drm: atmel-hlcdc: add a ->cleanup_fb() operation

2016-03-16 Thread Daniel Vetter
On Wed, Mar 16, 2016 at 02:57:35PM +0100, Boris Brezillon wrote:
> Add a ->cleanup_fb() operation to avoid memory leaks when the atomic
> operation is interrupted after the ->prepare_fb() call.
> 
> Signed-off-by: Boris Brezillon 
> Fixes 2389fc1 ("drm: atmel-hlcdc: Atomic mode-setting conversion")
> Reviewed-by: Nicolas Ferre 
> Tested-by: Nicolas Ferre 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  2 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +++---
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index fed517f..ec64140 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -81,11 +81,13 @@ struct atmel_hlcdc_plane_properties {
>   * @layer: HLCDC layer structure
>   * @properties: pointer to the property definitions structure
>   * @rotation: current rotation status
> + * @prepared: flagging the plane has prepared for an atomic update
>   */
>  struct atmel_hlcdc_plane {
>   struct drm_plane base;
>   struct atmel_hlcdc_layer layer;
>   struct atmel_hlcdc_plane_properties *properties;
> + bool prepared;
>  };
>  
>  static inline struct atmel_hlcdc_plane *
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 1ffe9c3..35027d0 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -715,11 +715,25 @@ static int atmel_hlcdc_plane_prepare_fb(struct 
> drm_plane *p,
>   const struct drm_plane_state *new_state)
>  {
>   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> + int ret;
>  
> - if (!new_state->fb)
> - return 0;
> + ret = atmel_hlcdc_layer_update_start(&plane->layer);
> + if (!ret)
> + plane->prepared = true;

Atomic helpers will keep track of this for you, and only call ->cleanup_fb
on a plane combo where it did (successfully) call ->prepare_fb.
-Daniel

> +
> + return ret;
> +}
> +
> +static void atmel_hlcdc_plane_cleanup_fb(struct drm_plane *p,
> + const struct drm_plane_state *old_state)
> +{
> + struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> +
> + if (!plane->prepared)
> + return;
>  
> - return atmel_hlcdc_layer_update_start(&plane->layer);
> + atmel_hlcdc_layer_update_rollback(&plane->layer);
> + plane->prepared = false;
>  }
>  
>  static void atmel_hlcdc_plane_atomic_update(struct drm_plane *p,
> @@ -739,6 +753,7 @@ static void atmel_hlcdc_plane_atomic_update(struct 
> drm_plane *p,
>   atmel_hlcdc_plane_update_disc_area(plane, state);
>  
>   atmel_hlcdc_layer_update_commit(&plane->layer);
> + plane->prepared = false;
>  }
>  
>  static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
> @@ -844,6 +859,7 @@ static void atmel_hlcdc_plane_init_properties(struct 
> atmel_hlcdc_plane *plane,
>  
>  static struct drm_plane_helper_funcs atmel_hlcdc_layer_plane_helper_funcs = {
>   .prepare_fb = atmel_hlcdc_plane_prepare_fb,
> + .cleanup_fb = atmel_hlcdc_plane_cleanup_fb,
>   .atomic_check = atmel_hlcdc_plane_atomic_check,
>   .atomic_update = atmel_hlcdc_plane_atomic_update,
>   .atomic_disable = atmel_hlcdc_plane_atomic_disable,
> -- 
> 2.5.0
> 

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


[RFC 1/5] drm: Add DRM support for tiny LCD displays

2016-03-16 Thread Daniel Vetter
On Wed, Mar 16, 2016 at 02:34:15PM +0100, Noralf Trønnes wrote:
> tinydrm provides a very simplified view of DRM for displays that has
> onboard video memory and is connected through a slow bus like SPI/I2C.
> 
> Signed-off-by: Noralf Trønnes 

Yay, it finally happens! I already made a comment on the cover letter
about the fbdev stuff, I think that's the biggest part to split out from
tinydrm here. I'm not entirely sure a detailed code review makes sense
before that part is done (and hey we can start merging already), so just a
high level review for now:

The big story in kms/drm in the past years is that we've rejecting
anything that remotely looks like a midlayer. Instead the preferred design
pattern is a library of helper functions to implement useful default
behaviour, or sometimes just building blocks for useful default behaviour.
And then build up real drivers using these pieces. The benefit of that is
two-fold:
- easier to share code with other drivers that only need part of the
  behaviour (e.g. fbdev deferred io support).
- easier to adapt to special hw that needs exceptions since worst case you
  can just copypaste an entire hook. Or implement the special case and
  call the default helper for the normal cases.

lwn has a good article on this pattern:

https://lwn.net/Articles/336262/

In the case of tinydrm I think that means we should have a bunch of new
drm helpers, or extensions for existing ones:
- fbdev deferred io support using ->dirtyfb in drm_fb_helper.c.
- Helper to generate a simple display pipeline with 1 plane, 1 crtc, 1
  encoder pointing at a specific drm_connector. There's lots of other
  simple hw that could use this. Maybe create a new
  drm_simple_kms_helper.c for this.
- A helper to create a simple drm_connector from a drm_panel (the
  get_modes hooks you have here), maybe also in drm_simple_kms_helper.c.
- Helpers to handle dirtyfb, like the clip rect merge function you have in
  here.
- Helper maybe for purely software framebuffers that are uploaded using
  cpu access instead of dma.

Then bus-specific support you have in later patches for tinydrm would each
be a separate drm driver, assemebled using those helper blocks. It's a
notch more boilerplate maybe, but all the separate pieces I listed above
would be useful in drivers outside of just tinydrm. And maybe other
drivers would need almost everything, except the drm_framebuffer must be
alloced using the dma api (i.e. those should use the cma helpers), e.g.
when your dumb bus can do dma of some sort.

Anyway first thoughts, I'm really happy that something like this finally
happens!

Cheers, Daniel
> ---
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tinydrm/Kconfig|  11 +
>  drivers/gpu/drm/tinydrm/Makefile   |   1 +
>  drivers/gpu/drm/tinydrm/core/Makefile  |   8 +
>  drivers/gpu/drm/tinydrm/core/internal.h|  43 +++
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 194 
>  drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c| 203 
>  drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c| 116 +++
>  drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c   | 345 
> +
>  drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c | 112 +++
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  97 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-plane.c   |  50 +++
>  include/drm/tinydrm/tinydrm.h  | 142 +
>  14 files changed, 1325 insertions(+)
>  create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
>  create mode 100644 drivers/gpu/drm/tinydrm/Makefile
>  create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
>  create mode 100644 drivers/gpu/drm/tinydrm/core/internal.h
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
>  create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-plane.c
>  create mode 100644 include/drm/tinydrm/tinydrm.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c4bf9a1..3f8ede0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>  source "drivers/gpu/drm/imx/Kconfig"
>  
>  source "drivers/gpu/drm/vc4/Kconfig"
> +
> +source "drivers/gpu/drm/tinydrm/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 1e9ff4c..c7c5c16 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -75,3 +75,4 @@ obj-y   += i2c/
>  obj-y+= pan

EXTENDED: 2016 X.Org Board of Directors Elections Nomination period is NOW

2016-03-16 Thread Peter Hutterer
We had a number of last-minute nominations and this did not give all nominees
the chance to respond to the nominations. Hence, we are extending the
nomination period for two weeks. All election dates thus move back by two
weeks. Below is the original text of the nomination request email.

We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors.  All X.Org Foundation members are
eligible for election to the board.

Nominations for the 2016 election are now open and will remain open
until 23:59 UTC on 29 March 2016.

The Board consists of directors elected from the membership.  Each
year, an election is held to bring the total number of directors to
eight. The four members receiving the highest vote totals will serve
as directors for two year terms.

The directors who received two year terms starting in 2015 were
Peter Hutterer, Martin Peres, Rob Clark and Daniel Vetter, They
will continue to serve until their term ends in 2017.  Current
directors whose term expires in 2016 are Alex Deucher, Matt Dew,
Egbert Eich and Keith Packard.

A director is expected to participate in the fortnightly IRC meeting to
discuss current business and to attend the annual meeting of the X.Org
Foundation, which will be held at a location determined in advance by
the Board of Directors.

A member may nominate themselves or any other member they feel is
qualified. Nominations should be sent to the Election Committee at
elections at x.org.

Nominees shall be required to be current members of the X.Org
Foundation, and submit a  personal statement of up to 200 words that
will be provided to prospective voters.  The collected statements,
along with the statement of contribution to the X.Org Foundation in
the members account page on http://members.x.org, will be made
available to all voters to help them make their voting decisions.

Nominations, membership applications or renewals and completed
personal statements must be received no later than 23:59 UTC on 15 March
2016.

The slate of candidates will be published 31 March
2016 and candidate Q&A will begin then. The deadline for Xorg
membership applications and renewals is 31 March 2016.

Cheers,
   Peter, on behalf of the X.Org BoD

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160316/3e24feb7/attachment-0001.sig>


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Jerome Glisse
On Wed, Mar 16, 2016 at 2:03 PM, Christian König
 wrote:
> Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
>>
>> From: Jérome Glisse 
>>
>> This consolidate uvd/vce into a common shape for all generation. It
>> also leverage the rdev->has_uvd flags to know what it is useless to
>> try to resume/suspend uvd/vce block.
>>
>> There is no functional changes when there is no error. On error the
>> device driver will behave differently than before after this patch.
>> It should now safely ignore uvd/vce errors and keeps normal operation
>> of others engine. This is an improvement over current situation where
>> we have different behavior depending on GPU generation and on what
>> fails.
>>
>> Finaly this is a preparatory step for a patch which allow to disable
>> uvd/vce as a driver option.
>>
>> This have only been tested on southern island so please test it on
>> other generations (i do not have hardware handy for now).
>>
>> Signed-off-by: Jérôme Glisse 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>
>
> NAK, skipping UVD and VCE suspend/resume when initialization fails should
> already be implemented.
>
> There might be some (quite some) bugs in there, but that doesn't justify
> reworking the initialization over all different generations. Especially
> since you don't have hardware to test all of them.
>
> Just make sure that radeon_uvd/vce_fini() is called when something goes
> wrong and/or that the UVD/VCE BO is properly released.
>
> Regards,
> Christian.

Current code is a mess when it comes to handling error related to
uvd/vce. This patch consolidate control flow in something easy to
follow. You can check that there is absolulety no control flow change
for the case where uvd/vce works and thus it does not break anything
that works. It will only gracefully fails and cleanup if things go
wrong. So while i have not tested on other hw i am confident that this
does not introduce regression.

I tried to do it without consolidation but it ended up in adding even
more if() levels that line did begins after 80colums. So please
reconsider because this is an improvement over existing code.

Jérôme


[RFC 0/5] drm: Add support for tiny LCD displays

2016-03-16 Thread Daniel Vetter
On Wed, Mar 16, 2016 at 02:34:14PM +0100, Noralf Trønnes wrote:
> This is an attempt at providing a DRM version of drivers/staging/fbtft.
> I'm sending this early before cleaning up the code hoping to get some
> feedback in case there are better ways to structure this.
> 
> The tinydrm module provides a very simplified view of DRM for displays that
> has onboard video memory and is connected through a slow bus like SPI/I2C.
> A driver using tinydrm has to provide a function that will be called from
> the dirtyfb ioctl and optionally drm_panel functions which can be used to
> set up the display controller and control backlight.
> 
> tinydrm also has fbdev support using fb_deferred_io which is tied in through
> the dirtyfb function call. A driver can use the provided deferred work code
> to collect dirtyfb calls and schedule display memory updates if it whishes.
> The various display controllers can have library modules that handles
> display updates.

fbdev fb_deferred_io should be part of the fbdev helper, not a separate
library. We already have hand-rolled fbdev deferred io in qxl, i915 & udl,
no need to invent yet another one. Well the one in i915 is a bit a hack.

I think the best option would be to extract the code from qxl (since it
already uses a work automatically if needed) and put it into drm_fb_helper.c.
Otherwise the layering goes bust. We already have drm_fb_helper_* hooks
for everything, so only thing to do in drivers is to remove lots of code
\o/

I haven't looked at any of the other parts, just a quick comment on this
part here.
-Daniel

> Display controllers that have a similar register interface as the MIPI DBI/DCS
> controllers can use the lcdreg module for register access.
> 
> struct tinydrm_device {
>   struct drm_device *base;
>   u32 width, height;
>   struct drm_panel panel;
> [...]
>   int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags,
>  unsigned color, struct drm_clip_rect *clips,
>  unsigned num_clips);
> };
> 
> +--+-+
> |  |  fbdev  |
> |  DRM +--+  |
> | |  |
> +-+--+
> ||
> |tinydrm |
> ||
> +--+ .  .  .  .  .  .  . |
> |  |deferred work|
> |  Display driver  +-+
> |  |  Controller module  |
> +--+-+
> | lcdreg |
> ++
> | Interface (SPI, I2C, parallel) |
> ++
> 
> 
> Noralf Trønnes (5):
>   drm: Add DRM support for tiny LCD displays
>   drm/tinydrm: Add lcd register abstraction
>   drm/tinydrm/lcdreg: Add SPI support
>   drm/tinydrm: Add mipi-dbi support
>   drm/tinydrm: Add support for several Adafruit TFT displays
> 
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/tinydrm/Kconfig|  27 +
>  drivers/gpu/drm/tinydrm/Makefile   |   8 +
>  drivers/gpu/drm/tinydrm/adafruit-tft.c | 256 
>  drivers/gpu/drm/tinydrm/core/Makefile  |   8 +
>  drivers/gpu/drm/tinydrm/core/internal.h|  43 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 194 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c| 203 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c| 116 
>  drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c   | 345 ++
>  drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c | 112 
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  97 +++
>  drivers/gpu/drm/tinydrm/core/tinydrm-plane.c   |  50 ++
>  drivers/gpu/drm/tinydrm/lcdreg/Kconfig |   8 +
>  drivers/gpu/drm/tinydrm/lcdreg/Makefile|   5 +
>  drivers/gpu/drm/tinydrm/lcdreg/internal.h  |   8 +
>  drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c   | 190 ++
>  drivers/gpu/drm/tinydrm/lcdreg/lcdreg-debugfs.c| 281 
>  drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c| 720 
> +
>  drivers/gpu/drm/tinydrm/mipi-dbi.c | 231 +++
>  include/drm/tinydrm/ili9340.h  |  85 +++
>  include/drm/tinydrm/lcdreg-spi.h   |  63 ++
>  include/drm/tinydrm/lcdreg.h   | 126 
>  include/drm/tinydrm/mipi-dbi.h |  24 +
>  include/drm/tinydrm/tinydrm.h  | 142 
>  26 files changed, 3345 insertions(+)
>  create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
>  create mode 100644 drivers/gpu/drm/tinydrm/Makefile
>  create mode 100644 drivers/gpu/drm/tinydrm/adafruit-tft.c
>  create 

[PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-03-16 Thread Lyude Paul
On Wed, 2016-03-16 at 21:39 +0200, Ville Syrjälä wrote:
> On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> > 
> > After unplugging a DP MST display from the system, we have to go through
> > and destroy all of the DRM connectors associated with it since none of
> > them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> > doesn't do a good enough job of ensuring that throughout the destruction
> > process that no modesettings can be done with the connectors. As it is
> > right now, intel_dp_destroy_mst_connector() works like this:
> > 
> > * Take all modeset locks
> > * Clear the configuration of the crtc on the connector, if there is one
> > * Drop all modeset locks, this is required because of circular
> >   dependency issues that arise with trying to remove the connector from
> >   sysfs with modeset locks held
> > * Unregister the connector
> > * Take all modeset locks, again
> > * Do the rest of the required cleaning for destroying the connector
> > * Finally drop all modeset locks for good
> So pretty much what I suspected
> https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html
> 
> > 
> > 
> > This only works sometimes. During the destruction process, it's very
> > possible that a userspace application will attempt to do a modesetting
> > using the connector. When we drop the modeset locks, an ioctl handler
> > such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> > locks from us. When this happens, one thing leads to another and
> > eventually we end up committing a mode with the non-existent connector:
> > 
> > [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to
> > enable link training
> > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel
> > equalization
> > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> > 
> > And in some cases, such as with the T460s using an MST dock, this
> > results in breaking modesetting and/or panicking the system.
> Are these just kernel oopses etc.? If the hardware gets upset from
> modesetting when the sink is gone, well, then we still have a problem
> because the user can of course yank the cable while the modeset is already
> underway.
It is more then that. Unfortunately though, fixing that part is not as easy. We
never expect an atomic modesetting commit to fail, but unfortunately any code
having to do with turning on DP MST has the chance of failing and we turn on DP
MST during commits. So fixing that would take moving quite a bit of code around.

> 
> > 
> > 
> > To work around this, we now unregister the connector at the very
> > beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> > locks, and then hold them until we finish the rest of the function.
> > 
> > CC: stable at vger.kernel.org
> > Signed-off-by: Lyude 
> > Signed-off-by: Rob Clark 
> These sobs don't make much sense to me.
I should have mentioned that Rob Clark was the one who came up with the idea of
just moving the connector->unregister() call to the top of the function.

> 
> Patch itself does make sense to me, so 
> Reviewed-by: Ville Syrjälä 
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index fa0dabf..b21ac88 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct
> > drm_dp_mst_topology_mgr *mgr,
> >    struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> >    struct drm_device *dev = connector->dev;
> >  
> > +   intel_connector->unregister(intel_connector);
> > +
> >    /* need to nuke the connector */
> >    drm_modeset_lock_all(dev);
> >    if (connector->state->crtc) {
> > @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> > drm_dp_mst_topology_mgr *mgr,
> >  
> >    WARN(ret, "Disabling mst crtc failed with %i\n", ret);
> >    }
> > -   drm_modeset_unlock_all(dev);
> >  
> > -   intel_connector->unregister(intel_connector);
> > -
> > -   drm_modeset_lock_all(dev);
> >    intel_connector_remove_from_fbdev(intel_connector);
> >    drm_connector_cleanup(connector);
> >    drm_modeset_unlock_all(dev);
> > -- 
> > 2.5.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-03-16 Thread Lyude
After unplugging a DP MST display from the system, we have to go through
and destroy all of the DRM connectors associated with it since none of
them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
doesn't do a good enough job of ensuring that throughout the destruction
process that no modesettings can be done with the connectors. As it is
right now, intel_dp_destroy_mst_connector() works like this:

* Take all modeset locks
* Clear the configuration of the crtc on the connector, if there is one
* Drop all modeset locks, this is required because of circular
  dependency issues that arise with trying to remove the connector from
  sysfs with modeset locks held
* Unregister the connector
* Take all modeset locks, again
* Do the rest of the required cleaning for destroying the connector
* Finally drop all modeset locks for good

This only works sometimes. During the destruction process, it's very
possible that a userspace application will attempt to do a modesetting
using the connector. When we drop the modeset locks, an ioctl handler
such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
locks from us. When this happens, one thing leads to another and
eventually we end up committing a mode with the non-existent connector:

[drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to 
enable link training
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel 
equalization
[drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
[drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi

And in some cases, such as with the T460s using an MST dock, this
results in breaking modesetting and/or panicking the system.

To work around this, we now unregister the connector at the very
beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
locks, and then hold them until we finish the rest of the function.

CC: stable at vger.kernel.org
Signed-off-by: Lyude 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index fa0dabf..b21ac88 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector->dev;

+   intel_connector->unregister(intel_connector);
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
if (connector->state->crtc) {
@@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,

WARN(ret, "Disabling mst crtc failed with %i\n", ret);
}
-   drm_modeset_unlock_all(dev);

-   intel_connector->unregister(intel_connector);
-
-   drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
drm_connector_cleanup(connector);
drm_modeset_unlock_all(dev);
-- 
2.5.0



[PATCH v3 2/2] drm: bridge: add sii902x DT bindings doc

2016-03-16 Thread Boris Brezillon
Add Sii9022 DT bindings description.

Signed-off-by: Boris Brezillon 
---
Changes since v1:
- rename doc file
- s/sil902/sii902/
---
 .../devicetree/bindings/display/bridge/sii902x.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii902x.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
new file mode 100644
index 000..e8d0ffa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
@@ -0,0 +1,35 @@
+sii902x HDMI bridge bindings
+
+Required properties:
+   - compatible: "sil,sii9022"
+   - reg: i2c address of the bridge
+   - reset-gpios: OF device-tree gpio specification for RST_N pin.
+
+Optional properties:
+   - interrupts-extended or interrupt-parent + interrupts: describe
+ the interrupt line used to inform the host about hotplug events.
+
+Optional subnodes:
+   - video input: this subnode can contain a video input port node
+ to connect the bridge to a display controller output (See this
+ documentation [1]).
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   hdmi-bridge at 39 {
+   compatible = "sil,sii9022";
+   reg = <0x39>;
+   reset-gpios = <&pioA 1 0>;
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   bridge_in: endpoint {
+   remote-endpoint = <&dc_out>;
+   };
+   };
+   };
+   };
-- 
2.5.0



[PATCH v3 1/2] drm: bridge: Add sii902x driver

2016-03-16 Thread Boris Brezillon
Add basic support for the sii902x RGB -> HDMI bridge.
This driver does not support audio output yet.

Signed-off-by: Boris Brezillon 
Tested-by: Nicolas Ferre 
---
Hello,

This patch is only adding basic support for the sii9022 chip.
As stated in the commit log, there's no audio support, but the
driver also hardcodes a lot of things (like the RGB input format to
use).
There are two reasons for this:
1/ the DRM framework does not allow for advanced link description
   between an encoder and a bridge (that's for the RGB format
   limitation). Any idea how this should be described?

2/ I don't have the datasheet of this HDMI encoder, and all logic
   has been extracted from those two drivers [1][2], which means
   I may miss some important things in my encoder setup.

Another thing I find weird in the drm_bridge interface is the fact
that we have a ->attach() method, but no ->detach(), which can be
a problem if we allow drm bridges and KMS drivers to be compiled as
modules. Any reason for that?

That's all for the questions part :-).

Best Regards,

Boris

Changes in v3:
- fix get_modes() implementation to avoid turning the screen in power
  save mode
- rename the driver (sil902x -> sii902x)

Changes in v2:
- fix errors reported by the kbuild robot
---
 drivers/gpu/drm/bridge/Kconfig   |   8 +
 drivers/gpu/drm/bridge/Makefile  |   1 +
 drivers/gpu/drm/bridge/sii902x.c | 479 +++
 3 files changed, 488 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/sii902x.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..fd463ea 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_SII902X
+   tristate "Silicon Image sii902x RGB/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   ---help---
+ Silicon Image sii902x bridge chip driver.
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..7144de3 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
new file mode 100644
index 000..4bcb84c
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -0,0 +1,479 @@
+/*
+ * Copyright (C) 2014 Atmel
+ *   Bo Shen 
+ *
+ * Authors:  Bo Shen 
+ *   Boris Brezillon 
+ *   Wu, Songjun 
+ *
+ *
+ * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SIL902X_TPI_VIDEO_DATA 0x0
+
+#define SIL902X_TPI_PIXEL_REPETITION   0x8
+#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
+#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
+#define SIL902X_TPI_AVI_PIXEL_REP_4X   3
+#define SIL902X_TPI_AVI_PIXEL_REP_2X   1
+#define SIL902X_TPI_AVI_PIXEL_REP_NONE 0
+#define SIL902X_TPI_CLK_RATIO_HALF (0 << 6)
+#define SIL902X_TPI_CLK_RATIO_1X   (1 << 6)
+#define SIL902X_TPI_CLK_RATIO_2X   (2 << 6)
+#define SIL902X_TPI_CLK_RATIO_4X   (3 << 6)
+
+#define SIL902X_TPI_AVI_IN_FORMAT  0x9
+#define SIL902X_TPI_AVI_INPUT_BITMODE_12BITBIT(7)
+#define SIL902X_TPI_AVI_INPUT_DITHER   BIT(6)
+#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED(2 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_FULL   (1 << 2)
+#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO   (0 << 2)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK (3 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422(2 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444(1 << 0)
+#define SIL902X_TPI_AVI_INPUT_COLORSPACE_RGB   (0 << 0)
+
+#define SIL902X_TPI_AVI_INFOFRAME  0x0c
+
+#define SIL902X_SYS_CTRL_DATA  0x1a
+#define SIL902X_SYS_CTRL_PWR_DWN   BIT(4)
+#define SIL902X_SYS_CTRL_AV_MUTE  

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

2016-03-16 Thread Robin Murphy
In the absence of an fb_mmap callback, the fbdev code falls back to a
naive implementation which relies upon the DMA address being the same
as the physical address, and the buffer being physically contiguous
from there. Whilst this often holds for standard CMA allocations via
the platform's regular DMA ops, if the allocation is provided by an
IOMMU then such assumptions can fall apart spectacularly.

To resolve this, reroute the fb_mmap call to the appropriate DMA API
implementation, as per the other cma_helper calls.

Signed-off-by: Robin Murphy 
---

Hi dri-devel,

This is an empirical fix for something I tickled via the newly-added
ARM HDLCD driver on a Juno platform - I have no idea whatsoever about
how "proper" it is in terms of the DRM infrastructure, so feel free to
treat this as a bug report rather than an actual patch if appropriate ;)

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

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index bb88e3d..117d7ea 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 struct drm_fb_cma {
@@ -221,6 +222,12 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
 EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
 #endif

+static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   return dma_mmap_writecombine(info->device, vma, info->screen_base,
+info->fix.smem_start, info->fix.smem_len);
+}
+
 static struct fb_ops drm_fbdev_cma_ops = {
.owner  = THIS_MODULE,
.fb_fillrect= drm_fb_helper_sys_fillrect,
@@ -231,6 +238,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
.fb_blank   = drm_fb_helper_blank,
.fb_pan_display = drm_fb_helper_pan_display,
.fb_setcmap = drm_fb_helper_setcmap,
+   .fb_mmap= drm_fb_cma_mmap,
 };

 static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
-- 
2.7.3.dirty



[PATCH v2 9/9] drm: atmel-hlcdc: route DMA accesses through AHB interfaces

2016-03-16 Thread Boris Brezillon
In relation with the actuall bandwidth consumed on a DMA Source interface,
choose the less used one for a created plane.

Signed-off-by: Boris Brezillon 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c  |  6 +++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 43 +++--
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index cbba029..14e74e5 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -319,7 +319,11 @@ static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc 
*c,
if (ret)
return ret;

-   return atmel_hlcdc_plane_prepare_disc_area(s);
+   ret = atmel_hlcdc_plane_prepare_disc_area(s);
+   if (ret)
+   return ret;
+
+   return atmel_hlcdc_plane_prepare_ahb_routing(s);
 }

 static void atmel_hlcdc_crtc_atomic_begin(struct drm_crtc *c,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 302c958..c71a300 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -165,6 +165,7 @@ struct atmel_hlcdc_planes *
 atmel_hlcdc_create_planes(struct drm_device *dev);

 int atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state);
+int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state);

 void atmel_hlcdc_crtc_irq(struct drm_crtc *c);

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 35027d0..0995eef 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -58,6 +58,8 @@ struct atmel_hlcdc_plane_state {
int disc_w;
int disc_h;

+   int ahb_id;
+
/* These fields are private and should not be touched */
int bpp[ATMEL_HLCDC_MAX_PLANES];
unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
@@ -359,8 +361,10 @@ atmel_hlcdc_plane_update_general_settings(struct 
atmel_hlcdc_plane *plane,

atmel_hlcdc_layer_update_cfg(&plane->layer,
 ATMEL_HLCDC_LAYER_DMA_CFG_ID,
-ATMEL_HLCDC_LAYER_DMA_BLEN_MASK,
-ATMEL_HLCDC_LAYER_DMA_BLEN_INCR16);
+ATMEL_HLCDC_LAYER_DMA_BLEN_MASK |
+ATMEL_HLCDC_LAYER_DMA_SIF,
+ATMEL_HLCDC_LAYER_DMA_BLEN_INCR16 |
+state->ahb_id);

atmel_hlcdc_layer_update_cfg(&plane->layer, layout->general_config,
 ATMEL_HLCDC_LAYER_ITER2BL |
@@ -435,6 +439,41 @@ static void atmel_hlcdc_plane_update_buffers(struct 
atmel_hlcdc_plane *plane,
}
 }

+int atmel_hlcdc_plane_prepare_ahb_routing(struct drm_crtc_state *c_state)
+{
+   unsigned int ahb_load[2] = { };
+   struct drm_plane *plane;
+
+   drm_atomic_crtc_state_for_each_plane(plane, c_state) {
+   struct atmel_hlcdc_plane_state *plane_state;
+   struct drm_plane_state *plane_s;
+   unsigned int pixels, load = 0;
+   int i;
+
+   plane_s = drm_atomic_get_plane_state(c_state->state, plane);
+   if (IS_ERR(plane_s))
+   return PTR_ERR(plane_s);
+
+   plane_state =
+   drm_plane_state_to_atmel_hlcdc_plane_state(plane_s);
+
+   pixels = (plane_state->src_w * plane_state->src_h) -
+(plane_state->disc_w * plane_state->disc_h);
+
+   for (i = 0; i < plane_state->nplanes; i++)
+   load += pixels * plane_state->bpp[i];
+
+   if (ahb_load[0] <= ahb_load[1])
+   plane_state->ahb_id = 0;
+   else
+   plane_state->ahb_id = 1;
+
+   ahb_load[plane_state->ahb_id] += load;
+   }
+
+   return 0;
+}
+
 int
 atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state *c_state)
 {
-- 
2.5.0



[PATCH v2 8/9] drm: atmel-hlcdc: check display mode validity in crtc->mode_fixup()

2016-03-16 Thread Boris Brezillon
Move the adjusted display mode check into ->mode_fixup().

Signed-off-by: Boris Brezillon 
Acked-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 12ec204..cbba029 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -142,11 +142,13 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
drm_crtc *c)
   cfg);
 }

-static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *crtc,
+static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *c,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
-   return true;
+   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+
+   return atmel_hlcdc_dc_mode_valid(crtc->dc, adjusted_mode) == MODE_OK;
 }

 static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
@@ -311,12 +313,8 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
drm_crtc_state *state)
 static int atmel_hlcdc_crtc_atomic_check(struct drm_crtc *c,
 struct drm_crtc_state *s)
 {
-   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
int ret;

-   if (atmel_hlcdc_dc_mode_valid(crtc->dc, &s->adjusted_mode) != MODE_OK)
-   return -EINVAL;
-
ret = atmel_hlcdc_crtc_select_output_mode(s);
if (ret)
return ret;
-- 
2.5.0



[PATCH v2 7/9] drm: atmel-hlcdc: rework the output code to support drm bridges

2016-03-16 Thread Boris Brezillon
The current output code only supports connection to drm panels.
First simplify the drm panel code, and then add support for external drm
bridges.

Signed-off-by: Boris Brezillon 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 193 +--
 2 files changed, 113 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 930d603..b33f19d 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -551,7 +551,7 @@ static int atmel_hlcdc_dc_modeset_init(struct drm_device 
*dev)

ret = atmel_hlcdc_create_outputs(dev);
if (ret) {
-   dev_err(dev->dev, "failed to create panel: %d\n", ret);
+   dev_err(dev->dev, "failed to create HLCDC outputs: %d\n", ret);
return ret;
}

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 75237b5..39802c0 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -34,11 +34,13 @@
  * @connector: DRM connector
  * @encoder: DRM encoder
  * @dc: pointer to the atmel_hlcdc_dc structure
+ * @panel: panel connected on the RGB output
  */
 struct atmel_hlcdc_rgb_output {
struct drm_connector connector;
struct drm_encoder encoder;
struct atmel_hlcdc_dc *dc;
+   struct drm_panel *panel;
 };

 static inline struct atmel_hlcdc_rgb_output *
@@ -54,46 +56,31 @@ drm_encoder_to_atmel_hlcdc_rgb_output(struct drm_encoder 
*encoder)
return container_of(encoder, struct atmel_hlcdc_rgb_output, encoder);
 }

-/**
- * Atmel HLCDC Panel device structure
- *
- * This structure is specialization of the slave device structure to
- * interface with drm panels.
- *
- * @base: base slave device fields
- * @panel: drm panel attached to this slave device
- */
-struct atmel_hlcdc_panel {
-   struct atmel_hlcdc_rgb_output base;
-   struct drm_panel *panel;
-};
-
-static inline struct atmel_hlcdc_panel *
-atmel_hlcdc_rgb_output_to_panel(struct atmel_hlcdc_rgb_output *output)
-{
-   return container_of(output, struct atmel_hlcdc_panel, base);
-}
-
-static void atmel_hlcdc_panel_encoder_enable(struct drm_encoder *encoder)
+static void atmel_hlcdc_rgb_encoder_enable(struct drm_encoder *encoder)
 {
struct atmel_hlcdc_rgb_output *rgb =
drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
-   struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);
-   drm_panel_enable(panel->panel);
+
+   if (rgb->panel) {
+   drm_panel_prepare(rgb->panel);
+   drm_panel_enable(rgb->panel);
+   }
 }

-static void atmel_hlcdc_panel_encoder_disable(struct drm_encoder *encoder)
+static void atmel_hlcdc_rgb_encoder_disable(struct drm_encoder *encoder)
 {
struct atmel_hlcdc_rgb_output *rgb =
drm_encoder_to_atmel_hlcdc_rgb_output(encoder);
-   struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);

-   drm_panel_disable(panel->panel);
+   if (rgb->panel) {
+   drm_panel_disable(rgb->panel);
+   drm_panel_unprepare(rgb->panel);
+   }
 }

 static const struct drm_encoder_helper_funcs 
atmel_hlcdc_panel_encoder_helper_funcs = {
-   .disable = atmel_hlcdc_panel_encoder_disable,
-   .enable = atmel_hlcdc_panel_encoder_enable,
+   .disable = atmel_hlcdc_rgb_encoder_disable,
+   .enable = atmel_hlcdc_rgb_encoder_enable,
 };

 static void atmel_hlcdc_rgb_encoder_destroy(struct drm_encoder *encoder)
@@ -110,9 +97,11 @@ static int atmel_hlcdc_panel_get_modes(struct drm_connector 
*connector)
 {
struct atmel_hlcdc_rgb_output *rgb =
drm_connector_to_atmel_hlcdc_rgb_output(connector);
-   struct atmel_hlcdc_panel *panel = atmel_hlcdc_rgb_output_to_panel(rgb);

-   return panel->panel->funcs->get_modes(panel->panel);
+   if (rgb->panel)
+   return rgb->panel->funcs->get_modes(rgb->panel);
+
+   return 0;
 }

 static int atmel_hlcdc_rgb_mode_valid(struct drm_connector *connector,
@@ -144,7 +133,13 @@ static const struct drm_connector_helper_funcs 
atmel_hlcdc_panel_connector_helpe
 static enum drm_connector_status
 atmel_hlcdc_panel_connector_detect(struct drm_connector *connector, bool force)
 {
-   return connector_status_connected;
+   struct atmel_hlcdc_rgb_output *rgb =
+   drm_connector_to_atmel_hlcdc_rgb_output(connector);
+
+   if (rgb->panel)
+   return connector_status_connected;
+
+   return connector_status_disconnected;
 }

 static void
@@ -152,9 +147,10 @@ atmel_hlcdc_panel_connector_destroy(struct drm_connector 
*connector)
 {
struct atmel_hlcdc_rgb_output *rgb =
  

[PATCH v2 6/9] drm: atmel-hlcdc: move output mode selection in CRTC implementation

2016-03-16 Thread Boris Brezillon
In order to support multiple outputs we need to move the output mode
selection to the CRTC object, so that the output validity check can be
done against the drm_atomic_state.

If the connectors selected by a specific mode setting are requiring
incompatible bus format the atomic operation is aborted (->atomic_check()
returns -EINVAL).

In order to implement that, we need to define our own CRTC state and
overload default ->reset(), ->atomic_duplicate_state() and
->atomic_destroy_state() functions.

Signed-off-by: Boris Brezillon 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 140 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |   3 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |   3 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c |  46 
 4 files changed, 142 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9863291..12ec204 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -32,6 +32,23 @@
 #include "atmel_hlcdc_dc.h"

 /**
+ * Atmel HLCDC CRTC state structure
+ *
+ * @base: base CRTC state
+ * @output_mode: RGBXXX output mode
+ */
+struct atmel_hlcdc_crtc_state {
+   struct drm_crtc_state base;
+   unsigned int output_mode;
+};
+
+static inline struct atmel_hlcdc_crtc_state *
+drm_crtc_state_to_atmel_hlcdc_crtc_state(struct drm_crtc_state *state)
+{
+   return container_of(state, struct atmel_hlcdc_crtc_state, base);
+}
+
+/**
  * Atmel HLCDC CRTC structure
  *
  * @base: base DRM CRTC structure
@@ -59,6 +76,7 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc *c)
struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
struct regmap *regmap = crtc->dc->hlcdc->regmap;
struct drm_display_mode *adj = &c->state->adjusted_mode;
+   struct atmel_hlcdc_crtc_state *state;
unsigned long mode_rate;
struct videomode vm;
unsigned long prate;
@@ -112,12 +130,15 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
drm_crtc *c)
if (adj->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= ATMEL_HLCDC_HSPOL;

+   state = drm_crtc_state_to_atmel_hlcdc_crtc_state(c->state);
+   cfg |= state->output_mode << 8;
+
regmap_update_bits(regmap, ATMEL_HLCDC_CFG(5),
   ATMEL_HLCDC_HSPOL | ATMEL_HLCDC_VSPOL |
   ATMEL_HLCDC_VSPDLYS | ATMEL_HLCDC_VSPDLYE |
   ATMEL_HLCDC_DISPPOL | ATMEL_HLCDC_DISPDLY |
   ATMEL_HLCDC_VSPSU | ATMEL_HLCDC_VSPHO |
-  ATMEL_HLCDC_GUARDTIME_MASK,
+  ATMEL_HLCDC_GUARDTIME_MASK | ATMEL_HLCDC_MODE_MASK,
   cfg);
 }

@@ -228,14 +249,78 @@ void atmel_hlcdc_crtc_resume(struct drm_crtc *c)
}
 }

+#define ATMEL_HLCDC_RGB444_OUTPUT  BIT(0)
+#define ATMEL_HLCDC_RGB565_OUTPUT  BIT(1)
+#define ATMEL_HLCDC_RGB666_OUTPUT  BIT(2)
+#define ATMEL_HLCDC_RGB888_OUTPUT  BIT(3)
+#define ATMEL_HLCDC_OUTPUT_MODE_MASK   GENMASK(3, 0)
+
+static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
+{
+   unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
+   struct atmel_hlcdc_crtc_state *hstate;
+   struct drm_connector_state *cstate;
+   struct drm_connector *connector;
+   struct atmel_hlcdc_crtc *crtc;
+   int i;
+
+   crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
+
+   for_each_connector_in_state(state->state, connector, cstate, i) {
+   struct drm_display_info *info = &connector->display_info;
+   unsigned int supported_fmts = 0;
+   int j;
+
+   if (!cstate->crtc)
+   continue;
+
+   for (j = 0; j < info->num_bus_formats; j++) {
+   switch (info->bus_formats[j]) {
+   case MEDIA_BUS_FMT_RGB444_1X12:
+   supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
+   break;
+   case MEDIA_BUS_FMT_RGB565_1X16:
+   supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
+   break;
+   case MEDIA_BUS_FMT_RGB666_1X18:
+   supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
+   break;
+   default:
+   break;
+   }
+   }
+
+   if (crtc->dc->desc->conflicting_output_formats)
+   output_fmts &= supported_fmts;
+   else
+   output_fmts |= suppor

[PATCH v2 5/9] drm: atmel-hlcdc: support extended timing ranges on sama5d4 and sama5d2

2016-03-16 Thread Boris Brezillon
The display timings on old SoCs older than the sama5d4 are quite limited
and prevent the use of many displays. Add support for extended timing
ranges on sama5d2 and sama5d4.

Signed-off-by: Boris Brezillon 
Acked-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 24 ++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  6 ++
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 851b4a0..70006a3 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -50,6 +50,9 @@ static const struct atmel_hlcdc_dc_desc 
atmel_hlcdc_dc_at91sam9n12 = {
.min_height = 0,
.max_width = 1280,
.max_height = 860,
+   .max_spw = 0x3f,
+   .max_vpw = 0x3f,
+   .max_hpw = 0xff,
.nlayers = ARRAY_SIZE(atmel_hlcdc_at91sam9n12_layers),
.layers = atmel_hlcdc_at91sam9n12_layers,
 };
@@ -134,6 +137,9 @@ static const struct atmel_hlcdc_dc_desc 
atmel_hlcdc_dc_at91sam9x5 = {
.min_height = 0,
.max_width = 800,
.max_height = 600,
+   .max_spw = 0x3f,
+   .max_vpw = 0x3f,
+   .max_hpw = 0xff,
.nlayers = ARRAY_SIZE(atmel_hlcdc_at91sam9x5_layers),
.layers = atmel_hlcdc_at91sam9x5_layers,
 };
@@ -237,6 +243,9 @@ static const struct atmel_hlcdc_dc_desc 
atmel_hlcdc_dc_sama5d3 = {
.min_height = 0,
.max_width = 2048,
.max_height = 2048,
+   .max_spw = 0x3f,
+   .max_vpw = 0x3f,
+   .max_hpw = 0x1ff,
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d3_layers),
.layers = atmel_hlcdc_sama5d3_layers,
 };
@@ -320,6 +329,9 @@ static const struct atmel_hlcdc_dc_desc 
atmel_hlcdc_dc_sama5d4 = {
.min_height = 0,
.max_width = 2048,
.max_height = 2048,
+   .max_spw = 0xff,
+   .max_vpw = 0xff,
+   .max_hpw = 0x3ff,
.nlayers = ARRAY_SIZE(atmel_hlcdc_sama5d4_layers),
.layers = atmel_hlcdc_sama5d4_layers,
 };
@@ -358,19 +370,19 @@ int atmel_hlcdc_dc_mode_valid(struct atmel_hlcdc_dc *dc,
int hback_porch = mode->htotal - mode->hsync_end;
int hsync_len = mode->hsync_end - mode->hsync_start;

-   if (hsync_len > 0x40 || hsync_len < 1)
+   if (hsync_len > dc->desc->max_spw + 1 || hsync_len < 1)
return MODE_HSYNC;

-   if (vsync_len > 0x40 || vsync_len < 1)
+   if (vsync_len > dc->desc->max_spw + 1 || vsync_len < 1)
return MODE_VSYNC;

-   if (hfront_porch > 0x200 || hfront_porch < 1 ||
-   hback_porch > 0x200 || hback_porch < 1 ||
+   if (hfront_porch > dc->desc->max_hpw + 1 || hfront_porch < 1 ||
+   hback_porch > dc->desc->max_hpw + 1 || hback_porch < 1 ||
mode->hdisplay < 1)
return MODE_H_ILLEGAL;

-   if (vfront_porch > 0x40 || vfront_porch < 1 ||
-   vback_porch > 0x40 || vback_porch < 0 ||
+   if (vfront_porch > dc->desc->max_vpw + 1 || vfront_porch < 1 ||
+   vback_porch > dc->desc->max_vpw || vback_porch < 0 ||
mode->vdisplay < 1)
return MODE_V_ILLEGAL;

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 53b4488..23521ba 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -50,6 +50,9 @@
  * @min_height: minimum height supported by the Display Controller
  * @max_width: maximum width supported by the Display Controller
  * @max_height: maximum height supported by the Display Controller
+ * @max_spw: maximum vertical/horizontal pulse width
+ * @max_vpw: maximum vertical back/front porch width
+ * @max_hpw: maximum horizontal back/front porch width
  * @layers: a layer description table describing available layers
  * @nlayers: layer description table size
  */
@@ -58,6 +61,9 @@ struct atmel_hlcdc_dc_desc {
int min_height;
int max_width;
int max_height;
+   int max_spw;
+   int max_vpw;
+   int max_hpw;
const struct atmel_hlcdc_layer_desc *layers;
int nlayers;
 };
-- 
2.5.0



[PATCH v2 4/9] drm: atmel-hlcdc: remove leftovers from atomic mode setting migration

2016-03-16 Thread Boris Brezillon
The ->dpms field is no longer used and can be removed.
The same goes for the dummy ->mode_fixup() implementation which always
returns true.

Signed-off-by: Boris Brezillon 
Acked-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 49494e9..2255dc9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -44,13 +44,11 @@ enum atmel_hlcdc_connector_rgb_mode {
  * @connector: DRM connector
  * @encoder: DRM encoder
  * @dc: pointer to the atmel_hlcdc_dc structure
- * @dpms: current DPMS mode
  */
 struct atmel_hlcdc_rgb_output {
struct drm_connector connector;
struct drm_encoder encoder;
struct atmel_hlcdc_dc *dc;
-   int dpms;
 };

 static inline struct atmel_hlcdc_rgb_output *
@@ -104,14 +102,6 @@ static void atmel_hlcdc_panel_encoder_disable(struct 
drm_encoder *encoder)
drm_panel_disable(panel->panel);
 }

-static bool
-atmel_hlcdc_panel_encoder_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
-{
-   return true;
-}
-
 static void
 atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder *encoder,
 struct drm_display_mode *mode,
@@ -147,7 +137,6 @@ atmel_hlcdc_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
 }

 static const struct drm_encoder_helper_funcs 
atmel_hlcdc_panel_encoder_helper_funcs = {
-   .mode_fixup = atmel_hlcdc_panel_encoder_mode_fixup,
.mode_set = atmel_hlcdc_rgb_encoder_mode_set,
.disable = atmel_hlcdc_panel_encoder_disable,
.enable = atmel_hlcdc_panel_encoder_enable,
@@ -248,7 +237,6 @@ static int atmel_hlcdc_create_panel_output(struct 
drm_device *dev,
if (!panel)
return -EINVAL;

-   panel->base.dpms = DRM_MODE_DPMS_OFF;

panel->base.dc = dc;

-- 
2.5.0



[PATCH v2 3/9] drm: atmel-hlcdc: fix connector and encoder types

2016-03-16 Thread Boris Brezillon
The hlcdc IP keep the pixel stream in raw RGB mode, and does not provide
any specific connector. Since DRM_MODE_CONNECTOR_RAW_RGB does not exist,
use DRM_MODE_CONNECTOR_Unknown.

Signed-off-by: Boris Brezillon 
Acked-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 0f7ec01..49494e9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -256,7 +256,7 @@ static int atmel_hlcdc_create_panel_output(struct 
drm_device *dev,
   &atmel_hlcdc_panel_encoder_helper_funcs);
ret = drm_encoder_init(dev, &panel->base.encoder,
   &atmel_hlcdc_panel_encoder_funcs,
-  DRM_MODE_ENCODER_LVDS, NULL);
+  DRM_MODE_ENCODER_NONE, NULL);
if (ret)
return ret;

@@ -266,7 +266,7 @@ static int atmel_hlcdc_create_panel_output(struct 
drm_device *dev,
 &atmel_hlcdc_panel_connector_helper_funcs);
ret = drm_connector_init(dev, &panel->base.connector,
 &atmel_hlcdc_panel_connector_funcs,
-DRM_MODE_CONNECTOR_LVDS);
+DRM_MODE_CONNECTOR_Unknown);
if (ret)
goto err_encoder_cleanup;

-- 
2.5.0



[PATCH v2 2/9] drm: atmel-hlcdc: support asynchronous atomic commit operations

2016-03-16 Thread Boris Brezillon
drm_atomic_helper_commit() does not support asynchronous commits.
Replace it by a specific commit function supporting these kind of requests.

Signed-off-by: Boris Brezillon 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 94 +++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  5 ++
 2 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 3d8d164..851b4a0 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -427,11 +427,102 @@ static void atmel_hlcdc_fb_output_poll_changed(struct 
drm_device *dev)
}
 }

+struct atmel_hlcdc_dc_commit {
+   struct work_struct work;
+   struct drm_device *dev;
+   struct drm_atomic_state *state;
+};
+
+static void
+atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit)
+{
+   struct drm_device *dev = commit->dev;
+   struct atmel_hlcdc_dc *dc = dev->dev_private;
+   struct drm_atomic_state *old_state = commit->state;
+
+   /* Apply the atomic update. */
+   drm_atomic_helper_commit_modeset_disables(dev, old_state);
+   drm_atomic_helper_commit_planes(dev, old_state, false);
+   drm_atomic_helper_commit_modeset_enables(dev, old_state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, old_state);
+
+   drm_atomic_helper_cleanup_planes(dev, old_state);
+
+   drm_atomic_state_free(old_state);
+
+   /* Complete the commit, wake up any waiter. */
+   spin_lock(&dc->commit.wait.lock);
+   dc->commit.pending = false;
+   wake_up_all_locked(&dc->commit.wait);
+   spin_unlock(&dc->commit.wait.lock);
+
+   kfree(commit);
+}
+
+static void atmel_hlcdc_dc_atomic_work(struct work_struct *work)
+{
+   struct atmel_hlcdc_dc_commit *commit =
+   container_of(work, struct atmel_hlcdc_dc_commit, work);
+
+   atmel_hlcdc_dc_atomic_complete(commit);
+}
+
+static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev,
+   struct drm_atomic_state *state,
+   bool async)
+{
+   struct atmel_hlcdc_dc *dc = dev->dev_private;
+   struct atmel_hlcdc_dc_commit *commit;
+   int ret;
+
+   ret = drm_atomic_helper_prepare_planes(dev, state);
+   if (ret)
+   return ret;
+
+   /* Allocate the commit object. */
+   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
+   if (!commit) {
+   ret = -ENOMEM;
+   goto error;
+   }
+
+   INIT_WORK(&commit->work, atmel_hlcdc_dc_atomic_work);
+   commit->dev = dev;
+   commit->state = state;
+
+   spin_lock(&dc->commit.wait.lock);
+   ret = wait_event_interruptible_locked(dc->commit.wait,
+ !dc->commit.pending);
+   if (ret == 0)
+   dc->commit.pending = true;
+   spin_unlock(&dc->commit.wait.lock);
+
+   if (ret) {
+   kfree(commit);
+   goto error;
+   }
+
+   /* Swap the state, this is the point of no return. */
+   drm_atomic_helper_swap_state(dev, state);
+
+   if (async)
+   queue_work(dc->wq, &commit->work);
+   else
+   atmel_hlcdc_dc_atomic_complete(commit);
+
+   return 0;
+
+error:
+   drm_atomic_helper_cleanup_planes(dev, state);
+   return ret;
+}
+
 static const struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = atmel_hlcdc_fb_create,
.output_poll_changed = atmel_hlcdc_fb_output_poll_changed,
.atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   .atomic_commit = atmel_hlcdc_dc_atomic_commit,
 };

 static int atmel_hlcdc_dc_modeset_init(struct drm_device *dev)
@@ -509,6 +600,7 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
if (!dc->wq)
return -ENOMEM;

+   init_waitqueue_head(&dc->commit.wait);
dc->desc = match->data;
dc->hlcdc = dev_get_drvdata(dev->dev->parent);
dev->dev_private = dc;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index ec64140..53b4488 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -130,6 +130,7 @@ struct atmel_hlcdc_planes {
  * @planes: instantiated planes
  * @layers: active HLCDC layer
  * @wq: display controller workqueue
+ * @commit: used for async commit handling
  */
 struct atmel_hlcdc_dc {
const struct atmel_hlcdc_dc_desc *desc;
@@ -139,6 +140,10 @@ struct atmel_hlcdc_dc {
struct atmel_hlcdc_planes *planes;
struct atmel_hlcdc_layer *layers[ATMEL_HLCDC_MAX_LAYERS];
struct workqueue_struct *wq;
+   struct {
+   wait_queue_head_t wait;
+   bool pending;
+   } commit;
 };

[PATCH v2 1/9] drm: atmel-hlcdc: add a ->cleanup_fb() operation

2016-03-16 Thread Boris Brezillon
Add a ->cleanup_fb() operation to avoid memory leaks when the atomic
operation is interrupted after the ->prepare_fb() call.

Signed-off-by: Boris Brezillon 
Fixes 2389fc1 ("drm: atmel-hlcdc: Atomic mode-setting conversion")
Reviewed-by: Nicolas Ferre 
Tested-by: Nicolas Ferre 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  2 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +++---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index fed517f..ec64140 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -81,11 +81,13 @@ struct atmel_hlcdc_plane_properties {
  * @layer: HLCDC layer structure
  * @properties: pointer to the property definitions structure
  * @rotation: current rotation status
+ * @prepared: flagging the plane has prepared for an atomic update
  */
 struct atmel_hlcdc_plane {
struct drm_plane base;
struct atmel_hlcdc_layer layer;
struct atmel_hlcdc_plane_properties *properties;
+   bool prepared;
 };

 static inline struct atmel_hlcdc_plane *
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 1ffe9c3..35027d0 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -715,11 +715,25 @@ static int atmel_hlcdc_plane_prepare_fb(struct drm_plane 
*p,
const struct drm_plane_state *new_state)
 {
struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
+   int ret;

-   if (!new_state->fb)
-   return 0;
+   ret = atmel_hlcdc_layer_update_start(&plane->layer);
+   if (!ret)
+   plane->prepared = true;
+
+   return ret;
+}
+
+static void atmel_hlcdc_plane_cleanup_fb(struct drm_plane *p,
+   const struct drm_plane_state *old_state)
+{
+   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
+
+   if (!plane->prepared)
+   return;

-   return atmel_hlcdc_layer_update_start(&plane->layer);
+   atmel_hlcdc_layer_update_rollback(&plane->layer);
+   plane->prepared = false;
 }

 static void atmel_hlcdc_plane_atomic_update(struct drm_plane *p,
@@ -739,6 +753,7 @@ static void atmel_hlcdc_plane_atomic_update(struct 
drm_plane *p,
atmel_hlcdc_plane_update_disc_area(plane, state);

atmel_hlcdc_layer_update_commit(&plane->layer);
+   plane->prepared = false;
 }

 static void atmel_hlcdc_plane_atomic_disable(struct drm_plane *p,
@@ -844,6 +859,7 @@ static void atmel_hlcdc_plane_init_properties(struct 
atmel_hlcdc_plane *plane,

 static struct drm_plane_helper_funcs atmel_hlcdc_layer_plane_helper_funcs = {
.prepare_fb = atmel_hlcdc_plane_prepare_fb,
+   .cleanup_fb = atmel_hlcdc_plane_cleanup_fb,
.atomic_check = atmel_hlcdc_plane_atomic_check,
.atomic_update = atmel_hlcdc_plane_atomic_update,
.atomic_disable = atmel_hlcdc_plane_atomic_disable,
-- 
2.5.0



[PATCH v2 0/9] drm: atmel-hlcdc: various fixes/improvements

2016-03-16 Thread Boris Brezillon
Hello,

This series is a collection of fixes and improvements for the
atmel-hlcdc driver.

The main feature added here is the support for external RGB -> XXX
bridges (patch 6 and 7).

The first patch is a fix preventing a potential memory leak.
Patch 2 is adding support for asynchronous mode setting, which was
supported before the migration to atomic mode setting.

Patch 3 is just a minor fix to expose the real encoder and connector
types (we are currently exposing an LVDS encoder/connector, which is
wrong since the display controller output the pixel stream in raw
RGB).

Patch 4 is removing useless fields and functions which were left
when moving to atomic modesetting.

Patch 8 is just a cosmetic patch moving the mode checking code
from ->atomic_check() to ->mode_fixup().

Patch 9 is increasing HLCDC bandwidth by making use of the two AHB
interfaces.

Best Regards,

Boris

Changes since v1:
- Add Nicolas Reviewed/Teste/Acked-by tags
- Add a patch to increase HLCDC bandwidth by using both AHB interfaces

Boris Brezillon (9):
  drm: atmel-hlcdc: add a ->cleanup_fb() operation
  drm: atmel-hlcdc: support asynchronous atomic commit operations
  drm: atmel-hlcdc: fix connector and encoder types
  drm: atmel-hlcdc: remove leftovers from atomic mode setting migration
  drm: atmel-hlcdc: support extended timing ranges on sama5d4 and
sama5d2
  drm: atmel-hlcdc: move output mode selection in CRTC implementation
  drm: atmel-hlcdc: rework the output code to support drm bridges
  drm: atmel-hlcdc: check display mode validity in crtc->mode_fixup()
  drm: atmel-hlcdc: route DMA accesses through AHB interfaces

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 154 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 123 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  17 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 249 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  |  65 +-
 5 files changed, 447 insertions(+), 161 deletions(-)

-- 
2.5.0



[PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

2016-03-16 Thread Ben Skeggs
On 03/15/2016 12:24 AM, Arnd Bergmann wrote:
> gcc-6 warns about code in the nouveau driver that is obviously silly:
> 
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 
> 'nv40_perfctr_next':
> drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison 
> always evaluats to false [-Wtautological-compare]
>   if (pm->sequence != pm->sequence) {
> 
> The behavior was accidentally introduced in a patch described as "This is
> purely preparation for upcoming commits, there should be no code changes 
> here.".
> As far as I can tell, that was true for the rest of that patch except for
> this one function, which has been changed to a NOP.
> 
> This patch restores the original behavior.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")
Reviewed-by: Ben Skeggs 

> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> index 4bef72a9d106..3fda594700e0 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c
> @@ -59,9 +59,11 @@ static void
>  nv40_perfctr_next(struct nvkm_pm *pm, struct nvkm_perfdom *dom)
>  {
>   struct nvkm_device *device = pm->engine.subdev.device;
> - if (pm->sequence != pm->sequence) {
> + struct nv40_pm *nv40pm = container_of(pm, struct nv40_pm, base);
> +
> + if (nv40pm->sequence != pm->sequence) {
>   nvkm_wr32(device, 0x400084, 0x0020);
> - pm->sequence = pm->sequence;
> + nv40pm->sequence = pm->sequence;
>   }
>  }
>  
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160316/4495b7bb/attachment.sig>


[RFC 5/5] drm/tinydrm: Add support for several Adafruit TFT displays

2016-03-16 Thread Noralf Trønnes
Add support for Adafruit MIPI DBI compatible SPI displays:
1.8" Color TFT LCD display - ST7735R (#358)
2.2" Color TFT LCD display - HX8340BN, 9-bit (#797)
2.8" PiTFT 320x240 TFT+Touchscreen for Raspberry Pi (#1601)

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/Kconfig|  11 ++
 drivers/gpu/drm/tinydrm/Makefile   |   3 +
 drivers/gpu/drm/tinydrm/adafruit-tft.c | 256 +
 include/drm/tinydrm/ili9340.h  |  85 +++
 4 files changed, 355 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/adafruit-tft.c
 create mode 100644 include/drm/tinydrm/ili9340.h

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index a7929e0..649f311 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -13,4 +13,15 @@ menuconfig DRM_TINYDRM
 config TINYDRM_MIPI_DBI
tristate

+config TINYDRM_ADAFRUIT_TFT
+   tristate "DRM driver for Adafruit SPI TFT displays"
+   depends on DRM_TINYDRM && SPI
+   select LCDREG_SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Adafruit displays:
+   2.8" PiTFT 320x240 for Raspberry Pi - ILI9340 (#1601)
+   2.2" Color TFT LCD display - HX8340BN, 9-bit mode (#797)
+   1.8" Color TFT LCD display - ST7735R (#358)
+
 source "drivers/gpu/drm/tinydrm/lcdreg/Kconfig"
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 35ba822..3c00201 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -3,3 +3,6 @@ obj-$(CONFIG_LCDREG)+= lcdreg/

 # Controllers
 obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
+
+# Displays
+obj-$(CONFIG_TINYDRM_ADAFRUIT_TFT) += adafruit-tft.o
diff --git a/drivers/gpu/drm/tinydrm/adafruit-tft.c 
b/drivers/gpu/drm/tinydrm/adafruit-tft.c
new file mode 100644
index 000..09049f7
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/adafruit-tft.c
@@ -0,0 +1,256 @@
+#define DEBUG
+
+/*
+ * DRM driver for Adafruit MIPI compatible SPI TFT displays
+ *
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum adafruit_tft_displays {
+   ADAFRUIT_1601 = 1601,
+   ADAFRUIT_797 = 797,
+   ADAFRUIT_358 = 358,
+};
+
+static u32 adafruit_tft_get_rotation(struct device *dev)
+{
+   u32 rotation = 0;
+
+   device_property_read_u32(dev, "rotation", &rotation);
+
+   return rotation;
+}
+
+static int adafruit_tft_1601_panel_prepare(struct drm_panel *panel)
+{
+   struct tinydrm_device *tdev = tinydrm_from_panel(panel);
+   struct lcdreg *reg = tdev->lcdreg;
+   u8 addr_mode;
+   int ret;
+
+   dev_dbg(tdev->base->dev, "%s\n", __func__);
+
+   if (tdev->regulator) {
+   ret = regulator_enable(tdev->regulator);
+   if (ret) {
+   dev_err(tdev->base->dev,
+   "Failed to enable regulator %d\n", ret);
+   return ret;
+   }
+   }
+
+   mipi_dbi_debug_dump_regs(reg);
+
+   /* Avoid flicker by skipping setup if the bootloader has done it */
+   if (mipi_dbi_display_is_on(reg))
+   return 0;
+
+   lcdreg_reset(reg);
+   ret = lcdreg_writereg(reg, ILI9340_SWRESET);
+   if (ret) {
+   dev_err(tdev->base->dev, "Error writing lcdreg %d\n", ret);
+   return ret;
+   }
+
+   msleep(20);
+
+   /* Undocumented registers */
+   lcdreg_writereg(reg, 0xEF, 0x03, 0x80, 0x02);
+   lcdreg_writereg(reg, 0xCF, 0x00, 0xC1, 0x30);
+   lcdreg_writereg(reg, 0xED, 0x64, 0x03, 0x12, 0x81);
+   lcdreg_writereg(reg, 0xE8, 0x85, 0x00, 0x78);
+   lcdreg_writereg(reg, 0xCB, 0x39, 0x2C, 0x00, 0x34, 0x02);
+   lcdreg_writereg(reg, 0xF7, 0x20);
+   lcdreg_writereg(reg, 0xEA, 0x00, 0x00);
+
+   lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23);
+   lcdreg_writereg(reg, ILI9340_PWCTRL2, 0x10);
+   lcdreg_writereg(reg, ILI9340_VMCTRL1, 0x3e, 0x28);
+   lcdreg_writereg(reg, ILI9340_VMCTRL2, 0x86);
+
+   lcdreg_writereg(reg, ILI9340_PIXSET, 0x55);
+   lcdreg_writereg(reg, ILI9340_FRMCTR1, 0x00, 0x18);
+   lcdreg_writereg(reg, ILI9340_DISCTRL, 0x08, 0x82, 0x27);
+
+   /* 3Gamma Function Disable */
+   lcdreg_writereg(reg, 0xF2, 0x00);
+
+   lcdreg_writereg(reg, ILI9340_GAMSET, 0x01);
+   lcdreg_writereg(reg, ILI9340_PGAMCTRL,
+   0x0F, 0x31, 0x2B, 0x0C, 0x0E, 0x08, 0x4E, 0xF1,
+   0x37, 0x07, 0x10, 0x03, 0x0E, 0x09, 0x00);
+   lcdreg_writereg(reg, ILI9

[RFC 4/5] drm/tinydrm: Add mipi-dbi support

2016-03-16 Thread Noralf Trønnes
Add support for MIPI DBI interfaced controllers.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/Kconfig|   3 +
 drivers/gpu/drm/tinydrm/Makefile   |   3 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 231 +
 include/drm/tinydrm/mipi-dbi.h |  24 
 4 files changed, 261 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/mipi-dbi.c
 create mode 100644 include/drm/tinydrm/mipi-dbi.h

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 671239f..a7929e0 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -10,4 +10,7 @@ menuconfig DRM_TINYDRM
  Choose this option if you have a tinydrm supported display.
  If M is selected the module will be called tinydrm.

+config TINYDRM_MIPI_DBI
+   tristate
+
 source "drivers/gpu/drm/tinydrm/lcdreg/Kconfig"
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index f4a92d9..35ba822 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -1,2 +1,5 @@
 obj-$(CONFIG_DRM_TINYDRM)  += core/
 obj-$(CONFIG_LCDREG)   += lcdreg/
+
+# Controllers
+obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
new file mode 100644
index 000..3021349
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -0,0 +1,231 @@
+//#define DEBUG
+/*
+ * MIPI Display Bus Interface (DBI) LCD controller support
+ *
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DCS_POWER_MODE_DISPLAY BIT(2)
+#define DCS_POWER_MODE_DISPLAY_NORMAL_MODE BIT(3)
+#define DCS_POWER_MODE_SLEEP_MODE  BIT(4)
+#define DCS_POWER_MODE_PARTIAL_MODEBIT(5)
+#define DCS_POWER_MODE_IDLE_MODE   BIT(6)
+#define DCS_POWER_MODE_RESERVED_MASK   (BIT(0) | BIT(1) | BIT(7))
+
+/* TODO: Move common functions to a separate module */
+void tinydrm_xrgb_to_rgb565(u32 *src, u16 *dst, unsigned num_pixels, bool 
swap_bytes)
+{
+   int i;
+
+   for (i = 0; i < num_pixels; i++) {
+   *dst = ((*src & 0x00F8) >> 8) |
+  ((*src & 0xFC00) >> 5) |
+  ((*src & 0x00F8) >> 3);
+   if (swap_bytes)
+   *dst = swab16(*dst);
+   src++;
+   dst++;
+   }
+}
+
+// TODO: Pass in regnr
+int tinydrm_update_rgb565_lcdreg(struct tinydrm_device *tdev, struct 
drm_framebuffer *fb, void *vmem, struct drm_clip_rect *clip)
+{
+   unsigned num_pixels = (clip->x2 - clip->x1 + 1) *
+ (clip->y2 - clip->y1 + 1);
+   struct lcdreg_transfer tr = {
+   .index = 1,
+   .width = 16,
+   .count = num_pixels
+   };
+   bool byte_swap = false;
+   u16 *buf = NULL;
+   int ret;
+
+   dev_err_once(tdev->base->dev, "pixel_format = %s, bpw = 0x%08x\n", 
drm_get_format_name(fb->pixel_format), tdev->lcdreg->bits_per_word_mask);
+
+   switch (fb->pixel_format) {
+   case DRM_FORMAT_RGB565:
+   tr.buf = vmem;
+   break;
+   case DRM_FORMAT_XRGB:
+   buf = kmalloc(num_pixels * sizeof(u16), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+#if defined(__LITTLE_ENDIAN)
+   byte_swap = !lcdreg_bpw_supported(tdev->lcdreg, 16);
+#endif
+   tinydrm_xrgb_to_rgb565(vmem, buf, num_pixels, byte_swap);
+   tr.buf = buf;
+   if (byte_swap) {
+   tr.width = 8;
+   tr.count *= 2;
+   }
+   break;
+   default:
+   dev_err_once(tdev->base->dev,
+"pixel_format '%s' is not supported\n",
+drm_get_format_name(fb->pixel_format));
+   return -EINVAL;
+   }
+
+   ret = lcdreg_write(tdev->lcdreg, MIPI_DCS_WRITE_MEMORY_START, &tr);
+   kfree(buf);
+
+   return ret;
+}
+
+static void mipi_dbi_deferred_update(struct work_struct *work)
+{
+   struct tinydrm_device *tdev = work_to_tinydrm(work);
+   struct lcdreg *reg = tdev->lcdreg;
+   struct tinydrm_fb_clip fb_clip;
+   struct drm_clip_rect *clip = &fb_clip.clip;
+   int ret;
+
+   dev_dbg(tdev->base->dev, "%s\n", __func__);
+
+   if (!tinydrm_deferred_begin(tdev, &fb_clip))
+   return;
+
+   dev_dbg(tdev->base->dev, "%s: vmem=%p, x1=%u, x2=%u, y1=%u, y2=%u\n", 
__func__, fb_clip.vmem, clip->x1, cli

[RFC 3/5] drm/tinydrm/lcdreg: Add SPI support

2016-03-16 Thread Noralf Trønnes
Add SPI bus support to lcdreg.
Supports the following protocols:
- MIPI DBI type C interface option 1 (3-wire) and option 3 (4-wire).
- Option 3 also fits some controllers where all registers are 16-bit.
- 8/16-bit register transfers that need to start with a special startbyte.

It also supports emulation for 16 and 9-bit words if the SPI controller
doesn't support it.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/lcdreg/Kconfig  |   5 +
 drivers/gpu/drm/tinydrm/lcdreg/Makefile |   2 +
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c | 720 
 include/drm/tinydrm/lcdreg-spi.h|  63 +++
 4 files changed, 790 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c
 create mode 100644 include/drm/tinydrm/lcdreg-spi.h

diff --git a/drivers/gpu/drm/tinydrm/lcdreg/Kconfig 
b/drivers/gpu/drm/tinydrm/lcdreg/Kconfig
index 41383b1..ade465f 100644
--- a/drivers/gpu/drm/tinydrm/lcdreg/Kconfig
+++ b/drivers/gpu/drm/tinydrm/lcdreg/Kconfig
@@ -1,3 +1,8 @@
 config LCDREG
tristate
depends on GPIOLIB || COMPILE_TEST
+
+config LCDREG_SPI
+   tristate
+   depends on SPI
+   select LCDREG
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/Makefile 
b/drivers/gpu/drm/tinydrm/lcdreg/Makefile
index c9ea774..4e14571 100644
--- a/drivers/gpu/drm/tinydrm/lcdreg/Makefile
+++ b/drivers/gpu/drm/tinydrm/lcdreg/Makefile
@@ -1,3 +1,5 @@
 obj-$(CONFIG_LCDREG)   += lcdreg.o
 lcdreg-y   += lcdreg-core.o
 lcdreg-$(CONFIG_DEBUG_FS)  += lcdreg-debugfs.o
+
+obj-$(CONFIG_LCDREG_SPI)   += lcdreg-spi.o
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c 
b/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c
new file mode 100644
index 000..5e9d8fe1
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c
@@ -0,0 +1,720 @@
+//#define VERBOSE_DEBUG
+//#define DEBUG
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static unsigned txlen;
+module_param(txlen, uint, 0);
+MODULE_PARM_DESC(txlen, "Transmit chunk length");
+
+static unsigned long bpwm;
+module_param(bpwm, ulong, 0);
+MODULE_PARM_DESC(bpwm, "Override SPI master bits_per_word_mask");
+
+struct lcdreg_spi {
+   struct lcdreg reg;
+   enum lcdreg_spi_mode mode;
+unsigned txbuflen;
+   void *txbuf_dc;
+   unsigned id;
+   u32 quirks;
+   u8 (*startbyte)(struct lcdreg *reg, struct lcdreg_transfer *tr,
+   bool read);
+   struct gpio_desc *dc;
+   struct gpio_desc *reset;
+};
+
+static inline struct lcdreg_spi *to_lcdreg_spi(struct lcdreg *reg)
+{
+   return reg ? container_of(reg, struct lcdreg_spi, reg) : NULL;
+}
+
+#ifdef VERBOSE_DEBUG
+static void lcdreg_vdbg_dump_spi(const struct device *dev, struct spi_message 
*m, u8 *startbyte)
+{
+   struct spi_transfer *tmp;
+   struct list_head *pos;
+   int i = 0;
+
+   if (startbyte)
+   dev_dbg(dev, "spi_message: startbyte=0x%02X\n", startbyte[0]);
+   else
+   dev_dbg(dev, "spi_message:\n");
+
+   list_for_each(pos, &m->transfers) {
+   tmp = list_entry(pos, struct spi_transfer, transfer_list);
+   if (tmp->tx_buf)
+   pr_debug("tr%i: bpw=%i, len=%u, 
tx_buf(%p)=[%*ph]\n", i, tmp->bits_per_word, tmp->len, tmp->tx_buf, tmp->len > 
64 ? 64 : tmp->len, tmp->tx_buf);
+   if (tmp->rx_buf)
+   pr_debug("tr%i: bpw=%i, len=%u, 
rx_buf(%p)=[%*ph]\n", i, tmp->bits_per_word, tmp->len, tmp->rx_buf, tmp->len > 
64 ? 64 : tmp->len, tmp->rx_buf);
+   i++;
+   }
+}
+#else
+static void lcdreg_vdbg_dump_spi(const struct device *dev, struct spi_message 
*m, u8 *startbyte)
+{
+}
+#endif
+
+static int lcdreg_spi_do_transfer(struct lcdreg *reg,
+ struct lcdreg_transfer *transfer)
+{
+   struct spi_device *sdev = to_spi_device(reg->dev);
+   struct lcdreg_spi *spi = to_lcdreg_spi(reg);
+   void *buf = transfer->buf;
+   size_t len = transfer->count * lcdreg_bytes_per_word(transfer->width);
+   size_t max = txlen ? : sdev->master->max_dma_len;
+   size_t room_left_in_page = PAGE_SIZE - offset_in_page(buf);
+   size_t chunk = min_t(size_t, len, max);
+   struct spi_message m;
+   struct spi_transfer *tr;
+   u8 *startbuf = NULL;
+   int ret, i;
+
+   dev_dbg(reg->dev, "%s: index=%u, count=%u, width=%u\n",
+   __func__, transfer->index, transfer->count, transfer->width);
+   lcdreg_dbg_transfer_buf(transfer);
+
+   tr = kzallo

[RFC 2/5] drm/tinydrm: Add lcd register abstraction

2016-03-16 Thread Noralf Trønnes
Add LCD register abstraction for MIPI DBI/DCS like controllers.
This hides LCD controller interface implementation details.
When built with debugfs, the register is available to userspace.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/Kconfig |   2 +
 drivers/gpu/drm/tinydrm/Makefile|   1 +
 drivers/gpu/drm/tinydrm/lcdreg/Kconfig  |   3 +
 drivers/gpu/drm/tinydrm/lcdreg/Makefile |   3 +
 drivers/gpu/drm/tinydrm/lcdreg/internal.h   |   8 +
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c| 190 
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-debugfs.c | 281 
 include/drm/tinydrm/lcdreg.h| 126 +++
 8 files changed, 614 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/Kconfig
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/internal.h
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-debugfs.c
 create mode 100644 include/drm/tinydrm/lcdreg.h

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f290045..671239f 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -9,3 +9,5 @@ menuconfig DRM_TINYDRM
help
  Choose this option if you have a tinydrm supported display.
  If M is selected the module will be called tinydrm.
+
+source "drivers/gpu/drm/tinydrm/lcdreg/Kconfig"
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 7476ed1..f4a92d9 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_TINYDRM)  += core/
+obj-$(CONFIG_LCDREG)   += lcdreg/
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/Kconfig 
b/drivers/gpu/drm/tinydrm/lcdreg/Kconfig
new file mode 100644
index 000..41383b1
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/lcdreg/Kconfig
@@ -0,0 +1,3 @@
+config LCDREG
+   tristate
+   depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/Makefile 
b/drivers/gpu/drm/tinydrm/lcdreg/Makefile
new file mode 100644
index 000..c9ea774
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/lcdreg/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_LCDREG)   += lcdreg.o
+lcdreg-y   += lcdreg-core.o
+lcdreg-$(CONFIG_DEBUG_FS)  += lcdreg-debugfs.o
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/internal.h 
b/drivers/gpu/drm/tinydrm/lcdreg/internal.h
new file mode 100644
index 000..140fcfd
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/lcdreg/internal.h
@@ -0,0 +1,8 @@
+
+#ifdef CONFIG_DEBUG_FS
+void lcdreg_debugfs_init(struct lcdreg *reg);
+void lcdreg_debugfs_exit(struct lcdreg *reg);
+#else
+static inline void lcdreg_debugfs_init(struct lcdreg *reg) { }
+static inline void lcdreg_debugfs_exit(struct lcdreg *reg) { }
+#endif
diff --git a/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c 
b/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c
new file mode 100644
index 000..bda848c
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c
@@ -0,0 +1,190 @@
+//#define DEBUG
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+/**
+ * Write to LCD register
+ *
+ * @reg: LCD register
+ * @regnr: Register number
+ * @transfer: Transfer to write
+ */
+int lcdreg_write(struct lcdreg *reg, unsigned regnr,
+struct lcdreg_transfer *transfer)
+{
+   if (WARN_ON_ONCE(!reg || !reg->write || !transfer))
+   return -EINVAL;
+
+   if (!transfer->width)
+   transfer->width = reg->def_width;
+
+   dev_dbg(reg->dev,
+   "lcdreg_write: regnr=0x%02x, index=%u, count=%u, width=%u\n",
+   regnr, transfer->index, transfer->count, transfer->width);
+   lcdreg_dbg_transfer_buf(transfer);
+
+   return reg->write(reg, regnr, transfer);
+}
+EXPORT_SYMBOL(lcdreg_write);
+
+/**
+ * Write 32-bit wide buffer to LCD register
+ * @reg: lcdreg
+ * @regnr: Register number
+ * @buf: Buffer to write
+ * @count: Number of words to write
+ */
+int lcdreg_write_buf32(struct lcdreg *reg, unsigned regnr, const u32 *buf,
+  unsigned count)
+{
+   struct lcdreg_transfer tr = {
+   .index = 1,
+   .width = reg->def_width,
+   .count = count,
+   };
+   int i, ret;
+
+   if (!buf)
+   return -EINVAL;
+
+   tr.buf = kmalloc_array(count, sizeof(*buf), GFP_KERNEL);
+   if (!tr.buf)
+   return -ENOMEM;
+
+

[RFC 1/5] drm: Add DRM support for tiny LCD displays

2016-03-16 Thread Noralf Trønnes
tinydrm provides a very simplified view of DRM for displays that has
onboard video memory and is connected through a slow bus like SPI/I2C.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/Kconfig|  11 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/core/Makefile  |   8 +
 drivers/gpu/drm/tinydrm/core/internal.h|  43 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 194 
 drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c| 203 
 drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c| 116 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c   | 345 +
 drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c | 112 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  97 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-plane.c   |  50 +++
 include/drm/tinydrm/tinydrm.h  | 142 +
 14 files changed, 1325 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
 create mode 100644 drivers/gpu/drm/tinydrm/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/core/internal.h
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-plane.c
 create mode 100644 include/drm/tinydrm/tinydrm.h

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

 source "drivers/gpu/drm/vc4/Kconfig"
+
+source "drivers/gpu/drm/tinydrm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c..c7c5c16 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -75,3 +75,4 @@ obj-y += i2c/
 obj-y  += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
+obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
new file mode 100644
index 000..f290045
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -0,0 +1,11 @@
+menuconfig DRM_TINYDRM
+   tristate "Support for small TFT LCD display modules"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_PANEL
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you have a tinydrm supported display.
+ If M is selected the module will be called tinydrm.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
new file mode 100644
index 000..7476ed1
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_TINYDRM)  += core/
diff --git a/drivers/gpu/drm/tinydrm/core/Makefile 
b/drivers/gpu/drm/tinydrm/core/Makefile
new file mode 100644
index 000..03309f4
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/core/Makefile
@@ -0,0 +1,8 @@
+obj-$(CONFIG_DRM_TINYDRM)  += tinydrm.o
+tinydrm-y  += tinydrm-core.o
+tinydrm-y  += tinydrm-crtc.o
+tinydrm-y  += tinydrm-framebuffer.o
+tinydrm-y  += tinydrm-plane.o
+tinydrm-y  += tinydrm-helpers.o
+tinydrm-y  += tinydrm-deferred.o
+tinydrm-$(CONFIG_DRM_KMS_FB_HELPER)+= tinydrm-fbdev.o
diff --git a/drivers/gpu/drm/tinydrm/core/internal.h 
b/drivers/gpu/drm/tinydrm/core/internal.h
new file mode 100644
index 000..a126658
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/core/internal.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+int tinydrm_crtc_create(struct tinydrm_device *tdev);
+
+static inline bool tinydrm_active(struct tinydrm_device *tdev)
+{
+   struct drm_crtc *crtc;
+
+   drm_for_each_crtc(crtc, tdev->base)
+   return crtc->state && crtc->state->active;
+
+   return false;
+}
+
+void tinydrm_mode_config_init(struct tinydrm_device *tdev);
+
+int tinydrm_plane_init(struct tinydrm_

[RFC 0/5] drm: Add support for tiny LCD displays

2016-03-16 Thread Noralf Trønnes
This is an attempt at providing a DRM version of drivers/staging/fbtft.
I'm sending this early before cleaning up the code hoping to get some
feedback in case there are better ways to structure this.

The tinydrm module provides a very simplified view of DRM for displays that
has onboard video memory and is connected through a slow bus like SPI/I2C.
A driver using tinydrm has to provide a function that will be called from
the dirtyfb ioctl and optionally drm_panel functions which can be used to
set up the display controller and control backlight.

tinydrm also has fbdev support using fb_deferred_io which is tied in through
the dirtyfb function call. A driver can use the provided deferred work code
to collect dirtyfb calls and schedule display memory updates if it whishes.
The various display controllers can have library modules that handles
display updates.
Display controllers that have a similar register interface as the MIPI DBI/DCS
controllers can use the lcdreg module for register access.

struct tinydrm_device {
struct drm_device *base;
u32 width, height;
struct drm_panel panel;
[...]
int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags,
   unsigned color, struct drm_clip_rect *clips,
   unsigned num_clips);
};

+--+-+
|  |  fbdev  |
|  DRM +--+  |
| |  |
+-+--+
||
|tinydrm |
||
+--+ .  .  .  .  .  .  . |
|  |deferred work|
|  Display driver  +-+
|  |  Controller module  |
+--+-+
| lcdreg |
++
| Interface (SPI, I2C, parallel) |
++


Noralf Trønnes (5):
  drm: Add DRM support for tiny LCD displays
  drm/tinydrm: Add lcd register abstraction
  drm/tinydrm/lcdreg: Add SPI support
  drm/tinydrm: Add mipi-dbi support
  drm/tinydrm: Add support for several Adafruit TFT displays

 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/Kconfig|  27 +
 drivers/gpu/drm/tinydrm/Makefile   |   8 +
 drivers/gpu/drm/tinydrm/adafruit-tft.c | 256 
 drivers/gpu/drm/tinydrm/core/Makefile  |   8 +
 drivers/gpu/drm/tinydrm/core/internal.h|  43 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c| 194 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c| 203 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c| 116 
 drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c   | 345 ++
 drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c | 112 
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |  97 +++
 drivers/gpu/drm/tinydrm/core/tinydrm-plane.c   |  50 ++
 drivers/gpu/drm/tinydrm/lcdreg/Kconfig |   8 +
 drivers/gpu/drm/tinydrm/lcdreg/Makefile|   5 +
 drivers/gpu/drm/tinydrm/lcdreg/internal.h  |   8 +
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c   | 190 ++
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-debugfs.c| 281 
 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-spi.c| 720 +
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 231 +++
 include/drm/tinydrm/ili9340.h  |  85 +++
 include/drm/tinydrm/lcdreg-spi.h   |  63 ++
 include/drm/tinydrm/lcdreg.h   | 126 
 include/drm/tinydrm/mipi-dbi.h |  24 +
 include/drm/tinydrm/tinydrm.h  | 142 
 26 files changed, 3345 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/Kconfig
 create mode 100644 drivers/gpu/drm/tinydrm/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/adafruit-tft.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/core/internal.h
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-crtc.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-deferred.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-fbdev.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-framebuffer.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
 create mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-plane.c
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/Kconfig
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/Makefile
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/internal.h
 create mode 100644 drivers/gpu/drm/tinydrm/lcdreg/lcdreg-core.c
 create mode 100644 d

[PATCH 1/3] pinctrl: Intel: add RX invertion config

2016-03-16 Thread Daniel Vetter
On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote:
> 
> On Tue, Mar 15, 2016 at 3:17 AM, Zheng, Qi  wrote:
> >> On Mon, Mar 14, 2016 at 9:56 AM, Zheng, Qi  wrote:
> >
> >> The "pi330532" device on Broxton requires this function to manually
> >> trigger an GPIO input interrupt.
> > (...)
> >> We have gone through this requirement from CHT to BXT, there was no
> >> other better way to simulate the GPIO interrupt for the use of those 
> >> devices.
> >
> >> I what you want is to trigger IRQs on GPIO lines using software we
> >> need to add that to the GPIOlib subsystem, so this register gets accessed
> >> from the GPIO side of things, not through pin control I think?
> >
> > We have pinctrl control map locally.
> > The RX inversion is implemented by pinctrl control calls, 
> > pinctrl_pm_select_default_state
> > and pinctrl_pm_select_sleep_state.
> >
> >> We have so many diverse function pointers in the gpiochip, so ability to
> >> trigger/test IRQs from software is certainly not a burden.
> >
> >> I don't understand the real-world usecase though, please explain what kind 
> >> of problem
> >> this is trying to overcome? Why does this pi330532 driver need to do that, 
> >> why can
> >> it not just inform the driver that needs this interrupt that it should 
> >> wake up, e.g by
> >> using a notification or just an open-coded function call or whatever?
> >
> > According to the pi330532 driver owner,
> > "
> > we needed this support to simulate the HPD interrupt behavior as we don’t 
> > have
> > dedicated interrupt line for Type-C DP HPD.
> 
> - What is a HPD interrupt?

hotplug interrupt, fires when you plug in a cable.

> - What is a Type-C DP HPD?

usb type C connector can multiplex both DisplayPort and USB, you need to
renegotiate the lane splitting every time the sink changes, i.e. on each
hotplug.

> - Again why can't you just use a notifier or function call?

Because windows sucks, hence all that coordination happens through hw
forwarded interrupts and magic registers. Same horror story on the sound
side, where the sound driver needs to know what kind of PCM stream the
monitor can take. It's hilarious. Except when they screw up the design and
then need to fake parts of it in software.

In sound we've switched over to a proper sw interface, and we tie the
different parts (drm graphics driver and alsa snd driver) using the
component.c framework.

> > We don’t have any notifications mechasism b/w USB and display/Gfx stack 
> > and
> > also not the ideal way to handle.  HPD toggling is the preferred approach 
> > suggested
> > by VPG and HW teams to meet timing requirements also.
> 
> What is VPG? Now it seems Intel's internal organization is being used as
> part of the argument to get this change in and that makes me a bit
> annoyed.
> 
> If there is no good notification mechanism then implement one instead
> of starting to software-generate hardware interrupts.
> 
> I also start to get the feeling that these USB and display stacks
> you are referring to are not the upstream versions.

There was chat of usb type C support for forever, but I was always
promised that we don't need any interactions on the sw side and it's all
magic in hw. There hasn't been any real design discussions in the open
source group. VPG is the hw/windows group and generally comes up with
"interesting" designs not suitable for upstream.

Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in
the future (since I tend to ignore everything that's not cc'ed to mailing
lists I don't care about, even when I'm on cc personally). I've added them
all to cc.

Cheers, Daniel


> > static void hpd_trigger(struct pi3usb30532_mux *chip, int state)
> > {
> > dev_info(&chip->client->dev, "[HPD trigger] state : %d\n", state);
> >
> > if (state)
> > pinctrl_pm_select_default_state(chip->dev);
> > else
> > pinctrl_pm_select_sleep_state(chip->dev);
> > }
> 
> Can we get the *TECHNICAL* explanation of why this thing needs
> to be done instead of using a notifier or function call?
> 
> Yours,
> Linus Walleij

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


[PATCH v2 1/2] drm: bridge: sil902x

2016-03-16 Thread Nicolas Ferre
Le 06/01/2016 13:25, Boris Brezillon a écrit :
> Add basic support for the sil902x RGB -> HDMI bridge.
> This driver does not support audio output yet.
> 
> Signed-off-by: Boris Brezillon 

You can add my:
Tested-by: Nicolas Ferre 

I tested it on a SAMA5D4 Xplained board with a Dell HDMI monitor.

Thanks, bye.


> ---
> Hello,
> 
> This patch is only adding basic support for the sil9022 chip.
> As stated in the commit log, there's no audio support, but the
> driver also hardcodes a lot of things (like the RGB input format to
> use).
> There are two reasons for this:
> 1/ the DRM framework does not allow for advanced link description
>between an encoder and a bridge (that's for the RGB format
>limitation). Any idea how this should be described?
> 
> 2/ I don't have the datasheet of this HDMI encoder, and all logic
>has been extracted from those two drivers [1][2], which means
>I may miss some important things in my encoder setup.
> 
> Another thing I find weird in the drm_bridge interface is the fact
> that we have a ->attach() method, but no ->detach(), which can be
> a problem if we allow drm bridges and KMS drivers to be compiled as
> modules. Any reason for that?
> 
> That's all for the questions part :-).
> 
> Best Regards,
> 
> Boris
> 
> Changes in v2:
> - fix errors reported by kbuild test robot
> 
> ---
>  drivers/gpu/drm/bridge/Kconfig   |   8 +
>  drivers/gpu/drm/bridge/Makefile  |   1 +
>  drivers/gpu/drm/bridge/sil902x.c | 491 
> +++
>  3 files changed, 500 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/sil902x.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 27e2022..9701fd2 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -40,4 +40,12 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>  
> +config DRM_SIL902X
> + tristate "Silicon Image sil902x RGB/HDMI bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + ---help---
> +   Silicon Image sil902x bridge chip driver.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index f13c33d..a689aad 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_SIL902X) += sil902x.o
> diff --git a/drivers/gpu/drm/bridge/sil902x.c 
> b/drivers/gpu/drm/bridge/sil902x.c
> new file mode 100644
> index 000..2657031
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/sil902x.c
> @@ -0,0 +1,491 @@
> +/*
> + * Copyright (C) 2014 Atmel
> + * Bo Shen 
> + *
> + * Authors:Bo Shen 
> + * Boris Brezillon 
> + * Wu, Songjun 
> + *
> + *
> + * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SIL902X_TPI_VIDEO_DATA   0x0
> +
> +#define SIL902X_TPI_PIXEL_REPETITION 0x8
> +#define SIL902X_TPI_AVI_PIXEL_REP_BUS_24BIT BIT(5)
> +#define SIL902X_TPI_AVI_PIXEL_REP_RISING_EDGE   BIT(4)
> +#define SIL902X_TPI_AVI_PIXEL_REP_4X 3
> +#define SIL902X_TPI_AVI_PIXEL_REP_2X 1
> +#define SIL902X_TPI_AVI_PIXEL_REP_NONE   0
> +#define SIL902X_TPI_CLK_RATIO_HALF   (0 << 6)
> +#define SIL902X_TPI_CLK_RATIO_1X (1 << 6)
> +#define SIL902X_TPI_CLK_RATIO_2X (2 << 6)
> +#define SIL902X_TPI_CLK_RATIO_4X (3 << 6)
> +
> +#define SIL902X_TPI_AVI_IN_FORMAT0x9
> +#define SIL902X_TPI_AVI_INPUT_BITMODE_12BIT  BIT(7)
> +#define SIL902X_TPI_AVI_INPUT_DITHER BIT(6)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_LIMITED  (2 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_FULL (1 << 2)
> +#define SIL902X_TPI_AVI_INPUT_RANGE_AUTO (0 << 2)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_BLACK   (3 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV422  (2 << 0)
> +#define SIL902X_TPI_AVI_INPUT_COLORSPACE_YUV444  (1 << 0)
> +#define SIL902X_

[PATCH 0/8] drm: atmel-hlcdc: various fixes/improvements

2016-03-16 Thread Nicolas Ferre
Le 06/01/2016 11:19, Boris Brezillon a écrit :
> Hello,
> 
> This series is a collection of fixes and improvements for the
> atmel-hlcdc driver.
> 
> The main feature added here is the support for external RGB -> XXX
> bridges (patch 6 and 7).
> 
> The first patch is a fix preventing a potential memory leak.
> Patch 2 is adding support for asynchronous mode setting, which was
> supported before the migration to atomic mode setting.
> 
> Patch 3 is just a minor fix to expose the real encoder and connector
> types (we are currently exposing an LVDS encoder/connector, which is
> wrong since the display controller output the pixel stream in raw
> RGB).
> 
> Patch 4 is removing useless fields and functions which were left
> when moving to atomic modesetting.
> 
> And patch 8 is just a cosmetic patch moving the mode checking code
> from ->atomic_check() to ->mode_fixup().

To give more weight to this series, you can also add my:

Tested-by: Nicolas Ferre 

Bye,


> Boris Brezillon (8):
>   drm: atmel-hlcdc: add a ->cleanup_fb() operation
>   drm: atmel-hlcdc: support asynchronous atomic commit operations
>   drm: atmel-hlcdc: fix connector and encoder types
>   drm: atmel-hlcdc: remove leftovers from atomic mode setting migration
>   drm: atmel-hlcdc: support extended timing ranges on sama5d4 and
> sama5d2
>   drm: atmel-hlcdc: move output mode selection in CRTC implementation
>   drm: atmel-hlcdc: rework the output code to support drm bridges
>   drm: atmel-hlcdc: check display mode validity in crtc->mode_fixup()
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 148 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 123 ++-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  16 ++
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 249 
> ++-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  |  22 +-
>  5 files changed, 400 insertions(+), 158 deletions(-)
> 


-- 
Nicolas Ferre


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Christian König
Am 16.03.2016 um 13:48 schrieb Jérôme Glisse:
> From: Jérome Glisse 
>
> This consolidate uvd/vce into a common shape for all generation. It
> also leverage the rdev->has_uvd flags to know what it is useless to
> try to resume/suspend uvd/vce block.
>
> There is no functional changes when there is no error. On error the
> device driver will behave differently than before after this patch.
> It should now safely ignore uvd/vce errors and keeps normal operation
> of others engine. This is an improvement over current situation where
> we have different behavior depending on GPU generation and on what
> fails.
>
> Finaly this is a preparatory step for a patch which allow to disable
> uvd/vce as a driver option.
>
> This have only been tested on southern island so please test it on
> other generations (i do not have hardware handy for now).
>
> Signed-off-by: Jérôme Glisse 
> Cc: Alex Deucher 
> Cc: Christian König 

NAK, skipping UVD and VCE suspend/resume when initialization fails 
should already be implemented.

There might be some (quite some) bugs in there, but that doesn't justify 
reworking the initialization over all different generations. Especially 
since you don't have hardware to test all of them.

Just make sure that radeon_uvd/vce_fini() is called when something goes 
wrong and/or that the UVD/VCE BO is properly released.

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/cik.c   | 226 ++
>   drivers/gpu/drm/radeon/evergreen.c | 122 ++-
>   drivers/gpu/drm/radeon/ni.c| 240 
> +
>   drivers/gpu/drm/radeon/r600.c  | 113 -
>   drivers/gpu/drm/radeon/rv770.c | 122 ++-
>   drivers/gpu/drm/radeon/si.c| 213 
>   drivers/gpu/drm/radeon/uvd_v4_2.c  |   5 +
>   7 files changed, 724 insertions(+), 317 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index f2a4c0f..489e202 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -8496,6 +8496,142 @@ restart_ih:
>   /*
>* startup/shutdown callbacks
>*/
> +
> +static void cik_uvd_vce_init(struct radeon_device *rdev)
> +{
> + struct radeon_ring *ring;
> + int r;
> +
> + if (!rdev->has_uvd)
> + return;
> +
> + r = radeon_uvd_init(rdev);
> + if (r)
> + goto error_uvd;
> + ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
> + ring->ring_obj = NULL;
> + r600_ring_init(rdev, ring, 4096);
> +
> + r = radeon_vce_init(rdev);
> + if (r)
> + goto error_vce;
> + ring = &rdev->ring[TN_RING_TYPE_VCE1_INDEX];
> + ring->ring_obj = NULL;
> + r600_ring_init(rdev, ring, 4096);
> + ring = &rdev->ring[TN_RING_TYPE_VCE2_INDEX];
> + ring->ring_obj = NULL;
> + r600_ring_init(rdev, ring, 4096);
> +
> + return;
> +
> +error_vce:
> + radeon_uvd_fini(rdev);
> +error_uvd:
> + dev_err(rdev->dev, "UVD/VCE init error (%d).\n", r);
> + /* On error just disable everything. */
> + rdev->has_uvd = 0;
> +}
> +
> +static void cik_uvd_vce_startup(struct radeon_device *rdev)
> +{
> + int r;
> +
> + if (!rdev->has_uvd)
> + return;
> +
> + r = uvd_v4_2_resume(rdev);
> + if (r)
> + goto error;
> + r = radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
> + if (r)
> + goto error_uvd;
> +
> + r = radeon_vce_resume(rdev);
> + if (r)
> + goto error_uvd;
> + r = vce_v2_0_resume(rdev);
> + if (r)
> + goto error_vce;
> + r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE1_INDEX);
> + if (r)
> + goto error_vce;
> + r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE2_INDEX);
> + if (r)
> + goto error_vce;
> +
> + return;
> +
> +error_vce:
> + radeon_vce_suspend(rdev);
> +error_uvd:
> + radeon_uvd_suspend(rdev);
> +error:
> + dev_err(rdev->dev, "UVD/VCE startup error (%d).\n", r);
> + /* On error just disable everything. */
> + radeon_vce_fini(rdev);
> + radeon_uvd_fini(rdev);
> + rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
> + rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
> + rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
> + rdev->has_uvd = 0;
> +}
> +
> +static void cik_uvd_vce_resume(struct radeon_device *rdev)
> +{
> + struct radeon_ring *ring;
> + int r;
> +
> + if (!rdev->has_uvd)
> + return;
> +
> + /* On uvd/vce error we disable uvd/vce so we should have bail above. */
> + BUG_ON(!rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size);
> + BUG_ON(!rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size);
> + BUG_ON(!rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size);
> +
> + ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, RADE

[PATCH 1/2] amdgpu: create only one IB for "all compute queues" tests

2016-03-16 Thread Christian König
Can somebody with commit access push those two patches after the review? 
I don't have write permission for libdrm.

Thanks in advance,
Christian.

Am 16.03.2016 um 13:54 schrieb Christian König:
> From: Christian König 
>
> It's simpler and allows us to test VMID sharing between
> between the compute queues as well.
>
> Signed-off-by: Christian König 
> ---
>   tests/amdgpu/basic_tests.c | 40 
>   1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
> index 4ef6014..d2086ce 100644
> --- a/tests/amdgpu/basic_tests.c
> +++ b/tests/amdgpu/basic_tests.c
> @@ -620,25 +620,25 @@ static void amdgpu_command_submission_compute(void)
>   r = amdgpu_cs_ctx_create(device_handle, &context_handle);
>   CU_ASSERT_EQUAL(r, 0);
>   
> - for (instance = 0; instance < 8; instance++) {
> - r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
> - AMDGPU_GEM_DOMAIN_GTT, 0,
> - &ib_result_handle, &ib_result_cpu,
> - &ib_result_mc_address, &va_handle);
> - CU_ASSERT_EQUAL(r, 0);
> + r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
> + AMDGPU_GEM_DOMAIN_GTT, 0,
> + &ib_result_handle, &ib_result_cpu,
> + &ib_result_mc_address, &va_handle);
> + CU_ASSERT_EQUAL(r, 0);
>   
> - r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
> + r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
>  &bo_list);
> - CU_ASSERT_EQUAL(r, 0);
> + CU_ASSERT_EQUAL(r, 0);
>   
> - ptr = ib_result_cpu;
> - for (i = 0; i < 16; ++i)
> - ptr[i] = 0x1000;
> + ptr = ib_result_cpu;
> + for (i = 0; i < 16; ++i)
> + ptr[i] = 0x1000;
>   
> - memset(&ib_info, 0, sizeof(struct amdgpu_cs_ib_info));
> - ib_info.ib_mc_address = ib_result_mc_address;
> - ib_info.size = 16;
> + memset(&ib_info, 0, sizeof(struct amdgpu_cs_ib_info));
> + ib_info.ib_mc_address = ib_result_mc_address;
> + ib_info.size = 16;
>   
> + for (instance = 0; instance < 8; instance++) {
>   memset(&ibs_request, 0, sizeof(struct amdgpu_cs_request));
>   ibs_request.ip_type = AMDGPU_HW_IP_COMPUTE;
>   ibs_request.ring = instance;
> @@ -660,14 +660,14 @@ static void amdgpu_command_submission_compute(void)
>AMDGPU_TIMEOUT_INFINITE,
>0, &expired);
>   CU_ASSERT_EQUAL(r, 0);
> + }
>   
> - r = amdgpu_bo_list_destroy(bo_list);
> - CU_ASSERT_EQUAL(r, 0);
> + r = amdgpu_bo_list_destroy(bo_list);
> + CU_ASSERT_EQUAL(r, 0);
>   
> - r = amdgpu_bo_unmap_and_free(ib_result_handle, va_handle,
> -  ib_result_mc_address, 4096);
> - CU_ASSERT_EQUAL(r, 0);
> - }
> + r = amdgpu_bo_unmap_and_free(ib_result_handle, va_handle,
> +  ib_result_mc_address, 4096);
> + CU_ASSERT_EQUAL(r, 0);
>   
>   r = amdgpu_cs_ctx_free(context_handle);
>   CU_ASSERT_EQUAL(r, 0);



[GIT PULL] drm/panel: Changes for v4.6-rc1

2016-03-16 Thread Thierry Reding
Hi Dave,

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to c8a3b2ae07130042682bc8e031bcfbae3754463d:

  drm/bridge: Make (pre/post) enable/disable callbacks optional (2016-03-02 
17:31:03 +0100)

Sorry again for this being so late. I had marked this as done in my TODO
list, but never actually sent it out. It's all been in linux-next for at
least two weeks, so I don't expect any surprises.

Thanks,
Thierry


drm/panel: Changes for v4.6-rc1

This contains a refactoring of parts of the DSI core to allow creating
DSI devices from non-DSI control busses (i.e. I2C, SPI, ...).

Other than that there's support for a couple of new panels as well as
a few cleanup patches.


Akshay Bhat (1):
  drm/panel: simple: Fix g121x1_l03 hsync/vsync polarity

Archit Taneja (5):
  drm/dsi: Check for CONFIG_OF when defining of_mipi_dsi_device_add()
  drm/dsi: Use mipi_dsi_device_register_full() for DSI device creation
  drm/dsi: Try to match non-DT DSI devices
  drm/dsi: Add routine to unregister a DSI device
  drm/dsi: Get DSI host by DT device node

Jitao Shi (2):
  dt-bindings: Add LG lp120up1 panel bindings
  drm/panel: simple: Support for LG lp120up1 panel

Laurent Pinchart (1):
  drm/bridge: Make (pre/post) enable/disable callbacks optional

Maciej S. Szmigiero (3):
  of: Add United Radiant Technology Corporation vendor prefix
  dt-bindings: Add URT UMSH-8596MD-xT panel bindings
  drm/panel: simple: Add URT UMSH-8596MD-xT panels support

 .../bindings/display/panel/lg,lp120up1.txt |   7 ++
 .../bindings/display/panel/urt,umsh-8596md.txt |  16 +++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 drivers/gpu/drm/drm_bridge.c   |  12 +-
 drivers/gpu/drm/drm_mipi_dsi.c | 127 +++--
 drivers/gpu/drm/panel/panel-simple.c   |  81 +
 include/drm/drm_crtc.h |   8 ++
 include/drm/drm_mipi_dsi.h |  26 +
 8 files changed, 262 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/lg,lp120up1.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt


[PATCH 2/2] amdgpu: add amdgpu_create_bo_from_userptr() v2

2016-03-16 Thread Christian König
From: Christian König 

We somehow forgot the flags paramter in amdgpu_create_bo_from_user_mem(). Fix
that with a new function.

v2: fix typo in function name

Signed-off-by: Christian König 
Reviewed-by: Michel Dänzer  (v1)
---
 amdgpu/amdgpu.h|  8 
 amdgpu/amdgpu_bo.c | 26 ++
 2 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 0851306..be7b924 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -637,6 +637,7 @@ int amdgpu_bo_import(amdgpu_device_handle dev,
  * want to map to GPU address space (make GPU accessible)
  * (This address must be correctly aligned).
  * \param size - [in] Size of allocation (must be correctly aligned)
+ * \param flags - [in] AMDGPU_GEM_USERPTR_* flags for userptr
  * \param buf_handle - [out] Buffer handle for the userptr memory
  * resource on submission and be used in other operations.
  *
@@ -660,6 +661,13 @@ int amdgpu_bo_import(amdgpu_device_handle dev,
  * It is responsibility of caller to correctly specify access rights
  * on VA assignment.
 */
+int amdgpu_create_bo_from_userptr(amdgpu_device_handle dev,
+ void *cpu, uint64_t size, uint32_t flags,
+ amdgpu_bo_handle *buf_handle);
+
+/**
+ * Deprecated, don't use for new implementations
+ */
 int amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
void *cpu, uint64_t size,
amdgpu_bo_handle *buf_handle);
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index d30fd1e..e150376 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -529,18 +529,16 @@ int amdgpu_bo_wait_for_idle(amdgpu_bo_handle bo,
}
 }

-int amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
-   void *cpu,
-   uint64_t size,
-   amdgpu_bo_handle *buf_handle)
+int amdgpu_create_bo_from_userptr(amdgpu_device_handle dev,
+ void *cpu, uint64_t size, uint32_t flags,
+ amdgpu_bo_handle *buf_handle)
 {
-   int r;
-   struct amdgpu_bo *bo;
struct drm_amdgpu_gem_userptr args;
+   struct amdgpu_bo *bo;
+   int r;

args.addr = (uintptr_t)cpu;
-   args.flags = AMDGPU_GEM_USERPTR_ANONONLY | AMDGPU_GEM_USERPTR_REGISTER |
-   AMDGPU_GEM_USERPTR_VALIDATE;
+   args.flags = flags;
args.size = size;
r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_GEM_USERPTR,
&args, sizeof(args));
@@ -561,6 +559,18 @@ int amdgpu_create_bo_from_user_mem(amdgpu_device_handle 
dev,
return r;
 }

+int amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
+  void *cpu, uint64_t size,
+  amdgpu_bo_handle *buf_handle)
+{
+   uint32_t flags = AMDGPU_GEM_USERPTR_ANONONLY |
+   AMDGPU_GEM_USERPTR_REGISTER |
+   AMDGPU_GEM_USERPTR_VALIDATE;
+
+   return amdgpu_create_bo_from_userptr(dev, cpu, size,
+flags, buf_handle);
+}
+
 int amdgpu_bo_list_create(amdgpu_device_handle dev,
  uint32_t number_of_resources,
  amdgpu_bo_handle *resources,
-- 
2.5.0



[PATCH 1/2] amdgpu: create only one IB for "all compute queues" tests

2016-03-16 Thread Christian König
From: Christian König 

It's simpler and allows us to test VMID sharing between
between the compute queues as well.

Signed-off-by: Christian König 
---
 tests/amdgpu/basic_tests.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index 4ef6014..d2086ce 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -620,25 +620,25 @@ static void amdgpu_command_submission_compute(void)
r = amdgpu_cs_ctx_create(device_handle, &context_handle);
CU_ASSERT_EQUAL(r, 0);

-   for (instance = 0; instance < 8; instance++) {
-   r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
-   AMDGPU_GEM_DOMAIN_GTT, 0,
-   &ib_result_handle, &ib_result_cpu,
-   &ib_result_mc_address, &va_handle);
-   CU_ASSERT_EQUAL(r, 0);
+   r = amdgpu_bo_alloc_and_map(device_handle, 4096, 4096,
+   AMDGPU_GEM_DOMAIN_GTT, 0,
+   &ib_result_handle, &ib_result_cpu,
+   &ib_result_mc_address, &va_handle);
+   CU_ASSERT_EQUAL(r, 0);

-   r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
+   r = amdgpu_get_bo_list(device_handle, ib_result_handle, NULL,
   &bo_list);
-   CU_ASSERT_EQUAL(r, 0);
+   CU_ASSERT_EQUAL(r, 0);

-   ptr = ib_result_cpu;
-   for (i = 0; i < 16; ++i)
-   ptr[i] = 0x1000;
+   ptr = ib_result_cpu;
+   for (i = 0; i < 16; ++i)
+   ptr[i] = 0x1000;

-   memset(&ib_info, 0, sizeof(struct amdgpu_cs_ib_info));
-   ib_info.ib_mc_address = ib_result_mc_address;
-   ib_info.size = 16;
+   memset(&ib_info, 0, sizeof(struct amdgpu_cs_ib_info));
+   ib_info.ib_mc_address = ib_result_mc_address;
+   ib_info.size = 16;

+   for (instance = 0; instance < 8; instance++) {
memset(&ibs_request, 0, sizeof(struct amdgpu_cs_request));
ibs_request.ip_type = AMDGPU_HW_IP_COMPUTE;
ibs_request.ring = instance;
@@ -660,14 +660,14 @@ static void amdgpu_command_submission_compute(void)
 AMDGPU_TIMEOUT_INFINITE,
 0, &expired);
CU_ASSERT_EQUAL(r, 0);
+   }

-   r = amdgpu_bo_list_destroy(bo_list);
-   CU_ASSERT_EQUAL(r, 0);
+   r = amdgpu_bo_list_destroy(bo_list);
+   CU_ASSERT_EQUAL(r, 0);

-   r = amdgpu_bo_unmap_and_free(ib_result_handle, va_handle,
-ib_result_mc_address, 4096);
-   CU_ASSERT_EQUAL(r, 0);
-   }
+   r = amdgpu_bo_unmap_and_free(ib_result_handle, va_handle,
+ib_result_mc_address, 4096);
+   CU_ASSERT_EQUAL(r, 0);

r = amdgpu_cs_ctx_free(context_handle);
CU_ASSERT_EQUAL(r, 0);
-- 
2.5.0



EXTENDED: 2016 X.Org Board of Directors Elections Nomination period is NOW

2016-03-16 Thread Luc Verhaegen
On Wed, Mar 16, 2016 at 04:03:08PM +1000, Peter Hutterer wrote:
> We had a number of last-minute nominations and this did not give all nominees
> the chance to respond to the nominations.

Sheepish Verhaegen.


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

2016-03-16 Thread Thierry Reding
Hi Dave,

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:

  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)

are available in the git repository at:

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

for you to fetch changes up to 341917fe2b62876599315a537b8e248e31bd1366:

  gpu: host1x: Use a signed return type for do_relocs() (2016-03-16 13:45:44 
+0100)

Sorry, I had this marked as done on my TODO list, but now realized I
hadn't sent it out after all. It's fairly tiny, so hopefully okay.

Thanks,
Thierry


drm/tegra: Changes for v4.6-rc1

Only two cleanups this time around. One fixes reference counting of
device tree nodes, the other changes the return value of a function
from an unsigned int to an int to reflect that it will return error
codes.


Amitoj Kaur Chawla (1):
  gpu: host1x: bus: Add missing of_node_put()

Markus Elfring (1):
  gpu: host1x: Use a signed return type for do_relocs()

 drivers/gpu/host1x/bus.c | 4 +++-
 drivers/gpu/host1x/job.c | 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)


[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

2016-03-16 Thread Jérôme Glisse
From: Jérome Glisse 

This consolidate uvd/vce into a common shape for all generation. It
also leverage the rdev->has_uvd flags to know what it is useless to
try to resume/suspend uvd/vce block.

There is no functional changes when there is no error. On error the
device driver will behave differently than before after this patch.
It should now safely ignore uvd/vce errors and keeps normal operation
of others engine. This is an improvement over current situation where
we have different behavior depending on GPU generation and on what
fails.

Finaly this is a preparatory step for a patch which allow to disable
uvd/vce as a driver option.

This have only been tested on southern island so please test it on
other generations (i do not have hardware handy for now).

Signed-off-by: Jérôme Glisse 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/radeon/cik.c   | 226 ++
 drivers/gpu/drm/radeon/evergreen.c | 122 ++-
 drivers/gpu/drm/radeon/ni.c| 240 +
 drivers/gpu/drm/radeon/r600.c  | 113 -
 drivers/gpu/drm/radeon/rv770.c | 122 ++-
 drivers/gpu/drm/radeon/si.c| 213 
 drivers/gpu/drm/radeon/uvd_v4_2.c  |   5 +
 7 files changed, 724 insertions(+), 317 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index f2a4c0f..489e202 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -8496,6 +8496,142 @@ restart_ih:
 /*
  * startup/shutdown callbacks
  */
+
+static void cik_uvd_vce_init(struct radeon_device *rdev)
+{
+   struct radeon_ring *ring;
+   int r;
+
+   if (!rdev->has_uvd)
+   return;
+
+   r = radeon_uvd_init(rdev);
+   if (r)
+   goto error_uvd;
+   ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
+   ring->ring_obj = NULL;
+   r600_ring_init(rdev, ring, 4096);
+
+   r = radeon_vce_init(rdev);
+   if (r)
+   goto error_vce;
+   ring = &rdev->ring[TN_RING_TYPE_VCE1_INDEX];
+   ring->ring_obj = NULL;
+   r600_ring_init(rdev, ring, 4096);
+   ring = &rdev->ring[TN_RING_TYPE_VCE2_INDEX];
+   ring->ring_obj = NULL;
+   r600_ring_init(rdev, ring, 4096);
+
+   return;
+
+error_vce:
+   radeon_uvd_fini(rdev);
+error_uvd:
+   dev_err(rdev->dev, "UVD/VCE init error (%d).\n", r);
+   /* On error just disable everything. */
+   rdev->has_uvd = 0;
+}
+
+static void cik_uvd_vce_startup(struct radeon_device *rdev)
+{
+   int r;
+
+   if (!rdev->has_uvd)
+   return;
+
+   r = uvd_v4_2_resume(rdev);
+   if (r)
+   goto error;
+   r = radeon_fence_driver_start_ring(rdev, R600_RING_TYPE_UVD_INDEX);
+   if (r)
+   goto error_uvd;
+
+   r = radeon_vce_resume(rdev);
+   if (r)
+   goto error_uvd;
+   r = vce_v2_0_resume(rdev);
+   if (r)
+   goto error_vce;
+   r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE1_INDEX);
+   if (r)
+   goto error_vce;
+   r = radeon_fence_driver_start_ring(rdev, TN_RING_TYPE_VCE2_INDEX);
+   if (r)
+   goto error_vce;
+
+   return;
+
+error_vce:
+   radeon_vce_suspend(rdev);
+error_uvd:
+   radeon_uvd_suspend(rdev);
+error:
+   dev_err(rdev->dev, "UVD/VCE startup error (%d).\n", r);
+   /* On error just disable everything. */
+   radeon_vce_fini(rdev);
+   radeon_uvd_fini(rdev);
+   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
+   rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
+   rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
+   rdev->has_uvd = 0;
+}
+
+static void cik_uvd_vce_resume(struct radeon_device *rdev)
+{
+   struct radeon_ring *ring;
+   int r;
+
+   if (!rdev->has_uvd)
+   return;
+
+   /* On uvd/vce error we disable uvd/vce so we should have bail above. */
+   BUG_ON(!rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size);
+   BUG_ON(!rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size);
+   BUG_ON(!rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size);
+
+   ring = &rdev->ring[R600_RING_TYPE_UVD_INDEX];
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, RADEON_CP_PACKET2);
+   if (r)
+   goto error;
+   r = uvd_v1_0_init(rdev);
+   if (r)
+   goto error_uvd;
+
+   ring = &rdev->ring[TN_RING_TYPE_VCE1_INDEX];
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, VCE_CMD_NO_OP);
+   if (r)
+   goto error_vce1;
+   ring = &rdev->ring[TN_RING_TYPE_VCE2_INDEX];
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, VCE_CMD_NO_OP);
+   if (r)
+   goto error_vce2;
+   r = vce_v1_0_init(rdev);
+   if (r)
+   goto error_vce;
+
+   return;
+
+error_vce:
+   radeon_ring_fini(rdev, &rde

[PATCH 3/3] drm/radeon: uvd/vce properly pin/unpin firmware accross suspend/resume.

2016-03-16 Thread Christian König
Am 16.03.2016 um 13:35 schrieb Jerome Glisse:
> On Wed, Mar 16, 2016 at 1:10 PM, Christian König
>  wrote:
>> Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
>>> From: Jérome Glisse 
>>>
>>> We need to unpin on suspend and pin on resume. This shuffle code around
>>> to do just that.
>>>
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Alex Deucher 
>>> Cc: Christian König 
>>
>> NAK, that won't work correctly.
>>
>> When the firmware is loaded at one location once you can't move it without
>> power cycling the ASIC.
>>
>> That only works when you completely shut down the system, but not if you
>> just suspend to memory on an APU or do a test cycle without actually power
>> down.
>>
>> We already tried this approach and it took me month to figure out what's
>> going wrong when the firmware end up at a different location after the
>> driver started again.
>>
>> Regards,
>> Christian.
> Well that exactly what happens on hibernation. The firmware keycheck
> is failing and vce breaks. I have been trying to make it works but
> even putting it at same location is not enough. This is only an issue
> with hibernation, and module load/unload, suspend is fine as hw is
> powercycle. So this patch will not break anything that does already
> work. It only make code follow what other part of the code does.

Take a look at the history of the UVD code. We already had it this way 
and changed it because that fixed suspend/resume for a lot of people.

Additional to that keeping the firmware at the same location is the 
documented behavior how the hardware should be programmed.

For Amdgpu Leo even had it working that UVD sessions survive a 
suspend/resume cycle, but we haven't dared to enable that for everything 
again because of all the problems testing it.

Regards,
Christian.

>
> Cheers,
> Jérôme
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



[PATCH 2/3] drm/radeon: add driver option to disable uvd/vce block.

2016-03-16 Thread Jerome Glisse
On Wed, Mar 16, 2016 at 1:20 PM, Christian König
 wrote:
> Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
>>
>> From: Jérome Glisse 
>>
>> Quite few suspend/hibernation bugs are related to this block. Add
>> an option to disable those as a work around.
>>
>> Signed-off-by: Jérôme Glisse 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>
>
> Reviewed-by: Christian König 
>

Well this patch is kind of useless without the patch i forgot to sent,
i am gonna send it in a bit once i tested drm-next-4.6 with it.

Cheers,
Jérôme


[PATCH 3/3] drm/radeon: uvd/vce properly pin/unpin firmware accross suspend/resume.

2016-03-16 Thread Jerome Glisse
On Wed, Mar 16, 2016 at 1:10 PM, Christian König
 wrote:
> Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
>>
>> From: Jérome Glisse 
>>
>> We need to unpin on suspend and pin on resume. This shuffle code around
>> to do just that.
>>
>> Signed-off-by: Jérôme Glisse 
>> Cc: Alex Deucher 
>> Cc: Christian König 
>
>
> NAK, that won't work correctly.
>
> When the firmware is loaded at one location once you can't move it without
> power cycling the ASIC.
>
> That only works when you completely shut down the system, but not if you
> just suspend to memory on an APU or do a test cycle without actually power
> down.
>
> We already tried this approach and it took me month to figure out what's
> going wrong when the firmware end up at a different location after the
> driver started again.
>
> Regards,
> Christian.

Well that exactly what happens on hibernation. The firmware keycheck
is failing and vce breaks. I have been trying to make it works but
even putting it at same location is not enough. This is only an issue
with hibernation, and module load/unload, suspend is fine as hw is
powercycle. So this patch will not break anything that does already
work. It only make code follow what other part of the code does.

Cheers,
Jérôme


[PATCH 2/3] drm/radeon: add driver option to disable uvd/vce block.

2016-03-16 Thread Christian König
Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
> From: Jérome Glisse 
>
> Quite few suspend/hibernation bugs are related to this block. Add
> an option to disable those as a work around.
>
> Signed-off-by: Jérôme Glisse 
> Cc: Alex Deucher 
> Cc: Christian König 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/radeon/radeon.h  | 1 +
>   drivers/gpu/drm/radeon/radeon_asic.c | 3 +++
>   drivers/gpu/drm/radeon/radeon_drv.c  | 4 
>   3 files changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 007be29..5c6ce3a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -113,6 +113,7 @@ extern int radeon_bapm;
>   extern int radeon_backlight;
>   extern int radeon_auxch;
>   extern int radeon_mst;
> +extern int radeon_uvd;
>   
>   /*
>* Copy from radeon_drv.h so we don't have to include both and have 
> conflicting
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 7d5a36d..49ee180 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -2689,6 +2689,9 @@ int radeon_asic_init(struct radeon_device *rdev)
>   rdev->asic->pm.set_memory_clock = NULL;
>   }
>   
> + if (!radeon_uvd)
> + rdev->has_uvd = false;
> +
>   return 0;
>   }
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index cad2555..03e4781 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -196,6 +196,7 @@ int radeon_bapm = -1;
>   int radeon_backlight = -1;
>   int radeon_auxch = -1;
>   int radeon_mst = 0;
> +int radeon_uvd = 1;
>   
>   MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
>   module_param_named(no_wb, radeon_no_wb, int, 0444);
> @@ -287,6 +288,9 @@ module_param_named(auxch, radeon_auxch, int, 0444);
>   MODULE_PARM_DESC(mst, "DisplayPort MST experimental support (1 = enable, 0 
> = disable)");
>   module_param_named(mst, radeon_mst, int, 0444);
>   
> +MODULE_PARM_DESC(uvd, "uvd/vce enable/disable uvd/vce support (1 = enable, 0 
> = disable)");
> +module_param_named(uvd, radeon_uvd, int, 0444);
> +
>   static struct pci_device_id pciidlist[] = {
>   radeon_PCI_IDS
>   };



[PATCH 1/3] drm/radeon: fix indentation.

2016-03-16 Thread Christian König
Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
> From: Jérome Glisse 
>
> I hate doing this but it hurts my eyes to go over code that does not
> comply with indentation rules. Only thing that is not only space change
> is in atom.c all other files are space indentation issues.
>
> Signed-off-by: Jérôme Glisse 
> Cc: Alex Deucher 

Oh, yes please. Patch is Acked-by: Christian König 
.

> ---
>   drivers/gpu/drm/radeon/atom.c   |   7 +-
>   drivers/gpu/drm/radeon/atombios_crtc.c  |   6 +-
>   drivers/gpu/drm/radeon/atombios_dp.c|   4 +-
>   drivers/gpu/drm/radeon/btc_dpm.c|  41 +++---
>   drivers/gpu/drm/radeon/ci_dpm.c |  42 +++---
>   drivers/gpu/drm/radeon/ci_smc.c |   8 +-
>   drivers/gpu/drm/radeon/cik.c|   6 +-
>   drivers/gpu/drm/radeon/cypress_dpm.c|   8 +-
>   drivers/gpu/drm/radeon/evergreen.c  |   2 +-
>   drivers/gpu/drm/radeon/evergreen_cs.c   |  32 ++---
>   drivers/gpu/drm/radeon/evergreen_hdmi.c |   2 +-
>   drivers/gpu/drm/radeon/kv_dpm.c |   4 +-
>   drivers/gpu/drm/radeon/ni.c |   4 +-
>   drivers/gpu/drm/radeon/ni_dpm.c | 170 
> 
>   drivers/gpu/drm/radeon/r600.c   |   8 +-
>   drivers/gpu/drm/radeon/r600_cs.c|  20 +--
>   drivers/gpu/drm/radeon/r600_dpm.c   |   6 +-
>   drivers/gpu/drm/radeon/r600_hdmi.c  |   4 +-
>   drivers/gpu/drm/radeon/radeon_atombios.c|   6 +-
>   drivers/gpu/drm/radeon/radeon_device.c  |   8 +-
>   drivers/gpu/drm/radeon/radeon_display.c |   6 +-
>   drivers/gpu/drm/radeon/radeon_fb.c  |   6 +-
>   drivers/gpu/drm/radeon/radeon_ib.c  |   4 +-
>   drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  92 ++---
>   drivers/gpu/drm/radeon/radeon_object.c  |   6 +-
>   drivers/gpu/drm/radeon/radeon_pm.c  |   2 +-
>   drivers/gpu/drm/radeon/radeon_semaphore.c   |   4 +-
>   drivers/gpu/drm/radeon/radeon_uvd.c |   8 +-
>   drivers/gpu/drm/radeon/radeon_vce.c |  22 +--
>   drivers/gpu/drm/radeon/radeon_vm.c  |  19 +--
>   drivers/gpu/drm/radeon/rs780_dpm.c  |   2 +-
>   drivers/gpu/drm/radeon/rv6xx_dpm.c  |  18 +--
>   drivers/gpu/drm/radeon/rv740_dpm.c  |  16 +--
>   drivers/gpu/drm/radeon/rv770_dpm.c  |  46 +++
>   drivers/gpu/drm/radeon/si.c |  44 +++---
>   drivers/gpu/drm/radeon/si_dpm.c |  98 +++---
>   drivers/gpu/drm/radeon/sumo_dpm.c   |   6 +-
>   drivers/gpu/drm/radeon/trinity_dpm.c|  24 ++--
>   drivers/gpu/drm/radeon/vce_v2_0.c   |   2 +-
>   39 files changed, 407 insertions(+), 406 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index ec1593a..f66c33d 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -66,9 +66,10 @@ int atom_debug = 0;
>   static int atom_execute_table_locked(struct atom_context *ctx, int index, 
> uint32_t * params);
>   int atom_execute_table(struct atom_context *ctx, int index, uint32_t * 
> params);
>   
> -static uint32_t atom_arg_mask[8] =
> -{ 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
> -0xFF00 };
> +static uint32_t atom_arg_mask[8] = {
> + 0x, 0x, 0x0000, 0x,
> + 0x00FF, 0xFF00, 0x00FF, 0xFF00
> +};
>   static int atom_arg_shift[8] = { 0, 0, 8, 16, 0, 8, 16, 24 };
>   
>   static int atom_dst_to_src[8][4] = {
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index e187bec..cf61e08 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1665,11 +1665,11 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int 
> x, int y,
>   }
>   
>   int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
> -  struct drm_framebuffer *fb,
> +   struct drm_framebuffer *fb,
> int x, int y, enum mode_set_atomic state)
>   {
> -   struct drm_device *dev = crtc->dev;
> -   struct radeon_device *rdev = dev->dev_private;
> + struct drm_device *dev = crtc->dev;
> + struct radeon_device *rdev = dev->dev_private;
>   
>   if (ASIC_IS_DCE4(rdev))
>   return dce4_crtc_do_set_base(crtc, fb, x, y, 1);
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 44ee72e..ae1ab4d 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -37,10 +37,10 @@
>   #define DP_DPCD_SIZE DP_RECEIVER_CAP_SIZE
>   
>   static char *voltage_names[] = {
> -"0.4V", "0.6V", "0.8V",

[PATCH 3/3] drm/radeon: uvd/vce properly pin/unpin firmware accross suspend/resume.

2016-03-16 Thread Christian König
Am 16.03.2016 um 12:56 schrieb jglisse at redhat.com:
> From: Jérome Glisse 
>
> We need to unpin on suspend and pin on resume. This shuffle code around
> to do just that.
>
> Signed-off-by: Jérôme Glisse 
> Cc: Alex Deucher 
> Cc: Christian König 

NAK, that won't work correctly.

When the firmware is loaded at one location once you can't move it 
without power cycling the ASIC.

That only works when you completely shut down the system, but not if you 
just suspend to memory on an APU or do a test cycle without actually 
power down.

We already tried this approach and it took me month to figure out what's 
going wrong when the firmware end up at a different location after the 
driver started again.

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_uvd.c | 61 
> -
>   drivers/gpu/drm/radeon/radeon_vce.c | 37 +-
>   2 files changed, 41 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 6fe9e4e..333b885 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -148,30 +148,6 @@ int radeon_uvd_init(struct radeon_device *rdev)
>   return r;
>   }
>   
> - r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
> - if (r) {
> - radeon_bo_unref(&rdev->uvd.vcpu_bo);
> - dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
> - return r;
> - }
> -
> - r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
> -   &rdev->uvd.gpu_addr);
> - if (r) {
> - radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> - radeon_bo_unref(&rdev->uvd.vcpu_bo);
> - dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
> - return r;
> - }
> -
> - r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
> - if (r) {
> - dev_err(rdev->dev, "(%d) UVD map failed\n", r);
> - return r;
> - }
> -
> - radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> -
>   for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
>   atomic_set(&rdev->uvd.handles[i], 0);
>   rdev->uvd.filp[i] = NULL;
> @@ -183,18 +159,9 @@ int radeon_uvd_init(struct radeon_device *rdev)
>   
>   void radeon_uvd_fini(struct radeon_device *rdev)
>   {
> - int r;
> -
>   if (rdev->uvd.vcpu_bo == NULL)
>   return;
>   
> - r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
> - if (!r) {
> - radeon_bo_kunmap(rdev->uvd.vcpu_bo);
> - radeon_bo_unpin(rdev->uvd.vcpu_bo);
> - radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> - }
> -
>   radeon_bo_unref(&rdev->uvd.vcpu_bo);
>   
>   radeon_ring_fini(rdev, &rdev->ring[R600_RING_TYPE_UVD_INDEX]);
> @@ -231,6 +198,13 @@ int radeon_uvd_suspend(struct radeon_device *rdev)
>   }
>   }
>   
> + r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
> + if (!r) {
> + radeon_bo_kunmap(rdev->uvd.vcpu_bo);
> + radeon_bo_unpin(rdev->uvd.vcpu_bo);
> + radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> + }
> +
>   return 0;
>   }
>   
> @@ -238,9 +212,26 @@ int radeon_uvd_resume(struct radeon_device *rdev)
>   {
>   unsigned size;
>   void *ptr;
> + int r;
>   
> - if (rdev->uvd.vcpu_bo == NULL)
> - return -EINVAL;
> + r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
> + if (r) {
> + dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
> + return r;
> + }
> + r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
> +   &rdev->uvd.gpu_addr);
> + if (r) {
> + radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> + dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
> + return r;
> + }
> + r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
> + radeon_bo_unreserve(rdev->uvd.vcpu_bo);
> + if (r) {
> + dev_err(rdev->dev, "(%d) UVD map failed\n", r);
> + return r;
> + }
>   
>   memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
>   
> diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
> b/drivers/gpu/drm/radeon/radeon_vce.c
> index c1c619f..4f7ae3c 100644
> --- a/drivers/gpu/drm/radeon/radeon_vce.c
> +++ b/drivers/gpu/drm/radeon/radeon_vce.c
> @@ -147,22 +147,6 @@ int radeon_vce_init(struct radeon_device *rdev)
>   return r;
>   }
>   
> - r = radeon_bo_reserve(rdev->vce.vcpu_bo, false);
> - if (r) {
> - radeon_bo_unref(&rdev->vce.vcpu_bo);
> - dev_err(rdev->dev, "(%d) failed to reserve VCE bo\n", r);
> - return r;
> - }
> -
> - r = radeon_bo_pin(rdev->vce.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
> -   &rdev->vce.gpu_addr);
> - radeon_bo_unreserve(rdev->vce.vcpu_bo);
> - if (r) {
> -   

i386 allyesconfig: gfx_v7_0_ring_emit_vm_flush

2016-03-16 Thread Borislav Petkov
Hey Alex,

I see this on a 32-bit, allyesconfig build today:

drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function 
‘gfx_v7_0_ring_emit_vm_flush’:
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3631:17: warning: initialization makes 
integer from pointer without a cast [-Wint-conversion]
  uint32_t seq = ring->fence_drv.sync_seq;
 ^
-- 
Regards/Gruss,
Boris.

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


[PULL] drm-intel-next-fixes

2016-03-16 Thread Jani Nikula

Hi Dave, I'll just flush this one out of the way.

BR,
Jani.

The following changes since commit f2c488212b511f7eadef78c564f1bff8f64db231:

  Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-next 
(2016-03-14 10:49:40 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2016-03-16

for you to fetch changes up to 94669e6ba1ada133394ec8295d773df8b9238d08:

  drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect. (2016-03-14 
10:50:58 +0200)


Maarten Lankhorst (1):
  drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect.

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

-- 
Jani Nikula, Intel Open Source Technology Center


[PATCH 3/3] drm/radeon: uvd/vce properly pin/unpin firmware accross suspend/resume.

2016-03-16 Thread jgli...@redhat.com
From: Jérome Glisse 

We need to unpin on suspend and pin on resume. This shuffle code around
to do just that.

Signed-off-by: Jérôme Glisse 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/radeon/radeon_uvd.c | 61 -
 drivers/gpu/drm/radeon/radeon_vce.c | 37 +-
 2 files changed, 41 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 6fe9e4e..333b885 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -148,30 +148,6 @@ int radeon_uvd_init(struct radeon_device *rdev)
return r;
}

-   r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
-   if (r) {
-   radeon_bo_unref(&rdev->uvd.vcpu_bo);
-   dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
-   return r;
-   }
-
-   r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
- &rdev->uvd.gpu_addr);
-   if (r) {
-   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
-   radeon_bo_unref(&rdev->uvd.vcpu_bo);
-   dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
-   return r;
-   }
-
-   r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
-   if (r) {
-   dev_err(rdev->dev, "(%d) UVD map failed\n", r);
-   return r;
-   }
-
-   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
-
for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
atomic_set(&rdev->uvd.handles[i], 0);
rdev->uvd.filp[i] = NULL;
@@ -183,18 +159,9 @@ int radeon_uvd_init(struct radeon_device *rdev)

 void radeon_uvd_fini(struct radeon_device *rdev)
 {
-   int r;
-
if (rdev->uvd.vcpu_bo == NULL)
return;

-   r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
-   if (!r) {
-   radeon_bo_kunmap(rdev->uvd.vcpu_bo);
-   radeon_bo_unpin(rdev->uvd.vcpu_bo);
-   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
-   }
-
radeon_bo_unref(&rdev->uvd.vcpu_bo);

radeon_ring_fini(rdev, &rdev->ring[R600_RING_TYPE_UVD_INDEX]);
@@ -231,6 +198,13 @@ int radeon_uvd_suspend(struct radeon_device *rdev)
}
}

+   r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
+   if (!r) {
+   radeon_bo_kunmap(rdev->uvd.vcpu_bo);
+   radeon_bo_unpin(rdev->uvd.vcpu_bo);
+   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
+   }
+
return 0;
 }

@@ -238,9 +212,26 @@ int radeon_uvd_resume(struct radeon_device *rdev)
 {
unsigned size;
void *ptr;
+   int r;

-   if (rdev->uvd.vcpu_bo == NULL)
-   return -EINVAL;
+   r = radeon_bo_reserve(rdev->uvd.vcpu_bo, false);
+   if (r) {
+   dev_err(rdev->dev, "(%d) failed to reserve UVD bo\n", r);
+   return r;
+   }
+   r = radeon_bo_pin(rdev->uvd.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
+ &rdev->uvd.gpu_addr);
+   if (r) {
+   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
+   dev_err(rdev->dev, "(%d) UVD bo pin failed\n", r);
+   return r;
+   }
+   r = radeon_bo_kmap(rdev->uvd.vcpu_bo, &rdev->uvd.cpu_addr);
+   radeon_bo_unreserve(rdev->uvd.vcpu_bo);
+   if (r) {
+   dev_err(rdev->dev, "(%d) UVD map failed\n", r);
+   return r;
+   }

memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);

diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index c1c619f..4f7ae3c 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -147,22 +147,6 @@ int radeon_vce_init(struct radeon_device *rdev)
return r;
}

-   r = radeon_bo_reserve(rdev->vce.vcpu_bo, false);
-   if (r) {
-   radeon_bo_unref(&rdev->vce.vcpu_bo);
-   dev_err(rdev->dev, "(%d) failed to reserve VCE bo\n", r);
-   return r;
-   }
-
-   r = radeon_bo_pin(rdev->vce.vcpu_bo, RADEON_GEM_DOMAIN_VRAM,
- &rdev->vce.gpu_addr);
-   radeon_bo_unreserve(rdev->vce.vcpu_bo);
-   if (r) {
-   radeon_bo_unref(&rdev->vce.vcpu_bo);
-   dev_err(rdev->dev, "(%d) VCE bo pin failed\n", r);
-   return r;
-   }
-
for (i = 0; i < RADEON_MAX_VCE_HANDLES; ++i) {
atomic_set(&rdev->vce.handles[i], 0);
rdev->vce.filp[i] = NULL;
@@ -196,7 +180,7 @@ void radeon_vce_fini(struct radeon_device *rdev)
  */
 int radeon_vce_suspend(struct radeon_device *rdev)
 {
-   int i;
+   int i, r;

if (rdev->vce.vcpu_bo == NULL)
return 0;
@@ -209,6 +193,13 @@ int radeon_vce_suspend(struct radeon_device *rdev)
return 0;

/* TODO: suspending runni

[PATCH 2/3] drm/radeon: add driver option to disable uvd/vce block.

2016-03-16 Thread jgli...@redhat.com
From: Jérome Glisse 

Quite few suspend/hibernation bugs are related to this block. Add
an option to disable those as a work around.

Signed-off-by: Jérôme Glisse 
Cc: Alex Deucher 
Cc: Christian König 
---
 drivers/gpu/drm/radeon/radeon.h  | 1 +
 drivers/gpu/drm/radeon/radeon_asic.c | 3 +++
 drivers/gpu/drm/radeon/radeon_drv.c  | 4 
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 007be29..5c6ce3a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -113,6 +113,7 @@ extern int radeon_bapm;
 extern int radeon_backlight;
 extern int radeon_auxch;
 extern int radeon_mst;
+extern int radeon_uvd;

 /*
  * Copy from radeon_drv.h so we don't have to include both and have conflicting
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index 7d5a36d..49ee180 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -2689,6 +2689,9 @@ int radeon_asic_init(struct radeon_device *rdev)
rdev->asic->pm.set_memory_clock = NULL;
}

+   if (!radeon_uvd)
+   rdev->has_uvd = false;
+
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index cad2555..03e4781 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -196,6 +196,7 @@ int radeon_bapm = -1;
 int radeon_backlight = -1;
 int radeon_auxch = -1;
 int radeon_mst = 0;
+int radeon_uvd = 1;

 MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
 module_param_named(no_wb, radeon_no_wb, int, 0444);
@@ -287,6 +288,9 @@ module_param_named(auxch, radeon_auxch, int, 0444);
 MODULE_PARM_DESC(mst, "DisplayPort MST experimental support (1 = enable, 0 = 
disable)");
 module_param_named(mst, radeon_mst, int, 0444);

+MODULE_PARM_DESC(uvd, "uvd/vce enable/disable uvd/vce support (1 = enable, 0 = 
disable)");
+module_param_named(uvd, radeon_uvd, int, 0444);
+
 static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
 };
-- 
1.8.3.1



[PATCH 1/3] drm/radeon: fix indentation.

2016-03-16 Thread jgli...@redhat.com
From: Jérome Glisse 

I hate doing this but it hurts my eyes to go over code that does not
comply with indentation rules. Only thing that is not only space change
is in atom.c all other files are space indentation issues.

Signed-off-by: Jérôme Glisse 
Cc: Alex Deucher 
---
 drivers/gpu/drm/radeon/atom.c   |   7 +-
 drivers/gpu/drm/radeon/atombios_crtc.c  |   6 +-
 drivers/gpu/drm/radeon/atombios_dp.c|   4 +-
 drivers/gpu/drm/radeon/btc_dpm.c|  41 +++---
 drivers/gpu/drm/radeon/ci_dpm.c |  42 +++---
 drivers/gpu/drm/radeon/ci_smc.c |   8 +-
 drivers/gpu/drm/radeon/cik.c|   6 +-
 drivers/gpu/drm/radeon/cypress_dpm.c|   8 +-
 drivers/gpu/drm/radeon/evergreen.c  |   2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c   |  32 ++---
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   2 +-
 drivers/gpu/drm/radeon/kv_dpm.c |   4 +-
 drivers/gpu/drm/radeon/ni.c |   4 +-
 drivers/gpu/drm/radeon/ni_dpm.c | 170 
 drivers/gpu/drm/radeon/r600.c   |   8 +-
 drivers/gpu/drm/radeon/r600_cs.c|  20 +--
 drivers/gpu/drm/radeon/r600_dpm.c   |   6 +-
 drivers/gpu/drm/radeon/r600_hdmi.c  |   4 +-
 drivers/gpu/drm/radeon/radeon_atombios.c|   6 +-
 drivers/gpu/drm/radeon/radeon_device.c  |   8 +-
 drivers/gpu/drm/radeon/radeon_display.c |   6 +-
 drivers/gpu/drm/radeon/radeon_fb.c  |   6 +-
 drivers/gpu/drm/radeon/radeon_ib.c  |   4 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  92 ++---
 drivers/gpu/drm/radeon/radeon_object.c  |   6 +-
 drivers/gpu/drm/radeon/radeon_pm.c  |   2 +-
 drivers/gpu/drm/radeon/radeon_semaphore.c   |   4 +-
 drivers/gpu/drm/radeon/radeon_uvd.c |   8 +-
 drivers/gpu/drm/radeon/radeon_vce.c |  22 +--
 drivers/gpu/drm/radeon/radeon_vm.c  |  19 +--
 drivers/gpu/drm/radeon/rs780_dpm.c  |   2 +-
 drivers/gpu/drm/radeon/rv6xx_dpm.c  |  18 +--
 drivers/gpu/drm/radeon/rv740_dpm.c  |  16 +--
 drivers/gpu/drm/radeon/rv770_dpm.c  |  46 +++
 drivers/gpu/drm/radeon/si.c |  44 +++---
 drivers/gpu/drm/radeon/si_dpm.c |  98 +++---
 drivers/gpu/drm/radeon/sumo_dpm.c   |   6 +-
 drivers/gpu/drm/radeon/trinity_dpm.c|  24 ++--
 drivers/gpu/drm/radeon/vce_v2_0.c   |   2 +-
 39 files changed, 407 insertions(+), 406 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index ec1593a..f66c33d 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -66,9 +66,10 @@ int atom_debug = 0;
 static int atom_execute_table_locked(struct atom_context *ctx, int index, 
uint32_t * params);
 int atom_execute_table(struct atom_context *ctx, int index, uint32_t * params);

-static uint32_t atom_arg_mask[8] =
-{ 0x, 0x, 0x00, 0x, 0xFF, 0xFF00, 0xFF,
-0xFF00 };
+static uint32_t atom_arg_mask[8] = {
+   0x, 0x, 0x0000, 0x,
+   0x00FF, 0xFF00, 0x00FF, 0xFF00
+};
 static int atom_arg_shift[8] = { 0, 0, 8, 16, 0, 8, 16, 24 };

 static int atom_dst_to_src[8][4] = {
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index e187bec..cf61e08 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1665,11 +1665,11 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int 
x, int y,
 }

 int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
-  struct drm_framebuffer *fb,
+ struct drm_framebuffer *fb,
  int x, int y, enum mode_set_atomic state)
 {
-   struct drm_device *dev = crtc->dev;
-   struct radeon_device *rdev = dev->dev_private;
+   struct drm_device *dev = crtc->dev;
+   struct radeon_device *rdev = dev->dev_private;

if (ASIC_IS_DCE4(rdev))
return dce4_crtc_do_set_base(crtc, fb, x, y, 1);
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 44ee72e..ae1ab4d 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -37,10 +37,10 @@
 #define DP_DPCD_SIZE DP_RECEIVER_CAP_SIZE

 static char *voltage_names[] = {
-"0.4V", "0.6V", "0.8V", "1.2V"
+   "0.4V", "0.6V", "0.8V", "1.2V"
 };
 static char *pre_emph_names[] = {
-"0dB", "3.5dB", "6dB", "9.5dB"
+   "0dB", "3.5dB", "6dB", "9.5dB"
 };

 /* radeon AUX functions */
diff --git a/drivers/gpu/drm/radeon/btc_dpm.c b/drivers/gpu/drm/radeon/btc_dpm.c
index 69556f5..38e5123 100644
--- a/drivers/gpu/drm/radeon/btc_dpm.c
+

[RFC 0/5] drm: Add support for tiny LCD displays

2016-03-16 Thread Eric Anholt
Noralf Trønnes  writes:

> This is an attempt at providing a DRM version of drivers/staging/fbtft.
> I'm sending this early before cleaning up the code hoping to get some
> feedback in case there are better ways to structure this.
>
> The tinydrm module provides a very simplified view of DRM for displays that
> has onboard video memory and is connected through a slow bus like SPI/I2C.
> A driver using tinydrm has to provide a function that will be called from
> the dirtyfb ioctl and optionally drm_panel functions which can be used to
> set up the display controller and control backlight.
>
> tinydrm also has fbdev support using fb_deferred_io which is tied in through
> the dirtyfb function call. A driver can use the provided deferred work code
> to collect dirtyfb calls and schedule display memory updates if it whishes.
> The various display controllers can have library modules that handles
> display updates.
> Display controllers that have a similar register interface as the MIPI DBI/DCS
> controllers can use the lcdreg module for register access.
>
> struct tinydrm_device {
>   struct drm_device *base;
>   u32 width, height;
>   struct drm_panel panel;
> [...]
>   int (*dirtyfb)(struct drm_framebuffer *fb, void *vmem, unsigned flags,
>  unsigned color, struct drm_clip_rect *clips,
>  unsigned num_clips);
> };

This is awesome!

I was wondering, have you considered what it would take to DMA
framebuffer contents from somewhere in memory to these displays?  Does
that look doable to you?

I'd love to be able to do something PRIME-like where vc4's doing the
rendering and we're periodically updating the TFT with the result.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160316/d682246e/attachment.sig>


DRM framebuffer removal broken since 13803132

2016-03-16 Thread Thomas Hellstrom
On 03/16/2016 11:17 AM, Maarten Lankhorst wrote:
> Hey,
>
> Op 16-03-16 om 09:34 schreef Thomas Hellstrom:
>> Hi!
>>
>> The commit
>>
>> From 13803132818cf8084d169617be060fd8e3411a98 Mon Sep 17 00:00:00 2001
>> From: Maarten Lankhorst 
>> Date: Wed, 9 Sep 2015 16:40:56 +0200
>> Subject: [PATCH] drm/core: Preserve the framebuffer after removing it.
>>
>> badly breaks vmwgfx multimon since the crtcs are no longer turned off at
>> framebuffer removal,
>> which is part of the user-space contract.
> Is this about rmfb or lastclose?
>
> Lastclose is handled by kms fbdev emulation, rmfb behavioral change was 
> intentional, but can be reverted.

OK, this is about rmfb.

/Thomas



DRM framebuffer removal broken since 13803132

2016-03-16 Thread Maarten Lankhorst
Hey,

Op 16-03-16 om 09:34 schreef Thomas Hellstrom:
> Hi!
>
> The commit
>
> From 13803132818cf8084d169617be060fd8e3411a98 Mon Sep 17 00:00:00 2001
> From: Maarten Lankhorst 
> Date: Wed, 9 Sep 2015 16:40:56 +0200
> Subject: [PATCH] drm/core: Preserve the framebuffer after removing it.
>
> badly breaks vmwgfx multimon since the crtcs are no longer turned off at
> framebuffer removal,
> which is part of the user-space contract.
Is this about rmfb or lastclose?

Lastclose is handled by kms fbdev emulation, rmfb behavioral change was 
intentional, but can be reverted.
> Also isn't this a security issue, since at, for example, Xorg crash, the
> crtcs can be left scanning out from memory
> DRM no longer owns?
>
Not in general, the drivers I've worked with have the framebuffers holding a 
reference to the underlying
object storage. Else this would be a security issue without the rmfb behavior 
too.

~Maarten


[PULL] vmwgfx-next-160316

2016-03-16 Thread Thomas Hellstrom
The following changes since commit f2c488212b511f7eadef78c564f1bff8f64db231:

  Merge branch 'linux-4.6' of git://github.com/skeggsb/linux into drm-next 
(2016-03-14 10:49:40 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-next-160316

for you to fetch changes up to 5476aa46ff0377229f780c42e77b7e7e756040c7:

  drm/vmwgfx: Bump driver minor (2016-03-16 08:00:31 +0100)


Pull request of 2016-03-16


Charmaine Lee (1):
  drm/vmwgfx: Add DXGenMips support

Thomas Hellstrom (12):
  drm/vmwgfx: Fix a screen object framebuffer dirty corner case
  drm/vmwgfx: Fix screen object page flips for large framebuffers
  drm/vmwgfx: Rework screen target page flips v2
  drm/vmwgfx: Break out implicit fb code
  drm/vmwgfx: Add implicit framebuffer checks to the screen target code
  drm/vmwgfx: Add suggested screen x and y connector properties
  drm/vmwgfx: Add connector properties to switch between explicit and 
implicit placement
  drm/vmwgfx: Calculate the cursor position based on the crtc gui origin
  drm/vmwgfx: Default to explicit crtc placement for screen targets and 
screen objects
  drm/vmwgfx: Send a hotplug event at master_set
  drm/vmwgfx: Allow the UPDATE_LAYOUT ioctl from control nodes
  drm/vmwgfx: Bump driver minor

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   9 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |  22 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 163 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |  16 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  19 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 179 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c| 453 +++-
 8 files changed, 496 insertions(+), 368 deletions(-)


DRM framebuffer removal broken since 13803132

2016-03-16 Thread Thomas Hellstrom
Hi!

The commit