[Intel-gfx] [PATCH 03/14] drm: Link directly from drm_master to drm_device

[Emil Velikov]

On 15 June 2016 at 16:45, Daniel Vetter  wrote:
> On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
>> On 14 June 2016 at 19:50, Daniel Vetter  wrote:
>> > Master-based auth only exists for the legacy/primary drm_minor, hence
>> > there can only be one per device. The goal here is to untangle the
>> > epic dereference games of minor->master and master->minor which is
>> > just massively confusing.
>> >
>> Good riddance :-)
>> Reviewed-by: Emil Velikov 
>>
>> Taking this a step further, have you considered:
>>  - having the master under drm_device, then
>>  - nuking the drm_file/drm_minor one and adding drm_minor::has_master.
>> The last one will be checked before accessing drm_minor::dev::master.
>>
>> The above should work just fine, right ?
>
> We still need a pointer for the dev->master link. A later patch will
> simplify that, but entirely embedding doesn't work: drm_master must be
> free-standing, since when you drop_master all the clients authenticated
> against you will still be connected to your master. This is to make sure
> that they loose their authentication when vt switching to another X
> server. When you reacquire master with set_master, all the clients
> authenticated against that master are again considered authenticated.
>
Just to double check:

+ * Note that master structures are only relevant for the legacy/primary device
+ * nodes, hence there can only be one per device, not one per drm_minor.

In the above does "one per device" reference the "legacy/primary
device node" or the "drm_master struct" ? I was thinking about the
latter then again, reading your reply I'm not sure any more :-(

Or perhaps it is the latter but it should read "one active/associated
per device" ? In which case, yes drm_master should be standalone. Can
you please shed some light ?

Thanks
Emil

[Bug 96444] GRID Autosport crash on loading race

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

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

--- Comment #16 from Lorenzo Bona  ---
I can confirm what Adam said.

I've builded mesa against LLVM 3.8 (debian sid) and GRID is working as
expected, no crashes or hangs.

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

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

[Emil Velikov]

Hi Jitao Shi,

A few comments/suggestions which I hope you'll find useful. Note that
I'm not an expert in the area so take them with a pinch of salt.

On 2 June 2016 at 10:57, Jitao Shi  wrote:

> +#define WRITE_STATUS_REG_CMD   0x01
> +#define READ_STATUS_REG_CMD0x05
> +#define BUSY   BIT(0)
> +#define CLEAR_ALL_PROTECT  0x00
> +#define BLK_PROTECT_BITS   0x0c
> +#define STATUS_REG_PROTECT BIT(7)
> +#define WRITE_ENABLE_CMD   0x06
> +#define CHIP_ERASE_CMD 0xc7
> +#define MAX_DEVS   0x8
Some of the above are unused - SPI_MAX_RETRY_CNT and PAGE2_SWSPI_CTL
come to might. Please double-check and nuke any unused ones for now ?

Add blank line between the macro definitions and the struct.

> +struct ps8640_info {
> +   u8 family_id;
> +   u8 variant_id;
> +   u16 version;
> +};
> +
> +struct ps8640 {
> +   struct drm_connector connector;
> +   struct drm_bridge bridge;
> +   struct edid *edid;
> +   struct mipi_dsi_device dsi;
> +   struct i2c_client *page[MAX_DEVS];
Throw in an enum that provides symbolic names for the different i2c
clients and rename "page" to clients or anything else that makes it
clearer ? Seems like '1' and '6' are never used.

Using better names than client2/7 in the actual code will be great :-)

> +   struct i2c_client *ddc_i2c;
> +   struct regulator_bulk_data supplies[2];
> +   struct drm_panel *panel;
> +   struct gpio_desc *gpio_rst_n;
> +   struct gpio_desc *gpio_slp_n;
> +   struct gpio_desc *gpio_mode_sel_n;
What does the _n suffix mean in the above three ? Bikeshed:
reset_gpio, sleep_gpio and mode_sel(ect)_gpio could also be used ;-)

> +   bool enabled;
> +
> +   /* firmware file info */
> +   struct ps8640_info info;
> +   bool in_fw_update;
> +   /* for firmware update protect */
> +   struct mutex fw_mutex;
> +};
> +
> +static const u8 enc_ctrl_code[6] = { 0xaa, 0x55, 0x50, 0x41, 0x52, 0x44 };
These feel a bit magical. Any chance you can give them symbolic names ?

> +static const u8 hw_chip_id[4] = { 0x00, 0x0a, 0x00, 0x30 };
> +
> +static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
> +{
> +   return container_of(e, struct ps8640, bridge);
> +}
> +
> +static inline struct ps8640 *connector_to_ps8640(struct drm_connector *e)
> +{
> +   return container_of(e, struct ps8640, connector);
> +}
> +
> +static int ps8640_read(struct i2c_client *client, u8 reg, u8 *data,
> +  u16 data_len)
> +{
> +   int ret;
> +   struct i2c_msg msgs[] = {
> +   {
> +.addr = client->addr,
> +.flags = 0,
> +.len = 1,
> +.buf = ,
> +   },
> +   {
> +.addr = client->addr,
> +.flags = I2C_M_RD,
> +.len = data_len,
> +.buf = data,
> +   }
> +   };
> +
> +   ret = i2c_transfer(client->adapter, msgs, 2);
> +
> +   if (ret == 2)
> +   return 0;
> +   if (ret < 0)
> +   return ret;
> +   else
> +   return -EIO;
> +}
> +
> +static int ps8640_write_bytes(struct i2c_client *client, const u8 *data,
> + u16 data_len)
> +{
> +   int ret;
> +   struct i2c_msg msg;
> +
> +   msg.addr = client->addr;
> +   msg.flags = 0;
> +   msg.len = data_len;
> +   msg.buf = (u8 *)data;
> +
> +   ret = i2c_transfer(client->adapter, , 1);
> +   if (ret == 1)
> +   return 0;
> +   if (ret < 0)
> +   return ret;
> +   else
> +   return -EIO;
> +}
> +
> +static int ps8640_write_byte(struct i2c_client *client, u8 reg,  u8 data)
> +{
> +   u8 buf[] = { reg, data };
> +
> +   return ps8640_write_bytes(client, buf, sizeof(buf));
> +}
> +
> +static void ps8640_get_mcu_fw_version(struct ps8640 *ps_bridge)
> +{
> +   struct i2c_client *client = ps_bridge->page[5];
> +   u8 fw_ver[2];
> +
> +   ps8640_read(client, 0x4, fw_ver, sizeof(fw_ver));
> +   ps_bridge->info.version = (fw_ver[0] << 8) | fw_ver[1];
> +
> +   DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", fw_ver[0], fw_ver[1]);
> +}
> +
> +static int ps8640_bridge_unmute(struct ps8640 *ps_bridge)
> +{
> +   struct i2c_client *client = ps_bridge->page[3];
> +   u8 vdo_ctrl_buf[3] = { PAGE3_SET_ADD, VDO_CTL_ADD, VDO_EN };
> +
> +   return ps8640_write_bytes(client, vdo_ctrl_buf, sizeof(vdo_ctrl_buf));
> +}
> +
> +static int ps8640_bridge_mute(struct ps8640 *ps_bridge)
> +{
> +   struct i2c_client *client = ps_bridge->page[3];
> +   u8 vdo_ctrl_buf[3] = { PAGE3_SET_ADD, VDO_CTL_ADD, VDO_DIS };
> +
> +   return ps8640_write_bytes(client, vdo_ctrl_buf, sizeof(vdo_ctrl_buf));
> +}
> +
> +static void ps8640_pre_enable(struct drm_bridge *bridge)
> +{
> +   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +   

[PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 05:42:11PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 15:47), Minchan Kim wrote:
> > > [..]
> > > > > this is what I'm getting with the [zsmalloc: keep first object offset 
> > > > > in struct page]
> > > > > applied:  "count:0 mapcount:-127". which may be not related to 
> > > > > zsmalloc at this point.
> > > > > 
> > > > > kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> > > > > kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  
> > > > > (null) index:0x1
> > > > 
> > > > Hm, it seems double free.
> > > > 
> > > > It doen't happen if you disable zram? IOW, it seems to be related
> > > > zsmalloc migration?
> > > 
> > > need to test more, can't confidently answer now.
> > > 
> > > > How easy can you reprodcue it? Could you bisect it?
> > > 
> > > it takes some (um.. random) time to trigger the bug.
> > > I'll try to come up with more details.
> > 
> > Could you revert [1] and retest?
> > 
> > [1] mm/compaction: split freepages without holding the zone lock
> 
> ok, so this is not related to zsmalloc. finally manged to reproduce
> it. will fork a separate thread.

The reason I mentioned [1] is that it seems to have a bug.

isolate_freepages_block
  __isolate_free_page
if(!zone_watermark_ok())
  return 0;
  list_add_tail(>lru, freelist);

However, the page is not isolated.
Joonsoo?

[PATCH V7 3/3] soc/tegra: pmc: Add support for IO pads power state and voltage

[Laxman Dewangan]

Hi Thierry,

On Tuesday 24 May 2016 04:18 PM, Jon Hunter wrote:
> On 23/05/16 10:03, Jon Hunter wrote:
>> On 20/05/16 15:45, Laxman Dewangan wrote:
>>> The IO pins of Tegra SoCs are grouped for common control of IO
>>> interface like setting voltage signal levels and power state of
>>> the interface. The group is generally referred as IO pads. The
>>> power state and voltage control of IO pins can be done at IO pads
>>> level.
>>>
>>> Tegra generation SoC supports the power down of IO pads when it
>>> is not used even in the active state of system. This saves power
>>> from that IO interface. Also it supports multiple voltage level
>>> in IO pins for interfacing on some of pads. The IO pad voltage is
>>> automatically detected till T124, hence SW need not to configure
>>> this. But from T210, the automatically detection logic has been
>>> removed, hence SW need to explicitly set the IO pad voltage into
>>> IO pad configuration registers.
>>>
>>> Add support to set the power states and voltage level of the IO pads
>>> from client driver. The implementation for the APIs are in generic
>>> which is applicable for all generation os Tegra SoC.
>>>
>>> IO pads ID and information of bit field for power state and voltage
>>> level controls are added for Tegra124, Tegra132 and Tegra210. The SOR
>>> driver is modified to use the new APIs.
>>>
>>> Signed-off-by: Laxman Dewangan 

Can you please review this?

Thanks,
Laxman

[PATCH] drm/atomic-helpers: Clear up cleanup_done a bit

[Oded Gabbay]

On Wed, Jun 15, 2016 at 1:08 PM, Daniel Vetter  
wrote:
> It's not obvious at first sight that this is a fastpath, make that
> clearer with a goto. Fallout from a discussion with Liviu on irc.
>
> Cc: Liviu.Dudau at arm.com
> Acked-by: Liviu.Dudau at arm.com
> Signed-off-by: Daniel Vetter 
> ---
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  4 ++--
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  3 ---

Hi Daniel,

I'm a bit confused, how the kfd changes relate to this specific commit ?
The commit message seems to talk about something else.

Oded

>  drivers/gpu/drm/drm_atomic_helper.c|  8 +++-
>  include/drm/drm_crtc.h | 23 
> --
>  4 files changed, 9 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> index ec4036a09f3e..a625b9137da2 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> @@ -187,12 +187,12 @@ int init_pipelines(struct device_queue_manager *dqm,
>  unsigned int get_first_pipe(struct device_queue_manager *dqm);
>  unsigned int get_pipes_num(struct device_queue_manager *dqm);
>
> -extern inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> *pdd)
> +static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> *pdd)
>  {
> return (pdd->lds_base >> 16) & 0xFF;
>  }
>
> -extern inline unsigned int
> +static inline unsigned int
>  get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
>  {
> return (pdd->lds_base >> 60) & 0x0E;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index d0d5f4baf72d..80113c335966 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -617,10 +617,7 @@ int kgd2kfd_resume(struct kfd_dev *kfd);
>  int kfd_init_apertures(struct kfd_process *process);
>
>  /* Queue Context Management */
> -inline uint32_t lower_32(uint64_t x);
> -inline uint32_t upper_32(uint64_t x);
>  struct cik_sdma_rlc_registers *get_sdma_mqd(void *mqd);
> -inline uint32_t get_sdma_base_addr(struct cik_sdma_rlc_registers *m);
>
>  int init_queue(struct queue **q, struct queue_properties properties);
>  void uninit_queue(struct queue *q);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 716aa535eb98..0556c95b7ddb 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1579,11 +1579,8 @@ void drm_atomic_helper_commit_cleanup_done(struct 
> drm_atomic_state *state)
> /* commit_list borrows our reference, need to remove before we
>  * clean up our drm_atomic_state. But only after it actually
>  * completed, otherwise subsequent commits won't stall 
> properly. */
> -   if (try_wait_for_completion(>flip_done)) {
> -   list_del(>commit_entry);
> -   spin_unlock(>commit_lock);
> -   continue;
> -   }
> +   if (try_wait_for_completion(>flip_done))
> +   goto del_commit:
>
> spin_unlock(>commit_lock);
>
> @@ -1597,6 +1594,7 @@ void drm_atomic_helper_commit_cleanup_done(struct 
> drm_atomic_state *state)
>   crtc->base.id, crtc->name);
>
> spin_lock(>commit_lock);
> +del_commit:
> list_del(>commit_entry);
> spin_unlock(>commit_lock);
> }
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3c84ddc7e4c8..a39e1f17a20e 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2820,29 +2820,14 @@ static inline void drm_connector_unreference(struct 
> drm_connector *connector)
>  #define drm_for_each_crtc(crtc, dev) \
> list_for_each_entry(crtc, &(dev)->mode_config.crtc_list, head)
>
> -static inline void
> -assert_drm_connector_list_read_locked(struct drm_mode_config *mode_config)
> -{
> -   /*
> -* The connector hotadd/remove code currently grabs both locks when
> -* updating lists. Hence readers need only hold either of them to be
> -* safe and the check amounts to
> -*
> -* WARN_ON(not_holding(A) && not_holding(B)).
> -*/
> -   WARN_ON(!mutex_is_locked(_config->mutex) &&
> -   !drm_modeset_is_locked(_config->connection_mutex));
> -}
> -
>  #define drm_for_each_connector(connector, dev) \
> /* loop to wrap everything into a srcu read-side critical section */  
>   \
> -   for (bool __conn_loop_srcu = true,
>   \
> -int __conn_loop_srcu_ret = 
> srcu_read_lock(_connector_list_srcu);\
> -__conn_loop_srcu; __conn_loop_srcu = false,  
>   \
> + 

[PATCHv16 10/13] cec: adv7842: add cec support

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:25 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add CEC support to the adv7842 driver.
> 
> Signed-off-by: Hans Verkuil 

Won't review patches 10-13, as the same reviews I made for patch 9
very likely applies.

As this series is causing non-staging drivers to be dependent of a
staging driver, I'll wait for the next version that should be
solving this issue.

For the new 9-13 patches, please be sure that checkpatch will be
happy. For the staging stuff, the checkpatch issues can be solved
later, as I'll re-check against checkpatch when it moves from staging
to mainstream.

Regards,
Mauro

Thanks,
Mauro

[PATCHv16 09/13] cec: adv7604: add cec support.

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:24 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add CEC support to the adv7604 driver.
> 
> Signed-off-by: Hans Verkuil 
> [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans 
> Verkuil]
> [k.debski at samsung.com: add missing methods cec/io_write_and_or]
> [k.debski at samsung.com: change adv7604 to adv76xx in added functions]
> [hansverk at cisco.com: use _clr_set instead of _and_or]
> ---
>  drivers/media/i2c/Kconfig   |   9 ++
>  drivers/media/i2c/adv7604.c | 332 
> +++-
>  2 files changed, 305 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 993dc50..cba1fc7 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -209,6 +209,7 @@ config VIDEO_ADV7604
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
>   depends on GPIOLIB || COMPILE_TEST
>   select HDMI
> + select MEDIA_CEC_EDID

Same note for all CEC drivers: don't do that! CEC is in staging. We
should not have any code outside staging depending or selecting CEC.

Instead, put all CEC dependent code inside #ifdefs.


>   ---help---
> Support for the Analog Devices ADV7604 video decoder.
>  
> @@ -218,6 +219,14 @@ config VIDEO_ADV7604
> To compile this driver as a module, choose M here: the
> module will be called adv7604.
>  
> +config VIDEO_ADV7604_CEC
> + bool "Enable Analog Devices ADV7604 CEC support"
> + depends on VIDEO_ADV7604 && MEDIA_CEC
> + default y

Remove "default y". CEC is experimental. Users should explicitly
agree adding experimental code that depends on staging stuff.

> + ---help---
> +   When selected the adv7604 will support the optional
> +   HDMI CEC feature.

Please add a notice that CEC is an experimental feature under
staging and may be changed or even removed in the future.

We don't want any application to use it yet, as we're still
experimenting with it.

For the rest of the code below, and for patches 10-13: all the above
applies to them.

> +
>  config VIDEO_ADV7842
>   tristate "Analog Devices ADV7842 decoder"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index beb2841..f462585 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -40,6 +40,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -80,6 +81,8 @@ MODULE_LICENSE("GPL");
>  
>  #define ADV76XX_OP_SWAP_CB_CR(1 << 0)
>  
> +#define ADV76XX_MAX_ADDRS (3)
> +
>  enum adv76xx_type {
>   ADV7604,
>   ADV7611,
> @@ -184,6 +187,12 @@ struct adv76xx_state {
>   u16 spa_port_a[2];
>   struct v4l2_fract aspect_ratio;
>   u32 rgb_quantization_range;
> +
> + struct cec_adapter *cec_adap;
> + u8   cec_addr[ADV76XX_MAX_ADDRS];
> + u8   cec_valid_addrs;
> + bool cec_enabled_adap;
> +
>   struct workqueue_struct *work_queues;
>   struct delayed_work delayed_work_enable_hotplug;
>   bool restart_stdi_once;
> @@ -381,7 +390,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 
> reg, u8 val)
>   return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val);
>  }
>  
> -static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, 
> u8 val)
> +static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
> +u8 val)
>  {
>   return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
>  }
> @@ -414,6 +424,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 
> reg, u8 val)
>   return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val);
>  }
>  
> +static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
> +u8 val)
> +{
> + return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
> +}
> +
>  static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
>  {
>   struct adv76xx_state *state = to_state(sd);
> @@ -872,9 +888,9 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev 
> *sd)
>  {
>   struct adv76xx_state *state = to_state(sd);
>   const struct adv76xx_chip_info *info = state->info;
> + u16 cable_det = info->read_cable_det(sd);
>  
> - return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl,
> - info->read_cable_det(sd));
> + return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
>  }
>  
>  static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
> @@ -1900,6 +1916,210 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
>   return 0;
>  }
>  
> +#if IS_ENABLED(CONFIG_VIDEO_ADV7604_CEC)
> +static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 
> tx_raw_status)
> +{
> + struct adv76xx_state *state = to_state(sd);
> +
> + if 

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Daniel Vetter]

On Thu, Jun 16, 2016 at 3:02 PM, Rainer Hochecker  
wrote:
> Daniel,
>
> Peter posted me some snippets about your discussion around vblank that
> confused me. Our use case is as follows:
> We synchronise our video player clock to the pace of the display. Assume we
> play some 23.976 content and the actual refresh rate is 24hz. We increment
> the clock every vblank, that makes the clock run faster. Audio is resampled
> to the faster running clock.
> For this we just need an event fired for vblank.
>
> Another requirement not directly related to 1)
> We would like to know when a frame in actually presented on screen. Now this
> is only guessing.


If you do vblank support right (which means GLX_OML_sync_control, it
should work on mesa/glx but not anywhere else unfortunately) you get
both. That's what I mean with calling the vblank ioctl directly is a
hack: It's only really one half of correctly done a/v sync, you get
the clock source but still have no idea when the frames actually show
up. GLX_OML_sync_control (and a port to EGL/wayland, if someone
bothers with that) gives you that control, plus ofc still a clock
source which is as accurate as the current one (since it's the same).

Note that DRI2/DRI3 and wayland all support this already, it's just a
matter of wiring it up as an EGL extension. And of course it won't
work on nvidia blobs because they just suck at this and don't want to
let apps control all the double/triple buffering and whatever else
they have in their driver.

Note that the only reason this works on mesa is because Mario Kleiner
really cares about it, and fixed up all the bugs across the entire
stack (meas, X, kernel drivers). Mario might be interested in an EGL
version of all this, not sure. Adding him.

Oh and: Please feel free to add other video players and folks
interested in this, I don't know them really at all.

Cheers, Daniel

>
> Rainer
>
> On Wed, Jun 15, 2016 at 10:57 AM, Daniel Vetter 
> wrote:
>>
>> On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer  
>> wrote:
>> > On 14.06.2016 18:35, Daniel Vetter wrote:
>> >> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer 
>> >> wrote:
>> >>> On 14.06.2016 18:03, Daniel Vetter wrote:
>>  Somehow this escaped us, this is a KMS ioctl which should only be
>>  used
>>  by the master (which is the thing that's also in control of kms
>>  resources). Everything else is bound to result in fail.
>> 
>>  Clients shouldn't have a trouble coping with this, since a pile of
>>  drivers don't support vblank waits (or just randomly fall over when
>>  using them). Note that the big motivation for abusing this like mad
>>  seems to be that EGL doesn't have OML_sync, but somehow it didn't
>>  cross anyone's mind that adding OML_sync to EGL would be useful.
>> >>>
>> >>> That may be one motivation, but it's certainly not the only one.
>> >>> DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any
>> >>> similar
>> >>> API at all.
>> >>
>> >> Hm, what else?
>> >
>> > Off the top of my head, I know specifically about compton and xfwm4.
>> > There's certainly more.
>>
>> But do they anything more fancy than what could be achieved with
>> OML_sync too? Or is the issue that they don't want to use EGL/GLX? In
>> that case I think it's reasonable to ask them to use bare-metal
>> Present, since that's not any less portable than using the vblank
>> ioctl.
>>
>> > Note that as I mentioned before in the other thread, I absolutely agree
>> > that DRM_IOCTL_WAIT_VBLANK isn't supposed to be used directly. But the
>> > fact of the matter is that it is being used like that (possibly has been
>> > since before the DRM master concept even existed), and presumably it
>> > actually works with simple setups (which might be the majority). So
>> > there might be some backlash if it suddenly stops working.
>>
>> Fully agreed. Hence just RFC, and yes we need to get the EGL extension
>> in place first, and at least kick most of the popular apps to have
>> their code ready, and wait a bit, and wait some more, before we can
>> nuke the ioctl from the kernel for non-master. It'll probably take 5
>> years if we're fast :( I do think that we should be ok with breaking
>> the last few hold-outs, but we definitely need to have an alternate
>> solution for EGL ready. Hence why I want to know whether there's
>> anyone who's using this outside of EGL.
>>
>> Really this was just drive-by that I spotted while looking around at
>> stuff for our other discussion around vblanks.
>> -Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>



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

[PATCH] drm/atomic-helpers: Clear up cleanup_done a bit

[Daniel Vetter]

On Thu, Jun 16, 2016 at 5:30 PM, Oded Gabbay  wrote:
> On Wed, Jun 15, 2016 at 1:08 PM, Daniel Vetter  
> wrote:
>> It's not obvious at first sight that this is a fastpath, make that
>> clearer with a goto. Fallout from a discussion with Liviu on irc.
>>
>> Cc: Liviu.Dudau at arm.com
>> Acked-by: Liviu.Dudau at arm.com
>> Signed-off-by: Daniel Vetter 
>> ---
>>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  4 ++--
>>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  3 ---
>
> Hi Daniel,
>
> I'm a bit confused, how the kfd changes relate to this specific commit ?
> The commit message seems to talk about something else.

They don't, this is just git fail on my side.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCHv16 08/13] DocBook/media: add CEC documentation

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:23 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Add DocBook documentation for the CEC API.

Please always send the documentation patch *before* the code,
in order to make easier to do the code review.

> 
> Signed-off-by: Hans Verkuil 
> [k.debski at samsung.com: add documentation for passthrough mode]
> [k.debski at samsung.com: minor fixes and change of reserved field sizes]
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/DocBook/device-drivers.tmpl  |   4 +
>  Documentation/DocBook/media/Makefile   |   2 +
>  Documentation/DocBook/media/v4l/biblio.xml |  10 +
>  Documentation/DocBook/media/v4l/cec-api.xml|  72 +
>  Documentation/DocBook/media/v4l/cec-func-close.xml |  59 
>  Documentation/DocBook/media/v4l/cec-func-ioctl.xml |  73 +
>  Documentation/DocBook/media/v4l/cec-func-open.xml  |  94 ++
>  Documentation/DocBook/media/v4l/cec-func-poll.xml  |  89 ++
>  .../DocBook/media/v4l/cec-ioc-adap-g-caps.xml  | 140 +
>  .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 324 
> +
>  .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml |  82 ++
>  .../DocBook/media/v4l/cec-ioc-dqevent.xml  | 190 
>  Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 245 
>  .../DocBook/media/v4l/cec-ioc-receive.xml  | 260 +
>  Documentation/DocBook/media_api.tmpl   |   6 +-
>  15 files changed, 1649 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
>  create mode 100644 
> Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml
>  create mode 100644 
> Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
>  create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml

Hmm... as CEC is at staging, I'm not very comfortable on having
it documented there as-is, as the documentation is expected to
be for non-staging stuff. Maybe the best would be to add, on every
xml above, a note saying that this is a *proposed* documentation
for a feature yet to be accepted.

> 
> diff --git a/Documentation/DocBook/device-drivers.tmpl 
> b/Documentation/DocBook/device-drivers.tmpl
> index 893b2ca..31258bf 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -270,6 +270,10 @@ X!Isound/sound_firmware.c
>  !Iinclude/media/media-devnode.h
>  !Iinclude/media/media-entity.h
>  
> + Consumer Electronics Control devices
> +!Iinclude/media/cec.h
> +!Iinclude/media/cec-edid.h
> + 

For the same reason, I would not add those yet.

>  
>
>  
> diff --git a/Documentation/DocBook/media/Makefile 
> b/Documentation/DocBook/media/Makefile
> index 2840ff4..fdc1386 100644
> --- a/Documentation/DocBook/media/Makefile
> +++ b/Documentation/DocBook/media/Makefile
> @@ -64,6 +64,7 @@ IOCTLS = \
>   $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' 
> $(srctree)/include/uapi/linux/dvb/net.h) \
>   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
> $(srctree)/include/uapi/linux/dvb/video.h) \
>   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
> $(srctree)/include/uapi/linux/media.h) \
> + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
> $(srctree)/include/linux/cec.h) \
>   $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' 
> $(srctree)/include/uapi/linux/v4l2-subdev.h) \
>  
>  DEFINES = \
> @@ -100,6 +101,7 @@ STRUCTS = \
>   $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' 
> $(srctree)/include/uapi/linux/dvb/net.h) \
>   $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' 
> $(srctree)/include/uapi/linux/dvb/video.h) \
>   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
> $(srctree)/include/uapi/linux/media.h) \
> + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
> $(srctree)/include/linux/cec.h) \
>   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
> $(srctree)/include/uapi/linux/v4l2-subdev.h) \
>   $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' 
> $(srctree)/include/uapi/linux/v4l2-mediabus.h)
>  
> diff --git a/Documentation/DocBook/media/v4l/biblio.xml 
> b/Documentation/DocBook/media/v4l/biblio.xml
> index 9beb30f..87f1d24 100644
> --- 

[PATCH v5 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

[Emil Velikov]

Hi Vinay,

I belive I've spotted a few issues. If my understanding is correct,
then I'll defer to Thierry if he'd like them fixed here, or as
follow-ups.

On 16 June 2016 at 04:00, Vinay Simha BN  wrote:


> +#define PANEL_NUM_REGULATORS   3
> +
Nit: #define PANEL_NUM_REGULATORS ARRAY_SIZE(regulator_names) or just
drop the extra define and use the latter directly ?


> +static int jdi_panel_init(struct jdi_panel *jdi)
> +{


> +   if (ret < 0)
> +   return ret;
> +
> +   return 0;
Nit: The above three lines can become one - "return ret;"

> +}
> +
> +static int jdi_panel_on(struct jdi_panel *jdi)
> +{
> +   struct mipi_dsi_device *dsi = jdi->dsi;
> +   int ret;
> +
> +   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> +   ret = mipi_dsi_dcs_set_display_on(dsi);
> +   if (ret < 0)
> +   return ret;
> +
> +   return 0;
Ditto.


> +static int jdi_panel_disable(struct drm_panel *panel)
> +{
> +   struct jdi_panel *jdi = to_jdi_panel(panel);
> +
> +   if (!jdi->enabled)
> +   return 0;
> +
Thinking out loud:

Thierry,
Shouldn't we fold 'enabled' and 'prepared' in struct drm_panel and
tweak the helpers respectively ? Is there any specific reason for
keeping these in the drivers ?


> +   if (jdi->backlight) {
We seems to be bailing out of jdi_panel_add() when this is NULL. Thus
we can omit the check.



> +static int jdi_panel_unprepare(struct drm_panel *panel)
> +{
> +   struct jdi_panel *jdi = to_jdi_panel(panel);
> +   struct device *dev = >dsi->dev;
> +   int ret;
> +
> +   if (!jdi->prepared)
> +   return 0;
> +
> +   ret = jdi_panel_off(jdi);
> +   if (ret) {
> +   dev_err(panel->dev, "failed to set panel off: %d\n", ret);
> +   return ret;
> +   }
> +
> +   ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), 
> jdi->supplies);
> +   if (ret < 0) {
> +   dev_err(dev, "regulator disable failed, %d\n", ret);
> +   return ret;
> +   }
> +
Since we cannot recover from most/all of the above I'm thinking if one
shouldn't drop the "return ret" lines. Same goes for jdi_panel_off().


> +   if (jdi->reset_gpio)
> +   gpiod_set_value(jdi->reset_gpio, 0);
> +
> +   if (jdi->enable_gpio)
Drop these two checks. The gpios are required, thus one should bail
out in jdi_panel_add()



> +static int jdi_panel_prepare(struct drm_panel *panel)
> +{

> +   if (jdi->reset_gpio) {
> +   gpiod_set_value(jdi->reset_gpio, 1);
> +   usleep_range(10, 20);
> +   }
> +
> +   if (jdi->enable_gpio) {
> +   gpiod_set_value(jdi->enable_gpio, 1);
> +   usleep_range(10, 20);
> +   }
> +


> +poweroff:
> +   if (jdi->reset_gpio)
> +   gpiod_set_value(jdi->reset_gpio, 0);
> +   if (jdi->enable_gpio)
> +   gpiod_set_value(jdi->enable_gpio, 0);
> +
Generic suggestion/nitpick: Please keep the teardown order the inverse
of the setup one. In here one could/should handle enable_gpio first
and then reset_gpio.

> +   return ret;
> +}
> +
> +static int jdi_panel_enable(struct drm_panel *panel)
> +{
> +   struct jdi_panel *jdi = to_jdi_panel(panel);
> +
> +   if (jdi->enabled)
> +   return 0;
> +
> +   if (jdi->backlight) {
Analogous to jdi_panel_disable - drop the check ?



> +static int jdi_panel_add(struct jdi_panel *jdi)
> +{


> +   jdi->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> +   if (IS_ERR(jdi->reset_gpio)) {
> +   dev_err(dev, "cannot get reset-gpios %ld\n",
> +   PTR_ERR(jdi->reset_gpio));
> +   jdi->reset_gpio = NULL;
> +   } else {
> +   gpiod_direction_output(jdi->reset_gpio, 0);
> +   }
> +
> +   jdi->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
> +   if (IS_ERR(jdi->enable_gpio)) {
> +   dev_err(dev, "cannot get enable-gpio %ld\n",
> +   PTR_ERR(jdi->enable_gpio));
> +   jdi->enable_gpio = NULL;
> +   } else {
> +   gpiod_direction_output(jdi->enable_gpio, 0);
> +   }
> +
As mentioned above - since these two are required, thus we should
error out of this function. Right ?

> +   jdi->backlight = drm_panel_create_dsi_backlight(jdi->dsi);
> +   if (!jdi->backlight)
> +   return -EPROBE_DEFER;
> +
> +   drm_panel_init(>base);
> +   jdi->base.funcs = _panel_funcs;
> +   jdi->base.dev = >dsi->dev;
> +
> +   ret = drm_panel_add(>base);
> +   if (ret < 0)
> +   return ret;
> +
> +   return 0;
return ret;

Regards,
Emil

[PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job

[zhoucm1]

On 2016年06月16日 17:52, Christian König wrote:
> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>
>>
>> On 2016年06月15日 19:44, Christian König wrote:
>>> From: Christian König 
>>>
>>> When we pipeline evictions the page directory could already be
>>> moving somewhere else when grab_id is called.
>> Isn't PD bo protected by job fence?
>> I think before job fence is signalled, the PD bo is safe, there 
>> shouldn't be a chance to evict PD bo.
>
> The crux here is that we start to pipeline BO evictions (we plan them 
> but don't execute them immediately).
>
> E.g. the eviction won't happen before the protecting fence is 
> signaled, but we have it planned and so the address returned by 
> amdgpu_bo_gpu_offset() is already the new one.
Thanks for mentioned, I see the code in ttm_bo_handle_move_mem:
 if (bo->mem.mm_node) {
 bo->offset = (bo->mem.start << PAGE_SHIFT) +
 bdev->man[bo->mem.mem_type].gpu_offset;
 bo->cur_placement = bo->mem.placement;
 } else
 bo->offset = 0;

it seems better to update the offset after the moving-fence is 
signalled, add a moving-fence callback?

Regards,
David Zhou
>
> Regards,
> Christian.
>
>>
>> Regards,
>> David Zhou
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
>>>   2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> index a3d7d13..850c4dd 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>>> @@ -661,6 +661,8 @@ static int amdgpu_cs_ib_vm_chunk(struct 
>>> amdgpu_device *adev,
>>>   }
>>>   }
>>>   +p->job->vm_pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>>> +
>>>   r = amdgpu_bo_vm_update_pte(p, vm);
>>>   if (!r)
>>>   amdgpu_cs_sync_rings(p);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> index d3e0576..82efb40 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>>> @@ -177,7 +177,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>>> struct amdgpu_ring *ring,
>>> struct amdgpu_sync *sync, struct fence *fence,
>>> unsigned *vm_id, uint64_t *vm_pd_addr)
>>>   {
>>> -uint64_t pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>>>   struct amdgpu_device *adev = ring->adev;
>>>   struct fence *updates = sync->last_vm_update;
>>>   struct amdgpu_vm_id *id, *idle;
>>> @@ -250,7 +249,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>>> struct amdgpu_ring *ring,
>>>   if (atomic64_read(>owner) != vm->client_id)
>>>   continue;
>>>   -if (pd_addr != id->pd_gpu_addr)
>>> +if (*vm_pd_addr != id->pd_gpu_addr)
>>>   continue;
>>> if (!same_ring &&
>>> @@ -298,14 +297,13 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>>> struct amdgpu_ring *ring,
>>>   fence_put(id->flushed_updates);
>>>   id->flushed_updates = fence_get(updates);
>>>   -id->pd_gpu_addr = pd_addr;
>>> +id->pd_gpu_addr = *vm_pd_addr;
>>> list_move_tail(>list, >vm_manager.ids_lru);
>>>   atomic64_set(>owner, vm->client_id);
>>>   vm->ids[ring->idx] = id;
>>> *vm_id = id - adev->vm_manager.ids;
>>> -*vm_pd_addr = pd_addr;
>>>   trace_amdgpu_vm_grab_id(vm, ring->idx, *vm_id, *vm_pd_addr);
>>> error:
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 10/10] drm/msm/rd: add module param to dump all bo's

[Rob Clark]

By default, if using $debugfs/.../rd to log cmdstream, only the
cmdstream buffers themselves are logged.  But in some cases we want
to capture other buffers in the submit (to see VBO's or shaders).
So add a mod-param knob to control this.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_rd.c | 38 +++---
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index fa02b5a..24254e0 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -27,6 +27,11 @@
  * This bypasses drm_debugfs_create_files() mainly because we need to use
  * our own fops for a bit more control.  In particular, we don't want to
  * do anything if userspace doesn't have the debugfs file open.
+ *
+ * The module-param "rd_full", which defaults to false, enables snapshotting
+ * all (non-written) buffers in the submit, rather than just cmdstream bo's.
+ * This is useful to capture the contents of (for example) vbo's or textures,
+ * or shader programs (if not emitted inline in cmdstream).
  */

 #ifdef CONFIG_DEBUG_FS
@@ -40,6 +45,10 @@
 #include "msm_gpu.h"
 #include "msm_gem.h"

+static bool rd_full = false;
+MODULE_PARM_DESC(rd_full, "If true, $debugfs/.../rd will snapshot all buffer 
contents");
+module_param_named(rd_full, rd_full, bool, 0600);
+
 enum rd_sect_type {
RD_NONE,
RD_TEST,   /* ascii text */
@@ -288,7 +297,12 @@ static void snapshot_buf(struct msm_rd_state *rd,
if (IS_ERR(buf))
return;

-   buf += iova - submit->bos[idx].iova;
+   if (iova) {
+   buf += iova - submit->bos[idx].iova;
+   } else {
+   iova = submit->bos[idx].iova;
+   size = obj->base.size;
+   }

rd_write_section(rd, RD_GPUADDR,
(uint32_t[2]){ iova, size }, 8);
@@ -320,17 +334,27 @@ void msm_rd_dump_submit(struct msm_gem_submit *submit)

rd_write_section(rd, RD_CMD, msg, ALIGN(n, 4));

-   /* could be nice to have an option (module-param?) to snapshot
-* all the bo's associated with the submit.  Handy to see vtx
-* buffers, etc.  For now just the cmdstream bo's is enough.
-*/
+   if (rd_full) {
+   for (i = 0; i < submit->nr_bos; i++) {
+   /* buffers that are written to probably don't start out
+* with anything interesting:
+*/
+   if (submit->bos[i].flags & MSM_SUBMIT_BO_WRITE)
+   continue;
+
+   snapshot_buf(rd, submit, i, 0, 0);
+   }
+   }

for (i = 0; i < submit->nr_cmds; i++) {
uint32_t iova = submit->cmd[i].iova;
uint32_t szd  = submit->cmd[i].size; /* in dwords */

-   snapshot_buf(rd, submit, submit->cmd[i].idx,
-   submit->cmd[i].iova, szd * 4);
+   /* snapshot cmdstream bo's (if we haven't already): */
+   if (!rd_full) {
+   snapshot_buf(rd, submit, submit->cmd[i].idx,
+   submit->cmd[i].iova, szd * 4);
+   }

switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
-- 
2.5.5

[PATCH 09/10] drm/msm/rd: split out snapshot_buf helper

[Rob Clark]

(reduce the noise in next patch)

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_rd.c | 36 ++--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 3eeb8af..fa02b5a 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -277,6 +277,26 @@ void msm_rd_debugfs_cleanup(struct drm_minor *minor)
kfree(rd);
 }

+static void snapshot_buf(struct msm_rd_state *rd,
+   struct msm_gem_submit *submit, int idx,
+   uint32_t iova, uint32_t size)
+{
+   struct msm_gem_object *obj = submit->bos[idx].obj;
+   const char *buf;
+
+   buf = msm_gem_get_vaddr_locked(>base);
+   if (IS_ERR(buf))
+   return;
+
+   buf += iova - submit->bos[idx].iova;
+
+   rd_write_section(rd, RD_GPUADDR,
+   (uint32_t[2]){ iova, size }, 8);
+   rd_write_section(rd, RD_BUFFER_CONTENTS, buf, size);
+
+   msm_gem_put_vaddr_locked(>base);
+}
+
 /* called under struct_mutex */
 void msm_rd_dump_submit(struct msm_gem_submit *submit)
 {
@@ -306,21 +326,11 @@ void msm_rd_dump_submit(struct msm_gem_submit *submit)
 */

for (i = 0; i < submit->nr_cmds; i++) {
-   uint32_t idx  = submit->cmd[i].idx;
uint32_t iova = submit->cmd[i].iova;
uint32_t szd  = submit->cmd[i].size; /* in dwords */
-   struct msm_gem_object *obj = submit->bos[idx].obj;
-   const char *buf = msm_gem_get_vaddr_locked(>base);
-
-   if (IS_ERR(buf))
-   continue;

-   buf += iova - submit->bos[idx].iova;
-
-   rd_write_section(rd, RD_GPUADDR,
-   (uint32_t[2]){ iova, szd * 4 }, 8);
-   rd_write_section(rd, RD_BUFFER_CONTENTS,
-   buf, szd * 4);
+   snapshot_buf(rd, submit, submit->cmd[i].idx,
+   submit->cmd[i].iova, szd * 4);

switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
@@ -335,8 +345,6 @@ void msm_rd_dump_submit(struct msm_gem_submit *submit)
(uint32_t[2]){ iova, szd }, 8);
break;
}
-
-   msm_gem_put_vaddr_locked(>base);
}
 }
 #endif
-- 
2.5.5

[PATCH 08/10] drm/msm: bump kernel api version

[Rob Clark]

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

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 3e15a50..e0d077d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -21,6 +21,16 @@
 #include "msm_gpu.h"
 #include "msm_kms.h"

+
+/*
+ * MSM driver version:
+ * - 1.0.0 - initial interface
+ * - 1.1.0 - adds madvise, and support for submits with > 4 cmd buffers
+ */
+#define MSM_VERSION_MAJOR  1
+#define MSM_VERSION_MINOR  1
+#define MSM_VERSION_PATCHLEVEL 0
+
 static void msm_fb_output_poll_changed(struct drm_device *dev)
 {
struct msm_drm_private *priv = dev->dev_private;
@@ -808,8 +818,9 @@ static struct drm_driver msm_driver = {
.name   = "msm",
.desc   = "MSM Snapdragon DRM",
.date   = "20130625",
-   .major  = 1,
-   .minor  = 0,
+   .major  = MSM_VERSION_MAJOR,
+   .minor  = MSM_VERSION_MINOR,
+   .patchlevel = MSM_VERSION_PATCHLEVEL,
 };

 #ifdef CONFIG_PM_SLEEP
-- 
2.5.5

[PATCH 07/10] drm/msm: deal with arbitrary # of cmd buffers

[Rob Clark]

For some optimizations coming on the userspace side, splitting larger
draw or gmem cmds into multiple cmdstream buffers, we need to support
much more than the previous small/arbitrary limit.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.h|  4 +---
 drivers/gpu/drm/msm/msm_gem_submit.c | 11 +--
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 7a4da81..b2f13cf 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -93,8 +93,6 @@ static inline bool is_vunmapable(struct msm_gem_object 
*msm_obj)
return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
 }

-#define MAX_CMDS 4
-
 /* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
  * associated with the cmdstream submission for synchronization (and
  * make it easier to unwind when things go wrong, etc).  This only
@@ -116,7 +114,7 @@ struct msm_gem_submit {
uint32_t size;  /* in dwords */
uint32_t iova;
uint32_t idx;   /* cmdstream buffer idx in bos[] */
-   } cmd[MAX_CMDS];
+   } *cmd;  /* array of size nr_cmds */
struct {
uint32_t flags;
struct msm_gem_object *obj;
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 736f158..9766f9a 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -29,10 +29,11 @@
 #define BO_PINNED   0x2000

 static struct msm_gem_submit *submit_create(struct drm_device *dev,
-   struct msm_gpu *gpu, int nr)
+   struct msm_gpu *gpu, int nr_bos, int nr_cmds)
 {
struct msm_gem_submit *submit;
-   int sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+   int sz = sizeof(*submit) + (nr_bos * sizeof(submit->bos[0])) +
+   (nr_cmds * sizeof(*submit->cmd));

submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
if (!submit)
@@ -42,6 +43,7 @@ static struct msm_gem_submit *submit_create(struct drm_device 
*dev,
submit->gpu = gpu;
submit->fence = NULL;
submit->pid = get_pid(task_pid(current));
+   submit->cmd = (void *)>bos[nr_bos];

/* initially, until copy_from_user() and bo lookup succeeds: */
submit->nr_bos = 0;
@@ -371,14 +373,11 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
*data,
if (args->pipe != MSM_PIPE_3D0)
return -EINVAL;

-   if (args->nr_cmds > MAX_CMDS)
-   return -EINVAL;
-
ret = mutex_lock_interruptible(>struct_mutex);
if (ret)
return ret;

-   submit = submit_create(dev, gpu, args->nr_bos);
+   submit = submit_create(dev, gpu, args->nr_bos, args->nr_cmds);
if (!submit) {
ret = -ENOMEM;
goto out_unlock;
-- 
2.5.5

[PATCH 06/10] drm/msm: wire up vmap shrinker

[Rob Clark]

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.h  |  2 ++
 drivers/gpu/drm/msm/msm_gem.c  | 25 -
 drivers/gpu/drm/msm/msm_gem.h  | 10 +
 drivers/gpu/drm/msm/msm_gem_shrinker.c | 40 ++
 4 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 2c16385..3ab10a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -149,6 +149,7 @@ struct msm_drm_private {
struct drm_mm mm;
} vram;

+   struct notifier_block vmap_notifier;
struct shrinker shrinker;

struct msm_vblank_ctrl vblank_ctrl;
@@ -202,6 +203,7 @@ void msm_gem_put_vaddr_locked(struct drm_gem_object *obj);
 void msm_gem_put_vaddr(struct drm_gem_object *obj);
 int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
 void msm_gem_purge(struct drm_gem_object *obj);
+void msm_gem_vunmap(struct drm_gem_object *obj);
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive);
 void msm_gem_move_to_active(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c05fc1d..886cfe0 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -421,6 +421,7 @@ void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj)
if (msm_obj->vaddr == NULL)
return ERR_PTR(-ENOMEM);
}
+   msm_obj->vmap_count++;
return msm_obj->vaddr;
 }

@@ -435,13 +436,17 @@ void *msm_gem_get_vaddr(struct drm_gem_object *obj)

 void msm_gem_put_vaddr_locked(struct drm_gem_object *obj)
 {
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
-   /* no-op for now */
+   WARN_ON(msm_obj->vmap_count < 1);
+   msm_obj->vmap_count--;
 }

 void msm_gem_put_vaddr(struct drm_gem_object *obj)
 {
-   /* no-op for now */
+   mutex_lock(>dev->struct_mutex);
+   msm_gem_put_vaddr_locked(obj);
+   mutex_unlock(>dev->struct_mutex);
 }

 /* Update madvise status, returns true if not purged, else
@@ -470,8 +475,7 @@ void msm_gem_purge(struct drm_gem_object *obj)

put_iova(obj);

-   vunmap(msm_obj->vaddr);
-   msm_obj->vaddr = NULL;
+   msm_gem_vunmap(obj);

put_pages(obj);

@@ -491,6 +495,17 @@ void msm_gem_purge(struct drm_gem_object *obj)
0, (loff_t)-1);
 }

+void msm_gem_vunmap(struct drm_gem_object *obj)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+   if (!msm_obj->vaddr || WARN_ON(!is_vunmapable(msm_obj)))
+   return;
+
+   vunmap(msm_obj->vaddr);
+   msm_obj->vaddr = NULL;
+}
+
 /* must be called before _move_to_active().. */
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
@@ -694,7 +709,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)

drm_prime_gem_destroy(obj, msm_obj->sgt);
} else {
-   vunmap(msm_obj->vaddr);
+   msm_gem_vunmap(obj);
put_pages(obj);
}

diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 631dab5..7a4da81 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -34,6 +34,11 @@ struct msm_gem_object {
 */
uint8_t madv;

+   /**
+* count of active vmap'ing
+*/
+   uint8_t vmap_count;
+
/* And object is either:
 *  inactive - on priv->inactive_list
 *  active   - on one one of the gpu's active_list..  well, at
@@ -83,6 +88,11 @@ static inline bool is_purgeable(struct msm_gem_object 
*msm_obj)
!msm_obj->base.dma_buf && !msm_obj->base.import_attach;
 }

+static inline bool is_vunmapable(struct msm_gem_object *msm_obj)
+{
+   return (msm_obj->vmap_count == 0) && msm_obj->vaddr;
+}
+
 #define MAX_CMDS 4

 /* Created per submit-ioctl, to track bo's and cmdstream bufs, etc,
diff --git a/drivers/gpu/drm/msm/msm_gem_shrinker.c 
b/drivers/gpu/drm/msm/msm_gem_shrinker.c
index 2bbd6d0..8d13b9e 100644
--- a/drivers/gpu/drm/msm/msm_gem_shrinker.c
+++ b/drivers/gpu/drm/msm/msm_gem_shrinker.c
@@ -100,6 +100,42 @@ msm_gem_shrinker_scan(struct shrinker *shrinker, struct 
shrink_control *sc)
return freed;
 }

+static int
+msm_gem_shrinker_vmap(struct notifier_block *nb, unsigned long event, void 
*ptr)
+{
+   struct msm_drm_private *priv =
+   container_of(nb, struct msm_drm_private, vmap_notifier);
+   struct drm_device *dev = priv->dev;
+   struct msm_gem_object *msm_obj;
+   unsigned unmapped = 0;
+   bool unlock;
+
+   if (!msm_gem_shrinker_lock(dev, ))
+   return NOTIFY_DONE;
+
+   list_for_each_entry(msm_obj, >inactive_list, mm_list) {
+ 

[PATCH 05/10] drm/msm: change gem->vmap() to get/put

[Rob Clark]

Before we can add vmap shrinking, we really need to know which vmap'ings
are currently being used.  So switch to get/put interface.  Stubbed put
fxns for now.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  6 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |  5 -
 drivers/gpu/drm/msm/msm_drv.h   |  6 --
 drivers/gpu/drm/msm/msm_fbdev.c |  3 ++-
 drivers/gpu/drm/msm/msm_gem.c   | 17 ++---
 drivers/gpu/drm/msm/msm_gem_prime.c |  4 ++--
 drivers/gpu/drm/msm/msm_gem_submit.c|  4 +++-
 drivers/gpu/drm/msm/msm_rd.c|  4 +++-
 drivers/gpu/drm/msm/msm_ringbuffer.c|  6 --
 9 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2aec27d..7dfe22e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -407,7 +407,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
return ret;
}

-   adreno_gpu->memptrs = msm_gem_vaddr(adreno_gpu->memptrs_bo);
+   adreno_gpu->memptrs = msm_gem_get_vaddr(adreno_gpu->memptrs_bo);
if (IS_ERR(adreno_gpu->memptrs)) {
dev_err(drm->dev, "could not vmap memptrs\n");
return -ENOMEM;
@@ -426,8 +426,12 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 void adreno_gpu_cleanup(struct adreno_gpu *gpu)
 {
if (gpu->memptrs_bo) {
+   if (gpu->memptrs)
+   msm_gem_put_vaddr(gpu->memptrs_bo);
+
if (gpu->memptrs_iova)
msm_gem_put_iova(gpu->memptrs_bo, gpu->base.id);
+
drm_gem_object_unreference_unlocked(gpu->memptrs_bo);
}
release_firmware(gpu->pm4);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a3e47ad8..fb8ba9d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1066,7 +1066,7 @@ static int dsi_cmd_dma_add(struct msm_dsi_host *msm_host,
}

if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
-   data = msm_gem_vaddr(msm_host->tx_gem_obj);
+   data = msm_gem_get_vaddr(msm_host->tx_gem_obj);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
pr_err("%s: get vaddr failed, %d\n", __func__, ret);
@@ -1094,6 +1094,9 @@ static int dsi_cmd_dma_add(struct msm_dsi_host *msm_host,
if (packet.size < len)
memset(data + packet.size, 0xff, len - packet.size);

+   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
+   msm_gem_put_vaddr(msm_host->tx_gem_obj);
+
return len;
 }

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index bcf33cf..2c16385 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -196,8 +196,10 @@ struct drm_gem_object 
*msm_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
 int msm_gem_prime_pin(struct drm_gem_object *obj);
 void msm_gem_prime_unpin(struct drm_gem_object *obj);
-void *msm_gem_vaddr_locked(struct drm_gem_object *obj);
-void *msm_gem_vaddr(struct drm_gem_object *obj);
+void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj);
+void *msm_gem_get_vaddr(struct drm_gem_object *obj);
+void msm_gem_put_vaddr_locked(struct drm_gem_object *obj);
+void msm_gem_put_vaddr(struct drm_gem_object *obj);
 int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
 void msm_gem_purge(struct drm_gem_object *obj);
 int msm_gem_sync_object(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index a9223be..ffd4a33 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -158,7 +158,7 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,

dev->mode_config.fb_base = paddr;

-   fbi->screen_base = msm_gem_vaddr_locked(fbdev->bo);
+   fbi->screen_base = msm_gem_get_vaddr_locked(fbdev->bo);
if (IS_ERR(fbi->screen_base)) {
ret = PTR_ERR(fbi->screen_base);
goto fail_unlock;
@@ -251,6 +251,7 @@ void msm_fbdev_free(struct drm_device *dev)

/* this will free the backing object */
if (fbdev->fb) {
+   msm_gem_put_vaddr(fbdev->bo);
drm_framebuffer_unregister_private(fbdev->fb);
drm_framebuffer_remove(fbdev->fb);
}
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 444d0b5..c05fc1d 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -408,7 +408,7 @@ fail:
return ret;
 }

-void *msm_gem_vaddr_locked(struct drm_gem_object *obj)
+void *msm_gem_get_vaddr_locked(struct drm_gem_object *obj)
 {
struct msm_gem_object 

[PATCH 04/10] drm/msm: shrinker support

[Rob Clark]

For a first step, only purge obj->madv==DONTNEED objects.  We could be
more agressive and next try unpinning inactive objects..  but that is
only useful if you have swap.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/msm_drv.c  |   5 ++
 drivers/gpu/drm/msm/msm_drv.h  |   8 +++
 drivers/gpu/drm/msm/msm_gem.c  |  32 +
 drivers/gpu/drm/msm/msm_gem.h  |   6 ++
 drivers/gpu/drm/msm/msm_gem_shrinker.c | 128 +
 6 files changed, 180 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/msm_gem_shrinker.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 60cb026..2bb2c4b 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -45,6 +45,7 @@ msm-y := \
msm_fence.o \
msm_gem.o \
msm_gem_prime.o \
+   msm_gem_shrinker.o \
msm_gem_submit.o \
msm_gpu.o \
msm_iommu.o \
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index ddf6878..3e15a50 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -195,6 +195,8 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}

+   msm_gem_shrinker_cleanup(ddev);
+
drm_kms_helper_poll_fini(ddev);

drm_connector_unregister_all(ddev);
@@ -352,6 +354,7 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
}

ddev->dev_private = priv;
+   priv->dev = ddev;

priv->wq = alloc_ordered_workqueue("msm", 0);
priv->atomic_wq = alloc_ordered_workqueue("msm:atomic", 0);
@@ -376,6 +379,8 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
if (ret)
goto fail;

+   msm_gem_shrinker_init(ddev);
+
switch (get_mdp_ver(pdev)) {
case 4:
kms = mdp4_kms_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index f757ade..bcf33cf 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -77,6 +77,8 @@ struct msm_vblank_ctrl {

 struct msm_drm_private {

+   struct drm_device *dev;
+
struct msm_kms *kms;

/* subordinate devices, if present: */
@@ -147,6 +149,8 @@ struct msm_drm_private {
struct drm_mm mm;
} vram;

+   struct shrinker shrinker;
+
struct msm_vblank_ctrl vblank_ctrl;
 };

@@ -165,6 +169,9 @@ void msm_gem_submit_free(struct msm_gem_submit *submit);
 int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct drm_file *file);

+void msm_gem_shrinker_init(struct drm_device *dev);
+void msm_gem_shrinker_cleanup(struct drm_device *dev);
+
 int msm_gem_mmap_obj(struct drm_gem_object *obj,
struct vm_area_struct *vma);
 int msm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
@@ -192,6 +199,7 @@ void msm_gem_prime_unpin(struct drm_gem_object *obj);
 void *msm_gem_vaddr_locked(struct drm_gem_object *obj);
 void *msm_gem_vaddr(struct drm_gem_object *obj);
 int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
+void msm_gem_purge(struct drm_gem_object *obj);
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive);
 void msm_gem_move_to_active(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 2636c27..444d0b5 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -448,6 +448,38 @@ int msm_gem_madvise(struct drm_gem_object *obj, unsigned 
madv)
return (msm_obj->madv != __MSM_MADV_PURGED);
 }

+void msm_gem_purge(struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj->dev;
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+   WARN_ON(!mutex_is_locked(>struct_mutex));
+   WARN_ON(!is_purgeable(msm_obj));
+   WARN_ON(obj->import_attach);
+
+   put_iova(obj);
+
+   vunmap(msm_obj->vaddr);
+   msm_obj->vaddr = NULL;
+
+   put_pages(obj);
+
+   msm_obj->madv = __MSM_MADV_PURGED;
+
+   drm_vma_node_unmap(>vma_node, dev->anon_inode->i_mapping);
+   drm_gem_free_mmap_offset(obj);
+
+   /* Our goal here is to return as much of the memory as
+* is possible back to the system as we are called from OOM.
+* To do this we must instruct the shmfs to drop all of its
+* backing pages, *now*.
+*/
+   shmem_truncate_range(file_inode(obj->filp), 0, (loff_t)-1);
+
+   invalidate_mapping_pages(file_inode(obj->filp)->i_mapping,
+   0, (loff_t)-1);
+}
+
 /* must be called before _move_to_active().. */
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index fa8e1f1..631dab5 

[PATCH 03/10] drm/msm: add put_iova() helper

[Rob Clark]

We'll need this too for shrinker/purging.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c40db08..2636c27 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -276,6 +276,26 @@ uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
return offset;
 }

+static void
+put_iova(struct drm_gem_object *obj)
+{
+   struct drm_device *dev = obj->dev;
+   struct msm_drm_private *priv = obj->dev->dev_private;
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   int id;
+
+   WARN_ON(!mutex_is_locked(>struct_mutex));
+
+   for (id = 0; id < ARRAY_SIZE(msm_obj->domain); id++) {
+   struct msm_mmu *mmu = priv->mmus[id];
+   if (mmu && msm_obj->domain[id].iova) {
+   uint32_t offset = msm_obj->domain[id].iova;
+   mmu->funcs->unmap(mmu, offset, msm_obj->sgt, obj->size);
+   msm_obj->domain[id].iova = 0;
+   }
+   }
+}
+
 /* should be called under struct_mutex.. although it can be called
  * from atomic context without struct_mutex to acquire an extra
  * iova ref if you know one is already held.
@@ -608,9 +628,7 @@ void msm_gem_describe_objects(struct list_head *list, 
struct seq_file *m)
 void msm_gem_free_object(struct drm_gem_object *obj)
 {
struct drm_device *dev = obj->dev;
-   struct msm_drm_private *priv = obj->dev->dev_private;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
-   int id;

WARN_ON(!mutex_is_locked(>struct_mutex));

@@ -619,13 +637,7 @@ void msm_gem_free_object(struct drm_gem_object *obj)

list_del(_obj->mm_list);

-   for (id = 0; id < ARRAY_SIZE(msm_obj->domain); id++) {
-   struct msm_mmu *mmu = priv->mmus[id];
-   if (mmu && msm_obj->domain[id].iova) {
-   uint32_t offset = msm_obj->domain[id].iova;
-   mmu->funcs->unmap(mmu, offset, msm_obj->sgt, obj->size);
-   }
-   }
+   put_iova(obj);

if (obj->import_attach) {
if (msm_obj->vaddr)
-- 
2.5.5

[PATCH 02/10] drm/msm: add madvise ioctl

[Rob Clark]

Doesn't do anything too interesting until we wire up shrinker.  Pretty
much lifted from i915.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_drv.c | 39 +++
 drivers/gpu/drm/msm/msm_drv.h |  1 +
 drivers/gpu/drm/msm/msm_gem.c | 35 +--
 drivers/gpu/drm/msm/msm_gem.h |  5 +
 include/uapi/drm/msm_drm.h| 25 -
 5 files changed, 102 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c65409..ddf6878 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -690,6 +690,44 @@ static int msm_ioctl_wait_fence(struct drm_device *dev, 
void *data,
return msm_wait_fence(priv->gpu->fctx, args->fence, , true);
 }

+static int msm_ioctl_gem_madvise(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct drm_msm_gem_madvise *args = data;
+   struct drm_gem_object *obj;
+   int ret;
+
+   switch (args->madv) {
+   case MSM_MADV_DONTNEED:
+   case MSM_MADV_WILLNEED:
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;
+
+   obj = drm_gem_object_lookup(file, args->handle);
+   if (!obj) {
+   ret = -ENOENT;
+   goto unlock;
+   }
+
+   ret = msm_gem_madvise(obj, args->madv);
+   if (ret >= 0) {
+   args->retained = ret;
+   ret = 0;
+   }
+
+   drm_gem_object_unreference(obj);
+
+unlock:
+   mutex_unlock(>struct_mutex);
+   return ret;
+}
+
 static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
DRM_AUTH|DRM_RENDER_ALLOW),
@@ -698,6 +736,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GEM_CPU_FINI, msm_ioctl_gem_cpu_fini, 
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_SUBMIT,   msm_ioctl_gem_submit,   
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_WAIT_FENCE,   msm_ioctl_wait_fence,   
DRM_AUTH|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE,  msm_ioctl_gem_madvise,  
DRM_AUTH|DRM_RENDER_ALLOW),
 };

 static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 5b2963f..f757ade 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -191,6 +191,7 @@ int msm_gem_prime_pin(struct drm_gem_object *obj);
 void msm_gem_prime_unpin(struct drm_gem_object *obj);
 void *msm_gem_vaddr_locked(struct drm_gem_object *obj);
 void *msm_gem_vaddr(struct drm_gem_object *obj);
+int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv);
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive);
 void msm_gem_move_to_active(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 69836f5..c40db08 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -413,6 +413,21 @@ void *msm_gem_vaddr(struct drm_gem_object *obj)
return ret;
 }

+/* Update madvise status, returns true if not purged, else
+ * false or -errno.
+ */
+int msm_gem_madvise(struct drm_gem_object *obj, unsigned madv)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+
+   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+
+   if (msm_obj->madv != __MSM_MADV_PURGED)
+   msm_obj->madv = madv;
+
+   return (msm_obj->madv != __MSM_MADV_PURGED);
+}
+
 /* must be called before _move_to_active().. */
 int msm_gem_sync_object(struct drm_gem_object *obj,
struct msm_fence_context *fctx, bool exclusive)
@@ -464,6 +479,7 @@ void msm_gem_move_to_active(struct drm_gem_object *obj,
struct msm_gpu *gpu, bool exclusive, struct fence *fence)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED);
msm_obj->gpu = gpu;
if (exclusive)
reservation_object_add_excl_fence(msm_obj->resv, fence);
@@ -532,13 +548,27 @@ void msm_gem_describe(struct drm_gem_object *obj, struct 
seq_file *m)
struct reservation_object_list *fobj;
struct fence *fence;
uint64_t off = drm_vma_node_start(>vma_node);
+   const char *madv;

WARN_ON(!mutex_is_locked(>dev->struct_mutex));

-   seq_printf(m, "%08x: %c %2d (%2d) %08llx %p %zu\n",
+   switch (msm_obj->madv) {
+   case __MSM_MADV_PURGED:
+   madv = " purged";
+   break;
+   case MSM_MADV_DONTNEED:
+   madv = " purgeable";
+   break;
+   case MSM_MADV_WILLNEED:
+   default:
+   

[PATCH 01/10] drm/msm: use mutex_lock_interruptible for submit ioctl

[Rob Clark]

Be kinder to things that do lots of signal handling (ie. Xorg)

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index eb4bb8b..ea5f709 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -372,11 +372,15 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
*data,
if (args->nr_cmds > MAX_CMDS)
return -EINVAL;

-   submit = submit_create(dev, gpu, args->nr_bos);
-   if (!submit)
-   return -ENOMEM;
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   return ret;

-   mutex_lock(>struct_mutex);
+   submit = submit_create(dev, gpu, args->nr_bos);
+   if (!submit) {
+   ret = -ENOMEM;
+   goto out_unlock;
+   }

ret = submit_lookup_objects(submit, args, file);
if (ret)
@@ -462,6 +466,7 @@ out:
submit_cleanup(submit);
if (ret)
msm_gem_submit_free(submit);
+out_unlock:
mutex_unlock(>struct_mutex);
return ret;
 }
-- 
2.5.5

[PATCH 00/10] drm/msm: some stuff I'm working on for 4.8

[Rob Clark]

Also working on fence-fd support for submit ioctl, but that is
depending on some other patches from Gustavo, and not so much
actually tested yet, so unlikely to be 4.8 material.  But I'll
send an RFC at least in near future.

Main interesting thing here is, I think, shrinker.  Currently
it is limited to purging madvise'd buffers (userspace bo cache)
and vmaps.  Maybe someday I'll setup a swap partition and take
this further, but the more important things to solve in the
short term are keeping the userspace bo-cache from causing
problems on devices w/ less memory (<= 1G) and keeping vmap's
from being a problem on 32b systems.

Rob Clark (10):
  drm/msm: use mutex_lock_interruptible for submit ioctl
  drm/msm: add madvise ioctl
  drm/msm: add put_iova() helper
  drm/msm: shrinker support
  drm/msm: change gem->vmap() to get/put
  drm/msm: wire up vmap shrinker
  drm/msm: deal with arbitrary # of cmd buffers
  drm/msm: bump kernel api version
  drm/msm/rd: split out snapshot_buf helper
  drm/msm/rd: add module param to dump all bo's

 drivers/gpu/drm/msm/Makefile|   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |   6 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c  |   5 +-
 drivers/gpu/drm/msm/msm_drv.c   |  59 ++-
 drivers/gpu/drm/msm/msm_drv.h   |  17 +++-
 drivers/gpu/drm/msm/msm_fbdev.c |   3 +-
 drivers/gpu/drm/msm/msm_gem.c   | 131 ++---
 drivers/gpu/drm/msm/msm_gem.h   |  23 -
 drivers/gpu/drm/msm/msm_gem_prime.c |   4 +-
 drivers/gpu/drm/msm/msm_gem_shrinker.c  | 168 
 drivers/gpu/drm/msm/msm_gem_submit.c|  26 +++--
 drivers/gpu/drm/msm/msm_rd.c|  66 ++---
 drivers/gpu/drm/msm/msm_ringbuffer.c|   6 +-
 include/uapi/drm/msm_drm.h  |  25 -
 14 files changed, 485 insertions(+), 55 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_gem_shrinker.c

-- 
2.5.5

[radeon-alex:amd-staging-4.6 645/989] drivers/gpu/drm/amd/amdgpu/../dal/dc/i2caux/dce80/i2c_sw_engine_dce80.c:53:23: error: 'ddc_hw_status_addr' defined but not used

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.6
head:   beebb009c05fd5a89617327a9cfb724f19cecf1b
commit: 9c681b658ebf2efed9c20e4b2051e543bc1fcb9a [645/989] drm/amd/dal: Adding 
Hawaii and Bonaire support to DAL
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 9c681b658ebf2efed9c20e4b2051e543bc1fcb9a
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the radeon-alex/amd-staging-4.6 HEAD 
beebb009c05fd5a89617327a9cfb724f19cecf1b builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../dal/dc/i2caux/dce80/i2c_sw_engine_dce80.c:53:23:
>>  error: 'ddc_hw_status_addr' defined but not used 
>> [-Werror=unused-const-variable=]
static const uint32_t ddc_hw_status_addr[] = {
  ^~
   cc1: all warnings being treated as errors

vim +/ddc_hw_status_addr +53 
drivers/gpu/drm/amd/amdgpu/../dal/dc/i2caux/dce80/i2c_sw_engine_dce80.c

37   * Header of this unit
38   */
39  
40  #include "i2c_sw_engine_dce80.h"
41  
42  /*
43   * Post-requisites: headers required by this unit
44   */
45  
46  #include "dce/dce_8_0_d.h"
47  #include "dce/dce_8_0_sh_mask.h"
48  
49  /*
50   * This unit
51   */
52  
  > 53  static const uint32_t ddc_hw_status_addr[] = {
54  mmDC_I2C_DDC1_HW_STATUS,
55  mmDC_I2C_DDC2_HW_STATUS,
56  mmDC_I2C_DDC3_HW_STATUS,
57  mmDC_I2C_DDC4_HW_STATUS,
58  mmDC_I2C_DDC5_HW_STATUS,
59  mmDC_I2C_DDC6_HW_STATUS,
60  mmDC_I2C_DDCVGA_HW_STATUS
61  };

---
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: 54177 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/f3686af8/attachment-0001.obj>

[PATCHv16 07/13] cec.txt: add CEC framework documentation

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:22 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Document the new HDMI CEC framework.

As we'll be moving documentation to Sphinx/Rst, it would be good if
you could make it work fine with sphinx, as this will likely be needed
for Kernel 4.9. Right now it most works, although several warnings are
produced: 

/devel/v4l/patchwork/tmp/cec.txt:40: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:40: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:40: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:40: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:40: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:42: WARNING: Definition list ends without a 
blank line; unexpected unindent.
/devel/v4l/patchwork/tmp/cec.txt:42: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:67: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:71: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:92: ERROR: Unexpected indentation.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:87: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:92: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:93: WARNING: Block quote ends without a blank 
line; unexpected unindent.
/devel/v4l/patchwork/tmp/cec.txt:93: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:93: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:95: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:97: WARNING: Definition list ends without a 
blank line; unexpected unindent.
/devel/v4l/patchwork/tmp/cec.txt:105: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:105: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:118: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:118: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:130: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:130: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:144: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:144: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:144: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:161: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:161: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:161: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:173: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:194: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:203: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:203: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:214: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:217: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:217: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:217: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:217: WARNING: Inline emphasis start-string 
without end-string.
/devel/v4l/patchwork/tmp/cec.txt:219: WARNING: Definition list ends without a 
blank line; unexpected unindent.
/devel/v4l/patchwork/tmp/cec.txt:224: WARNING: Inline emphasis start-string 
without 

[PATCH 22/22] arm64: dts: apq8016-sbc: Add HDMI display support

[Archit Taneja]

The APQ8016-sbc provides a HDMI output. The APQ8016 display block only
provides a MIPI DSI output. So, the board has a ADV7533 DSI to HDMI
encoder chip that sits between the DSI PHY output and the HDMI
connector.

Add the ADV7533 DT node under its I2C control bus, and tie the DSI
output port to the ADV7533's input port.

Cc: Andy Gross 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi | 48 +
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  | 82 ++
 2 files changed, 130 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
index ee828a8..e1e6c6b 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi
@@ -24,4 +24,52 @@
bias-pull-up;
};
};
+
+   adv7533_int_active: adv533_int_active {
+   pinmux {
+   function = "gpio";
+   pins = "gpio31";
+   };
+   pinconf {
+   pins = "gpio31";
+   drive-strength = <16>;
+   bias-disable;
+   };
+   };
+
+   adv7533_int_suspend: adv7533_int_suspend {
+   pinmux {
+   function = "gpio";
+   pins = "gpio31";
+   };
+   pinconf {
+   pins = "gpio31";
+   drive-strength = <2>;
+   bias-disable;
+   };
+   };
+
+   adv7533_switch_active: adv7533_switch_active {
+   pinmux {
+   function = "gpio";
+   pins = "gpio32";
+   };
+   pinconf {
+   pins = "gpio32";
+   drive-strength = <16>;
+   bias-disable;
+   };
+   };
+
+   adv7533_switch_suspend: adv7533_switch_suspend {
+   pinmux {
+   function = "gpio";
+   pins = "gpio32";
+   };
+   pinconf {
+   pins = "gpio32";
+   drive-strength = <2>;
+   bias-disable;
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 205ef89..5045695 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -59,6 +59,47 @@
/* On High speed expansion */
label = "HS-I2C2";
status = "okay";
+
+   adv_bridge: bridge at 39 {
+   status = "okay";
+
+   compatible = "adi,adv7533";
+   reg = <0x39>;
+
+   interrupt-parent = <>;
+   interrupts = <31 2>;
+
+   adi,dsi-lanes = <4>;
+
+   pd-gpios = < 32 0>;
+
+   avdd-supply = <_l6>;
+   v1p2-supply = <_l6>;
+   v3p3-supply = <_l17>;
+
+   pinctrl-names = "default","sleep";
+   pinctrl-0 = <_int_active 
_switch_active>;
+   pinctrl-1 = <_int_suspend 
_switch_suspend>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   adv7533_in: endpoint {
+   remote-endpoint = 
<_out>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   adv7533_out: endpoint {
+   remote-endpoint = 
<_con>;
+   };
+   };
+   };
+   };
};

i2c at 78ba000 {
@@ -164,6 +205,36 @@
lpass at 07708000 {
status = "okay";
};
+
+   mdss at 1a0 {
+   status = "okay";
+
+   mdp at 1a01000 {
+   status = "okay";
+   };
+
+   dsi at 1a98000 {
+   

[PATCH 21/22] arm64: dts: msm8916: Add display support

[Archit Taneja]

The MSM8916 SoC contains a MDP5 based display block, and one DSI output.
Add the top level MDSS DT node, and the MDP5, DSI and DSI PHY children
sub-blocks. Establish the link between MDP5's INTF1 output port and DSI's
input port.

Cc: Andy Gross 
Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 120 ++
 1 file changed, 120 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 9681200..d8cccfc 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -537,6 +537,126 @@
clocks = < GCC_PRNG_AHB_CLK>;
clock-names = "core";
};
+
+   mdss: mdss at 1a0 {
+   compatible = "qcom,mdss";
+   reg = <0x1a0 0x1000>,
+ <0x1ac8000 0x3000>;
+   reg-names = "mdss_phys", "vbif_phys";
+
+   power-domains = < MDSS_GDSC>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_VSYNC_CLK>;
+   clock-names = "iface_clk",
+ "bus_clk",
+ "vsync_clk";
+
+   interrupts = <0 72 0>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mdp: mdp at 1a01000 {
+   compatible = "qcom,mdp5";
+   reg = <0x1a01000 0x9>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <>;
+   interrupts = <0 0>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_VSYNC_CLK>;
+   clock-names = "iface_clk",
+ "bus_clk",
+ "core_clk",
+ "vsync_clk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mdp5_intf1_out: endpoint {
+   remote-endpoint = 
<_in>;
+   };
+   };
+   };
+   };
+
+   dsi0: dsi at 1a98000 {
+   compatible = "qcom,mdss-dsi-ctrl";
+   qcom,dsi-host-index = <0>;
+   reg = <0x1a98000 0x25c>;
+   reg-names = "dsi_ctrl";
+
+   interrupt-parent = <>;
+   interrupts = <4 0>;
+
+   assigned-clocks = < BYTE0_CLK_SRC>,
+ < PCLK0_CLK_SRC>;
+   assigned-clock-parents = <_phy0 0>,
+<_phy0 1>;
+
+   clocks = < GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_BYTE0_CLK>,
+< GCC_MDSS_PCLK0_CLK>,
+< GCC_MDSS_ESC0_CLK>;
+   clock-names = "mdp_core_clk",
+ "iface_clk",
+ "bus_clk",
+ "byte_clk",
+ "pixel_clk",
+ "core_clk";
+   phys = <_phy0>;
+   phy-names = "dsi-phy";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+ 

[PATCH 20/22] dt-bindings: msm/mdp: Provide details on MDP interface ports

[Archit Taneja]

The MDP4/5 DT node now contains a list of ports that describe how it
connects to external encoder interfaces like DSI and HDMI. These follow
the standard of_graph bindings, and allow us to get rid of the 'connectors'
phandle that contained a list of all the external encoders connected to
MDP.

The GPU phandle is removed too until we figure out what's the right way
to specify it in DT.

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/msm/mdp4.txt   | 68 --
 .../devicetree/bindings/display/msm/mdp5.txt   | 48 ++-
 2 files changed, 110 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.txt 
b/Documentation/devicetree/bindings/display/msm/mdp4.txt
index 1de9b17..3c341a1 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp4.txt
+++ b/Documentation/devicetree/bindings/display/msm/mdp4.txt
@@ -10,7 +10,6 @@ Required properties:
   * "qcom,mdp4" - mdp4
 - reg: Physical base address and length of the controller's registers.
 - interrupts: The interrupt signal from the display controller.
-- connectors: array of phandles for output device(s)
 - clocks: device clocks
   See ../clocks/clock-bindings.txt for details.
 - clock-names: the following clocks are required.
@@ -20,9 +19,23 @@ Required properties:
   * "lut_clk"
   * "hdmi_clk"
   * "tv_clk"
+- ports: contains the list of output ports from MDP. These connect to 
interfaces
+  that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
+  special case since it is a part of the MDP block itself).
+
+  Each output port contains an endpoint that describes how it is connected to 
an
+  external interface. These are described by the standard properties documented
+  here:
+   Documentation/devicetree/bindings/graph.txt
+   Documentation/devicetree/bindings/media/video-interfaces.txt
+
+  The output port mappings are:
+   Port 0 -> LCDC/LVDS
+   Port 1 -> DSI1 Cmd/Video
+   Port 2 -> DSI2 Cmd/Video
+   Port 3 -> DTV

 Optional properties:
-- gpus: phandle for gpu device
 - clock-names: the following clocks are optional:
   * "lut_clk"

@@ -31,12 +44,27 @@ Example:
 / {
...

-   mdp: qcom,mdp at 510 {
+   hdmi: hdmi at 4a0 {
+   ...
+   ports {
+   ...
+   port at 0 {
+   reg = <0>;
+   hdmi_in: endpoint {
+   remote-endpoint = <_dtv_out>;
+   };
+   };
+   ...
+   };
+   ...
+   };
+
+   ...
+
+   mdp: mdp at 510 {
compatible = "qcom,mdp4";
reg = <0x0510 0xf>;
interrupts = ;
-   connectors = <>;
-   gpus = <>;
clock-names =
"core_clk",
"iface_clk",
@@ -50,5 +78,35 @@ Example:
< MDP_LUT_CLK>,
< HDMI_TV_CLK>,
< MDP_TV_CLK>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mdp_lvds_out: endpoint {
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   mdp_dsi1_out: endpoint {
+   };
+   };
+
+   port at 2 {
+   reg = <2>;
+   mdp_dsi2_out: endpoint {
+   };
+   };
+
+   port at 3 {
+   reg = <3>;
+   mdp_dtv_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
};
 };
diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt 
b/Documentation/devicetree/bindings/display/msm/mdp5.txt
index b395905..30c11ea 100644
--- a/Documentation/devicetree/bindings/display/msm/mdp5.txt
+++ b/Documentation/devicetree/bindings/display/msm/mdp5.txt
@@ -49,12 +49,36 @@ Required properties:
 -   * "iface_clk"
 -   * "core_clk"
 -   * "vsync_clk"
+- ports: contains the list of output ports from MDP. These connect to 
interfaces
+  that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
+  special case since it is a part of the MDP block itself).
+
+  Each output port 

[PATCH 19/22] dt-bindings: msm/mdp5: Add MDP5 display bindings

[Archit Taneja]

Add a new doc for DT bindings for platforms that contain MDP5 display
controller hardware. The doc describes bindings for the top level
MDSS wrapper hardware and MDP5 itself.

Add an example for the bindings as found in MSM8916.

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/msm/mdp5.txt   | 114 +
 1 file changed, 114 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/msm/mdp5.txt

diff --git a/Documentation/devicetree/bindings/display/msm/mdp5.txt 
b/Documentation/devicetree/bindings/display/msm/mdp5.txt
new file mode 100644
index 000..b395905
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/mdp5.txt
@@ -0,0 +1,114 @@
+Qualcomm adreno/snapdragon MDP5 display controller
+
+Description:
+
+This is the bindings documentation for the Mobile Display Subsytem(MDSS) that
+encapsulates sub-blocks like MDP5, DSI, HDMI, eDP etc, and the MDP5 display
+controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994 and MSM8996.
+
+MDSS:
+Required properties:
+- compatible:
+  * "qcom,mdss" - MDSS
+- reg: Physical base address and length of the controller's registers.
+- reg-names: The names of register regions. The following regions are required:
+  * "mdss_phys"
+  * "vbif_phys"
+- interrupts: The interrupt signal from MDSS.
+- interrupt-controller: identifies the node as an interrupt controller.
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- power-domains: a power domain consumer specifier according to
+  Documentation/devicetree/bindings/power/power_domain.txt
+- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required.
+  * "iface_clk"
+  * "bus_clk"
+  * "vsync_clk"
+- #address-cells: number of address cells for the MDSS children. Should be 1.
+- #size-cells: Should be 1.
+- ranges: parent bus address space is the same as the child bus address space.
+
+Optional properties:
+- clock-names: the following clocks are optional:
+  * "lut_clk"
+
+MDP5:
+Required properties:
+- compatible:
+  * "qcom,mdp5" - MDP5
+- reg: Physical base address and length of the controller's registers.
+- reg-names: The names of register regions. The following regions are required:
+  * "mdp_phys"
+- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
+- interrupt-parent: phandle to the MDSS block
+  through MDP block
+- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required.
+-   * "bus_clk"
+-   * "iface_clk"
+-   * "core_clk"
+-   * "vsync_clk"
+
+Optional properties:
+- clock-names: the following clocks are optional:
+  * "lut_clk"
+
+
+Example:
+
+/ {
+   ...
+
+   mdss: mdss at 1a0 {
+   compatible = "qcom,mdss";
+   reg = <0x1a0 0x1000>,
+ <0x1ac8000 0x3000>;
+   reg-names = "mdss_phys", "vbif_phys";
+
+   power-domains = < MDSS_GDSC>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_VSYNC_CLK>;
+   clock-names = "iface_clk",
+ "bus_clk",
+ "vsync_clk"
+
+   interrupts = <0 72 0>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   mdp: mdp at 1a01000 {
+   compatible = "qcom,mdp5";
+   reg = <0x1a01000 0x9>;
+   reg-names = "mdp_phys";
+
+   interrupt-parent = <>;
+   interrupts = <0 0>;
+
+   clocks = < GCC_MDSS_AHB_CLK>,
+< GCC_MDSS_AXI_CLK>,
+< GCC_MDSS_MDP_CLK>,
+< GCC_MDSS_VSYNC_CLK>;
+   clock-names = "iface_clk",
+ "bus_clk",
+ "core_clk",
+ "vsync_clk";
+
+   };
+
+   dsi0: dsi at 1a98000 {
+   ...
+   };
+
+   dsi_phy0: dsi-phy at 1a98300 {
+   ...
+   };
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 18/22] dt-bindings: msm/mdp4: Create a separate binding doc for MDP4

[Archit Taneja]

MDP4 and MDP5 vary a bit in terms of device hierarchy and the properties
they require. Rename the binding doc to mdp4.txt and remove MDP5 specific
pieces. A separate document will be created for MDP5

Cc: Rob Herring 
Cc: devicetree at vger.kernel.org

Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/display/msm/mdp.txt| 57 --
 .../devicetree/bindings/display/msm/mdp4.txt   | 54 
 2 files changed, 54 insertions(+), 57 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/msm/mdp.txt
 create mode 100644 Documentation/devicetree/bindings/display/msm/mdp4.txt

diff --git a/Documentation/devicetree/bindings/display/msm/mdp.txt 
b/Documentation/devicetree/bindings/display/msm/mdp.txt
deleted file mode 100644
index ebfe016..000
--- a/Documentation/devicetree/bindings/display/msm/mdp.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Qualcomm adreno/snapdragon display controller
-
-Required properties:
-- compatible:
-  * "qcom,mdp4" - mdp4
-  * "qcom,mdp5" - mdp5
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The interrupt signal from the display controller.
-- connectors: array of phandles for output device(s)
-- clocks: device clocks
-  See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required.
-  For MDP4:
-   * "core_clk"
-   * "iface_clk"
-   * "bus_clk"
-   * "lut_clk"
-   * "hdmi_clk"
-   * "tv_clk"
-  For MDP5:
-   * "bus_clk"
-   * "iface_clk"
-   * "core_clk"
-   * "lut_clk" (some MDP5 versions may not need this)
-   * "vsync_clk"
-
-Optional properties:
-- gpus: phandle for gpu device
-- clock-names: the following clocks are optional:
-  * "lut_clk"
-
-Example:
-
-/ {
-   ...
-
-   mdp: qcom,mdp at 510 {
-   compatible = "qcom,mdp4";
-   reg = <0x0510 0xf>;
-   interrupts = ;
-   connectors = <>;
-   gpus = <>;
-   clock-names =
-   "core_clk",
-   "iface_clk",
-   "lut_clk",
-   "hdmi_clk",
-   "tv_clk";
-   clocks =
-   < MDP_CLK>,
-   < MDP_AHB_CLK>,
-   < MDP_AXI_CLK>,
-   < MDP_LUT_CLK>,
-   < HDMI_TV_CLK>,
-   < MDP_TV_CLK>;
-   };
-};
diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.txt 
b/Documentation/devicetree/bindings/display/msm/mdp4.txt
new file mode 100644
index 000..1de9b17
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/mdp4.txt
@@ -0,0 +1,54 @@
+Qualcomm adreno/snapdragon MDP4 display controller
+
+Description:
+
+This is the bindings documentation for the MDP4 display controller found in
+SoCs like MSM8960, APQ8064 and MSM8660.
+
+Required properties:
+- compatible:
+  * "qcom,mdp4" - mdp4
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt signal from the display controller.
+- connectors: array of phandles for output device(s)
+- clocks: device clocks
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required.
+  * "core_clk"
+  * "iface_clk"
+  * "bus_clk"
+  * "lut_clk"
+  * "hdmi_clk"
+  * "tv_clk"
+
+Optional properties:
+- gpus: phandle for gpu device
+- clock-names: the following clocks are optional:
+  * "lut_clk"
+
+Example:
+
+/ {
+   ...
+
+   mdp: qcom,mdp at 510 {
+   compatible = "qcom,mdp4";
+   reg = <0x0510 0xf>;
+   interrupts = ;
+   connectors = <>;
+   gpus = <>;
+   clock-names =
+   "core_clk",
+   "iface_clk",
+   "lut_clk",
+   "hdmi_clk",
+   "tv_clk";
+   clocks =
+   < MDP_CLK>,
+   < MDP_AHB_CLK>,
+   < MDP_AXI_CLK>,
+   < MDP_LUT_CLK>,
+   < HDMI_TV_CLK>,
+   < MDP_TV_CLK>;
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 17/22] drm/msm/mdp5: Update compatible strings for MDSS/MDP5

[Archit Taneja]

Introduce new compatible strings for the top level MDSS wrapper device,
and the MDP5 device.

Previously, the "qcom,mdp5" and "qcom,mdss_mdp" compatible strings
were used to match the top level platform_device (which was also tied
to the top level drm_device struct). Now, these strings are used
to match the MDP5 platform device.

Use "qcom,mdss" as the compatible string for top level MDSS device.
This is now used to match the top level platform_device (which is
tied to the drm_device struct).

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +-
 drivers/gpu/drm/msm/msm_drv.c   |  6 ++
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index d40dd65..9e022e6 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -815,12 +815,20 @@ static int mdp5_dev_remove(struct platform_device *pdev)
return 0;
 }

+static const struct of_device_id dt_match[] = {
+   { .compatible = "qcom,mdp5", },
+   /* to support downstream DT files */
+   { .compatible = "qcom,mdss_mdp", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, dt_match);
+
 static struct platform_driver mdp5_driver = {
.probe = mdp5_dev_probe,
.remove = mdp5_dev_remove,
.driver = {
.name = "msm_mdp",
-   /* Add a DT match field once we move to new hierarchy */
+   .of_match_table = dt_match,
},
 };

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 24c63ec..ad833d7 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1001,10 +1001,8 @@ static int msm_pdev_remove(struct platform_device *pdev)
 }

 static const struct of_device_id dt_match[] = {
-   { .compatible = "qcom,mdp4", .data = (void *) 4 },  /* mdp4 */
-   { .compatible = "qcom,mdp5", .data = (void *) 5 },  /* mdp5 */
-   /* to support downstream DT files */
-   { .compatible = "qcom,mdss_mdp", .data = (void *) 5 },  /* mdp5 */
+   { .compatible = "qcom,mdp4", .data = (void *)4 },   /* MDP4 */
+   { .compatible = "qcom,mdss", .data = (void *)5 },   /* MDP5 MDSS */
{}
 };
 MODULE_DEVICE_TABLE(of, dt_match);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 16/22] drm/msm: Drop the gpu binding

[Archit Taneja]

The driver currently identifies the GPU components it needs by parsing
a phandle list from the 'gpus' DT property.

This isn't the right binding to go with. So, for now, just search all
device nodes and find the gpu node we need by parsing a list of
compatible strings.

Once we know how to link the kms and gpu drivers, we'll drop this method
and use the correct binding.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 4f262f3..24c63ec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -813,25 +813,6 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
 }

-static int add_components(struct device *dev, struct component_match 
**matchptr,
-   const char *name)
-{
-   struct device_node *np = dev->of_node;
-   unsigned i;
-
-   for (i = 0; ; i++) {
-   struct device_node *node;
-
-   node = of_parse_phandle(np, name, i);
-   if (!node)
-   break;
-
-   component_match_add(dev, matchptr, compare_of, node);
-   }
-
-   return 0;
-}
-
 /*
  * Identify what components need to be added by parsing what remote-endpoints
  * our MDP output ports are connected to. In the case of LVDS on MDP4, there
@@ -948,10 +929,31 @@ static int add_display_components(struct device *dev,
return ret;
 }

+/*
+ * We don't know what's the best binding to link the gpu with the drm device.
+ * Fow now, we just hunt for all the possible gpus that we support, and add 
them
+ * as components.
+ */
+static const struct of_device_id msm_gpu_match[] = {
+   { .compatible = "qcom,adreno-3xx" },
+   { .compatible = "qcom,kgsl-3d0" },
+   { },
+};
+
 static int add_gpu_components(struct device *dev,
  struct component_match **matchptr)
 {
-   return add_components(>dev, matchptr, "gpus");
+   struct device_node *np;
+
+   np = of_find_matching_node(NULL, msm_gpu_match);
+   if (!np)
+   return 0;
+
+   of_node_put(np);
+
+   component_match_add(dev, matchptr, compare_of, np);
+
+   return 0;
 }

 static int msm_drm_bind(struct device *dev)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 15/22] drm/msm: Add components for MDP5

[Archit Taneja]

For MDP5 based platforms, the master device isn't the MDP5 platform
device, but the top level MDSS device, which is a parent to MDP5 and
interface (DSI, HDMI, eDP etc) devices.

In order to add components on MDP5 platforms, we first need to populate
the MDSS children, locate the MDP5 child, and then parse its ports to
get the display interfaces.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 61 +--
 1 file changed, 59 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index eb7a8a1..4f262f3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -843,6 +843,20 @@ static int add_components_mdp(struct device *mdp_dev,
 {
struct device_node *np = mdp_dev->of_node;
struct device_node *ep_node;
+   struct device *master_dev;
+
+   /*
+* on MDP4 based platforms, the MDP platform device is the component
+* master that adds other display interface components to itself.
+*
+* on MDP5 based platforms, the MDSS platform device is the component
+* master that adds MDP5 and other display interface components to
+* itself.
+*/
+   if (of_device_is_compatible(np, "qcom,mdp4"))
+   master_dev = mdp_dev;
+   else
+   master_dev = mdp_dev->parent;

for_each_endpoint_of_node(np, ep_node) {
struct device_node *intf;
@@ -877,7 +891,7 @@ static int add_components_mdp(struct device *mdp_dev,
continue;
}

-   component_match_add(mdp_dev, matchptr, compare_of, intf);
+   component_match_add(master_dev, matchptr, compare_of, intf);

of_node_put(intf);
of_node_put(ep_node);
@@ -886,10 +900,52 @@ static int add_components_mdp(struct device *mdp_dev,
return 0;
 }

+static int compare_name_mdp(struct device *dev, void *data)
+{
+   return (strstr(dev_name(dev), "mdp") != NULL);
+}
+
 static int add_display_components(struct device *dev,
  struct component_match **matchptr)
 {
-   return add_components_mdp(dev, matchptr);
+   struct device *mdp_dev;
+   int ret;
+
+   /*
+* MDP5 based devices don't have a flat hierarchy. There is a top level
+* parent: MDSS, and children: MDP5, DSI, HDMI, eDP etc. Populate the
+* children devices, find the MDP5 node, and then add the interfaces
+* to our components list.
+*/
+   if (of_device_is_compatible(dev->of_node, "qcom,mdss")) {
+   ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+   if (ret) {
+   dev_err(dev, "failed to populate children devices\n");
+   return ret;
+   }
+
+   mdp_dev = device_find_child(dev, NULL, compare_name_mdp);
+   if (!mdp_dev) {
+   dev_err(dev, "failed to find MDSS MDP node\n");
+   of_platform_depopulate(dev);
+   return -ENODEV;
+   }
+
+   put_device(mdp_dev);
+
+   /* add the MDP component itself */
+   component_match_add(dev, matchptr, compare_of,
+   mdp_dev->of_node);
+   } else {
+   /* MDP4 */
+   mdp_dev = dev;
+   }
+
+   ret = add_components_mdp(mdp_dev, matchptr);
+   if (ret)
+   of_platform_depopulate(dev);
+
+   return ret;
 }

 static int add_gpu_components(struct device *dev,
@@ -937,6 +993,7 @@ static int msm_pdev_probe(struct platform_device *pdev)
 static int msm_pdev_remove(struct platform_device *pdev)
 {
component_master_del(>dev, _drm_ops);
+   of_platform_depopulate(>dev);

return 0;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 14/22] drm/msm: Add display components by parsing MDP ports

[Archit Taneja]

The kms driver currently identifies all the mdss components it needs by
parsing a phandle list from the 'connectors' DT property.

Instead of this, describe a list of ports that the MDP hardware provides
to the external world. These ports are linked to external encoder
interfaces such as DSI, HDMI. These are also the subcomponent devices
that we need add. This description of ports complies with the generic
graph bindings.

The LVDS port is a special case since it is a part of MDP4 itself, and
its output connects directly to the LVDS panel. In this case, we don't
try to add it as a component.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 56 ++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index e623dc5..eb7a8a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -832,10 +832,64 @@ static int add_components(struct device *dev, struct 
component_match **matchptr,
return 0;
 }

+/*
+ * Identify what components need to be added by parsing what remote-endpoints
+ * our MDP output ports are connected to. In the case of LVDS on MDP4, there
+ * is no external component that we need to add since LVDS is within MDP4
+ * itself.
+ */
+static int add_components_mdp(struct device *mdp_dev,
+ struct component_match **matchptr)
+{
+   struct device_node *np = mdp_dev->of_node;
+   struct device_node *ep_node;
+
+   for_each_endpoint_of_node(np, ep_node) {
+   struct device_node *intf;
+   struct of_endpoint ep;
+   int ret;
+
+   ret = of_graph_parse_endpoint(ep_node, );
+   if (ret) {
+   dev_err(mdp_dev, "unable to parse port endpoint\n");
+   of_node_put(ep_node);
+   return ret;
+   }
+
+   /*
+* The LCDC/LVDS port on MDP4 is a speacial case where the
+* remote-endpoint isn't a component that we need to add
+*/
+   if (of_device_is_compatible(np, "qcom,mdp4") &&
+   ep.port == 0) {
+   of_node_put(ep_node);
+   continue;
+   }
+
+   /*
+* It's okay if some of the ports don't have a remote endpoint
+* specified. It just means that the port isn't connected to
+* any external interface.
+*/
+   intf = of_graph_get_remote_port_parent(ep_node);
+   if (!intf) {
+   of_node_put(ep_node);
+   continue;
+   }
+
+   component_match_add(mdp_dev, matchptr, compare_of, intf);
+
+   of_node_put(intf);
+   of_node_put(ep_node);
+   }
+
+   return 0;
+}
+
 static int add_display_components(struct device *dev,
  struct component_match **matchptr)
 {
-   return add_components(>dev, matchptr, "connectors");
+   return add_components_mdp(dev, matchptr);
 }

 static int add_gpu_components(struct device *dev,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 13/22] drm/msm: Create separate funcs for adding display/gpu components

[Archit Taneja]

Simplifies some of the code that we'll add later.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bc2c371..e623dc5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -832,6 +832,18 @@ static int add_components(struct device *dev, struct 
component_match **matchptr,
return 0;
 }

+static int add_display_components(struct device *dev,
+ struct component_match **matchptr)
+{
+   return add_components(>dev, matchptr, "connectors");
+}
+
+static int add_gpu_components(struct device *dev,
+ struct component_match **matchptr)
+{
+   return add_components(>dev, matchptr, "gpus");
+}
+
 static int msm_drm_bind(struct device *dev)
 {
return msm_drm_init(dev, _driver);
@@ -854,9 +866,15 @@ static const struct component_master_ops msm_drm_ops = {
 static int msm_pdev_probe(struct platform_device *pdev)
 {
struct component_match *match = NULL;
+   int ret;
+
+   ret = add_display_components(>dev, );
+   if (ret)
+   return ret;

-   add_components(>dev, , "connectors");
-   add_components(>dev, , "gpus");
+   ret = add_gpu_components(>dev, );
+   if (ret)
+   return ret;

pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
return component_master_add_with_match(>dev, _drm_ops, match);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 12/22] drm/msm/mdp5: Add missing mdp5_enable/disable calls

[Archit Taneja]

Since runtime PM isn't implemented yet, we need to call
mdp5_enable/disable in a few more places. These would later be
replaced by runtime PM get/put calls.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 2 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index 1c3c909..d53e551 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -54,7 +54,9 @@ int mdp5_irq_postinstall(struct msm_kms *kms)
MDP5_IRQ_INTF2_UNDER_RUN |
MDP5_IRQ_INTF3_UNDER_RUN;

+   mdp5_enable(mdp5_kms);
mdp_irq_register(mdp_kms, error_handler);
+   mdp5_disable(mdp5_kms);

return 0;
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 1f62899..d40dd65 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -33,6 +33,7 @@ static int mdp5_hw_init(struct msm_kms *kms)
unsigned long flags;

pm_runtime_get_sync(>dev);
+   mdp5_enable(mdp5_kms);

/* Magic unknown register writes:
 *
@@ -64,6 +65,7 @@ static int mdp5_hw_init(struct msm_kms *kms)

mdp5_ctlm_hw_reset(mdp5_kms->ctlm);

+   mdp5_disable(mdp5_kms);
pm_runtime_put_sync(>dev);

return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 11/22] drm/msm: Call pm_runtime_enable/disable for newly created devices

[Archit Taneja]

With the new device hierarchy for MDP5, we need to enable runtime PM
for both the toplevel MDSS device and the MDP5 device itself. Enable
runtime PM for the new devices.

Since MDP4 and MDP5 now have different places where runtime PM is
enabled, remove the previous pm_runtime_enable/disable calls, and
squash them in the respective kms drivers.

The new device hierarchy (as expressed in the DT bindings) has the GDSC
tied only to the MDSS wrapper device. This GDSC needs to be enabled for
accessing any register in the MDSS sub-blocks. Once every driver is
runtime adapted, the GDSC will be enabled when any sub-block device
calls runtime_get because of the parent-child relationship with MDSS.

Until then, we call pm_runtime_get_sync() once for the MDSS device to
ensure the GDSC is never disabled. This will be removed once all the
drivers are runtime PM adapted.

The error handling paths become a bit tricky when we call these runtime
PM funcs. There doesn't seem to be any helper that checks if runtime PM
is enabled already. Add bool variables in mdp4_kms/mdp5_kms structs to
check if the driver had managed to call pm_runtime_enable before bailing
out.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c  |  8 
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h  |  2 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c  |  6 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h  |  2 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c | 12 
 drivers/gpu/drm/msm/msm_drv.c|  5 +
 6 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 40cb300..09ad65c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -162,6 +162,7 @@ static const char * const iommu_ports[] = {
 static void mdp4_destroy(struct msm_kms *kms)
 {
struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+   struct device *dev = mdp4_kms->dev->dev;
struct msm_mmu *mmu = mdp4_kms->mmu;

if (mmu) {
@@ -173,6 +174,10 @@ static void mdp4_destroy(struct msm_kms *kms)
msm_gem_put_iova(mdp4_kms->blank_cursor_bo, mdp4_kms->id);
if (mdp4_kms->blank_cursor_bo)
drm_gem_object_unreference_unlocked(mdp4_kms->blank_cursor_bo);
+
+   if (mdp4_kms->rpm_enabled)
+   pm_runtime_disable(dev);
+
kfree(mdp4_kms);
 }

@@ -519,6 +524,9 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
clk_set_rate(mdp4_kms->clk, config->max_clk);
clk_set_rate(mdp4_kms->lut_clk, config->max_clk);

+   pm_runtime_enable(dev->dev);
+   mdp4_kms->rpm_enabled = true;
+
/* make sure things are off before attaching iommu (bootloader could
 * have left things on, in which case we'll start getting faults if
 * we don't disable):
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index c5d045d..25fb839 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -47,6 +47,8 @@ struct mdp4_kms {

struct mdp_irq error_handler;

+   bool rpm_enabled;
+
/* empty/blank cursor bo to use when cursor is "disabled" */
struct drm_gem_object *blank_cursor_bo;
uint32_t blank_cursor_iova;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 1559a36..1f62899 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -674,6 +674,9 @@ static void mdp5_destroy(struct platform_device *pdev)
mdp5_smp_destroy(mdp5_kms->smp);
if (mdp5_kms->cfg)
mdp5_cfg_destroy(mdp5_kms->cfg);
+
+   if (mdp5_kms->rpm_enabled)
+   pm_runtime_disable(>dev);
 }

 static int mdp5_init(struct platform_device *pdev, struct drm_device *dev)
@@ -726,6 +729,9 @@ static int mdp5_init(struct platform_device *pdev, struct 
drm_device *dev)
 */
clk_set_rate(mdp5_kms->core_clk, 2);

+   pm_runtime_enable(>dev);
+   mdp5_kms->rpm_enabled = true;
+
read_mdp_hw_revision(mdp5_kms, , );

mdp5_kms->cfg = mdp5_cfg_init(mdp5_kms, major, minor);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index d214d50..0373892 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -59,6 +59,8 @@ struct mdp5_kms {
 */
spinlock_t resource_lock;

+   bool rpm_enabled;
+
struct mdp_irq error_handler;
 };
 #define to_mdp5_kms(x) container_of(x, struct mdp5_kms, base)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
index 871c442..d444a69 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
@@ -152,6 +152,10 @@ void 

[PATCH 10/22] drm/msm/mdp5: Update the register offsets of MDP5 sub-blocks

[Archit Taneja]

The MDP5 sub-block register offsets are relative to the top level
MDSS register address.

Now that we have the start of MDP5 register address space, provide
the offsets relative to that. This involves subtracting the offsets
with 0x1000 or 0x100 depending on the MDP5 version.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 113 +++-
 1 file changed, 54 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 57f73f0..ac9e4cd 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -26,7 +26,6 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
.name = "msm8x74v1",
.mdp = {
.count = 1,
-   .base = { 0x00100 },
.caps = MDP_CAP_SMP |
0,
},
@@ -41,12 +40,12 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
},
.ctl = {
.count = 5,
-   .base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .base = { 0x00500, 0x00600, 0x00700, 0x00800, 0x00900 },
.flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
-   .base = { 0x01200, 0x01600, 0x01a00 },
+   .base = { 0x01100, 0x01500, 0x01900 },
.caps = MDP_PIPE_CAP_HFLIP |
MDP_PIPE_CAP_VFLIP |
MDP_PIPE_CAP_SCALE |
@@ -55,7 +54,7 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
},
.pipe_rgb = {
.count = 3,
-   .base = { 0x01e00, 0x02200, 0x02600 },
+   .base = { 0x01d00, 0x02100, 0x02500 },
.caps = MDP_PIPE_CAP_HFLIP |
MDP_PIPE_CAP_VFLIP |
MDP_PIPE_CAP_SCALE |
@@ -63,26 +62,26 @@ const struct mdp5_cfg_hw msm8x74v1_config = {
},
.pipe_dma = {
.count = 2,
-   .base = { 0x02a00, 0x02e00 },
+   .base = { 0x02900, 0x02d00 },
.caps = MDP_PIPE_CAP_HFLIP |
MDP_PIPE_CAP_VFLIP |
0,
},
.lm = {
.count = 5,
-   .base = { 0x03200, 0x03600, 0x03a00, 0x03e00, 0x04200 },
+   .base = { 0x03100, 0x03500, 0x03900, 0x03d00, 0x04100 },
.nb_stages = 5,
},
.dspp = {
.count = 3,
-   .base = { 0x04600, 0x04a00, 0x04e00 },
+   .base = { 0x04500, 0x04900, 0x04d00 },
},
.pp = {
.count = 3,
-   .base = { 0x21b00, 0x21c00, 0x21d00 },
+   .base = { 0x21a00, 0x21b00, 0x21c00 },
},
.intf = {
-   .base = { 0x21100, 0x21300, 0x21500, 0x21700 },
+   .base = { 0x21000, 0x21200, 0x21400, 0x21600 },
.connect = {
[0] = INTF_eDP,
[1] = INTF_DSI,
@@ -97,7 +96,6 @@ const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
.count = 1,
-   .base = { 0x00100 },
.caps = MDP_CAP_SMP |
0,
},
@@ -112,48 +110,48 @@ const struct mdp5_cfg_hw msm8x74v2_config = {
},
.ctl = {
.count = 5,
-   .base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .base = { 0x00500, 0x00600, 0x00700, 0x00800, 0x00900 },
.flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
-   .base = { 0x01200, 0x01600, 0x01a00 },
+   .base = { 0x01100, 0x01500, 0x01900 },
.caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
MDP_PIPE_CAP_DECIMATION,
},
.pipe_rgb = {
.count = 3,
-   .base = { 0x01e00, 0x02200, 0x02600 },
+   .base = { 0x01d00, 0x02100, 0x02500 },
.caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_DECIMATION,
},
.pipe_dma = {
.count = 2,
-   .base = { 0x02a00, 0x02e00 },
+   .base = { 0x02900, 0x02d00 },
.caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP,
},
.lm = {
.count = 5,
-   .base = { 0x03200, 0x03600, 0x03a00, 0x03e00, 0x04200 },
+   .base = { 0x03100, 0x03500, 0x03900, 0x03d00, 0x04100 },
.nb_stages = 5,
.max_width = 2048,
.max_height = 0x,
},
.dspp = {
.count = 3,
-   .base = { 0x04600, 0x04a00, 0x04e00 },
+   .base = { 0x04500, 0x04900, 

[PATCH 09/22] drm/msm/mdp5: Use updated MDP5 register names

[Archit Taneja]

Since MDSS registers were stuffed within the the MDP5 register
space, we had an __offset_MDP() macro to identify the offset
between the start of MDSS and MDP5 address spaces. This offset
macro expected a MDP index argument, which didn't make much
sense since we don't have multiple MDPs.

The offset is no longer needed now that we have devices for the 2
different register address spaces. Also, remove the "REG_MDP5_MDP_"
prefix to "REG_MDP5_".

Update the generated headers in mdp5.xml.h

We generally update headers as a separate patch, but we need to
do these together to prevent breaking build.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 203 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c |  14 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c |  26 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  10 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c |  18 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |   8 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c |  22 +--
 8 files changed, 143 insertions(+), 160 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index b275ce1..ca6ca30 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,19 +8,11 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1572 bytes, from 2016-02-10 17:07:21)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2849 bytes, from 2015-09-18 12:07:28)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
37194 bytes, from 2015-09-18 12:07:28)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
27887 bytes, from 2015-10-22 16:34:52)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
602 bytes, from 2015-10-22 16:35:02)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2015-05-20 20:03:07)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
41472 bytes, from 2016-01-22 18:18:18)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (  
10416 bytes, from 2015-05-20 20:03:14)
-
-Copyright (C) 2013-2015 by the following authors:
+- /local/mnt/workspace/source_trees/envytools/rnndb/../rnndb/mdp/mdp5.xml   (  
36965 bytes, from 2016-05-10 05:06:30)
+- /local/mnt/workspace/source_trees/envytools/rnndb/freedreno_copyright.xml (  
 1572 bytes, from 2016-05-09 06:32:54)
+- /local/mnt/workspace/source_trees/envytools/rnndb/mdp/mdp_common.xml  (  
 2849 bytes, from 2016-01-07 08:45:55)
+
+Copyright (C) 2013-2016 by the following authors:
 - Rob Clark  (robclark)
 - Ilia Mirkin  (imirkin)

@@ -198,118 +190,109 @@ static inline uint32_t MDSS_HW_VERSION_MAJOR(uint32_t 
val)
 #define MDSS_HW_INTR_STATUS_INTR_HDMI  0x0100
 #define MDSS_HW_INTR_STATUS_INTR_EDP   0x1000

-static inline uint32_t __offset_MDP(uint32_t idx)
-{
-   switch (idx) {
-   case 0: return (mdp5_cfg->mdp.base[0]);
-   default: return INVALID_IDX(idx);
-   }
-}
-static inline uint32_t REG_MDP5_MDP(uint32_t i0) { return 0x + 
__offset_MDP(i0); }
-
-static inline uint32_t REG_MDP5_MDP_HW_VERSION(uint32_t i0) { return 
0x + __offset_MDP(i0); }
-#define MDP5_MDP_HW_VERSION_STEP__MASK 0x
-#define MDP5_MDP_HW_VERSION_STEP__SHIFT0
-static inline uint32_t MDP5_MDP_HW_VERSION_STEP(uint32_t val)
+#define REG_MDP5_HW_VERSION0x
+#define MDP5_HW_VERSION_STEP__MASK 0x
+#define MDP5_HW_VERSION_STEP__SHIFT0
+static inline uint32_t MDP5_HW_VERSION_STEP(uint32_t val)
 {
-   return ((val) << MDP5_MDP_HW_VERSION_STEP__SHIFT) & 
MDP5_MDP_HW_VERSION_STEP__MASK;
+   return ((val) << MDP5_HW_VERSION_STEP__SHIFT) & 
MDP5_HW_VERSION_STEP__MASK;
 }
-#define MDP5_MDP_HW_VERSION_MINOR__MASK
0x0fff
-#define MDP5_MDP_HW_VERSION_MINOR__SHIFT   16
-static inline uint32_t MDP5_MDP_HW_VERSION_MINOR(uint32_t val)
+#define MDP5_HW_VERSION_MINOR__MASK0x0fff
+#define MDP5_HW_VERSION_MINOR__SHIFT 

[PATCH 08/22] drm/msm/mdp5: Remove old kms init/destroy funcs

[Archit Taneja]

With the new kms_init/destroy funcs in place for MDP5, we can get rid of
the old kms funcs. Some members of the mdp5_kms struct also become
redundant, so we remove those too.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 228 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   9 +-
 drivers/gpu/drm/msm/msm_drv.c   |   2 +-
 drivers/gpu/drm/msm/msm_kms.h   |   1 -
 4 files changed, 4 insertions(+), 236 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index dbe7405..dbd3ab2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -127,26 +127,6 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
mmu->funcs->destroy(mmu);
}
-
-   if (mdp5_kms->ctlm)
-   mdp5_ctlm_destroy(mdp5_kms->ctlm);
-   if (mdp5_kms->smp)
-   mdp5_smp_destroy(mdp5_kms->smp);
-   if (mdp5_kms->cfg)
-   mdp5_cfg_destroy(mdp5_kms->cfg);
-
-   kfree(mdp5_kms);
-}
-
-static void mdp5_kms_destroy2(struct msm_kms *kms)
-{
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   struct msm_mmu *mmu = mdp5_kms->mmu;
-
-   if (mmu) {
-   mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
-   mmu->funcs->destroy(mmu);
-   }
 }

 static const struct mdp_kms_funcs kms_funcs = {
@@ -164,7 +144,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.get_format  = mdp_get_format,
.round_pixclk= mdp5_round_pixclk,
.set_split_display = mdp5_set_split_display,
-   .destroy = mdp5_kms_destroy2,
+   .destroy = mdp5_kms_destroy,
},
.set_irqmask = mdp5_set_irqmask,
 };
@@ -428,21 +408,6 @@ fail:
return ret;
 }

-static void read_hw_revision(struct mdp5_kms *mdp5_kms,
-   uint32_t *major, uint32_t *minor)
-{
-   uint32_t version;
-
-   mdp5_enable(mdp5_kms);
-   version = mdp5_read(mdp5_kms, REG_MDSS_HW_VERSION);
-   mdp5_disable(mdp5_kms);
-
-   *major = FIELD(version, MDSS_HW_VERSION_MAJOR);
-   *minor = FIELD(version, MDSS_HW_VERSION_MINOR);
-
-   DBG("MDP5 version v%d.%d", *major, *minor);
-}
-
 static void read_mdp_hw_revision(struct mdp5_kms *mdp5_kms,
 u32 *major, u32 *minor)
 {
@@ -598,195 +563,6 @@ static u32 mdp5_get_vblank_counter(struct drm_device 
*dev, unsigned int pipe)

 struct msm_kms *mdp5_kms_init(struct drm_device *dev)
 {
-   struct platform_device *pdev = dev->platformdev;
-   struct mdp5_cfg *config;
-   struct mdp5_kms *mdp5_kms;
-   struct msm_kms *kms = NULL;
-   struct msm_mmu *mmu;
-   uint32_t major, minor;
-   int irq, i, ret;
-
-   mdp5_kms = kzalloc(sizeof(*mdp5_kms), GFP_KERNEL);
-   if (!mdp5_kms) {
-   dev_err(dev->dev, "failed to allocate kms\n");
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   spin_lock_init(_kms->resource_lock);
-
-   mdp_kms_init(_kms->base, _funcs);
-
-   kms = _kms->base.base;
-
-   mdp5_kms->dev = dev;
-
-   /* mdp5_kms->mmio actually represents the MDSS base address */
-   mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys", "MDP5");
-   if (IS_ERR(mdp5_kms->mmio)) {
-   ret = PTR_ERR(mdp5_kms->mmio);
-   goto fail;
-   }
-
-   mdp5_kms->vbif = msm_ioremap(pdev, "vbif_phys", "VBIF");
-   if (IS_ERR(mdp5_kms->vbif)) {
-   ret = PTR_ERR(mdp5_kms->vbif);
-   goto fail;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   ret = irq;
-   dev_err(dev->dev, "failed to get irq: %d\n", ret);
-   goto fail;
-   }
-
-   kms->irq = irq;
-
-   mdp5_kms->vdd = devm_regulator_get(>dev, "vdd");
-   if (IS_ERR(mdp5_kms->vdd)) {
-   ret = PTR_ERR(mdp5_kms->vdd);
-   goto fail;
-   }
-
-   ret = regulator_enable(mdp5_kms->vdd);
-   if (ret) {
-   dev_err(dev->dev, "failed to enable regulator vdd: %d\n", ret);
-   goto fail;
-   }
-
-   /* mandatory clocks: */
-   ret = get_clk(pdev, _kms->axi_clk, "bus_clk", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->ahb_clk, "iface_clk", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->core_clk, "core_clk", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->vsync_clk, "vsync_clk", true);
-   if (ret)
-   goto fail;
-
-   /* optional clocks: */
-   get_clk(pdev, _kms->lut_clk, "lut_clk", false);
-
-   /* we need to set a default rate before enabling.  Set a safe
-   

[PATCH 07/22] drm/msm/mdp5: Use the new hierarchy and drop old irq management

[Archit Taneja]

Call msm_mdss_init in msm_drv to set up top level registers/irq line.
Start using the new kms_init2/destroy2 funcs to inititalize MDP5 KMS.

With the MDSS interrupt and irqdomain set up, the old MDP5 irq code
can be dropped.

The mdp5_hw_init kms func now uses the platform device tied to MDP5
instead of the one tied to the drm_device/MDSS.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 105 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  17 ++
 drivers/gpu/drm/msm/msm_drv.c   |  15 -
 3 files changed, 18 insertions(+), 119 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index 73bc3e3..c6562d1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -15,7 +15,6 @@
  * this program.  If not, see .
  */

-#include 
 #include 

 #include "msm_drv.h"
@@ -68,8 +67,9 @@ void mdp5_irq_uninstall(struct msm_kms *kms)
mdp5_disable(mdp5_kms);
 }

-static void mdp5_irq_mdp(struct mdp_kms *mdp_kms)
+irqreturn_t mdp5_irq(struct msm_kms *kms)
 {
+   struct mdp_kms *mdp_kms = to_mdp_kms(kms);
struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
@@ -87,29 +87,6 @@ static void mdp5_irq_mdp(struct mdp_kms *mdp_kms)
for (id = 0; id < priv->num_crtcs; id++)
if (status & mdp5_crtc_vblank(priv->crtcs[id]))
drm_handle_vblank(dev, id);
-}
-
-irqreturn_t mdp5_irq(struct msm_kms *kms)
-{
-   struct mdp_kms *mdp_kms = to_mdp_kms(kms);
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
-   uint32_t intr;
-
-   intr = mdp5_read(mdp5_kms, REG_MDSS_HW_INTR_STATUS);
-
-   VERB("intr=%08x", intr);
-
-   if (intr & MDSS_HW_INTR_STATUS_INTR_MDP) {
-   mdp5_irq_mdp(mdp_kms);
-   intr &= ~MDSS_HW_INTR_STATUS_INTR_MDP;
-   }
-
-   while (intr) {
-   irq_hw_number_t hwirq = fls(intr) - 1;
-   generic_handle_irq(irq_find_mapping(
-   mdp5_kms->irqcontroller.domain, hwirq));
-   intr &= ~(1 << hwirq);
-   }

return IRQ_HANDLED;
 }
@@ -135,81 +112,3 @@ void mdp5_disable_vblank(struct msm_kms *kms, struct 
drm_crtc *crtc)
mdp5_crtc_vblank(crtc), false);
mdp5_disable(mdp5_kms);
 }
-
-/*
- * interrupt-controller implementation, so sub-blocks (hdmi/eDP/dsi/etc)
- * can register to get their irq's delivered
- */
-
-#define VALID_IRQS  (MDSS_HW_INTR_STATUS_INTR_DSI0 | \
-   MDSS_HW_INTR_STATUS_INTR_DSI1 | \
-   MDSS_HW_INTR_STATUS_INTR_HDMI | \
-   MDSS_HW_INTR_STATUS_INTR_EDP)
-
-static void mdp5_hw_mask_irq(struct irq_data *irqd)
-{
-   struct mdp5_kms *mdp5_kms = irq_data_get_irq_chip_data(irqd);
-   smp_mb__before_atomic();
-   clear_bit(irqd->hwirq, _kms->irqcontroller.enabled_mask);
-   smp_mb__after_atomic();
-}
-
-static void mdp5_hw_unmask_irq(struct irq_data *irqd)
-{
-   struct mdp5_kms *mdp5_kms = irq_data_get_irq_chip_data(irqd);
-   smp_mb__before_atomic();
-   set_bit(irqd->hwirq, _kms->irqcontroller.enabled_mask);
-   smp_mb__after_atomic();
-}
-
-static struct irq_chip mdp5_hw_irq_chip = {
-   .name   = "mdp5",
-   .irq_mask   = mdp5_hw_mask_irq,
-   .irq_unmask = mdp5_hw_unmask_irq,
-};
-
-static int mdp5_hw_irqdomain_map(struct irq_domain *d,
-   unsigned int irq, irq_hw_number_t hwirq)
-{
-   struct mdp5_kms *mdp5_kms = d->host_data;
-
-   if (!(VALID_IRQS & (1 << hwirq)))
-   return -EPERM;
-
-   irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);
-   irq_set_chip_data(irq, mdp5_kms);
-
-   return 0;
-}
-
-static struct irq_domain_ops mdp5_hw_irqdomain_ops = {
-   .map = mdp5_hw_irqdomain_map,
-   .xlate = irq_domain_xlate_onecell,
-};
-
-
-int mdp5_irq_domain_init(struct mdp5_kms *mdp5_kms)
-{
-   struct device *dev = mdp5_kms->dev->dev;
-   struct irq_domain *d;
-
-   d = irq_domain_add_linear(dev->of_node, 32,
-   _hw_irqdomain_ops, mdp5_kms);
-   if (!d) {
-   dev_err(dev, "mdp5 irq domain add failed\n");
-   return -ENXIO;
-   }
-
-   mdp5_kms->irqcontroller.enabled_mask = 0;
-   mdp5_kms->irqcontroller.domain = d;
-
-   return 0;
-}
-
-void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms)
-{
-   if (mdp5_kms->irqcontroller.domain) {
-   irq_domain_remove(mdp5_kms->irqcontroller.domain);
-   mdp5_kms->irqcontroller.domain = NULL;
-   }
-}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 4bffeaa..dbe7405 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ 

[PATCH 06/22] drm/msm/mdp5: Prepare new kms_init funcs

[Archit Taneja]

With MDP5 as a new device, we need to do less for MDP when initializing
modeset after all the components are bound.

Create mdp5_kms_init2/destroy2 funcs that inits modeset. These will
eventually replace the older kms_init/destroy funcs.

In the new kms_init2, the platform_device used is the one corresponding
to the new MDP5 platform_device. The new change here is that the irq is
now retrieved using irq_of_parse_and_map(), since MDP5 is a child interrupt
of the MDSS interrupt controller.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 115 
 drivers/gpu/drm/msm/msm_kms.h   |   1 +
 2 files changed, 116 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index d57ea9f..4bffeaa 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */

+#include 

 #include "msm_drv.h"
 #include "msm_mmu.h"
@@ -139,6 +140,17 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
kfree(mdp5_kms);
 }

+static void mdp5_kms_destroy2(struct msm_kms *kms)
+{
+   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   struct msm_mmu *mmu = mdp5_kms->mmu;
+
+   if (mmu) {
+   mmu->funcs->detach(mmu, iommu_ports, ARRAY_SIZE(iommu_ports));
+   mmu->funcs->destroy(mmu);
+   }
+}
+
 static const struct mdp_kms_funcs kms_funcs = {
.base = {
.hw_init = mdp5_hw_init,
@@ -782,6 +794,109 @@ fail:
return ERR_PTR(ret);
 }

+struct msm_kms *mdp5_kms_init2(struct drm_device *dev)
+{
+   struct msm_drm_private *priv = dev->dev_private;
+   struct platform_device *pdev;
+   struct mdp5_kms *mdp5_kms;
+   struct mdp5_cfg *config;
+   struct msm_kms *kms;
+   struct msm_mmu *mmu;
+   int irq, i, ret;
+
+   /* priv->kms would have been populated by the MDP5 driver */
+   kms = priv->kms;
+   if (!kms)
+   return NULL;
+
+   mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+
+   mdp_kms_init(_kms->base, _funcs);
+
+   pdev = mdp5_kms->pdev;
+
+   irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+   if (irq < 0) {
+   ret = irq;
+   dev_err(>dev, "failed to get irq: %d\n", ret);
+   goto fail;
+   }
+
+   kms->irq = irq;
+
+   config = mdp5_cfg_get_config(mdp5_kms->cfg);
+
+   /* make sure things are off before attaching iommu (bootloader could
+* have left things on, in which case we'll start getting faults if
+* we don't disable):
+*/
+   mdp5_enable(mdp5_kms);
+   for (i = 0; i < MDP5_INTF_NUM_MAX; i++) {
+   if (mdp5_cfg_intf_is_virtual(config->hw->intf.connect[i]) ||
+   !config->hw->intf.base[i])
+   continue;
+   mdp5_write(mdp5_kms, REG_MDP5_INTF_TIMING_ENGINE_EN(i), 0);
+
+   mdp5_write(mdp5_kms, REG_MDP5_INTF_FRAME_LINE_COUNT_EN(i), 0x3);
+   }
+   mdp5_disable(mdp5_kms);
+   mdelay(16);
+
+   if (config->platform.iommu) {
+   mmu = msm_iommu_new(>dev, config->platform.iommu);
+   if (IS_ERR(mmu)) {
+   ret = PTR_ERR(mmu);
+   dev_err(>dev, "failed to init iommu: %d\n", ret);
+   iommu_domain_free(config->platform.iommu);
+   goto fail;
+   }
+
+   ret = mmu->funcs->attach(mmu, iommu_ports,
+   ARRAY_SIZE(iommu_ports));
+   if (ret) {
+   dev_err(>dev, "failed to attach iommu: %d\n",
+   ret);
+   mmu->funcs->destroy(mmu);
+   goto fail;
+   }
+   } else {
+   dev_info(>dev,
+"no iommu, fallback to phys contig buffers for 
scanout\n");
+   mmu = NULL;
+   }
+   mdp5_kms->mmu = mmu;
+
+   mdp5_kms->id = msm_register_mmu(dev, mmu);
+   if (mdp5_kms->id < 0) {
+   ret = mdp5_kms->id;
+   dev_err(>dev, "failed to register mdp5 iommu: %d\n", ret);
+   goto fail;
+   }
+
+   ret = modeset_init(mdp5_kms);
+   if (ret) {
+   dev_err(>dev, "modeset_init failed: %d\n", ret);
+   goto fail;
+   }
+
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.max_width = config->hw->lm.max_width;
+   dev->mode_config.max_height = config->hw->lm.max_height;
+
+   dev->driver->get_vblank_timestamp = mdp5_get_vblank_timestamp;
+   dev->driver->get_scanout_position = mdp5_get_scanoutpos;
+   dev->driver->get_vblank_counter = mdp5_get_vblank_counter;
+   dev->max_vblank_count = 0x;
+   

[PATCH 05/22] drm/msm/mdp5: Create a separate MDP5 device

[Archit Taneja]

In order to have a tree-like device hierarchy between MDSS and its
sub-blocks (MDP5, DSI, HDMI, eDP etc), we need to create a separate
device/driver for MDP5. Currently, MDP5 and MDSS are squashed
together are are tied to the top level platform_device, which is
also the one used to create drm_device.

The mdp5_kms_init code is split into two parts. The part where device
resources are allocated are associated with the MDP5 driver's probe,
the rest is executed later when we initialize modeset.

With this change, unlike MDP4, the MDP5 platform_device isn't tied to
the top level drm_device anymore. The top level drm_device is now
associated with a platform device that corresponds to MDSS wrapper
hardware.

Create mdp5_init/destroy funcs that will be used by the MDP5 driver
probe/remove. Use the HW_VERSION register in the MDP5 register address
space. Both the MDSS and MDP VERSION registers give out identical
version info.

The older mdp5_kms_init code is left as is for now, this would be removed
later when we have all the pieces to support the new device hierarchy.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 185 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   2 +
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 drivers/gpu/drm/msm/msm_drv.h   |   3 +
 4 files changed, 189 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 2f2761f..d57ea9f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -117,7 +117,7 @@ static int mdp5_set_split_display(struct msm_kms *kms,
return mdp5_encoder_set_split_display(encoder, slave_encoder);
 }

-static void mdp5_destroy(struct msm_kms *kms)
+static void mdp5_kms_destroy(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct msm_mmu *mmu = mdp5_kms->mmu;
@@ -154,7 +154,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.get_format  = mdp_get_format,
.round_pixclk= mdp5_round_pixclk,
.set_split_display = mdp5_set_split_display,
-   .destroy = mdp5_destroy,
+   .destroy = mdp5_kms_destroy,
},
.set_irqmask = mdp5_set_irqmask,
 };
@@ -440,6 +440,21 @@ static void read_hw_revision(struct mdp5_kms *mdp5_kms,
DBG("MDP5 version v%d.%d", *major, *minor);
 }

+static void read_mdp_hw_revision(struct mdp5_kms *mdp5_kms,
+u32 *major, u32 *minor)
+{
+   u32 version;
+
+   mdp5_enable(mdp5_kms);
+   version = mdp5_read(mdp5_kms, REG_MDP5_MDP_HW_VERSION(0));
+   mdp5_disable(mdp5_kms);
+
+   *major = FIELD(version, MDP5_MDP_HW_VERSION_MAJOR);
+   *minor = FIELD(version, MDP5_MDP_HW_VERSION_MINOR);
+
+   DBG("MDP5 version v%d.%d", *major, *minor);
+}
+
 static int get_clk(struct platform_device *pdev, struct clk **clkp,
const char *name, bool mandatory)
 {
@@ -763,6 +778,170 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)

 fail:
if (kms)
-   mdp5_destroy(kms);
+   mdp5_kms_destroy(kms);
return ERR_PTR(ret);
 }
+
+static void mdp5_destroy(struct platform_device *pdev)
+{
+   struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+
+   if (mdp5_kms->ctlm)
+   mdp5_ctlm_destroy(mdp5_kms->ctlm);
+   if (mdp5_kms->smp)
+   mdp5_smp_destroy(mdp5_kms->smp);
+   if (mdp5_kms->cfg)
+   mdp5_cfg_destroy(mdp5_kms->cfg);
+}
+
+static int mdp5_init(struct platform_device *pdev, struct drm_device *dev)
+{
+   struct msm_drm_private *priv = dev->dev_private;
+   struct mdp5_kms *mdp5_kms;
+   struct mdp5_cfg *config;
+   u32 major, minor;
+   int ret;
+
+   mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);
+   if (!mdp5_kms) {
+   ret = -ENOMEM;
+   goto fail;
+   }
+
+   platform_set_drvdata(pdev, mdp5_kms);
+
+   spin_lock_init(_kms->resource_lock);
+
+   mdp5_kms->dev = dev;
+   mdp5_kms->pdev = pdev;
+
+   mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys", "MDP5");
+   if (IS_ERR(mdp5_kms->mmio)) {
+   ret = PTR_ERR(mdp5_kms->mmio);
+   goto fail;
+   }
+
+   /* mandatory clocks: */
+   ret = get_clk(pdev, _kms->axi_clk, "bus_clk", true);
+   if (ret)
+   goto fail;
+   ret = get_clk(pdev, _kms->ahb_clk, "iface_clk", true);
+   if (ret)
+   goto fail;
+   ret = get_clk(pdev, _kms->core_clk, "core_clk", true);
+   if (ret)
+   goto fail;
+   ret = get_clk(pdev, _kms->vsync_clk, "vsync_clk", true);
+   if (ret)
+   goto fail;
+
+   /* optional clocks: */
+   get_clk(pdev, _kms->lut_clk, "lut_clk", false);
+
+   /* we need to set a 

[PATCH 04/22] drm/msm/mdp5: Add MDSS top level driver

[Archit Taneja]

SoCs that contain MDP5 have a top level wrapper called MDSS that manages
clocks, power and irq for the sub-blocks within it.

Currently, the MDSS portions are stuffed into the MDP5 driver. This makes
it hard to represent the DT bindings in the correct way. We create a top
level MDSS helper that handles these parts. This is essentially moving out
some of the mdp5_kms irq code and MDSS register space and keeping it as a
separate entity. We haven't given any clocks to the top level MDSS yet,
but a AHB clock would be added in the future to access registers.

One thing to note is that the resources allocated by this helper are
tied to the top level platform_device (the one that allocates the
drm_device struct too). This device would be the parent to MDSS
sub-blocks like MDP5, DSI, eDP etc.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/Makefile |   1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c | 223 +++
 drivers/gpu/drm/msm/msm_drv.h|   4 +
 drivers/gpu/drm/msm/msm_kms.h|   2 +
 4 files changed, 230 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 60cb026..4727d04 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -35,6 +35,7 @@ msm-y := \
mdp/mdp5/mdp5_crtc.o \
mdp/mdp5/mdp5_encoder.o \
mdp/mdp5/mdp5_irq.o \
+   mdp/mdp5/mdp5_mdss.o \
mdp/mdp5/mdp5_kms.o \
mdp/mdp5/mdp5_plane.o \
mdp/mdp5/mdp5_smp.o \
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
new file mode 100644
index 000..871c442
--- /dev/null
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+
+#include "msm_drv.h"
+#include "mdp5_kms.h"
+
+/*
+ * If needed, this can become more specific: something like struct mdp5_mdss,
+ * which contains a 'struct msm_mdss base' member.
+ */
+struct msm_mdss {
+   struct drm_device *dev;
+
+   void __iomem *mmio, *vbif;
+
+   struct regulator *vdd;
+
+   struct {
+   volatile unsigned long enabled_mask;
+   struct irq_domain *domain;
+   } irqcontroller;
+};
+
+static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)
+{
+   msm_writel(data, mdss->mmio + reg);
+}
+
+static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)
+{
+   return msm_readl(mdss->mmio + reg);
+}
+
+static irqreturn_t mdss_irq(int irq, void *arg)
+{
+   struct msm_mdss *mdss = arg;
+   u32 intr;
+
+   intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);
+
+   VERB("intr=%08x", intr);
+
+   while (intr) {
+   irq_hw_number_t hwirq = fls(intr) - 1;
+
+   generic_handle_irq(irq_find_mapping(
+   mdss->irqcontroller.domain, hwirq));
+   intr &= ~(1 << hwirq);
+   }
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * interrupt-controller implementation, so sub-blocks (MDP/HDMI/eDP/DSI/etc)
+ * can register to get their irq's delivered
+ */
+
+#define VALID_IRQS  (MDSS_HW_INTR_STATUS_INTR_MDP | \
+   MDSS_HW_INTR_STATUS_INTR_DSI0 | \
+   MDSS_HW_INTR_STATUS_INTR_DSI1 | \
+   MDSS_HW_INTR_STATUS_INTR_HDMI | \
+   MDSS_HW_INTR_STATUS_INTR_EDP)
+
+static void mdss_hw_mask_irq(struct irq_data *irqd)
+{
+   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+
+   smp_mb__before_atomic();
+   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   smp_mb__after_atomic();
+}
+
+static void mdss_hw_unmask_irq(struct irq_data *irqd)
+{
+   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+
+   smp_mb__before_atomic();
+   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   smp_mb__after_atomic();
+}
+
+static struct irq_chip mdss_hw_irq_chip = {
+   .name   = "mdss",
+   .irq_mask   = mdss_hw_mask_irq,
+   .irq_unmask = mdss_hw_unmask_irq,
+};
+
+static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
+irq_hw_number_t hwirq)
+{
+   struct msm_mdss *mdss = d->host_data;
+
+   if (!(VALID_IRQS & (1 << hwirq)))
+   return 

[PATCH 03/22] drm/msm: Get irq number within kms driver itself

[Archit Taneja]

The driver gets the irq number using platform_get_irq on the main kms
platform device. This works fine since both MDP4 and MDP5 currently
have a flat device hierarchy. The platform device tied with the
drm_device points to the MDP DT node in both cases.

This won't work when MDP5 supports a tree-like hierarchy. In this
case, the platform device tied to the top level drm_device is the
MDSS DT node, and the irq we need for KMS is the one generated by
MDP5, not MDSS.

Get the irq number from the MDP4/5 kms driver itself. Each driver
can later provide the irq number based on what device hierarchy it
uses.

While we're at it, call drm_irq_install only when we have a valid KMS
driver.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 11 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 11 ++-
 drivers/gpu/drm/msm/msm_drv.c   | 14 --
 drivers/gpu/drm/msm/msm_kms.h   |  3 +++
 4 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d95e6ce..40cb300 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -444,7 +444,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
struct mdp4_kms *mdp4_kms;
struct msm_kms *kms = NULL;
struct msm_mmu *mmu;
-   int ret;
+   int irq, ret;

mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);
if (!mdp4_kms) {
@@ -465,6 +465,15 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
goto fail;
}

+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   ret = irq;
+   dev_err(dev->dev, "failed to get irq: %d\n", ret);
+   goto fail;
+   }
+
+   kms->irq = irq;
+
/* NOTE: driver for this regulator still missing upstream.. use
 * _get_exclusive() and ignore the error if it does not exist
 * (and hope that the bootloader left it on for us)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index baaa643..2f2761f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -586,7 +586,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
struct msm_kms *kms = NULL;
struct msm_mmu *mmu;
uint32_t major, minor;
-   int i, ret;
+   int irq, i, ret;

mdp5_kms = kzalloc(sizeof(*mdp5_kms), GFP_KERNEL);
if (!mdp5_kms) {
@@ -616,6 +616,15 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
goto fail;
}

+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0) {
+   ret = irq;
+   dev_err(dev->dev, "failed to get irq: %d\n", ret);
+   goto fail;
+   }
+
+   kms->irq = irq;
+
mdp5_kms->vdd = devm_regulator_get(>dev, "vdd");
if (IS_ERR(mdp5_kms->vdd)) {
ret = PTR_ERR(mdp5_kms->vdd);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index aada291..e9fb3b5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -419,12 +419,14 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
goto fail;
}

-   pm_runtime_get_sync(dev);
-   ret = drm_irq_install(ddev, platform_get_irq(pdev, 0));
-   pm_runtime_put_sync(dev);
-   if (ret < 0) {
-   dev_err(dev, "failed to install IRQ handler\n");
-   goto fail;
+   if (kms) {
+   pm_runtime_get_sync(dev);
+   ret = drm_irq_install(ddev, kms->irq);
+   pm_runtime_put_sync(dev);
+   if (ret < 0) {
+   dev_err(dev, "failed to install IRQ handler\n");
+   goto fail;
+   }
}

ret = drm_dev_register(ddev, 0);
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 00998f9..0452856 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -60,6 +60,9 @@ struct msm_kms_funcs {

 struct msm_kms {
const struct msm_kms_funcs *funcs;
+
+   /* irq number to be passed on to drm_irq_install */
+   int irq;
 };

 static inline void msm_kms_init(struct msm_kms *kms,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 02/22] drm/msm: Remove unused fields

[Archit Taneja]

These aren't used. Probably left overs when driver was refactored to
support both MDP4 and MDP5.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_kms.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index e3c..00998f9 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -60,11 +60,6 @@ struct msm_kms_funcs {

 struct msm_kms {
const struct msm_kms_funcs *funcs;
-
-   /* irq handling: */
-   bool in_irq;
-   struct list_head irq_list;/* list of mdp4_irq */
-   uint32_t vblank_mask; /* irq bits set for userspace vblank */
 };

 static inline void msm_kms_init(struct msm_kms *kms,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 01/22] drm/msm: Drop the id_table in platform_driver

[Archit Taneja]

This isn't needed as we only support OF.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/msm_drv.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9788989..aada291 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -861,11 +861,6 @@ static int msm_pdev_remove(struct platform_device *pdev)
return 0;
 }

-static const struct platform_device_id msm_id[] = {
-   { "mdp", 0 },
-   { }
-};
-
 static const struct of_device_id dt_match[] = {
{ .compatible = "qcom,mdp4", .data = (void *) 4 },  /* mdp4 */
{ .compatible = "qcom,mdp5", .data = (void *) 5 },  /* mdp5 */
@@ -883,7 +878,6 @@ static struct platform_driver msm_platform_driver = {
.of_match_table = dt_match,
.pm = _pm_ops,
},
-   .id_table   = msm_id,
 };

 static int __init msm_drm_register(void)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 00/22] drm/msm: Enable DT support

[Archit Taneja]

This patchset adds the last bits needed for getting the MSM display
bindings in correct shape, and as an example, adds display support for
MSM8916.

One problem with the MDP5 driver was that device hierarchy didn't match
with the hardware. All MDP5 based display blocks contain a top-level
MDSS wrapper hardware that manages IRQs, power and some clocks for
the sub-blocks (MDP5, DSI, HDMI, eDP etc) within it. The driver stuffs
this functionality within the MDP5 driver itself, which results in
probably not the cleanest design, and forces us to repeat some
resources (like, power domain, some top level clocks) across all the
sub-blocks. This is fixed by creating separate MDP5 and MDSS platform
devices, and making each piece manage its own resources. MDP4 still
continues to have the flat device hierarchy.

The second problem was the non-standard connector and gpu DT properites.
The former was needed to bind all the external components (DSI, HDMI etc)
before we started with intializing modeset. This is fixed by representing
the MDP interface outputs as ports, and linking them to the ports of the
encoders they are connected to. The 'gpu' property is removed in a
hack-ish way. The driver contains a list of all the compatible strings
for gpus, and searches the entire OF firmware for a matching node. Once
we know what's the right way to link the gpu and display nodes together
(if needed at all), we can add the required binding.

The device hierarchy for MDP5 platforms fits well for runtime PM
adaptation too. Although, for it to work correctly, all the encoder
drivers need to adapt to runtime PM too. With that in place, we still
hit issues in some usecases where the entire register context isn't
correctly restored during resume. It finally boils down to the helpers
we use for implementing atomic_commit. This will take some more time
to solve. For now, we just enable runtime PM early and leave it enabled.
This is necessary for MDP5 based SoCs since Qcom GDSCs are tied to power
domains. This will be fixed once we get all paths working properly with
runtime PM. 

This patchset will break bisectability, in the sense that both the
downstream and proposed DT bindings won't work if we apply only a partial
set of patches. With this series applied, only the proposed bindings will
work. Downstream dtsi files from older kernels will have to be adapted
slightly to get it running with these changes.

This series depends on two patchsets posted before:

drm/msm DT prep work:
http://www.spinics.net/lists/dri-devel/msg110197.html

ADV7533 support+DT bindings:
http://www.spinics.net/lists/linux-arm-msm/msg21085.html

Archit Taneja (22):
  drm/msm: Drop the id_table in platform_driver
  drm/msm: Remove unused fields
  drm/msm: Get irq number within kms driver itself
  drm/msm/mdp5: Add MDSS top level driver
  drm/msm/mdp5: Create a separate MDP5 device
  drm/msm/mdp5: Prepare new kms_init funcs
  drm/msm/mdp5: Use the new hierarchy and drop old irq management
  drm/msm/mdp5: Remove old kms init/destroy funcs
  drm/msm/mdp5: Use updated MDP5 register names
  drm/msm/mdp5: Update the register offsets of MDP5 sub-blocks
  drm/msm: Call pm_runtime_enable/disable for newly created devices
  drm/msm/mdp5: Add missing mdp5_enable/disable calls
  drm/msm: Create separate funcs for adding display/gpu components
  drm/msm: Add display components by parsing MDP ports
  drm/msm: Add components for MDP5
  drm/msm: Drop the gpu binding
  drm/msm/mdp5: Update compatible strings for MDSS/MDP5
  dt-bindings: msm/mdp4: Create a separate binding doc for MDP4
  dt-bindings: msm/mdp5: Add MDP5 display bindings
  dt-bindings: msm/mdp: Provide details on MDP interface ports
  arm64: dts: msm8916: Add display support
  arm64: dts: apq8016-sbc: Add HDMI display support

 .../devicetree/bindings/display/msm/mdp.txt|  57 
 .../devicetree/bindings/display/msm/mdp4.txt   | 112 
 .../devicetree/bindings/display/msm/mdp5.txt   | 160 +++
 arch/arm64/boot/dts/qcom/apq8016-sbc-soc-pins.dtsi |  48 
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi  |  82 ++
 arch/arm64/boot/dts/qcom/msm8916.dtsi  | 120 
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c|  19 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h|   2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h| 203 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c| 113 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c|  14 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c|  26 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c|  10 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c| 125 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 320 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h|  15 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.c   | 235 +++
 

[PATCH v2] drm/fsl-dcu: Exchange fail_encoder and fail_connector

[Meng Yi]

Signed-off-by: Meng Yi 
---
Change in V2:
-add prefix "drm/fsl-dcu" to subject
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
index c564ec6..759527e 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c
@@ -51,9 +51,9 @@ int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device 
*fsl_dev)
drm_kms_helper_poll_init(fsl_dev->drm);

return 0;
-fail_encoder:
-   fsl_dev->crtc.funcs->destroy(_dev->crtc);
 fail_connector:
fsl_dev->encoder.funcs->destroy(_dev->encoder);
+fail_encoder:
+   fsl_dev->crtc.funcs->destroy(_dev->crtc);
return ret;
 }
-- 
2.1.0.27.g96db324

[RESEND PATCH v3 1/2] PM / Domains: Allow genpd to power on during the system PM phases

[maruthi srinivas]

On Mon, May 30, 2016 at 3:13 PM, Ulf Hansson  wrote:
> If the PM domain is powered off when the first device starts its system PM
> prepare phase, genpd prevents any further attempts to power on the PM
> domain during the following system PM phases. Not until the system PM
> complete phase is finalized for all devices in the PM domain, genpd again
> allows it to be powered on.
>
> This behaviour needs to be changed, as a subsystem/driver for a device in
> the same PM domain may still need to be able to serve requests in some of
> the system PM phases. Accordingly, it may need to runtime resume its
> device and thus also request the corresponding PM domain to be powered on.
>
> To deal with these scenarios, let's make the device operational in the
> system PM prepare phase by runtime resuming it, no matter if the PM domain
> is powered on or off. Changing this also enables us to remove genpd's
> suspend_power_off flag, as it's being used to track this condition.
> Additionally, we must allow the PM domain to be powered on via runtime PM
> during the system PM phases.
>
> This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
> driver. It registers a genpd to model the ACP as a PM domain, but
> unfortunately it's also abuses genpd's "internal" suspend_power_off flag
> to deal with a corner case at system PM resume.
>
> More precisely, the so called SMU block powers on the ACP at system PM
> resume, unconditionally if it's being used or not. This may lead to that
> genpd's internal status of the power state, may not correctly reflect the
> power state of the HW after a system PM resume.
>
> Because of changing the behaviour of genpd, by runtime resuming devices in
> the prepare phase, the AMD ACP drm driver no longer have to deal with this
> corner case. So let's just drop the related code in this driver.
>
> Cc: David Airlie 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Maruthi Srinivas Bayyavarapu 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Ulf Hansson 
> ---
>
> Changes in v3:
> - Updated changelog.
>
> Changes in v2:
> - Updated changelog.
> - Added a fix in the AMD ACP (Audio CoProcessor) drm driver, which
> registers a genpd. The fix removes the usage of genpd's internal
> suspend_power_off flag as it's not needed after this change. Because 
> of
> this change I am also requesting an ack from the drm driver 
> maintainer.
>
>
> ---
>  drivers/base/power/domain.c | 84 
> -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 23 -
>  include/linux/pm_domain.h   |  1 -
>  3 files changed, 31 insertions(+), 77 deletions(-)
>

For the ACP part of DRM driver :

Acked-by: Maruthi Bayyavarapu 

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv16 05/13] cec/TODO: add TODO file so we know why this is still in staging

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:20 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> Explain why cec.c is still in staging.

Hmm... as this is for staging, even having pointed several things to
be improved, I may end merging this series. Will decide after finishing
the patch review.

> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/staging/media/cec/TODO | 13 +
>  1 file changed, 13 insertions(+)
>  create mode 100644 drivers/staging/media/cec/TODO
> 
> diff --git a/drivers/staging/media/cec/TODO b/drivers/staging/media/cec/TODO
> new file mode 100644
> index 000..c0751ef
> --- /dev/null
> +++ b/drivers/staging/media/cec/TODO
> @@ -0,0 +1,13 @@
> +The reason why cec.c is still in staging is that I would like
> +to have a bit more confidence in the uABI. The kABI is fine,
> +no problem there, but I would like to let the public API mature
> +a bit.
> +
> +Once I'm confident that I didn't miss anything then the cec.c source
> +can move to drivers/media and the linux/cec.h and linux/cec-funcs.h
> +headers can move to uapi/linux and added to uapi/linux/Kbuild to make
> +them public.
> +
> +Hopefully this will happen later in 2016.
> +
> +Hans Verkuil 



Thanks,
Mauro

of_reserved_mem_device_init_by_idx() returns -EINVAL if "memory-region" is missing

[Alexey Brodkin]

Hi Marek,

We used to use of_reserved_mem_device_init() in such a context in GPU drivers:
>8---
/* Get the optional framebuffer memory resource */
ret = of_reserved_mem_device_init(drm->dev);
if (ret && ret != -ENODEV)
return ret;
>8---

The point is we may have a dedicated reserved memory area or may not have 
(depends on a particular .dts).
Our expectation is if reserved memory area is missing then 
of_reserved_mem_device_init()
just returns -ENODEV and it used to work like this.

Now with your commit 59ce4039727e "of: reserved_mem: add support for using 
more than one region for given device"
behavior is different. of_reserved_mem_device_init_by_idx() has this:
>8---
target = of_parse_phandle(np, "memory-region", idx);
if (!target)
return -EINVAL;
>8---

So I'm wondering which part should be fixed:
 1) of_reserved_mem itself or
 2) users of of_reserved_mem_device_init()

Any thoughts?

Regards,
Alexey

[PATCH v3 7/7] drm/tilcdc: Avoid error print by of_graph_get_next_endpoint()

[Jyri Sarha]

Avoid error print by of_graph_get_next_endpoint() if there is no ports
present.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 03acb4f..ad3db4d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -138,12 +138,21 @@ static int dev_match_of(struct device *dev, void *data)
 int tilcdc_get_external_components(struct device *dev,
   struct component_match **match)
 {
+   struct device_node *node;
struct device_node *ep = NULL;
int count = 0;

-   while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
-   struct device_node *node;
+   /* Avoid error print by of_graph_get_next_endpoint() if there
+* is no ports present.
+*/
+   node = of_get_child_by_name(dev->of_node, "ports");
+   if (!node)
+   node = of_get_child_by_name(dev->of_node, "port");
+   if (!node)
+   return 0;
+   of_node_put(node);

+   while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
node = of_graph_get_remote_port_parent(ep);
if (!node && !of_device_is_available(node)) {
of_node_put(node);
-- 
1.9.1

[PATCH v3 6/7] drm/tilcdc: Refer to panel.txt and tfp410.txt bindings in tilcdc.txt

[Jyri Sarha]

The legacy panel.txt and tfp410.txt bindings are still the only supported
way to connect lcd panel and tfp410 DVI encoder to tilcdc.

Signed-off-by: Jyri Sarha 
---
 Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 2136ee8..6efa4c5 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -24,6 +24,10 @@ Optional nodes:
binding follows Documentation/devicetree/bindings/graph.txt and
suppors a single port with a single endpoint.

+ - See also Documentation/devicetree/bindings/display/tilcdc/panel.txt and
+   Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
+   tfp410 DVI encoder or lcd panel to lcdc
+
 Example:

fb: fb at 4830e000 {
-- 
1.9.1

[PATCH v3 5/7] drm/tilcdc: Call drm_crtc_vblank_on() and *_off() in start() and stop()

[Jyri Sarha]

Add drm_crtc_vblank_on() and *_off() calls to start() and stop()
functions, to make sure any vblank waits etc. gets properly cleaned
up.

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

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 48f890d..b1ba719 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -109,6 +109,8 @@ static void start(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
tilcdc_set(dev, LCDC_RASTER_CTRL_REG, 
LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+   drm_crtc_vblank_on(crtc);
 }

 static void stop(struct drm_crtc *crtc)
@@ -132,6 +134,8 @@ static void stop(struct drm_crtc *crtc)
dev_err(dev->dev, "%s: timeout waiting for framedone\n",
__func__);
}
+
+   drm_crtc_vblank_off(crtc);
 }

 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
-- 
1.9.1

[PATCH v3 4/7] drm/tilcdc: Increase time out for waiting frame done interrupt

[Jyri Sarha]

Increase time out for waiting frame done interrupt. 50ms is long
enough for the usual display modes (50 Hz or higher refresh rate), but
it may be a bit tight for some unusual mode.

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

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 8e9f168..48f890d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -127,7 +127,7 @@ static void stop(struct drm_crtc *crtc)
if (priv->rev == 2) {
int ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
 tilcdc_crtc->frame_done,
-msecs_to_jiffies(50));
+msecs_to_jiffies(500));
if (ret == 0)
dev_err(dev->dev, "%s: timeout waiting for framedone\n",
__func__);
-- 
1.9.1

[PATCH v3 3/7] drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()

[Jyri Sarha]

Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
into stop() function. This is just a cleanup and enables independent
use of stop() function.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 7c42475..8e9f168 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -113,9 +113,25 @@ static void start(struct drm_crtc *crtc)

 static void stop(struct drm_crtc *crtc)
 {
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
+   struct tilcdc_drm_private *priv = dev->dev_private;

+   tilcdc_crtc->frame_done = false;
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
+
+   /*
+* if necessary wait for framedone irq which will still come
+* before putting things to sleep..
+*/
+   if (priv->rev == 2) {
+   int ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
+tilcdc_crtc->frame_done,
+msecs_to_jiffies(50));
+   if (ret == 0)
+   dev_err(dev->dev, "%s: timeout waiting for framedone\n",
+   __func__);
+   }
 }

 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
@@ -212,22 +228,7 @@ void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode)
pm_runtime_get_sync(dev->dev);
start(crtc);
} else {
-   tilcdc_crtc->frame_done = false;
stop(crtc);
-
-   /*
-* if necessary wait for framedone irq which will still come
-* before putting things to sleep..
-*/
-   if (priv->rev == 2) {
-   int ret = wait_event_timeout(
-   tilcdc_crtc->frame_done_wq,
-   tilcdc_crtc->frame_done,
-   msecs_to_jiffies(50));
-   if (ret == 0)
-   dev_err(dev->dev, "timeout waiting for 
framedone\n");
-   }
-
pm_runtime_put_sync(dev->dev);

if (tilcdc_crtc->next_fb) {
-- 
1.9.1

[PATCH v3 2/7] drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ function

[Jyri Sarha]

Reorder the IRQ function so that the write to LCDC_END_OF_INT_IND_REG
is done last. The write to LCDC_END_OF_INT_IND_REG indicates to LCDC
that the interrupt service routine has completed (see section
13.3.6.1.6 in AM335x TRM). This is needed if LCDC's ipgvmodirq module
is configured for pulse interrupts.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 4d8f9a5..7c42475 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -725,12 +725,17 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = true;
}

-   if (priv->rev == 2) {
-   if (stat & LCDC_FRAME_DONE) {
-   tilcdc_crtc->frame_done = true;
-   wake_up(_crtc->frame_done_wq);
-   }
-   tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
+   if (stat & LCDC_FIFO_UNDERFLOW)
+   dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
+   __func__, stat);
+
+   if (priv->rev == 1)
+   return IRQ_HANDLED;
+   /* The rest is for revision 2 only */
+
+   if (stat & LCDC_FRAME_DONE) {
+   tilcdc_crtc->frame_done = true;
+   wake_up(_crtc->frame_done_wq);
}

if (stat & LCDC_SYNC_LOST) {
@@ -746,9 +751,10 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
}
}

-   if (stat & LCDC_FIFO_UNDERFLOW)
-   dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
-   __func__, stat);
+   /* Indicate to LCDC that the interrupt service routine has
+* completed, see 13.3.6.1.6 in AM335x TRM.
+*/
+   tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);

return IRQ_HANDLED;
 }
-- 
1.9.1

[PATCH v3 1/7] drm/tilcdc: Restore old dpms state in pm_resume()

[Jyri Sarha]

Restore old dpms state in pm_resume(). The dpms is turned off in
pm_suspend() and it should be restored to its original state in
pm_resume(). Without this patch the display is left blanked after a
suspend/resume cycle.

Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
engine when suspend invoked")

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 7 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 3 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  | 2 ++
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 79027b1..4d8f9a5 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -246,6 +246,13 @@ void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode)
}
 }

+int tilcdc_crtc_current_dpms_state(struct drm_crtc *crtc)
+{
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   return tilcdc_crtc->dpms;
+}
+
 static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 308e197..148b1ed 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -598,6 +598,7 @@ static int tilcdc_pm_suspend(struct device *dev)
}

/* Disable the LCDC controller, to avoid locking up the PRCM */
+   priv->saved_dpms_state = tilcdc_crtc_current_dpms_state(priv->crtc);
tilcdc_crtc_dpms(priv->crtc, DRM_MODE_DPMS_OFF);

/* Save register state: */
@@ -628,6 +629,8 @@ static int tilcdc_pm_resume(struct device *dev)
 priv->saved_register[n++]);
}

+   tilcdc_crtc_dpms(priv->crtc, priv->saved_dpms_state);
+
drm_kms_helper_poll_enable(ddev);

return 0;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index c1de18b..3b52ce8 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -67,6 +67,7 @@ struct tilcdc_drm_private {

/* register contents saved across suspend/resume: */
u32 *saved_register;
+   int saved_dpms_state;
bool ctx_valid;

 #ifdef CONFIG_CPU_FREQ
@@ -172,5 +173,6 @@ void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc 
*crtc,
 int tilcdc_crtc_mode_valid(struct drm_crtc *crtc, struct drm_display_mode 
*mode);
 int tilcdc_crtc_max_width(struct drm_crtc *crtc);
 void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
+int tilcdc_crtc_current_dpms_state(struct drm_crtc *crtc);

 #endif /* __TILCDC_DRV_H__ */
-- 
1.9.1

[PATCH v3 0/7] drm/tilcdc Fixes and cleanups

[Jyri Sarha]

Some fixes and cleanups that should get merged to tilcdc even if my
atomic changes are still a work in progress.

Changes since v2:
- "drm/tilcdc: Restore old dpms state in pm_resume()"
  - Improve description
- "drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ
  - Handle LCDC_FIFO_UNDERFLOW also for v1 silicon
- "drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()"
  - Improve description
- Add "drm/tilcdc: Increase time out for waiting frame done interrupt"

Changes since first version:
- "drm/tilcdc: Restore old dpms state in pm_resume()"
  - Fix typos from description and subject
- Add "drm/tilcdc: Call drm_crtc_vblank_on() and *_off() in start() and
stop()"

Jyri Sarha (7):
  drm/tilcdc: Restore old dpms state in pm_resume()
  drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ
function
  drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()
  drm/tilcdc: Increase time out for waiting frame done interrupt
  drm/tilcdc: Call drm_crtc_vblank_on() and *_off() in start() and
stop()
  drm/tilcdc: Refer to panel.txt and tfp410.txt bindings in tilcdc.txt
  drm/tilcdc: Avoid error print by of_graph_get_next_endpoint()

 .../devicetree/bindings/display/tilcdc/tilcdc.txt  |  4 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 66 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  3 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 13 -
 5 files changed, 62 insertions(+), 26 deletions(-)

-- 
1.9.1

[GIT PULL] drm/mediatek: MT8173 HDMI support

[Philipp Zabel]

Am Donnerstag, den 16.06.2016, 06:19 +1000 schrieb Dave Airlie:
> On 13 June 2016 at 19:44, Philipp Zabel  wrote:
> > Hi Dave,
> >
> > please consider merging this tag, which contains the v16 MT8173 HDMI
> > patches I sent on 2016-05-26, rebased onto v4.7-rc2. There have been no
> > further comments.
> 
> arm32 build
>  DTC drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dtb
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c:
> In function ‘mtk_hdmi_ddc_probe’:
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c:322:111:
> warning: format ‘%llx’ expects argument of type ‘long long unsigned
> int’, but argument 4 has type ‘resource_size_t {aka unsigned int}’
> [-Wformat=]
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c:322:111:
> warning: format ‘%llx’ expects argument of type ‘long long unsigned
> int’, but argument 5 has type ‘resource_size_t {aka unsigned int}’
> [-Wformat=]
> 
> Please fix that and resend.
> Dave.

I'll fix it up as follows and resend:

--8<--
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
index c24bbc4..33c9e1b 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c
@@ -319,8 +319,8 @@ static int mtk_hdmi_ddc_probe(struct platform_device *pdev)

dev_dbg(dev, "ddc->adap: %p\n", >adap);
dev_dbg(dev, "ddc->clk: %p\n", ddc->clk);
-   dev_dbg(dev, "physical adr: 0x%llx, end: 0x%llx\n", mem->start,
-   mem->end);
+   dev_dbg(dev, "physical adr: %pa, end: %pa\n", >start,
+   >end);

return 0;

-->8--

regards
Philipp

[Bug 88458] The monitor turns off when playing starcraft 2 in wine

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

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

--- Comment #9 from Jaakko Niemi  ---
Good news!

I got apitrace working, "apitrace trace wine .wine... Battle.net.exe", which is
the application from which you start the games. I got 26G file after 15 minutes
of playing one starcraft mission.

Also looks like now the crashes have turned into VM faults:

[456447.423707] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
tried 5 times
[456447.423717] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery
failed
[457965.078259] radeon :01:00.0: GPU fault detected: 146 0x06c3d014
[457965.078262] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0xA036
[457965.078263] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x030D0014
[457965.078265] VM fault (0x04, vmid 1) at page 41014, write from CB (208)
[458184.091683] radeon :01:00.0: GPU fault detected: 146 0x02e2500c
[458184.091686] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x9A97
[458184.091688] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0205000C
[458184.091689] VM fault (0x0c, vmid 1) at page 39575, read from CB (80)
[458201.097207] radeon :01:00.0: GPU fault detected: 146 0x0023a014
[458201.097209] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x9E81
[458201.097210] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x030A0014
[458201.097211] VM fault (0x04, vmid 1) at page 40577, write from CB (160)

This happened after upgrading from kernel 4.6.0 (Mesa from June 1st), to kernel
4.7.0-rc2, drm-next, Mesa from June 11th.

Previously I got hang within 10 minutess, now spent bit over an hour with just
abovementioned log entries, no visible delays on screen. I'll continue testing.

Would apitrace output still be interested on resolving this issue, or some more
information?

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

[PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job

[zhoucm1]

On 2016年06月15日 19:44, Christian König wrote:
> From: Christian König 
>
> When we pipeline evictions the page directory could already be
> moving somewhere else when grab_id is called.
Isn't PD bo protected by job fence?
I think before job fence is signalled, the PD bo is safe, there 
shouldn't be a chance to evict PD bo.

Regards,
David Zhou
>
> Signed-off-by: Christian König 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index a3d7d13..850c4dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -661,6 +661,8 @@ static int amdgpu_cs_ib_vm_chunk(struct amdgpu_device 
> *adev,
>   }
>   }
>   
> + p->job->vm_pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
> +
>   r = amdgpu_bo_vm_update_pte(p, vm);
>   if (!r)
>   amdgpu_cs_sync_rings(p);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index d3e0576..82efb40 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -177,7 +177,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
> amdgpu_ring *ring,
> struct amdgpu_sync *sync, struct fence *fence,
> unsigned *vm_id, uint64_t *vm_pd_addr)
>   {
> - uint64_t pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>   struct amdgpu_device *adev = ring->adev;
>   struct fence *updates = sync->last_vm_update;
>   struct amdgpu_vm_id *id, *idle;
> @@ -250,7 +249,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
> amdgpu_ring *ring,
>   if (atomic64_read(>owner) != vm->client_id)
>   continue;
>   
> - if (pd_addr != id->pd_gpu_addr)
> + if (*vm_pd_addr != id->pd_gpu_addr)
>   continue;
>   
>   if (!same_ring &&
> @@ -298,14 +297,13 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
> amdgpu_ring *ring,
>   fence_put(id->flushed_updates);
>   id->flushed_updates = fence_get(updates);
>   
> - id->pd_gpu_addr = pd_addr;
> + id->pd_gpu_addr = *vm_pd_addr;
>   
>   list_move_tail(>list, >vm_manager.ids_lru);
>   atomic64_set(>owner, vm->client_id);
>   vm->ids[ring->idx] = id;
>   
>   *vm_id = id - adev->vm_manager.ids;
> - *vm_pd_addr = pd_addr;
>   trace_amdgpu_vm_grab_id(vm, ring->idx, *vm_id, *vm_pd_addr);
>   
>   error:

[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled

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

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

--- Comment #15 from Alex Deucher  ---
(In reply to charlie from comment #13)
> I'm now using "drm-next-4.8-wip" (from
> https://cgit.freedesktop.org/~agd5f/linux/).  I still require
> "fiji_disable_pcie_dpm.diff" to overcome the bug.  I can't remember if
> "disable_gen3.diff" no longer patches cleanly or does not work once the
> kernel is compiled.  In any case, "disable_gen3.diff" is no longer effective.
>

On newer kernels you can configure the supported pcie gen modes via module
option.  E.g., append:
amdgpu.pcie_gen_cap=0x00030003
to the kernel command line in grub to limit the bus and the card to pcie gen2.

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

[Bug 91294] [R7 370] DPM and power profile change crash the system

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

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

--- Comment #10 from Paul Frederiks  ---
I'm happy to report that I did not need to patch the kernel after upgrading to
kernel 4.5.0 from debian unstable.

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

[Bug 92974] Fiji Nano long boot up and long X startup with amdgpu-powerplay enabled

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

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

--- Comment #14 from Alex Deucher  ---
(In reply to charlie from comment #13)
> I'm now using "drm-next-4.8-wip" (from
> https://cgit.freedesktop.org/~agd5f/linux/).  I still require
> "fiji_disable_pcie_dpm.diff" to overcome the bug.  I can't remember if
> "disable_gen3.diff" no longer patches cleanly or does not work once the
> kernel is compiled.  In any case, "disable_gen3.diff" is no longer effective.
> 
> Is this a bios issue?  If so, then I can upgrade to the latest bios for my
> motherboard to see if the bug persists without patching the kernel.

It could be.  Does a new bios help?  We've seen similar issues with certain
boards internally.  What CPU/motherboard is this?  If your board has options
for configuring the default pcie gen or generic pcie performance options does
changing any of them help?

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

[PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 02:22:09PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 13:47), Minchan Kim wrote:
> [..]
> > > this is what I'm getting with the [zsmalloc: keep first object offset in 
> > > struct page]
> > > applied:  "count:0 mapcount:-127". which may be not related to zsmalloc 
> > > at this point.
> > > 
> > > kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> > > kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  
> > > (null) index:0x1
> > 
> > Hm, it seems double free.
> > 
> > It doen't happen if you disable zram? IOW, it seems to be related
> > zsmalloc migration?
> 
> need to test more, can't confidently answer now.
> 
> > How easy can you reprodcue it? Could you bisect it?
> 
> it takes some (um.. random) time to trigger the bug.
> I'll try to come up with more details.

Could you revert [1] and retest?

[1] mm/compaction: split freepages without holding the zone lock

> 
>   -ss
> 
> > > kernel: flags: 0x8000()
> > > kernel: page dumped because: nonzero mapcount
> > > kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> > > crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 
> > > mii snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm 
> > > snd_timer snd soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod 
> > > hid_generic usb
> > > kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > > 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> > > kernel:   8801124c73f8 814d69b0 
> > > ea0004076e00
> > > kernel:  81e658a0 8801124c7420 811e9b63 
> > > 
> > > kernel:  ea0004076e00 81e658a0 8801124c7440 
> > > 811e9ca9
> > > kernel: Call Trace:
> > > kernel:  [] dump_stack+0x68/0x92
> > > kernel:  [] bad_page+0x158/0x1a2
> > > kernel:  [] free_pages_check_bad+0xfc/0x101
> > > kernel:  [] free_hot_cold_page+0x135/0x5de
> > > kernel:  [] __free_pages+0x67/0x72
> > > kernel:  [] release_freepages+0x13a/0x191
> > > kernel:  [] compact_zone+0x845/0x1155
> > > kernel:  [] ? compaction_suitable+0x76/0x76
> > > kernel:  [] compact_zone_order+0xe0/0x167
> > > kernel:  [] ? compact_zone+0x1155/0x1155
> > > kernel:  [] try_to_compact_pages+0x2f1/0x648
> > > kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> > > kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> > > kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> > > kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> > > kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> > > kernel:  [] ? drain_all_pages+0x1d6/0x205
> > > kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> > > kernel:  [] ? debug_show_all_locks+0x226/0x226
> > > kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> > > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > > kernel:  [] ? lock_acquire+0xec/0x147
> > > kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> > > kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> > > kernel:  [] ? finish_wait+0x1a4/0x1b0
> > > kernel:  [] khugepaged+0x1d4/0x484f
> > > kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> > > kernel:  [] ? finish_task_switch+0x3de/0x484
> > > kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> > > kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> > > kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> > > kernel:  [] ? __schedule+0xa4d/0xd16
> > > kernel:  [] kthread+0x252/0x261 > > > kernel:  
> > > [] ? hugepage_vma_revalidate+0xef/0xef > > > kernel:  
> > > [] ? kthread_create_on_node+0x377/0x377 > > > kernel:  
> > > [] ret_from_fork+0x1f/0x40 > > > kernel:  
> > > [] ? kthread_create_on_node+0x377/0x377 > > > -- Reboot 
> > > --

[PATCH] drm/radeon: fix asic initialization for virtualized environments

[Rodriguez, Andres]

> -Original Message-
> From: Alex Deucher [mailto:alexdeucher at gmail.com]
> Sent: June-15-16 1:00 PM
> To: Alex Williamson
> Cc: Maling list - DRI developers; Deucher, Alexander; Rodriguez, Andres; for
> 3.8
> Subject: Re: [PATCH] drm/radeon: fix asic initialization for virtualized
> environments
> 
> On Wed, Jun 15, 2016 at 12:45 PM, Alex Williamson
>  wrote:
> > On Wed, 15 Jun 2016 02:23:37 -0400
> > Alex Deucher  wrote:
> >
> >> On Mon, Jun 13, 2016 at 4:10 PM, Alex Williamson
> >>  wrote:
> >> > On Mon, 13 Jun 2016 15:45:20 -0400
> >> > Alex Deucher  wrote:
> >> >
> >> >> When executing in a PCI passthrough based virtuzliation
> >> >> environment, the hypervisor will usually attempt to send a PCIe
> >> >> bus reset signal to the ASIC when the VM reboots. In this
> >> >> scenario, the card is not correctly initialized, but we still
> >> >> consider it to be posted. Therefore, in a passthrough based
> >> >> environemnt we should always post the card to guarantee it is in a
> good state for driver initialization.
> >> >>
> >> >> Ported from amdgpu commit:
> >> >> amdgpu: fix asic initialization for virtualized environments
> >> >>
> >> >> Cc: Andres Rodriguez 
> >> >> Cc: Alex Williamson 
> >> >> Signed-off-by: Alex Deucher 
> >> >> Cc: stable at vger.kernel.org
> >> >> ---
> >> >>  drivers/gpu/drm/radeon/radeon_device.c | 21
> +
> >> >>  1 file changed, 21 insertions(+)
> >> >
> >> > Thanks, I expect it's an improvement, though it's always a bit
> >> > disappointing when a driver starts modifying its behavior based on
> >> > what might be a transient feature of the platform, in this case a
> >> > hypervisor platform.  For instance, why does our bus reset and
> >> > video ROM execution result in a different state than a physical
> >> > BIOS doing the same?  Can't this condition occur regardless of a
> >> > hypervisor,
> >>
> >> Just doing a pci reset is not enough on newer cards.  The hw handling
> >> pci resets changed in CI and more of the logic moved to the driver.
> >
> > Gag, please relay my disapproval to your hardware folks.
> >
> >> That does a limited reset, but not the registers that the driver
> >> checks to determine whether or not the asic has been posted so the
> >> driver skips posting and leaves the hw in a bad reset state.
> >>
> >> > perhaps a rare hot-add of a GPU, a bare metal kexec reboot, or
> >> > perhaps simply a system BIOS optimized to post a limited set of devices.
> >>
> >> We can tell if a card has never been posted and properly post it.
> >> Where it's tricky is when a card has been posted and has subsequently
> >> been pci reset on CI and newer hw.  I'm not sure of a good way to
> >> detect this particular scenario.  Generally this is mainly done for
> >> qemu/kvm.
> >
> > How do you tell if a card has never been posted?  Is it something we
> > could easily toggle after a bus reset?
> 
> We check CONFIG_MEMSIZE which is a scratch register set by the asic_init
> command table to tell the driver how much vram is on the board.
> 

Yeah, detecting a specific virtualization environment is something that I don't
really like. Specially since there isn't a nice generic way to do this for all
environments (i.e. in this patch I used x86 specific functionality). If there 
is a 
generic approach that works on multiple host CPU architectures do let me know.

Another approach I considered was adding an option, amdgpu.always_post
that would shift the responsibility onto the user. But I don't think it's 
really fair
to have that expectation, and at some point you start falling into config hell.

As Alex mentioned, we don't really have a good mechanism for detecting
when we need to post due to how the HW handles PCIe bus reset. Hopefully
we can get this fixed for future ASICs.

> >
> >> > Detection based on some state of the device rather than an
> >> > expectation based on what the device is running on seems
> >> > preferable.  I suspect Andres' patch for amdgpu only affects newer
> >> > devices, which pretty much all suffer reset issues, at least under
> >> > QEMU/VFIO, but I wonder how this patch affects existing working
> devices, like 6, 7, and some 8-series.
> >>
> >> Posting the asic at init time should be safe on all asics.
> >>
> >> > Anyway, if this is the solution to the poor behavior we've seen
> >> > with assigned AMD cards, maybe someone could request the same for
> >> > the closed drivers, including Windows.  Thanks,
> >>
> >> The closed drivers already do this.
> >
> > Hmm, that's not terribly encouraging then since the majority of users
> > are running Windows guests for the purpose of creating a gaming VM and
> > still experiencing reset issues with the closed drivers there.
> > Thanks,
> 
> I'll have to check with the windows team to see how much validation they do
> with the windows driver as a qemu/kvm guest.  It could be that they don't
> properly detect that as a virtual case.
> 
> Alex

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > I guess we'll need the bisect on this one to make progress.
> 
> Sigh, I was afraid that might be the next step.

OK, I have a curious data point.  I assumed the problem would be
somewhere in the drm update, so I started bisecting that at the top. 
 However, the top most commit:

commit 1d6da87a3241deb13d073c4125d19ed0e5a0c62c
Merge: 1f40c49 a39ed68
Author: Linus Torvalds 
Date:   Mon May 23 11:48:48 2016 -0700

Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

Isn't actually bad.  There's no flicker here, so whatever caused the
problem came from some update after this.

James

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

[Rainer Hochecker]

Daniel,

Peter posted me some snippets about your discussion around vblank that
confused me. Our use case is as follows:
We synchronise our video player clock to the pace of the display. Assume we
play some 23.976 content and the actual refresh rate is 24hz. We increment
the clock every vblank, that makes the clock run faster. Audio is resampled
to the faster running clock.
For this we just need an event fired for vblank.

Another requirement not directly related to 1)
We would like to know when a frame in actually presented on screen. Now
this is only guessing.

Rainer

On Wed, Jun 15, 2016 at 10:57 AM, Daniel Vetter 
wrote:

> On Wed, Jun 15, 2016 at 9:29 AM, Michel Dänzer  wrote:
> > On 14.06.2016 18:35, Daniel Vetter wrote:
> >> On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer 
> wrote:
> >>> On 14.06.2016 18:03, Daniel Vetter wrote:
> >>>> Somehow this escaped us, this is a KMS ioctl which should only be used
> >>>> by the master (which is the thing that's also in control of kms
> >>>> resources). Everything else is bound to result in fail.
> >>>>
> >>>> Clients shouldn't have a trouble coping with this, since a pile of
> >>>> drivers don't support vblank waits (or just randomly fall over when
> >>>> using them). Note that the big motivation for abusing this like mad
> >>>> seems to be that EGL doesn't have OML_sync, but somehow it didn't
> >>>> cross anyone's mind that adding OML_sync to EGL would be useful.
> >>>
> >>> That may be one motivation, but it's certainly not the only one.
> >>> DRM_IOCTL_WAIT_VBLANK is used by apps which don't use EGL or any
> similar
> >>> API at all.
> >>
> >> Hm, what else?
> >
> > Off the top of my head, I know specifically about compton and xfwm4.
> > There's certainly more.
>
> But do they anything more fancy than what could be achieved with
> OML_sync too? Or is the issue that they don't want to use EGL/GLX? In
> that case I think it's reasonable to ask them to use bare-metal
> Present, since that's not any less portable than using the vblank
> ioctl.
>
> > Note that as I mentioned before in the other thread, I absolutely agree
> > that DRM_IOCTL_WAIT_VBLANK isn't supposed to be used directly. But the
> > fact of the matter is that it is being used like that (possibly has been
> > since before the DRM master concept even existed), and presumably it
> > actually works with simple setups (which might be the majority). So
> > there might be some backlash if it suddenly stops working.
>
> Fully agreed. Hence just RFC, and yes we need to get the EGL extension
> in place first, and at least kick most of the popular apps to have
> their code ready, and wait a bit, and wait some more, before we can
> nuke the ioctl from the kernel for non-master. It'll probably take 5
> years if we're fast :( I do think that we should be ok with breaking
> the last few hold-outs, but we definitely need to have an alternate
> solution for EGL ready. Hence why I want to know whether there's
> anyone who's using this outside of EGL.
>
> Really this was just drive-by that I spotted while looking around at
> stuff for our other discussion around vblanks.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/85b087df/attachment.html>

[PATCH v6v3 02/12] mm: migrate: support non-lru movable page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 09:12:07AM +0530, Anshuman Khandual wrote:
> On 06/16/2016 05:56 AM, Minchan Kim wrote:
> > On Wed, Jun 15, 2016 at 12:15:04PM +0530, Anshuman Khandual wrote:
> >> On 06/15/2016 08:02 AM, Minchan Kim wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jun 13, 2016 at 03:08:19PM +0530, Anshuman Khandual wrote:
> > On 05/31/2016 05:31 AM, Minchan Kim wrote:
> >>> @@ -791,6 +921,7 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   int rc = -EAGAIN;
> >>>   int page_was_mapped = 0;
> >>>   struct anon_vma *anon_vma = NULL;
> >>> + bool is_lru = !__PageMovable(page);
> >>>  
> >>>   if (!trylock_page(page)) {
> >>>   if (!force || mode == MIGRATE_ASYNC)
> >>> @@ -871,6 +1002,11 @@ static int __unmap_and_move(struct page *page, 
> >>> struct page *newpage,
> >>>   goto out_unlock_both;
> >>>   }
> >>>  
> >>> + if (unlikely(!is_lru)) {
> >>> + rc = move_to_new_page(newpage, page, mode);
> >>> + goto out_unlock_both;
> >>> + }
> >>> +
> >
> > Hello Minchan,
> >
> > I might be missing something here but does this implementation support 
> > the
> > scenario where these non LRU pages owned by the driver mapped as PTE 
> > into
> > process page table ? Because the "goto out_unlock_both" statement above
> > skips all the PTE unmap, putting a migration PTE and removing the 
> > migration
> > PTE steps.
> >>> You're right. Unfortunately, it doesn't support right now but surely,
> >>> it's my TODO after landing this work.
> >>>
> >>> Could you share your usecase?
> >>
> >> Sure.
> > 
> > Thanks a lot!
> > 
> >>
> >> My driver has privately managed non LRU pages which gets mapped into user 
> >> space
> >> process page table through f_ops->mmap() and vmops->fault() which then 
> >> updates
> >> the file RMAP (page->mapping->i_mmap) through page_add_file_rmap(page). 
> >> One thing
> > 
> > Hmm, page_add_file_rmap is not exported function. How does your driver can 
> > use it?
> 
> Its not using the function directly, I just re-iterated the sequence of 
> functions
> above. (do_set_pte -> page_add_file_rmap) gets called after we grab the page 
> from
> driver through (__do_fault->vma->vm_ops->fault()).
> 
> > Do you use vm_insert_pfn?
> > What type your vma is? VM_PFNMMAP or VM_MIXEDMAP?
> 
> I dont use vm_insert_pfn(). Here is the sequence of events how the user space
> VMA gets the non LRU pages from the driver.
> 
> - Driver registers a character device with 'struct file_operations' binding
> - Then the 'fops->mmap()' just binds the incoming 'struct vma' with a 'struct
>   vm_operations_struct' which provides the 'vmops->fault()' routine which
>   basically traps all page faults on the VMA and provides one page at a time
>   through a driver specific allocation routine which hands over non LRU pages
> 
> The VMA is not anything special as such. Its what we get when we try to do a
> simple mmap() on a file descriptor pointing to a character device. I can
> figure out all the VM_* flags it holds after creation.
> 
> > 
> > I want to make dummy driver to simulate your case.
> 
> Sure. I hope the above mentioned steps will help you but in case you need more
> information, please do let me know.

I got understood now. :)
I will test it with dummy driver and will Cc'ed when I send a patch.

Thanks.

[PATCH] drm: rockchip: select DRM_GEM_CMA_HELPER

[Daniel Vetter]

On Thu, Jun 16, 2016 at 02:27:57PM +0200, Arnd Bergmann wrote:
> The rockchip drm driver started using drm_gem_cma_vm_ops, but that might
> not be part of the kernel, causing the link to fail:
> 
> drivers/gpu/built-in.o:(.data+0xb234): undefined reference to 
> `drm_gem_cma_vm_ops'
> 
> This adds a Kconfig 'select' statement to enable it like the other
> user do.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 80f67cd80add ("drm/rockchip: Use cma gem vm ops")

Applied to drm-misc, thanks.
-Daniel
> ---
>  drivers/gpu/drm/rockchip/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index d30bdc38a760..e48611e83c03 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -2,6 +2,7 @@ config DRM_ROCKCHIP
>   tristate "DRM Support for Rockchip"
>   depends on DRM && ROCKCHIP_IOMMU
>   depends on RESET_CONTROLLER
> + select DRM_GEM_CMA_HELPER
>   select DRM_KMS_HELPER
>   select DRM_KMS_FB_HELPER
>   select DRM_PANEL
> -- 
> 2.9.0
> 
> ___
> 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

DRM DMA Engine

[Daniel Vetter]

On Thu, Jun 16, 2016 at 01:09:34PM +0100, Jose Abreu wrote:
> Hi Daniel,
> 
> Sorry to bother you again. I promise this is the last time :)
> 
> On 15-06-2016 11:15, Daniel Vetter wrote:
> > On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu  
> > wrote:
> >> On 15-06-2016 09:52, Daniel Vetter wrote:
> >>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu  
> >>> wrote:
> > I assume that xilinx VDMA is the only way to feed pixel data into your
> > display pipeline. Under that assumption:
> >
> > drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
> > would represent the dma channel. With atomic you can subclass
> > drm_plane/crtc_state structures to store all the runtime configuration 
> > in
> > there.
> >
> > The actual buffer itsel would be represented by a drm_framebuffer, which
> > either wraps a shmem gem or a cma gem object.
> >
> > If you want to know about the callbacks used by the atomic helpers to 
> > push
> > out plane updates, look at the hooks drm_atomic_helper_commit_planes()
> > (and the related functions, see kerneldoc) calls.
> >
> > I hope this helps a bit more.
> > -Daniel
>  Thanks a lot! With your help I was able to implement all the
>  needed logic. Sorry to bother you but I have one more question.
>  Right now I can initialize and configure the vdma correctly but I
>  can only send one frame. I guess when the dma completes
>  transmission I need to ask drm for a new frame, right? Because
>  the commit function starts the vdma correctly but then the dma
>  halts waiting for a new descriptor.
> >>> DRM has a continuous scanout model, i.e. when userspace doesn't give
> >>> you a new frame you're supposed to keep scanning out the current one.
> >>> So you need to rearm your upload code with the same drm_framebuffer if
> >>> userspace hasn't supplied a new one since the last time before the
> >>> vblank period starts.
> >>>
> >>> This is different to v4l, where userspace has to supply each frame
> >>> (and the kernel gets angry when there's not enough frames and signals
> >>> an underrun of the queue). This is because drm is geared at desktops,
> >>> and there it's perfectly normal to show the exact same frame for a
> >>> long time.
> >>> -Daniel
> >> Thanks, I was thinking this was similar to v4l. I am now able to
> >> send multiple frames so it is finally working! I have one little
> >> implementation detail: The controller that I am using supports
> >> deep color mode but I am using FB CMA helpers to create the
> >> framebuffer and I've seen that the supported bpp in these helpers
> >> only goes up to 32, right? Does this means that with these
> >> helpers I can't use deep color? Can I implement this deep color
> >> mode (48bpp) using a custom fb or do I also need custom gem
> >> allocation functions (Right now I am using GEM CMA helpers)?
> > Suprising the cma doesn't take pixel_format into account. If this
> > really doesn't work, pls fix up the cma helpers, not roll your own
> > copypasta ;-)
> >
> > Note that the fbdev emulation itself (maybe that's what threw you off)
> > only supports legacy rgb formats up to 32bits. But native kms can
> > support anything, we just might need to add the DRM_FOURCC codes for
> > that.
> > -Daniel
> 
> So, I ended up using 32bits and everything is working fine! I
> tested using [1] and [2] but now I have kind of a dumb question:
> I want to use the new driver that I created as a secondary output
> of my desktop so that I can play videos using mplayer but I am
> not being able to do this. If I check in my linux settings only
> one display is being detected, although in /dev/dri the two video
> cards are present (the native one and the one I added). Does the
> driver needs something additional to do this or is it only in my
> X configuration? I tried editing this configuration but still
> doesn't work. I believe that because my driver is not being
> probed at runtime the display is not being created by X. Is this
> correct?

X with multiple drivers is kinda a bit much. I think it should work
somewhat if you treat the 2nd driver as an offload engine. Afaik you can
change that through xrandr, but not sure. I didn't implement this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
>  wrote:
> > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > On Tue, 31 May 2016, James Bottomley <
> > > James.Bottomley at HansenPartnership.com> wrote:
> > > > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > > > On Mon, 30 May 2016, James Bottomley <
> > > > > James.Bottomley at HansenPartnership.com> wrote:
> > > > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > > > something
> > > > > > that
> > > > > > went in during the merge window.  The flicker isn't
> > > > > > continuous,
> > > > > > it's
> > > > > > periodic, with an interval of something like 2-5 seconds. 
> > > > > >  It
> > > > > > looks
> > > > > > like an old analogue TV going out of sync and then
> > > > > > resyncing.
> > > > > >  I've
> > > > > > attached the dmesg and X.org log below just in case they
> > > > > > can
> > > > > > help.
> > > > > >  I
> > > > > > might be able to bisect this next week, but, unfortunately,
> > > > > > this is
> > > > > > my
> > > > > > current laptop and I'm travelling this week.
> > > > > 
> > > > > Please try i915.enable_psr=0 module parameter.
> > > > 
> > > > Makes no discernable difference.  Current parameter settings
> > > > are:
> > > 
> > > Sorry for the silence. Would you mind trying out drm-intel
> > > -nightly
> > > branch of [1]?
> > > 
> > > BR,
> > > Jani.
> > > 
> > > [1] http://cgit.freedesktop.org/drm-intel
> > 
> > No, flicker is still there (and in fact seems worse) with the tree
> > with
> > this commit at the top:
> > 
> > commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
> > Author: Daniel Vetter 
> > Date:   Thu Jun 16 14:38:54 2016 +0200
> > 
> > drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
> > manifest
> 
> Strange indeed, I hoped the improved watermark code in -nightly would
> help. I assume nothing in dmesg about underruns or something similar?

Not that I can tell.  I've attached the full dmesg just in case.

> I guess we'll need the bisect on this one to make progress.

Sigh, I was afraid that might be the next step.

James

-- next part --
[0.00] Linux version 4.7.0-rc3+ (jejb at jarvis) (gcc version 4.8.5 
(SUSE Linux) ) #4 SMP PREEMPT Thu Jun 16 13:57:07 PDT 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-test 
root=UUID=994363fd-c12c-4c6c-92e9-85e8ac695cf9 ro resume=/dev/nvme0n1p2 
splash=silent quiet showopts pcie_aspm=force
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  960, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]: 1024, xstate_sizes[4]:   64
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 1088 
bytes, using 'standard' format.
[0.00] x86/fpu: Using 'eager' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x00057fff] usable
[0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved
[0.00] BIOS-e820: [mem 0x00059000-0x0009cfff] usable
[0.00] BIOS-e820: [mem 0x0009d000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x69537fff] usable
[0.00] BIOS-e820: [mem 0x69538000-0x69538fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x69539000-0x69562fff] reserved
[0.00] BIOS-e820: [mem 0x69563000-0x695bdfff] usable
[0.00] BIOS-e820: [mem 0x695be000-0x69daefff] reserved
[0.00] BIOS-e820: [mem 0x69daf000-0x7907dfff] usable
[0.00] BIOS-e820: [mem 0x7907e000-0x793f8fff] reserved
[0.00] BIOS-e820: [mem 0x793f9000-0x79448fff] ACPI data
[0.00] BIOS-e820: [mem 0x79449000-0x79c00fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x79c01000-0x7a4fefff] reserved
[0.00] BIOS-e820: [mem 0x7a4ff000-0x7a4f] usable
[0.00] BIOS-e820: [mem 0x7a50-0x7a5f] reserved
[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: 

[PATCH] drm: rockchip: select DRM_GEM_CMA_HELPER

[Arnd Bergmann]

The rockchip drm driver started using drm_gem_cma_vm_ops, but that might
not be part of the kernel, causing the link to fail:

drivers/gpu/built-in.o:(.data+0xb234): undefined reference to 
`drm_gem_cma_vm_ops'

This adds a Kconfig 'select' statement to enable it like the other
user do.

Signed-off-by: Arnd Bergmann 
Fixes: 80f67cd80add ("drm/rockchip: Use cma gem vm ops")
---
 drivers/gpu/drm/rockchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc38a760..e48611e83c03 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -2,6 +2,7 @@ config DRM_ROCKCHIP
tristate "DRM Support for Rockchip"
depends on DRM && ROCKCHIP_IOMMU
depends on RESET_CONTROLLER
+   select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_PANEL
-- 
2.9.0

Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> On Tue, 31 May 2016, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > On Mon, 30 May 2016, James Bottomley <
> > > James.Bottomley at HansenPartnership.com> wrote:
> > > > I've tested a pristine 4.6.0 system, so it's definitely
> > > > something
> > > > that
> > > > went in during the merge window.  The flicker isn't continuous,
> > > > it's
> > > > periodic, with an interval of something like 2-5 seconds.  It
> > > > looks
> > > > like an old analogue TV going out of sync and then resyncing. 
> > > >  I've
> > > > attached the dmesg and X.org log below just in case they can
> > > > help. 
> > > >  I
> > > > might be able to bisect this next week, but, unfortunately,
> > > > this is
> > > > my
> > > > current laptop and I'm travelling this week.
> > > 
> > > Please try i915.enable_psr=0 module parameter.
> > 
> > Makes no discernable difference.  Current parameter settings are:
> 
> Sorry for the silence. Would you mind trying out drm-intel-nightly
> branch of [1]?
> 
> BR,
> Jani.
> 
> [1] http://cgit.freedesktop.org/drm-intel

No, flicker is still there (and in fact seems worse) with the tree with
this commit at the top:

commit 3eb202ecc3668583f9ff4338211dbab47d755d1c
Author: Daniel Vetter 
Date:   Thu Jun 16 14:38:54 2016 +0200

drm-intel-nightly: 2016y-06m-16d-12h-38m-37s UTC integration
manifest

James

[radeon-alex:amd-staging-4.6 588/989] drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link_ddc.c:44:21: error: 'dvi_hdmi_dongle_signature_str' defined but not used

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.6
head:   beebb009c05fd5a89617327a9cfb724f19cecf1b
commit: 8b66b16511d44cc9917c04a1608dd721774e4445 [588/989] drm/amd/dal: Use max 
clocks/safemarks for dce10
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
git checkout 8b66b16511d44cc9917c04a1608dd721774e4445
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the radeon-alex/amd-staging-4.6 HEAD 
beebb009c05fd5a89617327a9cfb724f19cecf1b builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link_ddc.c:44:21: error: 
>> 'dvi_hdmi_dongle_signature_str' defined but not used 
>> [-Werror=unused-const-variable=]
static const int8_t dvi_hdmi_dongle_signature_str[] = "6140063500G";
^
   cc1: all warnings being treated as errors

vim +/dvi_hdmi_dongle_signature_str +44 
drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link_ddc.c

142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  28  #include "include/adapter_service_interface.h"
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  29  #include "include/ddc_service_types.h"
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  30  #include "include/grph_object_id.h"
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  31  #include "include/dpcd_defs.h"
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  32  #include "include/logger_interface.h"
43fb14b7c drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c Chris Park 
2016-01-27  33  #include "include/vector.h"
43fb14b7c drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c Chris Park 
2016-01-27  34  
43fb14b7c drivers/gpu/drm/amd/dal/dc/core/dc_link_ddc.c Chris Park 
2016-01-27  35  #include "dc_link_ddc.h"
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  36  
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  37  #define AUX_POWER_UP_WA_DELAY 500
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  38  #define I2C_OVER_AUX_DEFER_WA_DELAY 70
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  39  
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  40  /* CV smart dongle slave address for retrieving supported HDTV 
modes*/
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  41  #define CV_SMART_DONGLE_ADDRESS 0x20
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  42  /* DVI-HDMI dongle slave address for retrieving dongle 
signature*/
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  43  #define DVI_HDMI_DONGLE_ADDRESS 0x68
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25 @44  static const int8_t dvi_hdmi_dongle_signature_str[] = 
"6140063500G";
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  45  struct dvi_hdmi_dongle_signature_data {
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  46   int8_t vendor[3];/* "AMD" */
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  47   uint8_t version[2];
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  48   uint8_t size;
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  49   int8_t id[11];/* "6140063500G"*/
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  50  };
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  51  /* DP-HDMI dongle slave address for retrieving dongle 
signature*/
142fbbaab drivers/gpu/drm/amd/dal/dc/dcs/ddc_service.c  Harry Wentland 
2015-11-25  52  #define DP_HDMI_DONGLE_ADDRESS 0x40

:: The code at line 44 was first introduced by commit
:: 142fbbaab6655947879414a5a9730a6da12b7cf3 drm/amd/dal: Add dal display 
driver

:: TO: Harry Wentland 
:: CC: Alex Deucher 

---
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: 54174 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/c4b92587/attachment-0001.obj>

[PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 01:23:43PM +0900, Sergey Senozhatsky wrote:
> On (06/16/16 11:58), Minchan Kim wrote:
> [..]
> > RAX: 2065676162726166 so rax is totally garbage, I think.
> > It means obj_to_head returns garbage because get_first_obj_offset is
> > utter crab because (page_idx / class->pages_per_zspage) was totally
> > wrong.
> > 
> > >   ^^
> > > 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)
> >  
> > 
> > 
> > > > Could you test with [zsmalloc: keep first object offset in struct page]
> > > > in mmotm?
> > > 
> > > sure, I can.  will it help, tho? we have a race condition here I think.
> > 
> > I guess root cause is caused by get_first_obj_offset.
> 
> sounds reasonable.
> 
> > Please test with it.
> 
> 
> this is what I'm getting with the [zsmalloc: keep first object offset in 
> struct page]
> applied:  "count:0 mapcount:-127". which may be not related to zsmalloc at 
> this point.
> 
> kernel: BUG: Bad page state in process khugepaged  pfn:101db8
> kernel: page:ea0004076e00 count:0 mapcount:-127 mapping:  (null) 
> index:0x1

Hm, it seems double free.

It doen't happen if you disable zram? IOW, it seems to be related
zsmalloc migration?

How easy can you reprodcue it? Could you bisect it?

> kernel: flags: 0x8000()
> kernel: page dumped because: nonzero mapcount
> kernel: Modules linked in: lzo zram zsmalloc mousedev coretemp hwmon 
> crc32c_intel snd_hda_codec_realtek i2c_i801 snd_hda_codec_generic r8169 mii 
> snd_hda_intel snd_hda_codec snd_hda_core acpi_cpufreq snd_pcm snd_timer snd 
> soundcore lpc_ich processor mfd_core sch_fq_codel sd_mod hid_generic usb
> kernel: CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> 4.7.0-rc3-next-20160615-dbg-5-gfd11984-dirty #491
> kernel:   8801124c73f8 814d69b0 ea0004076e00
> kernel:  81e658a0 8801124c7420 811e9b63 
> kernel:  ea0004076e00 81e658a0 8801124c7440 811e9ca9
> kernel: Call Trace:
> kernel:  [] dump_stack+0x68/0x92
> kernel:  [] bad_page+0x158/0x1a2
> kernel:  [] free_pages_check_bad+0xfc/0x101
> kernel:  [] free_hot_cold_page+0x135/0x5de
> kernel:  [] __free_pages+0x67/0x72
> kernel:  [] release_freepages+0x13a/0x191
> kernel:  [] compact_zone+0x845/0x1155
> kernel:  [] ? compaction_suitable+0x76/0x76
> kernel:  [] compact_zone_order+0xe0/0x167
> kernel:  [] ? compact_zone+0x1155/0x1155
> kernel:  [] try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? try_to_compact_pages+0x2f1/0x648
> kernel:  [] ? compaction_zonelist_suitable+0x3a6/0x3a6
> kernel:  [] ? get_page_from_freelist+0x2c0/0x133c
> kernel:  [] __alloc_pages_direct_compact+0xea/0x30d
> kernel:  [] ? get_page_from_freelist+0x133c/0x133c
> kernel:  [] ? drain_all_pages+0x1d6/0x205
> kernel:  [] __alloc_pages_nodemask+0x143d/0x16b6
> kernel:  [] ? debug_show_all_locks+0x226/0x226
> kernel:  [] ? warn_alloc_failed+0x24c/0x24c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] ? lock_acquire+0xec/0x147
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x3b/0x5c
> kernel:  [] ? _raw_spin_unlock_irqrestore+0x47/0x5c
> kernel:  [] ? finish_wait+0x1a4/0x1b0
> kernel:  [] khugepaged+0x1d4/0x484f
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? finish_task_switch+0x3de/0x484
> kernel:  [] ? _raw_spin_unlock_irq+0x27/0x45
> kernel:  [] ? trace_hardirqs_on_caller+0x3d2/0x492
> kernel:  [] ? prepare_to_wait_event+0x3f7/0x3f7
> kernel:  [] ? __schedule+0xa4d/0xd16
> kernel:  [] kthread+0x252/0x261
> kernel:  [] ? hugepage_vma_revalidate+0xef/0xef
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> kernel:  [] ret_from_fork+0x1f/0x40
> kernel:  [] ? kthread_create_on_node+0x377/0x377
> -- Reboot --
> 
>   -ss

DRM DMA Engine

[Jose Abreu]

Hi Daniel,

Sorry to bother you again. I promise this is the last time :)

On 15-06-2016 11:15, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu  
> wrote:
>> On 15-06-2016 09:52, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 1:19 PM, Jose Abreu  
>>> wrote:
> I assume that xilinx VDMA is the only way to feed pixel data into your
> display pipeline. Under that assumption:
>
> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
> would represent the dma channel. With atomic you can subclass
> drm_plane/crtc_state structures to store all the runtime configuration in
> there.
>
> The actual buffer itsel would be represented by a drm_framebuffer, which
> either wraps a shmem gem or a cma gem object.
>
> If you want to know about the callbacks used by the atomic helpers to push
> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
> (and the related functions, see kerneldoc) calls.
>
> I hope this helps a bit more.
> -Daniel
 Thanks a lot! With your help I was able to implement all the
 needed logic. Sorry to bother you but I have one more question.
 Right now I can initialize and configure the vdma correctly but I
 can only send one frame. I guess when the dma completes
 transmission I need to ask drm for a new frame, right? Because
 the commit function starts the vdma correctly but then the dma
 halts waiting for a new descriptor.
>>> DRM has a continuous scanout model, i.e. when userspace doesn't give
>>> you a new frame you're supposed to keep scanning out the current one.
>>> So you need to rearm your upload code with the same drm_framebuffer if
>>> userspace hasn't supplied a new one since the last time before the
>>> vblank period starts.
>>>
>>> This is different to v4l, where userspace has to supply each frame
>>> (and the kernel gets angry when there's not enough frames and signals
>>> an underrun of the queue). This is because drm is geared at desktops,
>>> and there it's perfectly normal to show the exact same frame for a
>>> long time.
>>> -Daniel
>> Thanks, I was thinking this was similar to v4l. I am now able to
>> send multiple frames so it is finally working! I have one little
>> implementation detail: The controller that I am using supports
>> deep color mode but I am using FB CMA helpers to create the
>> framebuffer and I've seen that the supported bpp in these helpers
>> only goes up to 32, right? Does this means that with these
>> helpers I can't use deep color? Can I implement this deep color
>> mode (48bpp) using a custom fb or do I also need custom gem
>> allocation functions (Right now I am using GEM CMA helpers)?
> Suprising the cma doesn't take pixel_format into account. If this
> really doesn't work, pls fix up the cma helpers, not roll your own
> copypasta ;-)
>
> Note that the fbdev emulation itself (maybe that's what threw you off)
> only supports legacy rgb formats up to 32bits. But native kms can
> support anything, we just might need to add the DRM_FOURCC codes for
> that.
> -Daniel

So, I ended up using 32bits and everything is working fine! I
tested using [1] and [2] but now I have kind of a dumb question:
I want to use the new driver that I created as a secondary output
of my desktop so that I can play videos using mplayer but I am
not being able to do this. If I check in my linux settings only
one display is being detected, although in /dev/dri the two video
cards are present (the native one and the one I added). Does the
driver needs something additional to do this or is it only in my
X configuration? I tried editing this configuration but still
doesn't work. I believe that because my driver is not being
probed at runtime the display is not being created by X. Is this
correct?

[1] https://dri.freedesktop.org/libdrm/
[2] https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c

Thanks!

Best regards,
Jose Miguel Abreu

[PATCHv16 04/13] cec: add HDMI CEC framework

[Mauro Carvalho Chehab]

Em Fri, 29 Apr 2016 15:52:19 +0200
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
> 
> Besides the cec module itself it also adds a cec-edid module that
> contains helper functions to find and manipulate the CEC physical
> address inside an EDID. Even if the CEC support itself is disabled,
> drivers will still need these functions.
> 
> Note that the CEC framework is added to staging/media and that the
> cec.h and cec-funcs.h headers are not exported yet. While the kABI
> is mature, I would prefer to allow the uABI some more time before
> it is mainlined in case it needs more tweaks.

As pointed via IRC, it sounds like checkpatch were never used
on this patch series. Just this one got more than 100 errors/warnings:

total: 6 errors, 107 warnings, 5895 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Please fix, except if you have a good reason why not follow the
CodingStyle.

> 
> Signed-off-by: Hans Verkuil 
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
> [k.debski at samsung.com: change kthread handling when setting logical
> address]
> [k.debski at samsung.com: code cleanup and fixes]
> [k.debski at samsung.com: add missing CEC commands to match spec]
> [k.debski at samsung.com: add RC framework support]
> [k.debski at samsung.com: move and edit documentation]
> [k.debski at samsung.com: add vendor id reporting]
> [k.debski at samsung.com: add possibility to clear assigned logical
> addresses]
> [k.debski at samsung.com: documentation fixes, clenaup and expansion]
> [k.debski at samsung.com: reorder of API structs and add reserved fields]
> [k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
> problem]
> [k.debski at samsung.com: add sequence number handling]
> [k.debski at samsung.com: add passthrough mode]
> [k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
> minor additions]
> Signed-off-by: Kamil Debski 
> ---
>  MAINTAINERS|   16 +
>  drivers/media/Kconfig  |3 +
>  drivers/media/Makefile |2 +
>  drivers/media/cec-edid.c   |  139 ++
>  drivers/staging/media/Kconfig  |2 +
>  drivers/staging/media/Makefile |1 +
>  drivers/staging/media/cec/Kconfig  |8 +
>  drivers/staging/media/cec/Makefile |1 +
>  drivers/staging/media/cec/cec.c| 2481 
> 
>  include/linux/cec-funcs.h  | 1871 +++
>  include/linux/cec.h|  985 ++
>  include/media/cec-edid.h   |  103 ++
>  include/media/cec.h|  236 
>  13 files changed, 5848 insertions(+)
>  create mode 100644 drivers/media/cec-edid.c
>  create mode 100644 drivers/staging/media/cec/Kconfig
>  create mode 100644 drivers/staging/media/cec/Makefile
>  create mode 100644 drivers/staging/media/cec/cec.c
>  create mode 100644 include/linux/cec-funcs.h
>  create mode 100644 include/linux/cec.h
>  create mode 100644 include/media/cec-edid.h
>  create mode 100644 include/media/cec.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bfcb7ea..83bd865 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2760,6 +2760,22 @@ F: drivers/net/ieee802154/cc2520.c
>  F:   include/linux/spi/cc2520.h
>  F:   Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
>  
> +CEC DRIVER
> +M:   Hans Verkuil 
> +L:   linux-media at vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +W:   http://linuxtv.org
> +S:   Supported

> +F:   Documentation/cec.txt
> +F:   Documentation/DocBook/media/v4l/cec*

Not sure about the above. We're in the process of changing the
documentation engines at the Kernel, and the docs location will
likely change soon enough.

> +F:   drivers/staging/media/cec/cec.c
> +F:   drivers/media/cec-edid.c
> +F:   drivers/media/rc/keymaps/rc-cec.c
> +F:   include/media/cec.h
> +F:   include/media/cec-edid.h
> +F:   include/linux/cec.h
> +F:   include/linux/cec-funcs.h
> +
>  CELL BROADBAND ENGINE ARCHITECTURE
>  M:   Arnd Bergmann 
>  L:   linuxppc-dev at lists.ozlabs.org
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index a8518fb..052dcf7 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -80,6 +80,9 @@ config MEDIA_RC_SUPPORT
>  
> Say Y when you have a TV or an IR device.
>  
> +config MEDIA_CEC_EDID
> + tristate
> +
>  #
>  # Media controller
>  #Selectable only for webcam/grabbers, as other drivers don't use it
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index e608bbc..b56f013 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -2,6 +2,8 @@
>  # Makefile for the kernel multimedia device drivers.
>  #
>  
> 

[PATCH v2 0/6] drm/tilcdc Fixes and cleanups

[Tomi Valkeinen]

On 15/06/16 11:39, Jyri Sarha wrote:
> Some fixes and cleanups that should get merged to tilcdc even if my
> atomic changes are still a work in progress.
> 
> Jyri Sarha (6):
>   drm/tilcdc: Restore old dpms state in pm_resume()
>   drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ
> function
>   drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()
>   drm/tilcdc: Call drm_crtc_vblank_on() and *_off() in start() and
> stop()
>   drm/tilcdc: Refer to panel.txt and tfp410.txt bindings in tilcdc.txt
>   drm/tilcdc: Avoid error print by of_graph_get_next_endpoint()
> 
>  .../devicetree/bindings/display/tilcdc/tilcdc.txt  |  4 ++
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c   | 66 
> ++
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c|  3 +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|  2 +
>  drivers/gpu/drm/tilcdc/tilcdc_external.c   | 13 -
>  5 files changed, 62 insertions(+), 26 deletions(-)
> 

Beside the minor comments I had, looks fine to me.

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 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/20160616/6519bb24/attachment-0001.sig>

[PATCH v2 3/6] drm/tilcdc: Move waiting of LCDC_FRAME_DONE IRQ into stop()

[Tomi Valkeinen]

On 15/06/16 11:39, Jyri Sarha wrote:
> Move wait queue waiting of LCDC_FRAME_DONE IRQ from tilcdc_crtc_dpms()
> into stop() function.

You could mention the reason for this, which is just a cleanup here (I
presume).

> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 ---
>  1 file changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 1343717..cfa1a4e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -113,9 +113,25 @@ static void start(struct drm_crtc *crtc)
>  
>  static void stop(struct drm_crtc *crtc)
>  {
> + struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
>   struct drm_device *dev = crtc->dev;
> + struct tilcdc_drm_private *priv = dev->dev_private;
>  
> + tilcdc_crtc->frame_done = false;
>   tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> + /*
> +  * if necessary wait for framedone irq which will still come
> +  * before putting things to sleep..
> +  */
> + if (priv->rev == 2) {
> + int ret = wait_event_timeout(tilcdc_crtc->frame_done_wq,
> +  tilcdc_crtc->frame_done,
> +  msecs_to_jiffies(50));

Not part of this patch, but I think the timeout could be increased quite
a bit. It's never supposed to happen. And while video timings with 50ms
frames are not common, I don't see that as impossible either.

Of course, optimally the timeout would be calculated from the video
timings, which shouldn't be too difficult either...

Anyway, as I said, not part of this patch.

 Tomi

-- 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/20160616/053eb097/attachment.sig>

[PATCH v2 2/6] drm/tilcdc: Write to LCDC_END_OF_INT_IND_REG at the end of IRQ function

[Tomi Valkeinen]

On 15/06/16 11:39, Jyri Sarha wrote:
> Reorder the IRQ function so that the write to LCDC_END_OF_INT_IND_REG
> is done last. The write to LCDC_END_OF_INT_IND_REG indicates to LCDC
> that the interrupt service routine has completed (see section
> 13.3.6.1.6 in AM335x TRM). This is needed if LCDC's ipgvmodirq module
> is configured for pulse interrupts.
> 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 4d8f9a5..1343717 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -725,14 +725,19 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
>   tilcdc_crtc->frame_intact = true;
>   }
>  
> - if (priv->rev == 2) {
> - if (stat & LCDC_FRAME_DONE) {
> - tilcdc_crtc->frame_done = true;
> - wake_up(_crtc->frame_done_wq);
> - }
> - tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
> + if (priv->rev == 1)
> + return IRQ_HANDLED;
> + /* The rest is for revision 2 only */
> +
> + if (stat & LCDC_FRAME_DONE) {
> + tilcdc_crtc->frame_done = true;
> + wake_up(_crtc->frame_done_wq);
>   }
>  
> + if (stat & LCDC_FIFO_UNDERFLOW)
> + dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
> + __func__, stat);

We do have underflow irq for rev1 too, don't we?

Why not just move the "if (priv->rev == 2) {" block to the end? Or maybe
extract the write to the LCDC_END_OF_INT_IND_REG from the current block,
and move only that to the end. Much less re-ordering needed for that.

 Tomi

-- 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/20160616/a533814a/attachment.sig>

[PATCH v2 1/6] drm/tilcdc: Restore old dpms state in pm_resume()

[Tomi Valkeinen]

On 15/06/16 11:39, Jyri Sarha wrote:
> Restore old dpms state in pm_resume(). The dpms is turned off in
> pm_suspend() and it should be restored to its original state in
> pm_resume().
> 
> Fixes commit 614b3cfeb8d2 ("drm/tilcdc: disable the lcd controller/dma
> engine when suspend invoked")

This still doesn't explain the issue (at least clearly). If you send a
fix for some problem, it's good to have a clear explanation of what's
the problem (from user's perspective, what does he see).

 Tomi

-- 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/20160616/b3c1135e/attachment.sig>

[PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job

[Christian König]

Am 16.06.2016 um 11:54 schrieb zhoucm1:
>
>
> On 2016年06月16日 17:52, Christian König wrote:
>> Am 16.06.2016 um 10:33 schrieb zhoucm1:
>>>
>>>
>>> On 2016年06月15日 19:44, Christian König wrote:
 From: Christian König 

 When we pipeline evictions the page directory could already be
 moving somewhere else when grab_id is called.
>>> Isn't PD bo protected by job fence?
>>> I think before job fence is signalled, the PD bo is safe, there 
>>> shouldn't be a chance to evict PD bo.
>>
>> The crux here is that we start to pipeline BO evictions (we plan them 
>> but don't execute them immediately).
>>
>> E.g. the eviction won't happen before the protecting fence is 
>> signaled, but we have it planned and so the address returned by 
>> amdgpu_bo_gpu_offset() is already the new one.
> Thanks for mentioned, I see the code in ttm_bo_handle_move_mem:
> if (bo->mem.mm_node) {
> bo->offset = (bo->mem.start << PAGE_SHIFT) +
> bdev->man[bo->mem.mem_type].gpu_offset;
> bo->cur_placement = bo->mem.placement;
> } else
> bo->offset = 0;
>
> it seems better to update the offset after the moving-fence is 
> signalled, add a moving-fence callback?

No, when the next operation wants to move the BO back in it needs the 
already updated offset.

All we need to do is to make sure that all offsets are determined when 
the BO is validated into the domain where the submission needs it.

This is actually a requirement for retrieving all buffer offsets anyway 
because an application could request to move the buffer directly after 
making a submission with it.

The only reason we haven't noticed that previously is because 
applications can't affect the PD directly and we didn't pipelined 
evictions (the only other reason for moving a buffer).

I should probably take a look at adding a couple of warning to 
amdgpu_bo_gpu_offset() again.

Regards,
Christian.

>
> Regards,
> David Zhou
>>
>> Regards,
>> Christian.
>>
>>>
>>> Regards,
>>> David Zhou

 Signed-off-by: Christian König 
 ---
   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
   2 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
 b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
 index a3d7d13..850c4dd 100644
 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
 @@ -661,6 +661,8 @@ static int amdgpu_cs_ib_vm_chunk(struct 
 amdgpu_device *adev,
   }
   }
   +p->job->vm_pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
 +
   r = amdgpu_bo_vm_update_pte(p, vm);
   if (!r)
   amdgpu_cs_sync_rings(p);
 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
 b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
 index d3e0576..82efb40 100644
 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
 @@ -177,7 +177,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
 struct amdgpu_ring *ring,
 struct amdgpu_sync *sync, struct fence *fence,
 unsigned *vm_id, uint64_t *vm_pd_addr)
   {
 -uint64_t pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
   struct amdgpu_device *adev = ring->adev;
   struct fence *updates = sync->last_vm_update;
   struct amdgpu_vm_id *id, *idle;
 @@ -250,7 +249,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
 struct amdgpu_ring *ring,
   if (atomic64_read(>owner) != vm->client_id)
   continue;
   -if (pd_addr != id->pd_gpu_addr)
 +if (*vm_pd_addr != id->pd_gpu_addr)
   continue;
 if (!same_ring &&
 @@ -298,14 +297,13 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
 struct amdgpu_ring *ring,
   fence_put(id->flushed_updates);
   id->flushed_updates = fence_get(updates);
   -id->pd_gpu_addr = pd_addr;
 +id->pd_gpu_addr = *vm_pd_addr;
 list_move_tail(>list, >vm_manager.ids_lru);
   atomic64_set(>owner, vm->client_id);
   vm->ids[ring->idx] = id;
 *vm_id = id - adev->vm_manager.ids;
 -*vm_pd_addr = pd_addr;
   trace_amdgpu_vm_grab_id(vm, ring->idx, *vm_id, *vm_pd_addr);
 error:
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[PATCH v7 00/12] Support non-lru page migration

[Minchan Kim]

On Thu, Jun 16, 2016 at 11:48:27AM +0900, Sergey Senozhatsky wrote:
> Hi,
> 
> On (06/16/16 08:12), Minchan Kim wrote:
> > > [  315.146533] kasan: CONFIG_KASAN_INLINE enabled
> > > [  315.146538] kasan: GPF could be caused by NULL-ptr deref or user 
> > > memory access
> > > [  315.146546] general protection fault:  [#1] PREEMPT SMP KASAN
> > > [  315.146576] Modules linked in: lzo zram zsmalloc mousedev coretemp 
> > > hwmon crc32c_intel r8169 i2c_i801 mii snd_hda_codec_realtek 
> > > snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core 
> > > acpi_cpufreq snd_pcm snd_timer snd soundcore lpc_ich mfd_core processor 
> > > sch_fq_codel sd_mod hid_generic usbhid hid ahci libahci libata ehci_pci 
> > > ehci_hcd scsi_mod usbcore usb_common
> > > [  315.146785] CPU: 3 PID: 38 Comm: khugepaged Not tainted 
> > > 4.7.0-rc3-next-20160614-dbg-4-ga1c2cbc-dirty #488
> > > [  315.146841] task: 8800bfaf2900 ti: 880112468000 task.ti: 
> > > 880112468000
> > > [  315.146859] RIP: 0010:[]  [] 
> > > zs_page_migrate+0x355/0xaa0 [zsmalloc]
> > 
> > Thanks for the report!
> > 
> > zs_page_migrate+0x355? Could you tell me what line is it?
> > 
> > It seems to be related to obj_to_head.
> 
> reproduced. a bit different call stack this time. but the problem is
> still the same.
> 
> zs_compact()
> ...
> 6371:   e8 00 00 00 00  callq  6376 
> 6376:   0f 0b   ud2
> 6378:   48 8b 95 a8 fe ff ffmov-0x158(%rbp),%rdx
> 637f:   4d 8d 74 24 78  lea0x78(%r12),%r14
> 6384:   4c 89 eemov%r13,%rsi
> 6387:   4c 89 e7mov%r12,%rdi
> 638a:   e8 86 c7 ff ff  callq  2b15 
> 638f:   41 89 c5mov%eax,%r13d
> 6392:   4c 89 f0mov%r14,%rax
> 6395:   48 c1 e8 03 shr$0x3,%rax
> 6399:   8a 04 18mov(%rax,%rbx,1),%al
> 639c:   84 c0   test   %al,%al
> 639e:   0f 85 f2 02 00 00   jne6696 
> 63a4:   41 8b 44 24 78  mov0x78(%r12),%eax
> 63a9:   41 0f af c7 imul   %r15d,%eax
> 63ad:   41 01 c5add%eax,%r13d
> 63b0:   4c 89 f0mov%r14,%rax
> 63b3:   48 c1 e8 03 shr$0x3,%rax
> 63b7:   48 01 d8add%rbx,%rax
> 63ba:   48 89 85 88 fe ff ffmov%rax,-0x178(%rbp)
> 63c1:   41 81 fd ff 0f 00 00cmp$0xfff,%r13d
> 63c8:   0f 87 1a 03 00 00   ja 66e8 
> 63ce:   49 63 f5movslq %r13d,%rsi
> 63d1:   48 03 b5 98 fe ff ffadd-0x168(%rbp),%rsi
> 63d8:   48 8b bd a8 fe ff ffmov-0x158(%rbp),%rdi
> 63df:   e8 67 d9 ff ff  callq  3d4b 
> 63e4:   a8 01   test   $0x1,%al
> 63e6:   0f 84 d9 02 00 00   je 66c5 
> 63ec:   48 83 e0 fe and$0xfffe,%rax
> 63f0:   bf 01 00 00 00  mov$0x1,%edi
> 63f5:   48 89 85 b0 fe ff ffmov%rax,-0x150(%rbp)
> 63fc:   e8 00 00 00 00  callq  6401 
> 6401:   48 8b 85 b0 fe ff ffmov-0x150(%rbp),%rax

RAX: 2065676162726166 so rax is totally garbage, I think.
It means obj_to_head returns garbage because get_first_obj_offset is
utter crab because (page_idx / class->pages_per_zspage) was totally
wrong.

>   ^^
> 6408:   f0 0f ba 28 00  lock btsl $0x0,(%rax)



> > Could you test with [zsmalloc: keep first object offset in struct page]
> > in mmotm?
> 
> sure, I can.  will it help, tho? we have a race condition here I think.

I guess root cause is caused by get_first_obj_offset.
Please test with it.

Thanks!

[PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job

[Christian König]

Am 16.06.2016 um 10:33 schrieb zhoucm1:
>
>
> On 2016年06月15日 19:44, Christian König wrote:
>> From: Christian König 
>>
>> When we pipeline evictions the page directory could already be
>> moving somewhere else when grab_id is called.
> Isn't PD bo protected by job fence?
> I think before job fence is signalled, the PD bo is safe, there 
> shouldn't be a chance to evict PD bo.

The crux here is that we start to pipeline BO evictions (we plan them 
but don't execute them immediately).

E.g. the eviction won't happen before the protecting fence is signaled, 
but we have it planned and so the address returned by 
amdgpu_bo_gpu_offset() is already the new one.

Regards,
Christian.

>
> Regards,
> David Zhou
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++
>>   2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index a3d7d13..850c4dd 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -661,6 +661,8 @@ static int amdgpu_cs_ib_vm_chunk(struct 
>> amdgpu_device *adev,
>>   }
>>   }
>>   +p->job->vm_pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>> +
>>   r = amdgpu_bo_vm_update_pte(p, vm);
>>   if (!r)
>>   amdgpu_cs_sync_rings(p);
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index d3e0576..82efb40 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -177,7 +177,6 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>> struct amdgpu_ring *ring,
>> struct amdgpu_sync *sync, struct fence *fence,
>> unsigned *vm_id, uint64_t *vm_pd_addr)
>>   {
>> -uint64_t pd_addr = amdgpu_bo_gpu_offset(vm->page_directory);
>>   struct amdgpu_device *adev = ring->adev;
>>   struct fence *updates = sync->last_vm_update;
>>   struct amdgpu_vm_id *id, *idle;
>> @@ -250,7 +249,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>> struct amdgpu_ring *ring,
>>   if (atomic64_read(>owner) != vm->client_id)
>>   continue;
>>   -if (pd_addr != id->pd_gpu_addr)
>> +if (*vm_pd_addr != id->pd_gpu_addr)
>>   continue;
>> if (!same_ring &&
>> @@ -298,14 +297,13 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, 
>> struct amdgpu_ring *ring,
>>   fence_put(id->flushed_updates);
>>   id->flushed_updates = fence_get(updates);
>>   -id->pd_gpu_addr = pd_addr;
>> +id->pd_gpu_addr = *vm_pd_addr;
>> list_move_tail(>list, >vm_manager.ids_lru);
>>   atomic64_set(>owner, vm->client_id);
>>   vm->ids[ring->idx] = id;
>> *vm_id = id - adev->vm_manager.ids;
>> -*vm_pd_addr = pd_addr;
>>   trace_amdgpu_vm_grab_id(vm, ring->idx, *vm_id, *vm_pd_addr);
>> error:
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch v2] drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()

[Dan Carpenter]

There is no limit on high "idx" can go.  It should be less than
ARRAY_SIZE(data.states) which is 16.

The "data" variable wasn't declared in that scope so I shifted the code
around a bit to make it work.  Also I made "idx" unsigned.

Fixes: f3898ea12fc1 ('drm/amd/powerplay: add some sysfs interfaces for 
powerplay.')
Signed-off-by: Dan Carpenter 
---
v2: make idx unsigned

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index 589b36e..0e13d80 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -270,30 +270,28 @@ static ssize_t amdgpu_set_pp_force_state(struct device 
*dev,
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = ddev->dev_private;
enum amd_pm_state_type state = 0;
-   long idx;
+   unsigned long idx;
int ret;

if (strlen(buf) == 1)
adev->pp_force_state_enabled = false;
-   else {
-   ret = kstrtol(buf, 0, );
+   else if (adev->pp_enabled) {
+   struct pp_states_info data;

-   if (ret) {
+   ret = kstrtoul(buf, 0, );
+   if (ret || idx >= ARRAY_SIZE(data.states)) {
count = -EINVAL;
goto fail;
}

-   if (adev->pp_enabled) {
-   struct pp_states_info data;
-   amdgpu_dpm_get_pp_num_states(adev, );
-   state = data.states[idx];
-   /* only set user selected power states */
-   if (state != POWER_STATE_TYPE_INTERNAL_BOOT &&
-   state != POWER_STATE_TYPE_DEFAULT) {
-   amdgpu_dpm_dispatch_task(adev,
-   AMD_PP_EVENT_ENABLE_USER_STATE, 
, NULL);
-   adev->pp_force_state_enabled = true;
-   }
+   amdgpu_dpm_get_pp_num_states(adev, );
+   state = data.states[idx];
+   /* only set user selected power states */
+   if (state != POWER_STATE_TYPE_INTERNAL_BOOT &&
+   state != POWER_STATE_TYPE_DEFAULT) {
+   amdgpu_dpm_dispatch_task(adev,
+   AMD_PP_EVENT_ENABLE_USER_STATE, , 
NULL);
+   adev->pp_force_state_enabled = true;
}
}
 fail:

[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip

[Michel Dänzer]

On 15.06.2016 18:23, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 05:03:41PM +0900, Michel Dänzer wrote:
>> On 14.06.2016 17:06, Daniel Vetter wrote:
>>> On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote:
 On 14.06.2016 14:53, Daniel Vetter wrote:
>
> I didn't know that we pass vblank waits to X clients. Either way annoying,
> since it means you need to keep things working like this for amd drivers
> forever.

 Please don't try to single out our drivers, it seems like rather your
 driver is the odd man out in this case.
>>>
>>> Hm, why/where is i915 special?
>>
>> By only triggering the vblank interrupt at the end of a vertical blank
>> period, breaking the original DRM_IOCTL_WAIT_VBLANK functionality.
> 
> Ok, turns out we never did that, but we did move the drm event for page
> flip completion around. So indeed vblank wait drm event should fire at
> start of vblank if possible. I still maintain that (by default) you
> shouldn't allow a page flip to overtake a drm event.

We don't allow that AFAIK. If you think we do, please describe the
scenario you're thinking of.

The only thing I can think of is that you may be concerned about cases
where userspace calls DRM_IOCTL_MODE_PAGE_FLIP several times in a row
without calling DRM_IOCTL_WAIT_VBLANK in between. If so, I can change
patch 2 to also track page flip completions in
file_priv->last_vblank_wait. That would ensure that two consecutive
flips can never complete in the same vertical blank period.


> How bad would it really be to just always delay the page_flip past vblank?

 [...]
>>
>> [...] always delaying flip programming past vblank can cause flips to be
>> unnecessarily delayed by one frame.
> 
> Yes, but right now you show them too early, breaking existing stuff.

No, we don't! Neither before this series nor after it, nor at any point
during it.

The DRI2 code in our DDX drivers actually checks for this and complains
if a flip completes earlier than expected. We did break this before and
received bug reports about it. Mario fixed it by changing the
MASTER_UPDATE_MODE register to 3, which restricts flips to take effect
only at the beginning of vertical blank. This series makes it safe to
change it back to 0 (allowing flips to take effect anywhere in vertical
blank) and then does so.


> If that's not good enough I'd say we should add a
> faster-than-vblank-but-still-synced page_flip flag. Then userspace could
> tell you exactly whether you should always wait (no flags), or never wait
> (with this new flag).

 That would be an inferior solution compared to my series, e.g.: If
 userspace calls DRM_IOCTL_MODE_PAGE_FLIP before the target vblank seqno
 is reached, it cannot use the new flag, otherwise the flip might take
 effect too early. However, if we are then already in the target vblank
 period when the fences have signalled and we are ready to program the
 flip, we have to wait for the end of vblank first, and the flip will be
 delayed by one frame.

 If we're going to change the userspace interface, it would be better to
 re-purpose the reserved field of struct drm_mode_crtc_page_flip for
 explicitly specifying the target vblank seqno (via a new cap and flag).
 Then the kernel and userspace would no longer need to second-guess each
 other.

 But even if we take that route, this series would be desirable for
 getting us most of the way there for existing userspace.
>>>
>>> Well that's what I mean. You'r patches here shoehorn what you want into
>>> existing api, trying to second-guess userspaces intentions inferred from
>>> what it does. Ime that tends to end in trouble. It would be much better to
>>> have a clear uabi for this. And my flag was just a suggestion.
>>>
>>> [...] At least I think the generic kms rules are:
>>>
>>> - vblank events fire at lockstep [...].
>>> - pageflip immediately after a vblank wait needs to hit the next vblank.
>>> - pageflip in a loop needs to result in at most 1 flip per vblank, and if
>>>   you're too fast then the kernel should return -EBUSY. [...]
>>
>> My series doesn't break any of these rules (or any others I'm aware of).
>> It avoids unnecessarily delaying flips in some cases within the confines
>> of these rules.
>>
>>
>>> Imo everything else (in this case: make the flip complete on the same
>>> frame as the vblank, if you hit the vblank window) needs special flags,
>>> with clear meaning of what they do. The specific flip target sounds like a
>>> good idea, except that current userspace can't be fixed, so we need to
>>> make it work without any flag.
>>
>> Hey, that was my point above! So you agree that (something like) this
>> series will be needed anyway, even if new flags are added to make it
>> more explicit? :)
> 
> Yeah I think there's a bit of confusion going on here ;-) Of course I'm
> not against fixing this, and I agree that fixing it by delaying the 

[patch] drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()

[Dan Carpenter]

Sure, I'll resend.  Unsigned is a little cleaner.  There is no new error
code/message or change in behavior though either way.

regards,
dan carpenter

[PATCH 1/2] drm/mediatek: Add gamma correction

[Bibby Hsieh]

Hi, Daniel, 

Thank you for your suggestion, I will modify that to use the atomic
color management.

Bibby

On Tue, 2016-06-14 at 07:43 +0200, Daniel Vetter wrote:
> On Tue, Jun 14, 2016 at 10:55:52AM +0800, Bibby Hsieh wrote:
> > Apply gamma function to correct brightness values.
> > It applies arbitrary mapping curve to compensate the
> > incorrect transfer function of the panel.
> > 
> > Signed-off-by: Bibby Hsieh 
> 
> I think it would be much better to use the new atomic color management
> support, which includes gamma. See drm_crtc_enable_color_mgmt.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |   12 ++
> >  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 +
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |   56 
> > ++-
> >  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |9 +
> >  4 files changed, 77 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 24aa3ba..1b38406 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -127,6 +127,16 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> > state->base.crtc = crtc;
> >  }
> >  
> > +static void mtk_crtc_gamma_set(struct drm_crtc *crtc, u16 *r,
> > +  u16 *g, u16 *b, uint32_t start, uint32_t size)
> > +{
> > +   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> > +   mtk_ddp_gamma_set(mtk_crtc->ddp_comp[i], r, g, b, start, size);
> > +}
> > +
> >  static struct drm_crtc_state *mtk_drm_crtc_duplicate_state(struct drm_crtc 
> > *crtc)
> >  {
> > struct mtk_crtc_state *state;
> > @@ -418,6 +428,7 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> > .reset  = mtk_drm_crtc_reset,
> > .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
> > .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
> > +   .gamma_set  = mtk_crtc_gamma_set,
> >  };
> >  
> >  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> > @@ -569,6 +580,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > if (ret < 0)
> > goto unprepare;
> >  
> > +   drm_mode_crtc_set_gamma_size(_crtc->base, MTK_LUT_SIZE);
> > priv->crtc[pipe] = _crtc->base;
> > priv->num_pipes++;
> >  
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > index 81e5566..d332564 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> > @@ -19,6 +19,7 @@
> >  #include "mtk_drm_plane.h"
> >  
> >  #define OVL_LAYER_NR   4
> > +#define MTK_LUT_SIZE   512
> >  
> >  int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> >  void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int 
> > pipe);
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > index 3970fcf..3fd5141 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > @@ -24,6 +24,7 @@
> >  #include "mtk_drm_drv.h"
> >  #include "mtk_drm_plane.h"
> >  #include "mtk_drm_ddp_comp.h"
> > +#include "mtk_drm_crtc.h"
> >  
> >  #define DISP_OD_EN 0x
> >  #define DISP_OD_INTEN  0x0008
> > @@ -38,6 +39,18 @@
> >  #define DISP_COLOR_WIDTH   0x0c50
> >  #define DISP_COLOR_HEIGHT  0x0c54
> >  
> > +#define DISP_AAL_EN0x000
> > +#define DISP_AAL_SIZE  0x030
> > +
> > +#define DISP_GAMMA_CFG 0x020
> > +#define DISP_GAMMA_LUT 0x700
> > +
> > +#define LUT_10BIT_MASK 0x3ff
> > +
> > +#define AAL_EN BIT(0)
> > +
> > +#define GAMMA_LUT_EN   BIT(1)
> > +
> >  #defineOD_RELAY_MODE   BIT(0)
> >  
> >  #defineUFO_BYPASS  BIT(2)
> > @@ -76,6 +89,40 @@ static void mtk_ufoe_start(struct mtk_ddp_comp *comp)
> > writel(UFO_BYPASS, comp->regs + DISP_REG_UFO_START);
> >  }
> >  
> > +static void mtk_aal_config(struct mtk_ddp_comp *comp, unsigned int w,
> > +  unsigned int h, unsigned int vrefresh)
> > +{
> > +   writel(h << 16 | w, comp->regs + DISP_AAL_SIZE);
> > +}
> > +
> > +static void mtk_aal_start(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(AAL_EN, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_aal_stop(struct mtk_ddp_comp *comp)
> > +{
> > +   writel_relaxed(0x0, comp->regs  + DISP_AAL_EN);
> > +}
> > +
> > +static void mtk_gamma_set(struct mtk_ddp_comp *comp, u16 *r, u16 *g,
> > + u16 *b, uint32_t start, uint32_t size)
> > +{
> > +  

[patch] drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()

[Dan Carpenter]

On Thu, Jun 16, 2016 at 09:26:03AM +0200, walter harms wrote:
> 
> 
> Am 16.06.2016 08:41, schrieb Dan Carpenter:
> > There is no limit on high "idx" can go.  It should be less than
> > ARRAY_SIZE(data.states) which is 16.
> > 
> > The "data" variable wasn't declared in that scope so I shifted the code
> > around a bit to make it work.
> > 
> > Fixes: f3898ea12fc1 ('drm/amd/powerplay: add some sysfs interfaces for 
> > powerplay.')
> > Signed-off-by: Dan Carpenter 
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > index 589b36e..ce9e97f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > @@ -275,25 +275,23 @@ static ssize_t amdgpu_set_pp_force_state(struct 
> > device *dev,
> >  
> > if (strlen(buf) == 1)
> > adev->pp_force_state_enabled = false;
> > -   else {
> > -   ret = kstrtol(buf, 0, );
> > +   else if (adev->pp_enabled) {
> > +   struct pp_states_info data;
> >  
> > -   if (ret) {
> > +   ret = kstrtol(buf, 0, );
> > +   if (ret || idx >= ARRAY_SIZE(data.states)) {
> > count = -EINVAL;
> > goto fail;
> > }
> 
> 
> i would also expect a check idx < 0, does it mean this can not happen ?
> otherwise maybe kstrtoul is a solution ?

The original code could underflow, but my code can't.  ARRAY_SIZE()
means the comparison is type promoted to size_t which is unsigned long.

regards,
dan carpenter

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

[Rob Clark]

So, if we wanted to extend this to support the fourcc-modifiers that
we have on the kernel side for compressed/tiled/etc formats, what
would be the right approach?

A new version of the existing extension or a new
EGL_EXT_image_dma_buf_import2 extension, or ??

BR,
-R

On Mon, Feb 25, 2013 at 6:54 AM, Tom Cooksey  wrote:
> Hi All,
>
> The final spec has had enum values assigned and been published on Khronos:
>
> http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>
> Thanks to all who've provided input.
>
>
> Cheers,
>
> Tom
>
>
>
>> -Original Message-
>> From: mesa-dev-bounces+tom.cooksey=arm.com at lists.freedesktop.org 
>> [mailto:mesa-dev-
>> bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom 
>> Cooksey
>> Sent: 04 October 2012 13:10
>> To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; 
>> dri-
>> devel at lists.freedesktop.org; linux-media at vger.kernel.org
>> Subject: [Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - New draft!
>>
>> Hi All,
>>
>> After receiving a fair bit of feedback (thanks!), I've updated the
>> EGL_EXT_image_dma_buf_import spec
>> and expanded it to resolve a number of the issues. Please find the latest 
>> draft below and let
>> me
>> know any additional feedback you might have, either on the lists or by 
>> private e-mail - I
>> don't mind
>> which.
>>
>> I think the only remaining issue now is if we need a mechanism whereby an 
>> application can
>> query
>> which drm_fourcc.h formats EGL supports or if just failing with 
>> EGL_BAD_MATCH when the
>> application
>> has use one EGL doesn't support is sufficient. Any thoughts?
>>
>>
>> Cheers,
>>
>> Tom
>>
>>
>> 8<
>>
>>
>> Name
>>
>> EXT_image_dma_buf_import
>>
>> Name Strings
>>
>> EGL_EXT_image_dma_buf_import
>>
>> Contributors
>>
>> Jesse Barker
>> Rob Clark
>> Tom Cooksey
>>
>> Contacts
>>
>> Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)
>> Tom Cooksey (tom 'dot' cooksey 'at' arm 'dot' com)
>>
>> Status
>>
>> DRAFT
>>
>> Version
>>
>> Version 4, October 04, 2012
>>
>> Number
>>
>> EGL Extension ???
>>
>> Dependencies
>>
>> EGL 1.2 is required.
>>
>> EGL_KHR_image_base is required.
>>
>> The EGL implementation must be running on a Linux kernel supporting the
>> dma_buf buffer sharing mechanism.
>>
>> This extension is written against the wording of the EGL 1.2 
>> Specification.
>>
>> Overview
>>
>> This extension allows creating an EGLImage from a Linux dma_buf file
>> descriptor or multiple file descriptors in the case of multi-plane YUV
>> images.
>>
>> New Types
>>
>> None
>>
>> New Procedures and Functions
>>
>> None
>>
>> New Tokens
>>
>> Accepted by the  parameter of eglCreateImageKHR:
>>
>> EGL_LINUX_DMA_BUF_EXT
>>
>> Accepted as an attribute in the  parameter of
>> eglCreateImageKHR:
>>
>> EGL_LINUX_DRM_FOURCC_EXT
>> EGL_DMA_BUF_PLANE0_FD_EXT
>> EGL_DMA_BUF_PLANE0_OFFSET_EXT
>> EGL_DMA_BUF_PLANE0_PITCH_EXT
>> EGL_DMA_BUF_PLANE1_FD_EXT
>> EGL_DMA_BUF_PLANE1_OFFSET_EXT
>> EGL_DMA_BUF_PLANE1_PITCH_EXT
>> EGL_DMA_BUF_PLANE2_FD_EXT
>> EGL_DMA_BUF_PLANE2_OFFSET_EXT
>> EGL_DMA_BUF_PLANE2_PITCH_EXT
>> EGL_YUV_COLOR_SPACE_HINT_EXT
>> EGL_SAMPLE_RANGE_HINT_EXT
>> EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT
>>
>> Accepted as the value for the EGL_YUV_COLOR_SPACE_HINT_EXT attribute:
>>
>> EGL_ITU_REC601_EXT
>> EGL_ITU_REC709_EXT
>> EGL_ITU_REC2020_EXT
>>
>> Accepted as the value for the EGL_SAMPLE_RANGE_HINT_EXT attribute:
>>
>> EGL_YUV_FULL_RANGE_EXT
>> EGL_YUV_NARROW_RANGE_EXT
>>
>> Accepted as the value for the EGL_YUV_CHROMA_HORIZONTAL_SITING_HINT_EXT &
>> EGL_YUV_CHROMA_VERTICAL_SITING_HINT_EXT attributes:
>>
>> EGL_YUV_CHROMA_SITING_0_EXT
>> EGL_YUV_CHROMA_SITING_0_5_EXT
>>
>>
>> Additions to Chapter 2 of the EGL 1.2 Specification (EGL Operation)
>>
>> Add to section 2.5.1 "EGLImage Specification" (as defined by the
>> EGL_KHR_image_base specification), in the description of
>> eglCreateImageKHR:
>>
>>"Values accepted for  are listed in Table aaa, below.
>>
>>   
>> +-++
>>   | |  Notes 
>> |
>>   
>> +-++
>>   |  EGL_LINUX_DMA_BUF_EXT  |   Used for EGLImages imported from Linux   
>> |
>>   | |   dma_buf file descriptors 
>> |
>>   
>> +-++
>>Table aaa.  Legal values for eglCreateImageKHR  parameter
>>
>> ...
>>
>> 

[patch v2] drm/amdgpu: missing bounds check in amdgpu_set_pp_force_state()

[Christian König]

Am 16.06.2016 um 10:30 schrieb Dan Carpenter:
> There is no limit on high "idx" can go.  It should be less than
> ARRAY_SIZE(data.states) which is 16.
>
> The "data" variable wasn't declared in that scope so I shifted the code
> around a bit to make it work.  Also I made "idx" unsigned.
>
> Fixes: f3898ea12fc1 ('drm/amd/powerplay: add some sysfs interfaces for 
> powerplay.')
> Signed-off-by: Dan Carpenter 

Acked-by: Christian König .

> ---
> v2: make idx unsigned
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 589b36e..0e13d80 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -270,30 +270,28 @@ static ssize_t amdgpu_set_pp_force_state(struct device 
> *dev,
>   struct drm_device *ddev = dev_get_drvdata(dev);
>   struct amdgpu_device *adev = ddev->dev_private;
>   enum amd_pm_state_type state = 0;
> - long idx;
> + unsigned long idx;
>   int ret;
>   
>   if (strlen(buf) == 1)
>   adev->pp_force_state_enabled = false;
> - else {
> - ret = kstrtol(buf, 0, );
> + else if (adev->pp_enabled) {
> + struct pp_states_info data;
>   
> - if (ret) {
> + ret = kstrtoul(buf, 0, );
> + if (ret || idx >= ARRAY_SIZE(data.states)) {
>   count = -EINVAL;
>   goto fail;
>   }
>   
> - if (adev->pp_enabled) {
> - struct pp_states_info data;
> - amdgpu_dpm_get_pp_num_states(adev, );
> - state = data.states[idx];
> - /* only set user selected power states */
> - if (state != POWER_STATE_TYPE_INTERNAL_BOOT &&
> - state != POWER_STATE_TYPE_DEFAULT) {
> - amdgpu_dpm_dispatch_task(adev,
> - AMD_PP_EVENT_ENABLE_USER_STATE, 
> , NULL);
> - adev->pp_force_state_enabled = true;
> - }
> + amdgpu_dpm_get_pp_num_states(adev, );
> + state = data.states[idx];
> + /* only set user selected power states */
> + if (state != POWER_STATE_TYPE_INTERNAL_BOOT &&
> + state != POWER_STATE_TYPE_DEFAULT) {
> + amdgpu_dpm_dispatch_task(adev,
> + AMD_PP_EVENT_ENABLE_USER_STATE, , 
> NULL);
> + adev->pp_force_state_enabled = true;
>   }
>   }
>   fail:

[PATCH v2 03/10] dt-bindings: msm/mdp: Fix up clock related bindings

[Archit Taneja]

On 06/14/2016 12:33 AM, Rob Herring wrote:
> On Fri, Jun 10, 2016 at 04:16:33PM +0530, Archit Taneja wrote:
>> MDP5:
>> - Don't ask for source clock
>>
>> MDP4:
>> - Give a better name for MDP_TV_CLK
>> - Remove TV_SRC
>> - Add MDP_AXI_CLK
>
> This could use the explanation in the commit msg why it is okay you are
> breaking compatibility.

Sure, I'll do that. Thanks for the reviews.

Archit

>
> With that,
>
> Acked-by: Rob Herring 
>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation

[radeon-alex:amd-staging-4.6 397/989] drivers/gpu/drm/amd/amdgpu/../dal/dc/calcs/bandwidth_calcs.c:2780:7: error: array subscript is above array bounds

[kbuild test robot]

results->bytes_per_request[k]),
142fbbaab Harry Wentland 2015-11-25  2771   
(add(
142fbbaab Harry Wentland 2015-11-25  2772   
add(
142fbbaab Harry Wentland 2015-11-25  2773   
vbios->blackout_duration,
142fbbaab Harry Wentland 2015-11-25  2774   
mul(
142fbbaab Harry Wentland 2015-11-25  2775   
vbios->mcifwrmc_urgent_latency,
142fbbaab Harry Wentland 2015-11-25  2776   
int_to_fixed(
142fbbaab Harry Wentland 2015-11-25  2777   
2))),
142fbbaab Harry Wentland 2015-11-25  2778   
results->mcifwr_burst_time[y_clk_level][sclk_level]) {
142fbbaab Harry Wentland 2015-11-25  2779   
results->blackout_recovery_time =
142fbbaab Harry Wentland 2015-11-25 @2780   
bw_max(
142fbbaab Harry Wentland 2015-11-25  2781   
results->blackout_recovery_time,
142fbbaab Harry Wentland 2015-11-25  2782   
bw_div(
142fbbaab Harry Wentland 2015-11-25  2783   
(sub(
142fbbaab Harry Wentland 2015-11-25  2784   
add(
142fbbaab Harry Wentland 2015-11-25  2785   
mul(
142fbbaab Harry Wentland 2015-11-25  2786   
bw_div(
142fbbaab Harry Wentland 2015-11-25  2787   
mul(
142fbbaab Harry Wentland 2015-11-25  2788   

results->display_bandwidth[k],

:: The code at line 2780 was first introduced by commit
:: 142fbbaab6655947879414a5a9730a6da12b7cf3 drm/amd/dal: Add dal display 
driver

:: TO: Harry Wentland 
:: CC: Alex Deucher 

---
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: 54172 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160616/e2db6c0d/attachment-0001.obj>

[Intel-gfx] [PATCH 06/14] drm: Extract drm_master_relase

[Daniel Vetter]

On Wed, Jun 15, 2016 at 12:43:11PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:01PM +0200, Daniel Vetter wrote:
> > Like with drm_master_open protect it with a check for primary_client
> > to make it clear that this can't happen on render/control nodes.
> > 
> > Signed-off-by: Daniel Vetter 
> Reviewed-by: Chris Wilson 

Merged up to this one here to drm-misc, thanks for the review. I'll resend
the remaining ones anew, there's a trickle of small conflicts due to the
leak fix.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3 05/10] drm/rockchip: analogix_dp: add rk3399 eDP support

[Yakir Yang]

Tomasz,

On 06/15/2016 05:25 PM, Tomasz Figa wrote:
> Hi Yakir,
>
> Yakir Yang  rock-chips.com> writes:
Required properties:
 -- compatible: "rockchip,rk3288-edp";
 +- compatible: "rockchip,rk3288-edp",
 + "rockchip,rk3399-edp";
>>> As commented by Tomasz on gerrit, there is a pre-existing typo here.
>>> Specifically "rockchip,rk3288-edp" should be "rockchip,rk3288-dp".
>>>
>>> The typo is pre-existing so I'm not sure you would need to spin this
>>> series to fix it, but if you were spinning it anyway it wouldn't hurt
>>> to fix.  Could also just send out a followon patch to fix this after
>>> the series lands...
>> My bad, forget to fix that :(
>> it would be better to merge that fix into this series, would send a
>> follow patch soon.
> No need to respin the whole series just for this typo. It's better to fix it
> in a separate patch later at this point, especially since this revision of
> the series looks quite good.

Okay,

BR,
- Yakir

> Best regards,
> Tomasz
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/10]

[Yakir Yang]

Tomasz,

On 06/15/2016 05:27 PM, Tomasz Figa wrote:
> Hi Yakir,
>
> Yakir Yang  rock-chips.com> writes:
>> RK3399 and RK3288 shared the same eDP IP controller, only some light
>> difference with VOP configure and GRF configure.
>>
>> Also same misc fix to analogix_dp driver:
>> - Hotplug invalid which report by Dan Carpenter
>> - Make panel detect to an optional action
>> - correct the register bit define error in ANALOGIX_DP_PLL_REG_1
> This version looks good to me. For all patches in the series:
>
> Reviewed-by: Tomasz Figa 

Thanks ;)

- Yakir

> Best regards,
> Tomasz
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel