[PATCH libdrm 7/8] Fix unused, and unused-but-set variables warnings

[Emil Velikov]

On 27 February 2015 at 18:07, Jan Vesely  wrote:
> Signed-off-by: Jan Vesely 
> ---
>  tests/exynos/exynos_fimg2d_test.c | 4 +---
>  xf86drm.c | 9 ++---
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
...
> @@ -333,7 +336,6 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
> drm_server_info->get_perms(_group, _mode);
> devmode  = serv_mode ? serv_mode : DRM_DEV_MODE;
> devmode &= ~(S_IXUSR|S_IXGRP|S_IXOTH);
> -   group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
>  }
>
>  #if !defined(UDEV)
> @@ -354,6 +356,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
>  }
>
>  if (drm_server_info) {
> +   group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
I think you can leave this back where it was. It doesn't seem to bring
anything beneficial.

-Emil

[PATCH] nouveau: add coherent BO attribute

[Maarten Lankhorst]

Hey,

Op 13-03-15 om 07:27 schreef Alexandre Courbot:
> Add a flag allowing Nouveau to specify that an object should be coherent
> at allocation time. This is required for some class of objects like
> fences which are randomly-accessed by both the CPU and GPU. This flag
> instructs the kernel driver to make sure the object remains coherent
> even on architectures for which coherency is not guaranteed by the bus.
> 
> Signed-off-by: Alexandre Courbot 
I don't see a problem with this patch, but similar patches to intel to libdrm 
have been shot down when the changes weren't in an official kernel yet, so I 
think this should wait until the change is at least in drm-next. ;-)

[PATCH libdrm 0/8] Warnings fixes

[Jan Vesely]

On Fri, 2015-03-13 at 23:20 +, Emil Velikov wrote:
> Hi Jan,
> 
> On 27 February 2015 at 22:27, Emil Velikov  
> wrote:
> > On 27/02/15 18:07, Jan Vesely wrote:
> >> His series fixes most of the warnings my compiler spits out running
> >> make distcheck.
> >> Most of the changes do not change behaviour and those the do are in 
> >> separate
> >> patches.
> > Nicely done Jan. If you don't mind I would prefer if Theirry's series
> > lands first as it will clash with some of the patches in tests.
> >
> Seems that Thierry's quite busy so I've went ahead and sent over a few
> comments. I'm not planning to look at the patch #4, but the rest look
> great. With the comments addressed feel free to add
> 
> Reviewed-by: Emil Velikov 

Thank you for finding time to review these. I'll start pushing the
reviewed ones tomorrow, and send v2 of the 3 you commented on.


jan


> 
> Thierry, just realised that I've made a mistake writing your name last
> time. Sincerest of apologies, it was not intentional.
> 
> Cheers,
> Emil

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/ce223df8/attachment.sig>

[PATCH libdrm 1/8] Add static qualifier to local functions

[Jan Vesely]

On Fri, 2015-03-13 at 23:07 +, Emil Velikov wrote:
> On 27 February 2015 at 18:07, Jan Vesely  wrote:
> > Signed-off-by: Jan Vesely 
> > ---
> >  tests/drmstat.c |  8 
> >  tests/kmstest/main.c|  2 +-
> >  tests/modeprint/modeprint.c | 18 +-
> >  tests/proptest/proptest.c   |  2 +-
> >  tests/radeon/radeon_ttm.c   |  4 ++--
> >  xf86drm.c   |  2 +-
> >  xf86drmMode.c   |  2 +-
> >  7 files changed, 19 insertions(+), 19 deletions(-)
> >
> > diff --git a/tests/drmstat.c b/tests/drmstat.c
> > index 5935d07..36cc70d 100644
> > --- a/tests/drmstat.c
> > +++ b/tests/drmstat.c
> > @@ -81,13 +81,13 @@ static void getversion(int fd)
> > printf( "No driver available\n" );
> >  }
> >  }
> > -
> > -void handler(int fd, void *oldctx, void *newctx)
> > +
> > +static void handler(int fd, void *oldctx, void *newctx)
> >  {
> >  printf("Got fd %d\n", fd);
> >  }
> >
> It's only "user" was commented out as a transition to libdrm2 afaict.
> Should be safe to nuke alongside the commented out caller.

This one got commented out in 8/8 if you prefer I can nuke it, and apply
8/8 before this one.

> 
> > -void process_sigio(char *device)
> > +static void process_sigio(char *device)
> >  {
> >  int  fd;
> >
> > @@ -427,7 +427,7 @@ int main(int argc, char **argv)
> >  return r;
> >  }
> >
> > -void DRM_PRINTFLIKE(4, 0)
> > +static void DRM_PRINTFLIKE(4, 0)
> >  xf86VDrvMsgVerb(int scrnIndex, int type, int verb, const char *format,
> >  va_list args)
> Think don't need to bother making this static and just nuke it. It
> seems like it was added by mistake (commit c3092ead642) and never
> used.

same here. it is removed in 8/8 I can reorder the patches tog et rid of
this artifact

> 
> ...
> > diff --git a/xf86drm.c b/xf86drm.c
> > index e117bc6..016247f 100644
> > --- a/xf86drm.c
> > +++ b/xf86drm.c
> > @@ -131,7 +131,7 @@ drmMsg(const char *format, ...)
> >  }
> >  }
> >
> > -void
> > +static void
> >  drmSetDebugMsgFunction(debug_msg_func_t debug_msg_ptr)
> >  {
> >  drm_debug_print = debug_msg_ptr;
> > diff --git a/xf86drmMode.c b/xf86drmMode.c
> > index 9ea8fe7..1c06a19 100644
> > --- a/xf86drmMode.c
> > +++ b/xf86drmMode.c
> > @@ -76,7 +76,7 @@ static inline int DRM_IOCTL(int fd, unsigned long cmd, 
> > void *arg)
> >   * Util functions
> >   */
> >
> > -void* drmAllocCpy(void *array, int count, int entry_size)
> > +static void* drmAllocCpy(void *array, int count, int entry_size)
> Strictly speaking these could still be used, despite never being part
> of the API. Although my vote (fwiw) would be to that we're safe.

This one is heavily used in the same file.

> 
> Cheers,
> Emil

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/bc04f98c/attachment-0001.sig>

[PATCH libdrm 7/8] Fix unused, and unused-but-set variables warnings

[Jan Vesely]

On Fri, 2015-03-13 at 22:56 +, Emil Velikov wrote:
> On 27 February 2015 at 18:07, Jan Vesely  wrote:
> > Signed-off-by: Jan Vesely 
> > ---
> >  tests/exynos/exynos_fimg2d_test.c | 4 +---
> >  xf86drm.c | 9 ++---
> >  2 files changed, 7 insertions(+), 6 deletions(-)
> >
> ...
> > @@ -333,7 +336,6 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
> > drm_server_info->get_perms(_group, _mode);
> > devmode  = serv_mode ? serv_mode : DRM_DEV_MODE;
> > devmode &= ~(S_IXUSR|S_IXGRP|S_IXOTH);
> > -   group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> >  }
> >
> >  #if !defined(UDEV)
> > @@ -354,6 +356,7 @@ static int drmOpenDevice(dev_t dev, int minor, int type)
> >  }
> >
> >  if (drm_server_info) {
> > +   group = (serv_group >= 0) ? serv_group : DRM_DEV_GID;
> I think you can leave this back where it was. It doesn't seem to bring
> anything beneficial.

"group" variable is now only available #if !defined(UDEV), so  I can;'t
really move it back without adding a pair of ifdefs,
moving it here looked nicer than adding another set of #if/#endif.

I wanted to move the declaration here as well, but I'm not sure how it'd
play with old/broken compilers that need to be supported.

jan

> 
> -Emil

-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/8cf0c582/attachment.sig>

[PATCH 2/2] drm/exynos: fix the initialization order in FIMD

[Inki Dae]

On 2015년 03월 12일 13:36, Hyungwon Hwang wrote:
> Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos:
> fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
> called when is_drm_iommu_supported() returns true. In this case,
> the kernel is going to be panicked because crtc is not set yet.

Nice catch!!!

> 
> [1.211156] [drm] Initialized drm 1.1.0 20060810
> [1.216785] Unable to handle kernel NULL pointer dereference at virtual 
> address 0350
> [1.223415] pgd = c0004000
> [1.226086] [0350] *pgd=
> [1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [1.234940] Modules linked in:
> [1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 
> 4.0.0-rc1-00062-g7a7cc79-dirty #123
> [1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [1.252214] task: ee8c8000 ti: ee8d task.ti: ee8d
> [1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8
> [1.262370] LR is at fimd_bind+0x138/0x1a8
> [1.266450] pc : []lr : []psr: 2113
> [1.266450] sp : ee8d1d28  ip :   fp : 
> [1.277906] r10: 0001  r9 : c09d693c  r8 : c0a2d6a8
> [1.283114] r7 : 0034  r6 : 0001  r5 : ee0bb400  r4 : ee244c10
> [1.289624] r3 :   r2 :   r1 : 0001  r0 : 
> [1.296135] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kernel
> [1.303426] Control: 10c5387d  Table: 4000404a  DAC: 0015
> [1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210)
> [1.315143] Stack: (0xee8d1d28 to 0xee8d2000)
> [1.319486] 1d20:    c0113d18 ee0bb400 ee0bb400 
> ee245c30 eebbe210
> [1.327645] 1d40: ee008a40 ee244c10 ee0bb400 0001 0034 c02fb834 
>  c030a858
> [1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 
>  
> [1.343963] 1d80: ee244a10 ee0bb400  eeb60740 eeb60810  
>  c02f6ba4
> [1.352123] 1da0: ee0bb400   c02e0500 ee244a00 c0a04a14 
> ee0bb400 c02e1de4
> [1.360282] 1dc0:  c030a858 0002 eeb60820 eeb60820 0002 
> eeb60780 c03033d4
> [1.368441] 1de0: c06e9cec  ee244a10 eeb60780 c0a056f8 c03035fc 
> c0a04b24 c0a04b24
> [1.376600] 1e00: ee244a10 0001 c0a049d0 c02f6d34 c0ad462c eeba0790 
>  ee244a10
> [1.384759] 1e20: ffed c0a049d0  c03090b0 ee244a10 c0ad462c 
> c0a2d840 c03077a0
> [1.392919] 1e40: eeb5e880 c024b738 08db ee244a10 c0a049d0 ee244a44 
>  c09e71d8
> [1.401078] 1e60: 00c6 c0307a6c c0a049d0  c03079e0 c0305ea8 
> ee826e5c ee1dc7b4
> [1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 
> c06e9d10 c0a049d0
> [1.417396] 1ea0: c06e9d10 c0ad4600  c0308360  0003 
> c06e9d10 c02f6e14
> [1.42] 1ec0:  c0896204     
>  
> [1.433714] 1ee0:   c02f6d5c c02f6d5c  eeb5d740 
> c09e71d8 c0008a30
> [1.441874] 1f00: ef7fca5e   0066  ee8d1f28 
> c003ff1c c02514e8
> [1.450033] 1f20: 6113  c093906c ef7fca5e 00c6 c004018c 
>  c093906c
> [1.458192] 1f40: c08a9690 c093840c 0006 0006 c09eb2ac c09c0d74 
> 0006 c09c0d54
> [1.466351] 1f60: c0a3d680 c09745a0 c09d693c 00c6  c0974db4 
> 0006 0006
> [1.474510] 1f80: c09745a0   c0692e00   
>  
> [1.482669] 1fa0:  c0692e08  c000f040   
>  
> [1.490828] 1fc0:       
>  
> [1.498988] 1fe0:     0013  
>  
> [1.507159] [] (fimd_wait_for_vblank) from [] 
> (fimd_bind+0x138/0x1a8)
> [1.515313] [] (fimd_bind) from [] 
> (component_bind_all+0xc4/0x20c)
> [1.523209] [] (component_bind_all) from [] 
> (exynos_drm_load+0xa0/0x140)
> [1.531632] [] (exynos_drm_load) from [] 
> (drm_dev_register+0xa0/0xf4)
> [1.539788] [] (drm_dev_register) from [] 
> (drm_platform_init+0x44/0xcc)
> [1.548121] [] (drm_platform_init) from [] 
> (try_to_bring_up_master.part.1+0xc8/0x104)
> [1.557668] [] (try_to_bring_up_master.part.1) from [] 
> (component_master_add_with_match+0xd0/0x118)
> [1.568431] [] (component_master_add_with_match) from 
> [] (exynos_drm_platform_probe+0xf0/0x118)
> [1.578847] [] (exynos_drm_platform_probe) from [] 
> (platform_drv_probe+0x48/0x98)
> [1.588052] [] (platform_drv_probe) from [] 
> (driver_probe_device+0x140/0x380)
> [1.596902] [] (driver_probe_device) from [] 
> (__driver_attach+0x8c/0x90)
> [1.605321] [] (__driver_attach) from [] 
> (bus_for_each_dev+0x54/0x88)
> [1.613480] [] (bus_for_each_dev) from [] 
> (bus_add_driver+0xec/0x200)
> [1.621640] [] 

[PATCH 4/4] drm/msm/mdp5: Enable DSI connector in msm drm driver

[Hai Li]

This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 268 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  69 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  12 +-
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 6 files changed, 353 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 6c467fb..2c9a9dc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -68,6 +68,8 @@ const struct mdp5_cfg_hw msm8x74_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 2,
@@ -125,6 +127,8 @@ const struct mdp5_cfg_hw apq8084_config = {
},
.intfs = {
[0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
[3] = INTF_HDMI,
},
.max_clk = 32000,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 9b38cde..f877e1d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -626,7 +626,16 @@ void mdp5_crtc_set_intf(struct drm_crtc *crtc, struct 
mdp5_interface *intf)

/* now that we know what irq's we want: */
mdp5_crtc->err.irqmask = intf2err(intf->num);
-   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
+
+   /* Register command mode Pingpong done as vblank for now,
+* so that atomic commit should wait for it to finish.
+* Ideally, in the future, we should take rd_ptr done as vblank,
+* and let atomic commit wait for pingpong done for commond mode.
+*/
+   if (intf->mode == MDP5_INTF_DSI_MODE_COMMAND)
+   mdp5_crtc->vblank.irqmask = lm2ppdone(lm);
+   else
+   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
mdp_irq_update(_kms->base);

mdp5_ctl_set_intf(mdp5_crtc->ctl, intf);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index a17eb9c..efe7aaf 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -98,6 +98,221 @@ static void bs_fini(struct mdp5_encoder *mdp5_encoder) {}
 static void bs_set(struct mdp5_encoder *mdp5_encoder, int idx) {}
 #endif

+/*
+ * Command mode encoder, used by DSI command mode path.
+ * Should move to a separate file, once global bandwidth
+ * functions are available.
+ */
+#define VSYNC_CLK_RATE 1920
+static int pingpong_tearcheck_setup(struct drm_encoder *encoder,
+   struct drm_display_mode *mode)
+{
+   struct mdp5_kms *mdp5_kms = get_kms(encoder);
+   struct device *dev = encoder->dev->dev;
+   u32 total_lines_x100, vclks_line, cfg;
+   long vsync_clk_speed;
+   int pp_id = GET_PING_PONG_ID(mdp5_crtc_get_lm(encoder->crtc));
+
+   if (IS_ERR_OR_NULL(mdp5_kms->vsync_clk)) {
+   dev_err(dev, "vsync_clk is not initialized\n");
+   return -EINVAL;
+   }
+
+   total_lines_x100 = mode->vtotal * mode->vrefresh;
+   if (!total_lines_x100) {
+   dev_err(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n",
+   __func__, mode->vtotal, mode->vrefresh);
+   return -EINVAL;
+   }
+
+   vsync_clk_speed = clk_round_rate(mdp5_kms->vsync_clk, VSYNC_CLK_RATE);
+   if (vsync_clk_speed <= 0) {
+   dev_err(dev, "vsync_clk round rate failed %ld\n",
+   vsync_clk_speed);
+   return -EINVAL;
+   }
+   vclks_line = vsync_clk_speed * 100 / total_lines_x100;
+
+   cfg = MDP5_PP_SYNC_CONFIG_VSYNC_COUNTER_EN
+   | MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN;
+   cfg |= MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line);
+
+   mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg);
+   mdp5_write(mdp5_kms,
+   REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0);
+   mdp5_write(mdp5_kms,
+   REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_START_POS(pp_id), mode->vdisplay);
+   mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id),
+   MDP5_PP_SYNC_THRESH_START(4) |
+   MDP5_PP_SYNC_THRESH_CONTINUE(4));
+
+   return 0;
+}
+
+static int pingpong_tearcheck_enable(struct 

[PATCH 3/4] drm/msm: Initial add DSI connector support

[Hai Li]

This change adds the DSI connector support in msm drm driver.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Kconfig   |   11 +
 drivers/gpu/drm/msm/Makefile  |4 +
 drivers/gpu/drm/msm/dsi/dsi.c |  203 
 drivers/gpu/drm/msm/dsi/dsi.h |  115 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 1997 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  706 
 drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
 drivers/gpu/drm/msm/msm_drv.h |   20 +
 8 files changed, 3408 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
  Compile in support for logging register reads/writes in a format
  that can be parsed by envytools demsm tool.  If enabled, register
  logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+   bool "Enable DSI support in MSM DRM driver"
+   depends on DRM_MSM
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   default y
+   help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_host.o \
+   dsi/dsi_manager.o \
+   dsi/dsi_phy.o

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..de77260
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2015, 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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi.h"
+
+int msm_dsi_modeset_init(struct msm_drm_sub_dev *base, struct drm_device *dev)
+{
+   struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
+   struct msm_drm_private *priv = dev->dev_private;
+   int ret, i;
+
+   if (WARN_ON((base->num_encoders != MSM_DSI_ENCODER_NUM) ||
+   !base->encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
+   !base->encoders[MSM_DSI_CMD_ENCODER_ID]))
+   return -EINVAL;
+
+   msm_dsi->dev = dev;
+
+   ret = msm_dsi_host_modeset_init(msm_dsi->host, dev);
+   if (ret) {
+   dev_err(dev->dev, "failed to modeset init host: %d\n", ret);
+   goto fail;
+   }
+
+   msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
+   if (IS_ERR(msm_dsi->bridge)) {
+   ret = PTR_ERR(msm_dsi->bridge);
+   dev_err(dev->dev, "failed to create dsi bridge: %d\n", ret);
+   msm_dsi->bridge = NULL;
+   goto fail;
+   }
+
+   msm_dsi->connector = msm_dsi_manager_connector_init(msm_dsi->id);
+   if (IS_ERR(msm_dsi->connector)) {
+   ret = PTR_ERR(msm_dsi->connector);
+   dev_err(dev->dev, "failed to create dsi connector: %d\n", ret);
+   msm_dsi->connector = NULL;
+   goto fail;
+   }
+
+   for (i = 0; i < base->num_encoders; i++)
+   base->encoders[i]->bridge = msm_dsi->bridge;
+
+   priv->bridges[priv->num_bridges++]   = msm_dsi->bridge;
+   priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+
+   return 0;
+fail:
+   if (msm_dsi) {
+   /* bridge/connector are normally destroyed by drm: */
+   if (msm_dsi->bridge) {
+   msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
+   msm_dsi->bridge = NULL;
+   }
+   if (msm_dsi->connector) {
+   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
+   msm_dsi->connector = NULL;
+   }
+   }
+
+   return ret;
+}
+
+static void dsi_destroy(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi)
+   return;

[PATCH 2/4] drm/msm: Add split display interface

[Hai Li]

This change is to add an interface to MDP for connector devices
setting split display information.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/msm_kms.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 3a78cb4..a9f17bd 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -47,6 +47,10 @@ struct msm_kms_funcs {
const struct msm_format *(*get_format)(struct msm_kms *kms, uint32_t 
format);
long (*round_pixclk)(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder);
+   int (*set_split_display)(struct msm_kms *kms,
+   struct drm_encoder *encoder,
+   struct drm_encoder *slave_encoder,
+   bool is_cmd_mode);
/* cleanup: */
void (*preclose)(struct msm_kms *kms, struct drm_file *file);
void (*destroy)(struct msm_kms *kms);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/4] drm/msm/dsi: Update generated DSI header file

[Hai Li]

Prepare for initial DSI implementation

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 418 ++
 1 file changed, 376 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index abf1bba..1dcfae2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -8,19 +8,10 @@ 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 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20908 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
27208 bytes, from 2015-01-13 23:56:11)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
26848 bytes, from 2015-01-13 23:55:57)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (   
8253 bytes, from 2014-12-08 16:13:00)
-
-Copyright (C) 2013 by the following authors:
+- /usr2/hali/local/envytools/envytools/rnndb/dsi/dsi.xml (  18681 
bytes, from 2015-03-04 23:08:31)
+- /usr2/hali/local/envytools/envytools/rnndb/freedreno_copyright.xml (   1453 
bytes, from 2015-01-28 21:43:22)
+
+Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)

 Permission is hereby granted, free of charge, to any person obtaining
@@ -51,11 +42,11 @@ enum dsi_traffic_mode {
BURST_MODE = 2,
 };

-enum dsi_dst_format {
-   DST_FORMAT_RGB565 = 0,
-   DST_FORMAT_RGB666 = 1,
-   DST_FORMAT_RGB666_LOOSE = 2,
-   DST_FORMAT_RGB888 = 3,
+enum dsi_vid_dst_format {
+   VID_DST_FORMAT_RGB565 = 0,
+   VID_DST_FORMAT_RGB666 = 1,
+   VID_DST_FORMAT_RGB666_LOOSE = 2,
+   VID_DST_FORMAT_RGB888 = 3,
 };

 enum dsi_rgb_swap {
@@ -69,20 +60,63 @@ enum dsi_rgb_swap {

 enum dsi_cmd_trigger {
TRIGGER_NONE = 0,
+   TRIGGER_SEOF = 1,
TRIGGER_TE = 2,
TRIGGER_SW = 4,
TRIGGER_SW_SEOF = 5,
TRIGGER_SW_TE = 6,
 };

+enum dsi_cmd_dst_format {
+   CMD_DST_FORMAT_RGB111 = 0,
+   CMD_DST_FORMAT_RGB332 = 3,
+   CMD_DST_FORMAT_RGB444 = 4,
+   CMD_DST_FORMAT_RGB565 = 6,
+   CMD_DST_FORMAT_RGB666 = 7,
+   CMD_DST_FORMAT_RGB888 = 8,
+};
+
+enum dsi_lane_swap {
+   LANE_SWAP_0123 = 0,
+   LANE_SWAP_3012 = 1,
+   LANE_SWAP_2301 = 2,
+   LANE_SWAP_1230 = 3,
+   LANE_SWAP_0321 = 4,
+   LANE_SWAP_1032 = 5,
+   LANE_SWAP_2103 = 6,
+   LANE_SWAP_3210 = 7,
+};
+
 #define DSI_IRQ_CMD_DMA_DONE   0x0001
 #define DSI_IRQ_MASK_CMD_DMA_DONE  0x0002
 #define DSI_IRQ_CMD_MDP_DONE   0x0100
 #define DSI_IRQ_MASK_CMD_MDP_DONE  0x0200
 #define DSI_IRQ_VIDEO_DONE 0x0001
 #define DSI_IRQ_MASK_VIDEO_DONE
0x0002
+#define DSI_IRQ_BTA_DONE   0x0010
+#define DSI_IRQ_MASK_BTA_DONE  0x0020
 #define DSI_IRQ_ERROR  0x0100
 #define DSI_IRQ_MASK_ERROR 0x0200
+#define REG_DSI_6G_HW_VERSION  0x
+#define DSI_6G_HW_VERSION_MAJOR__MASK  0xf000
+#define DSI_6G_HW_VERSION_MAJOR__SHIFT 28
+static inline uint32_t DSI_6G_HW_VERSION_MAJOR(uint32_t val)
+{
+   return ((val) << DSI_6G_HW_VERSION_MAJOR__SHIFT) & 
DSI_6G_HW_VERSION_MAJOR__MASK;
+}
+#define DSI_6G_HW_VERSION_MINOR__MASK  0x0fff
+#define DSI_6G_HW_VERSION_MINOR__SHIFT 16
+static inline uint32_t DSI_6G_HW_VERSION_MINOR(uint32_t val)
+{
+   return ((val) << DSI_6G_HW_VERSION_MINOR__SHIFT) & 
DSI_6G_HW_VERSION_MINOR__MASK;
+}
+#define DSI_6G_HW_VERSION_STEP__MASK   0x
+#define DSI_6G_HW_VERSION_STEP__SHIFT  0
+static inline 

[PATCH 0/4] drm/msm: Initial add DSI support

[Hai Li]

DSI is supported by both mdp4 and mdp5. This patch series adds the common DSI
controller driver and also enable it in mdp5.

Hai Li (4):
  drm/msm/dsi: Update generated DSI header file
  drm/msm: Add split display interface
  drm/msm: Initial add DSI connector support
  drm/msm/mdp5: Enable DSI connector in msm drm driver

 drivers/gpu/drm/msm/Kconfig |   11 +
 drivers/gpu/drm/msm/Makefile|4 +
 drivers/gpu/drm/msm/dsi/dsi.c   |  203 +++
 drivers/gpu/drm/msm/dsi/dsi.h   |  115 ++
 drivers/gpu/drm/msm/dsi/dsi.xml.h   |  418 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c  | 1997 +++
 drivers/gpu/drm/msm/dsi/dsi_manager.c   |  706 ++
 drivers/gpu/drm/msm/dsi/dsi_phy.c   |  352 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |4 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|   11 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  268 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |   69 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   12 +-
 drivers/gpu/drm/msm/msm_drv.c   |2 +
 drivers/gpu/drm/msm/msm_drv.h   |   20 +
 drivers/gpu/drm/msm/msm_kms.h   |4 +
 16 files changed, 4141 insertions(+), 55 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

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

[PATCH] rnndb: Update DSI core and PHY registers for 8084

[Hai Li]

DSI core registers in DSI6G are compatible with the old versions.
The offsets are 4-byte shift down because of the addition of a
HW_VERSION register. This difference will be handled in source code.

DSI PHY registers are incompatible. This change adds a new domain
for 28nm PHY and PHY regulator, which are used in 8084 and some other
chips.

Signed-off-by: Hai Li 
---
 rnndb/dsi/dsi.xml | 212 --
 1 file changed, 191 insertions(+), 21 deletions(-)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index 19898e1..480ec46 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -10,11 +10,11 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
+   
+   
+   
+   
+   



@@ -26,11 +26,30 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   





+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   



@@ -38,10 +57,18 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   




+   
+   
+   
+   
+   
+



@@ -56,15 +83,20 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   

+   

  
+   


-   
+   
+   
+   

  

-   
+   



@@ -74,11 +106,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
+   
+   
+   
+   



@@ -96,27 +127,53 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   
+   
+   





+   



-   
-   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   


+   
+   
+   
+   
+   
+   
+   
+   
+   





-   
-   
-   
+   
+   
+   
+   



@@ -130,12 +187,34 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   



-   
-   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   



@@ -272,4 +351,95 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">

 

+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+
+   
+   
+   
+   
+   
+
+   
+   
+
+   
+   
+   
+   
+   
+   
+
+   
+   
+
+
+
+   
+   
+   
+   
+   
+   
+   
+
+
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code 

[PATCH 1/2] drm/exynos: add more condition to check iommu support

[Inki Dae]

On 2015년 03월 12일 13:36, Hyungwon Hwang wrote:
> Checking whether the iommu mapping allocated is not enough to determine
> whether iommu is supported properly or not. Even though there is mapping,
> the kernel is going to be panicked without the iommu being allocated.
> So this patch adds the additional condition to check whether iommu is
> really supported or not.
> 
> [0.960859] [drm] Initialized drm 1.1.0 20060810
> [1.016344] [ cut here ]
> [1.016453] kernel BUG at drivers/iommu/exynos-iommu.c:481!
> [1.020877] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [1.026693] Modules linked in:
> [1.029736] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
> 4.0.0-rc1-00089-gb7abcc2-dirty #13
> [1.037802] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [1.043880] task: db0c ti: db0a6000 task.ti: db0a6000
> [1.049268] PC is at __exynos_sysmmu_enable+0x188/0x214
> [1.054470] LR is at exynos_iommu_attach_device+0x44/0x118
> [1.059940] pc : []lr : []psr: 6193
> [1.059940] sp : db0a7cd8  ip :   fp : 
> [1.071394] r10: a113  r9 :   r8 : db355f90
> [1.076603] r7 : db25b210  r6 : db355640  r5 :   r4 : 
> [1.083113] r3 :   r2 : db355640  r1 : 5b244000  r0 : db25b210
> [1.089624] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
> kernel
> [1.097001] Control: 10c5387d  Table: 4000406a  DAC: 0015
> [1.102729] Process swapper/0 (pid: 1, stack limit = 0xdb0a6210)
> [1.108719] Stack: (0xdb0a7cd8 to 0xdb0a8000)
> [1.113060] 7cc0:   
>  db355f80
> [1.121223] 7ce0:  db355640 db25b210 db355f90  a113 
>  c02bf1a0
> [1.129383] 7d00: a113 c0115974 00200200 5b244000 db25b210 db25b210 
> da822c10 db157800
> [1.137542] 7d20: c0846540  c07ea3f4 c02bc8e8 db25b210 db278b40 
> da822c10 c001eb48
> [1.145701] 7d40: da822e10 db25b210 da822c10 c02ef444 da822e10 0001 
> 0001 c02f0af4
> [1.153860] 7d60: da822e10 db2b0640 db2b25c0 db2b0640  c02f3850 
> db157800 
> [1.162019] 7d80: db157800   db278900  c02eb7d8 
> db157800 
> [1.170179] 7da0:  c08267b8  c02d4a44 c08e69f4 da822c00 
> db157800 c02d62c4
> [1.178337] 7dc0:  c07ea3f4  c02faf6c db2b07e0 db2b07e0 
> 0002 db2b0640
> [1.186497] 7de0: db2b07d0 c02f33f0 db2b0640  c0827130 c05a5230 
> da822c10 c02f34dc
> [1.194656] 7e00: c08268c8 da822c10 0001 c08268c8 c0826774 c02eb97c 
> da822c10 da8c0cd0
> [1.202815] 7e20:  c08e6ab0 da822c10 c0826774 fdfb c02f9acc 
> c08e6ab0 da822c10
> [1.210974] 7e40: c08466d8  c0826774 c02f7ea4 db2b8f80 c02491a0 
> db2b7a80 da822c10
> [1.219134] 7e60: c0826774 da822c44 c0827458 db2b7a80 007d c02f81cc 
>  c0826774
> [1.227293] 7e80: c02f8140 c02f61b0 db11205c db2b93b4 c0826774 db2b8f80 
>  c02f7540
> [1.235452] 7ea0: c070a3ac  c08e6a84 c0826774  c08e6a84 
>  c02f8a48
> [1.243611] 7ec0:   c08e6a84 c02eb6f0  c070a3ac 
>  
> [1.251770] 7ee0:       
> c08095a0 c08095a0
> [1.259930] 7f00: c02eb628 c0008a3c c0584ad4 c078395c 007d dfeff9b0 
>  dfeff9af
> [1.268089] 7f20:  db0a7f38 dfeffb46 dfeffb37 c0584ad4 c0040f40 
> 395c 
> [1.276248] 7f40: c0716918 dfeffb57 0006 0006 c080d618 dfeff980 
> c07fee24 0006
> [1.284408] 7f60: c07ea3ec c0851c80 c0851c80 007d c07ea3f4 c07aee28 
> 0006 0006
> [1.292566] 7f80: c07ae5ac c0047e88 1c80 c03c   
>  
> [1.300725] 7fa0:  c048  c000f390   
>  
> [1.308884] 7fc0:       
>  
> [1.317044] 7fe0:     0013  
>  ffdf
> [1.325220] [] (__exynos_sysmmu_enable) from [] 
> (exynos_iommu_attach_device+0x44/0x118)
> [1.334928] [] (exynos_iommu_attach_device) from [] 
> (iommu_attach_device+0x1c/0xc8)
> [1.344305] [] (iommu_attach_device) from [] 
> (arm_iommu_attach_device+0x18/0x50)
> [1.353420] [] (arm_iommu_attach_device) from [] 
> (drm_iommu_attach_device+0x4c/0xcc)
> [1.362880] [] (drm_iommu_attach_device) from [] 
> (fimd_bind+0x124/0x198)
> [1.371298] [] (fimd_bind) from [] 
> (component_bind_all+0xc4/0x228)
> [1.379195] [] (component_bind_all) from [] 
> (exynos_drm_load+0xa0/0x148)
> [1.387618] [] (exynos_drm_load) from [] 
> (drm_dev_register+0xa8/0x104)
> [1.395864] [] (drm_dev_register) from [] 
> (drm_platform_init+0x44/0xdc)
> [1.404195] [] (drm_platform_init) from [] 
> 

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Michel Dänzer]

On 13.03.2015 18:11, Daniel Vetter wrote:
> On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
>> On 12.03.2015 06:14, Alex Deucher wrote:
>>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
>>> wrote:
 On Wed, Mar 11, 2015 at 2:21 PM, Christian König
  wrote:
> On 11.03.2015 16:44, Alex Deucher wrote:
>>
>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>> uses the ttm bo size to determine when to select top down
>> allocation but since the ttm bo is not initialized yet the
>> check is always false.
>>
>> Noticed-by: Oded Gabbay 
>> Signed-off-by: Alex Deucher 
>> Cc: stable at vger.kernel.org
>
>
> And I was already wondering why the heck the BOs always made this 
> ping/pong
> in memory after creation.
>
> Patch is Reviewed-by: Christian König 

 And fixing that promptly broke VCE due to vram location requirements.
 Updated patch attached.  Thoughts?
>>>
>>> And one more take to make things a bit more explicit for static kernel
>>> driver allocations.
>>
>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>> problem is really that some BOs are expected to be within a certain
>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>> would be better to fix that by setting lpfn directly than indirectly via
>> RADEON_GEM_CPU_ACCESS.
>>
>>
>> Anyway, since this isn't the first bug which prevents
>> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>> wonder if its performance impact should be re-evaluated. Lauri?
> 
> Topdown allocation in drm_mm is just a hint/bias really, it won't try too
> hard to segregate things. If you depend upon perfect topdown allocation
> for correctness then this won't work well. The trouble starts once you've
> split your free space up - it's not going to look for the topmost hole
> first but still picks just the one on top of the stack.

TTM_PL_FLAG_TOPDOWN sets DRM_MM_SEARCH_BELOW as well as
DRM_MM_CREATE_TOP. So it should traverse the list of holes in reverse
order, right?


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

[PATCH] nouveau: add coherent BO attribute

[Alexandre Courbot]

On Fri, Mar 13, 2015 at 3:39 PM, Alexandre Courbot  wrote:
> On Fri, Mar 13, 2015 at 3:36 PM, Ilia Mirkin  wrote:
>> Doesn't this require a kernel version that has your other patch? What
>> happens when this runs on an older kernel? Does it get silently
>> ignored, or does it end up erroring out? If it errors out, that's
>> fine. Otherwise some sort of version check should be put in, no?
>
> The corresponding kernel patch is already merged in Ben's tree. If
> running with an older kernel, this flag will be a no-op, which is fine
> since GK20A's GPU (the reason for this patch as you have guessed :))
> is not enabled for these kernels.
>
> I am fine with adding a version check if you think it is necessary.

So as discussed on IRC, I will check the DRM version from Mesa. This
patch should be good to go - it will require a version increase in
libdrm though. Let me know if you want me to send a patch for this
too.

[PATCH 5/5] drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE requests

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

When an i2c WRITE gets an i2c defer or short i2c ack reply, we are
supposed to switch the request from I2C_WRITE to I2C_WRITE_STATUS_UPDATE
when we continue to poll for the completion of the request.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_dp_helper.c | 41 +
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d5368ea..4db81a6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -422,6 +422,25 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)
   I2C_FUNC_10BIT_ADDR;
 }

+static void drm_dp_i2c_msg_set_request(struct drm_dp_aux_msg *msg,
+  const struct i2c_msg *i2c_msg)
+{
+   msg->request = (i2c_msg->flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ : DP_AUX_I2C_WRITE;
+   msg->request |= DP_AUX_I2C_MOT;
+}
+
+static void drm_dp_i2c_msg_write_status_update(struct drm_dp_aux_msg *msg)
+{
+   /*
+* In case of i2c defer or short i2c ack reply to a write,
+* we need to switch to WRITE_STATUS_UPDATE to drain the
+* rest of the message
+*/
+   if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_I2C_WRITE)
+   msg->request |= DP_AUX_I2C_WRITE_STATUS_UPDATE;
+}
+
 /*
  * Transfer a single I2C-over-AUX message and handle various error conditions,
  * retrying the transaction as appropriate.  It is assumed that the
@@ -490,6 +509,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * Both native ACK and I2C ACK replies received. We
 * can assume the transfer was successful.
 */
+   if (ret != msg->size)
+   drm_dp_i2c_msg_write_status_update(msg);
return ret;

case DP_AUX_I2C_REPLY_NACK:
@@ -501,6 +522,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
DRM_DEBUG_KMS("I2C defer\n");
aux->i2c_defer_count++;
usleep_range(400, 500);
+   drm_dp_i2c_msg_write_status_update(msg);
continue;

default:
@@ -566,10 +588,7 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,

for (i = 0; i < num; i++) {
msg.address = msgs[i].addr;
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-   msg.request |= DP_AUX_I2C_MOT;
+   drm_dp_i2c_msg_set_request(, [i]);
/* Send a bare address packet to start the transaction.
 * Zero sized messages specify an address only (bare
 * address) transaction.
@@ -577,6 +596,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
msg.buffer = NULL;
msg.size = 0;
err = drm_dp_i2c_do_msg(aux, );
+
+   /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+   drm_dp_i2c_msg_set_request(, [i]);
+
if (err < 0)
break;
/* We want each transaction to be as large as possible, but
@@ -589,6 +615,13 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
msg.size = min(transfer_size, msgs[i].len - j);

err = drm_dp_i2c_drain_msg(aux, );
+
+   /*
+* Reset msg.request in case in case it got
+* changed into a WRITE_STATUS_UPDATE.
+*/
+   drm_dp_i2c_msg_set_request(, [i]);
+
if (err < 0)
break;
transfer_size = err;
-- 
2.0.5

[PATCH 4/5] drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.

Cc: Thierry Reding 
Cc: "Terje Bergström" 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tegra/dpaux.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index b1617af..a48687a 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -122,6 +122,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux,
 */
if (msg->size < 1) {
switch (msg->request & ~DP_AUX_I2C_MOT) {
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
case DP_AUX_I2C_WRITE:
case DP_AUX_I2C_READ:
value = DPAUX_DP_AUXCTL_CMD_ADDRESS_ONLY;
-- 
2.0.5

[PATCH 3/5] drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

Looks like radeon doesn't do anything special with the request type,
so hopefully just treating it the same as a i2c write is enough.

Cc: Alex Deucher 
Cc: "Christian König" 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8d74de8..9960b69 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -178,6 +178,7 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
/* The atom implementation only supports writes with a max 
payload of
 * 12 bytes since it uses 4 bits for the total count (header + 
payload)
 * in the parameter space.  The atom interface supports 16 byte
-- 
2.0.5

[PATCH 2/5] drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.

i915 doesn't try to interpret wht request type apart from separating
reads from writes, and so we should be able to treat this the same as
a normal i2c write.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 33d5877..aed5f26 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -956,6 +956,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
txsize = msg->size ? HEADER_SIZE + msg->size : 
BARE_ADDRESS_SIZE;
rxsize = 1;

-- 
2.0.5

[PATCH 1/5] drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
spec.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/tegra/dpaux.c | 2 +-
 include/drm/drm_dp_helper.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index d6b55e3..b1617af 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -152,7 +152,7 @@ static ssize_t tegra_dpaux_transfer(struct drm_dp_aux *aux,

break;

-   case DP_AUX_I2C_STATUS:
+   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
if (msg->request & DP_AUX_I2C_MOT)
value |= DPAUX_DP_AUXCTL_CMD_MOT_RQ;
else
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 523f04c..27301f5 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -46,7 +46,7 @@

 #define DP_AUX_I2C_WRITE   0x0
 #define DP_AUX_I2C_READ0x1
-#define DP_AUX_I2C_STATUS  0x2
+#define DP_AUX_I2C_WRITE_STATUS_UPDATE 0x2
 #define DP_AUX_I2C_MOT 0x4
 #define DP_AUX_NATIVE_WRITE0x8
 #define DP_AUX_NATIVE_READ 0x9
-- 
2.0.5

[PATCH 0/5] drm/dp: i2c-over-aux short write support

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

This series tries to implement support for short i2c-over-aux writes.

I did notice that my monitor (HP ZR24w) does support DDC/CI so I was
able to do some writes, but I only saw native defers instead of i2c
defers/short acks. So I've not actually been able to test this.

Another complication with DDC/CI seems to be that the monitor doesn't
seem to like the default 100kHz bus speed. I had to drop it to 10kHz
to make it reliable (my dongle supports bus speed control fortunately).
Currently we have no standard way to configure the bus speed AFAICS,
so at least with this monitor DDC/CI is a bit useless.

I tried to fix up radeon and tegra too. gma500 I left alone since it's
not using dp i2c helper.

Ville Syrjälä (5):
  drm/dp: s/I2C_STATUS/I2C_WRITE_STATUS_UPDATE/
  drm/i915: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
  drm/radeon: Handle DP_AUX_I2C_WRITE_STATUS_UPDATE
  drm/tegra: Handle I2C_WRITE_STATUS_UPDATE for address only writes
  drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial I2C_WRITE
requests

 drivers/gpu/drm/drm_dp_helper.c  | 42 
 drivers/gpu/drm/i915/intel_dp.c  |  1 +
 drivers/gpu/drm/radeon/atombios_dp.c |  1 +
 drivers/gpu/drm/tegra/dpaux.c|  3 ++-
 include/drm/drm_dp_helper.h  |  2 +-
 5 files changed, 43 insertions(+), 6 deletions(-)

-- 
2.0.5

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

[Daniel Vetter]

On Mon, Mar 09, 2015 at 08:10:06AM +0800, Zhigang Gong wrote:
> > -Original Message-
> > From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> > Jeff McGee
> > Sent: Saturday, March 7, 2015 2:44 AM
> > To: Zhigang Gong
> > Cc: daniel at ffwll.ch; intel-gfx at lists.freedesktop.org;
> > beignet at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> > Subject: Re: [Beignet] [PATCH] drm/i915: Export total subslice and EU counts
> > 
> > On Thu, Mar 05, 2015 at 12:35:55PM +0800, Zhigang Gong wrote:
> > > There is one minor conflict when apply the KMD patch to latest
> > > drm-intel-nightly branch. It should be easy to fix.
> > >
> > > Another issue is that IMO, we should bump libdrm's version number when
> > > increase these new APIs. Then in Beignet, we can check the libdrm
> > > version at build time and determine whether we will use these new
> > > interfaces. Thus, we can avoid breaking beignet on those systems which
> > > have previous libdrm/kernel installed.
> > >
> > Right. I can append a libdrm patch to bump the version. And then I suppose I
> > will follow the process to make a new release. Not sure right now how that
> > works. First time going through it.
> > 
> > Also, how should we test for the libdrm version and conditionally use the 
> > API?
> We can check the libdrm version at configuration time and define a macro to
> indicate whether we can use these new APIs in beignet.
> > Is there a previous example of this in Beignet that I could follow?
> Yes, one example is userptr. You can check the usage of DRM_INTEL_USERPTR and 
> HAS_USERPTR
> In beignet.

Ok, applied the kernel patch. Please go ahead with libdrm parts.

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

[Beignet] [Intel-gfx] [PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Daniel Vetter]

On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
> On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> > On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > > My only concern is about the following macros:
> > > 
> > > > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> > > > +#define LOCAL_I915_PARAM_EU_TOTAL34
> > > 
> > > How about to just use the definitons in the kernel header file?
> > > For an example:
> > > 
> > >   #include 
> > > 
> > >   #ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
> > >   //Put all the code into this block.
> > >   #endif
> > > 
> > > Then we can avoid put the same definitions in different files,
> > > and we can avoid unecessary testing on an old kernel which doesn't
> > > have this kernel interface.
> > > 
> > > For all the other part, it LGTM.
> > > 
> > > Reviewed-by: Zhigang Gong 
> > 
> > Once we update the libdrm requirements in igt we tend to go around and
> > replace all the now obsolete LOCAL_ defines. Imo not worth doing extra
> > work until then.
> > 
> > Patch applied, thanks.
> > -Daniel
> > 
> 
> Patch applied? Do you want me to make the name change first? Should the
> kernel part be reviewed and merged first?

Forgot my own review comment already ;-) Fixed up with a follow-up patch.
And I'll pull the kernel part in now too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/3] arm/dts/ls1021a: Add a TFT LCD panel dts node for DCU

[Jianwei Wang]

Add a required display-timings node for the TFT LCD panel
the TFT LCD panel is WQVGA "480x272", and the bpp is 24.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a-twr.dts | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a-twr.dts 
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..4780b11 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -58,6 +58,32 @@
};
 };

+ {
+   display = <>;
+   status = "okay";
+
+   display: display at 0 {
+   bits-per-pixel = <24>;
+
+   display-timings {
+   native-mode = <>;
+   timing0: nl4827hc19 {
+   clock-frequency = <1087>;
+   hactive = <480>;
+   vactive = <272>;
+   hback-porch = <2>;
+   hfront-porch = <2>;
+   vback-porch = <2>;
+   vfront-porch = <2>;
+   hsync-len = <41>;
+   vsync-len = <4>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
+   };
+};
+
  {
bus-num = <0>;
status = "okay";
-- 
2.1.0.27.g96db324

[PATCH 2/3] arm/dts/ls1021a: Add DCU dts node

[Jianwei Wang]

Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---
 arch/arm/boot/dts/ls1021a.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..ea83bdc 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
 <_clk 1>;
};

+   dcu: dcu at 2ce {
+   compatible = "fsl,dcu";
+   reg = <0x0 0x2ce 0x0 0x1>;
+   interrupts = ;
+   clocks = <_clk 0>;
+   clock-names = "dcu";
+   big-endian;
+   status = "disabled";
+   };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
-- 
2.1.0.27.g96db324

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

[Jianwei Wang]

This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on Freescale SoCs.

2D-ACE is a Freescale display controller. It provide an hardware
cursor.

This is a simplified version, only a primary plane, a fb created for
fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
encoder is not in use.

Signed-off-by: Alison Wang 
Signed-off-by: Xiubo Li 
Signed-off-by: Jianwei Wang 
---

Changed in v2: 
- Add atomic support
- Modify bindings file
- Rename node for compatibility
- Move platform related code out for compatibility

Added in v1: 
- Add support for DCU display controller on the Freescale LS102x SoCs.
- Create a primary plane, a fb created for fbdev, a crtc, a connector
for TFT LCD panel, an encoder.

 arch/arm/mach-imx/mach-ls1021a.c|  36 
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/fsl/Kconfig |  17 ++
 drivers/gpu/drm/fsl/Makefile|   8 +
 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c | 203 
 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h |  28 +++
 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c  | 164 
 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h  |  26 +++
 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c   | 288 
 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h   | 168 
 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c |  26 +++
 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c   |  42 
 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h   |  17 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c | 187 ++
 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h |  23 +++
 include/linux/fsl/dcu.h |  22 +++
 17 files changed, 1258 insertions(+)
 create mode 100644 drivers/gpu/drm/fsl/Kconfig
 create mode 100644 drivers/gpu/drm/fsl/Makefile
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_connector.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
 create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
 create mode 100644 include/linux/fsl/dcu.h

diff --git a/arch/arm/mach-imx/mach-ls1021a.c b/arch/arm/mach-imx/mach-ls1021a.c
index b89c858..4fb346d 100644
--- a/arch/arm/mach-imx/mach-ls1021a.c
+++ b/arch/arm/mach-imx/mach-ls1021a.c
@@ -8,9 +8,44 @@
  */

 #include 
+#include 
+#include 
+#include 
+#include 

 #include "common.h"

+void dcu_pixclk_disable(void)
+{
+   struct regmap *scfg_regmap;
+
+   scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
+   if (IS_ERR(scfg_regmap)) {
+   pr_err("No syscfg phandle specified\n");
+   return;
+   }
+
+   regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_DISABLE);
+}
+
+void dcu_pixclk_enable(void)
+{
+   struct regmap *scfg_regmap;
+
+   scfg_regmap = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
+   if (IS_ERR(scfg_regmap)) {
+   pr_err("No syscfg phandle specified\n");
+   return;
+   }
+
+   regmap_write(scfg_regmap, SCFG_PIXCLKCR, PXCK_ENABLE);
+}
+
+static void __init ls1021a_init_machine(void)
+{
+   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+   dcu_pixclk_enable();
+}
 static const char * const ls1021a_dt_compat[] __initconst = {
"fsl,ls1021a",
NULL,
@@ -18,5 +53,6 @@ static const char * const ls1021a_dt_compat[] __initconst = {

 DT_MACHINE_START(LS1021A, "Freescale LS1021A")
.smp= smp_ops(ls1021a_smp_ops),
+   .init_machine   = ls1021a_init_machine,
.dt_compat  = ls1021a_dt_compat,
 MACHINE_END
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..a6957aa 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -199,6 +199,8 @@ source "drivers/gpu/drm/bochs/Kconfig"

 source "drivers/gpu/drm/msm/Kconfig"

+source "drivers/gpu/drm/fsl/Kconfig"
+
 source "drivers/gpu/drm/tegra/Kconfig"

 source "drivers/gpu/drm/panel/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..ab5b9ef 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_ARMADA) += armada/
 obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
+obj-$(CONFIG_DRM_FSL_DCU) += fsl/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git 

[PATCH] drm: Silence sparse warnings

[Daniel Vetter]

On Fri, Mar 13, 2015 at 02:51:25PM +0200, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrjälä 
> 
> ../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was 
> not declared. Should it be static?
> ../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locked' was 
> not declared. Should it be static?
> ../drivers/gpu/drm/drm_vm.c:681:5: warning: symbol 'drm_vma_info' was not 
> declared. Should it be static?
> 
> ../drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was 
> not declared. Should it be static?
> ../drivers/gpu/drm/drm_pci.c:216:5: warning: symbol 'drm_irq_by_busid' was 
> not declared. Should it be static?
> 
> ../drivers/gpu/drm/drm_info.c:47:5: warning: symbol 'drm_name_info' was not 
> declared. Should it be static?
> ../drivers/gpu/drm/drm_info.c:72:5: warning: symbol 'drm_vm_info' was not 
> declared. Should it be static?
> ../drivers/gpu/drm/drm_info.c:116:5: warning: symbol 'drm_bufs_info' was not 
> declared. Should it be static?
> ../drivers/gpu/drm/drm_info.c:159:5: warning: symbol 'drm_clients_info' was 
> not declared. Should it be static?
> ../drivers/gpu/drm/drm_info.c:209:5: warning: symbol 'drm_gem_name_info' was 
> not declared. Should it be static?
> 
> ../drivers/gpu/drm/drm_ioc32.c:1019:20: warning: symbol 'drm_compat_ioctls' 
> was not declared. Should it be static?
> 
> ../drivers/gpu/drm/drm_bridge.c:52:12: warning: function 'drm_bridge_attach' 
> with external linkage has definition
> 
> Signed-off-by: Ville Syrjälä 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_bridge.c | 2 +-
>  drivers/gpu/drm/drm_info.c   | 1 +
>  drivers/gpu/drm/drm_ioc32.c  | 2 +-
>  drivers/gpu/drm/drm_pci.c| 1 +
>  drivers/gpu/drm/drm_vm.c | 1 +
>  5 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index d1187e5..eaa5790 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -49,7 +49,7 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> -extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
> *bridge)
> +int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
>  {
>   if (!dev || !bridge)
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
> index f1b32f9..cbb4fc0 100644
> --- a/drivers/gpu/drm/drm_info.c
> +++ b/drivers/gpu/drm/drm_info.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  
> +#include "drm_internal.h"
>  #include "drm_legacy.h"
>  
>  /**
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 2f4c4343..aa8bbb4 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -1016,7 +1016,7 @@ static int compat_drm_wait_vblank(struct file *file, 
> unsigned int cmd,
>   return 0;
>  }
>  
> -drm_ioctl_compat_t *drm_compat_ioctls[] = {
> +static drm_ioctl_compat_t *drm_compat_ioctls[] = {
>   [DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
>   [DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE32)] = compat_drm_getunique,
>   [DRM_IOCTL_NR(DRM_IOCTL_GET_MAP32)] = compat_drm_getmap,
> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
> index fd29f03..1b1bd42 100644
> --- a/drivers/gpu/drm/drm_pci.c
> +++ b/drivers/gpu/drm/drm_pci.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include "drm_internal.h"
>  #include "drm_legacy.h"
>  
>  /**
> diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
> index 4a2c328..aab49ee 100644
> --- a/drivers/gpu/drm/drm_vm.c
> +++ b/drivers/gpu/drm/drm_vm.c
> @@ -41,6 +41,7 @@
>  #include 
>  #endif
>  #include 
> +#include "drm_internal.h"
>  #include "drm_legacy.h"
>  
>  struct drm_vma_entry {
> -- 
> 2.0.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Daniel Vetter]

On Fri, Mar 13, 2015 at 06:46:33PM +0900, Michel Dänzer wrote:
> On 13.03.2015 18:11, Daniel Vetter wrote:
> > On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
> >> On 12.03.2015 06:14, Alex Deucher wrote:
> >>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
> >>> wrote:
>  On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>   wrote:
> > On 11.03.2015 16:44, Alex Deucher wrote:
> >>
> >> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> >> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
> >> uses the ttm bo size to determine when to select top down
> >> allocation but since the ttm bo is not initialized yet the
> >> check is always false.
> >>
> >> Noticed-by: Oded Gabbay 
> >> Signed-off-by: Alex Deucher 
> >> Cc: stable at vger.kernel.org
> >
> >
> > And I was already wondering why the heck the BOs always made this 
> > ping/pong
> > in memory after creation.
> >
> > Patch is Reviewed-by: Christian König 
> 
>  And fixing that promptly broke VCE due to vram location requirements.
>  Updated patch attached.  Thoughts?
> >>>
> >>> And one more take to make things a bit more explicit for static kernel
> >>> driver allocations.
> >>
> >> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> >> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> >> problem is really that some BOs are expected to be within a certain
> >> range from the beginning of VRAM, but lpfn isn't set accordingly. It
> >> would be better to fix that by setting lpfn directly than indirectly via
> >> RADEON_GEM_CPU_ACCESS.
> >>
> >>
> >> Anyway, since this isn't the first bug which prevents
> >> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
> >> wonder if its performance impact should be re-evaluated. Lauri?
> > 
> > Topdown allocation in drm_mm is just a hint/bias really, it won't try too
> > hard to segregate things. If you depend upon perfect topdown allocation
> > for correctness then this won't work well. The trouble starts once you've
> > split your free space up - it's not going to look for the topmost hole
> > first but still picks just the one on top of the stack.
> 
> TTM_PL_FLAG_TOPDOWN sets DRM_MM_SEARCH_BELOW as well as
> DRM_MM_CREATE_TOP. So it should traverse the list of holes in reverse
> order, right?

Sure that additional segregation helps a bit more, but in the end if you
split things badly and are a bit unlucky then the buffer can end up pretty
much anywhere. Just wanted to mention that in case someone gets confused
when the buffers end up in unexpected places.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Intel-gfx] [PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Daniel Vetter]

On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> My only concern is about the following macros:
> 
> > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> > +#define LOCAL_I915_PARAM_EU_TOTAL34
> 
> How about to just use the definitons in the kernel header file?
> For an example:
> 
>   #include 
> 
>   #ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
>   //Put all the code into this block.
>   #endif
> 
> Then we can avoid put the same definitions in different files,
> and we can avoid unecessary testing on an old kernel which doesn't
> have this kernel interface.
> 
> For all the other part, it LGTM.
> 
> Reviewed-by: Zhigang Gong 

Once we update the libdrm requirements in igt we tend to go around and
replace all the now obsolete LOCAL_ defines. Imo not worth doing extra
work until then.

Patch applied, thanks.
-Daniel

> 
> Thanks,
> Zhigang Gong.
> 
> On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mcgee at intel.com wrote:
> > From: Jeff McGee 
> > 
> > New test core_getparams consists of 2 subtests, each one testing
> > the ability of userspace to query the correct value of a GT config
> > attribute: subslice total or EU total. drm/i915 implementation of
> > these queries is required for Cherryview and Gen9+ devices (non-
> > simulated).
> > 
> > v2: Duplicate small amount of new libdrm functionality to avoid
> > bumping libdrm version requirement (Daniel). Convert some
> > igt_asserts to the appropriate comparison variants. Add a
> > test description.
> > v3: Actually use the LOCAL GETPARAM defines. Otherwise can't build
> > against older libdrm as intended by v2.
> > 
> > For: VIZ-4636
> > Signed-off-by: Jeff McGee 
> > ---
> >  tests/.gitignore   |   1 +
> >  tests/Makefile.sources |   1 +
> >  tests/core_getparams.c | 167 
> > +
> >  3 files changed, 169 insertions(+)
> >  create mode 100644 tests/core_getparams.c
> > 
> > diff --git a/tests/.gitignore b/tests/.gitignore
> > index 426cc67..c742308 100644
> > --- a/tests/.gitignore
> > +++ b/tests/.gitignore
> > @@ -1,6 +1,7 @@
> >  # Please keep sorted alphabetically
> >  core_get_client_auth
> >  core_getclient
> > +core_getparams
> >  core_getstats
> >  core_getversion
> >  drm_import_export
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 51e8376..999c8f8 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \
> >  
> >  TESTS_progs_M = \
> > core_get_client_auth \
> > +   core_getparams \
> > drv_suspend \
> > drv_hangman \
> > gem_bad_reloc \
> > diff --git a/tests/core_getparams.c b/tests/core_getparams.c
> > new file mode 100644
> > index 000..2855d06
> > --- /dev/null
> > +++ b/tests/core_getparams.c
> > @@ -0,0 +1,167 @@
> > +/*
> > + * Copyright © 2014 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + * Authors:
> > + *Jeff McGee 
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "drmtest.h"
> > +#include "intel_chipset.h"
> > +#include "intel_bufmgr.h"
> > +
> > +IGT_TEST_DESCRIPTION("Tests the export of parameters via 
> > DRM_IOCTL_I915_GETPARAM\n");
> > +
> > +int drm_fd;
> > +int devid;
> > +
> > +static void
> > +init(void)
> > +{
> > +   drm_fd = drm_open_any();
> > +   devid = intel_get_drm_devid(drm_fd);
> > +}
> > +
> > +static void
> > +deinit(void)
> > +{
> > +   close(drm_fd);
> > +}
> > +
> > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL33
> > +#define LOCAL_I915_PARAM_EU_TOTAL  34
> > +
> > +static int
> > +getparam(int param, int *value)
> > +{
> > +   drm_i915_getparam_t gp;
> > +   int ret;
> > +
> > +   memset(, 0, sizeof(gp));
> > +   gp.value = value;
> > +   gp.param = param;
> > +   ret 

[Intel-gfx] [PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Zhigang Gong]

My only concern is about the following macros:

> +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> +#define LOCAL_I915_PARAM_EU_TOTAL34

How about to just use the definitons in the kernel header file?
For an example:

  #include 

  #ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
  //Put all the code into this block.
  #endif

Then we can avoid put the same definitions in different files,
and we can avoid unecessary testing on an old kernel which doesn't
have this kernel interface.

For all the other part, it LGTM.

Reviewed-by: Zhigang Gong 

Thanks,
Zhigang Gong.

On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 
> 
> New test core_getparams consists of 2 subtests, each one testing
> the ability of userspace to query the correct value of a GT config
> attribute: subslice total or EU total. drm/i915 implementation of
> these queries is required for Cherryview and Gen9+ devices (non-
> simulated).
> 
> v2: Duplicate small amount of new libdrm functionality to avoid
> bumping libdrm version requirement (Daniel). Convert some
> igt_asserts to the appropriate comparison variants. Add a
> test description.
> v3: Actually use the LOCAL GETPARAM defines. Otherwise can't build
> against older libdrm as intended by v2.
> 
> For: VIZ-4636
> Signed-off-by: Jeff McGee 
> ---
>  tests/.gitignore   |   1 +
>  tests/Makefile.sources |   1 +
>  tests/core_getparams.c | 167 
> +
>  3 files changed, 169 insertions(+)
>  create mode 100644 tests/core_getparams.c
> 
> diff --git a/tests/.gitignore b/tests/.gitignore
> index 426cc67..c742308 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -1,6 +1,7 @@
>  # Please keep sorted alphabetically
>  core_get_client_auth
>  core_getclient
> +core_getparams
>  core_getstats
>  core_getversion
>  drm_import_export
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 51e8376..999c8f8 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \
>  
>  TESTS_progs_M = \
>   core_get_client_auth \
> + core_getparams \
>   drv_suspend \
>   drv_hangman \
>   gem_bad_reloc \
> diff --git a/tests/core_getparams.c b/tests/core_getparams.c
> new file mode 100644
> index 000..2855d06
> --- /dev/null
> +++ b/tests/core_getparams.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Jeff McGee 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "drmtest.h"
> +#include "intel_chipset.h"
> +#include "intel_bufmgr.h"
> +
> +IGT_TEST_DESCRIPTION("Tests the export of parameters via 
> DRM_IOCTL_I915_GETPARAM\n");
> +
> +int drm_fd;
> +int devid;
> +
> +static void
> +init(void)
> +{
> + drm_fd = drm_open_any();
> + devid = intel_get_drm_devid(drm_fd);
> +}
> +
> +static void
> +deinit(void)
> +{
> + close(drm_fd);
> +}
> +
> +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> +#define LOCAL_I915_PARAM_EU_TOTAL34
> +
> +static int
> +getparam(int param, int *value)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memset(, 0, sizeof(gp));
> + gp.value = value;
> + gp.param = param;
> + ret = drmIoctl(drm_fd, DRM_IOCTL_I915_GETPARAM, );
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
> +
> +static void
> +subslice_total(void)
> +{
> + unsigned int subslice_total = 0;
> + int ret;
> +
> + ret = getparam(LOCAL_I915_PARAM_SUBSLICE_TOTAL, (int*)_total);
> +
> + if (ret) {
> + /*
> +  * These devices are not required to implement the
> +  * interface. If they do not, -ENODEV must be returned.
> + */
> + if ((intel_gen(devid) < 8) ||
> 

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Archit Taneja]

On 03/13/2015 02:36 PM, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
>>
>>
>> On 03/11/2015 08:47 PM, Daniel Vetter wrote:
>>> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:


 On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
>> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
 On 03/10/2015 03:17 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 151a050..38f83a0 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
>>  help
>>FBDEV helpers for KMS drivers.
>>
>> +config DRM_FBDEV_EMULATION
>> +bool "Enable legacy fbdev support for your modesetting driver"
>> +depends on DRM
>> +select DRM_KMS_HELPER
>> +select DRM_KMS_FB_HELPER
>> +select FB_SYS_FILLRECT
>> +select FB_SYS_COPYAREA
>> +select FB_SYS_IMAGEBLIT
>> +select FB_SYS_FOPS
>> +select FB_CFB_FILLRECT
>> +select FB_CFB_COPYAREA
>> +select FB_CFB_IMAGEBLIT
>> +default y
>> +help
>> +  Choose this option if you have a need for the legacy fbdev
>> +  support. Note that this support also provide the linux console
>> +  support on top of your modesetting driver.
>
> Maybe clarify that for linux console support you also need
> CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.

 DRM_KMS_FB_HELPER selects that for us, right?
>>>
>>> Hm right I've missed that. Reminds me that you need one more patch at 
>>> the
>>> end to remove all the various select DRM_KMS_FB_HELPER from all drm
>>> drivers. Otherwise this knob here won't work by default if you e.g. 
>>> select
>>> radeon. In general we can't mix explicit options with menu entries with 
>>> a
>>> select.
>>
>> I was trying that out. Removing DRM_KMS_FB_HELPER and having
>> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff 
>> internally in
>> their respective xyz_fbdev.c files.
>
> But with the stubbed out functions that should work, right? Why doesn't
> it?

 There are still calls to functions from fb core like fb_set_suspend and
 register_framebuffer which aren't covered by the drm fb helper functions.
>>>
>>> Hm, sounds like we need another patch to stub out fb_set_suspend when
>>> fbdev isn't enabled. Is there anything else?
>>
>> There are a handful of fb core functions which are called by drm drivers:
>>
>> fb_alloc_cmap/fb_dealloc_cmap
>>
>> fb_sys_read/fb_sys_write
>>
>> register_framebuffer/unregister_framebuffer/unlink_framebuffer/
>> remove_conflicting_framebuffers
>>
>> fb_set_suspend
>>
>> fb_deferred_io_init/fb_deferred_io_cleanup
>>
>> framebuffer_alloc/framebuffer_release
>
> Hm yeah that's somewhat annoying indeed. What about the following:
> 1. We move all the #include  from drivers into drm_fb_helper.h
>
> 2. Then we add stubs for these functions in drm_fb_helper.h, like this
>
> #if defined(CONFIG_FB)
> #include 
> #else
>
> /* static inline stubs for all the fb stuff used by kms drivers */
> #endif
>
> Imo this makes sense since kms drivers really have a bit a special
> situation with fbdev. They're not full-blown fbdev drivers and can be
> useful fully without fbdev.
>
> What do you think?

This looks good! I'll give it a try.

Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 4/4] drm/msm/mdp5: Make the intf connection in config module

[Stephane Viau]

Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.

v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
v3: add sanity check before writing in INTF_TIMING_ENGINE_EN registers

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   8 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   4 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 112 ++--
 3 files changed, 75 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 72c075a..8bee023 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
.count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
},
+   .intfs = {
+   [0] = INTF_eDP,
+   [3] = INTF_HDMI,
+   },
.max_clk = 2,
 };

@@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
.count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
},
+   .intfs = {
+   [0] = INTF_eDP,
+   [3] = INTF_HDMI,
+   },
.max_clk = 32000,
 };

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 69e35ac..12224d7 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -56,6 +56,8 @@ struct mdp5_smp_block {
int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
 };

+#define MDP5_INTF_NUM_MAX  5
+
 struct mdp5_cfg_hw {
char  *name;

@@ -69,6 +71,8 @@ struct mdp5_cfg_hw {
struct mdp5_sub_block ad;
struct mdp5_sub_block intf;

+   u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+
uint32_t max_clk;
 };

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 390d9d2..7e03af5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
return 0;
 }

+static int construct_encoder(struct mdp5_kms *mdp5_kms,
+   enum mdp5_intf_type intf_type, int intf_num)
+{
+   struct drm_device *dev = mdp5_kms->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct drm_encoder *encoder;
+   struct mdp5_interface intf = {
+   .num= intf_num,
+   .type   = intf_type,
+   .mode   = MDP5_INTF_MODE_NONE,
+   };
+   int ret = 0;
+
+   encoder = mdp5_encoder_init(dev, );
+   if (IS_ERR(encoder)) {
+   ret = PTR_ERR(encoder);
+   dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
+   return ret;
+   }
+
+   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
+   priv->encoders[priv->num_encoders++] = encoder;
+
+   if (intf_type == INTF_HDMI) {
+   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+   if (ret)
+   dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
+
+   } else if (intf_type == INTF_eDP) {
+   /* Construct bridge/connector for eDP: */
+   ret = msm_edp_modeset_init(priv->edp, dev, encoder);
+   if (ret)
+   dev_err(dev->dev, "failed to init eDP: %d\n", ret);
+   }
+
+   return ret;
+}
+
 static int modeset_init(struct mdp5_kms *mdp5_kms)
 {
static const enum mdp5_pipe crtcs[] = {
@@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
};
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
-   struct drm_encoder *encoder;
const struct mdp5_cfg_hw *hw_cfg;
int i, ret;

@@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}

-   if (priv->hdmi) {
-   struct mdp5_interface intf = {
-   .num= 3,
-   .type   = INTF_HDMI,
-   .mode   = MDP5_INTF_MODE_NONE,
-   };
-
-   /* Construct encoder for HDMI: */
-   encoder = mdp5_encoder_init(dev, );
-   if (IS_ERR(encoder)) {
-   dev_err(dev->dev, "failed to construct encoder\n");
-   ret = PTR_ERR(encoder);
-   goto fail;
-   }
-
-   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;;
-   priv->encoders[priv->num_encoders++] = encoder;
-
-   ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
-   if (ret) {

[PATCH v3 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines

[Stephane Viau]

Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   7 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  31 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  72 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  13 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   1 +
 7 files changed, 276 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .flush_hw_mask = 0x003f,
},
.pipe_vig = {
.count = 4,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 4e90740..69e35ac 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -44,6 +44,11 @@ struct mdp5_lm_block {
uint32_t nb_stages; /* number of stages per blender */
 };

+struct mdp5_ctl_block {
+   MDP5_SUB_BLOCK_DEFINITION;
+   uint32_t flush_hw_mask; /* FLUSH register's hardware mask */
+};
+
 struct mdp5_smp_block {
int mmb_count;  /* number of SMP MMBs */
int mmb_size;   /* MMB: size in bytes */
@@ -55,7 +60,7 @@ struct mdp5_cfg_hw {
char  *name;

struct mdp5_smp_block smp;
-   struct mdp5_sub_block ctl;
+   struct mdp5_ctl_block ctl;
struct mdp5_sub_block pipe_vig;
struct mdp5_sub_block pipe_rgb;
struct mdp5_sub_block pipe_dma;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 15136f1..9527ad1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -82,8 +82,6 @@ static void request_pending(struct drm_crtc *crtc, uint32_t 
pending)
mdp_irq_register(_kms(crtc)->base, _crtc->vblank);
 }

-#define mdp5_lm_get_flush(lm)  mdp_ctl_flush_mask_lm(lm)
-
 static void crtc_flush(struct drm_crtc *crtc, u32 flush_mask)
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
@@ -110,8 +108,8 @@ static void crtc_flush_all(struct drm_crtc *crtc)
drm_atomic_crtc_for_each_plane(plane, crtc) {
flush_mask |= mdp5_plane_get_flush(plane);
}
-   flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl);
-   flush_mask |= mdp5_lm_get_flush(mdp5_crtc->lm);
+
+   flush_mask |= mdp_ctl_flush_mask_lm(mdp5_crtc->lm);

crtc_flush(crtc, flush_mask);
 }
@@ -442,13 +440,14 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   struct drm_gem_object *cursor_bo, *old_bo;
+   struct drm_gem_object *cursor_bo, *old_bo = NULL;
uint32_t blendcfg, cursor_addr, stride;
int ret, bpp, lm;
unsigned int depth;
enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
uint32_t roi_w, roi_h;
+   bool cursor_enable = true;
unsigned long flags;

if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
@@ -461,7 +460,8 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,

if (!handle) {
DBG("Cursor off");
-   return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
+   cursor_enable = false;
+   goto set_cursor;
}

cursor_bo = drm_gem_object_lookup(dev, file, handle);
@@ -502,11 +502,14 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,

spin_unlock_irqrestore(_crtc->cursor.lock, flags);

-   ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, true);
-   if (ret)
+set_cursor:
+   ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, 0, cursor_enable);
+   if (ret) {
+   dev_err(dev->dev, "failed to %sable cursor: %d\n",
+   cursor_enable ? "en" : "dis", 

[PATCH v3 2/4] drm/msm/mdp5: Enhance operation mode for pipeline configuration

[Stephane Viau]

DSI and WB interfaces need a more complex pipeline configuration
than the current mdp5_ctl_set_intf().

For example, memory output connections need to be selected for
WB. Interface mode (Video vs. Command modes) also need to be
configured for DSI.

This change takes care of configuring the whole pipeline as far
as operation mode goes. DSI and WB interfaces will be added
later.

v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  4 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 39 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 91 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 29 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 16 -
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 48 ---
 7 files changed, 159 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index dba4d52..4e90740 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -84,6 +84,10 @@ const struct mdp5_cfg_hw *mdp5_cfg_get_hw_config(struct 
mdp5_cfg_handler *cfg_hn
 struct mdp5_cfg *mdp5_cfg_get_config(struct mdp5_cfg_handler *cfg_hnd);
 int mdp5_cfg_get_hw_rev(struct mdp5_cfg_handler *cfg_hnd);

+#define mdp5_cfg_intf_is_virtual(intf_type) ({ \
+   typeof(intf_type) __val = (intf_type);  \
+   (__val) >= INTF_VIRTUAL ? true : false; })
+
 struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms *mdp5_kms,
uint32_t major, uint32_t minor);
 void mdp5_cfg_destroy(struct mdp5_cfg_handler *cfg_hnd);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index bfba236..15136f1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -611,48 +611,17 @@ void mdp5_crtc_cancel_pending_flip(struct drm_crtc *crtc, 
struct drm_file *file)
 }

 /* set interface for routing crtc->encoder: */
-void mdp5_crtc_set_intf(struct drm_crtc *crtc, int intf,
-   enum mdp5_intf intf_id)
+void mdp5_crtc_set_intf(struct drm_crtc *crtc, struct mdp5_interface *intf)
 {
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
-   uint32_t intf_sel;
-   unsigned long flags;
+   int lm = mdp5_crtc_get_lm(crtc);

/* now that we know what irq's we want: */
-   mdp5_crtc->err.irqmask = intf2err(intf);
-   mdp5_crtc->vblank.irqmask = intf2vblank(intf);
+   mdp5_crtc->err.irqmask = intf2err(intf->num);
+   mdp5_crtc->vblank.irqmask = intf2vblank(lm, intf);
mdp_irq_update(_kms->base);

-   spin_lock_irqsave(_kms->resource_lock, flags);
-   intf_sel = mdp5_read(mdp5_kms, REG_MDP5_DISP_INTF_SEL);
-
-   switch (intf) {
-   case 0:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF0__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF0(intf_id);
-   break;
-   case 1:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF1__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF1(intf_id);
-   break;
-   case 2:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF2__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF2(intf_id);
-   break;
-   case 3:
-   intf_sel &= ~MDP5_DISP_INTF_SEL_INTF3__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF3(intf_id);
-   break;
-   default:
-   BUG();
-   break;
-   }
-
-   mdp5_write(mdp5_kms, REG_MDP5_DISP_INTF_SEL, intf_sel);
-   spin_unlock_irqrestore(_kms->resource_lock, flags);
-
-   DBG("%s: intf_sel=%08x", mdp5_crtc->name, intf_sel);
mdp5_ctl_set_intf(mdp5_crtc->ctl, intf);
 }

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 1511290..a548113 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -33,6 +33,16 @@
  * requested by the client (in mdp5_crtc_mode_set()).
  */

+struct op_mode {
+   struct mdp5_interface intf;
+   /*
+* TODO: add a state variable to control the pipeline
+*
+* eg: WB interface needs both buffer addresses to be committed +
+* output buffers ready to be written into, before we can START.
+*/
+};
+
 struct mdp5_ctl {
struct mdp5_ctl_manager *ctlm;

@@ -41,8 +51,8 @@ struct mdp5_ctl {
/* whether this CTL has been allocated or not: */
bool busy;

-   /* memory output connection (@see mdp5_ctl_mode): */
-   u32 mode;
+   /* Operation Mode Configuration for the Pipeline */
+   struct op_mode pipeline;

/* REG_MDP5_CTL_*() registers access info + lock: */
spinlock_t hw_lock;
@@ -94,19 +104,81 @@ u32 

[PATCH v3 1/4] drm/msm/mdp5: Update generated header files

[Stephane Viau]

Prepare for pipeline operation mode configuration, in particular
for DSI and WB modes.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 68 -
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index c276624..095a54c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,7 +8,7 @@ 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:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
27229 bytes, from 2015-02-10 17:00:41)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
27094 bytes, from 2015-01-23 16:27:31)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2014-06-02 18:31:15)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-01-23 16:20:19)

@@ -37,11 +37,14 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
SOFTWARE.
 */


-enum mdp5_intf {
+enum mdp5_intf_type {
+   INTF_DISABLED = 0,
INTF_DSI = 1,
INTF_HDMI = 3,
INTF_LCDC = 5,
INTF_eDP = 9,
+   INTF_VIRTUAL = 100,
+   INTF_WB = 101,
 };

 enum mdp5_intfnum {
@@ -67,11 +70,11 @@ enum mdp5_pipe {

 enum mdp5_ctl_mode {
MODE_NONE = 0,
-   MODE_ROT0 = 1,
-   MODE_ROT1 = 2,
-   MODE_WB0 = 3,
-   MODE_WB1 = 4,
-   MODE_WFD = 5,
+   MODE_WB_0_BLOCK = 1,
+   MODE_WB_1_BLOCK = 2,
+   MODE_WB_0_LINE = 3,
+   MODE_WB_1_LINE = 4,
+   MODE_WB_2_LINE = 5,
 };

 enum mdp5_pack_3d {
@@ -144,30 +147,25 @@ enum mdp5_data_format {
DATA_FORMAT_YUV = 1,
 };

-#define MDP5_IRQ_INTF0_WB_ROT_COMP 0x0001
-#define MDP5_IRQ_INTF1_WB_ROT_COMP 0x0002
-#define MDP5_IRQ_INTF2_WB_ROT_COMP 0x0004
-#define MDP5_IRQ_INTF3_WB_ROT_COMP 0x0008
-#define MDP5_IRQ_INTF0_WB_WFD  0x0010
-#define MDP5_IRQ_INTF1_WB_WFD  0x0020
-#define MDP5_IRQ_INTF2_WB_WFD  0x0040
-#define MDP5_IRQ_INTF3_WB_WFD  0x0080
-#define MDP5_IRQ_INTF0_PING_PONG_COMP  0x0100
-#define MDP5_IRQ_INTF1_PING_PONG_COMP  0x0200
-#define MDP5_IRQ_INTF2_PING_PONG_COMP  0x0400
-#define MDP5_IRQ_INTF3_PING_PONG_COMP  0x0800
-#define MDP5_IRQ_INTF0_PING_PONG_RD_PTR
0x1000
-#define MDP5_IRQ_INTF1_PING_PONG_RD_PTR
0x2000
-#define MDP5_IRQ_INTF2_PING_PONG_RD_PTR
0x4000
-#define MDP5_IRQ_INTF3_PING_PONG_RD_PTR
0x8000
-#define MDP5_IRQ_INTF0_PING_PONG_WR_PTR
0x0001
-#define MDP5_IRQ_INTF1_PING_PONG_WR_PTR
0x0002
-#define MDP5_IRQ_INTF2_PING_PONG_WR_PTR
0x0004
-#define MDP5_IRQ_INTF3_PING_PONG_WR_PTR
0x0008
-#define MDP5_IRQ_INTF0_PING_PONG_AUTO_REF  0x0010
-#define MDP5_IRQ_INTF1_PING_PONG_AUTO_REF  0x0020
-#define MDP5_IRQ_INTF2_PING_PONG_AUTO_REF  0x0040
-#define MDP5_IRQ_INTF3_PING_PONG_AUTO_REF  0x0080
+#define MDP5_IRQ_WB_0_DONE 0x0001
+#define MDP5_IRQ_WB_1_DONE 0x0002
+#define MDP5_IRQ_WB_2_DONE 0x0010
+#define MDP5_IRQ_PING_PONG_0_DONE  0x0100
+#define MDP5_IRQ_PING_PONG_1_DONE  0x0200
+#define MDP5_IRQ_PING_PONG_2_DONE  0x0400
+#define MDP5_IRQ_PING_PONG_3_DONE  0x0800
+#define MDP5_IRQ_PING_PONG_0_RD_PTR0x1000
+#define MDP5_IRQ_PING_PONG_1_RD_PTR0x2000
+#define MDP5_IRQ_PING_PONG_2_RD_PTR0x4000
+#define MDP5_IRQ_PING_PONG_3_RD_PTR0x8000
+#define MDP5_IRQ_PING_PONG_0_WR_PTR0x0001
+#define MDP5_IRQ_PING_PONG_1_WR_PTR0x0002
+#define MDP5_IRQ_PING_PONG_2_WR_PTR0x0004
+#define MDP5_IRQ_PING_PONG_3_WR_PTR0x0008
+#define MDP5_IRQ_PING_PONG_0_AUTO_REF  0x0010
+#define MDP5_IRQ_PING_PONG_1_AUTO_REF   

[PATCH v3 0/4] drm/msm: preparation for WB/DSI connectors

[Stephane Viau]

WB and DSI support are in the pipe and will come out soon. Before that,
we need to prepare the MDP5 driver so we can support these connectors.

v2: rename macro to mdp5_cfg_intf_is_virtual() [pointed by Archit]
v3: add sanity check before writing in INTF_TIMING_ENGINE_EN registers

Note:
"drm/msm: Add display configuration for msm8x16" patch set depends on
"drm/msm: preparation for WB/DSI connectors" patch set.

Stephane Viau (4):
  drm/msm/mdp5: Update generated header files
  drm/msm/mdp5: Enhance operation mode for pipeline configuration
  drm/msm/mdp5: Add START signal to kick off certain pipelines
  drm/msm/mdp5: Make the intf connection in config module

 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h |  68 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |  10 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  15 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c|  70 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 326 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  75 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  40 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 100 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  49 -
 9 files changed, 522 insertions(+), 231 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH] nouveau: add coherent BO attribute

[Alexandre Courbot]

On Fri, Mar 13, 2015 at 3:36 PM, Ilia Mirkin  wrote:
> Doesn't this require a kernel version that has your other patch? What
> happens when this runs on an older kernel? Does it get silently
> ignored, or does it end up erroring out? If it errors out, that's
> fine. Otherwise some sort of version check should be put in, no?

The corresponding kernel patch is already merged in Ben's tree. If
running with an older kernel, this flag will be a no-op, which is fine
since GK20A's GPU (the reason for this patch as you have guessed :))
is not enabled for these kernels.

I am fine with adding a version check if you think it is necessary.

[PATCH] nouveau: add coherent BO attribute

[Alexandre Courbot]

Add a flag allowing Nouveau to specify that an object should be coherent
at allocation time. This is required for some class of objects like
fences which are randomly-accessed by both the CPU and GPU. This flag
instructs the kernel driver to make sure the object remains coherent
even on architectures for which coherency is not guaranteed by the bus.

Signed-off-by: Alexandre Courbot 
---
 include/drm/nouveau_drm.h | 1 +
 nouveau/abi16.c   | 3 +++
 nouveau/nouveau.h | 1 +
 3 files changed, 5 insertions(+)

diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index b18cad02419b..87aefc5e9d2f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
 #define NOUVEAU_GEM_DOMAIN_VRAM  (1 << 1)
 #define NOUVEAU_GEM_DOMAIN_GART  (1 << 2)
 #define NOUVEAU_GEM_DOMAIN_MAPPABLE  (1 << 3)
+#define NOUVEAU_GEM_DOMAIN_COHERENT  (1 << 4)

 #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
 #define NOUVEAU_GEM_TILE_16BPP   0x0001
diff --git a/nouveau/abi16.c b/nouveau/abi16.c
index ae13821bc0cc..d2d1d0d1942d 100644
--- a/nouveau/abi16.c
+++ b/nouveau/abi16.c
@@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
if (bo->flags & NOUVEAU_BO_MAP)
info->domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;

+   if (bo->flags & NOUVEAU_BO_COHERENT)
+   info->domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
+
if (!(bo->flags & NOUVEAU_BO_CONTIG))
info->tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;

diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index a55e2b020778..4adda0e3594c 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -127,6 +127,7 @@ union nouveau_bo_config {
 #define NOUVEAU_BO_MAP 0x8000
 #define NOUVEAU_BO_CONTIG  0x4000
 #define NOUVEAU_BO_NOSNOOP 0x2000
+#define NOUVEAU_BO_COHERENT 0x1000

 struct nouveau_bo {
struct nouveau_device *device;
-- 
2.3.2

[PATCH] rnndb: update generated headers

[Stephane Viau]

From: Beeresh Gopal 

To avoid ambiguity rename register
FRAME_SIZE to SSTILE_FRAME_SIZE.

Signed-off-by: Beeresh Gopal 
---
 rnndb/mdp/mdp4.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rnndb/mdp/mdp4.xml b/rnndb/mdp/mdp4.xml
index 26d1deb..a84f530 100644
--- a/rnndb/mdp/mdp4.xml
+++ b/rnndb/mdp/mdp4.xml
@@ -290,7 +290,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   



-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH v2 2/2] drm/msm/mdp4: Support NV12MT format in mdp4

[Stephane Viau]

From: Beeresh Gopal 

Using fb modifier flag, support NV12MT format in MDP4.

v2:
- rework the modifier's description [Daniel Vetter's comment]
- drop .set_mode_config() callback [Rob Clark's comment]

Signed-off-by: Beeresh Gopal 
Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
 include/uapi/drm/drm_fourcc.h |  5 +
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d81e19d..6387881 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
if (mdp4_kms->rev > 1)
mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);

+   dev->mode_config.allow_fb_modifiers = true;
+
 out:
pm_runtime_put_sync(dev->dev);

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index cde2500..2c2d6a5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -33,6 +33,21 @@ struct mdp4_plane {
 };
 #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)

+/* MDP format helper functions */
+static inline
+enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
+{
+   bool is_tile = false;
+
+   if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+   is_tile = true;
+
+   if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
+   return FRAME_TILE_YCBCR_420;
+
+   return FRAME_LINEAR;
+}
+
 static void mdp4_plane_set_scanout(struct drm_plane *plane,
struct drm_framebuffer *fb);
 static int mdp4_plane_mode_set(struct drm_plane *plane,
@@ -203,6 +218,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
uint32_t op_mode = 0;
uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
+   enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);

if (!(crtc && fb)) {
DBG("%s: disabled!", mdp4_plane->name);
@@ -302,6 +318,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count 
- 1) |
MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) 
|
+   MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
COND(format->unpack_tight, 
MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));

mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
@@ -322,6 +339,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);

+   if (frame_type != FRAME_LINEAR)
+   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
+   MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
+   MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
+
return 0;
 }

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 188e61f..2ff79cb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -161,4 +161,9 @@
  * authoritative source for all of these.
  */

+/* Samsung framebuffer modifiers */
+
+/* Tiled: 64x32 pixel macroblocks */
+#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
+
 #endif /* DRM_FOURCC_H */
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH v2 1/2] drm/msm: update generated headers

[Stephane Viau]

From: Beeresh Gopal 

To avoid ambiguity rename FRAME_SIZE to
SSTILE_FRAME_SIZE

Signed-off-by: Beeresh Gopal 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 +
 1 file changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
index 1d39174..2d0029d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.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 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(  
20908 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(  
27208 bytes, from 2015-01-13 23:56:11)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
26848 bytes, from 2015-01-13 23:55:57)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (   
8253 bytes, from 2014-12-08 16:13:00)
-
-Copyright (C) 2013-2014 by the following authors:
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp4.xml(  
20915 bytes, from 2015-02-06 15:25:51)
+- /local/mnt/workspace/sandbox/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2015-02-06 15:25:09)
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-02-06 15:25:09)
+
+Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)

 Permission is hereby granted, free of charge, to any person obtaining
@@ -680,18 +672,18 @@ static inline uint32_t MDP4_PIPE_SRC_STRIDE_B_P3(uint32_t 
val)
return ((val) << MDP4_PIPE_SRC_STRIDE_B_P3__SHIFT) & 
MDP4_PIPE_SRC_STRIDE_B_P3__MASK;
 }

-static inline uint32_t REG_MDP4_PIPE_FRAME_SIZE(enum mdp4_pipe i0) { return 
0x00020048 + 0x1*i0; }
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK  0x
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT 16
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_HEIGHT(uint32_t val)
+static inline uint32_t REG_MDP4_PIPE_SSTILE_FRAME_SIZE(enum mdp4_pipe i0) { 
return 0x00020048 + 0x1*i0; }
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK   0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT  16
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(uint32_t val)
 {
-   return ((val) << MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT) & 
MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK;
+   return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT) & 
MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK;
 }
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__MASK   0x
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT  0
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_WIDTH(uint32_t val)
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK
0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT   0
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(uint32_t val)
 {
-   return ((val) << MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT) & 
MDP4_PIPE_FRAME_SIZE_WIDTH__MASK;
+   return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT) & 
MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK;
 }

 static inline uint32_t REG_MDP4_PIPE_SRC_FORMAT(enum mdp4_pipe i0) { return 
0x00020050 + 0x1*i0; }
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH v2 0/2] drm/msm: Add support for NV12MT format in mdp4

[Stephane Viau]

Resending a v2 on behalf of Beeresh with comments from Daniel and Rob
addressed.

Beeresh Gopal (2):
  drm/msm: update generated headers
  drm/msm/mdp4: Support NV12MT format in mdp4

 drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h   | 36 ---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 +++
 include/uapi/drm/drm_fourcc.h |  5 +
 4 files changed, 43 insertions(+), 22 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH] drm: Silence sparse warnings

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

../drivers/gpu/drm/drm_vm.c:405:6: warning: symbol 'drm_vm_open_locked' was not 
declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:431:6: warning: symbol 'drm_vm_close_locked' was 
not declared. Should it be static?
../drivers/gpu/drm/drm_vm.c:681:5: warning: symbol 'drm_vma_info' was not 
declared. Should it be static?

../drivers/gpu/drm/drm_pci.c:146:5: warning: symbol 'drm_pci_set_unique' was 
not declared. Should it be static?
../drivers/gpu/drm/drm_pci.c:216:5: warning: symbol 'drm_irq_by_busid' was not 
declared. Should it be static?

../drivers/gpu/drm/drm_info.c:47:5: warning: symbol 'drm_name_info' was not 
declared. Should it be static?
../drivers/gpu/drm/drm_info.c:72:5: warning: symbol 'drm_vm_info' was not 
declared. Should it be static?
../drivers/gpu/drm/drm_info.c:116:5: warning: symbol 'drm_bufs_info' was not 
declared. Should it be static?
../drivers/gpu/drm/drm_info.c:159:5: warning: symbol 'drm_clients_info' was not 
declared. Should it be static?
../drivers/gpu/drm/drm_info.c:209:5: warning: symbol 'drm_gem_name_info' was 
not declared. Should it be static?

../drivers/gpu/drm/drm_ioc32.c:1019:20: warning: symbol 'drm_compat_ioctls' was 
not declared. Should it be static?

../drivers/gpu/drm/drm_bridge.c:52:12: warning: function 'drm_bridge_attach' 
with external linkage has definition

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_bridge.c | 2 +-
 drivers/gpu/drm/drm_info.c   | 1 +
 drivers/gpu/drm/drm_ioc32.c  | 2 +-
 drivers/gpu/drm/drm_pci.c| 1 +
 drivers/gpu/drm/drm_vm.c | 1 +
 5 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index d1187e5..eaa5790 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -49,7 +49,7 @@ void drm_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_bridge_remove);

-extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
+int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
 {
if (!dev || !bridge)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index f1b32f9..cbb4fc0 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -37,6 +37,7 @@
 #include 
 #include 

+#include "drm_internal.h"
 #include "drm_legacy.h"

 /**
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 2f4c4343..aa8bbb4 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -1016,7 +1016,7 @@ static int compat_drm_wait_vblank(struct file *file, 
unsigned int cmd,
return 0;
 }

-drm_ioctl_compat_t *drm_compat_ioctls[] = {
+static drm_ioctl_compat_t *drm_compat_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION32)] = compat_drm_version,
[DRM_IOCTL_NR(DRM_IOCTL_GET_UNIQUE32)] = compat_drm_getunique,
[DRM_IOCTL_NR(DRM_IOCTL_GET_MAP32)] = compat_drm_getmap,
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index fd29f03..1b1bd42 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include "drm_internal.h"
 #include "drm_legacy.h"

 /**
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index 4a2c328..aab49ee 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -41,6 +41,7 @@
 #include 
 #endif
 #include 
+#include "drm_internal.h"
 #include "drm_legacy.h"

 struct drm_vma_entry {
-- 
2.0.5

[PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16

["Stéphane Viau"]

Hi,

> Hi,
>
> On 03/09/2015 06:41 PM, Stephane Viau wrote:
>> This change adds the hw configuration for msm8x16 chipsets in
>> mdp5_cfg module.
>>
>> Note that only one external display interface is present in this
>> configuration (DSI) but has not been enabled yet. It will be enabled
>> once drm/msm driver supports DSI connectors.
>>
>> Signed-off-by: Stephane Viau 
>> ---
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51
>> -
>>   1 file changed, 50 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> index 96ea6dd..9ff7ac1 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> @@ -1,5 +1,5 @@
>>   /*
>> - * Copyright (c) 2014 The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2014-2015 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 and
>> @@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
>>  .max_clk = 32000,
>>   };
>>
>> +const struct mdp5_cfg_hw msm8x16_config = {
>> +.name = "msm8x16",
>> +.mdp = {
>> +.count = 1,
>> +.base = { 0x01000 },
>> +},
>> +.smp = {
>> +.mmb_count = 8,
>> +.mmb_size = 8192,
>> +.clients = {
>> +[SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
>> +[SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
>> +},
>> +},
>> +.ctl = {
>> +.count = 5,
>> +.base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
>> +},
>> +.pipe_vig = {
>> +.count = 1,
>> +.base = { 0x05000 },
>> +},
>> +.pipe_rgb = {
>> +.count = 2,
>> +.base = { 0x15000, 0x17000 },
>> +},
>> +.pipe_dma = {
>> +.count = 1,
>> +.base = { 0x25000 },
>> +},
>> +.lm = {
>> +.count = 2, /* LM0 and LM3 */
>> +.base = { 0x45000, 0x48000 },
>> +.nb_stages = 5,
>> +},
>> +.dspp = {
>> +.count = 1,
>> +.base = { 0x55000 },
>> +
>> +},
>> +.intf = {
>> +.count = 1, /* INTF_1 */
>> +.base = { 0x6B800 },
>
> We would need to put the other non-existent INTF_0, INTF_2 and INTF_3
> base addresses here too, so that the writes to
> REG_MDP5_INTF_TIMING_ENGINE_EN in the patch "Make the intf connection in
> config module" access the correct registers.

You are referring here to the discussion we had in "drm/msm/mdp5: Make the
intf connection in config module"[1]...

Let me clarify:
We see these faults when interfaces are *present* but not *supported* by
the driver, where:
 - *present* means that the interfaces are physically implemented in HW
and therefore need to be reflected by "intf.base" addresses
 - *supported* means that the msm KMS driver is actually able to drive an
interface
If you look at mdp5_cfg.c in "drm/msm/mdp5: Make the intf connection in
config module"[1], 4 interfaces (intf.base) are present (for apq8084), but
only 2 are supported (intfs[])...
What I meant is that even though our driver cannot support all interfaces
present in a chip, we still need to disable them in mdp5_kms_init().
(BTW, this is probably due to my bootloader enabling the DSI whereas the
msm KMS driver does not support it as of yet - and thus leads to
artifacts/underflow on my eDP panel.)

So to answer your comment, it doesn't make too much sense to define base
addresses for interfaces that are not present in a chip. Instead I'd
prefer to check if intf.base is not NULL before writing in
REG_MDP5_INTF_TIMING_ENGINE_EN registers.. and avoid some INVALID_INDEX
BUGs ;-).

I'm sending out a v3 for "drm/msm/mdp5: Make the intf connection in config
module" in a minute...

[1] http://lists.freedesktop.org/archives/dri-devel/2015-March/078651.html

>
> Archit
>
>> +},
>> +/* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented
>> */
>> +.max_clk = 32000,
>> +};
>> +
>>   static const struct mdp5_cfg_handler cfg_handlers[] = {
>>  { .revision = 0, .config = { .hw = _config } },
>>  { .revision = 2, .config = { .hw = _config } },
>>  { .revision = 3, .config = { .hw = _config } },
>> +{ .revision = 6, .config = { .hw = _config } },
>>   };
>>
>>
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Jani Nikula]

On Fri, 13 Mar 2015, Rob Clark  wrote:
> hopefully someone else in China can suggest a good way of sending
> patches (I have no clue there)

An alternative is to subscribe with all email addresses you may be
sending patches (or messages) from, but disabling list mail delivery for
all but one address in the dri-devel list management interface.

You can have git format-patch/send-email add a From: line at the
beginning of the patch (separate from mail headers) matching the
Signed-off-by. I forget the config for this, but it's there somewhere.


HTH,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Alex Deucher]

On Fri, Mar 13, 2015 at 12:36 PM, Daniel Vetter  wrote:
> On Fri, Mar 13, 2015 at 06:46:33PM +0900, Michel Dänzer wrote:
>> On 13.03.2015 18:11, Daniel Vetter wrote:
>> > On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
>> >> On 12.03.2015 06:14, Alex Deucher wrote:
>> >>> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
>> >>> wrote:
>>  On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>>   wrote:
>> > On 11.03.2015 16:44, Alex Deucher wrote:
>> >>
>> >> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>> >> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>> >> uses the ttm bo size to determine when to select top down
>> >> allocation but since the ttm bo is not initialized yet the
>> >> check is always false.
>> >>
>> >> Noticed-by: Oded Gabbay 
>> >> Signed-off-by: Alex Deucher 
>> >> Cc: stable at vger.kernel.org
>> >
>> >
>> > And I was already wondering why the heck the BOs always made this 
>> > ping/pong
>> > in memory after creation.
>> >
>> > Patch is Reviewed-by: Christian König 
>> 
>>  And fixing that promptly broke VCE due to vram location requirements.
>>  Updated patch attached.  Thoughts?
>> >>>
>> >>> And one more take to make things a bit more explicit for static kernel
>> >>> driver allocations.
>> >>
>> >> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>> >> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>> >> problem is really that some BOs are expected to be within a certain
>> >> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>> >> would be better to fix that by setting lpfn directly than indirectly via
>> >> RADEON_GEM_CPU_ACCESS.
>> >>
>> >>
>> >> Anyway, since this isn't the first bug which prevents
>> >> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
>> >> wonder if its performance impact should be re-evaluated. Lauri?
>> >
>> > Topdown allocation in drm_mm is just a hint/bias really, it won't try too
>> > hard to segregate things. If you depend upon perfect topdown allocation
>> > for correctness then this won't work well. The trouble starts once you've
>> > split your free space up - it's not going to look for the topmost hole
>> > first but still picks just the one on top of the stack.
>>
>> TTM_PL_FLAG_TOPDOWN sets DRM_MM_SEARCH_BELOW as well as
>> DRM_MM_CREATE_TOP. So it should traverse the list of holes in reverse
>> order, right?
>
> Sure that additional segregation helps a bit more, but in the end if you
> split things badly and are a bit unlucky then the buffer can end up pretty
> much anywhere. Just wanted to mention that in case someone gets confused
> when the buffers end up in unexpected places.

There's no explicit requirement that they have to be at the top or
bottom per se, it's just the the buffers in question have a specific
restricted location requirement and they are set up at driver init
time and not moved for the life of the driver so I'd rather not put
them somewhere too sub-optimal.

Alex

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/i915/skl: cleanup an indenting issue

[Dan Carpenter]

This statement is indented an extra space.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 959058f..028c6d4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3905,13 +3905,13 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
I915_WRITE(GEN6_RP_DOWN_THRESHOLD,
GT_INTERVAL_FROM_US(dev_priv, (ei_down * threshold_down / 
100)));

-I915_WRITE(GEN6_RP_CONTROL,
-   GEN6_RP_MEDIA_TURBO |
-   GEN6_RP_MEDIA_HW_NORMAL_MODE |
-   GEN6_RP_MEDIA_IS_GFX |
-   GEN6_RP_ENABLE |
-   GEN6_RP_UP_BUSY_AVG |
-   GEN6_RP_DOWN_IDLE_AVG);
+   I915_WRITE(GEN6_RP_CONTROL,
+  GEN6_RP_MEDIA_TURBO |
+  GEN6_RP_MEDIA_HW_NORMAL_MODE |
+  GEN6_RP_MEDIA_IS_GFX |
+  GEN6_RP_ENABLE |
+  GEN6_RP_UP_BUSY_AVG |
+  GEN6_RP_DOWN_IDLE_AVG);

dev_priv->rps.power = new_power;
dev_priv->rps.last_adj = 0;

[git pull] drm fixes

[Paul Bolle]

Dave Airlie schreef op vr 06-03-2015 om 21:52 [+]:
> Thierry Reding (1):
>   drm/mm: Support 4 GiB and larger ranges

Yesterday the screen on my (outdated) ThinkPad X41 went, well, black
while it was busy compiling something unattended. I eventually had to
power cycle that laptop to regain control. I found a drm related BUG()
in the logs (pasted at the end of the message).

I only have three months worth of logs (a diagnoising session pushed
most of the logs into /dev/null a few weeks ago). But this is the only
time I saw that BUG in that period. Now that commit is the last thing
touching that code, and the various unsigned long to u64 conversions
_might_ just have gone wrong for 32 bits. I didn't spot anything utterly
obvious in that commit, but point a finger at it just in case.

Thanks,


Paul Bolle

mrt 12 19:29:00 x41 kernel: [ cut here ]
mrt 12 19:29:00 x41 kernel: kernel BUG at drivers/gpu/drm/drm_mm.c:305!
mrt 12 19:29:01 x41 kernel: invalid opcode:  [#1] SMP 
mrt 12 19:29:01 x41 kernel: Modules linked in: bnep bluetooth fuse arc4 
lib80211_crypt_wep ip6t_rpfilter ip6t_RE
JECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc 
ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_
tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat 
nf_conntrack iptable_mangle iptable_secur
ity iptable_raw gpio_ich iTCO_wdt iTCO_vendor_support snd_intel8x0 
snd_ac97_codec ppdev ipw2200 ac97_bus snd_seq
 sdhci_pci pcspkr serio_raw sdhci snd_seq_device libipw i2c_i801 mmc_core 
snd_pcm lpc_ich lib80211 thinkpad_acpi
 cfg80211 snd_timer irda snd parport_pc soundcore rfkill parport crc_ccitt 
acpi_cpufreq binfmt_misc i915 i2c_alg
o_bit drm_kms_helper tg3 drm ptp ata_generic
mrt 12 19:29:01 x41 kernel:  yenta_socket pps_core pata_acpi video
mrt 12 19:29:01 x41 kernel: CPU: 0 PID: 1749 Comm: gnome-shell Not tainted 
4.0.0-0.rc3.1.local0.fc21.i686 #1
mrt 12 19:29:01 x41 kernel: Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW 
(2.09 ) 12/14/2006
mrt 12 19:29:02 x41 kernel: task: e17cc5e0 ti: e1696000 task.ti: e1696000
mrt 12 19:29:06 x41 kernel: EIP: 0060:[] EFLAGS: 00210206 CPU: 0
mrt 12 19:29:06 x41 kernel: EIP is at 
drm_mm_insert_node_in_range_generic+0x3b5/0x480 [drm]
mrt 12 19:29:06 x41 kernel: EAX: 00df EBX: ef734c08 ECX: ef438d00 EDX: 

mrt 12 19:29:06 x41 kernel: ESI: ef734c00 EDI: ef734c00 EBP: e1697c6c ESP: 
e1697bf0
mrt 12 19:29:06 x41 kernel:  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
mrt 12 19:29:06 x41 kernel: CR0: 80050033 CR2: a24b7000 CR3: 21632000 CR4: 
07d0
mrt 12 19:29:06 x41 kernel: Stack:
mrt 12 19:29:07 x41 kernel:  e1697c54  005f  0080 
ef734c00  f6b0de00
mrt 12 19:29:07 x41 kernel:    0093   
1000  0032
mrt 12 19:29:07 x41 kernel:     00c5  
 f6bb434c 0080
mrt 12 19:29:07 x41 kernel: Call Trace:
mrt 12 19:29:09 x41 kernel:  [] i915_gem_object_pin_view+0x666/0x8a0 
[i915]
mrt 12 19:29:09 x41 kernel:  [] 
i915_gem_execbuffer_reserve_vma.isra.11+0x62/0x100 [i915]
mrt 12 19:29:09 x41 kernel:  [] 
i915_gem_execbuffer_reserve+0x2d9/0x350 [i915]
mrt 12 19:29:09 x41 kernel:  [] 
i915_gem_do_execbuffer.isra.16+0x65d/0xe00 [i915]
mrt 12 19:29:09 x41 kernel:  [] ? __kmalloc+0x1f5/0x250
mrt 12 19:29:09 x41 kernel:  [] ? i915_gem_execbuffer2+0x59/0x2d0 
[i915]
mrt 12 19:29:09 x41 kernel:  [] i915_gem_execbuffer2+0x8b/0x2d0 [i915]
mrt 12 19:29:09 x41 kernel:  [] ? i915_gem_execbuffer+0x510/0x510 
[i915]
mrt 12 19:29:09 x41 kernel:  [] ? ktime_get+0x4a/0x110
mrt 12 19:29:09 x41 kernel:  [] ? drm_getmap+0xc0/0xc0 [drm]
mrt 12 19:29:09 x41 kernel:  [] do_vfs_ioctl+0x322/0x540
mrt 12 19:29:09 x41 kernel:  [] ? inode_has_perm.isra.32+0x32/0x50
mrt 12 19:29:09 x41 kernel:  [] ? file_has_perm+0x97/0xa0
mrt 12 19:29:09 x41 kernel:  [] ? selinux_file_ioctl+0x4b/0xe0
mrt 12 19:29:09 x41 kernel:  [] SyS_ioctl+0x60/0x90
mrt 12 19:29:09 x41 kernel:  [] sysenter_do_call+0x12/0x12
mrt 12 19:29:09 x41 kernel: Code: 05 0f 0b 8d 76 00 3b 55 e4 77 0b 72 05 3b 45 
e0 73 04 0f 0b 66 90 8b 7d 98 03 47 20 13 57 24 3b 55 ec 72 12 77 05 3b 45 e8 
76 0b <0f> 0b 89 f6 8d bc 27 00 00 00 00 39 55 cc 77 0b 72 05 39 45 b8
mrt 12 19:29:09 x41 kernel: EIP: [] 
drm_mm_insert_node_in_range_generic+0x3b5/0x480 [drm] SS:ESP 0068:e1697bf0
mrt 12 19:29:10 x41 kernel: ---[ end trace 3402b5fea7a4b768 ]---

[RFC][PATCH] amdkfd: Convert timestamping to use 64bit time accessors

[Arnd Bergmann]

On Thursday 12 March 2015 10:23:40 John Stultz wrote:
> Convert the timestamping in the amdkfd driver to use
> a timespec64 and 64bit time accessors.
> 
> Cc: Arnd Bergmann 
> Cc: Oded Gabbay 
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: John Stultz 
> 

The patch looks good, but I'd always include at least a one-liner
about what it's good for. In this case, the existing code
is completely safe beyond y2038 because you are dealing with
monotonic time, so it's worth mentioning that we do this in
order to kill off all uses of struct timespec.

Arnd

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Sebastian Andrzej Siewior]

On 03/13/2015 03:23 AM, Michel Dänzer wrote:
> The commits from
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=f957063fee6392bb9365370db6db74dc0b2dce0a
> to
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=cffefd9bb31cd35ab745d3b49005d10616d25bdc
> and
> http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=b6610101718d4ab90d793c482625e98eb1262cad
> might help for this.
Thanks.

I can't reproduce this myself but I pulled in the commits you mentioned
and "drm/radeon: only enable kv/kb dpm interrupts once v3" to avoid a
reject. The box runs, glxgears and so on seem to do something, can't
look at the screen :) All of those commits (and a ton more) are marked
stable so I will probably get them anyway…

Sebastian

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Michel Dänzer]

On 12.03.2015 22:09, Alex Deucher wrote:
> On Thu, Mar 12, 2015 at 5:23 AM, Christian König
>  wrote:
>> On 12.03.2015 10:02, Michel Dänzer wrote:
>>>
>>> On 12.03.2015 06:14, Alex Deucher wrote:

 On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher 
 wrote:
>
> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>  wrote:
>>
>> On 11.03.2015 16:44, Alex Deucher wrote:
>>>
>>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>>> uses the ttm bo size to determine when to select top down
>>> allocation but since the ttm bo is not initialized yet the
>>> check is always false.
>>>
>>> Noticed-by: Oded Gabbay 
>>> Signed-off-by: Alex Deucher 
>>> Cc: stable at vger.kernel.org
>>
>>
>> And I was already wondering why the heck the BOs always made this
>> ping/pong
>> in memory after creation.
>>
>> Patch is Reviewed-by: Christian König 
>
> And fixing that promptly broke VCE due to vram location requirements.
> Updated patch attached.  Thoughts?

 And one more take to make things a bit more explicit for static kernel
 driver allocations.
>>>
>>> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
>>> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
>>> problem is really that some BOs are expected to be within a certain
>>> range from the beginning of VRAM, but lpfn isn't set accordingly. It
>>> would be better to fix that by setting lpfn directly than indirectly via
>>> RADEON_GEM_CPU_ACCESS.
>>
>>
>> Yeah, agree. We should probably try to find the root cause of this instead.
>>
>> As far as I know VCE has no documented limitation on where buffers are
>> placed (unlike UVD). So this is a bit strange. Are you sure that it isn't
>> UVD which breaks here?
> 
> It's definitely VCE, I don't know why UVD didn't have a problem.  I
> considered using pin_restricted to make sure it got pinned in the CPU
> visible region, but that had two problems: 1. it would end up getting
> migrated when pinned,

Maybe something like radeon_uvd_force_into_uvd_segment() is needed for
VCE as well?


> 2. it would end up at the top of the restricted
> region since the top down flag is set which would end up fragmenting
> vram.

If that's an issue (which outweighs the supposed benefit of
TTM_PL_FLAG_TOPDOWN), then again the proper solution would be not to set
TTM_PL_FLAG_TOPDOWN when rbo->placements[i].lpfn != 0 and smaller than
the whole available region, instead of checking for VRAM and
RADEON_GEM_CPU_ACCESS.


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

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Archit Taneja]

On 03/11/2015 08:47 PM, Daniel Vetter wrote:
> On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
>>
>>
>> On 03/10/2015 05:47 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
 On 03/10/2015 03:35 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
>> On 03/10/2015 03:17 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
 diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
 index 151a050..38f83a0 100644
 --- a/drivers/gpu/drm/Kconfig
 +++ b/drivers/gpu/drm/Kconfig
 @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
  FBDEV helpers for KMS drivers.

 +config DRM_FBDEV_EMULATION
 +  bool "Enable legacy fbdev support for your modesetting driver"
 +  depends on DRM
 +  select DRM_KMS_HELPER
 +  select DRM_KMS_FB_HELPER
 +  select FB_SYS_FILLRECT
 +  select FB_SYS_COPYAREA
 +  select FB_SYS_IMAGEBLIT
 +  select FB_SYS_FOPS
 +  select FB_CFB_FILLRECT
 +  select FB_CFB_COPYAREA
 +  select FB_CFB_IMAGEBLIT
 +  default y
 +  help
 +Choose this option if you have a need for the legacy fbdev
 +support. Note that this support also provide the linux console
 +support on top of your modesetting driver.
>>>
>>> Maybe clarify that for linux console support you also need
>>> CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
>>
>> DRM_KMS_FB_HELPER selects that for us, right?
>
> Hm right I've missed that. Reminds me that you need one more patch at the
> end to remove all the various select DRM_KMS_FB_HELPER from all drm
> drivers. Otherwise this knob here won't work by default if you e.g. select
> radeon. In general we can't mix explicit options with menu entries with a
> select.

 I was trying that out. Removing DRM_KMS_FB_HELPER and having
 DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally 
 in
 their respective xyz_fbdev.c files.
>>>
>>> But with the stubbed out functions that should work, right? Why doesn't
>>> it?
>>
>> There are still calls to functions from fb core like fb_set_suspend and
>> register_framebuffer which aren't covered by the drm fb helper functions.
>
> Hm, sounds like we need another patch to stub out fb_set_suspend when
> fbdev isn't enabled. Is there anything else?

There are a handful of fb core functions which are called by drm drivers:

fb_alloc_cmap/fb_dealloc_cmap

fb_sys_read/fb_sys_write

register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers

fb_set_suspend

fb_deferred_io_init/fb_deferred_io_cleanup

framebuffer_alloc/framebuffer_release


>
 Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and
 replace them with 'select DRM_FBDEV_EMULATION'?

 Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds
 for fb related function calls/declarations in each driver, something that's
 already done for i915 and msm drivers.
>>>
>>> The problem with the patch as-is the massive amounts of selects the FB
>>> helper still has. We need to get rid of them so that when you disable
>>> fbdev emulation you can indeed disable fbcon and the entire fbdev
>>> subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER
>>> and moving all the selects to DRM_FBDEV_EMULATION should work out? If that
>>> doesn't work we need to look again how to better stub things out I think.
>>
>> That's true. Also, as Jani pointed out, maybe it isn't the best idea to make
>> every kms driver select DRM_FBDEV_EMULATION?
>>
>> Maybe the drivers that are currently built with fbdev emulation by default
>> can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y,
>> the drivers should run as is. Later, we could take up each driver and build
>> the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915
>> and msm?
>
> Yeah we definitely can't mix select with a user-visible option. I think we
> just need to fix up the remaining functions and create stubs for them if
> needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we
> should still select for fbcon since otherwise tons of bug reports about
> "where is my fbcon with kms?".

I'll give this a try. Although, it would be a better idea to make the 
drivers not call these at all when fbdev emulation isn't asked for. With 
the stubs, if someone does try to use the driver with 
DRM_FBDEV_EMULATION not set, the worst that'll happen would be that the 
driver fails to probe. Which isn't so bad.

Archit

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

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Jani Nikula]

On Fri, 13 Mar 2015, Daniel Vetter  wrote:
> #if defined(CONFIG_FB)
> #include 
> #else

Side note, #if IS_ENABLED(CONFIG_FB)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 0/7] drm/exynos: clean ups

[Inki Dae]

On 2015년 03월 13일 03:45, Gustavo Padovan wrote:
> 2015-03-12 Inki Dae :
> 
>> On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> Here goes some clean ups to the exynos drivers. The main clean ups is
>>> the presetting and zpos making the property immutable and the removal
>>> of *_win_data structures.
>>
>> With your cleanup patch set, the plane test doesn't work. Have you ever
>> tested plane feature with modetest application?
>>
>> I typed like below and it looks like no problem but I cannot see
>> anything on Panel except for cute four penguins.
>>
>> # modetest -P 29:100x100+0+0
>> trying to open device 'i915'...failed.
>> trying to open device 'radeon'...failed.
>> trying to open device 'nouveau'...failed.
>> trying to open device 'vmwgfx'...failed.
>> trying to open device 'omapdrm'...failed.
>> trying to open device 'exynos'...success.
>> testing 100x100 at XR24 overlay plane 25
>>
>> And for two plane test,
>>
>> # modetest -P 29:100x100+0+0 -P 29:100x100+0+100
>> trying to open device 'i915'...failed.
>> trying to open device 'radeon'...failed.
>> trying to open device 'nouveau'...failed.
>> trying to open device 'vmwgfx'...failed.
>> trying to open device 'omapdrm'...failed.
>> trying to open device 'exynos'...success.
>> testing 100x100 at XR24 overlay plane 25
>> testing 100x100 at XR24 overlay plane 26
>>
>> Still no screen.
> 
> Well, I did some more testing and even without my patches I can't see a plane
> on the screen. Running only on exynos-drm-next also doesn't work so it is not
> something that my patches introduced, it is already a bug upstream.
> I'm using a snow for testing.

It's strange. I can see a semicircular small box on the screen without
your patch set, and that works well on not only exynos-drm-next but also
exynos-drm-fixes. I'm using a trarts2 board based on Exynos4412 SoC.

Could anyone check the plane test with modetest for double-check?

Thanks,
Inki Dae

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

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Fine, I will try to catch up.
Thanks anyway.

Have a nice day,
John

On Fri, Mar 13, 2015 at 11:07 AM, Rob Clark  wrote:

> On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
> > Got it, maybe I should work on the drm-next or latest linux master.
> >
> > I am working on the drm git repo below for now as Daniel Vetter told me
> > git://people.freedesktop.org/~airlied/linux
> > I am quite confused now 'cause there are a bounch of git repo, I really
> > do not know which one should I git clone.
> >
>
> Hmm, I suspect airlied hasn't updated his master branch in a while,
> which is probably causing confusing..  using his drm-next branch or
> linus master would be better..  in general, drm-next for latest and
> greatest drm is probably best, but right at the moment there is
> probably not much difference from linus master.
>
> I usually end up 'git remote add'ing a bunch of different trees to
> track both what has already landed in linus's master branch, and also
> what is coming in drm-next (and various different arm trees related to
> other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
> a safe bet.
>
> BR,
> -R
>
>
> >
> > On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
> >>
> >> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
> >> wrote:
> >> > From: John Hunter 
> >> >
> >> > IMHO, some annotations were copypaste from somewhere else, it is
> >> > obviously not rightly modified. Hope I am right with that.
> >> > ---
> >> >  drivers/gpu/drm/drm_crtc.c | 115
> >> > ++---
> >> >  1 file changed, 56 insertions(+), 59 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> > index f2d667b..7f771e9 100644
> >> > --- a/drivers/gpu/drm/drm_crtc.c
> >> > +++ b/drivers/gpu/drm/drm_crtc.c
> >> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
> >> > drm_connector_status status)
> >> >  /**
> >> >   * drm_mode_object_get - allocate a new identifier
> >> >   * @dev: DRM device
> >> > - * @ptr: object pointer, used to generate unique ID
> >> > - * @type: object type
> >> > + * @obj: object pointer, used to generate unique ID
> >> > + * @obj_type: object type
> >> >   *
> >> >   * LOCKING:
> >> >   *
> >> > - * Create a unique identifier based on @ptr in @dev's identifier
> space.
> >> > Used
> >> > + * Create a unique identifier based on @obj in @dev's identifier
> space.
> >> > Used
> >> >   * for tracking modes, CRTCs and connectors.
> >>
> >> so, I don't suppose you can rebase against a newer upstream kernel?
> >>
> >> From a quick look, it seems like the arg name errors where corrected
> >> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
> >> bodies fixes from your patch are still applicable.  In the current
> >> form, the patch does not apply against drm-next (or latest linux
> >> master), but most of it is still applicable and would be a very
> >> welcome improvement.
> >>
> >> Thanks :-)
> >>
> >> BR,
> >> -R
> >>
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/d9f4d797/attachment.html>

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Michel Dänzer]

On 13.03.2015 08:23, Carsten Emde wrote:
> (About 30 OSADL QA Farm systems are now running 3.18.9-rt4. BTW: To
> check out what kernels are under test you may sort the kernel list
> (https://www.osadl.org/?id=933) by kernel version
> (https://www.osadl.org/?id=1001) and scroll down the page.)
> 
> The most striking problem of kernel 3.18.9-rt4 affects all systems that
> are equipped with Radeon graphics (irrespective whether PCIe cards or
> APUs with on-chip graphics). They suffer from a hanging radeon driver.
> The block occurs when accelerated graphics load is created by x11perf or
> gltestperf. Sometimes only the graphics are frozen while ssh login still
> is possible, somtimes the entire box is no longer accessible at all. In
> any case, a reboot is needed to recover from this situation.
> 
> Here is a selection of kernel messages:

[...]

The commits from
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=f957063fee6392bb9365370db6db74dc0b2dce0a
to
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=cffefd9bb31cd35ab745d3b49005d10616d25bdc
and
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=b6610101718d4ab90d793c482625e98eb1262cad
might help for this.


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

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

 * @filp: file * from the ioctl
> > - * @cmd: cmd from ioctl
> > - * @arg: arg from ioctl
> > + * @dev: DRM device
> > + * @data: ioctl data
> > + * @file_priv: DRM file info
> >   *
> >   * LOCKING:
> >   * Takes mode config lock.
> > @@ -2515,6 +2506,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> > ret = -EINVAL;
> > goto out_err1;
> > }
> > +
> > clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
> > if (!clips) {
> > ret = -ENOMEM;
> > @@ -2544,15 +2536,14 @@ out_err1:
> > return ret;
> >  }
> >
> > -
> >  /**
> >   * drm_fb_release - remove and free the FBs on this file
> > - * @filp: file * from the ioctl
> > + * @priv: file * from the ioctl
> >   *
> >   * LOCKING:
> >   * Takes mode config lock.
> >   *
> > - * Destroy all the FBs associated with @filp.
> > + * Destroy all the FBs associated with @priv.
> >   *
> >   * Called by the user via ioctl.
> >   *
> > @@ -2616,7 +2607,7 @@ int drm_mode_attachmode_crtc(struct drm_device
> *dev, struct drm_crtc *crtc,
> >
> > WARN_ON(!list_empty());
> >
> > - out:
> > +out:
> > list_for_each_entry_safe(dup_mode, next, , head)
> > drm_mode_destroy(dev, dup_mode);
> >
> > @@ -2660,10 +2651,9 @@ EXPORT_SYMBOL(drm_mode_detachmode_crtc);
> >
> >  /**
> >   * drm_fb_attachmode - Attach a user mode to an connector
> > - * @inode: inode from the ioctl
> > - * @filp: file * from the ioctl
> > - * @cmd: cmd from ioctl
> > - * @arg: arg from ioctl
> > + * @dev: DRM device
> > + * @data: ioctl data
> > + * @file_priv: DRM file info
> >   *
> >   * This attaches a user specified mode to an connector.
> >   * Called by the user via ioctl.
> > @@ -2707,6 +2697,7 @@ int drm_mode_attachmode_ioctl(struct drm_device
> *dev,
> > }
> >
> > drm_mode_attachmode(dev, connector, mode);
> > +
> >  out:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > @@ -2715,10 +2706,9 @@ out:
> >
> >  /**
> >   * drm_fb_detachmode - Detach a user specified mode from an connector
> > - * @inode: inode from the ioctl
> > - * @filp: file * from the ioctl
> > - * @cmd: cmd from ioctl
> > - * @arg: arg from ioctl
> > + * @dev: DRM device
> > + * @data: ioctl data
> > + * @file_priv: DRM file info
> >   *
> >   * Called by the user via ioctl.
> >   *
> > @@ -2754,6 +2744,7 @@ int drm_mode_detachmode_ioctl(struct drm_device
> *dev,
> > }
> >
> > ret = drm_mode_detachmode(dev, connector, );
> > +
> >  out:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > @@ -2790,6 +2781,7 @@ struct drm_property *drm_property_create(struct
> drm_device *dev, int flags,
> >
> > list_add_tail(>head, >mode_config.property_list);
> > return property;
> > +
> >  fail:
> > kfree(property->values);
> > kfree(property);
> > @@ -3078,6 +3070,7 @@ int drm_mode_getproperty_ioctl(struct drm_device
> *dev,
> > }
> > out_resp->count_enum_blobs = blob_count;
> > }
> > +
> >  done:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > @@ -3187,6 +3180,7 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
> >  {
> > if (property->flags & DRM_MODE_PROP_IMMUTABLE)
> > return false;
> > +
> > if (property->flags & DRM_MODE_PROP_RANGE) {
> > if (value < property->values[0] || value >
> property->values[1])
> > return false;
> > @@ -3194,6 +3188,7 @@ static bool drm_property_change_is_valid(struct
> drm_property *property,
> > } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> > int i;
> > uint64_t valid_mask = 0;
> > +
> > for (i = 0; i < property->num_values; i++)
> > valid_mask |= (1ULL << property->values[i]);
> > return !(value & ~valid_mask);
> > @@ -3326,6 +3321,7 @@ int drm_mode_obj_get_properties_ioctl(struct
> drm_device *dev, void *data,
> > }
> > }
> > arg->count_props = props_count;
> > +
> >  out:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > @@ -3487,7 +3483,6 @@ int drm_mode_gamma_set_ioctl(struct drm_device
> *dev,
> >  out:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > -
> >  }
> >
> >  int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> > @@ -3535,6 +3530,7 @@ int drm_mode_gamma_get_ioctl(struct drm_device
> *dev,
> > ret = -EFAULT;
> > goto out;
> > }
> > +
> >  out:
> > mutex_unlock(>mode_config.mutex);
> > return ret;
> > @@ -3668,6 +3664,7 @@ int drm_mode_create_dumb_ioctl(struct drm_device
> *dev,
> >
> > if (!dev->driver->dumb_create)
> > return -ENOSYS;
> > +
> > return dev->driver->dumb_create(file_priv, dev, args);
> >  }
> >
> > --
> > 1.9.1
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150313/f80e2494/attachment-0001.html>

[PATCH 15/22] drm: %pF is only for function pointers

[Daniel Vetter]

On Wed, Mar 11, 2015 at 10:13:50PM -0500, Scott Wood wrote:
> Use %pS for actual addresses, otherwise you'll get bad output
> on arches like ppc64 where %pF expects a function descriptor.
> 
> Signed-off-by: Scott Wood 
> Cc: dri-devel at lists.freedesktop.org

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index d512134..48f7359 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -70,7 +70,7 @@ void drm_err(const char *format, ...)
>   vaf.fmt = format;
>   vaf.va = 
>  
> - printk(KERN_ERR "[" DRM_NAME ":%pf] *ERROR* %pV",
> + printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
>  __builtin_return_address(0), );
>  
>   va_end(args);
> -- 
> 2.1.0
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Daniel Vetter]

On Thu, Mar 12, 2015 at 06:02:56PM +0900, Michel Dänzer wrote:
> On 12.03.2015 06:14, Alex Deucher wrote:
> > On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher  
> > wrote:
> >> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
> >>  wrote:
> >>> On 11.03.2015 16:44, Alex Deucher wrote:
> 
>  radeon_bo_create() calls radeon_ttm_placement_from_domain()
>  before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>  uses the ttm bo size to determine when to select top down
>  allocation but since the ttm bo is not initialized yet the
>  check is always false.
> 
>  Noticed-by: Oded Gabbay 
>  Signed-off-by: Alex Deucher 
>  Cc: stable at vger.kernel.org
> >>>
> >>>
> >>> And I was already wondering why the heck the BOs always made this 
> >>> ping/pong
> >>> in memory after creation.
> >>>
> >>> Patch is Reviewed-by: Christian König 
> >>
> >> And fixing that promptly broke VCE due to vram location requirements.
> >> Updated patch attached.  Thoughts?
> > 
> > And one more take to make things a bit more explicit for static kernel
> > driver allocations.
> 
> struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
> latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
> problem is really that some BOs are expected to be within a certain
> range from the beginning of VRAM, but lpfn isn't set accordingly. It
> would be better to fix that by setting lpfn directly than indirectly via
> RADEON_GEM_CPU_ACCESS.
> 
> 
> Anyway, since this isn't the first bug which prevents
> TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
> wonder if its performance impact should be re-evaluated. Lauri?

Topdown allocation in drm_mm is just a hint/bias really, it won't try too
hard to segregate things. If you depend upon perfect topdown allocation
for correctness then this won't work well. The trouble starts once you've
split your free space up - it's not going to look for the topmost hole
first but still picks just the one on top of the stack.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

[Daniel Vetter]

On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
> 
> 
> On 03/11/2015 08:47 PM, Daniel Vetter wrote:
> >On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
> >>
> >>
> >>On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> >>>On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
> >On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
> >>On 03/10/2015 03:17 PM, Daniel Vetter wrote:
> >>>On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 151a050..38f83a0 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
>   help
> FBDEV helpers for KMS drivers.
> 
> +config DRM_FBDEV_EMULATION
> + bool "Enable legacy fbdev support for your modesetting driver"
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select FB_SYS_FOPS
> + select FB_CFB_FILLRECT
> + select FB_CFB_COPYAREA
> + select FB_CFB_IMAGEBLIT
> + default y
> + help
> +   Choose this option if you have a need for the legacy fbdev
> +   support. Note that this support also provide the linux console
> +   support on top of your modesetting driver.
> >>>
> >>>Maybe clarify that for linux console support you also need
> >>>CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
> >>
> >>DRM_KMS_FB_HELPER selects that for us, right?
> >
> >Hm right I've missed that. Reminds me that you need one more patch at the
> >end to remove all the various select DRM_KMS_FB_HELPER from all drm
> >drivers. Otherwise this knob here won't work by default if you e.g. 
> >select
> >radeon. In general we can't mix explicit options with menu entries with a
> >select.
> 
> I was trying that out. Removing DRM_KMS_FB_HELPER and having
> DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally 
> in
> their respective xyz_fbdev.c files.
> >>>
> >>>But with the stubbed out functions that should work, right? Why doesn't
> >>>it?
> >>
> >>There are still calls to functions from fb core like fb_set_suspend and
> >>register_framebuffer which aren't covered by the drm fb helper functions.
> >
> >Hm, sounds like we need another patch to stub out fb_set_suspend when
> >fbdev isn't enabled. Is there anything else?
> 
> There are a handful of fb core functions which are called by drm drivers:
> 
> fb_alloc_cmap/fb_dealloc_cmap
> 
> fb_sys_read/fb_sys_write
> 
> register_framebuffer/unregister_framebuffer/unlink_framebuffer/
> remove_conflicting_framebuffers
> 
> fb_set_suspend
> 
> fb_deferred_io_init/fb_deferred_io_cleanup
> 
> framebuffer_alloc/framebuffer_release

Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include  from drivers into drm_fb_helper.h

2. Then we add stubs for these functions in drm_fb_helper.h, like this

#if defined(CONFIG_FB)
#include 
#else

/* static inline stubs for all the fb stuff used by kms drivers */
#endif

Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.

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

[PATCH v3 00/10] Use media bus formats in imx-drm and add drm panel support

[Philipp Zabel]

Am Donnerstag, den 12.03.2015, 18:53 +0100 schrieb Emil Renner Berthing:
> Hi Philipp
> 
> On 12 March 2015 at 10:58, Philipp Zabel  wrote:
> > Currently the imx-drm driver misuses the V4L2_PIX_FMT constants to describe 
> > the
> > pixel format on the parallel bus between display controllers and encoders. 
> > Now
> > that MEDIA_BUS_FMT is available, use that instead.
> 
> I've tested this series on the Hercules eCAFE Slim HD, which uses the
> RGB666_1X24_CPADHI format, and it still boots up with screen output.
> You can add
> 
> Tested-by: Emil Renner Berthing 

Thanks for testing! I'll add that to the relevant patches (5-7).

regards
Philipp

[Intel-gfx] [Beignet] [PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Jeff McGee]

On Fri, Mar 13, 2015 at 05:59:13PM +0100, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
> > On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> > > On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > > > My only concern is about the following macros:
> > > > 
> > > > > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> > > > > +#define LOCAL_I915_PARAM_EU_TOTAL34
> > > > 
> > > > How about to just use the definitons in the kernel header file?
> > > > For an example:
> > > > 
> > > >   #include 
> > > > 
> > > >   #ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
> > > >   //Put all the code into this block.
> > > >   #endif
> > > > 
> > > > Then we can avoid put the same definitions in different files,
> > > > and we can avoid unecessary testing on an old kernel which doesn't
> > > > have this kernel interface.
> > > > 
> > > > For all the other part, it LGTM.
> > > > 
> > > > Reviewed-by: Zhigang Gong 
> > > 
> > > Once we update the libdrm requirements in igt we tend to go around and
> > > replace all the now obsolete LOCAL_ defines. Imo not worth doing extra
> > > work until then.
> > > 
> > > Patch applied, thanks.
> > > -Daniel
> > > 
> > 
> > Patch applied? Do you want me to make the name change first? Should the
> > kernel part be reviewed and merged first?
> 
> Forgot my own review comment already ;-) Fixed up with a follow-up patch.
> And I'll pull the kernel part in now too.
> -Daniel

Thanks. That leaves just the libdrm patch and version bump before Beignet
can merge their patches.
-Jeff

[PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Daniel Vetter]

On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mcgee at intel.com wrote:
> From: Jeff McGee 
> 
> New test core_getparams consists of 2 subtests, each one testing
> the ability of userspace to query the correct value of a GT config
> attribute: subslice total or EU total. drm/i915 implementation of
> these queries is required for Cherryview and Gen9+ devices (non-
> simulated).
> 
> v2: Duplicate small amount of new libdrm functionality to avoid
> bumping libdrm version requirement (Daniel). Convert some
> igt_asserts to the appropriate comparison variants. Add a
> test description.
> v3: Actually use the LOCAL GETPARAM defines. Otherwise can't build
> against older libdrm as intended by v2.
> 
> For: VIZ-4636
> Signed-off-by: Jeff McGee 
> ---
>  tests/.gitignore   |   1 +
>  tests/Makefile.sources |   1 +
>  tests/core_getparams.c | 167 
> +
>  3 files changed, 169 insertions(+)
>  create mode 100644 tests/core_getparams.c
> 
> diff --git a/tests/.gitignore b/tests/.gitignore
> index 426cc67..c742308 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -1,6 +1,7 @@
>  # Please keep sorted alphabetically
>  core_get_client_auth
>  core_getclient
> +core_getparams
>  core_getstats
>  core_getversion
>  drm_import_export
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 51e8376..999c8f8 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \
>  
>  TESTS_progs_M = \
>   core_get_client_auth \
> + core_getparams \

Sorry I missed this little one: core_ is for drm core stuff shared by all
drivers (i.e. even those not supporting gem or kms). getparam is an i915
specific thing, so imo better to have drv_ as a prefix.

For our naming conventions and igt test sections see the docs at

http://people.freedesktop.org/~danvet/igt/

For review I think signing up someone from the beignet team might be best.
Cheers, Daniel

>   drv_suspend \
>   drv_hangman \
>   gem_bad_reloc \
> diff --git a/tests/core_getparams.c b/tests/core_getparams.c
> new file mode 100644
> index 000..2855d06
> --- /dev/null
> +++ b/tests/core_getparams.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Jeff McGee 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "drmtest.h"
> +#include "intel_chipset.h"
> +#include "intel_bufmgr.h"
> +
> +IGT_TEST_DESCRIPTION("Tests the export of parameters via 
> DRM_IOCTL_I915_GETPARAM\n");
> +
> +int drm_fd;
> +int devid;
> +
> +static void
> +init(void)
> +{
> + drm_fd = drm_open_any();
> + devid = intel_get_drm_devid(drm_fd);
> +}
> +
> +static void
> +deinit(void)
> +{
> + close(drm_fd);
> +}
> +
> +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> +#define LOCAL_I915_PARAM_EU_TOTAL34
> +
> +static int
> +getparam(int param, int *value)
> +{
> + drm_i915_getparam_t gp;
> + int ret;
> +
> + memset(, 0, sizeof(gp));
> + gp.value = value;
> + gp.param = param;
> + ret = drmIoctl(drm_fd, DRM_IOCTL_I915_GETPARAM, );
> + if (ret)
> + return -errno;
> +
> + return 0;
> +}
> +
> +static void
> +subslice_total(void)
> +{
> + unsigned int subslice_total = 0;
> + int ret;
> +
> + ret = getparam(LOCAL_I915_PARAM_SUBSLICE_TOTAL, (int*)_total);
> +
> + if (ret) {
> + /*
> +  * These devices are not required to implement the
> +  * interface. If they do not, -ENODEV must be returned.
> + */
> + if ((intel_gen(devid) < 8) ||
> + IS_BROADWELL(devid) ||
> + igt_run_in_simulation()) {
> + igt_assert_eq(ret, -ENODEV);
> + 

[Beignet] [Intel-gfx] [PATCH i-g-t v3] tests/core_getparams: Create new test core_getparams

[Jeff McGee]

On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
> On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
> > My only concern is about the following macros:
> > 
> > > +#define LOCAL_I915_PARAM_SUBSLICE_TOTAL  33
> > > +#define LOCAL_I915_PARAM_EU_TOTAL34
> > 
> > How about to just use the definitons in the kernel header file?
> > For an example:
> > 
> >   #include 
> > 
> >   #ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
> >   //Put all the code into this block.
> >   #endif
> > 
> > Then we can avoid put the same definitions in different files,
> > and we can avoid unecessary testing on an old kernel which doesn't
> > have this kernel interface.
> > 
> > For all the other part, it LGTM.
> > 
> > Reviewed-by: Zhigang Gong 
> 
> Once we update the libdrm requirements in igt we tend to go around and
> replace all the now obsolete LOCAL_ defines. Imo not worth doing extra
> work until then.
> 
> Patch applied, thanks.
> -Daniel
> 

Patch applied? Do you want me to make the name change first? Should the
kernel part be reviewed and merged first?
-Jeff

> > 
> > Thanks,
> > Zhigang Gong.
> > 
> > On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mcgee at intel.com wrote:
> > > From: Jeff McGee 
> > > 
> > > New test core_getparams consists of 2 subtests, each one testing
> > > the ability of userspace to query the correct value of a GT config
> > > attribute: subslice total or EU total. drm/i915 implementation of
> > > these queries is required for Cherryview and Gen9+ devices (non-
> > > simulated).
> > > 
> > > v2: Duplicate small amount of new libdrm functionality to avoid
> > > bumping libdrm version requirement (Daniel). Convert some
> > > igt_asserts to the appropriate comparison variants. Add a
> > > test description.
> > > v3: Actually use the LOCAL GETPARAM defines. Otherwise can't build
> > > against older libdrm as intended by v2.
> > > 
> > > For: VIZ-4636
> > > Signed-off-by: Jeff McGee 
> > > ---
> > >  tests/.gitignore   |   1 +
> > >  tests/Makefile.sources |   1 +
> > >  tests/core_getparams.c | 167 
> > > +
> > >  3 files changed, 169 insertions(+)
> > >  create mode 100644 tests/core_getparams.c
> > > 
> > > diff --git a/tests/.gitignore b/tests/.gitignore
> > > index 426cc67..c742308 100644
> > > --- a/tests/.gitignore
> > > +++ b/tests/.gitignore
> > > @@ -1,6 +1,7 @@
> > >  # Please keep sorted alphabetically
> > >  core_get_client_auth
> > >  core_getclient
> > > +core_getparams
> > >  core_getstats
> > >  core_getversion
> > >  drm_import_export
> > > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > > index 51e8376..999c8f8 100644
> > > --- a/tests/Makefile.sources
> > > +++ b/tests/Makefile.sources
> > > @@ -15,6 +15,7 @@ NOUVEAU_TESTS_M = \
> > >  
> > >  TESTS_progs_M = \
> > >   core_get_client_auth \
> > > + core_getparams \
> > >   drv_suspend \
> > >   drv_hangman \
> > >   gem_bad_reloc \
> > > diff --git a/tests/core_getparams.c b/tests/core_getparams.c
> > > new file mode 100644
> > > index 000..2855d06
> > > --- /dev/null
> > > +++ b/tests/core_getparams.c
> > > @@ -0,0 +1,167 @@
> > > +/*
> > > + * Copyright © 2014 Intel Corporation
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining 
> > > a
> > > + * copy of this software and associated documentation files (the 
> > > "Software"),
> > > + * to deal in the Software without restriction, including without 
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice (including the 
> > > next
> > > + * paragraph) shall be included in all copies or substantial portions of 
> > > the
> > > + * Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > SHALL
> > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > > OTHER
> > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > ARISING
> > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > DEALINGS
> > > + * IN THE SOFTWARE.
> > > + *
> > > + * Authors:
> > > + *Jeff McGee 
> > > + *
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "drmtest.h"
> > > +#include "intel_chipset.h"
> > > +#include "intel_bufmgr.h"
> > > +
> > > +IGT_TEST_DESCRIPTION("Tests the export of parameters via 
> > > DRM_IOCTL_I915_GETPARAM\n");
> > > +
> > > +int drm_fd;
> > > +int devid;
> > > +
> > > +static void
> > > 

[PATCH 2/2] drm/msm: Support NV12MT format in mdp4

["Stéphane Viau"]

Hi Daniel,

> On Fri, Feb 20, 2015 at 3:42 PM, Beeresh Gopal 
> wrote:
>> +/* Samsung framebuffer modifiers */
>> +
>> +/*
>> + * NV12 64x32 Tiled
>> + *
>> + * 2 planes Y and CbCr, grouped into 64x32 macro tiles,
>> + * with a non-standard order in memory (Z-shape).
>> + *
>> + * Pixel layout identical to DRM_FORMAT_NV21 format:
>> + * index 0 = Y plane, [7:0] Y
>> + * index 1 = Cb:Cr plane, [15:0] Cb:Cr little endian
>> + */
>> +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
>
> This description mixes layout information with pixel format. Strictly
> speaking you could use this for other formats, but since the
> description doesn't mention whether this is in bytes or pixels that's
> a bit awkward. Or just mandatae that this can only be used with NV12
> fourcc (and maybe add a check for that into the core drm code.

Agreed: I think /* Tiled: 64x32 pixel macroblocks */ - or something along
those lines - as a description should do the trick.

>
> Also, is this really samsung and not mpeg?

>From my understanding the VENDOR is actually SAMSUNG for the following
reasons:
 a) V4L2_PIX_FMT_NV12MT has  been introduced[1] for the Samsung’s s5p-fimc
driver (which got renamed into exynos4-is[2])
 b) A search on “V4L2_PIX_FMT_NV12MT” in the drivers folder only returns
Samsung drivers so far..

[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4a3c9b4f0df43207eb0b4d0da9cb51e185506bd5
[2]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=56fa1a6a6a7da91e7ece8b01b0ae8adb2926e434


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Stéphane
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

KING:
> >>   * Takes mode config lock.
> >> @@ -2304,10 +2298,9 @@ static int framebuffer_check(const struct
> >> drm_mode_fb_cmd2 *r)
> >>
> >>  /**
> >>   * drm_mode_addfb2 - add an FB to the graphics configuration
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >> @@ -2370,10 +2363,9 @@ out:
> >>
> >>  /**
> >>   * drm_mode_rmfb - remove an FB from the configuration
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >> @@ -2425,10 +2417,9 @@ out:
> >>
> >>  /**
> >>   * drm_mode_getfb - get FB info
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >> @@ -2515,6 +2506,7 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> >> ret = -EINVAL;
> >> goto out_err1;
> >> }
> >> +
> >> clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
> >> if (!clips) {
> >> ret = -ENOMEM;
> >> @@ -2544,15 +2536,14 @@ out_err1:
> >> return ret;
> >>  }
> >>
> >> -
> >>  /**
> >>   * drm_fb_release - remove and free the FBs on this file
> >> - * @filp: file * from the ioctl
> >> + * @priv: file * from the ioctl
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >>   *
> >> - * Destroy all the FBs associated with @filp.
> >> + * Destroy all the FBs associated with @priv.
> >>   *
> >>   * Called by the user via ioctl.
> >>   *
> >> @@ -2616,7 +2607,7 @@ int drm_mode_attachmode_crtc(struct drm_device
> *dev,
> >> struct drm_crtc *crtc,
> >>
> >> WARN_ON(!list_empty());
> >>
> >> - out:
> >> +out:
> >> list_for_each_entry_safe(dup_mode, next, , head)
> >> drm_mode_destroy(dev, dup_mode);
> >>
> >> @@ -2660,10 +2651,9 @@ EXPORT_SYMBOL(drm_mode_detachmode_crtc);
> >>
> >>  /**
> >>   * drm_fb_attachmode - Attach a user mode to an connector
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * This attaches a user specified mode to an connector.
> >>   * Called by the user via ioctl.
> >> @@ -2707,6 +2697,7 @@ int drm_mode_attachmode_ioctl(struct drm_device
> >> *dev,
> >> }
> >>
> >> drm_mode_attachmode(dev, connector, mode);
> >> +
> >>  out:
> >> mutex_unlock(>mode_config.mutex);
> >> return ret;
> >> @@ -2715,10 +2706,9 @@ out:
> >>
> >>  /**
> >>   * drm_fb_detachmode - Detach a user specified mode from an connector
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * Called by the user via ioctl.
> >>   *
> >> @@ -2754,6 +2744,7 @@ int drm_mode_detachmode_ioctl(struct drm_device
> >> *dev,
> >> }
> >>
> >> ret = drm_mode_detachmode(dev, connector, );
> >> +
> >>  out:
> >> mutex_unlock(>mode_config.mutex);
> >> return ret;
> >> @@ -2790,6 +2781,7 @@ struct drm_property *drm_property_create(struct
>

[Bug 89534] GPU lockup with wine

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

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

--- Comment #11 from John  ---
Created attachment 114275
  --> https://bugs.freedesktop.org/attachment.cgi?id=114275=edit
xorg log when it crashed, though I don't see anything of interest in it.

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #10 from John  ---
Created attachment 114274
  --> https://bugs.freedesktop.org/attachment.cgi?id=114274=edit
regdump with dpm off and hyperz on, after it crashed

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #9 from John  ---
Created attachment 114273
  --> https://bugs.freedesktop.org/attachment.cgi?id=114273=edit
regdump with dpm on and hyperz off, after it crashed

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #8 from John  ---
Created attachment 114272
  --> https://bugs.freedesktop.org/attachment.cgi?id=114272=edit
regdump when the computer starts

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #7 from John  ---
Created attachment 114271
  --> https://bugs.freedesktop.org/attachment.cgi?id=114271=edit
dmesg with a cpu stuck instead of gpu, might be unrelated

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #6 from John  ---
Created attachment 114270
  --> https://bugs.freedesktop.org/attachment.cgi?id=114270=edit
dmsg with dpm on and hyperz off after it crashed

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

[Bug 89534] GPU lockup with wine

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

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

--- Comment #5 from John  ---
I was able to finally play the game by disabling dpm and disabling HYPERZ, but
then in my last try it crashed again even with these disabled. So I am not sure
how much they helped... maybe I just got lucky?

I'll add some logs.

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

[PATCH] nouveau: add coherent BO attribute

[Ilia Mirkin]

Doesn't this require a kernel version that has your other patch? What
happens when this runs on an older kernel? Does it get silently
ignored, or does it end up erroring out? If it errors out, that's
fine. Otherwise some sort of version check should be put in, no?

On Fri, Mar 13, 2015 at 2:27 AM, Alexandre Courbot  
wrote:
> Add a flag allowing Nouveau to specify that an object should be coherent
> at allocation time. This is required for some class of objects like
> fences which are randomly-accessed by both the CPU and GPU. This flag
> instructs the kernel driver to make sure the object remains coherent
> even on architectures for which coherency is not guaranteed by the bus.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  include/drm/nouveau_drm.h | 1 +
>  nouveau/abi16.c   | 3 +++
>  nouveau/nouveau.h | 1 +
>  3 files changed, 5 insertions(+)
>
> diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
> index b18cad02419b..87aefc5e9d2f 100644
> --- a/include/drm/nouveau_drm.h
> +++ b/include/drm/nouveau_drm.h
> @@ -96,6 +96,7 @@ struct drm_nouveau_setparam {
>  #define NOUVEAU_GEM_DOMAIN_VRAM  (1 << 1)
>  #define NOUVEAU_GEM_DOMAIN_GART  (1 << 2)
>  #define NOUVEAU_GEM_DOMAIN_MAPPABLE  (1 << 3)
> +#define NOUVEAU_GEM_DOMAIN_COHERENT  (1 << 4)
>
>  #define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
>  #define NOUVEAU_GEM_TILE_16BPP   0x0001
> diff --git a/nouveau/abi16.c b/nouveau/abi16.c
> index ae13821bc0cc..d2d1d0d1942d 100644
> --- a/nouveau/abi16.c
> +++ b/nouveau/abi16.c
> @@ -195,6 +195,9 @@ abi16_bo_init(struct nouveau_bo *bo, uint32_t alignment,
> if (bo->flags & NOUVEAU_BO_MAP)
> info->domain |= NOUVEAU_GEM_DOMAIN_MAPPABLE;
>
> +   if (bo->flags & NOUVEAU_BO_COHERENT)
> +   info->domain |= NOUVEAU_GEM_DOMAIN_COHERENT;
> +
> if (!(bo->flags & NOUVEAU_BO_CONTIG))
> info->tile_flags = NOUVEAU_GEM_TILE_NONCONTIG;
>
> diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
> index a55e2b020778..4adda0e3594c 100644
> --- a/nouveau/nouveau.h
> +++ b/nouveau/nouveau.h
> @@ -127,6 +127,7 @@ union nouveau_bo_config {
>  #define NOUVEAU_BO_MAP 0x8000
>  #define NOUVEAU_BO_CONTIG  0x4000
>  #define NOUVEAU_BO_NOSNOOP 0x2000
> +#define NOUVEAU_BO_COHERENT 0x1000
>
>  struct nouveau_bo {
> struct nouveau_device *device;
> --
> 2.3.2
>

[OSADL QA 3.18.9-rt4 #1] Radeon driver hangs

[Carsten Emde]

(About 30 OSADL QA Farm systems are now running 3.18.9-rt4. BTW: To 
check out what kernels are under test you may sort the kernel list 
(https://www.osadl.org/?id=933) by kernel version 
(https://www.osadl.org/?id=1001) and scroll down the page.)

The most striking problem of kernel 3.18.9-rt4 affects all systems that 
are equipped with Radeon graphics (irrespective whether PCIe cards or 
APUs with on-chip graphics). They suffer from a hanging radeon driver. 
The block occurs when accelerated graphics load is created by x11perf or 
gltestperf. Sometimes only the graphics are frozen while ssh login still 
is possible, somtimes the entire box is no longer accessible at all. In 
any case, a reboot is needed to recover from this situation.

Here is a selection of kernel messages:

Rack #0/Slot #3 [AMD/ATI] RV730 XT [Radeon HD 4670]:
[16081.272035] INFO: task kworker/u24:4:268 blocked for more than 120 
seconds.
[16081.285776]   Not tainted 3.18.9-rt4 #26
[16081.294286] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[16081.309901] kworker/u24:4   D 88081ed8b340 0   268  2 
0x1000
[16081.309938] Workqueue: radeon-crtc radeon_flip_work_func [radeon]
[16081.309960]  880805ccfbe8 0046 88081ed0c700 

[16081.309962]  9000 c920 8808112fb420 
880805cc1a10
[16081.309963]  880805ccfbf8 01008108a0da 880805ccfc98 
880805cc1a10
[16081.309966] Call Trace:
[16081.309972]  [] schedule+0x34/0xa0
[16081.309974]  [] schedule_timeout+0x22c/0x2d0
[16081.309984]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[16081.309993]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[16081.310001]  [] 
radeon_fence_wait_seq_timeout.constprop.8+0x2e7/0x340 [radeon]
[16081.310004]  [] ? __wake_up_sync+0x20/0x20
[16081.310013]  [] radeon_fence_wait+0x86/0xc0 [radeon]
[16081.310023]  [] radeon_flip_work_func+0x15c/0x190 
[radeon]
[16081.310025]  [] process_one_work+0x154/0x450
[16081.310026]  [] worker_thread+0x6b/0x4d0
[16081.310028]  [] ? rescuer_thread+0x290/0x290
[16081.310029]  [] kthread+0xcd/0xf0
[16081.310031]  [] ? kthread_worker_fn+0x1d0/0x1d0
[16081.310034]  [] ret_from_fork+0x7c/0xb0
[16081.310035]  [] ? kthread_worker_fn+0x1d0/0x1d0


Rack #0/Slot #7 [AMD/ATI] Cayman XT [Radeon HD 6970]:
INFO: task Xorg:10038 blocked for more than 120 seconds.
  Not tainted 3.18.9-rt4 #25
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
XorgD 816b7f88 0 10038  10032 0x1044
8800c5ad78e8 0002 88041e80c460 c5c8
88041e80c5c8 0002 c5a8 c5c8
880417728000 88041401 000c 88041401
Call Trace:
[] schedule+0x34/0xa0
[] schedule_timeout+0x204/0x270
[] ? radeon_fence_process+0x16/0x40 [radeon]
[] ? radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[] 
radeon_fence_wait_seq_timeout.constprop.7+0x227/0x330 [radeon]
[] ? prepare_to_wait_event+0x110/0x110
[] radeon_fence_wait_any+0x57/0x70 [radeon]
[] radeon_sa_bo_new+0x2cf/0x4e0 [radeon]
[] ? debug_smp_processor_id+0x17/0x20
[] radeon_ib_get+0x37/0xf0 [radeon]
[] radeon_cs_ioctl+0x22d/0x820 [radeon]
[] drm_ioctl+0x1a4/0x630 [drm]
[] ? debug_smp_processor_id+0x17/0x20
[] ? unpin_current_cpu+0x1a/0x70
[] ? migrate_enable+0xb0/0x1b0
[] radeon_drm_ioctl+0x4b/0x80 [radeon]
[] do_vfs_ioctl+0x2e0/0x4d0
[] ? __fget+0x72/0xa0
[] SyS_ioctl+0x81/0xa0
[] tracesys_phase2+0xd4/0xd9


Rack #4/Slot #1 Chipset: "KAVERI" (ChipID = 0x130c)
[  600.266245] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
disables this message.
[  600.281856] XorgD 0002 0  3821   3812 
0x00400080
[  600.281865]  880223ddf908 0082 c1c0 
c328
[  600.281867]  88023720c328 0002 c308 
c328
[  600.281869]  81c1b480 880036cfcb60 000c 
880036cfcb60
[  600.281873] Call Trace:
[  600.281882]  [] schedule+0x34/0xa0
[  600.281885]  [] schedule_timeout+0x204/0x270
[  600.281929]  [] ? radeon_fence_process+0x16/0x40 
[radeon]
[  600.281949]  [] ? 
radeon_fence_any_seq_signaled+0x44/0x90 [radeon]
[  600.281968]  [] 
radeon_fence_wait_seq_timeout.constprop.7+0x227/0x330 [radeon]
[  600.281972]  [] ? prepare_to_wait_event+0x110/0x110
[  600.281992]  [] radeon_fence_wait_any+0x57/0x70 
[radeon]
[  600.282023]  [] radeon_sa_bo_new+0x2cf/0x4e0 [radeon]
[  600.282027]  [] ? dequeue_task_fair+0x43e/0x650
[  600.282055]  [] radeon_ib_get+0x37/0xf0 [radeon]
[  600.282078]  [] radeon_cs_ioctl+0x22d/0x820 [radeon]
[  600.282098]  [] drm_ioctl+0x1a4/0x630 [drm]
[  600.282104]  [] ? do_futex+0x109/0xb20
[  600.282106]  [] ? put_prev_entity+0x96/0x3f0
[  600.282122]  [] radeon_drm_ioctl+0xe/0x10 [radeon]
[  600.282125]  [] do_vfs_ioctl+0x2e0/0x4d0
[  600.282128]  [] ? __fget+0x72/0xa0
[  600.282131]  [] SyS_ioctl+0x81/0xa0
[  600.282134]  [] ? 

[PATCH 0/7] drm/exynos: clean ups

[Inki Dae]

On 2015년 02월 19일 22:22, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Hi,
> 
> Here goes some clean ups to the exynos drivers. The main clean ups is
> the presetting and zpos making the property immutable and the removal
> of *_win_data structures.

With your cleanup patch set, the plane test doesn't work. Have you ever
tested plane feature with modetest application?

I typed like below and it looks like no problem but I cannot see
anything on Panel except for cute four penguins.

# modetest -P 29:100x100+0+0
trying to open device 'i915'...failed.
trying to open device 'radeon'...failed.
trying to open device 'nouveau'...failed.
trying to open device 'vmwgfx'...failed.
trying to open device 'omapdrm'...failed.
trying to open device 'exynos'...success.
testing 100x100 at XR24 overlay plane 25

And for two plane test,

# modetest -P 29:100x100+0+0 -P 29:100x100+0+100
trying to open device 'i915'...failed.
trying to open device 'radeon'...failed.
trying to open device 'nouveau'...failed.
trying to open device 'vmwgfx'...failed.
trying to open device 'omapdrm'...failed.
trying to open device 'exynos'...success.
testing 100x100 at XR24 overlay plane 25
testing 100x100 at XR24 overlay plane 26

Still no screen.

Thanks,
Inki Dae

> 
> 
> Gustavo Padovan (6):
>   drm/exynos: remove unused exynos_crtc->win_enable() callback
>   drm/exynos: remove struct *_win_data abstraction on planes
>   drm/exynos: preset zpos value for overlay planes
>   drm/exynos: make zpos property immutable
>   drm/exynos: remove exynos_plane_destroy()
>   drm/exynos: remove leftover functions declarations
> 
> Mandeep Singh Baines (1):
>   drm/exynos: track vblank events on a per crtc basis
> 
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 176 +--
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 101 ++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c|  27 
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|  20 +--
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 195 ++
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  |  66 +++--
>  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 134 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 217 
> ++---
>  10 files changed, 311 insertions(+), 639 deletions(-)
> 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

cool.. something along the lines of:

 git pull --rebase  drm-next

and then

 git mergetool

should do the job

Thanks :-)

BR,
-R

On Thu, Mar 12, 2015 at 11:31 PM, John Hunter  wrote:
> Fine, I will try to catch up.
> Thanks anyway.
>
> Have a nice day,
> John
>
> On Fri, Mar 13, 2015 at 11:07 AM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
>> > Got it, maybe I should work on the drm-next or latest linux master.
>> >
>> > I am working on the drm git repo below for now as Daniel Vetter told me
>> > git://people.freedesktop.org/~airlied/linux
>> > I am quite confused now 'cause there are a bounch of git repo, I really
>> > do not know which one should I git clone.
>> >
>>
>> Hmm, I suspect airlied hasn't updated his master branch in a while,
>> which is probably causing confusing..  using his drm-next branch or
>> linus master would be better..  in general, drm-next for latest and
>> greatest drm is probably best, but right at the moment there is
>> probably not much difference from linus master.
>>
>> I usually end up 'git remote add'ing a bunch of different trees to
>> track both what has already landed in linus's master branch, and also
>> what is coming in drm-next (and various different arm trees related to
>> other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
>> a safe bet.
>>
>> BR,
>> -R
>>
>>
>> >
>> > On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
>> >>
>> >> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
>> >> wrote:
>> >> > From: John Hunter 
>> >> >
>> >> > IMHO, some annotations were copypaste from somewhere else, it is
>> >> > obviously not rightly modified. Hope I am right with that.
>> >> > ---
>> >> >  drivers/gpu/drm/drm_crtc.c | 115
>> >> > ++---
>> >> >  1 file changed, 56 insertions(+), 59 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> > index f2d667b..7f771e9 100644
>> >> > --- a/drivers/gpu/drm/drm_crtc.c
>> >> > +++ b/drivers/gpu/drm/drm_crtc.c
>> >> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> >> > drm_connector_status status)
>> >> >  /**
>> >> >   * drm_mode_object_get - allocate a new identifier
>> >> >   * @dev: DRM device
>> >> > - * @ptr: object pointer, used to generate unique ID
>> >> > - * @type: object type
>> >> > + * @obj: object pointer, used to generate unique ID
>> >> > + * @obj_type: object type
>> >> >   *
>> >> >   * LOCKING:
>> >> >   *
>> >> > - * Create a unique identifier based on @ptr in @dev's identifier
>> >> > space.
>> >> > Used
>> >> > + * Create a unique identifier based on @obj in @dev's identifier
>> >> > space.
>> >> > Used
>> >> >   * for tracking modes, CRTCs and connectors.
>> >>
>> >> so, I don't suppose you can rebase against a newer upstream kernel?
>> >>
>> >> From a quick look, it seems like the arg name errors where corrected
>> >> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
>> >> bodies fixes from your patch are still applicable.  In the current
>> >> form, the patch does not apply against drm-next (or latest linux
>> >> master), but most of it is still applicable and would be a very
>> >> welcome improvement.
>> >>
>> >> Thanks :-)
>> >>
>> >> BR,
>> >> -R
>> >>
>
>
>
>
> --
> Best regards
> Junwang Zhao
> Microprocessor Research and Develop Center
> Department of Computer Science 
> Peking University
> Beijing, 100871, PRC

[PATCH 6/6] drm/exynos: dsi: do not set TE GPIO direction by input

[Hyungwon Hwang]

On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index e385d24..58e0620 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1324,15 +1324,15 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi 
*dsi)
goto out;
}

-   ret = gpio_request_one(dsi->te_gpio, GPIOF_IN, "te_gpio");
+   ret = gpio_request(dsi->te_gpio, "te_gpio");
if (ret) {
dev_err(dsi->dev, "gpio request failed with %d\n", ret);
goto out;
}

te_gpio_irq = gpio_to_irq(dsi->te_gpio);
-
irq_set_status_flags(te_gpio_irq, IRQ_NOAUTOEN);
+
ret = request_threaded_irq(te_gpio_irq, exynos_dsi_te_irq_handler, NULL,
IRQF_TRIGGER_RISING, "TE", dsi);
if (ret) {
-- 
1.9.1

[PATCH 5/6] drm/exynos: dsi: add support for MIC driver as a bridge

[Hyungwon Hwang]

MIC must be initilized by MIPI DSI when it is being bound.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 77236ad..e385d24 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -280,6 +281,7 @@ struct exynos_dsi {
struct list_head transfer_list;

struct exynos_dsi_driver_data *driver_data;
+   struct device_node *bridge_node;
 };

 #define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
@@ -1787,7 +1789,22 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)

ret = exynos_dsi_of_read_u32(ep, "samsung,esc-clock-frequency",
 >esc_clk_rate);
+   if (ret < 0)
+   goto end;
+
+   of_node_put(ep);
+
+   ep = of_graph_get_next_endpoint(node, NULL);
+   if (!ep) {
+   ret = -ENXIO;
+   goto end;
+   }

+   dsi->bridge_node = of_graph_get_remote_port_parent(ep);
+   if (!dsi->bridge_node) {
+   ret = -ENXIO;
+   goto end;
+   }
 end:
of_node_put(ep);

@@ -1800,6 +1817,7 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
struct exynos_drm_display *display = dev_get_drvdata(dev);
struct exynos_dsi *dsi = display_to_dsi(display);
struct drm_device *drm_dev = data;
+   struct drm_bridge *bridge;
int ret;

ret = exynos_drm_create_enc_conn(drm_dev, display);
@@ -1809,6 +1827,12 @@ static int exynos_dsi_bind(struct device *dev, struct 
device *master,
return ret;
}

+   bridge = of_drm_find_bridge(dsi->bridge_node);
+   if (bridge) {
+   display->encoder->bridge = bridge;
+   drm_bridge_attach(drm_dev, bridge);
+   }
+
return mipi_dsi_host_register(>dsi_host);
 }

-- 
1.9.1

[PATCH 4/6] drm/exynos: dsi: add support for Exynos5433 SoC

[Hyungwon Hwang]

From: Donghwa Lee 

This patch adds support for Exynos5433. The goal is achieved by
1. Getting the address of registers from driver data
2. Getting the fixed value for registers from driver data
3. Getting different number of clocks using driver data
4. Getting max frequency of pixel clock from driver data

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
---
 .../devicetree/bindings/video/exynos_dsim.txt  |  24 +-
 drivers/gpu/drm/exynos/Kconfig |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 431 ++---
 3 files changed, 313 insertions(+), 144 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt 
b/Documentation/devicetree/bindings/video/exynos_dsim.txt
index ca2b4aa..fea7718 100644
--- a/Documentation/devicetree/bindings/video/exynos_dsim.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt
@@ -6,6 +6,7 @@ Required properties:
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs 
*/
+   "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
   - reg: physical base address and length of the registers set for the device
   - interrupts: should contain DSI interrupt
   - clocks: list of clock specifiers, must contain an entry for each required
@@ -30,10 +31,19 @@ Video interfaces:
   Device node can contain video interface port nodes according to [2].
   The following are properties specific to those nodes:

-  port node:
-- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
+  port node inbound:
+- reg: (required) must be 0.
+  port node outbound:
+- reg: (required) must be 1.

-  endpoint node of DSI port (reg = 1):
+  endpoint node connected from mic node (reg = 0):
+- remote-endpoint: specifies the endpoint in mic node. This node is 
required
+  for Exynos5433 mipi dsi. So mic can access to panel node
+  thoughout this dsi node.
+  endpoint node connected to panel node (reg = 1):
+- remote-endpoint: specifies the endpoint in panel node. This node is
+  required in all kinds of exynos mipi dsi to represent
+  the connection between mipi dsi and panel.
 - samsung,burst-clock-frequency: specifies DSI frequency in high-speed 
burst
   mode
 - samsung,esc-clock-frequency: specifies DSI frequency in escape mode
@@ -72,7 +82,15 @@ Example:
#address-cells = <1>;
#size-cells = <0>;

+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <_to_decon>;
+   };
+   };
+
port at 1 {
+   reg = <1>;
dsi_ep: endpoint {
reg = <0>;
samsung,burst-clock-frequency = 
<5>;
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 52282ac..5d297dd 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -41,7 +41,7 @@ config DRM_EXYNOS_DPI

 config DRM_EXYNOS_DSI
bool "EXYNOS DRM MIPI-DSI driver support"
-   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON)
+   depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS_DECON || DRM_EXYNOS7_DECON)
select DRM_MIPI_DSI
select DRM_PANEL
default n
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 05fe93d..77236ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -33,38 +33,6 @@
 /* returns true iff both arguments logically differs */
 #define NEQV(a, b) (!(a) ^ !(b))

-#define DSIM_STATUS_REG0x0 /* Status register */
-#define DSIM_SWRST_REG 0x4 /* Software reset register */
-#define DSIM_CLKCTRL_REG   0x8 /* Clock control register */
-#define DSIM_TIMEOUT_REG   0xc /* Time out register */
-#define DSIM_CONFIG_REG0x10/* Configuration register */
-#define DSIM_ESCMODE_REG   0x14/* Escape mode register */
-
-/* Main display image resolution register */
-#define DSIM_MDRESOL_REG   0x18
-#define DSIM_MVPORCH_REG   0x1c/* Main display Vporch register */
-#define DSIM_MHPORCH_REG   0x20/* Main display Hporch register */
-#define DSIM_MSYNC_REG 0x24/* Main display sync area register */
-
-/* Sub display image resolution register */
-#define DSIM_SDRESOL_REG   0x28
-#define DSIM_INTSRC_REG0x2c/* Interrupt source register */
-#define DSIM_INTMSK_REG

[PATCH 3/6] drm/exynos: mic: add MIC driver

[Hyungwon Hwang]

MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.

Signed-off-by: Hyungwon Hwang 
---
 .../devicetree/bindings/video/exynos-mic.txt   |  49 +++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 483 +
 4 files changed, 539 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c

diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt 
b/Documentation/devicetree/bindings/video/exynos-mic.txt
new file mode 100644
index 000..0804389
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-mic.txt
@@ -0,0 +1,49 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-mic";
+- reg: physical base address and length of the DECON registers set and
+   system register of mic.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+  "sclk_decon_eclk"
+- ports: contains a port which is connected to decon node and dsi node.
+address-cells and size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the
+   decon node or dsi node. The reg value must be 0 and 1 respectively.
+
+Example:
+SoC specific DT entry:
+mic: mic at 1393 {
+   compatible = "samsung,exynos5433-mic";
+   reg = <0x1393 0x48 0x13B8 0x1010>;
+   clocks = <_disp CLK_PCLK_MIC0>,
+  <_disp CLK_SCLK_RGB_VCLK_TO_MIC0>;
+   clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   mic_to_decon: endpoint {
+   remote-endpoint = <_to_mic>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   mic_to_dsi: endpoint {
+   remote-endpoint = <_to_mic>;
+   };
+   };
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 11acd6c..52282ac 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -103,3 +103,9 @@ config DRM_EXYNOS_DECON
depends on DRM_EXYNOS
help
  Choose this option if you want to use Exynos DECON for DRM.
+
+config DRM_EXYNOS_MIC
+   bool "Exynos DRM MIC"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos MIC for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 915842d..ad05a88 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -22,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += exynos_drm_rotator.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_GSC) += exynos_drm_gsc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_DECON)   += exynos_drm_decon.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o

 obj-$(CONFIG_DRM_EXYNOS)   += exynosdrm.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
new file mode 100644
index 000..c6d4fd1
--- /dev/null
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -0,0 +1,483 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics Co.Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundationr
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Sysreg registers for MIC */
+#define DSD_CFG_MUX0x1004
+#define MIC0_RGB_MUX   (1 << 0)
+#define MIC0_I80_MUX   (1 << 1)
+#define MIC0_ON_MUX(1 << 5)
+
+/* MIC registers */
+#define MIC_OP 0x0
+#define MIC_IP_VER 0x0004
+#define MIC_V_TIMING_0 0x0008
+#define MIC_V_TIMING_1 0x000C
+#define 

[PATCH 2/6] of: add helper for getting endpoint node of specific identifiers

[Hyungwon Hwang]

When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the order of dt nodes
to get the right node.

Signed-off-by: Hyungwon Hwang 
Acked-by: Rob Herring 
---
 drivers/of/base.c| 33 +
 include/linux/of_graph.h |  8 
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 36536b6..d7fa99d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2155,6 +2155,39 @@ struct device_node *of_graph_get_next_endpoint(const 
struct device_node *parent,
 EXPORT_SYMBOL(of_graph_get_next_endpoint);

 /**
+ * of_graph_get_endpoint_by_regs() - get endpoint node of specific identifiers
+ * @parent: pointer to the parent device node
+ * @port_reg: identifier (value of reg property) of the parent port node
+ * @reg: identifier (value of reg property) of the endpoint node
+ *
+ * Return: An 'endpoint' node pointer which is identified by reg and at the 
same
+ * is the child of a port node identified by port_reg. reg and port_reg are
+ * ignored when they are -1.
+ */
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   struct of_endpoint endpoint;
+   struct device_node *node, *prev_node = NULL;
+
+   while (1) {
+   node = of_graph_get_next_endpoint(parent, prev_node);
+   of_node_put(prev_node);
+   if (!node)
+   break;
+
+   of_graph_parse_endpoint(node, );
+   if (((port_reg == -1) || (endpoint.port == port_reg)) &&
+   ((reg == -1) || (endpoint.id == reg)))
+   return node;
+
+   prev_node = node;
+   }
+
+   return NULL;
+}
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e859eb7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -31,6 +31,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
 struct device_node *of_graph_get_next_endpoint(const struct device_node 
*parent,
struct device_node *previous);
+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg);
 struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -49,6 +51,12 @@ static inline struct device_node *of_graph_get_next_endpoint(
return NULL;
 }

+struct device_node *of_graph_get_endpoint_by_regs(
+   const struct device_node *parent, int port_reg, int reg)
+{
+   return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
const struct device_node *node)
 {
-- 
1.9.1

[PATCH 1/6] drm/exynos: add Exynos5433 decon driver

[Hyungwon Hwang]

From: Joonyoung Shim 

DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Hyungwon Hwang 
---
 .../devicetree/bindings/video/exynos-decon.txt |  65 +++
 drivers/gpu/drm/exynos/Kconfig |   6 +
 drivers/gpu/drm/exynos/Makefile|   1 +
 drivers/gpu/drm/exynos/exynos_drm_decon.c  | 539 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/regs-decon.h| 163 +++
 7 files changed, 778 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
 create mode 100644 drivers/gpu/drm/exynos/regs-decon.h

diff --git a/Documentation/devicetree/bindings/video/exynos-decon.txt 
b/Documentation/devicetree/bindings/video/exynos-decon.txt
new file mode 100644
index 000..377afbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos-decon.txt
@@ -0,0 +1,65 @@
+Device-Tree bindings for Samsung Exynos SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos5433-decon";
+- reg: physical base address and length of the DECON registers set.
+- interrupts: should contain a list of all DECON IP block interrupts in the
+ order: VSYNC, LCD_SYSTEM. The interrupt specifier format
+ depends on the interrupt controller used.
+- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys"
+  in the same order as they were listed in the interrupts
+  property.
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+- clock-names: list of clock names sorted in the same order as the clocks
+  property. Must contain "aclk_decon", "aclk_smmu_decon0x",
+  "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
+  "sclk_decon_eclk"
+- ports: contains a port which is connected to mic node. address-cells and
+size-cells must 1 and 0, respectively.
+- port: contains an endpoint node which is connected to the endpoint in the mic
+   node. The reg value muset be 0.
+- i80-if-timings: specify whether the panel which is connected to decon uses
+ i80 lcd interface or mipi video interface. This node contains
+ no timing information as that of fimd does. Because there is
+ no register in decon to specify i80 interface timing value,
+ it is not needed, but make it remain to use same kind of node
+ in fimd and exynos7 decon.
+
+Example:
+SoC specific DT entry:
+decon: decon at 1380 {
+   compatible = "samsung,exynos5433-decon";
+   reg = <0x1380 0x2104>;
+   clocks = <_disp CLK_ACLK_DECON>, <_disp CLK_ACLK_SMMU_DECON0X>,
+   <_disp CLK_ACLK_XIU_DECON0X>,
+   <_disp CLK_PCLK_SMMU_DECON0X>,
+   <_disp CLK_SCLK_DECON_VCLK>,
+   <_disp CLK_SCLK_DECON_ECLK>;
+   clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x",
+   "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk";
+   interrupt-names = "vsync", "lcd_sys";
+   interrupts = <0 202 0>, <0 203 0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   decon_to_mic: endpoint {
+   remote-endpoint = <_to_decon>;
+   };
+   };
+   };
+};
+
+Board specific DT entry:
+ {
+   i80-if-timings {
+   };
+};
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index a5e7461..11acd6c 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -97,3 +97,9 @@ config DRM_EXYNOS_GSC
depends on DRM_EXYNOS_IPP && ARCH_EXYNOS5 && !ARCH_MULTIPLATFORM
help
  Choose this option if you want to use Exynos GSC for DRM.
+
+config DRM_EXYNOS_DECON
+   bool "Exynos DRM DECON"
+   depends on DRM_EXYNOS
+   help
+ Choose this option if you want to use Exynos DECON for DRM.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index cc90679..915842d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -21,5 +21,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IPP)+= exynos_drm_ipp.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)+= exynos_drm_fimc.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR) += 

[PATCH 0/6] Add drivers for Exynos5433 display

[Hyungwon Hwang]

This patchset is based on the git(branch name: exynos-drm-next) which is
maintained by Inki Dae.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

This patchset adds 2 new device drivers, decon and mic, and adds support for
Exynos5433 mipi dsi. To enable display in a Exynos5433 board, decon(display
controller), MIC(Mobile image compressor), mipi dsi, and panel have to be turned
on. This patchset contains support for 3 drivers for SoC level devices.

Donghwa Lee (1):
  drm/exynos: dsi: add support for Exynos5433 SoC

Hyungwon Hwang (4):
  of: add helper for getting endpoint node of specific identifiers
  drm/exynos: mic: add MIC driver
  drm/exynos: dsi: add support for MIC driver as a bridge
  drm/exynos: dsi: do not set TE GPIO direction by input

Joonyoung Shim (1):
  drm/exynos: add Exynos5433 decon driver

 .../devicetree/bindings/video/exynos-decon.txt |  65 +++
 .../devicetree/bindings/video/exynos-mic.txt   |  49 ++
 .../devicetree/bindings/video/exynos_dsim.txt  |  24 +-
 drivers/gpu/drm/exynos/Kconfig |  14 +-
 drivers/gpu/drm/exynos/Makefile|   2 +
 drivers/gpu/drm/exynos/exynos_drm_decon.c  | 539 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   3 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 459 --
 drivers/gpu/drm/exynos/exynos_drm_mic.c| 483 ++
 drivers/gpu/drm/exynos/regs-decon.h| 163 +++
 drivers/of/base.c  |  33 ++
 include/linux/of_graph.h   |   8 +
 13 files changed, 1697 insertions(+), 146 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/video/exynos-decon.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_decon.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_mic.c
 create mode 100644 drivers/gpu/drm/exynos/regs-decon.h

--
1.9.1

[PATCH] drm/exynos: fix the number of overlay planes

[Hyungwon Hwang]

The number of overlay planes is one less than the maximum number of
planes, because the one is used for primary plane.

Signed-off-by: Hyungwon Hwang 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 90168d7..98a239a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -81,7 +81,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)

exynos_drm_mode_config_init(dev);

-   for (nr = 0; nr < MAX_PLANE; nr++) {
+   for (nr = 0; nr < MAX_PLANE - 1; nr++) {
struct drm_plane *plane;
unsigned long possible_crtcs = (1 << MAX_CRTC) - 1;

-- 
1.9.1

[PATCH] arm: dts: set panel clock properly for trats2 board

[Hyungwon Hwang]

Since commit abc0b1447d4974963548777a5ba4a4457c82c426 ("drm: Perform
basic sanity checks on probed modes"), it became mandatory to set
the pixel clock of the panel. This patch sets the pixel clock properly.

Signed-off-by: Hyungwon Hwang 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b4..073ff01 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -691,7 +691,7 @@

display-timings {
timing-0 {
-   clock-frequency = <0>;
+   clock-frequency = <6000>;
hactive = <720>;
vactive = <1280>;
hfront-porch = <5>;
-- 
1.9.1

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
> Got it, maybe I should work on the drm-next or latest linux master.
>
> I am working on the drm git repo below for now as Daniel Vetter told me
> git://people.freedesktop.org/~airlied/linux
> I am quite confused now 'cause there are a bounch of git repo, I really
> do not know which one should I git clone.
>

Hmm, I suspect airlied hasn't updated his master branch in a while,
which is probably causing confusing..  using his drm-next branch or
linus master would be better..  in general, drm-next for latest and
greatest drm is probably best, but right at the moment there is
probably not much difference from linus master.

I usually end up 'git remote add'ing a bunch of different trees to
track both what has already landed in linus's master branch, and also
what is coming in drm-next (and various different arm trees related to
other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
a safe bet.

BR,
-R


>
> On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
>> wrote:
>> > From: John Hunter 
>> >
>> > IMHO, some annotations were copypaste from somewhere else, it is
>> > obviously not rightly modified. Hope I am right with that.
>> > ---
>> >  drivers/gpu/drm/drm_crtc.c | 115
>> > ++---
>> >  1 file changed, 56 insertions(+), 59 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > index f2d667b..7f771e9 100644
>> > --- a/drivers/gpu/drm/drm_crtc.c
>> > +++ b/drivers/gpu/drm/drm_crtc.c
>> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> > drm_connector_status status)
>> >  /**
>> >   * drm_mode_object_get - allocate a new identifier
>> >   * @dev: DRM device
>> > - * @ptr: object pointer, used to generate unique ID
>> > - * @type: object type
>> > + * @obj: object pointer, used to generate unique ID
>> > + * @obj_type: object type
>> >   *
>> >   * LOCKING:
>> >   *
>> > - * Create a unique identifier based on @ptr in @dev's identifier space.
>> > Used
>> > + * Create a unique identifier based on @obj in @dev's identifier space.
>> > Used
>> >   * for tracking modes, CRTCs and connectors.
>>
>> so, I don't suppose you can rebase against a newer upstream kernel?
>>
>> From a quick look, it seems like the arg name errors where corrected
>> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
>> bodies fixes from your patch are still applicable.  In the current
>> form, the patch does not apply against drm-next (or latest linux
>> master), but most of it is still applicable and would be a very
>> welcome improvement.
>>
>> Thanks :-)
>>
>> BR,
>> -R
>>